Versions Compared

Old Version 3

changes.mady.by.user Branko Marovic

Saved on

compared with

New Version Current

changes.mady.by.user Martin van Es

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Code

Documentation

Mind map with requirements

Access

Data model

...

Image Added

Entities

  • Applicant - The user of who want to have their identity vetted. They use Applicant vetting application.
  • RA (registration authority) - The user responsible for approving claims that have been presented by applicants. They use RA vetting application.
  • User - Applicant, RA (and potentially instance of another type of user).
  • Approval - Confirmation by another user (typically by RAs) regarding assertions 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...] 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 and 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 Assertion - Representation of some evidence that supports a claim Claim or the content or value(s) associated with that claim Claim; in case of self-assertions, it just serves to connect users to claims Claims about them (when they are just instances of claims Claims) and provide the actual content of the claim Claim (such as an external identifier, ID doc number etc., perhaps even to quantify the amount of confidence for the claim) Claim in the form of LoA).
  • Claim (= alternative descriptive name: assertion type?) - Please elaborate, particularly config; e.g.: Specific Standardised 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, technical implementation (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 assertionsin 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 one assertion the incarnation of a single claim, but they the Assertion is the instantiation of the Claim for the specific user, but it may warrant several attestations Attestations!)
  • Claim_type (= alternative descriptive names: assertion group, assertion creator?) - Please elaborate, particularly handler The technical back-end implementation of a Claim, 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?)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 [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?] Claims via the relations defined in the att2claims table.
  • Attestations for Claims Attestations for claims (att2claims) - Association between claims of assertions and attestations Assertions of Claims and Attestations they lead to.

Data

...

usage notes

  1. On the specificity of claimsClaims:
    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 assertionsevidence 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 Assertions (what they contain how they are produced) and attestations Attestations (what assertions Assertions say about users)
  2. The associations between claims Assertions of assertions Claims and attestations Attestations are currently untyped/unqualified, so there are no different variants for different uses, but we may later introduce some 'LoAs' or clustering semantics: "A specific assertion The Assertion provides the claim Claim by which we <predicate> the related attestation Attestation (determined by the attestationAttestation's name) about the user", where <predicate> could be one of: "support (=corrobating evidence)", "imply (direct =sufficent evidence), "add info relevant for", "negate", or even "provide one of 3 required 3 confirmations for").
  3. Assertion→claim→attestation Assertion→Claim→Attestation can be also used for internal purposes, e.g. as a mechanism to record some internally used information about users (in assertionsAssertions), their roles (in claimsClaims) and permissions (in Attestations).
  4. 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 attestations).time there will only be one approval->assertion->claim→attestation train.

Newly discovered related conceptual works