A Primer for Decentralized Identifiers | Hacker News Reader

A Primer for Decentralized Identifiers

w3c-ccg.github.io

80 pointsvlfig15 comments

https://human-id.org/ (a non-profit startup)

it's a little disheartening that all of the sites you link to include conglomerated tracking mechanisms, e.g., proprietary tracking for wikipedia (even if this is relatively benign), google for the latter two, plus wordpress for human-id.org.

Aside from a spec that tells the "how", I don't understand what or why it is. What problem does this solve? How can or should I use this?

It's mentioned in the "How DIDs Differ from Other Globally Unique Identifiers" section.

> The need for globally unique identifiers that do not require a centralized registration authority is not new. UUIDs (Universally Unique Identifiers, also called GUIDs, Globally Unique Identifiers) were developed for this purpose in the 1980s and standardized first by the Open Software Foundation and then by IETF RFC 4122.

> As a rule, however, UUIDs are not globally resolvable and URNs – if resolvable – require a centralized registration authority. In addition, neither UUIDs or URNs inherently address a third characteristic – the ability to cryptographically verify ownership of the identifier.

TLDR: We've used UUIDs for a while now, they're cool and all but don't work in a distributed network as they assume location-addressing to one central, verifying server. Instead, DIDs work via content-addressing, making them more ideal in distributed networks as they're easier to verify.

A lot of time you don't need to identify people, you just need unique accounts. There is no fundamental need to have one identity linked on HN, reddit, Facebook.

Agree! None of these specifications are required to be implemented. They are there to cover the use cases outlined in the specifications themselves, so feel free to pick and chose which ones to follow. Obviously it's better for the open web if you use them when you're implementing something for your use case, rather than coming up with a new specification that is similar but incompatible.

But as you say, if you're implementing something that doesn't require global identifiers in a decentralized/distributed context, don't use DIDs :)

I agree. Did I overlook a 'use cases' section? Any suggestions on short write ups?

Imagine you run a community college and want to identify students, but wish to do so in a privacy-preserving manner. Keep in mind you need to identify them from the high schools or other colleges they are transferring from as well as you'll need to identify them to the colleges they transfer to after.

DIDs allow for creating network wide identifiers that can be digitally verified. They work great in conjunction with verifiable credentials. So now you can keep and share records on students using their DID. You can create a unique DID for each student, even a unique id for each record which maps back to the student's DID.

It may not seem like much, but it forms the basis for creating systems where identity can be kept private, even from the individuals administering the system.

First impression from someone who implements lots of Web specs: it reeks of bull crap. I don't see the point in standardising a new URI schema. The example shown at <https://w3c.github.io/did-core/#parts-of-a-did> comes with much expense: verbosity, dereferencing (i.e. network round-trip) to get a document with additional required information and drags in the json-ld spec for no good reason.

If I were in charge of minting identifiers, I would always just use the http URI schema; the controller/verification stuff could be simply appended right there. With just a modicum of care and planning, the URIs will last as long as the Web itself. http://enwp.org/PURL http://w3id.org

For privacy preserving IDs I suggest you look at Coconut Credentials — https://medium.com/chainspace/coconut-threshold-issuance-sel...

How is DIDs not privacy preserving? You chose what information you put in it. Also, Coconut Credentials seems to be for "distributed ledgers" while DIDs are agnostic in their usage.

I don't know much about DIDs this was my first encounter.

I was just sharing.

Sorry, I wasn't meant to be abrasive or anything, it's a genuine question. When you say "For privacy preserving IDs..." it sounds like DIDs are not privacy preserving, while the people who worked on DIDs did in fact think about privacy when designing it. But maybe I'm understanding your previous comment wrong, sorry if that's the case.

I find the choice to use ownership language strange. The url/uri based systems are fundamentally inadequate for many if not most of their current use cases (they are not and never were intended to be persistent), and as the authors point out, there the urn system requires a central authority. Thus there is a need for some other system.

The ability to claim and prove authorship and determine the provenance (or tampering) of an identified document is crucial. For the most part people bindly trust that the nytimes.com that they are seeing is the real one, but there are so many ways that the can be compromised it is hard to comprehend.

More importantly, the current ways of protecting oneself against such issues are no longer accessible to the common man except via an interaction with some giant corporate edifice that they also have to trust. If you want to publish a document and distribute it in a way that its integrity and authorship can be determined there aren't good options.

Even more more to the point, there is currently no way general way to give a link to such a document that can be dereferenced to an untrusted host in such a way that the integrity of the document can be verified.

I supposed we could all share magnet links and check that they were signed with the nytimes pgp key, but then we are back to the issue of how to determine and distribute the nytimes pgp key. The WOT doesn't work, and pgp fails for anonymous publishing. Maybe the infrastructure behind DIDs will be able to solve the problems with WOT.

It will be interesting to see what comes of this, but I'm wary of its adjacency to the blockchain buzzwords.

> If you want to publish a document and distribute it in a way that its integrity and authorship can be determined there aren't good options.

Perhaps the situation would be a little better if browsers supported Hashlinks[0]. The integrity hash in the URL would ensure that that the document returned is the one intended by the person who gave you the link.

I don't think it quite makes sense for a browser to store an address book of identities with associated public keys, but if an author hosts their document on a domain that is associated with them (and has a TLS certificate, recorded in a Certificate Transparency log) then the visitor can be reasonably sure of the document's authorship.

For good measure, the document should include in its body the domain name of the site where it is hosted, to avoid any weird problems with redirects.

[0] https://w3c-ccg.github.io/hashlink/

Reply on news.ycombinator.com