Hacker Newsnew | past | comments | ask | show | jobs | submit | kimhd's commentslogin

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

[2] https://verite.id/verite/patterns/identifier


The original article was based on fundamental misunderstandings of Blockcerts, but the follow-up Blockcerts community discussion (including the article's author) was productive:

http://community.blockcerts.org/t/response-to-blockchain-blo...


Including the response of JHH in the comments again.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: