- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Thu, 13 Jun 2019 15:56:30 -0400
- To: =Drummond Reed <drummond.reed@evernym.com>, Markus Sabadello <markus@danubetech.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
On 6/13/19 1:11 PM, =Drummond Reed wrote: > 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". I think that might still be too broad. Taken to the extreme, one could argue we need to create a Turing complete syntax for constructing identifiers via DID URLs for things that don't have them. In my view, the purpose of a DID URL is to create a stable reference to existing information about a specific thing, where the precise location of that information may change over time because of changes in the DID Document. It's a pointer. In this light, there are some use cases for DID URLs that make sense to me: --- 1. Suppose you want to reference some information within a DID Document, rather than the DID Document itself. If you could assign it an identifier and include that identifier in a DID URL, you'd have a stable way to reference it. Using a DID URL with a fragment addresses this use case (and it is already a common pattern for other types of resources on the Web), e.g. did:method:abc123#something. A processor that handles a DID URL like this would retrieve the DID Document and then find the resource within it with an `id` that matches the full DID URL. Again, this is already a common pattern on the Web today. For example, browsers will fetch HTML files and then direct the viewport to a specific "anchor" identified by the fragment. 2. Suppose you want to reference what a DID Document looked like at some point in time or at some version. If you could include that time or version information in your DID URL, then you could have a stable reference to how the DID Document looked in the past. We could use matrix parameters like `version-id` and `version-time` to address this use case. 3. Suppose you want a stable reference to some information that may move around on the Web from time to time. If you could create a pointer within a DID Document that could point at the current location of that information, then you could reference that pointer's identifier in a DID URL, thereby creating a stable reference to the information. The use of services with IDs and endpoints to external resources (pointers within DID documents) combined with the `service=<service ID>` matrix parameter can be used to address this use case. In addition, services that have standardized directory structures and/or query parameters, etc. can provide an additional portability benefit through the use of DID URLs. This is because we treat DID URL query params, etc. as opaque, which means they can "pass through" to whatever service endpoint is expressed. --- Where I start to see trouble is with matrix parameters like "service-type". The only thing that a DID URL with `service-type` and no additional matrix parameters could refer to is "the list of services of this type (in the given DID Document)". Furthermore, this is not an existing resource, but rather one that has to be dynamically constructed. Is that a valuable thing to refer to or is it itself only a single parameter to determining what someone is referring to? I would guess that any use cases for this would be treating it as a single parameter. In that case, you need another parameter that indicates how to make a selection from that list or else the reference would not be stable. Of course, then you're specifying some algorithm to run that the DID URL processor must understand. This is an unbounded extensibility problem. It also seems to me, that, if this sort of matrix parameter were supported, then there would be no reason not to say that all manner of combinations of things should be able to be referred to and dynamically constructed as well. What if I want to refer to the collection of all keys of type X and services of type Z at version time Y? Rather, I would think that the use case for selecting a service by type would involve something *more* than a DID URL. The application should handle this. If the application is a service then it could use some other kind of URL like this: https://example.com?id=<DID>&service-type=xxx&preference=yyy But this is beyond the scope of DID URLs. > > 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 > <mailto: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 <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 >> > -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Thursday, 13 June 2019 19:56:56 UTC