The identity ecosystem can involve many different roles. The roles differ between each implementation â for example, centralised and federated models will differ, as will self-certified / self-sovereign models, and one person or organization (an âactorâ or âparticipating entityâ) may perform more than one role.
An overview of the roles that could be involved is shown below. This model assumes a single trust framework and Trustmark. It supports the implementation of the framework though trust schemes that specialise the framework for specific sectors or use cases.
Not all framework implementations will have all of these roles. A key design choice for when creating a framework is which roles to implement; this choice will be influenced by whether the body defining the framework is creating an open market approach to identity trust, or creating a single implementation of a framework and scheme for a territory.
A brief explanation of each different role is shown below:
Role | Explanation |
Trust Framework | A trust framework is a set of specifications, rules and agreements often referred to by various names, such as âoperating regulations,â âscheme rules,â or âoperating policies.â. The framework is likely to include a certification process by which other roles in the eco-system can be shown to be compliant with the trust framework. Each trust framework is likely to need some form of governance or oversight authority to maintain and oversee compliance with the framework. |
Authoritative Source | An organization that is regarded as the definitive authority for identity or eligibility information, often in law. Examples of authoritative sources include government agencies (passports, driving licenses), banks, educational institutions, healthcare providers. |
Issuer | Issues some form of credential that proves who the user is and / or what they are eligible to do. This could be: electronic issuance of ID documents (e.g. passport, driving license), certificates of education, qualifications, entitlements, medical information, proof of social / societal activity, ID fraud risk assessments through to a confirmation of the users age bracket (e.g. over 18) or a determination of the Level of Assurance. They could be, or could get data from, a trusted âauthoritative sourceâ to allow the credential they issue to be validated. The provision of eligibility data is sometimes referred to as an âattribute serviceâ. |
Direct Issuer | Issues the user with a digitized credential after verifying directly that the user is who they claim to be. |
Indirect Issuer | Issues the user with a digitized credential. Relies on the Identity Provider to verify who the user is. A provider of an API call from a Digital Identity Provider to validate information provided by the user is an example of an indirect issuer. |
Derived Issuer | Derives a new status from credential(s) gathered for a user, such as Over 18 or a Level of Assurance. An Identity Provider will often play the role a Derived Issuer, or an external Rule Agent might play this role. |
Access Issuer | Issues an Access Credential to an account in a Relying Party to allow the user to logon to that Relying Party again and again. Relying Parties are often an access issuer. |
Identity Provider |
Creates and maintains a Digital Identity for users that they can present to Relying Parties to prove who they are and what they are eligible to do. The Digital Identity must comply with the overall rules of the trust framework and of any sector-specific trust schemes. In the self-sovereign model, the provider of an app or wallet to hold verifiable credentials is the Identity Provider.
An Identity Provider has a rules engine that allows it to determine a Relying Parties requirement through an RP Credential Request, and assist the user through the process of gathering any required credentials and applying the rules to those credentials to derive new ones to meet the Relying Parties needs. They may âoutsourceâ |
Identity Proofing Provider | The ID Proofing Provider understands ID Proofing models and will work directly with the user to take them through the ID Proofing process.At the end of the process the ID Proofing Provider will share the Digitized Credentials gathered as part of the proofing process and the result of the proofing process, a Derived Credential representing the level of ID assurance achieved, back to the Digital ID. |
Rules Agent | A specialist in applying a set of rules to create a derived credential, such as a level of assurance or a complex finance assessment on the user. |
Authenticator Provider | A specialist in providing authenticators, such as biometrics, leveraged by an Identity Provider to issue and manage a userâs authenticators. Banks may be particularly suitable to play this role as they |
Broker |
In a market where there are multiple Identity Providers, a broker allows a Relying Party to enter a single contract and single technical integration to access a critical mass of digital identities or eligibility information from different Identity Providers or credential issuers. A Broker may retain Evidence relating to a Digital ID transactions on behalf of the Relying Party, but this retention shall be performed in accordance with any Scheme operational rules |
Trust Scheme | Defines an implementation of the framework within the overarching rules defined by the trust framework. Implementations could be sector specific, territory specific or global-multinational. For example, sector-specific use cases, requiring a separate trust scheme, might be: online age verification using zero knowledge proofs, anti-money-laundering checks, or air travel. These sector-specific schemes will often contain the actual implementation of local or global regulations specific to that sector. Schemes may further define, extend or omit optional elements of the trust framework to tailor the identity service to the needs of the specific implementation. For example, the trust scheme might define the ID Proofing requirements for a specific sector within the overarching requirement set by the trust framework. Where the line between trust framework and trust scheme is drawn needs careful consideration. |
Trustmark | Communicates trust and compliance with the framework and schemes to the end user and Relying Parties. Indicates that a participating entity is associated with a particular trust framework and allows an individual to verify that is the case. |
ID Solution | Each Relying Party a user deals with will need a solution to record the Identity Provider, and / or credential issuer services that are used. The Relying Party may also record permissions or access rights against an identity that are specific to that Relying Party. Many Relying Parties will use a Customer Identity Access Management (CIAM) system to achieve this. |
Relying Party | Someone providing goods or services that the user wants to access, who requires some level of trust in who the user is, or what they are eligible to do. Also, who may want the user to re-access their services from time to time. The Relying Party might become a form of issuer to enable re-access, issuing an Access Credential. A Relying Party could be an organization but could also be another person or a âthing". |
The role definitions above can also be found in the OIX Glossary of Terms.
It is important to note that in many cases these different roles can be played by one âactorâ, or party. For example:
When designing a framework, it is important that the obligations that will be put on each party playing a role in the framework is considered. The applicability of each policy, procedure, rule and standards to each role needs to be determined.
In each of the following sections regarding the different elements of the framework, the roles that are obligated to fulfil that element are identified. Those constructing and managing frameworks can use these references to construct contracts for specific roles, or parties, within the implementation of a framework.
Tables in the contents section of this guide have a column entitled âWho?â that indicates the obligated roles for each element of the framework. The following abbreviations are used: