
Decentralized Identifiers – DIDs - rapnie
https://w3c-ccg.github.io/did-spec/
======
saurik
This is really annoying as the technical term for the identifier of a phone
number--one of the most prototypical centralized identifiers--is also a "DID":
a Direct Inward Dialing (number, but we don't say "number"). So now "in the
future, people won't tell each other their DID to let people call them, they
will give them their DID" :/.

~~~
dkersten
Does anybody care what the W3C think anymore? I was under the impression that
the WHATWG was formed due to the browser developers’ frustrations with the W3C
and they now mostly ignore what W3C says or does. So, what are the chances of
this actually catching on?

~~~
parvenu74
W3C is the coordination point for WebAssembly:
[https://www.w3.org/wasm/](https://www.w3.org/wasm/)

Personally, I think WebAssembly is going to massively revolutionize app
delivery. In ten years we will have all but forgotten about JavaScript,
switching instead to client-side apps that run at near binary-native speeds,
written in real languages with complete type systems.

~~~
dkersten
Ah, thanks, I didn’t know that WebAssembly was a W3C drive. Good to know they
still have relevance.

------
rapnie
There is an interesting paper on using DID in combination with ActivityPub [0]
presented in the 'Rebooting the Web-of-Trust' [1] event in Fall 2017.

> ActivityPub implementations at the present moment rely on HTTPS as their
> transport, which in turn relies on two centralized systems: DNS and SSL
> certificate authorities. Is there any way to bring self-sovereignty to the
> federated social web?

> Thankfully there is; ActivityPub was written intentionally to be layerable
> on any protocol that can support HTTP GET and POST verbs. The Decentralized
> Identifiers specification looks to be a good fit for ActivityPub.

[..]

> Here we see an example of Alyssa's profile that is entirely free of
> traditional centralized DNS authorities. We were able to look up Alyssa's
> object via her DID, but we still have access to all her endpoints, which in
> this case are pointing to Tor Hidden Services. No central DNS required!

[0] [https://github.com/WebOfTrustInfo/rebooting-the-web-of-
trust...](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-
fall2017/blob/master/topics-and-advance-readings/activitypub-decentralized-
distributed.md#distributed-identity)

[1] [http://www.weboftrust.info/](http://www.weboftrust.info/)

------
Confiks
There was a talk about this on the Decentralized Web Summit. Unfortunately the
(livestreaming) version uploaded to Youtube is (still) borked, but they have
reuploaded the videos to the IA directly:
[https://archive.org/details/decentralizedwebsummitmedia-2018...](https://archive.org/details/decentralizedwebsummitmedia-2018-hashlounge/DWeb+Hash+Lounge+080118+06.mov)
(from 12m00s on).

Would anyone know how they plan to represent Idemix (or U-Prove) keys and
proofs, for example for Hyperledger Indy / Sovrin? There doesn't seem to be
anything in the w3id.org JSON-LD schemes, and while wading through the
mountains of code of Hyperledger Indy I haven't been able to find any
interface to DID documents.

~~~
rschulman
I don't know in particular how they intend to portray Idemix, but both
Hyperleger and Sovrin are heavily involved in the development of the spec, so
I'm pretty sure they're thinking of it.

Generally speaking, keys are embedded in a DID document in a standard text
format and proofs are published as a signature using one of the published
keys.

------
edhelas
> It is also similar to the relationship of the IETF generic URN specification
> ([URN]) and a specific URN namespace definition (such as the UUID URN
> namespace defined in [RFC4122]). The difference is that a DID method
> specification, in addition to defining a specific DID scheme, must also
> specify the methods for reading, writing, and revoking DID records on the
> network for which it is written.

So let's stick with UUID for now…

~~~
rapnie
"Horsepower - The term was adopted in the late 18th century by Scottish
engineer James Watt to compare the output of steam engines with the power of
draft horses."

So let's stick with horses for now :)

DIDs are different beasts than UUIDs, with different design goals [0]. Is why
they need this specification.

Whether the specification is any good, is a topic of discussion, of course..

[0] [https://w3c-ccg.github.io/did-spec/#design-
goals](https://w3c-ccg.github.io/did-spec/#design-goals)

------
hobofan
While I can see the need for DIDs somewhat, I feel like content-addressing
documents fits the decentralization paradigm much better when it comes to a
lot of types of data.

While it doesn't have all the properties of DIDs, it has the most important
ones, and comes with some other nice ones (automatic deduplication).

~~~
eudoxus
I may be wrong, but are you thinking of DIDs as an ID for an object, like CIDs
in IPFS. If so, then you are confusing what DIDs are for. They're created as a
method of using some distributed network as a backend for a entity (could be a
Human, could be another machine) to store their identifiers on. These entity's
can take actions, like signing a doc and uploading it to a blockchain. The DID
in this instance is the record of verifying who this entity is, and if they
should be trusted to do that action.

Content addressable IDs, or CIDs in IPFS are used to identity a document or
object.

So the distinction here is objects (some record of data) vs entities
(something that can take actions).

~~~
hobofan
For a lot of use-cases cases I don't see a need for a distinction between the
two (if you don't have a requirement for mutability, revokation, etc.).
Especially in recent developments in the decentralized space, it seems to me
that having most data (regardless of object or entity) be immutable and
content-addressable, makes reasoning about systems a lot easier, since you
don't have to worry about the data you are pointing to changing from under
you. Of course, different use-cases have different needs.

> The DID in this instance is the record of verifying who this entity is, and
> if they should be trusted to do that action.

I don't see why you wouldn't be able to use a CID for that. As long as the
content the CID points to contains the record of the entity, and a
cryptographic signature, you could do the exact same thing.

~~~
eudoxus
Except in the DID instance, you can represent a DID using a CID. This is how
IPFS creates their implementation called IPID[0]. DID is a schema/protocol for
DID and DDO, and its associated content. Its one step higher then a CID.

[0] -
[https://github.com/jonnycrunch/ipid](https://github.com/jonnycrunch/ipid)

------
runeks
So... how, exactly, do they propose tying together a human being with a public
key, thus creating a DID, without the use of a central registrar?

As far as I can see, in the end it just comes down to users trusting the same
set of registrars — which we already have in the form of Certificate
Authorities.

~~~
rsync
"So... how, exactly, do they propose tying together a human being with a
public key, thus creating a DID, without the use of a central registrar?"

The answer, as you might expect, is with a blockchain.

There was a booth last week at the decentralized web summit for the "BTCR DID
Method" which I believe is sponsored by W3C. You can read about it by going
here:

[https://decentralizedweb.net/science-
fair/](https://decentralizedweb.net/science-fair/)

Here you are:

"The Bitcoin Reference DID method supports DIDs on the public Bitcoin
blockchain The Bitcoin Reference DID method (did:btcr) supports DIDs on the
public Bitcoin blockchain. The Bitcoin Reference method has minimal design
goals: a DID trust anchor based on the Bitcoin blockchain, updates publicly
visible and auditable via Bitcoin transactions, and optionally, additional DID
Document information referenced in the transaction OP_RETURN data field. No
other Personal Identifiable Information (PII) would be placed on the immutable
blockchain.

A secondary intent of the BTCR method is to serve as a very conservative, very
secure example and some best practices for creating a DID method. The use
cases for BTCR are focused on anonymous and pseudo-anonymous identities, web-
of-trust style webs of identity, and absolute mimimal personal information
disclosure. Other DID methods will likely need to loosen these standards.

Some aspects of the BTCR method will not be practical if inappropriately
scaled — for instance, there is a transaction cost to update keys and DDO
object, potential UTXO inflation (i.e. one additional unspent output for every
BTCR-based identity), and even if segwit isn't used it could cause blockchain
bloat. However, identities using the BTCR method can be a strong as Bitcoin
itself -- currently securing billions of dollars of digital value."

~~~
runeks
I still don’t quite get it.

What would I put in the Bitcoin blockchain in order to create a DID? A public
key hash and what else? In other words, what do I want to tie together with a
public key, using the Bitcoin blockchain, in order to use it as an identifier?

~~~
satanik
It depends on the DID method. The DID is a string with the following pattern:
did:<method>:<method-specific-id>. There's a variety of DID methods with
different underlying public ledgers, such as Bitcoin and Ethereum. The
<method-specific-id> depends on the <method>. For instance, there's DID
methods that use the underlying wallet address as the id and others use the
smart contract deployed.

------
dc10
I get the motivation for this kind of identifier. I have a project in mind
that could make use of the DID format. So I was optimistic to see that thought
has been put into it.

But when I read "if _value_ is an object... if _value_ is a string..." (from
the specification of publicKey property), I worry. Did the authors choose JSON
to take advantage of loose typing as a "feature"? Is it OK for a specification
to require this kind of introspection and conditional logic?

------
yahyaheee
Went down this rabbit hole a couple months back, like blockchain I’m sure
there are a couple use cases, but most identify is inherently centralized as
it is formed through relationships.

~~~
jonnydubowsky
Good point about identity being relationship-based. I've found DID's to be
quite effective in providing cryptographically verifiable social proofs that
are powered by our relationships. Keybase has an excellent integration of
DID's and social proofs. I've verified my Hacker news identity and linked this
identity to my Keybase identity, along with my Twitter, FB and github
identity. If you know me on one of these platforms, you can cross-reference my
identity and see that I've attested to my identity across multiple platforms.
When you go to my Keybase profile, you can see I am currently in control of
these identities, and I can revoke the keys I've created as provable links
between my various profiles. This layering of social proofs is powerful in a
variety of ways.

