5 ms·

You should have a look at this doc: https://w3c.github.io/did-spec-registries/#did-methods https://w3c.github.io/did-spec-registries/#did-methods Lots of concr

You should have a look at this doc: https://w3c.github.io/did-spec-registries/#did-methods https://w3c.github.io/did-spec-registries/#did-methods Lots of concrete examples of how DIDs are being implemented. Ceramic is particularly interesting and advanced in their thinking.

jFriedensreich 5y ago
that explains a lot but also how would this even work? every solution that relies on generic did s would have to implement all supported methods? or is every method an incompatible namespace in which case what is even the point of did? i really don't get it...
- dwaite 5y ago
  TL;DR it remains to be seen if DIDs create more problems than they solve. I think you got it correctly. "DID" is basically a qualifier for identifiers which can have metadata resolved about them using 'some mechanism', and there are 100+ mechanisms (DID methods). These all have varying technical and non-technical differentiating factors, partially described in the DID Rubrick https://w3c.github.io/did-rubric/ https://w3c.github.io/did-rubric/ . DID methods will not have consistent features nor will the metadata resolved by them consistently meet your data requirements, so you will be limited both in terms of methods you can accept for your use case, and DIDs you can accept within that. One if the base ideas is that it puts users in control of their identity by "owning" a DID, presumably with a lot of local software assistance. This is likely not a single DID, both for interoperability and privacy reasons. It is also likely the DID will be "controlled" by others in some cases - e.g. if a employer or bank accepts DIDs as an authentication system, they will want to be able to guarantee the authentication meets their standards/regulatory requirements.
jFriedensreich 5y ago
and regarding ceramic : i tried finding out what the heck that was and had the same amount of luck as with did. is this written for a different species of developers? they seem to try solving the same problems of ipfs pubsub and ipns but without any hint how they solved it.
contravariant 5y ago
> did:did: Why on earth...

jFriedensreich 5y ago

that explains a lot but also how would this even work? every solution that relies on generic did s would have to implement all supported methods? or is every method an incompatible namespace in which case what is even the point of did? i really don't get it...

dwaite 5y ago
TL;DR it remains to be seen if DIDs create more problems than they solve. I think you got it correctly. "DID" is basically a qualifier for identifiers which can have metadata resolved about them using 'some mechanism', and there are 100+ mechanisms (DID methods). These all have varying technical and non-technical differentiating factors, partially described in the DID Rubrick https://w3c.github.io/did-rubric/ https://w3c.github.io/did-rubric/ . DID methods will not have consistent features nor will the metadata resolved by them consistently meet your data requirements, so you will be limited both in terms of methods you can accept for your use case, and DIDs you can accept within that. One if the base ideas is that it puts users in control of their identity by "owning" a DID, presumably with a lot of local software assistance. This is likely not a single DID, both for interoperability and privacy reasons. It is also likely the DID will be "controlled" by others in some cases - e.g. if a employer or bank accepts DIDs as an authentication system, they will want to be able to guarantee the authentication meets their standards/regulatory requirements.

jFriedensreich 5y ago

and regarding ceramic : i tried finding out what the heck that was and had the same amount of luck as with did. is this written for a different species of developers? they seem to try solving the same problems of ipfs pubsub and ipns but without any hint how they solved it.

contravariant 5y ago

> did:did: Why on earth...