Written by In our Live 5 for 2021, we said that governance would be a major topic for digital identity this year. Nowhere has this been more true than in the UK, where the government has been diligently working with a wide set of stakeholders to develop its digital identity and attribute trust framework – the rules of road for digital identity in the UK. The work continues but with the publication of the second iteration of the framework I thought it would be helpful to focus on one particular aspect – how might the framework apply to decentralised identity, given that is the direction of travel in the industry.
The roles in federated and decentralised identity schemes are different
Many existing trust frameworks are designed around a particular identity scheme such as the BankID schemes, itsme, Verified.me and so on. Each of these schemes has a defined set of participants and roles to make it work, with the rules stating what is expected of each participant based on their role. The UK framework is however seeking to be much broader, being applicable to a range of digital identity schemes or solutions. But this is not straightforward – the roles in a federated identity scheme are quite different to the roles in a decentralised identity scheme.
In the current iteration of the framework, the government has chosen to define the following key roles:
- Identity Service Provider – established the identity of the user and potentially provides them with an identity “account” so their identity can be re-used in multiple contexts.
- Attribute Provider – provides information about the user that can either be used in the establishment of their identity or can be associated with their identity if required to access to a service (e.g. a qualification or entitlement could be such an attribute).
- Orchestration Provider – brings the parties together in a network to avoid everyone having to integrate with everyone else.
- Relying Party – the service provider that wants to establish the identity or other attributes of the user, in order to be able to deliver the requested service.
These are typical of the roles you would expect to see in a federated identity scheme, such as BankID or indeed the yet to be decommissioned GOV.UK Verify. By contrast a decentralised or self-sovereign digital identity scheme would typically include the following different set of roles:
- Issuer – the party that issues cryptographically verifiable credentials (containing identity data or attributes about the subject) to the subject.
- Wallet Provider – the party that provides the subject with a wallet to manage their credentials. Typically, the wallet provider cannot see the contents of the wallet.
- Verifier – the service provider or other party that relies on credentials presented by the user (using their wallet) by verifying their cryptographic integrity as well as using the registry to determine that they trust the issuer.
- Registry – a repository for details of the issuers of credentials.
Federated and decentralised schemes have different roles and so it should be expected that some of the framework rules may need to be different too.
Why does any of this matter?
The rules of the framework need to apply clearly to any party that wishes to participate in the framework including legal, commercial and technical aspects – and if they are not clear this will create issues with participation and confusion in the marketplace. Furthermore, if the framework assumes a particular way of putting the pieces of the puzzle together, it may stifle innovation.
There may not be a simple mapping between federated and decentralised identity roles.
To explore this a little further let’s consider the Identity Service Provider role. The framework says that role will be responsible to:
- “Prove and verify” the identity of users following the government’s identity proofing standard GPG45, and
- (Optionally) Provide the user with an “account” allowing so that the verified identity can be used in multiple contexts, which requires establishing authenticator(s) to ensure only the user can access their account.
The framework also says that the Identity Service Provider requirements can be met by multiple parties, or more specifically that an “Identity Service Provider” may deliver a subset of the requirements. For example, a biometric facial matching provider could be certified against just the biometric facial matching requirements in GPG45. End-to-end, however, all of the Identity Service Provider requirements must be met somehow for an identity transaction to be recognised.
To see how these requirements might be met by a decentralised identity scheme, let’s consider two example scenarios (there are others):
Scenario 1: Single Issuer
The simplest decentralised scenario is that a single issuer performs all parts of the GPG45 and issues a credential to the user that contains a fully verified identity. That credential is then held by the user in their wallet until they need to present it to a verifier. It would be the Wallet Provider who would be giving the user the optional “account” (i.e. their wallet) referred to in the framework to facilitate re-use of that digital identity.
The Identity Service Provider role as defined is therefore split across two parties (the issuer and wallet provider) and it is clear who is responsible for what. There is, of course detail, such as how the issuer can be sure it only issues credentials into approved wallets, but that can be defined in lower-level scheme documents.
This scenario is that is does not truly reflect the flexibility of decentralised identity – with the user playing a role in determining what can be shared from any number of issuers to the verifier. If anything, it looks more like a federated identity solution just using different technical rails to deliver the identity information from the Identity Service Provider to the Relying Party (the Verifier in the above diagram).
Scenario 2: Multiple Issuers
Having multiple parties involved in delivering parts of the GPG45 requirements would be a more complex scenario but more in line with how decentralised identity is intended to work.
Issuers will provide credentials to the user relevant to the relationship between the issuer and the user. Provided the user can obtain enough different credentials to meet the GPG45 requirements, they will then be able to present some combination of those credentials to the verifier. It would then be down to the verifier to determine whether the set requirements of GPG45 had been met.
This has a couple of implications:
- The wallet would need to be “smart”, receiving a request from the verifier for particular credentials and assisting the user in choosing the right set of credentials to satisfy that request.
- The verifier themselves would take on part of the “Identity Service Provider” role. They would need to request credentials to meet GPG45 requirements and then check that the credentials presented met those requirements or supplement them with additional back-office checks.
The “Identity Service Provider” role, as defined in the framework, would therefore be spread across a number of organisations (issues, wallet provider and verifiers). Determining who is responsible for what could get very complex. If each party is certified under the framework for their bit, who will ensure that all the parts fit together and there are no gaps in any particular transaction?
The point about this scenario is it shows the potential flexibility envisaged in decentralised identity solutions and it is not clear that the framework (and the proposed certification arrangements) will support this level of flexibility.
Furthermore, when you add attribute provision into the mix, in a decentralised world scenario 2 is more likely than scenario 1. For example, an employer may wish for a potential employee to present a combination of identity, right to work, qualification and experience credentials which are unlikely to come from a single issuer.
Conclusion
The intention of the framework is very clearly to support different identity solutions, which is good. However, by defining roles that are aligned with more traditional federated identity solutions there is a danger decentralised identity approaches may not fit. Ensuring that they do is very important. The EU in the proposed update to the eIDAS regulation has made it very clear that it is moving towards a more decentralised model for digital identity. Numerous other players are heading in this direction too.
