Re: Report on the DID Spec call today

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
>