Endorsement triples could automatically instantiate domains #537
Description
The current spec says that the only way to instantiate a domain is through domain membership triples (DMT). It is also been discussed that an environment ID can double as a domain ID which means any Endorsement triple that is accepted into the ACS could also instantiate a DMT in the ACS. The current spec only describes instantiation of the ECT with cm-type = 'endorsement'. It could be updated to also allow instantiation of an ECT with cm-type = 'domain-member'.
The value to the corim author is they don't have to maintain as many DMT triples. Additionally, when a DDT is authored, there needs to be an already instantiated domain ID since DDT doesn't allow domain ID instantiation.
For example, if there was a trust dependency from D1 to D0. Before the DDT [D1, [D0]] can be written, the DMTs: [D0, [D0]] and [D1, [D1]] must first be written. But if there ware endorsement triples that generated ECTs for E0 and E1 plush D0 and D1, where the environment-map for E0 = the environment-map for D0 and also for E1 = D1, then the DMT triples can be omitted from the corim.
I.e., given the Endorsement triples:
[ Env-0, Meas-0 ]
[ Env-1, Meas-1 ]
The ACS would contain the following ECTs:
[ Env: E0, Meas: M0, cm-type: 'endorsement' ]
[ Env: E1, Meas: M1, cm-type: 'endorsement' ]
[ DomID: E0, Member: E0, cm-type: 'domain-member' ]
[ DomID: E1, Member: E1, cm-type: 'domain-member' ]
If there was a DDT that revealed a dependency from E1 to E0, the following triple can be added without also adding DMT triples.
[ DomID: E1, trustee: E0, cm-type: 'trust-dep' ]
Note that it wouldn't be forbidden to include the DMTs that enable the DDT to work:
[ DomID: E0, Member: E0, cm-type: 'domain-member' ]
[ DomID: E1, Member: E1, cm-type: 'domain-member' ]
However, the Verifier would observe that these ACS entries already exist, so would politely ignore the DMTs that add them again.
Note that E0 need not be a member of E1 for a trust dependency to exist. The only expectation is that E0 and E1 exist in the ACS. In otherwords, membership and trust relationships are intended to be orthogonal. This issue doesn't try to change that.
Note also that RVPs are "possible state" so wouldn't automatically generate domain membership ECTs. But corroborated RVPs/Evidence could generate domain member ECTs since this represents Attester actual state.