Mozilla and Google Objections Overruled on “Decentralized Identifiers” by W3C

A DID URI is a URI with a 'method' and globally unique part: did:method:somegloballyuniqueid.

The "did" part is literal; a standardized URI namespace. The method part is some symbol that specifies how the unique id resolves and its representation (JSON, whatever.) The method part is what this story is about; W3C has declined to enshrine a set of methods in the standard.

Instead, W3C is delegating to a registry of methods. This registry has already grown to a sizeable number.

The idea is that you will apply a DID URI using its method and obtain a DID 'document'. This document has claims, credentials, etc. The DID owner can cryptographically prove the document represents them and relying parties can cryptographical verify claims in the document.

The actual workflow is more involved than described here but that's the gist of it.

BTW, your list of identity schemes you've had experience with roughly correspond to 'method's, although they aren't 'distributed' in the DID sense.

My understanding is DIDs are a unique identifier. There's a few methods that can be used regarding the construction of the identifier. It could be a unique key (did:key- https://w3c-ccg.github.io/did-method-key/). It could be using web infrastructure (did:web - https://w3c-ccg.github.io/did-method-web/). It could be using blockchain infrastructure (did:ion).

Whatever it is, it becomes an identifier used to receive credentials and send messages to. For example, your digital wallet can have a DID which can be used to store credentials. Your digital wallet can have many DIDs which can be useful to avoid correlation of identities.

The credentials (and the identities they represent) themselves are normally bundled into things like Verifiable Credentials (https://www.w3.org/TR/vc-data-model/) which have to be issued to something - like a DID.

They removed the core part of the DID standard where they made it expire after 6months.

I was told they requested the DID standard as it was needed for future projects.

I'm not sure this is the "flex" you wanted it to be. A cursory look at the specification gave me a pretty good idea what DID are supposed to be, and for (and I would only say I know enough identity-related stuff in order to implement things in my own services, but not over two decades). The use cases are relatively easy to understand, and there is bunch of implementations in the wild as well.

Maybe it would also help by looking at some of the proposed DID methods that are more similar to the approach you're used to. While not centralized, maybe DNS is something you're more familiar with, so you can link it together with existing knowledge?

In that case, the specification for the `did:dns` method, using DID together with DNS might be helpful for you: https://danubetech.github.io/did-method-dns/

What exactly is it you don't understand? Maybe your knowledge about centralized identity management is not helping you in this case, but making it harder to understand.

The forces in place here seems to be:

- distributed ledgers allow a different (decentralized) paradigm for identity management, where users own their identities and service providers authorize and authenticate them through verifiable credentials

- years of blockchains and even more years of web certificates have created processes to handle cryptographic material, that service providers supposedly find more secure than "username and password" to manage the identities issuing the verifiable credentials

- in realpolitik, Microsoft (Azure) is expanding in the cloud market by trying to establish a presence in niches (ie: Intel SGX, DIDs) [1]

I understand the overall skepticism about blockchain related technologies, but the intrinsic advantages that I see in them are:

- (for a service provider) having a tamper-proof log of all the auth changes for an identity

- (for a service provider/user) relying on cryptographic signatures allows for a private validation of an identity/claim

- (for a user) provided this is not EEE allover again, a greater degree of choices on how to manage your identity

I do not have as much experience as you do, so maybe there is some wheel-reinventing that I am not aware of :)

0. https://docs.microsoft.com/en-us/azure/active-directory/veri...

1. https://techcommunity.microsoft.com/t5/identity-standards-bl...

"1. there should be no central issuing agency;

2. the identifier should be inherently persistent, not requiring the continued operation of an underlying organization;

3. it should be possible to prove control of the identifier cryptographically;

4. it should be possible to discover metadata about the identifier."

Additional capabilities got tacked on during discussions, and I think are handled in different specs, such as DID-Messaging, but at it's core the above are the primary requirements.

[1] https://www.w3.org/TR/did-use-cases/

Seemed to me that DIDs are a more general version of blockchain addresses.

Like, you create a DID from a public key, and everyone who handles DID related stuff can ensure only who controls the related private key is the real owner.

