Cleanup Section 5.4.2. Matching Evidence against Reference Values

[nedmsmith]

Section 5.4.2 "Matching Evidence against Reference Values" uses endorsement and reference values incorrectly. This section should not describe endorsement processing since its focus is on reference values processing.

Suggested replacement text:
"A Reference Value Provider (RVP) may publish Reference Values, which are reviewed to determine if they are contained in the Accepted Claims Set (ACS). This section describes the process performed by the Verifier to determine which Reference Values should be compared to the Evidence claims contained in the ACS.

The verifier compares Reference Values claims with ACS claims. If they match, the RVP authority that asserted the claims is added to the ACS (for each claim that matched).

The following subsections describe how Reference Values are grouped (Section 5.4.2.1) and how a Verifier matches Reference Values against the ACS (Section 5.4.2.2)."

Notes:

• CoMID references were removed since reference claims can occur in other tag types (e.g., coswid) and is somewhat unnecessary.
• The signature over the RIM / COSWID is the authority that asserts claims (Not the authorized-by field). The authorized-by field describes authority matching constraints. Section 5.3.2.2 also needs wordsmithing.
• Reference Values claims aren't 'added' to the ACS, as they are already in the ACS but under the authority of the Attester rather than the RVP. Hence, the only action needed is for the RVP authority to be added to existing claims.

[deeglaze]

I found the concept of "matching" to be too vague. The document mentions that triples are "subject, object, predicate", but the representation is just subject and object. The predicate appears to be implicit in the selection of profile. To me that should be explicit if that's the intention. For example the in-toto attestation format explicitly represents predicates and names them through a URI to the schema definition. Predicates can be applied at individual value scales rather than profiles on entire CoRIM document scales, thus explicit representation to me is valuable for concision and reuse.

If "predicate" is meant to be implicitly raw equality with the intention of allowing later extensions by profiles, I'd like to see that third element of a triple called out as $$[whatever]-triple-predicate-type-choice. For instance, the Intel Profile for CoRIM defines generic expressions for numerical and set matching that would be nice to use across profiles. I don't really know how to distinguish predicate in a measurement map triple from a conditional endorsement, given that conditions can be defined as predicates apart from the quality of "stateful". Still the "or" semantics of matching a set of acceptable values is conditional without statefulness. The type definition is clear about intent for matching stateful environments, but can be abused for disjunctive stateless predicates, albeit with significant bloat.

I interpret then that conditional-endorsement-series-triples to be the entry point for endorsements, and statelessness is an empty refv that trivially applies. Emptiness is disallowed with the non-empty requirement for measurement-values-map, but what is the semantics of "matching" a singular / name: / 11 => "" key against Evidence? It seems to be purely diagnostic for reporting match failures of other keys in the map.

The endorsed-triples memberkey then is a shorthand to avoid bloated representation. If that is the case, it would help my conceptual understanding to see the presentation of triples-map use group notation to discuss the three triples as describing the general concept of endorsement.

triples-map = non-empty<{
  ? &(reference-triples: 0) =>
    [ + reference-triple-record ]
  // * &endorsement-triple-group-choice //
  ? &(identity-triples: 2) =>
    [ + identity-triple-record ]
  ? &(attest-key-triples: 3) =>
    [ + attest-key-triple-record ]
  ? &(dependency-triples: 4) =>
    [ + domain-dependency-triple-record ]
  ? &(membership-triples: 5) =>
    [ + domain-membership-triple-record ]
  ? &(coswid-triples: 6) =>
    [ + coswid-triple-record ]
  * $$triples-map-extension
}>

&endorsement-triple-group-choice //= &(
  ? &(endorsed-triples: 1) =>
    [ + endorsed-triple-record ]
  ? &(conditional-endorsement-series-triples: 8) =>
    [ + conditional-endorsement-series-triple-record ])
  ? &(conditional-endorsement-triples: 9) =>
    [ + conditional-endorsement-triple-record ])
)

[nedmsmith]

Reference value predicate means all the claims in the reference value triple have to have corresponding evidence claims or the RVP asserted claims cannot be assserted as attester actual state.

Endorsement predicate means if the attester is in a particular actual state, the endorsed claims can be appended to the attester's actual state.

non-equivalence matching has more to do with the behavior of the matching operator than the semantics of reference or endorsement.

[andrew-draper]

I don't think the document does it wrong, it does it using a different meaning of reference values and endorsements from the one you have Ned. We've discussed this and agreed to create a Multi-Conditional-Endorsement triple, which takes over the alternative meaning. As part of the change to section 5 I will try and use your text to describe your meaning of what Reference Value Triple means.

[nedmsmith]

I don't think the document does it wrong, it does it using a different meaning of reference values and endorsements from the one you have Ned.

CoRIM needs to be faithful to the terminology conventions in 9334 and the endorsements draft. There is no need to redefine reference values for the purposes of defining a multi-conditional-endorsement triple.

[andrew-draper]

Closed by #193