Re: DID spec Test Suite

Standing ovation to Andrew for development of a DID test suite and
Manu/Digital Bazaar for driving this effort. This is tremendously valuable
to the community!

I have some questions, but I suggest giving this some brief air time next
CCG call for high level coordination, and to make sure everyone's aware of
this development. I'll call on you next meeting to discuss.
Thanks,
Kim



On Fri, Jun 7, 2019 at 7:05 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> Hi all,
>
> Andrew Jones (cc'd) is currently working on a DID specification test
> suite and has made a full pass on the spec, pulling out every normative
> statement that needs to be tested.
>
> The good news is that we have a kernel of a set of tests that we can
> implement now and try to demonstrate interop between DID libraries that
> produce and validate DIDs and DID Documents. Hooray. We expect the test
> suite to be ready in two weeks with tests for 26 of the normative
> statements in the specification (roughly ~60 tests).
>
> The bad news is that there are an additional 83 normative statements
> that are not testable. For example:
>
> """
> A DID is a new type of URL that SHOULD NOT require a centralized
> authority to register, resolve or deactivate, nor to update associated
> data.
> """
>
> So, how do you write a test to ensure that a Decentralized Identifier
> Registry is not centralized?
>
> There are other statements that have more to do with DID Resolution than
> the core DID Document and should probably be moved to the DID Resolution
> specification. For example:
>
> """
> Therefore DID resolvers and other client applications SHOULD validate
> that keys were not expired at the time they were used.
> """
>
> That statement is testable, but probably belongs in the DID Resolution
> specification.
>
> ... and other statements that have to do with requirements on DID Method
> specifications (and cannot be automatically tested, so there will be a
> strong argument to remove the normative statement from the specification
> when it goes standards-track). For example:
>
> """
> The DID method specification MUST specify how a client creates a DID and
> its associated DID Document on the Decentralized Identifier Registry,
> including all cryptographic operations necessary to establish proof of
> control.
> """
>
> Just putting this out there so that others are aware of the current
> state of things related to the test suite.
>
> The mistake we made with the Verifiable Credentials test suite was
> waiting until we were in the W3C Standard Candidate Recommendation phase
> to put together the test suite. We are trying to fix this issue by
> making sure we have a test suite going into the DID Working Group.
>
> The challenge is going to be augmenting, moving, or rewording those 83
> normative statements in a timely fashion. During the early days of the
> VC WG, I went through and reworded/stripped many of those statements. My
> hope is that we can depend on the editors to do the right thing and not
> block them from making these changes. An extended discussion on 83
> normative statements will slow progress to a crawl, and we don't want
> that right now.
>
> To be clear, we can do this work when the DID WG is under way... but as
> with all things, it's easier to do these sorts of changes earlier than
> later.
>
> Just sharing this information with the group... we'll have to figure out
> how to manage this as the months roll on.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>