Decentralized ID Part 3: Credential and DID Methods
In part one of this blog series, we outlined some of the trust challenges facing the implementation of decentralized identity. In part two, we covered some of the questions about digital wallets. In this installment, we will discuss two more vectors of complexity: the diversity credentials and blockchain identity resolution.
What is a credential? Unfortunately, “credential” is over-used identity jargon that may mean different things to different people. In the authentication space, a credential is something that proves who you are, like a username-password combination, or a USB security token. But in the decentralized identity space, a “credential” refers to the information about a person–what in OpenID Connect we’d call a collection of claims (or in SAML we’d call the attributes). Sounds easy enough… but wait. How exactly do we bundle and send these claims?
It turns out there is no agreement on this. One of the oldest ways to accomplish this task was to generate an X.509 certificate. But PKI is far from ideal; it does not support an important feature–selective disclosure–what if I only want to convey some of the claims? We don’t want to overshare information to the relying party. The ISO mobile driver license specifications define another format for credentials, as does the W3C verifiable credentials spec. In fact, there are many credential formats, and little agreement on which will be the primary format for decentralized identity–if a primary format even emerges. The table below provides some of the possibilities:
While writing decentralized identities to a blockchain is not a requirement, there are some synergies. Most identity experts agree that for privacy reasons, you cannot store personal information on the blockchain. But there are other use cases. First, a blockchain could provide a convenient alternative to verify the integrity of a decentralized credential–for example, the issuer could write a hash to a blockchain with enough metadata to enable a relying party to verify that the decentralized credential has not changed. A blockchain could also provide immutable metadata about the issuance of a credential. A blockchain could publish information enabling issuers, holders and verifiers to communicate. These are just a few examples–there are probably more.
In fact, many platforms exist specifically to issue self-sovereign identities on a specific blockchain. Kilt comes to mind, which provides an identity layer for the Polkadot blockchain. Polygon-ID has made some pretty bold claims about their blockchain identity platform (see their press release). Holo enables you to link your Web2 identity to your wallet address. And these are just a few examples of how decentralized identities are connecting to blockchains.
If you want to reference data on a blockchain, the W3C community provides a convenient way to do that using a decentralized ID or “DID” URL, with this format:
Drummond Reed from Avast asserts that DIDs are a “waistline” protocol, like the Internet Protocol (“IP”) in the network space–many protocols and technology stacks will be built on top of DIDs. I think that’s true–the DID URL connects us to a new Internet distributed infrastructure for data storage.
But how do you make sense of, or “resolve,” a DID? This is especially vexing question when each platform is different. For example, resolving a Polygon-ID DID is different then resolving a Kilt DID. But after resolution, you get a DID document, which provides metadata about the DID, like how to retrieve data or verify integrity. How many DID methods are there? A lot–134 at last count accord to the DID Specification Registries document. How are browser vendors going to implement 134 DID methods? They are not. This is the main reason the DID specifications are not yet final.
So while the format of DID URL’s is relatively uncontentious, it’s hard to say when the W3C will finalize this standard. Although a major roadblock has been removed when the W3C overruled the objections of Google and Mozilla. And where is an ecosystem when its “waistline” protocol is not finalized?
So to conclude this series, despite excitement about decentralized identity, and even as OpenID Connect community is on a fast track to finish standards for presentation and authentication, there are still many unanswered questions about decentralized identity. How long do these questions take to get worked out? Is EIDAS 2 the killer application that drives us to standardization? Maybe. But net-net, it’s unclear to me when and if a consolidation will occur.
I think Kristina Yasuda has some pragmatic advice for adoption: use what you can. If you have an application that would benefit from decentralized identity–think of the 10 US states, Apple Wallet and the TSA–then be a trailblazer. Ultimately, adoption makes standards relevant–so don’t wait. Decentralized identity is not perfect. And hopefully these three blogs perpare you for that dive!