Page History

...

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)
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").
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).
User/Claim Assertions will only exist in two flavours: the one that has been approved by the RA, as a copy of the last known good state of the Attestation and (possibly) a newer one that represents the refreshed state of the Assertion. The refreshed Assertion can be (re)approved by the RA and when doing so, will invalidate the approval of the old assertion, so that on any moment in time there will only be one approval->assertion->claim→attestation train.