Re: Report on the DID Spec call today

Dmitri,

I like Markus' litmus test that "If a certain matrix parameter helps to
construct identifiers (URIs) for something that needs an identifier, then
that matrix parameter is justified".

For today's DID/DID Resolution meeting
<https://docs.google.com/document/d/1qYBaXQMUoB86Alquu7WBtWOxsS8SMhp1fioYKEGCabE/edit?usp=sharing>,
I wrote up a more in-depth explanation of this perspective called Algorithmic
Construction of DID URLs: A Perspective on Matrix Parameters
<https://docs.google.com/document/d/1-aHdUyhzUNWPU_kZ2ICnyBguZmN1jUidaRlIcqYgYuI/edit?usp=sharing>.
I look forward to discussing that on today's call.

=Drummond



On Thu, Jun 13, 2019 at 9:32 AM Markus Sabadello <markus@danubetech.com>
wrote:

> Dmitri,
>
> If that was the litmus test, then the "service" matrix parameter wouldn't
> pass it either, since you could also argue that you can select a service by
> ID simply "by retrieving and parsing DID Documents".
> However we have already approved "service", and there has been very broad
> support for it.
>
> On the other hand, you say that according to your litmus test,
> "version-time" should have a matrix parameter.
> But you could also argue that you can support versioning without matrix
> parameters, on a different layer (using "resolver options" to the DID
> Resolution process, as Manu has explained
> <https://github.com/w3c-ccg/did-spec/pull/194#issuecomment-489433321>).
>
> So for me, the litmus test should be the following:
> "If a certain matrix parameter helps to construct identifiers (URIs) for
> something that needs an identifier, then that matrix parameter is
> justified".
>
> In other words, "identification" should remain the core aspect of any
> decision for/against individual matrix parameters.
>
> For things like "service-type", I can see arguments either way:
> - Contra: You don't need a "service-type" matrix parameter, because you
> can implement that as a resolver option, or by manually parsing a DID
> Document.
> - Pro: In some cases you do need a DID URL that identifies the set of
> service endpoints of a certain type.
>
> I remember your in-depth analysis
> <https://github.com/w3c-ccg/did-spec/issues/90#issuecomment-439636972> of
> different options for DID URL syntax from a few months ago also had some
> really good thoughts on this.
>
> Markus
> On 6/11/19 4:32 PM, Dmitri Zagidulin wrote:
>
> I agree with the concerns Manu brought up, that we have to be careful to
> prevent a proliferation of reserved matrix params.
>
> I think Drummond hits on a key issue:
>
> > That general capability (for which there can literally be thousands of
> use cases) can't be addressed by parsing DID documents
>
> I think this may be a great litmus test that helps determine whether
> something should be a reserved matrix param (when it's unclear).
> Specifically, if something /can't/ be addressed by retrieving a DID Doc
> and parsing it, it makes more sense to reserve a param.
> And if it can, we should prefer not reserving one.
>
> For example, matrix params that specify a previous version (or a version
> at a particular date in time) of a DID Document? Those cannot be
> implemented via parsing a did doc; that metadata is outside the doc.
>
> Whereas, key type or service type? Is easily implemented by 'fetch the did
> doc, look at the keys or services, look at their types, filter accordingly'.
>
>
>
> On Mon, Jun 10, 2019 at 3:16 AM =Drummond Reed <drummond.reed@evernym.com>
> wrote:
>
>> On Fri, Jun 7, 2019 at 6:40 AM Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>>
>>> Hey Drummond, apologies that many of us couldn't make the call
>>>
>>
>> I know that's not an option for everyone, and that you're putting in
>> double-time to finish the VC spec work.
>>
>>
>>>
>>> On 6/6/19 10:26 PM, =Drummond Reed wrote:
>>> > # Second, we closed on a second matrix parameter: service-type. #
>>> > Third, we had a good, long discussion about the proposed key and
>>> > key-type parameters. We didn't close on them, but we make a lot of
>>> > progress.
>>>
>>> I have very serious reservations about all of the *-type matrix
>>> parameters. I continue to not understand the use cases and why we're
>>> stuffing application-level logic into the DID. The same goes for the key
>>> parameter, which feels like a solved problem (use a fragment id).
>>>
>>
>> This is one of those cases where it really helps to be on the calls. The
>> call notes will help, but the issues that came up were interesting and
>> important enough that IMHO they need a separate writeup. I didn't have time
>> to do that this weekend but I want to get to it in the next 48 hours so we
>> have something to discuss & comment on for this week's DID call, which we
>> agreed to devote entirely to the subject of matrix parameters.
>>
>>
>>> The need for the service parameter is clear, so this isn't a complete
>>> push back against matrix parameters... it's a push back on the growing
>>> list of matrix parameters that seem to have layer violations in them
>>> and/or poorly described use cases.
>>>
>>
>> Just a note RE your mention of "documented use case" below. What
>> qualifies as documented? Where should it be written up/posted in respect of
>> a community spec like this?
>>
>>
>>>
>>> I know it's frustrating to hear this, especially because I haven't been
>>> commenting on the PRs and haven't been able to attend the meetings
>>> (which is why I really appreciate the summaries on the mailing list).
>>> The VC spec is eating up all of my standards effort time, so it's not
>>> due to a lack of interest, but due to being time poor at present. I'm
>>> hoping that will come to a close soon as the VC spec is completed.
>>>
>>
>> Good.
>>
>>
>>> In any case, I just wanted to shoot this out there so that it doesn't
>>> come up as a surprise. Things that would alleviate my concern would be:
>>>
>>> * A documented use case for service-type.
>>>
>>
>> I'm cc'ing Daniel Buchner as he's had the longest-running use case for
>> service-type. Daniel, can you document this use case (ideally per whatever
>> Manu's answer is about the best way to document it).
>>
>>
>>> * A documented use case for key-type.
>>>
>>
>> Several good ones were brought up on the call. I'm hoping Ken Ebert
>> and Mike Lodder are able to document the one they described about key
>> negotiation.
>>
>>
>>>
>>> Once we have those use cases, we can debate whether or not the use case
>>> should be addressed using matrix parameters or good 'ol fashioned "just
>>> parse the DID Document looking for those types" method.
>>>
>>
>> While I get that, the part of that debate that hasn't received as much
>> attention until this matrix parameters discussion is algorithmic
>> construction of DID URLs. That general capability (for which there can
>> literally be thousands of use cases) can't be addressed by parsing DID
>> documents. This came up on the last call and that's what I want to document
>> in more depth.
>>
>>
>>> The underlying concern that I have is that we're over complicating the
>>> base layer (DID URL syntax).
>>>
>>
>> Yes, I understand that concern, and it's a valid one. So far I believe
>> that matrix parameters are a "just right" solution to that complexity
>> tradeoff, but we need to complete the discussion to decide about that.
>>
>> Again, I'll post a link to a writeup on algorithmic construction of DID
>> URLs as soon as I have it ready.
>>
>> =D
>>
>
>