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" :/.
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?
For pure browser stuff maybe. The W3C still puts out some very very useful resources and standards not directly browser related that are important (such as AP and Micropub)
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.
I don't think this is very well-known, at least among people who haven't worked on telephony implementations (? I have no idea where this is commonly used). Never in my life has someone asked me for my DID instead of my phone number.
It's fairly plausible that the people working on this specification were unaware of this pre-existing acronym (which ranked after Defense In Depth, when I searched it), and just said "Oh, we're making Distributed IDentifiers. Let's call them DIDs! That's easy to remember."
When used in verbal conversation, is it generally spelled out like CPU (dee eye dee), or said as a word like RAM (did)?
at the two telecom jobs in my past DID only got called a "DID" when specifically talking about configuring routes for DID or some other associated configuration. Even as telecom engineers unless that was the specific context the nomenclature was to call it a phone number all other times. Across separate companies.
And yet ...
...you've got me wanting to pay attention to something; I'm migrating from a public telco/PTSN job to The world of hosted pbx and managed voice in two weeks and I wonder if that linguistic quirk translates between the two types of environment.
> 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.
"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..
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).
Sadly not that much from the top of my head. I mostly became familiar with it through IPFS[0][1], but the Wikipedia article lists other projects that might have interesting resources[2].
Disclaimer: I'm working on a project[3] to create a content-addressable version of OWL2 (Web Ontology Language), so I'm certainly a bit biased.
Unfortunately, much of the information we interact with every day is ever-changing and published by someone specific, which is not a feature provided by content-addressable storage.
Depends on what content-addressable storage you mean specifically. IPFS (disclaimer: I work on IPFS) handles this by using IPNS together with your PeerID. As long as you have the ID of who the "someone specific" is, you can listen for their published changes. The changesets themselves are immutable, but IPNS provides a mutable naming layer on top of that.
That, then, is not content-addressable storage, and is instead an entirely different part of the system bundled in under the same name. I'm not sure what benefit such a thing actually provides, anyway.
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).
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.
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.
Contend addressed documents wouldn't fit directly into what DID is trying to accomplish. A DID is supposed to be a unique id to identify an identity, such as a Person, a company or even your pets. A DID maps to a DID Document that may change overtime, e.g.: the public keys listed in it. If we were using content-addressing for the identifiers, they would be changing over time, which will be hard to use in a variety of systems.
This doesn't mean that we cannot use content-addressing. For instance, in IPFS world, the DID could actually be using IPNS to point to a CID. This allows to have a persistent DID pointing to CIDs at different times. There's actually a DID method called IPID (based on IPFS), that uses a strategy similar to this.
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!
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.
> Because DIDs reside on a distributed ledger, each entity may serve as its own root authority—an architecture referred to as DPKI [0] (decentralized PKI).
There is a whole bunch of related docs in the WebOfTrust github repo's, many of which are related to blockchain (which does not have my interest, ATM).
The spec continues:
> Note that DID methods may also be developed for identifiers registered in federated or centralized identity management systems. For their part, all types of identifier systems may add support for DIDs. This creates an interoperability bridge between the worlds of centralized, federated, and decentralized identifiers.
Then later on there is a chapter on DID Resolvers [1] but this does not have much detail. So, I guess, the actual resolving mechanisms are out of scope of the spec.
The DID system doesn't use any central registrars. Connecting a key with an entity consists of the entity represented by the DID publishing the key in their DID document. That document is then published on some ledger (can be blockchain but could also be, e.g., IPFS) so that others can discover it.
There is bunch of discussions happening currently about how to get Identity right and how applications using IPFS can use DID for their identity management.
"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:
"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."
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?
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.
I mentioned Keybase's use of DID's in another comment in this thread. They've done a great job of demonstrating how a fairly non-technical user can generate their own PGP keys and cross reference these keys to various social identities and attestations. The records for each user's attestations and identity claims are written to the bitcoin blockchain, which gives users the ability to continue use of these identity claims, even if Keybase were to cease existing. Blockstack's identity model has some similar features, and in general, I've found the successful use of DID's to be blockchain agnostic, which is (IMHO) the way it should be.
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.
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.
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... (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.
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.
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?
44 comments
[ 5.2 ms ] story [ 108 ms ] threadPersonally, 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.
It's fairly plausible that the people working on this specification were unaware of this pre-existing acronym (which ranked after Defense In Depth, when I searched it), and just said "Oh, we're making Distributed IDentifiers. Let's call them DIDs! That's easy to remember."
When used in verbal conversation, is it generally spelled out like CPU (dee eye dee), or said as a word like RAM (did)?
And yet ...
...you've got me wanting to pay attention to something; I'm migrating from a public telco/PTSN job to The world of hosted pbx and managed voice in two weeks and I wonder if that linguistic quirk translates between the two types of environment.
So let's stick with UUID for now…
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
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).
Disclaimer: I'm working on a project[3] to create a content-addressable version of OWL2 (Web Ontology Language), so I'm certainly a bit biased.
[0]: https://arxiv.org/abs/1407.3561
[1]: https://medium.com/@ConsenSys/an-introduction-to-ipfs-9bba48...
[2]: https://en.wikipedia.org/wiki/Content-addressable_storage#Op...
[3]: https://github.com/rlay-project/rlay-ontology
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).
> 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.
[0] - https://github.com/jonnycrunch/ipid
This doesn't mean that we cannot use content-addressing. For instance, in IPFS world, the DID could actually be using IPNS to point to a CID. This allows to have a persistent DID pointing to CIDs at different times. There's actually a DID method called IPID (based on IPFS), that uses a strategy similar to this.
> 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...
[1] http://www.weboftrust.info/
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.
> Because DIDs reside on a distributed ledger, each entity may serve as its own root authority—an architecture referred to as DPKI [0] (decentralized PKI).
There is a whole bunch of related docs in the WebOfTrust github repo's, many of which are related to blockchain (which does not have my interest, ATM).
The spec continues:
> Note that DID methods may also be developed for identifiers registered in federated or centralized identity management systems. For their part, all types of identifier systems may add support for DIDs. This creates an interoperability bridge between the worlds of centralized, federated, and decentralized identifiers.
Then later on there is a chapter on DID Resolvers [1] but this does not have much detail. So, I guess, the actual resolving mechanisms are out of scope of the spec.
[0] https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust...
[1] https://w3c-ccg.github.io/did-spec/#did-resolvers
Some links:
- https://github.com/ipfs/dynamic-data-and-capabilities/issues...
- https://github.com/ipfs-shipyard/peer-star/issues/6
- https://github.com/ipfs-shipyard/peer-star/issues/7
Also, browse around in the repositories and their open issues.
If anyone is really into decentralized identities and authentication, please give it a read. Feedback would be appreciated!
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/
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."
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?
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.
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.
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?