Define /.well-known endpoint for an API to advertise optional features supported

[tplooker]

As is the case in many standards based HTTP APIs, when optional features or points of extensibility are present it is useful for the API to be able to advertise which features it does and does not support. One popular mechanism for achieving this is via /.well-known endpoints, openid connect discovery is one such relevant example that makes use of this mechanism.

The proposal would be to define an endpoint whereby an API could advertise support for some of the following features that are either optional or intended to be extendable

• Supported Digital Signature Schemes (e.g Ed25519Signature2018)
• Supported Credential Status Methods (e.g RevocationList2020Status)
• Optional APIs

Outstanding questions

• Do we want to seperate out support for issuance vs verification of the above elements? E.g I may support verifying VCs under a certain scheme but not issuing?

[OR13]

I am in favor of using well known endpoints for discovery, IIRC there was a part of the PE spec that was supposed to support this. we should see if its usable.

[csuwildcat]

Yeah, I'd argue we should add these features to the Well-Known DID Configuration object, and that they should point to the PE spec's mechanisms for how to represent them.

[bumblefudge]

I think it is reasonable to assume that a significant portion of users of the API would support verification but not issuance-- if not for these examples, at least for future optional APIs. Example: we can verify multiple revocation methods but only issue according to one of them.

[csuwildcat]

@tplooker we specifically created Well-Known DID Config to be patterned after the things you might find in an OIDC Config, as you mentioned, so it would really be a shame if we all created a clone of something already defined :/

https://identity.foundation/.well-known/resources/did-configuration/

[mprorock]

I am a big fan of this @tplooker

[bumblefudge]

On today's VC-API call, @mprorock drew our attn to this PR:
w3c-ccg/traceability-interop#45

[msporny]

We discussed this on the 2022-01-18 call. @mprorock reported that DID Configuration exists. DID Config might be complex to implement correctly, Traceability folks are using this, same issue as discovery but uses did:web for some of this (but does not cover all capabilities); good step in right direction. Since we have gotten away from optional features, but using things like did:web for discovery, that might carry us most of the way there (@mprorock's personal sense).

As PR #45 on Traceability is implemented for dynamic testing, that might be a path -- might be a good way to handle that. Depends on appetite for other implementers that might want to weigh in on service and key discovery.

Discussion will continue in this PR.

[OR13]

We no longer think well known did configuration is a good solution... there are replacements for it under development at DIF and there are discovery features and GET endpoints that need to be defined here... both are better solutions.

closing as won't fix.