The following diagram show the different elements of a Digital ID and how they interact with those involved in providing and receiving trust in the Digital ID ecosystem:
This section on Trust Rules defines how each component part of the Digital ID works, and how each part interacts with the other roles in the ecosystem to form a Smart Digital ID.
A Digital ID needs to be able to interpret the rules required to meet the needs of a particular use case. The rules might be:
A Digital ID will typically have a Rules Engine to allow it to interpret
Authentication happens when the user wants to:
The user uses the Authenticators to allow them to be re-recognized to use the Digital Identity, or an element of the Digital ID, for example a specific credential.
Some frameworks will implement a separate role of Authenticator Provider that allows a third party, such as a bank, to provide authenticators to the Digital ID. The separate authenticator provider issues, manages and revokes the usersâ credentials.
A Digital ID must help the user gather Digitized Credentials to meet the rules of the organizations the user is interacting with. A good digital ID will help the user through the process, guiding them to gather credentials to meet the often-complex rules of organizations.
If a user does not have a credential that is required by an organization, they can get a Digitized Credential from an Issuer.
The issuer could be the Authoritative Source of the credential, such as a government passport office, or a third party that creates a trusted credential using the source issued document and / or data.
Third party credential issuers may act as an aggregator for several authoritative sources of the same information, such as passport agencies, licensing agencies or educational institutions.
In circumstances where a third party issuer issues a credential, derived from an Authoritative Source, and subsequently it is deemed inaccurate or untrustworthy due to the third party issuerâs processing errors, the Authoritative Source would be held accountable for this error in digitized credential issuance.
The trust in the credential can be traced back to the Direct Issuer.
Credentials will contain Claims, Evidence and who the issuer is.
It will be digitally signed so that who the issuer is can be traced and itâs integrity is ensured.
A credential may also contain restrictions on who can read it, including allowing it to only be read if the reader is in the possession of the right cryptographic key.
The claims are the actual information about the user the credential contains, such as name, date of birth, education details, health information.
The evidence will show the type of the claim, how it was verified as belonging to the user, the rules applied to undertake that verification and who the issuer of the credential is.
The Digital ID might get a credential for the user from a credential Issuer that trusts that the Digital Identity Provider trusts the user, as per the below example:
The Indirect Issuer does not verify who the user is themselves.
The user may not give explicit consent for indirect access to credentials, instead some other legal permission such as legitimate interest may be used.
Another type of credential is an access credential. When a Relying Party wants to allow a user to access their services again and again, they might issue an access credential to the user which links their Digital ID to their account:
To support the principle of data minimization, where only the information vital to complete a transaction is share
The original issuer of the credential issues a cut down, or summarized, credential that only contains the information required to fulfil a specific transaction. For example, proving the user is over 18:
This credential may be re-used with many Relying Parties who have the same informational need, or restricted the relying party for whom it is issued (as per the example above).
This Framework guide recognizes that users should have the ability to include self-asserted credentials into their Digital ID where this would improve engagement with organizations they are interacting with.
In this case the user themselves may have a level of trust that is achieved through an identity assurance process (see later). Thus the user may be trusted, b
However, the inclusion of these credentials is considered out of scope of this framework guide and inclusion could be a service capability delivered as a âvalue-addâ option or feature implemented by a digital identity scheme. Consequently, the responsibility for any reliance on User provided/asserted Credentials by a scheme would be subject to the commercial terms between the Scheme and that Relying Party.
A Digital ID must help derive credentials to meet the rules of the organizations the user is interacting with. A smart Digital ID will help the user through the process, guiding them to gather credentials to meet the often-complex rules of organizations.
For example, the Digital ID rules engine may combine the credentials, direct and indirect, to create a Derived Credential that is of the level of assurance the organization requires. The creation of Derived Credentials must be executed by a trustworthy organization through the application of the rules for the Framework.
Here a Derived Credential for COVID Safe is created. Two digitized credentials have been used to derive the COVID Safe status, a Covid Vaccine and a Covid Test. The Digital ID provider is the issuer of the new Derived Credential.
A Derived Credential might be derived from a single Digital Credential, for example an Over 18 credential could be derived from a Driving License:
This derivation could be done by the Identity Provider, making them the issuer of the Derived Credential, or could be done by the original issuer of the credential, in this example the Driver Licensing Authority.
The Derived Credential will have authenticators bound to it that must be used to access and present the credential.
Zero Knowledge Proofs, where a cryptographic method is used to link the Derived Credential back to the Digitized Credential may be desirable to ensure that the original issuer of the credential is hidden from the party to whom the Derived Credential is issued, but is still legally traceable if required by the IdP.
The Rules Agent reads Digitized Credentials to derive the new credential
Like with the Indirect Issuer, the user may not interact directly with the Rules Agent. The Digital Identity Provider may call the Rules Agent directly with the userâs consent, passing them the required credentials to make the determination.
Identity Proofing and Assurance involves 3 steps:
The combination of these steps may be referred to as an Identity Assurance Model, or Identity Assurance Policy.
The Rules Engine (or Rules Agent) will determine what needs to happen in each step depending on the level of assurance being determined using an assurance policy:
Inclusion must be considered by trust frameworks to ensure the maximum number of users can access identity services. Techniques such as Vouching and manual evidence checking should be considered.
There are three techniques generally used in the Proofing process. A process for scoring the different data and methods used within each technique should also be considered:
A single credential might have one or more of the proofing techniques applied to it. For example, as passport might be used for both validation and verification. Credentials used for identity risk assessments might be deliberately independent from credentials used for validation or verification.
The result of the proofing process is a collection of trusted credentials, which can then be shared with, or presented to, Relying Parties. The collection of trusted credentials can also be used in an identity assurance process to achieve a level of trust, or assurance, to be presented to a Relying Party.
From trusted credentials, trusted claims can be drawn. For example, trust in a personâs name address and date of birth can the
Interoperability between frameworks might be achieved by aligning proofing scores or determining equivalence between proofing scores across different frameworks.
A more sophisticated form of a Rules Agent is an Identity Proofing Provider (IdPP).
Identity Assurance is the process of establishing trust in the user themselves.
Different use cases will demand different levels of trust in a userâs identity. The level of trust required is often dependent on the risk and value of the transaction. For example, more surety in a userâs identity is required to allow them to board a plane than to deliver a low value retail item to their address.
The level of trust achieved in an identity is a function of the amount and quality (proofing score) of the credentials collected about the user.
For example, a basic level of trust might be established by an issuer checking the userâs self-declared address against a database of known addresses. This might be a sufficient level of trust to deliver goods to this personâs address.
To board a plane however, trust in the userâs identity is required to be more strongly established:
The trust framework, or a trust scheme, might define the level of identity trust that Relying Parties in a particular sector require, or might choose to use, to meet their regulatory requirements. This is called a Level of Assurance.
As the assurance level increases, then the quality and mix of authenticators used to allow re-assertion of that level of assurance should also increase.
The following table describes the identity assurance process:
The following diagram shows a derived credential for a Level of Assurance linked to the bound authenticators and linked back to the credentials used in its establishment:
The result of this process is a trusted user with an assured identity. In some implementations of trust frameworks the level of assurance achieved is recorded against the user and can be presented to the Relying Party as an indicator of trust in the user.
Interoperability between frameworks might be achieved by aligning levels of assurance or determining equivalence between levels of assurance across different frameworks.