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 (explain why approvals do not approve claims or attestations - e.g. because we want RAs to approve/confirm the validity of concrete evidence (or just the referenced claim), and not some more vague concepts; also explain approved_with) [So when the user is about to approve some assertion/claim, all associated attestations should be also displayed in order to show the ramifications of this approval...]
• Assertion - Representation 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)
• Claim (= alternative descriptive name: assertion type?) - Please elaborate, particularly config; e.g.: Specific statement related to the applicant that is implied by the assertion, config is used for its (or attestation's?) visual(?) presentation (is this correct? is there something additional or some other aspect, e.g. exposure of assertions to specific kinds of users or some external entities?). The claim determines what an assertion is about, so it is a classifier for assertions that should reflect an assertions-related 'vocabulary'. (It is important to note that one assertion the incarnation of a single claim, but they may warrant several attestations!)
• Claim type (= alternative descriptive names: assertion group, assertion creator?) - Please elaborate, particularly handler e.g.: "Type" of claim which exclusively groups claims (and associated assertions) based on the way they are obtained, created, or their common purpose. (Are the associations of newly created assertions with their claims hardcoded within handlers that produce these assertions?)
• Attestation - Kinds of conclusions that can be stated about users. They are based on claims [Do we need some config or details here as well, e.g. to determine the (visual) presentation of attestations or their exposure to specific kinds of users or external entities?]
• Attestations for claims (att2claims) - Association between claims of assertions and attestations they lead to.

Data use notes

1. On the specificity of claims:
   1. 'Assertion-Claim-Claim type' train/procession reflects the technological (delivery/implementation) aspect.
   2. 'Assertion-Claim-att2claim-Attestation' train reflects the semantic aspect, i.e. what can be concluded about users based on 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 claims of assertions and attestations are currently untyped/unqualified, so there no different variants for different uses but we may later introduce some 'LoAs' or clustering semantics: "A specific 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 (direct evidence), "add info relevant for", "negate", or even "provide one of required 3 confirmations").
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).