Re: Report on the DID Spec call today

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 <mailto:drummond.reed@evernym.com>> wrote:
>
>     On Fri, Jun 7, 2019 at 6:40 AM Manu Sporny
>     <msporny@digitalbazaar.com <mailto: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
>