Demystifying decentralized identity

In my last blog post I shared Accenture’s Tech Vision 2023 “When Atoms meet Bits” which paints a future that seamlessly converges our physical and digital lives, powered by AI models that will fundamentally change our world. It calls out digital identity as the first of the four foundational trends driving this new reality and shared some exciting news about the levels of interest. However, all was not rosy, and it did share some unwelcome news about the perception of decentralized identity as being too complex, where 79% of executives report their organizations’ preferred strategy leans toward centralized solutions.

In this post I wanted to attempt to demystify decentralized identity and share some of the benefits that can be realized. And this is an elevator pitch for those that are newbies to this area, so is a simplified explanation and doesn't try to capture every step in the process.

So, where to start? Let's start with a simplified picture that compares the centralized and decentralized models. Then let's try to kill a couple of myths.

Centralized

Typically, in the current centralized approach:

• Data Corp holds Jane’s data and issues Jane an identity (e.g., employee ID).
• Jane shares her identity data with Service Inc (e.g., to get a credit card).
• Service Inc requests that Data Corp verify Jane’s data (e.g., proof of employment).

This approach requires that:

• Service Inc onboard with Data Corp so they access the API to verify Jane’s data, (expensive for both Service Inc and Data Corp with business, technical, and regulatory overheads)
• Data Corp provide a service that allows Service Inc make verification requests, (increases Data Corp risk profile by opening its data to external API calls)
• Jane needs to typically share more data than required in order that Service Inc can verify with Data Corp. (increases Service Inc regulatory requirements since it’s processing, and often holding, more personal data)

There are also other privacy issues, such as the fact that Data Corp can now track all the entities with which Jane shared data, and technical issues, such as the fact that Jane’s data cannot be verified offline and always requires Internet access which can result in verification latency.

Decentralized

Typically, in the decentralized, or self-sovereign, approach:

• Data Corp holds Jane’s data and issues Jane a verifiable credential (e.g., employee info) to her digital wallet,
• Jane responds to Service Inc’s proof request with a proof response (e.g., to get a credit card).
• Service Inc retrieves Data Corp’s public key from its published location and verifies Jane’s proof response.

This approach requires that:

• Service Inc can retrieve Data Corp’s public key, trusts Data Corp, and trusts Jane’s digital wallet provider, (if you can’t trust the security of the wallet, then you can’t trust any credentials issued to it)
• Data Corp publish their public key,
• Jane has a secure and trusted digital wallet, anchored to her identity, with which she can respond to the Service Inc proof request.

Myth Busters

• It doesn’t mean that we don’t still have centralized, trusted, data issuers, such as Data Corp. It just means that the verification can happen without everyone having to go back to Data Corp. This also means that with PK caching, and a reasonable approach to revocation, you can verify credentials peer-to-peer, which minimizes network dependency and verification latency making for a more robust real-time solution.
• It does not require Blockchain and can work against any public key directory or indeed any mechanisms for publishing public keys.
• It does not require any additional storage of PII and in fact the whole philosophy is to minimize the data that needs to be stored by a 3rd Party. The PII resides with the Issuer, in whatever MDM system they use today, the only difference is that they now release the data to the individual where they store in a personal, secure, encrypted, digital wallet.

Challenges

The Trust Network is the biggest challenge of the decentralized approach and the reason why many executives are slow to adopt, despite all the benefits they could realize. Trust is something that any relying party (verifier), such as Service Inc, could establish for themselves, creating their own trust list of issuers and tech providers. However, in practical terms this isn’t very scalable, and therefore trust networks (registries, ecosystems) are emerging that a relying party can trust. However, these trust networks tend to be geography, industry, or use case specific – such as EU Gateway for digital covid certificates, IATA for travel, GLEIF for legal entities, ... – and moving forward we can expect multiple networks to emerge, where relying parties will trust one or more networks.

In a subsequent blog post I’ll talk in more detail about trust networks, what’s emerging, and what we can do in the short-term while the market matures.