Using a Digital ID must be delightful, not painful.
Creating digital identities, or wallets, full of digitized versions of real-world credentials and then leaving the user to work out which credentials, or parts of credentials, are needed for each transaction is not sufficient.
The userâs Digital ID must be intelligent! It must be Smart!
It must be able to accept âthe rulesâ for a transaction and work out how to fulfil those rules on behalf of the user. If that means getting a credential the user does not currently have, the Smart Digital ID should assist the user to get it. If it means combining information from several credentials to meet data minimised needs, the Smart Digital ID must do that safely and with the userâs consent.
Users cannot be expected to need to understand âthe rulesâ â the rules are too complicated! Try working out the rules for a âcovid safeâ status for instance? The userâs Smart Digital ID must be their assistant to help them through the process.
The Smart Digital ID is a service the user depends on to ensure they can prove who they are and what they are eligible to do as they go about their day to day lives. The Smart Digital ID must seamlessly provide trust in who the user is and what they can do.
A Smart Digital ID could be delivered to the user via a Smart Wallet on their device or it could be securely hosted in the cloud.
This guide explores the components a Digital ID needs to be Smart, and defines how trust frameworks can be designed to support Smart Digital ID.
For many types of transaction, digital or otherwise, organizations need to know who they are dealing with and what that person is able, or eligible, to do. The rise of Identity Theft means that organizations cannot rely on a person simply claiming to be who they are, independent verification and risk checks are required. Equally, genuine individuals may try to present false information about themselves in order to gain access to goods, services or environments that they do not have the eligibility for. Examples where trust is needed, and the risks to be mitigated are:
Users interact with many different types of organization online, for many different purposes:
In order to simplify the sourcing of Credentials, ID solutions may take credential services from an organization that creates and markets âpackagesâ of credentials, a âcredential aggregatorâ. These credentials must have been created in accordance with the framework.
Organizations providing services to users typically have their own tailored ID Solution that enables them to:
The user ends up repeating the same process again and again with each organization they deal with, and has many usernames and passports:
This model has a number of challenges for each party:
A Digital Identity may enable a user to provide trust in their identity to any organization.
The Digital Identity has the following advantages for users and organizations:
A Digital ID is a set of verified digital Credentials. Examples of Credentials include:
A user will approach an organization for services and will provide the organization with the information they need to do business with the user using their Digital ID.
The user might then use their Digital ID to access an account they set up with that organization.
The Digital ID will come from a provider that the user trusts to give them the tools to manage their ID. The Digital ID might be in the form of a âwalletâ that allows the user to collect and manage credentials. The wallet might be on a user mobile device or managed in the cloud.
The simplest implementation of Digital ID is where the user is providing a Digitized version of a real-world Credential, such as a passport, driving license, covid vaccine or qualifications.
The Digitized Credential must have been verified as belonging to the user.
Authenticators are used to identify the user is the owner of the Digital ID and Digitized Credential.
If we consider what also seems like a simple example â proving the user is Over 18 - we quickly see that the Digital ID must have some level of sophistication if it is to help the user prove who they are for everyday tasks. It must be a Smart Digital ID:
Organizations might not ask the user for a specific Digitized Credential but might ask for information that can be derived from one or more credentials.
For example, the user can provide a Derived Credential that says they are Over 18.
This could be derived programmatically by the Smart Digital ID from a digitized credential that has been verified as belonging to the user. The digitized credential itself does not need to be shared with the wine seller.
The Rules for deriving Over 18 are determined by a Rules Engine. For instance, a rule might be that a) the Over 18 proof must be derived from a government issued credential and b) the government credential must have been verified as belonging to the user to an agreed standard and c) the user has used authenticators to access the digital ID that prove this is the genuine user.
Organizations must be able to set their own rules.
To answer an organizations question, a complex set of rules might be required that may require several digitized credentials to be gathered.
Another example is proving a user is Covid Safe:
The rules for a COVID Safe status might be: a vaccine course from a list of approved types completed within the last 12 months PLUS a negative test from a list of approve types within the last 72 hours.
Rules may vary by use case, trust framework or individual organization
Many Derived Credentials are point-in-time and need to re-assessed at point of next request.
Also, Digitized Credentials may expire or be revoked. In which case and other credentials derived from them may no longer be valid.
Using a finance example, to open an account with a financial services provider the user might need to prove they have a sufficient level of assurance:
Trust that the user is the genuine individual is derived from the credentials gathered by the user.
For example, a photo from a passport or driving license cross checked with a selfie of the user, can be used to verify that this is the genuine user. Or a logon to online banking.
Higher levels of assurance usually also need multiple robust Authenticators to be âboundâ to the users as part of the proofing process, to provide multi-factor Authentication.
A Level of Assurance is a form of Derived Credential. Levels of Assurance are dynamic and need to be continually re-assessed as the users' credentials expire and fraud risks are re-assessed.
The process is handled by the Rules Engine. The user sees that they are asked to gather certain credentials and set up specific authenticators. They will not usually be aware they have achieved a specific Level of Assurance.
A user may have many different Levels of Assurance for different use cases and organizations.
Some trust frameworks may also require that the credentials used to derive a level of assurance are shared with the organization, as a form of evidence.
Finally, users may use their Digital IDs to logon to an organizational account again and again. This does not just mean financial accounts, but any organization the user has an ongoing relationship with:
The organization would issue the User with an Access Credential that is their Account Key for that organization.
Or many organizations could rely on a generic Account Key created by the Digital ID.
Next time the user interacts with the organization they present them with their Account Key to show them who they are.
The organization may require authenticators of a particular type or level of quality to trust the Digital ID.
Rules Engine. The Smart Digital ID works out what a user needs to meet an organizations business rules using a rules engine or rules agent, and helps the user gather, derive and present credentials to meet the organizationâs needs. The Digital ID must be smart. It must make the users life easier. To do so it must interpret organizations rules on behalf of the user. The user cannot be expected to understand and process the complex rules that organizations must work to. The Digital ID should work out whether the user have right information or credentials required. If they donât have them, it should help them get them. It should combine credentials if necessary to created derived credentials that meet the organizations rules, removing processing and data handling burden from organizations. It should apply the principle of data minimisation, only sharing the information organization require to meet their needs; no more, no less.
Digitized versions of Credentials â The Digital ID can carry credentials such a passport, driving license, vaccine certificate or relevant qualifications.
Derived credentials â The Digital ID can also work out that users meet the business rules of an organization, such as being over 18, COVID safe or meeting a specific âlevel of assuranceâ.
Digital ID to access an account - Organizations can also choose to allow access to accounts they hold with you. Thus, removing the need for you to issue your own logon authenticators (e.g., user IDs and passwords).
Firstly â this is likely to be an evolution, not a revolution. Organizations will move towards using Digital Identities over time. Organizations might use Digital IDs in all ways described below, or just one.
Some organizations might only use a Digital ID to gather credentials to proof the user themselves and will continue to issue the user with their own organization-specific authenticators.
Some organizations will rely on the Digital ID to make complex rule-based decisions for them, leveraging derived credentials such a Level of Assurance or Over 18.
Other organizations might issue their own
Other organizations might user a Digital ID solely as an access method, as many organizations do with OpenID Connect today, to save issuance and management of their own authenticators. The organization would continue to get their proofing and eligibility information directly:
Finally, some organizations might move to fully embrace the use of Digital Identities for both account opening and ongoing account access (Digital ID access to accounts):
Organizations will still need their own ID Solution â often referred to as a Customer Identity Access Management (CIAM) Solution - to manage their interaction with the Digital ID and determine the userâs privileges within that organization.
There may be multiple Identity Providers in a particular market. This may be enforced to ensure a competitive market, or driven by market forces alone and consumer choice. Or an ID market might be formed by a consortium of companies who already issue IDs to a critical mass of users, such as Banks or Telcos.
Organizations will not want to contract with, and separately interface to, Digital Identities from different Identity Providers, so Brokers are likely to emerge, who aggregate Identity Providers and / or credential issuers into single services.
To establish Trust within an identity ecosystem, rules are required to which all parties subscribe that enable organizations, or Relying Parties, to consume identities and their associated information with confidence.
Accordingly, some form of governance framework is required.
Governance frameworks are not a new concept. They are commonly used outside of the world of digital identities, to govern a variety of multi-party systems where participants desire the ability to engage in a common type of transaction with any of the other participants, and to do so in a consistent and predictable manner. In such cases, they are proven to work and scale. Common examples include credit card systems, electronic payment systems, and the internet domain name registration system, which all rely on a set of interdependent specifications, rules, and agreements. This set of specifications, rules and agreements is referred to by various names, such as âoperating regulations,â âscheme rules,â or âoperating policies.â
In the world of identity systems, we refer to the governance framework as the âtrust framework.â
âTrust frameworkâ is a generic term often used to describe a legally enforceable set of specifications, rules, and agreements that govern a multi-party system established for a common purpose, designed for conducting specific types of transactions among a community of participants, and bound by a common set of requirements. Examples include credit card systems (such as Visa or MasterCard), electronic payment systems (such as SWIFT or NACHA), the domain name registration system (ICANN), and identity systems. They all share a variety of common characteristics, including the fact that each participant needs assurances that each other participant will follow the same set of rules applicable to its particular role.
The set of specifications, rules, and agreements that govern such multi-party systems are referred to by various names. For example, the Visa payment card system refers to them as âOperating Regulationsâ; the NACHA electronic funds transfer system calls them âOperating Rulesâ; some identity systems do refer to them as a âtrust frameworkâ, such as Australiaâs DTA, Canadaâs DIACC framework, Indiaâs Aadhaar service and eIDAS) others refer to them as âScheme Rules.â Other identity systems call them âCommon Operating Rulesâ, âOperating Policies.â or similar descriptions.
OIX uses the term âtrust framework,â as that is the term most commonly used in the field of digital identity management.
A âtrust frameworkâ means an environment for identity transactions governed by a set of rules where users, organizations, services, and devices can trust each other. A trust framework involves:
a) a set of rules: roles, principles, policies, procedures and standards,
b) a group of participating entities,
c) governing the collection, verification, storage, exchange, authentication, and reliance on credentials about an individual person, a legal entity, device, or digital object, for the purpose of facilitating trusted identity transactions.