Decentralized Identities Demystified
In a world that revolves about online transactions we use our digital identity at work, at home, and across every app, service, and device. Users must register for an account with a different username & password for every service provider with whom they wish to engage, and in such systems the user’s identity is managed by each service provider so that our identity and digital interactions are owned and controlled by other parties, some of whom we aren’t even aware of. Access to our IDs can be removed at any time by external parties and security of the information we send to perform minimal transactions may be easily comprised. We grant consent and access rights to many apps and devices, which requires a high degree of vigilance to track who has access to what information. For enterprise, collaboration requires complex orchestration to securely exchange data. Centralized and federated systems are the main identity models and neither has provided an identity service that is both private and easy to use.
Users want transactions to be more secure while incurring less overhead. Towards this end a new ecosystem is evolving based on decentralized identities. The Decentralized Identity Model describes how to handle scenarios when working over the internet in a secure manner that respects users’ privacy. It is based on distributed ledger technology (e.g., blockchain) and provides users with the ability to prove their identity without giving it away.
DID Building Blocks
The DID ecosystem employs the following building blocks:
- decentralized identities (DID)
DIDs are a new type of identifier that enables verifiable, decentralized digital identity. A DID represents a piece of information you wish to prove, and can identify any subject — a person, organization, thing, data model, abstract entity, etc. — that the controller of the DID decides that it identifies. DIDs restore control of identity to consumers using an identity wallet containing verified information about themselves from certified issuers, by enabling the controller to prove control over it. They are implemented independently of any centralized registry, identity provider, or certificate authority.
- decentralized identities documents
DIDs are presented in the form of a document which contains information associated with the DID. DID documents specify verification methods and services relevant to interactions with the DID subject. The W3C DID Working Group is developing a standard for the core architecture, data model and representation of DIDs. A DID document can express cryptographic material, verification methods, or service endpoints, which provide a set of mechanisms enabling a DID controller to prove control of the DID. A DID document may also contain semantics about the subject that it identifies.
The standard elements of DID document include the DID itself for self-description, a set of public keys for verification, a set of authentication methods, a set of service endpoints for interaction, a timestamp for audit history and a signature for integrity.
- verifiable credentials (VC)
A verifiable credential is certified proof of your identity which is stored by the user in their own wallet. More formally, verifiable credentials are data objects consisting of claims made by an accredited issuer attesting to the validity of information about the user (holder of the VC).
Verifiable credentials represent information found in physical credentials — passport or license — as well as new things that have no physical equivalent — ownership of a bank account. They are digitally signed and therefore tamper-resistant and instantaneously verifiable. VCs can be issued by anyone, about anything, and can be presented to and verified by everyone and are comprised of metadata, claims, and proofs of those claims. An open standard for digital credentials is being defined by the W3C working group.
- verifiable claims
A verifiable claim is a claim of possession of a VC. A verifiable claim may be a qualification, an achievement, a quality, or a piece of information about an entity’s background. Examples include a person’s name, government ID, payment provider, home address, university degree, etc.
- verifiable presentations
Verifiable presentations are signed proof of your claim that can be presented to a verifying party. They contain identity data, taken from Verifiable IDs and/or attestations, that the holder creates and chooses to share with a verifier, and proofs that can be signed with cryptographic keys. Verifiable presentations are generated or derived from verifiable credentials and can be cryptographically verified by the verifier.
- distributed verifiable data registry
The verifiable data registry, or ledger, stores proofs of claims, not the claims themselves; issuers of credentials write to the registry and verifiers read from the registry. A distributed verifiable data registry is any system that supports recording DIDs and returning data necessary to produce a DID in a non-centralized manner. Examples include distributed ledgers, decentralized file systems, blockchains, databases of any kind, peer-to-peer networks, and other forms of non-centralized trusted data storage.
The distributed ledger/data registry acts as the source of truth in place of a central authority. The identity information is not held on the ledger but within a wallet managed by the user. Ledgers store keys (or other) to prove the validity of the claims and presentations presented by the holder to the verifier.
DID Personas
The personas in the DID ecosystem are termed issuers, holders, and verifiers. Certified credential issuers of credentials attest that the user’s proof is accurate and create verifiable credentials signed with the issuer’s DID as well as the users’ DIDs. The holder can then present the verifiable credentials as proof of their identity to any verifier that requests it. Verifiers can verify that the proofs are true via a distributed ledger.
Putting it all together: DID ecosystem data flow
Users create a decentralized identity (DID) for each piece of information to be shared.
An issuer validates the DID and records the proof in a public distributed ledger and returns a verifiable credential (VC) with the issuers signature. The user/holder of the VC then stores it in a digital wallet.
In order for the holder of a VC to make a verifiable claim using the VC to prove an identity, the holder signs the VC, and creates a verifiable presentation of the claimed identity. The holder then submits it to the verifier who validates the presentation using the proof from the distributed ledger.
A full view of the DID ecosystem and data flow is depicted below in Figure 3:
To best illustrate the ecosystem data flow let us look at an example.
Say, Woodgrove Inc. is a company, Proseware is another company that offers Woodgrove employees discounts, and Alice is an employee at Woodgrove, Inc. who wants to get a discount from Proseware.
Woodgrove is deploying a verifiable credential (VC) solution to provide a more manageable way for Alice to prove she is an employee of Woodgrove. To enable Alice to use her VC the following setup takes place:
- The issuer of the credential, Woodgrove Inc., creates a public key and a private key.
- The public key is stored on a decentralized ledger.
- When the key is added to the infrastructure, the entry is recorded in the ledger.
- The issuer provides Alice the private key which she stores in her wallet application.
When Alice is ready to make a purchase from Proseware and obtain her discount, the transaction flow is as described in Figure 4. Specifically,
- First, Alice requests a Woodgrove Inc. company discount from Proseware.
- Next, Alice grants access to her credential to Proseware, the verifier, via her Authenticator wallet app.
- In her wallet Alice has a verifiable credential signed with Woodgrove’s (the issuer) private key, as described above.
- Alice then adds her signature with her private key and generates a verifiable presentation which she sends to Proseware.
- Finally, Proseware, the verifier, validates Alice’s employee credentials by matching with the public keys from the public decentralized ledger.
Each time Alice successfully uses the private key the transaction is logged in the wallet application.
DID syntactic components
The W3C working group is defining a standard syntax for decentralized identifiers, documents, presentations, and verifiable credentials using the components defined below.
A DID URI is composed of three parts: the scheme DID, a method identifier, and a unique method-specific identifier specified by the DID method. A DID URL is a basic DID that incorporates other standard URI components such as path, query, and fragment, used to locate a particular resource. DIDs are resolvable to DID documents.
A DID subject is the entity identified by the DID; anything can be the subject of a DID: person, group, organization, thing, or concept or even the DID controller.
A DID controller is the entity — person, organization, or autonomous software — that has the capability to make changes to a DID document. This capability is typically asserted by the control of a set of cryptographic keys used by software acting on behalf of the controller. A DID might have more than one controller and a DID subject can be one of the DID controllers.
A DID method is the mechanism by which a particular type of DID and its associated DID document is created, resolved, updated, and deactivated. It is defined using separate DID method specifications.
A DID resolver is a system component that takes a DID as input and produces a conforming DID document as output. This process is called DID resolution. The steps for resolving a specific type of DID are defined by the relevant DID method specification.
A DID URL de-referencer is a system component that takes a DID URL as input and produces a resource as output.
DID syntax
A simple example of a verifiable credential:
Ecosystem Players
The Decentralized identity foundation (DIF) is an engineering-driven organization focused on developing the foundational elements necessary to establish an open ecosystem for decentralized identity and ensure interoperation between all participants. Their vision is to enable a world where decentralized identity solutions allow entities to gain control over their identities and allow trusted interactions, and currently entertain an extensive membership.
The OpenID Foundation is a nonprofit international standards development organization that is promoting the OpenID community and technologies.
The World Wide Web Consortium (WC3) working group is leading the way in defining the syntax and standards for DID components.
Microsoft has pioneered the way with its own complete ecosystem based on Microsoft Azure AD Verifiable Credentials. Their ecosystem components include (1) W3C Decentralized Identifiers (DIDs) as the document and data, (2) an Azure Identity Overlay Network (ION) Node — did:ion — as their decentralized data registry, (3) the Microsoft Authenticator App as the user’s digital wallet, (4) the Microsoft Resolver as the API that connects to their ION node to look up and resolve DIDs using the did:ion method and return the DID Document Object (DDO), and (5) the Microsoft Azure Active Directory Verified Credentials Service which is an issuance and verification service in Azure that uses a REST API for W3C Verifiable Credentials that are signed with the did:ion method. It enables identity owners to generate, present, and verify claims, and forms the basis of trust between users of the systems.
Microsoft Partner service providers include Acuant, AU10TIX identity intelligence, CLEAR, IDEMIA, Jumio, LexisNexis Risk Solutions, Onfido, Socure, and Vu.
Pilots are underway in Government of Flanders in Belgium, at the National Health System in the United Kingdom, and at Keio University Tokyo Japan.
Where is this all headed?
I applaud Microsoft for leading the way into data privacy ecosystems, enabling users to parallel using their physical identification with a secure privacy preserving digital solution. Part of Microsoft’s business model is likely based on having users of their DID ecosystem register with Microsoft Azure Active Directory thus increasing their client base. However, as consumers become acquainted with and use their ecosystem, and as other ecosystems hopefully arise, users will prefer and eventually demand DID based ecosystems for their transactions, rather than having to submit personal ID numbers, birth date, and more to order lunch. It is still early in the game and the arena is open for big players to join and secure a good portion of the market.
This article has also been published in the Cisco Tech Blog.
