Information Model Description

[hannestschofenig]

This PR addresses issues #59 and #60.

[mcr]

I would love an example of a composite device.

[ounsworth]

Comments:

In the aasvg, you have "1..n EvidenceBundle", "0..n CertificateAlternatives", and "1..n EvidenceStatement".
I agree that's how I also imagine this being user,d but technically they are all declared as SEQUENCE, so are all 0..n.
For example, if your Evidence is already an X.509 certificate then you could conceivably put that in the SEQUENCE OF CertificateAlternatives and leave the SEQUENCE OF EvidenceStatement empty. I'm not sure that's a good idea, but it is allowed under the current definitions.

I think we should add a usecase that deals with Endorsements. This is related to #63.
Possibly just modify the wording of #3 to "... multiple Attesters or Endorsers", and "... Evidence or Endorsement statements".

I think there are actually two valid ways of addressing #4: the one you describe where a Verifier has to look across EvidenceBundles in order to find the complete cert chains that it needs, or merging all of those into a single EvidenceBundle with a single de-duplicated SEQUENCE OF CertificateAlternatives; that would look like:

 +-------------------------+
 |  EvidenceBundle         |
 +-------------------------+
 | EvidenceStatements {     |
 |   EvidenceStatement (1)  |
 |   ...                     |
 |  EvidenceStatement (n)  |
 | }                         |
 | CertificateAlternatives { |
 |  EndEntity (1)          |
 |  ...                     |
 |  EndEntity (n)            |
 | <remainder of           |
 |     certificate chain >     |
 | }                   |
 +-------------------------+

We could call what you wrote 4a, and this 4b. 4a helps the verifier by providing 1-to-1 mapping between EvidenceStatements and the EndEntity certificate to verify it, but makes the Relying Party implementation more complicated, for example by needing to re-assemble complete certificate chains across EvidenceBundles if the Verifier needs to be invoked separately for each EvidenceStatement.
Whereas 4b means that each EvidenceBundle is self-contained and any EvidenceStatement can be verified using only the SEQUENCE OF CertificateAlternatives in its bundle, but Verifiers will have to do proper certificate path building since the SEQUENCE OF CertificateAlternatives is now a cert bag and not a cert chain.
Pros and Cons to both.