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

I think you’re misreading what I said here — I think we should have had resolution in from the start, but I’ve been told many times that it isn’t. But you can’t meaningfully talk about DIDs and DID Documents without talking about resolution at all. I’m not making a claim that it :is: in scope now, I was merely pointing out that I had originally thought that it was. It isn’t, and that’s what we have to work with. 

That line of the charter does say something very important though: the idea of getting from a DID to a DID Document through the use of a DID Method is something that’s in scope, so we can say what needs to happen without being prescriptive of how it happens. That kind of abstraction layer is really, really important in good system design. Without these function definitions, the current document has NO abstraction layering between DIDs and DID Documents. This lack of proper boundaries has led to many arguments and discussions about what goes where. For a concrete example, I doubt that most of the stated needs for matrix parameters would not be addressed by the “input metadata” construct that I’ve proposed in my pull request. 

So what I’ve proposed is something that defines resolution (and dereferencing) as a process that can be called, but the details of that process are a black box. So we aren’t defining resolution as a protocol or algorithm, but we’re defining it in terms of something that you can call and expect certain results from. 

It would be lovely to have a test suite that tests all parts of the system, but resolver tests are a different set of tests than what would be required to test the normative statements that I have added. I don’t think we NEED to have tests from both directions because it all depends on what we’re testing. Since the core spec, with my new next, only defines what goes in and what goes out, it’s up to the test suite to test the ability of systems to call those functions. In other words, we effectively implement a mocked DID Resolver that doesn’t actually do any DID resolution. It’s a unit test, like when you use a couple of variables that pretend to be a full database. If you’re unit testing a piece of code that depends on database calls, that doesn’t mean you also need to unit test every database out there. You seem to be saying that this is implied, which is simply not true.  It’s separation of concerns and well-defined layers: in this simile the DID resolvers are the database and we’re testing the code that calls the database accessor functions, not the databases themselves. In other words, it’s all the aspects that we need for a good and robust system where the parts are composable in meaningful ways. 

I did not propose new text to what you said in your email because I have a fundamental disagreement with the position you’re taking, in addition to more specific issues with the points themselves. A text patch won’t do to reconcile that, but I thought it important enough to address a key point within your text. It is simply not true that a function definition means you have to have independent tests of both sides, and in fact that makes little sense in terms of test frameworks in general. You always want to mock out as much of the system as you can in order to put certain pieces under test. We are defining features for the caller of these functions, without defining anything about how the functions are fulfilled. Therefore it’s our mandate to test callers of the functions, not the way that they’re fulfilled by resolution implementations. Are these “resolution” tests? Yes. But importantly, are these “resolver” tests? No. 

And as stated on the calls, this isn’t just about a response to the status of the charter — it’s to make the document more sensible, more implementable, and importantly, to help us move more quickly to focus on the things that the group cares about. Having good abstraction layers are vitally important for interoperable standards because good layering allows innovation in the spaces between the layers. 

It seems to me that there are other concerns underneath your stated concern for having normative language around the resolution functions as I’m proposing it. Can you please point out where and how the normative requirements, as stated, will affect or disadvantage Digital Bazaar’s implementations? Is there a concern that needing to comply with this will make existing implementations incompatible? While that’s an inherent risk in any draft standard work, I believe that specific concerns can be worked through without throwing out everything and having a toothless spec.

We all want this to succeed.

 — Justin

> On Apr 17, 2020, at 1:38 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On 4/17/20 11:09 AM, Justin Richer wrote:
>> 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.
> 
> Justin, thanks for elaborating upon your position. I'm having a hard
> time understanding your mental model for the test suite, so it may take
> me a couple of more reads of your email to understand where you're
> coming from.
> 
> I didn't see a concrete counter-proposal for the suggested text in my
> proposal: Could you please provide a concrete counter-proposal, even if
> it is "strike that bullet item".
> 
> The text I suggested was to cover our bases with organizations that were
> not under the impression that we'd do the sort of thing you are
> proposing in this WG (or some variation thereof). That is, if everyone
> agrees to the interpretation of the proposed item you referred to, we
> cover all of our foreseeable bases.
> 
> If we just agree to what you're proposing, which again, I do not
> understand fully yet, but will try again over the weekend, we may not
> have all of our bases covered.
> 
>> I do think we should have fully put resolution in scope for
>> this working group from the start, and had assumed it would
>> be.
> 
> That is the point of contention. We should not assume anyone else
> thought that. In fact, during our first face-to-face meeting, we have a
> long conversation about just this topic with no clear resolution.
> 
> To further clarify, Digital Bazaar, absolutely did not agree to do *all
> caps* "DID Resolution" in this WG. The specification and implementations
> were nowhere ready and I suggest that they're still nowhere ready. From
> our perspective, what we're contemplating doing is new and could be
> argued as within scope, and I've done my best to put forward a
> defensible argument that would allow us to pull a variation of your
> current PR in if we can get the group to get to a consensus position on
> the points I raised.
> 
> One of those points, the one you outlined, feels vital to me, because it
> allows us to test in both directions. Write the tests as you're
> suggesting, or write the tests against concrete implementations. Both of
> those being in scope. Perhaps the way forward is to see if people feel
> that we'd be covered if we just didn't add the bullet item...
> personally, it's a risk I'd rather not take. I'll get an official stance
> from Digital Bazaar before the call... I expect other companies would
> need to do something similar.
> 
> -- manu
> 
> -- 
> 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
>