4 ms·

Great to see some progress with the standard. We’ve been working on generating DIDs for our upcoming users. We’re using IDX + Ceramic as our backend. For our u

Great to see some progress with the standard. We’ve been working on generating DIDs for our upcoming users. We’re using IDX + Ceramic as our backend. For our use case (making web3 profiles like https://shokunin.dns.xyz https://shokunin.dns.xyz), it’s cool to have a DID as a chain agnostic ID. I’m curious what people here have been using DIDs for besides that.

csense 5y ago
It sounds like you understand enough about DID's to start incorporating them into an actual product. You'll have a bunch of users, and you want to give each of your users a DID. Congratulations! I certainly wasn't able to get that level of understanding from the document. In Section 1.1, it says the DID "did:example:123456789abcdefghijk" resolves to a DID document. Would you then be running some software with all your users' DID's on some server identified by a subdomain, for example identity.dns.xyz? And then the DID for one of your users, let's call her Alice, would be "did:identity.dns.xyz:123456789abcdefghijk"? And then if I run a totally different company, and Alice wants to use my website, instead of registering a separate account with my website, she can instead type "did:identity.dns.xyz:123456789abcdefghijk" into my website? Does my site's software then contact identity.dns.xyz to ask it something? Or is all the information my site needs to do its thing contained in the DID itself? Is "123456789abcdefghijk" the hash of some document that's returned to my website by the identity.dns.xyz server? Or is Alice running some identity management browser extension that knows to present a document whose hash is "123456789abcdefghijk" to my website? Or instead of being the hash of a document, is "123456789abcdefghijk" the hash of a public key which signs something {returned by the identity.dns.xyz server | presented by Alice's software}? Or is "123456789abcdefghijk" just a string your webserver happened to generate to identify Alice uniquely that came from /dev/urandom or a PRIMARY KEY column in your database that has no cryptographic meaning? If Alice's DID document is cryptographically linked to her DID, how does she update it? If the DID is the hash of the document, does that mean Alice gets a new DID whenever she edits her profile on dns.xyz? What if Alice updates her dns.xyz profile because she accidentally pasted an Ethereum private key into a forum post, then generated a new address that wasn't compromised? How does my website know that the user presenting Alice's DID document is Alice sending her most up-to-date DID document, rather than Eve sending an outdated DID document with the compromised Ethereum address that once belonged to Alice, in an attempt to get my website to interact or send stuff to the compromised Ethereum address? Is a DID like a generalized Bitcoin address, a generalized IPNS name, a generalized email address, or something else entirely?
- cel 5y ago
  Great questions, csense. It is preferable that users bring their own DIDs, rather than you assigning them DIDs as a service provider, to ensure user autonomy. However, you can create DIDs via websites as you are suggesting, using did:web [1]. DIDs are structured or namespaced by DID Methods: the part after "did:" is called the DID Method name, and each Method has its own specification and implementations. There is a registry of DID Methods [2], although it is not a requirement that DID methods be registered. There is a document comparing some DID methods using a Rubric: [3]. > [...] instead of registering a separate account with my website, she can instead type "did:identity.dns.xyz:123456789abcdefghijk" into my website? It can obviate account registration per website, yes. For usability reasons it is often considered desirable that users not have to know about DIDs, type them or see them. The functionality could instead be handled by the user's software. There is a browser standard and polyfill in development which can be used for this: Credential Handler API [4]. > Does my site's software then contact identity.dns.xyz to ask it something? Or is all the information my site needs to do its thing contained in the DID itself? If you have "did:identity.dns.xyz:...", it would depend on what the "identity.dns.xyz" DID method is. If you don't know what the "identity.dns.xyz" DID method is, you could ask a DID resolver that you trust; but they might not know either. If instead you had "did:web:identity.dns.xyz:...", you would indeed contact `identity.dns.xyz` over HTTPS to request the respective DID document. If you instead have a "did:key:..." DID [5], you would indeed have all the information contained in the DID itself, as did:key encodes the public key. In other kinds of DID methods, you may need to contact a peer-to-peer network to resolve the DID. > Is "123456789abcdefghijk" the hash of some document that's returned to my website by the identity.dns.xyz server? It depends on the DID method. If you are using did:web, which is based on HTTPS as mentioned, there is no hash, although this could be handled using hashlinks [6], which is mentioned in the did:web specification as a TODO. In other DID methods, the method-specific-id (the "123456789abcdefghijk" part) is a hash which might refer to some static data or initialization state. > Or is Alice running some identity management browser extension that knows to present a document whose hash is "123456789abcdefghijk" to my website? Possibly, depending on the DID method and how it is implemented. But DIDs are generally expected to be public, globally resolvable, and highly available. > [...] is "123456789abcdefghijk" the hash of a public key which signs something Could be, again depending on the DID method. Some DID methods are based on decentralized ledger technologies where the method-specific-id represents an account id derived from public key hash, e.g. did:ethr [7] and did:tz [8]. > [...] {returned by the identity.dns.xyz server | presented by Alice's software}? Yes, if you are authenticating the user with a DID, generally you would ask them to sign a challenge using authentication key material from their DID document. The DID document is what the DID resolves to, and it includes public keys. In the case of did:key, the DID document contains a single key as encoded in the DID. In the case of a DID method based on a public key hash, the public key must be provided or looked up somehow, or the signing algorithm must support public key recovery [9]. > Or is "123456789abcdefghijk" just a string your webserver happened to generate to identify Alice uniquely that came from /dev/urandom or a PRIMARY KEY column in your database that has no cryptographic meaning? The DID method determines the structure and meaning of the method-specific-id (the "123456789abcdefghijk" part). If you are using did:web, the string is not cryptographic but corresponds to a HTTPS URL. > If Alice's DID document is cryptographically linked to her DID, how does she update it? She performs a DID document update operation [10]. If the DID method is based on a decentralized ledger technology (e.g. btcr [11], ethr, tz), she might publish a transaction to the corresponding network or make a call on a "smart contract". in the case of a did:key, the DID document cannot be updated. > If the DID is the hash of the document, does that mean Alice gets a new DID whenever she edits her profile on dns.xyz? If the DID method is static (basing the DID on the document hash entirely), it would probably have to be a new DID, but if it is only an initial document hash, the DID method could provide for verifying and applying updates somehow. There are also some properties for indicating equivalence between DIDs which might be useful [12]. A DID document could also be updated while still using hashes for integrity protection and referencing if the DID method uses the hash as the DID document version ID. A DID can be resolved at a given version ID using the versionId parameter [13]. For privacy, generally DID documents should not include personal data [14]. Edits to a profile on would then only affect DID documents if they are updating keypairs, or indicating relationships with other DIDs (e.g. using alsoKnownAs), or updating service endpoints, etc. For decentralization and user autonomy, users should be able to update their DID documents with their software directly, rather than having a website in control of their DID and having to ask the website to update it. In the web context that may mean a browser extension or key management API. But there are institutional use cases where the website is expected to have control. > How does my website know that the user presenting Alice's DID document is Alice sending her most up-to-date DID document, rather than Eve sending an outdated DID document with the compromised Ethereum address that once belonged to Alice [...] Often DIDs are resolved publicly or by contacting a network rather than via asking the user (did:peer [15] is a different case). But the concern still applies. Updating a DID document to remove a compromised key is called revocation [16]. The DID method should have some protocol for how updates are performed, which may include how they are ordered, such as by being witnessed or confirmed by some entity or network. The question of the valid state of a DID document should be abstracted by your DID resolver [17]. > Is a DID like a generalized Bitcoin address, a generalized IPNS name, a generalized email address, or something else entirely? More like a generalized Bitcoin address I think, although there are comparisons to be made with the others. Another idea: generalized PGP keys. It is primarily about identity, rather than about communication, storage or payments. For more info I recommend checking out the Decentralized Identity Foundation (DIF)'s FAQ: "What is a DID?" [18]. [1] https://w3c-ccg.github.io/did-method-web/ https://w3c-ccg.github.io/did-method-web/ [2] https://www.w3.org/TR/did-spec-registries/ https://www.w3.org/TR/did-spec-registries/ [3] https://w3c.github.io/did-rubric/ https://w3c.github.io/did-rubric/ [4] https://w3c-ccg.github.io/credential-handler-api/ https://w3c-ccg.github.io/credential-handler-api/ [5] https://w3c-ccg.github.io/did-method-key/ https://w3c-ccg.github.io/did-method-key/ [6] https://datatracker.ietf.org/doc/html/draft-sporny-hashlink https://datatracker.ietf.org/doc/html/draft-sporny-hashlink [7] https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md https://github.com/decentralized-identity/ethr-did-resolver/... [8] https://did-tezos.spruceid.com/ https://did-tezos.spruceid.com/ [9] https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work https://crypto.stackexchange.com/questions/18105/how-does-re... [10] https://www.w3.org/TR/did-core/#method-operations https://www.w3.org/TR/did-core/#method-operations [11] https://w3c-ccg.github.io/didm-btcr/ https://w3c-ccg.github.io/didm-btcr/ [12] https://www.w3.org/TR/did-core/#equivalence-properties https://www.w3.org/TR/did-core/#equivalence-properties [13] https://www.w3.org/TR/did-core/#did-parameters https://www.w3.org/TR/did-core/#did-parameters [14] https://www.w3.org/TR/did-core/#keep-personal-data-private https://www.w3.org/TR/did-core/#keep-personal-data-private [15] https://identity.foundation/peer-did-method-spec/ https://identity.foundation/peer-did-method-spec/ [16] https://www.w3.org/TR/did-core/#verification-method-revocation https://www.w3.org/TR/did-core/#verification-method-revocati... [17] https://www.w3.org/TR/did-core/#dfn-did-resolvers https://www.w3.org/TR/did-core/#dfn-did-resolvers [18] https://identity.foundation/faq/#what-is-a-did https://identity.foundation/faq/#what-is-a-did
hanniabu 5y ago
Idk, maybe it's just because I've already gotten used to ENS addresses, but I'd rather not have something that works become fragmented because w3 who's been asleep at the wheel on this feels left out and wants to remain relevant. How would DNS work with this? If it's chain agnostic then it doesn't seem possible to register names like you can now with them on Ethereum.
- witweb 5y ago
  DIDs are not meant to compete with ENS addresses. They solve different problems.
- leshokunin 5y ago
  They’re different things. We generate the DID when the user creates an account. We use wallets to create that DID. The issue of ENS is a side one. We do happen to have domains (and issue subdomains) on ENS, but that’s to have a pretty URL to resolve the DID. They’re not interdependent.

csense 5y ago

It sounds like you understand enough about DID's to start incorporating them into an actual product. You'll have a bunch of users, and you want to give each of your users a DID. Congratulations! I certainly wasn't able to get that level of understanding from the document. In Section 1.1, it says the DID "did:example:123456789abcdefghijk" resolves to a DID document. Would you then be running some software with all your users' DID's on some server identified by a subdomain, for example identity.dns.xyz? And then the DID for one of your users, let's call her Alice, would be "did:identity.dns.xyz:123456789abcdefghijk"? And then if I run a totally different company, and Alice wants to use my website, instead of registering a separate account with my website, she can instead type "did:identity.dns.xyz:123456789abcdefghijk" into my website? Does my site's software then contact identity.dns.xyz to ask it something? Or is all the information my site needs to do its thing contained in the DID itself? Is "123456789abcdefghijk" the hash of some document that's returned to my website by the identity.dns.xyz server? Or is Alice running some identity management browser extension that knows to present a document whose hash is "123456789abcdefghijk" to my website? Or instead of being the hash of a document, is "123456789abcdefghijk" the hash of a public key which signs something {returned by the identity.dns.xyz server | presented by Alice's software}? Or is "123456789abcdefghijk" just a string your webserver happened to generate to identify Alice uniquely that came from /dev/urandom or a PRIMARY KEY column in your database that has no cryptographic meaning? If Alice's DID document is cryptographically linked to her DID, how does she update it? If the DID is the hash of the document, does that mean Alice gets a new DID whenever she edits her profile on dns.xyz? What if Alice updates her dns.xyz profile because she accidentally pasted an Ethereum private key into a forum post, then generated a new address that wasn't compromised? How does my website know that the user presenting Alice's DID document is Alice sending her most up-to-date DID document, rather than Eve sending an outdated DID document with the compromised Ethereum address that once belonged to Alice, in an attempt to get my website to interact or send stuff to the compromised Ethereum address? Is a DID like a generalized Bitcoin address, a generalized IPNS name, a generalized email address, or something else entirely?

cel 5y ago
Great questions, csense. It is preferable that users bring their own DIDs, rather than you assigning them DIDs as a service provider, to ensure user autonomy. However, you can create DIDs via websites as you are suggesting, using did:web [1]. DIDs are structured or namespaced by DID Methods: the part after "did:" is called the DID Method name, and each Method has its own specification and implementations. There is a registry of DID Methods [2], although it is not a requirement that DID methods be registered. There is a document comparing some DID methods using a Rubric: [3]. > [...] instead of registering a separate account with my website, she can instead type "did:identity.dns.xyz:123456789abcdefghijk" into my website? It can obviate account registration per website, yes. For usability reasons it is often considered desirable that users not have to know about DIDs, type them or see them. The functionality could instead be handled by the user's software. There is a browser standard and polyfill in development which can be used for this: Credential Handler API [4]. > Does my site's software then contact identity.dns.xyz to ask it something? Or is all the information my site needs to do its thing contained in the DID itself? If you have "did:identity.dns.xyz:...", it would depend on what the "identity.dns.xyz" DID method is. If you don't know what the "identity.dns.xyz" DID method is, you could ask a DID resolver that you trust; but they might not know either. If instead you had "did:web:identity.dns.xyz:...", you would indeed contact `identity.dns.xyz` over HTTPS to request the respective DID document. If you instead have a "did:key:..." DID [5], you would indeed have all the information contained in the DID itself, as did:key encodes the public key. In other kinds of DID methods, you may need to contact a peer-to-peer network to resolve the DID. > Is "123456789abcdefghijk" the hash of some document that's returned to my website by the identity.dns.xyz server? It depends on the DID method. If you are using did:web, which is based on HTTPS as mentioned, there is no hash, although this could be handled using hashlinks [6], which is mentioned in the did:web specification as a TODO. In other DID methods, the method-specific-id (the "123456789abcdefghijk" part) is a hash which might refer to some static data or initialization state. > Or is Alice running some identity management browser extension that knows to present a document whose hash is "123456789abcdefghijk" to my website? Possibly, depending on the DID method and how it is implemented. But DIDs are generally expected to be public, globally resolvable, and highly available. > [...] is "123456789abcdefghijk" the hash of a public key which signs something Could be, again depending on the DID method. Some DID methods are based on decentralized ledger technologies where the method-specific-id represents an account id derived from public key hash, e.g. did:ethr [7] and did:tz [8]. > [...] {returned by the identity.dns.xyz server | presented by Alice's software}? Yes, if you are authenticating the user with a DID, generally you would ask them to sign a challenge using authentication key material from their DID document. The DID document is what the DID resolves to, and it includes public keys. In the case of did:key, the DID document contains a single key as encoded in the DID. In the case of a DID method based on a public key hash, the public key must be provided or looked up somehow, or the signing algorithm must support public key recovery [9]. > Or is "123456789abcdefghijk" just a string your webserver happened to generate to identify Alice uniquely that came from /dev/urandom or a PRIMARY KEY column in your database that has no cryptographic meaning? The DID method determines the structure and meaning of the method-specific-id (the "123456789abcdefghijk" part). If you are using did:web, the string is not cryptographic but corresponds to a HTTPS URL. > If Alice's DID document is cryptographically linked to her DID, how does she update it? She performs a DID document update operation [10]. If the DID method is based on a decentralized ledger technology (e.g. btcr [11], ethr, tz), she might publish a transaction to the corresponding network or make a call on a "smart contract". in the case of a did:key, the DID document cannot be updated. > If the DID is the hash of the document, does that mean Alice gets a new DID whenever she edits her profile on dns.xyz? If the DID method is static (basing the DID on the document hash entirely), it would probably have to be a new DID, but if it is only an initial document hash, the DID method could provide for verifying and applying updates somehow. There are also some properties for indicating equivalence between DIDs which might be useful [12]. A DID document could also be updated while still using hashes for integrity protection and referencing if the DID method uses the hash as the DID document version ID. A DID can be resolved at a given version ID using the versionId parameter [13]. For privacy, generally DID documents should not include personal data [14]. Edits to a profile on would then only affect DID documents if they are updating keypairs, or indicating relationships with other DIDs (e.g. using alsoKnownAs), or updating service endpoints, etc. For decentralization and user autonomy, users should be able to update their DID documents with their software directly, rather than having a website in control of their DID and having to ask the website to update it. In the web context that may mean a browser extension or key management API. But there are institutional use cases where the website is expected to have control. > How does my website know that the user presenting Alice's DID document is Alice sending her most up-to-date DID document, rather than Eve sending an outdated DID document with the compromised Ethereum address that once belonged to Alice [...] Often DIDs are resolved publicly or by contacting a network rather than via asking the user (did:peer [15] is a different case). But the concern still applies. Updating a DID document to remove a compromised key is called revocation [16]. The DID method should have some protocol for how updates are performed, which may include how they are ordered, such as by being witnessed or confirmed by some entity or network. The question of the valid state of a DID document should be abstracted by your DID resolver [17]. > Is a DID like a generalized Bitcoin address, a generalized IPNS name, a generalized email address, or something else entirely? More like a generalized Bitcoin address I think, although there are comparisons to be made with the others. Another idea: generalized PGP keys. It is primarily about identity, rather than about communication, storage or payments. For more info I recommend checking out the Decentralized Identity Foundation (DIF)'s FAQ: "What is a DID?" [18]. [1] https://w3c-ccg.github.io/did-method-web/ https://w3c-ccg.github.io/did-method-web/ [2] https://www.w3.org/TR/did-spec-registries/ https://www.w3.org/TR/did-spec-registries/ [3] https://w3c.github.io/did-rubric/ https://w3c.github.io/did-rubric/ [4] https://w3c-ccg.github.io/credential-handler-api/ https://w3c-ccg.github.io/credential-handler-api/ [5] https://w3c-ccg.github.io/did-method-key/ https://w3c-ccg.github.io/did-method-key/ [6] https://datatracker.ietf.org/doc/html/draft-sporny-hashlink https://datatracker.ietf.org/doc/html/draft-sporny-hashlink [7] https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md https://github.com/decentralized-identity/ethr-did-resolver/... [8] https://did-tezos.spruceid.com/ https://did-tezos.spruceid.com/ [9] https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work https://crypto.stackexchange.com/questions/18105/how-does-re... [10] https://www.w3.org/TR/did-core/#method-operations https://www.w3.org/TR/did-core/#method-operations [11] https://w3c-ccg.github.io/didm-btcr/ https://w3c-ccg.github.io/didm-btcr/ [12] https://www.w3.org/TR/did-core/#equivalence-properties https://www.w3.org/TR/did-core/#equivalence-properties [13] https://www.w3.org/TR/did-core/#did-parameters https://www.w3.org/TR/did-core/#did-parameters [14] https://www.w3.org/TR/did-core/#keep-personal-data-private https://www.w3.org/TR/did-core/#keep-personal-data-private [15] https://identity.foundation/peer-did-method-spec/ https://identity.foundation/peer-did-method-spec/ [16] https://www.w3.org/TR/did-core/#verification-method-revocation https://www.w3.org/TR/did-core/#verification-method-revocati... [17] https://www.w3.org/TR/did-core/#dfn-did-resolvers https://www.w3.org/TR/did-core/#dfn-did-resolvers [18] https://identity.foundation/faq/#what-is-a-did https://identity.foundation/faq/#what-is-a-did

hanniabu 5y ago

Idk, maybe it's just because I've already gotten used to ENS addresses, but I'd rather not have something that works become fragmented because w3 who's been asleep at the wheel on this feels left out and wants to remain relevant. How would DNS work with this? If it's chain agnostic then it doesn't seem possible to register names like you can now with them on Ethereum.

witweb 5y ago
DIDs are not meant to compete with ENS addresses. They solve different problems.
leshokunin 5y ago
They’re different things. We generate the DID when the user creates an account. We use wallets to create that DID. The issue of ENS is a side one. We do happen to have domains (and issue subdomains) on ENS, but that’s to have a pretty URL to resolve the DID. They’re not interdependent.