On the 11th February 2021, the Government published its “alpha” paper on “digital identity and attributes trust framework”. The paper itself, and a foreword by Matt Warman MP, Minister for Digital Infrastructure can be found here: The UK digital identity and attributes trust framework – GOV.UK (www.gov.uk)
For those of us involved with trying to shape the digital infrastructure landscape, security, privacy, and the role digital identity will play in both the internet of value, but also in the physical world, this paper is significant. However, the implication of this paper has more significance for organisations and us as individuals who may be required to have some form of digital identity in the coming years, for it is this paper that sets the tone of what digital identity really is.
The identity lexicon
Before we get into the document itself, the governments definition of a digital identity is at odds with most digital identity communities. Unfortunately, the definition is very much aligned with what many may see as an “identity card”. The definition is provided as:
“A digital identity is a digital representation of a person. It enables them to prove who they are during interactions and transactions. They can use it online or in person. Organisations that let users use secure digital identities during interactions and transactions can trust that those users are who they say they are.”
This may on the face of things feel like a sound definition, however, much of the physical documents that we use today to provide comfort of who we are, are not seen specifically as identity documents. For example, a bank statement or utilities bill, these are both documents that are commonly used to help prove identity. In reality, our identity, and ability to prove who we are, is based on a wide range of different documents (or credentials) that we hold, these credentials providing information about us to verify the claims we make about ourselves. Identity therefore is more of a domain, or collection of credentials, so one digital identity is not the definition. Identity is also not necessarily related to an individual, rather it could be related to an organisation or even an object.
Later in the paper there are definitions provided of what a “digital identity” may contain. Unfortunately, these definitions follow closely with the definition of a digital identity, so all digital identities are containing personal identifiable claims. This shouldn’t be the case. For example, my identity for my gym membership should not require much in the form of personal identifiable data, rather a simple membership number may suffice. The need therefore for my name, address etc is superfluous.
This leads on to the lexicon used within the paper. The W3C has papers on the definitions of verifiable credentials, credentials being a well understood term not just within identity, but within software engineering too. Credentials contain claims, claims that are being made by the holder of the credential. Again, common terminology not just within identity communities, but software engineering. It is strange therefore that the “Trust Framework” (TF) document introduces terminology such as attributes which ambiguously blends credentials and claims.
The document introduces other ambiguous terms, or areas of distinction which are not required. The document defines the role of organisations within the TF as either:
- Identity service provider
- Attribute service provider
- Orchestration provider
- Relying party
The distinction between an identity service provider and attribute service provider is hard to follow, since in reality both carry out the same role, especially in the world of SSI. An identity service provider will issue credentials, these credentials within them hold “claims” (attributes). An attribute provider is doing the same function, so it seems odd to have a distinction – unless of course the paper is trying to separate federated identity providers from the provision of identity.
As part of the government drive to ensure interoperability, its imperative that the descriptive nature of the service is in sync with the wider global community, so standardising the lexicon, the definition of an identity and definition of companies that act as issuers is key to the success of any government-based initiative.
How identity can be shared
The paper starts to form a vision of how identity data can be shared, and how it is shared in some cases. The paper states that:
“Each organisation or scheme will need to provide enough information for another to be able to:
- identify the person
- decide if the person or business is eligible for something”
This goes against many principles, perhaps even GDPR. You do not need to determine identity in order to determine if they are authorised to use a service or entitled to something. Under GDPR, an organisation must only ask for the data that it needs to carry out its business function. There are many use cases that do not require personal identifiable data to be shared, and therefore this should be true in a digital world. For example, if I am to present my “ticket” to enter a stadium I am not asked to also provide personal identifiable documentation. The same applies when boarding a train. In both cases my ticket acts as my identification in order to use those services.
The document also starts to define some of the rules and mechanics behind the sharing of personal identifiable data. Unfortunately, in the case of “orchestration providers and relaying parties”, no rules are set. The issue here is that without any rules, their role could see them breach many aspects of an identity owner’s privacy. Within the SSI community, orchestration providers cannot look inside the credentials that are being shared, this should not be possible. In addition, relying parties (or verifiers) should not be allowed to collaborate with others in order to form a profile of an identity. These are fundamental rules that must be put in place in order to safeguard personal identifiable data in the future.
Regarding the mechanics of sharing information, in expected fashion, the document references the National Institute of Standards and Technology (NIST) regarding security aspects. However, the application of this needs to be examined from a practical point, for example references to FIPS 140-3 hint at the need for Hardware Security Modules (HSM) regarding encryption functions. However, with encryption occurring on a user’s mobile device, this simply is not possible, nor ever desirable. NIST along with the National Cyber Secuerity Centre (NCSC) also references technologies such as TLS to protect data-in-flight, however, protocols such as DIDComm need to be incorporated into any such trust framework on identity and security.
Conclusion
The paper is a good starting point, however, that is exactly what it is, a starting point. It is clear that the lexicon needs a be brought in line with international lexicons used to define identity or identity / trust services. The paper needs to be less ambiguous and should focus on the trust element of the framework, not necessarily the mechanics of sharing identity-based data. In doing so, the paper will become much sharper, concise and lead to papers containing greater detail on the mechanics of sharing verifiable data later. Ideally the government will realise that SSI is a mature identity solution, that the trust framework will work hand in hand with any such framework a government may introduce. This is before pointing out that SSI already has in place the world’s largest dedicated identity infrastructure. If government can start to embrace all the hard work that has been done in this space for many years, then the UK could dramatically accelerate digital identity uptake and help drive the internet of value. Something that will help the economy at a time it is needed most.