Data model

• User - Applicant, RA (and potentially instance of another type of user)
• Approval - Confirmation by another user (typically by RAs) regarding Assertions about an Applicant.
  We can not approve Attestations because there is a weak (N-N) link that relates Attestations to Assertions which could lead to Applicant exchanging Assertions for approved Attestations if they are not hard linked. If we link the Attestation hard to the Assertion, we are in fact approving the Assertion an not the Attestation. approved_with holds extra metadata about the approval, e.g. "in person". Since the earned Attestations will automatically follow from approving Assertions, the RA should be shown what Assertions she implicitly approves by approving the Assertion.
• Assertion - Record of some evidence that supports a Claim or the content or value(s) associated with that Claim; in case of self-assertions, it just serves to connect users to Claims about them (when they are just instances of Claims) and provide the actual content of the Claim (such as an external identifier, ID doc number etc., perhaps even to quantify the amount of confidence for the Claim in the form of LoA).
• Claim (= alternative descriptive name: assertion type?) - Standardised statement related to the applicant that is implied by the assertion, config is used for its technical implementation (e.g. in the case of a Federative Claim based on SAML it contains the entityID of the IdP/Proxy) and visual presentation. Claims determine what Assertions are about, so they classify Assertions and should reflect an Assertions-related 'vocabulary'. It is important to note that the Assertion is the instantiation of the Claim for the specific user, but it may warrant several Attestations!
• Claim_type (= alternative descriptive names: assertion group, assertion creator?) The technical back-end implementation of a Claim, e.g. SAML, OIDC or a Self-Asserted form. It takes the config from the parent Claim.
• Attestation - Kinds of conclusions that can be stated about users. They are based on Claims via the relations defined in the att2claims table.
• Attestations for Claims (att2claims) - Association between Assertions of Claims and Attestations they lead to.

Data usage notes

1. On the specificity of Claims:
   1. 'Assertion-Claim-Claim_type' train/procession reflects the technological (evidence/delivery/implementation) aspect.
   2. 'Assertion-Claim-att2claim-Attestation' train reflects the semantic aspect, i.e. what can be concluded about users based on evidence recorded in the Assertions.
   3. Since 'Claim' is the juncture for both a. and b., it can be quite granular, as it is specific in terms of both Assertions (what they contain how they are produced) and Attestations (what Assertions say about users)
2. The associations between Assertions of Claims and Attestations are currently untyped/unqualified, so there are no variants for different uses, but we may later introduce some 'LoAs' or clustering semantics: "The Assertion provides the Claim by which we <predicate> the related Attestation (determined by the Attestation's name) about the user", where <predicate> could be one of: "support (=corrobating evidence)", "imply (=sufficent evidence), "add info relevant for", "negate", or even "provide one of 3 required confirmations for").
3. Assertion→Claim→Attestation can be also used for internal purposes, e.g. as a mechanism to record some internally used information about users (in Assertions), their roles (in Claims) and permissions (in Attestations).