- From: =Drummond Reed <drummond.reed@evernym.com>
- Date: Mon, 10 Jun 2019 00:14:54 -0700
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Credentials Community Group <public-credentials@w3.org>, Daniel Buchner <Daniel.Buchner@microsoft.com>
- Message-ID: <CAAjunnbsbWGpUwdG6eRWsXeoTe8aB7Giqirf5OHTO2J+zry_Nw@mail.gmail.com>
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
Received on Monday, 10 June 2019 07:15:30 UTC