Rip and replace of existing technology with something new and different is not a path to success in an enterprise setting. How can the DID/VC ecosystem bootstrap from what exists already?
Innovative technology solution providers seeking Enterprise customers sometimes miss the mark when they propose a rip-n-replace approach. Their pitch tends to be some variation of “We have this technical solution Y that will so much better/faster/stronger than what you have currently (Disclaimer/Fine Print - You will have to entirely replace the X you have currently with our solution Y)”. That rapidly gets the bozo bit flipped on them.
Within the IT department of any medium to large size enterprise, there is an appreciation of the resources that are needed to manage a portfolio of capabilities, and any competent staff will seek to minimize the number of moving parts that make up that portfolio.
So, in order to be successful, any new technology will need to demonstrate a meaningful gain-to-pain ratio for bridging what they currently have to what is being proposed.
For those who are working in, championing and building the capabilities of the W3C Verifiable Credential (VC) and W3C Decentralized Identifier (DID) ecosystem there are two particular areas I would urge you to read up on and, if appropriate, contribute to and support:
- The OpenID Connect (OIDC) Self-Issued Identity Provider (SIOP) which bridges the gap between existing OIDC implementations and the DID/VC Ecosystem
did:webDecentralized Identifier Method Specification
The OpenID Connect (OIDC) Self-Issued Identity Provider (SIOP)
I am not going to spend any time here on the SIOP work for the simple reason that others have already done a great job of writing about it.
In particular I would urge you to check out “If you build an island, you’ll need a boat” by Emily Fry and Tobias Looker which provides a great perspective on why this is important, and “Where to begin with OIDC and SIOP” by Kaliya which gets into much more of the details.
did:web DID Method Specification
When you read the DID specification, it notes that the “DID Resolution function takes as its input a DID and a set of input metadata and returns a DID document” but that the specifics of how that is implemented, including what infrastructure component implements the resolution function or the nature of the target of the resolution i.e. where the DID document actually resides, is deemed to be out of scope.
So, to fill this gap, you have infrastructure components such as the Universal Resolver that does that resolution for you i.e. You feed the resolver a DID and it will automagically resolve it globally to a target where the DID document resides. All too often that target happens to be a distributed ledger.
But what if an authoritative issuer or a sovereign entity did not want to have a dependency on a ledger for the DID that uniquely identifies them as the issuer? What if they wanted to bootstrap existing infrastructure that they already own/operate/trust such as their web and DNS infrastructure?
This is where the
did.web specification comes in – “DIDs that target a distributed ledger face significant practical challenges in bootstrapping enough meaningful trusted data around identities to incentivize mass adoption. We propose using a new DID method in conjunction with blockchain-based DIDs that allows them to bootstrap trust using a web domain’s existing reputation.”
did:web:www.some_authoriative_issuer.com => which resolves to => https://www.some_authoriative_issuer.com/did.json
did:web:www.some_authoriative_issuer.com:business_unit_1 => which resolves to => https://www.some_authoriative_issuer.com/business_unit_1/did.json did:web:www.some_authoriative_issuer.com:business_unit_2 => which resolves to => https://www.some_authoriative_issuer.com/business_unit_2/did.json
Work in progress
This specification is a work in progress but it looks to be particularly suited to entities who have made concrete investments in securing their DNS and web infrastructure and have direct control over them.
In no specific order, here are some of the ideas I am thinking thru currently:
- A trap that folks can fall into with this is to apply the existing mental model of an identity provider to the VC model.
- In the traditional identity provider model the IdP has an identifier AND they also control the identifier they issue to a subject.
- In the VC model, the issuer has an identifier (a DID) but the identifier of the subject/holder (a DID) may not be issued by the issuer but be something that is fully owned and controlled by the subject.
- What I am excited by is the option of using
did:webto identify the issuer in a VC, especially when that issuer is an authoritative entity that must stand behind the VC attestations it makes e.g. A sovereign issuing a passport or a DMV issuing a Driver’s License.
- I am still in the process of thinking thru the scenario and the implications (both positive and negative) where the authoritative issuer of a VC may also want to issue and control the identifier (DID) of the Subject of the VC.
did:web provides a bridge between what is already understood and trusted within an Enterprise and the new DID/VC ecosystem. As such, organizations that are building infrastructure and thinking about DID resolution should be looking at and refining this spec and consider if it makes sense for them to support within their environment.
cyberforge: random and relevant
- Traceability Vocabulary - describes a Linked Data vocabulary for asserting Verifiable Credentials related to traceability information, such as chemical properties, mechanical properties, country of origin, and other attributes used to determine the status of a products and materials in a supply chain.