charter-drafts
charter-drafts copied to clipboard
w3c
[wg/did] DID Resolution specification on the Rec track.
From @msporny: [[ Place the DID Resolution specification on the Recommendation track. ]] From 2023 AC review.
From @OR13: [[ Place the DID Resolution specification on the Recommendation track.
To address previous formal objections, the working group needs to demonstrate that the DID URL format can be implemented with sufficient interoperability.
Some working group members have argued that this requires a single standard DID Method that is mandatory to implement. Others have argued that defining the URL format and resolution behavior is sufficient.
We don’t believe the W3C is the correct place to standardize specific methods, in much the same way that it is not the place to standardize web servers.
We believe that, following in the spirit of HTTP, W3C can define URLs, Dereferencing and Resolution, and relinquish the responsibility of standardizing DID Methods to other organizations.
In particular we believe that Key Transparency (keytrans), Supply Chain Integrity, Transparency, and Trust (scitt), Multiformats (multi) working groups at IETF might be better places to standardize specific DID Methods, due to the active participation of subject matter experts whose interest in relevant use cases demonstrates optimal contribution to fit-for-purpose DID methods.
]] From 2023 AC Review
I'm happy to answer any questions and to propose additional text, on a dedicated issue.
From @jandrieu [[ A significant failing of the initial DID Core specification was a failure to develop interoperability between DID Methods. This lack of interoperability was cited as a reason for multiple Formal Objections to that specification. We concur, it's problem. (...) We believe the answer is simple: standardize DID Resolution. Not restricted to FPWD status, but actually create a normative global standard for Resolution as a W3C Recommendation.
By defining a common API that all DID Methods can implement to provide an interface for a back-end verifiable data registry, we allow any system that can support those implementations an equal opportunity to interoperate with any other, just like HTTP allows any browser to reach any website, regardless of the back-end technology that does the heavy lifting.
That's how we get to interoperability. ]] From 2023 AC Review
From @rxgrant [[ / DID Resolution has consensus and resolves 2021 formal objections /
This WG has a technically sound path available to it that dissolves most and maybe all objections, should the W3C apply its values and properly seek consensus! ]] From 2023 AC Review
Following several discussions at TPAC this week, I believe that one possible way forward might be:
- Charter the DID WG purely to maintain the DID Core spec. Such a maintenance group needs minimal W3T support and should, in theory anyway, be uncontroversial in that it is a W3C Rec that needs maintaining. I suggest this group should not be asked to define one or more DID methods for standardization.
- A separate WG can be chartered to work on resolution. My own model for this would be that each resolver is independent and resolves one or more DID methods. If asked to resolve a DID method that it understands, it returns the DID Doc. If it's asked to resolve a DID for which it has no support, it should be able to pass the request on to another resolver that does. Each resolver is independent and self-sovereign but operates in a network so clients don't need to know a priori which resolver to go to. That's the interop piece.
- The suggestion was made (by David Singer) that a new DID method be devised that was obviously and explicitly designed purely for testing purposes. A kind of baseline interop to get you started. Informally this has been called 'did:stupid'. I see the immediate attraction and can see the potential. However, I am not 100% convinced that it's necessary. It may be, sure, but it may not (I'm kinda hoping it isn't).
- If you'll allow me to divert into a very GS1-centric view, I'd actually like the concept of a resolver to be more widely scoped so that, sure, it performed all the DID resolution functions. That's priority number 1 and clearly the immediate need. But there are other identifier types that are associated with resolvers. DOIs are a well-known example (you can resolve DOIs at doi.org, handle.net and a bunch of others) and, yes, there are GS1 identifiers. Full disclosure, I am responsible for our "GS1-Conformant resolution" standard. If the concept of a network of resolvers is attractive, such that each one performs a discoverable set of resolution operations, then I'd like to at least explore the possibility that a resolver could not only resolve one or more DID methods but might also be able to resolve other ID types too that were not DIDs. A 'standardized protocol' to create the network of resolvers could be as simple as each resolver publishing a list of its own capabilities (at GS1 we call this a Resolver Description File, located at /.well-known/gs1resolver) so each was discoverable, or it could be some sort of secure communication such that each resolver could act as a proxy for the one that's actually doing the work. Dunno - this is very much TBD. If this idea flies, the resolution WG would have 2 Rec Track docs: DID resolution - which I would expect to be pretty much unchanged from the current CG draft, and one on a resolver networking protocol/federation/whatever is the least pejorative word here that could optionally be implemented by any resolver of any kind.
Phil, I probably missed some of the TPAC conversations, since I had to leave on Tuesday, but here are some thoughts:
- I think we should stick with the current proposal of having one WG that will 1. maintain DID Core, and 2. standardize DID Resolution. Having two separate WGs feels like a lot of unnecessary overhead, considering also the close relationship between DID Core and DID Resolution. Whether or not 3. standardizing DID methods will be included is still being discussed as far as I can tell. But even without standardizing specific DID methods, there should be sufficient content and value in standardizing DID Resolution, and I believe this by itself provides a lot of opportunity to demonstrate practical and useful interoperability.
- I agree the idea of having a test DID method did:stupid could be interesting. This is also the reason why originally I was not opposed to including this in the Charter. But see above, I don't think it's really necessary to standardize any specific DID method in a W3C WG in order to demonstrate interoperability between DID resolvers and applications. Furthermore, there could actually also be a risk that defining something like did:stupid could "backfire", and give the impression that DID applications and resolvers can only ever interoperate if there is a narrowly defined common set of DID methods, which of course is not true and harms decentralization and innovation.
- I like the idea of resolvers passing on requests to other resolvers. There have already been some thoughts similar to this, e.g. see the methodNotSupported error code, various DID Resolution architectures, and a thread about local/remote resolvers. I could imagine a number of different ways how a "network of resolvers" could interact. I'm not sure if really a separate protocol is required for that, or if that could be achieved with existing functionality in DID Core and DID Resolution, with maybe the addition of a few extension DID resolution options and metadata properties.
- The idea of making resolution capabilities discoverable has also already been discussed in a similar way. I think something like this would make sense and could be defined by the new WG.
- Regarding resolving other ID types than DIDs: This is a very interesting topic. In the DIF Universal Resolver, the original idea was also that it would be really "universal" and also support other identifiers such as domain names. BUT: If we widen the scope of Resolution to cover also non-DID identifiers, then what would be the "common elements" of such a Resolution specification or implementation? Wouldn't there then be a need to define yet another abstraction layer, which DIDs actually already provide? In other words, you could also go the other direction and just "DIDify" any identifier type, such as did:doi or did:gtin, no? :)
So my bottom line is, I think we should have one WG for maintaining DID Core and standardizing DID Resolution, and as part of that we can work on extensions and additional functionalities like the ones you describe.
