12 ms·

I found it all pretty simple after looking at it briefly when I first learned about it. A DID URI is a URI with a 'method' and globally unique part: did:method

I found it all pretty simple after looking at it briefly when I first learned about it. A DID URI is a URI with a 'method' and globally unique part: did:method:somegloballyuniqueid. The "did" part is literal; a standardized URI namespace. The method part is some symbol that specifies how the unique id resolves and its representation (JSON, whatever.) The method part is what this story is about; W3C has declined to enshrine a set of methods in the standard. Instead, W3C is delegating to a registry of methods. This registry has already grown to a sizeable number. The idea is that you will apply a DID URI using its method and obtain a DID 'document'. This document has claims, credentials, etc. The DID owner can cryptographically prove the document represents them and relying parties can cryptographical verify claims in the document. The actual workflow is more involved than described here but that's the gist of it. BTW, your list of identity schemes you've had experience with roughly correspond to 'method's, although they aren't 'distributed' in the DID sense.

WhyNotHugo 4y ago
What advantages does DID have to something like OpenID? Which is actually decentralised without a central registry.
- fgiveme 4y ago
  This is OpenID's privacy policy: https://openid.net/foundation/members/privacy_policy https://openid.net/foundation/members/privacy_policy They will turn your information to the authority when requested. How is that decentralised?
  - zaphar 4y ago
    OpenID is a standard. Openid.net is one provider not the only provider. You are free to use another provider.
  - WhyNotHugo 4y ago
    It's decentralised because you can pick up any other provider or even host your own (which I did, until OpenID declined from popularity and wasn't accepted anywhere any more).
CuriousSkeptic 4y ago
What problem does adding a common “did:” prefix to these identifiers solve over plain old URIs? Or perhaps my question is more general. What problem does this particular common standard address that individually standardised uri-schemes would not?
makeitdouble 4y ago
What I get from your explanation: it’s a new way to deal with cases where one proves ownership of something else (but in a more indirect way than exposing or accessing the thing itself) That reminded me of proof of domain ownership, where we point a registrar to an arbitrary field in our domain records to prove it’s ours. Sadly I also don’t have enough imagination to see any practical use for that. It feels like an abstraction above every other systems we have today, except any provider would still need to support both this and the underlying actual protocol…
- topspin 4y ago
  > It feels like an abstraction above every other systems we have today, except any provider would still need to support both this and the underlying actual protocol It is an abstraction. As to the burden of 'providers', when one reads about the principles of DID design one finds a deliberate bias toward the identity side (person, thing, etc.): All the subject needs is their DID and to (somehow) verify that it represents their identity. Whatever backend providers inflict upon themselves to deal with that is their problem. This mentality is intended to make coping with identity easy for the 'I' (identity) party.
CharlesMerriam2 4y ago
And so it is as clear as is the Summer's sun.
andreskytt 4y ago
I’m genuinely curious as to why discussions on identity inevitably also involve claims about that identity. For authentication purposes, all that’s necessary is for a user to prove they are in control of an identifiers by presenting some credentials like a nonce encrypted with a private key. Yes, one can share data in-band during the authentication process (as part of the certificate, for example), but it’s not necessary and verifiable claims can be shared via a myriad of other mechanisms like API calls. So why do we spend enormous amounts of resources on trying to merge authentication and data sharing?
- PretzelPirate 4y ago
  Because identity and credentials aren’t the same. A credential tells a system that “I have the correct secret” and an identity tells it “this is who I am”. Who you are is important in understanding what you can and can’t do in a system. For example, an identity might say “this person is a US citizen” and then all systems that can’t allow US citizens will respond appropriately and block your access. Credentials are often shared, identities should never be shared. Credentials will often grant you access to a specific identity. The issue with DID is that there isn’t a way to differentiate whether a credential holder matches the identity those credentials grant access to. The nice thing is that it allows for a set of attestations to be associated with your identity that allow you to essentially be verified once instead of per-system. You could have one financial company go through the KYC process for you and others could leverage their attestations about who you are. You also don’t have to give control over your identity to a third party like Google, Apple, Meta, or Microsoft. I appreciate that since I’m leaving the Apple ecosystem and have way too many accounts set up which use Apple for login. It’s not fun to try and change that and recover my access to those sites.
  - alisonkisk 4y ago
  - Karunamon 4y ago
    You've described the identity of a person, which is not the only or the most common use for credentials. Consider a public/private keypair, where the private key is the credential, the public key is the "identity", but that public key can grant access to any number of accounts despite not being anything other than a randomly generated key.
