Regarding "getting a jump-start on a DID Resolution test suite", there is already such a test suite:

I think we should contribute this to CCG too.

Sometimes the boundary between a DID method test suite (such as did:key) and a DID Resolution test suite is debatable, e.g. I raised an issue which lists a few tests that in my opinion should be moved from the did:key test suite to the DID Resolution test suite, since they test something that's not method-specific:


----- Manu Sporny wrote -----
From: Manu Sporny <msporny@digitalbazaar.com>
Date: 27.08.2022 16:28
To: Joel Thorstensson <oed@3box.io>
Cc: W3C Credentials CG <public-credentials@w3.org>
Subject: Re: Initial did:key interoperability test suite launched
On Fri, Aug 26, 2022 at 1:57 PM Joel Thorstensson <oed@3box.io> wrote:
Why does the test suite rely use http?

The best alternative we could think of would:

* Ask every developer to create and maintain a docker image for their
did:key resolution library.

* Create a complex test environment that would be specific to DID
Methods where the test suite downloads every implementation docker
image and runs it against the test suite, collating the output, and
producing a report, which would not be adequate for seeing if the DID
Resolver is actually modifying/munging the output of the DID Method
implementation... so we'd have to have a separate DID Resolver test
suite for each DID Method anyway.

IOW, it would require almost the same amount of effort from the
developer for something that doesn't meet our community testing
requirements for production-grade library implementations.
Does this mean that I need to run and maintain a server to prove that my implementation conforms to the spec?

It means that /someone/ will need to run and maintain that server (or
pay you to do it), yes. For-profit enterprises that need to prove the
production-readiness of their systems will have a strong incentive to
do this for you if they use your library. At this point in history,
the cost of running such a system is no longer an issue -- Linode has
shared CPU plans that start at $5/month, which is a rounding error for
most any organization.

The other benefit we get with an HTTP API-based testing methodology is
getting a jump-start on a DID Resolution test suite as well as a
scalable mechanism for testing DID Method specifications... we're
demonstrating DID Method READ right now... with a generalized plan for
Create, Update, and Deactivate on the way. If we're able to pull the
latter off, we'll be able to demonstrate interop across multiple DID
Methods, which is the next step in our community's evolution --
globally standardized DID Methods with real demonstrable proof of

Did that answer your question, Joel?

-- manu

Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)