w3c
Resolver descriptions
I note that Issues 25 and 26 are closed but suggest the topic might be worth revisiting. In GS1 Digital Link we define the concept of a Resolver Description File that provides useful information about the capabilities of the service. Our own is at https://id.gs1.org/.well-known/gs1resolver (we have a JSON schema for this as part of the spec - most terms are optional, only one or two are mandatory). This allows a number of key bits of information to be machine discoverable:
- the types of GS1 identifiers supported (for which read 'DID methods we understand');
- the resolver's root (we allow any number of path segments before the GS1 stuff takes over the URI space);
- who operates the service;
- more...
It perhaps does something more important, however - it allows each resolver to be sovereign about what it does and yet still be interoperable with others. If I understand the spec properly, requests to service endpoints have to be constructed. Is it possible that a resolver that supports method A may only be able to handles requests to service endpoints of types X and Y and not Z??
SUGGESTION: Why not store these sorts of configuration parameters (e.g. for Resolvers as well as for DID Method specifications) as credentials directly in the DID Registry? #eatourowndogfood
The Trusted Digital Web works this way (https://hyperonomy.com/2019/11/06/trusted-digital-web-whitepaper/).
Goodness, it's almost 5 years since I first raised this topic. But it remains open from my POV. I'd really like there to be a standardized method for declaring a DID resolver's specific capabilities (assuming, surely, it won't be the case that all DID resolvers MUST handle all DID methods).
@philarcher Agreed. A discovery endpoint where a resolver can self-describe its capabilities would be interesting.
I agree we should add this feature, and I also still find the discussions in https://github.com/w3c/did-resolution/issues/25 and https://github.com/w3c/did-resolution/issues/26 useful.
Having such a feature can help with the "achieving practical interoperability" objective.
This could come in various forms I suppose:
- A single "resolver descriptions" data structures.
- Multiple data structures, e.g. to express supported DID methods, supported DID parameters, etc. Note this micro-spec at DIF for enumerating DID methods.
- A more complex query endpoint with input parameters.
Probably 1. would be simplest?
This was discussed during the did meeting on 23 January 2025.
View the transcript
w3c/did-resolution#51
Wip: We'll go through the issues.
Wip: Do we want to define a way for a resolver to say what it supports?
Wip: Goal -- go through these issues to identify ones that need to go in the spec -- and looking for volunteers.
markus_sabadello: Lean not, but could help with the practicality argument -- a standard way to ask a resolver supports.
manu: Can just ask to resolve a DID of a type, and it either does or doesn't.
manu: That said -- we would not encourage anyone to use a resolver blindly -- it would be done at coding time and the human trust (and features) would be evaluated at that time. Not need dynamically.
… Gets into the /whois capability that allows a DID to express information about itself. Don't put in the spec, but incubated in practice/other spec, and then see if we want to add it into the core spec.
<Zakim> JoeAndrieu, you wanted to avoid programmatic discovery because trust should not be automated
dmitriz: Another vote for not in the core spec. Echo Manu's comments.
JoeAndrieu: +1 to evaluating why to trust a resolver -- not just a what it supports.
This was discussed during the did meeting on 23 January 2025.
Based on this discussion, we decided this issue would be best addressed as a extension. With caveats that if you have to ask a resolver to describe what it supports then you also should be concerned about why you should trust that resolver.
