4 ms·

So I've just scanned over this stuff, maybe someone can fill in some gaps for me. There's a list of DID methods "in development" [1]. Is this the list of metho

So I've just scanned over this stuff, maybe someone can fill in some gaps for me. There's a list of DID methods "in development" [1]. Is this the list of methods, or is there a centralized registry, or are these just "known" methods? If there's a centralized registry -- then this isn't really "decentralized" is it? On top of that there's a land-grab that's already begun for the method names, and isn't that going to kill the spec? com, nft, object, web, are already registered by private orgs. But if it's not centralized, then it's not unique. What stops me from making my own "verifiable registry" [2] for eg `did:nft:internet` which cryptographically proves I own the internet? "Ceramic Network" (the owner of "nft" on the w3c site) says they own it in their registry .. but who's correct? [1] https://w3c.github.io/did-spec-registries/#did-methods https://w3c.github.io/did-spec-registries/#did-methods [2] https://www.w3.org/TR/did-core/#dfn-verifiable-data-registry https://www.w3.org/TR/did-core/#dfn-verifiable-data-registry

radicalbyte 4y ago
That's the list of methods; and yes, there is very much a land grab going on right now. No, there's nothing stopping you making your own methods. But will anyone actually use it?
- oofbey 4y ago
  So if I’m building a service that lets somebody login with a DID, and I’m using a DID library to verify your authN then that library needs a different code block for every one of those methods?? LOL. What could possibly go wrong? Or less sarcastically, how could this possibly be expected to work?
  - cratermoon 4y ago
    Yeah DID is a dumpster fire. It's a consulting company's dream spec. Anything is possible but almost nothing is required. It smells a bit like SAML all over again, wherein they try to satisfy every stakeholder and end up satisfying none.
    - dwaite 4y ago
      To be fair, SAML was a victory at the time - in that they could even get the parties involved to agree to come to the table and write specs and agree to implement them. IMHO, such consensus work improved in quality for a while after the WS-* dumpster fire was put out by JSON.
      - cratermoon 4y ago
        Oh 100% SAML over WS-*. At least SAML can be made to work across vendors. I've never seen anything WS work outside of MSFT products.
  - dwaite 4y ago
    "that library needs a different code block for every one of those methods" Yes, and that is trusted code - even with isolation, an compromise of that method's resolution code would result in malicious parties being able to impersonate anyone else using that method. There are use cases where you don't want correlation, in which case the decentralized identifier might exist only for you to log into a single web site. At that point, it might be easier to use a method like did:key or did:jwk which encode all of their information into the URL itself, and forego the ability to rotate or revoke keys.
- echelon 4y ago
  > there is very much a land grab going on right now. Where and how? Edit: I just saw the list. It's very land grabby feeling.
  - leaflets2 4y ago
    Where is the list?
fooey 4y ago
It's such a bad spec it'll never be implemented by anyone In a round about way W3C successfully did the opposite of what they claimed they where trying to do, killing the entire concept and ensuring it won't ever actually happen
kimhd 4y ago
That method registry is simply self-service way to register DID methods, so it functions like the latter -- "known" methods. There's no editorial/curation aspect to this registry; that's out of scope. The requirements are simply basic DID method conformance -- specify how the create/read/update/write methods are implemented, security considerations, and so on. The land grab concern you mention is real, but would likely not be addressed at this level (again, it would be considered out of scope), but could happen in a different standards group. Some relevant work includes defining criteria by which to evaluate DID methods -- i.e., does it support update operations (e.g., did:key doesn't), does it rely on a blockchain and if so, is it permissioned, and numerous other factors. Probably the most comprehensive treatment of these are the DID method Rubric [1] With Verite, our considerations were mostly around no/low cost, interoperable/open source implementations for the open source implementation (although anyone can use any method they like). The ones we're most likely to add open source implementations for next are did:pkh and did:ion. [1] https://www.w3.org/TR/did-rubric https://www.w3.org/TR/did-rubric [2] https://verite.id/verite/patterns/identifier https://verite.id/verite/patterns/identifier

radicalbyte 4y ago

That's the list of methods; and yes, there is very much a land grab going on right now. No, there's nothing stopping you making your own methods. But will anyone actually use it?

oofbey 4y ago
So if I’m building a service that lets somebody login with a DID, and I’m using a DID library to verify your authN then that library needs a different code block for every one of those methods?? LOL. What could possibly go wrong? Or less sarcastically, how could this possibly be expected to work?
- cratermoon 4y ago
  Yeah DID is a dumpster fire. It's a consulting company's dream spec. Anything is possible but almost nothing is required. It smells a bit like SAML all over again, wherein they try to satisfy every stakeholder and end up satisfying none.
  - dwaite 4y ago
    To be fair, SAML was a victory at the time - in that they could even get the parties involved to agree to come to the table and write specs and agree to implement them. IMHO, such consensus work improved in quality for a while after the WS-* dumpster fire was put out by JSON.
    - cratermoon 4y ago
      Oh 100% SAML over WS-*. At least SAML can be made to work across vendors. I've never seen anything WS work outside of MSFT products.
- dwaite 4y ago
  "that library needs a different code block for every one of those methods" Yes, and that is trusted code - even with isolation, an compromise of that method's resolution code would result in malicious parties being able to impersonate anyone else using that method. There are use cases where you don't want correlation, in which case the decentralized identifier might exist only for you to log into a single web site. At that point, it might be easier to use a method like did:key or did:jwk which encode all of their information into the URL itself, and forego the ability to rotate or revoke keys.
echelon 4y ago
> there is very much a land grab going on right now. Where and how? Edit: I just saw the list. It's very land grabby feeling.
- leaflets2 4y ago
  Where is the list?

fooey 4y ago

It's such a bad spec it'll never be implemented by anyone In a round about way W3C successfully did the opposite of what they claimed they where trying to do, killing the entire concept and ensuring it won't ever actually happen

kimhd 4y ago

That method registry is simply self-service way to register DID methods, so it functions like the latter -- "known" methods. There's no editorial/curation aspect to this registry; that's out of scope. The requirements are simply basic DID method conformance -- specify how the create/read/update/write methods are implemented, security considerations, and so on. The land grab concern you mention is real, but would likely not be addressed at this level (again, it would be considered out of scope), but could happen in a different standards group. Some relevant work includes defining criteria by which to evaluate DID methods -- i.e., does it support update operations (e.g., did:key doesn't), does it rely on a blockchain and if so, is it permissioned, and numerous other factors. Probably the most comprehensive treatment of these are the DID method Rubric [1] With Verite, our considerations were mostly around no/low cost, interoperable/open source implementations for the open source implementation (although anyone can use any method they like). The ones we're most likely to add open source implementations for next are did:pkh and did:ion. [1] https://www.w3.org/TR/did-rubric https://www.w3.org/TR/did-rubric [2] https://verite.id/verite/patterns/identifier https://verite.id/verite/patterns/identifier