1. 12
  1. 6

    Here’s the actual spec. Odd that the PR didn’t link to it.

    1. 1

      Here is also the particular version/snapshot published today as the Recommendation: https://www.w3.org/TR/2022/REC-did-core-20220719/

      W3C’s home page currently links to this^ - in this blog post: https://www.w3.org/blog/news/archives/9618

      Additional backlinks in W3C public mailing lists:

      Shared on Lemmy: https://lemmy.ml/post/375154
      Shared on Secure Scuttlebutt: %EiDaoVNwPGMteykCAmkoMS8r4hpreGANkw9eZPy6BJw=.sha256

    2. 3

      A related headline: W3C overrules objections by Google, Mozilla to decentralized identifier spec.

      Edits! Thanks to this comment:

      The W3C response to this: Director’s Decision on DID 1.0 Proposed Recommendation Formal Objections.

      Personally I find it deeply concerning that this spec would rely on a proof-of-work blockchain.

      1. 9

        The linked FAQ is the DID Working Group’s public response to the formal objections in 2021. The W3C (Director) decided on the formal objections in 2022: https://www.w3.org/2022/06/DIDRecommendationDecision.html (https://lemmy.ml/post/347337)

        The Decentralized Identifiers (DIDs) v1.0 specification does not rely on proof-of-work or blockchains. How to perform DID operations - recording, distributing, and querying state, etc. - is up to each DID method.

        1. 5

          This is a fantastic clarification, thanks for commenting!

          1. 1

            You’re welcome! It’s an important concern.

            It should be up to applications what DID methods to support.

            Some DID methods are rated by various criteria, in this DID Method Rubric: https://www.w3.org/TR/did-rubric/. Some applications may choose to support or prohibit some DID methods based on relevant criteria for various use cases.

            Some DID methods are listed in DID Specification Registries: https://www.w3.org/TR/did-spec-registries/#did-methods. Listing there is not required and does not imply any kind of endorsement; but it is intended to reduce namespace conflicts.

        2. 7

          I haven’t read through the whole spec yet, but based on the Introduction, I don’t see anything requiring a blockchain.

          The obvious way to define a concrete DID scheme is to put a public key (or digest thereof) into the URI, and to have the identity document be signed by that key. The tricky part is how the payload of a URI is resolved to that document. The spec says:

          …any such system that supports recording DIDs and returning data necessary to produce DID documents is called a verifiable data registry. Examples include distributed ledgers, decentralized file systems, databases of any kind, peer-to-peer networks, and other forms of trusted data storage.

          It’s “just”a global namespace that maps public keys to signed identity documents. This is conceptually simple; the only problems are scale and redundancy. Those are serious problems but they’re simpler than those of decentralized digital currency, and they don’t need the same solutions (blockchains.) There are existing technologies like Keybase that attempt to solve it.

          Here’s a simple but workable non-blockchain solution: upload your identity document to any web server, with its HTTP URL containing the encoded public key, and link to it from some public HTML page. Then resolvers can use any web search engine to look for it.

          1. 1

            Good idea! Sounds like a hybrid of did:key and did:web.

        3. 3

          I don’t get why this is a good thing. Without any default mechanism to validate and the like across implementors, this means that it’s up to the implementor and can and will be vastly different between implementors. What value does this give me as a website owner? Why should I use this instead of other account based systems if it’s not trivial for other websites I interoperate with to also adopt this? What does this offer me that something like OAuth2 and OIDC does not?

          1. 3

            My hot/snarky take: it’s a giant tarpit that very few web developers and site operators will bother implementing in a generic way. Instead we’ll all fall back on the Pareto subset of features FB, Google, MS, et. al. implement.

            It’s darkly funny to me that they call out how email isn’t really decentralized any more b/c of consolidation onto a few providers, then jump to “everyone will get control of their online identity!” IMHO the exact same market forces that took control of email are going to do the same damn thing, because “standards” inevitably lose out to profit and growth OKRs and KPIs.

            JWT, Linked Data, et. al. center on a worldview where “extensibility == freedom”, whereas the rest of us actually live in the world where we can only support about 1% of the emergent standards and integration points. In that (real) context, extensibility actually ends giving rise to the XKCD “now we have N standards” and further consolidating authority in the hands of the big players who can force use of their particular flavor/subset/extensions.