Resolver descriptions

[philarcher]

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??

[mwherman2000]

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/).

[philarcher]

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).

[jandrieu]

@philarcher Agreed. A discovery endpoint where a resolver can self-describe its capabilities would be interesting.