RESOLVED: Refactor the conformance test suite to support did:key as the only mandatory DID format for the test suite.
Originally: https://github.com/w3c-ccg/vc-http-api/issues/184
This is ready for PR against the spec, in some informative section of testing.
Suggest this move to https://github.com/w3c-ccg/vc-api-test-suite, and close this issue.
The group discussed this on the 2022-12-13 telecon. It was highlighted that the Jobs for the Future Plugfest 2
@jandrieu noted that nothing should be mandatory, and test suite should say what they support and what DID Methods they can verify. This is important if only to surface nascar problem in this space. If company A gets VC from company B, then VC is useless. The "hey we have a default mechanism" will elevate a DID Method above others. @jandrieu feels like there should be no "default mandatory". The current test suite enables each implementation to convey what DID methods and what cryptosuites they support. @TallTed noted that he was supportive of negotiations that will need to be a part of the ecosystem. Greg Bernstein asked "recommended vs. mandatory" -- it's nice to give guidance? @dlongley noted that giving a recommendation might be fraught, but what we could do is surface, of existing implementations, give number breakdowns of what supports which DID Method -- people could use that as a proxy for what could be implemented, Greg seemed to agree with the approach. @jandrieu noted that he liked how that let new candidates emerge as frontrunners. @dlongley noted that an implementation might expose multiple configurations to the test infrastructure (e.g. "works with did:key" and "works with did:jwk") and the test infrastructure would then use each configured endpoint appropriately across various VC API tests.
The group settled on the notion that there will be no mandatory or recommended DID Method(s) or cryptosuites and instead implementations will be able to convey what they support and those implementations will be used appropriately across the test suites.