Re: Clarity on DID Resolution as it refers to DID WG

Hi Manu,

I agree that it’s important to get more clarity on the interpretation of the charter text. I do not agree with your rewording of the charter line below, though (as I’ve said on numerous occasions) I do think we should have fully put resolution in scope for this working group from the start, and had assumed it would be. Still, since we are all working under the charter text and it’s up to us, under the guidance of the chairs, to interpret that charter text and how it applies to our work, I think it’s very important that we be clear about what we’re doing and what we’re not doing.

Regardless, I wanted to talk specifically about one of your bullet points below:

> * It is in scope to add resolution tests to the test
>  suite that exercise the generalized DID resolution
>  process in the specification on concrete DID Method
>  implementations.

You raised this as a concern with pull request #253, and stated emphatically on the call that by having normative language around the resolution contract functions we would be required, unequivocally, to have a full set of tests for resolvers. This is a false conclusion, and though I explained why on the special call yesterday I wanted to do so here on the list as well for others to see.

When you’re testing a function definition, you need to think about what part of that function definition you’re testing. It’s easy to think that you’re testing implementations of that function definition, which is what you’re saying is required here. And if these functions were defined in the scope of a DID Resolution specification that included details and nuance about implementation of the functions, then you’d be correct. However, we need to remember the context in which these functions are being defined: DIDs and DID documents. In other words, the functions are being defined in terms of the expectations of the callers of the functions. And so it is fully in scope for us to test a caller of the function and not the implementation of it. 

You have also asked how this would map into an automated test suite, so let me lay that out in more detail as well:

We are testing DIDs and DID documents, and the code that produces and consumes them. So you’ve got code that generates a DID against a particular method or a DID URL from a DID with parameters and fragments and whatnot in order to DO something with that DID. You hook that code into the test suite and have it throw a bunch of DIDs and DID URLs at the resolve() and dereference() functions of the test suite. This means that the test suite will stub out the implementations of these functions, such that any valid DID will hand back a valid dummy DID document, probably the same one. An invalid DID will produce an error. If your code tries to call resolve() with a DID URL instead of a DID, you don’t pass the test. Additionally, you’ve got code that’s going to parse and process the DID documents. So the test suite hands you back a plain JSON document with the wrong mime type — you need to handle that as an error and if not you don’t pass the test. If your code is handed back an error response and crashes because it tries to parse the (empty) document, you don’t pass the test. If you get handed back a corrupted data stream, you need to handle that case gracefully as well. 

None of these tests are testing resolver code, and all of them are very useful for the community and for testing the different aspects of the specification. The functional definitions of resolve() and dereference() lend themselves to testing far more than anything else in the document, save perhaps for the ABNF itself.

So I ask that people look at the functional contracts from the perspective that they’re written in — not in terms of constraints that they put on resolvers, but instead on capabilities they allow for the callers, and the kinds of things that it allows us to test with those callers.

 — Justin


> On Apr 16, 2020, at 2:16 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> There is a line in our current charter that was a topic of debate in our
> DID WG special call today. Namely, this one:
> 
>> Establish a deterministic mapping between DID method
>> identifiers and the resolution process used to resolve that
>> DID method.
> 
> Interpretations of what that sentence means have been varied and have
> spilled into the DID Resolution discussion. If the DID WG takes a
> consistent (and official) position on the interpretation of that
> statement, it'll help us figure out how to bring this DID Resolution
> discussion to a close.
> 
> Hindsight being 20/20, that statement probably should have said
> something more along these lines:
> 
> Define a concrete, generalized, and extensible DID resolution process
> for DID Method implementers that transforms a DID into a DID Document.
> 
> Specifically, this means that:
> 
> * It is in scope for the DID WG to define a concrete process
>  that takes a DID as input and provides a DID Document as
>  output.
> 
> * It is in scope to make that process take in options and
>  provide back a document along with different
>  classes of metadata (e.g., subject, document, and
>  resolution metadata).
> 
> * It is in scope to add resolution tests to the test
>  suite that exercise the generalized DID resolution
>  process in the specification on concrete DID Method
>  implementations.
> 
> * It is out of scope to normatively define DID Method specific
>  details of implementing DID resolution.
> 
> * It is out of scope to normatively define DID Resolution
>  protocols and representation formats.
> 
> * It is out of scope to test concrete DID Resolution
>  protocols and data formats beyond the necessary
>  process to demonstrate interoperability between the
>  test suite and an implementation.
> 
> If we can get consensus on the above, it'll provide clarity around
> exactly how far we can take this DID Resolution discussion and exactly
> what is in scope and out of scope.
> 
> My request is that the Chairs put this (or some variation) to the WG
> during the next call where getting consensus on this would be an
> appropriate use of everyone's time.
> 
> -- manu
> 
> PS: Thanks to Dave Longley for kicking off[1] this thought process to
> get more clarity.
> 
> [1] https://github.com/w3c/did-core/pull/253#issuecomment-614787033
> 
> -- 
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>