search

ietf-rats-wg / draft-ietf-rats-corim

Other
7 stars 7 forks source link

N/A in Conceptual Message Representation Requirements table #233

Open henkbirkholz opened 4 months ago

henkbirkholz commented 4 months ago

Is that policy (the "yet undefined RATS Conceptual Message")? Verifier_ECTs seem to be an indirect way to say either policy or "RVP or Endorser that is co-located with Verifier Owner". The N/A seems weirdly undefined to me - and i think it must be possible to map it to existing CMs, right?

deeglaze commented 4 months ago

Do you have a reference to the text you're talking about? I'm not quite able to follow what this issue is discussing.

nedmsmith commented 4 months ago

Since ECT isn't defined until later in the document, it didn't make sense to use terms that assume the reader understands it. I took a stab at rewording using common language.

I also replaced n/a with Verifier: | Verifier | List of expected actual state claims, List of Verifier generated claims | If the list of expected claims are in the ACS, then add the list of Verifier generated claims to the ACS with Verifier authority |

The goal is to provide a concise description of verifier objectives.

i think it must be possible to map it to existing CMs, right?

Yes. There is an unwritten section for Phase 5 where this should be documented. There are two use cases from existing comid that logically fit into phase 5. The triples-map defines:

  ? &(identity-triples: 2) =>  [ + identity-triple-record ]
  ? &(attest-key-triples: 3) => [ + attest-key-triple-record ]
  ? &(dependency-triples: 4) => [ + domain-dependency-triple-record ]

The identity and attest-key triples are essentially asking the Verifier to perform key validation checks. If validity checking isn't desired, the key object can be supplied as a measurement-values-map entry. If the keys are valid, the keys are added to the ACS with Verifier authority. The dependency triple is asking the Verifier to check the graph of which AEs attested which TEs based on an expected graph. If the graph checks out, the Verifier adds the environments that check out under the Verifier authority. We have not yet pulled in the internal representations for these use cases.

Phase 6 describes policy additions. This could also be a use case for Verifier making assertions if the policy is Appraisal Policy for Evidence where the Verifier Owner authors the policy. If the policy is satisfied, the new claims asserted are asserted with the policy owner authority. Given the policy owner and verifier are the same entity, this would be a case where the new claims are added under Verifier authority. This case is probably best described in phase 6 though.