Typically your company will validate those credentials to some level for employees. At a minimum, you establish what you need to know for payroll, in other cases you do extensive background investigations. For the public, however, we’re stuck with rudimentary solutions for ID verification (bank/credit accounts, mailing letters, etc) or unreliable and invasive solutions like ID.me.

The idea of things like DID and sovereign identity is that the human has agency and can provide or not provide credentials to establish who they are. That could include a verifiable, signed representation of your birth certificate, a professional license or some other credential. Think of it as a new iteration of 90s “web of trust” concepts.

My take is that it is a) X.509 re-born with different encoding (JSON-LD vs BER or PEM) and b) a scheme to promote use of certain blockchains for a purpose that blockchains don't suit well.

This building so much flexibility into protocols seems like a 90s holdover.

We are realizing that the more moving parts you have, the more edge cases you have, and the more attack surface area.

Then why would we expect Mozilla or Google or anyone else on that committee to ever determine one? Or to object to a free-for-all naming scheme if the problem is inherently ad-hoc?

Whether or not this standard succeeds, one can see the very real threat of standard capture here. Which has happened before, on numerous occasions, when a canonical implementation arrives that just so happens to prioritize their interests.

Probably a few big tech companies will form a consortium and use their weight for setting a de-facto standard.

It's not immediately clear what DIDs are, what problems they're solving (and what value they're providing to the ecosystem), why they're better than other options in the same space, and how they'll function and scale years into the future. That's a legitimate cause for skepticism.

That the objections brought on by the two largest browser vendors are dismissed entirely, without further addressing the concerns stated, is unsettling.

Some other interesting entries in this same vein, that are already in the DID registry, are Mastercard (https://idservice.com) and SecureKey (https://securekey.com).

Like, it's not a flat URI scheme leaving structure up to controllers. But it's also not a fully defined ontology.

Pick a use case description in section three. Any one. Each one could provoke an entire domain-specific organization into heated arguments about subrequirements and subsubrequirements.

Even if this recommendation doesn't make it, it's neat.

Any way you turn you walk into this system, right?

I think the W3C got lost in their XML dreams, and got huffed by WHATWG, whose standards I actively dislike.

It's blockchain bullshit that you can ignore.

You say this is not a problem, and immediately say this:

> it's hard to find a single project that uses DID protocols at scale in a worthwhile and effective manner.

Of course it's hard. For a protocol to operate at scale its implementations have to be compatible

This paragraph gave me temporary brain fog. I think it's saying that so long as the proposed syntax is flexible enough that one or more DID methods can satisfy... and then I'm lost again.

I would say that the process worked as intended. There was disagreement among members, things got discussed (see https://www.w3.org/2022/03/did-fo-report.html for details) and a decision was made according to the W3C process. All good!

It's futile because the future universe of DID methods can't be anticipated now, so whatever wrong set of DID methods W3 promulgated would include both poor choices and omit good choices. It's harmful because whatever future methods might emerge will relegated to a second class for having failed to 'get in' on the initial standard.

Better to avoid prematurely enshrining some arbitrary set of methods and allow a consensus to emerge via practice and exposure. At some point, as the inevitable shake-out of bad ideas and nefarious actors occurs, DID methods can be standardized in a useful way. Yes, the lack of a simple list of SHALLs will impede the immediate adoption of DID for all conceivable purposes, but better that struggle than the next to impossible task of loosening the grip of beneficial parties that have a standards document to wave around.

It's almost like they've learned something over the last quarter century.

That's how standard bodies are supposed to work: by finding consensus. If there are many objections, the spec should be adjusted until people agree.

However, if you have enough clout, you can try and still ram it through. See hardware APIs. 2 out of 3 major browsers have objected.

They represent your identity, have a relatively standardized format, but anyone can issue them, decide what to put on them and where the contact methods point, and you can have as many number and different versions as you wish.

It's like Mozilla are saying "We have centrally planned the number of carbon credits that may be spent by each technology, and determined that blockchains are a forbidden technology. We will therefore undermine any efforts of other people to implement standards where using blockchains is even a possibility."