Stateless conditional endorsement series use cases

[shnwc]

Currently, the CDDL definition of triples-map supports conditional-endorsement-series-triples. In each conditional-endorsement-series-triple-record, the subject is a stateful-environment-record, where there must be at least one field in its measurement-values-map.

In the new use case, the environment is stateless, without any measurement value field. A new triple record such as the stateless-conditional-endorsement-series-triple-record defined below will be able to support this use case.

stateless-conditional-endorsement-series-triple-record = [
  environment-map
  ; order matters: the first matching record wins and halts matching
  [ + conditional-series-record ]
  ? authorized-by: [ + $crypto-key-type-choice ]
]

In this triple record, the optional authorized-by field lists the authorities for all the measurement-values-map structures in the series.

Since there is no ambiguity between conditional-endorsement-series-triple-record (with its first entry as an record) and stateless-conditional-endorsement-series-triple-record (with its first entry as a map), the triples-map entry:

  ? &(conditional-endorsement-series-triples: 8) =>
    [ + conditional-endorsement-series-triple-record ]

can be updated to add stateless-conditional-endorsement-series-triple-record as an option:

  ? &(conditional-endorsement-series-triples: 8) =>
    [ + conditional-endorsement-series-triple-record /  stateless-conditional-endorsement-series-triple-record ]

[nedmsmith]

For conditional-endorsement-series-triple-record, the stateful-environment-map contained a measurement-map which contains authorized-by. A stateless alternative omits the measurement-map thereby eliminating the authorized-by also.

I think it's a reasonable consideration to put authorized-by in the triple record directly (as an object property or attribute) that provides object context (rather than being the object directly).

Note that other triples that define measurements that are not defined in terms of measurement-map don't have authorized-by which seems like an oversight. For example, identity-triple-record and attest-key-triple-record.

[shnwc]

To consolidate the existing conditional-endorsement-series-triples and conditional-endorsement-triples definition in triples-map, and the above stateless-conditional-endorsement-series-triple-record, we can have a single streamlined / unified CDDL definition to cover all the use cases.

conditional-endorsements-triple-record = [
  subject-record
  object-record
  ? authorizied-by: [ + $crypto-key-type-choice ]
]

subject-record = [
  environment-map
  ? common-reference: measurement-values-map
]

object-record = non-empty{[
  ? common-endorsement: measurement-values-map
  ? series: [ + conditional-series-record ]
]}

; Note: this is existing definition
conditional-series-record = [
  refv: measurement-values-map
  endv: measurement-values-map
]

The triples-map is updated to include this conditional-endorsements-triple-record:

  ? &(conditional-endorsements-triple: 10) =>
    [ + conditional-endorsements-triple-record ]

In the above conditional-endorsements-triple-record definition, the subject-record is the same as stateful-environment-record when the optional common-reference entry is present, otherwise it contains the environment-map in the stateless-conditional-endorsement-series-triple-record.

The object-record has two optional entries, and at least one of them need to be present. If only common-endorsement is present, it supports the case cases for conditional-endorsement-triples. If only series is present, it supports the use cases for conditional-endorsement-series-triples. If both entries are present, each conditional-series-record in series contains record-specific reference and endorsement claims, while common-reference and common-endorsement contain reference and endorsement claims common across all conditional-series-records.

[yogeshbdeshpande]

Is this not achieved now by MEC Triples which is added recently. I think, this issue needs to be closed!

[yogeshbdeshpande]

@andrew-draper to check if all concerns are addressed and close it subsequently!