throwaway0asd 4y ago
The method part is only necessary in the case of anonymous, or untrusted, access. If the distributed access points are trusted, known to each other and verifiable, the method part becomes irrelevant because it can be addressed in the body of the message and the willingness of the distant end to process, or not, such message. As somebody interested in solving for decentralization and previously unaware of the W3C DID effort I formed my own proven solution to this problem 3 years ago. This was one of the less challenging and trivial aspects of the problem space.
tgsovlerkhgsel 4y ago
That sounds very much like one of those solutions that is so complicated that it covers everything in theory, and in practice everyone just ignores it and picks some other standard (or 3...) that is actually narrow enough to cleanly implement and gets the job done.
- nailer 4y ago
  It reminds me of openid 1, with the ridiculous URLs that regular people were supposed to remember. openid died, and openid 'connect' is just a set of standardised claims for oauth.

WhyNotHugo 4y ago

What advantages does DID have to something like OpenID? Which is actually decentralised without a central registry.

fgiveme 4y ago
This is OpenID's privacy policy: https://openid.net/foundation/members/privacy_policy https://openid.net/foundation/members/privacy_policy They will turn your information to the authority when requested. How is that decentralised?
- zaphar 4y ago
  OpenID is a standard. Openid.net is one provider not the only provider. You are free to use another provider.
- WhyNotHugo 4y ago
  It's decentralised because you can pick up any other provider or even host your own (which I did, until OpenID declined from popularity and wasn't accepted anywhere any more).

CuriousSkeptic 4y ago

What problem does adding a common “did:” prefix to these identifiers solve over plain old URIs? Or perhaps my question is more general. What problem does this particular common standard address that individually standardised uri-schemes would not?

makeitdouble 4y ago

What I get from your explanation: it’s a new way to deal with cases where one proves ownership of something else (but in a more indirect way than exposing or accessing the thing itself) That reminded me of proof of domain ownership, where we point a registrar to an arbitrary field in our domain records to prove it’s ours. Sadly I also don’t have enough imagination to see any practical use for that. It feels like an abstraction above every other systems we have today, except any provider would still need to support both this and the underlying actual protocol…

topspin 4y ago
> It feels like an abstraction above every other systems we have today, except any provider would still need to support both this and the underlying actual protocol It is an abstraction. As to the burden of 'providers', when one reads about the principles of DID design one finds a deliberate bias toward the identity side (person, thing, etc.): All the subject needs is their DID and to (somehow) verify that it represents their identity. Whatever backend providers inflict upon themselves to deal with that is their problem. This mentality is intended to make coping with identity easy for the 'I' (identity) party.

CharlesMerriam2 4y ago

And so it is as clear as is the Summer's sun.

andreskytt 4y ago

I’m genuinely curious as to why discussions on identity inevitably also involve claims about that identity. For authentication purposes, all that’s necessary is for a user to prove they are in control of an identifiers by presenting some credentials like a nonce encrypted with a private key. Yes, one can share data in-band during the authentication process (as part of the certificate, for example), but it’s not necessary and verifiable claims can be shared via a myriad of other mechanisms like API calls. So why do we spend enormous amounts of resources on trying to merge authentication and data sharing?

PretzelPirate 4y ago
Because identity and credentials aren’t the same. A credential tells a system that “I have the correct secret” and an identity tells it “this is who I am”. Who you are is important in understanding what you can and can’t do in a system. For example, an identity might say “this person is a US citizen” and then all systems that can’t allow US citizens will respond appropriately and block your access. Credentials are often shared, identities should never be shared. Credentials will often grant you access to a specific identity. The issue with DID is that there isn’t a way to differentiate whether a credential holder matches the identity those credentials grant access to. The nice thing is that it allows for a set of attestations to be associated with your identity that allow you to essentially be verified once instead of per-system. You could have one financial company go through the KYC process for you and others could leverage their attestations about who you are. You also don’t have to give control over your identity to a third party like Google, Apple, Meta, or Microsoft. I appreciate that since I’m leaving the Apple ecosystem and have way too many accounts set up which use Apple for login. It’s not fun to try and change that and recover my access to those sites.
- alisonkisk 4y ago
- Karunamon 4y ago
  You've described the identity of a person, which is not the only or the most common use for credentials. Consider a public/private keypair, where the private key is the credential, the public key is the "identity", but that public key can grant access to any number of accounts despite not being anything other than a randomly generated key.

throwaway0asd 4y ago

The method part is only necessary in the case of anonymous, or untrusted, access. If the distributed access points are trusted, known to each other and verifiable, the method part becomes irrelevant because it can be addressed in the body of the message and the willingness of the distant end to process, or not, such message. As somebody interested in solving for decentralization and previously unaware of the W3C DID effort I formed my own proven solution to this problem 3 years ago. This was one of the less challenging and trivial aspects of the problem space.

tgsovlerkhgsel 4y ago

That sounds very much like one of those solutions that is so complicated that it covers everything in theory, and in practice everyone just ignores it and picks some other standard (or 3...) that is actually narrow enough to cleanly implement and gets the job done.

nailer 4y ago
It reminds me of openid 1, with the ridiculous URLs that regular people were supposed to remember. openid died, and openid 'connect' is just a set of standardised claims for oauth.