11–20 of 89 posts
Unless I miss something, this looks like a solution to nonexistent problem?
Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. Sounds like a PGP replacement in some ways. Also possibly an alternative to SSN (for Americans).
Earlier quoted context omitted.
That's probably what someone would have said if they saw Facebook 20 years ago. The intention here is to get out in front of FAANG before they can make their own, proprietary standards for ID. As terrifying as it is, personal identification is going to become a huge part of the next 10 years of computing, and potentially radically change the way we interact with the web.
I'm, sadly, old enough to remember this absolutist argument about OAuth. I'm curious, what's the risk here?
Risks would include, privacy concerns, from obvious to not yet identified; the standards not being good at things other interested parties may like; mechanisms that encourage/require normal users to delegate some functions to private third parties; mechanisms that make it hard for normal users to use their identities as they choose; mechanisms that place more burdens on the user for retail fraud ("identity theft", for instance); the list goes on.
For more, consider the ways that ID is used against people today. Now apply automation and a world-wide attack surface, and do not consider mitigations that might have an effect on some big actor's bottom line.
Unless I miss something, this looks like a solution to nonexistent problem?
That's probably what someone would have said if they saw Facebook 20 years ago. The intention here is to get out in front of FAANG before they can make their own, proprietary standards for ID. As terrifying as it is, personal identification is going to become a huge part of the next 10 years of computing, and potentially radically change the way we interact with the web.
Earlier quoted context omitted.
Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. Sounds like a PGP replacement in some ways. Also possibly an alternative to SSN (for Americans).
The same as the X.501 PKI we've had for decades.
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 ), 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.
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?
Unless I miss something, this looks like a solution to nonexistent problem?
Full disclosure: I worked on the XDI and XRI specifications that paved the way for DID, and also very slightly on the DID specs (contributing thoughts and inputs, I did not author any part of the DID specs).
It's a good set of specs, written by people that know identity and have a good vision.
Unless I miss something, this looks like a solution to nonexistent problem?
That's probably what someone would have said if they saw Facebook 20 years ago. The intention here is to get out in front of FAANG before they can make their own, proprietary standards for ID. As terrifying as it is, personal identification is going to become a huge part of the next 10 years of computing, and potentially radically change the way we interact with the web.
This is just a variation on the URN idea afaict. RFC2141 is more than 20 years old. There's been plenty of time to get out in front of fb, et al.