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.

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 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 more secure transactions with less overhead for them. 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.

Figure 1: The data model for verifiable credentials is a World Wide Web Consortium (W3C) Recommendation, ‘Verifiable Credentials Data Model 1.0 – Expressing verifiable information on the Web’, published 19 November 2019.

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 contain information associated with a DID. DID documents express 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.

Figure 2: Sample verifiable presentation

• 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 to 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 their DID and 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:

Figure 3: The DID Ecosystem

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.
• 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:

1. The issuer of the credential, Woodgrove Inc., creates a public key and a private key.
2. The public key is stored on a decentralized ledger.
3. When the key is added to the infrastructure, the entry is recorded in the ledger.
4. The issuer provides Alice the private key which she stores in her wallet application.

Figure 4: VC Data Flow Diagram

When Alice is ready to make a purchase from Woodgrove and obtain her discount, the transaction flow is as described in Figure 4. Specifically,

1. Alice requests a Woodgrove Inc. company discount from Proseware.
2. Alice grants access to her credential to Proseware, the verifier, via her Authenticator wallet app.
3. In her wallet Alice has a verifiable credential signed with Woodgrove’s (the issuer) private key, as described above.
4. Alice adds her signature with her private key and generates a verifiable presentation which she sends to Proseware.
5. Proseware, the verifier, validates Alice’s employee credentials by matching with the public keys from the public decentralized ledger.
6. 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.

Figure 5: DID URI Syntax

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

Examples:

• unique verification method: did:example:123#public-key-0
• unique service: did:example:123#agent
• External resource: did:example:123?service=agent&relativeRef=/credentials#degree
• query: did:example:123456?versionId=1
• With parameters: did:example:123?service=files&relativeRef=/resume.pdf

A simple example of a verifiable credential:

{
// set the context, which establishes the special terms we will be using
// such as 'issuer' and 'alumniOf’.
"@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ],
// specify the identifier for the credential
"id": "http://example.edu/credentials/1872",
// the credential types, which declare what data to expect in the credential
"type": ["VerifiableCredential", "AlumniCredential"],
// the entity that issued the credential
"issuer": "https://example.edu/issuers/565049",
// when the credential was issued
"issuanceDate": "2010-01-01T19:23:24Z",
// claims about the subjects of the credential ”
credentialSubject": {
// identifier for the only subject of the credential
	"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
	// assertion about the only subject of the credential
	alumniOf": {
	  "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
	   name": [
{ "value": "Example University", "lang": "en" },
		{ "value": "Exemple d'Université", "lang": "fr" }
   ]
}
                   },
"// digital proof that makes the credential tamper-evident
// see the NOTE at end of this section for more detail
"proof": {
	// the cryptographic signature suite that was used to generate the signature
	"type": "RsaSignature2018",
	 // the date the signature was created
	"created": "2017-06-18T21:19:10Z",
	// purpose of this proof
	"proofPurpose": "assertionMethod",
	// the identifier of the public key that can verify the signature
	"verificationMethod": "https://example.edu/issuers/565049/keys/1",
	// the digital signature value
	"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj PAYuNzVBAh4vGHSrQyHUdBBPM"
}
}

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 interop 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.

Figure 6: Microsoft DID Ecosystem

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 an 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 privacyecosystems, enabling users to parallel using physicalidentification with a secure privacy preserving digital solution.Part of Microsoft’s business model is likely based on having usersof their DID ecosystem register with Microsoft Azure ActiveDirectory thus increasing their client base. However, as consumersbecome acquainted with and use their ecosystem, and as otherecosystems hopefully arise, users will prefer and eventually demandDID based ecosystems for their transactions, rather than having tosubmit personal ID numbers, birth date, and more to order lunch. Itis still early in the game and the arena is open for big players tojoin and secure a good portion of the market.