Open philarcher opened 4 years ago
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:
Probably 1. would be simplest?
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:
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??