Re: Report on the DID Spec call today

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