DID WG Special call — Minutes

Date: 2020-04-01

Attendees

Present: Daniel Burnett, Manu Sporny, Brent Zundel, Dave Longley, Drummond Reed, Daniel Buchner, Markus Sabadello

Regrets:

Guests:

Chair:

Scribe(s): Manu Sporny

Content:

Daniel Burnett: Why don’t you start us off Markus.

Markus Sabadello: I can give a summary of where we are right now. On the last call we talked about whether or not we wanted DID Parameters.
… We talked about DID Parameters in general, parameters that influence DID Resolution process, part of the identifier itself, service endpoint selection, versioning, whether we need them or not… there is broad support for some kind of mechanism to pass parameters as part of the DID URL, part of the identifier.
… We also have resolver options, separate from that.
… I think people want parameters as part of the DID URL. Right now the spec has the concept of matrix parameters, in ABNF. There is the thing between DID and the path, use key value pairs for service selection… there is a proposal to remove those.
… The argument is: we already have query params, why do we need matrix params? Why do we need both?
… The application that I’ve tried to document or explain during the face to face meeting, and after that, was around service selection service endpoint URLs, motivated by PURLs.
… PURLs are persistent URLs, they can point to different other URLs over time, stable identifier but over time references different resources.
… That’s really why the CCG came up with matrix parameters, in order to use that, you want to be able to select the service from the DID Document w/o using path, query, and fragment, because you want to pass those to service endpoint being selected.
… There are path, query, fragment that are user controlled, very much like how PURLs work in HTTP universe.
… Did some historical digging and found some resources that talk about this - blog post by Phil Windley, stuff created by RWoT, email from dlongley…

Markus reads from an email from dlongley — on need for PURLs and how to do stuff in DID Documents.

Markus Sabadello: https://lists.w3.org/Archives/Public/public-credentials/2019Jun/0028.html

Markus Sabadello: So passing this through to service endpoint.

Markus Sabadello: https://www.windley.com/archives/2019/02/decentralized_identifiers.shtml

Markus Sabadello: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/did-resolution-collected-diagrams.md

Markus Sabadello: (some historical links outlining the service endpoint selection functionality)

Markus Sabadello: More recently, removing matrix params have become stronger, some are wondering if it’s necessary. Dave Longley wrote a thorough and well informed analysis on how this could be done w/o matrix parameters.
… the proposal is to have special query parameters that achieve the same effect. You can have service parameter and path encoded as different query parameters.

Dave Longley: https://github.com/w3c/did-core/issues/159#issuecomment-598286814

Markus Sabadello: The example in the slide deck talks about service, service_path, and version as DID Parameters controlled by DID Core spec.
… … and the registries.

Daniel Buchner: That was my understanding

Daniel Buchner: so at the ‘top-level’ they are all assumed to be DID-tied params

Daniel Buchner: vs prams for anything else

Dave Longley: we probably want “service-path” to be more like “service-relative-ref” so people know they can include fragments, etc.

Markus Sabadello: This is the proposal now, if matrix parameters are removed, this is how it would be

Drummond Reed: If we go the route of DID parameters being DID query params, then IMHO we definitely need a way for DID methods to define method-specific parameter (just as we have done for “matrix”-style parameters)

Drummond Reed: I would call them “DID URL encoded parameters”

Markus Sabadello: In my next comment, I try to argue why matrix params are preferable.

Daniel Buchner: To make sure we’re all on the same page, all the top level parameters in DID URI are DID-specific params… would general idea would be to drop them after resolution? Those parameters wouldn’t appear in generated output?

Markus Sabadello: Yes, that’s my understanding.

Drummond Reed: I wanted to stress that from a spec standpoint, I think we just specify that query parameter strings for DIDs use this DID URL Parameter Encoding, so anything you wanted to pass on to a service or intermediary would be encoded this way, whatever the target of that parameter is, decodes it.

Daniel Buchner: Just want to make sure my base line assumptions are correct.

Dave Longley: Yes to dbuc, there is no pass through. We would define DID Parameters, which we would encode as query parameters, what those do would be in a spec somewhere, there wouldn’t be passthrough in the way that there would be with matrix parameters.

Daniel Buchner: Great, that is what I was assuming/hoping

Markus Sabadello: I can summarize why I – I know there is support for removing – I think there are benefits to matrix params - it’s shorter, easier to read.

Daniel Buchner: Can a URL parameter version be defined such that it combines those two different params into one? Such as: service=files user123/pics/me/png?version=14.6#frag1

Markus Sabadello: two parameters vs. 3 parameters to express same thing… if you want to pass query, fragment to a service, you don’t have to encode… they map directly.
… The second example, it transfers control of the URL components away from DID Controller to spec authors and registries. Like having HTTP spec maintainer registry of allowed paths and query strings in HTTP URLs, there is no central registry. The nice thing about matrix param approach is that the information space is left to DID Controller. In the query string case, we define operations on the DID and structure and the meaning is defined by spec/WG and not left to the DID controller anymore.
… There is a bit of a Web Arch argument.

Daniel Buchner: Can we do something in the URL parameter that provides a domain specific language?

Daniel Buchner: Question: why can’t service and service-path be combine for URL param example –> service=files user123/pics/me/png?version=14.6#frag1

Drummond Reed: I’m not sure if I totally understand the question – I think the Dave Longley proposal for DID URL encoded parameters is that … just as certain web services say URL encode to get through pipeline, we can say the same thing - you can put anything you want in there, you just need to URIEncode whatever that is.

Daniel Buchner: so this would be valid then: service=files:user123/pics/me/png?version=14.6#frag1

Daniel Buchner: and the colon would not be URL encoded

Daniel Buchner: because it isn’t a url encoded char

Daniel Buchner: right?

Dave Longley: The value can be whatever you want it to be provided that it’s URIEncoded.
… You URIEncode some value, that’s how it goes through.
… There could be other delimiters in it, up to who is defining DID Parameter to say what the value is… we can do microsyntax, it’s a matter of defining what that value should look like for the DID Parameter.

Markus Sabadello: They both work

Daniel Buchner: If we did that syntax and used a colon, I don’t think the colon gets encoded, because it’s a reserved char

Daniel Buchner: I think

Daniel Buchner: Reserved characters ; / ? : @ = & (does not include blank space)

Markus Sabadello: it’s great that DID Controller still has control over parameters, but you don’t have control over meaning of query parameters… that would be defined by spec, and that’s where I’m a little hesitant… hand over that information space. Maybe we don’t need actual path anymore… might not need path in DID URL, if we just URIEncode, not sure what a path would do.
… What if you have a path and query parameters… I’m worried that we’ll have complications if we have different levels of passing paths/query/fragment in DID URL.

Drummond Reed: If we go in direction of DID URL encoded params, important that we define parameter that can be extended by DID Methods or DID URL authors… clear way to do that, define syntax for doing that matrix params/semicolon params, it becomes part of encoding rules, we can provide full features of information space.
… Second point, is path even valid, we have to say - is it useful? Can path be used to navigate DID Document itself. DID w/ only a fragment should identify something in DID Document. Seems to me that it would be clear that if you had a DID URL Encoded query, you should not have a non-URL encoded fragment.

Daniel Buchner: I think it should

Dave Longley: https://tools.ietf.org/html/rfc3986#section-3

Dave Longley: We don’t need any paths anymore in DID URL
… There is an example that says that example URIs and component parts … you can see where some foo scheme is being used and URN scheme is being used.
… You can see that path follows scheme, before query fragment, URL parsers, including WHATWG parser, in the path space, it puts in URN. The method and colon delimited thing go into path, query and fragment follow… it’s clean w/ existing parsers - path is colon delimited things that are DID method specific,
… we don’t have any need for any path that uses slashes from that perspective… fits in cleanly w/ URNs and more traditional HTTPs are doing, and we have a purpose for all of those things.

Daniel Buchner: dlongley: can you add an example really quickly to that doc?

Drummond Reed: Very good point, Dave—that the official “path” with DID syntax is in fact the colon-delimited section after the scheme

Daniel Buchner: The service endpoints, same type of service endpoints, but three of them? Path and select using fragment? #frag1, #frag2, and #frag3… and I’d use one of them to select, is that a valid use case?

Markus Sabadello: wrt. removing the path - also agree if we decide to go this way, query parameters, removing path would be right thing to do… that’s what URNs are doing - uses query strings, doesn’t use paths.

Daniel Buchner: dlongley: I mean the doc that the example we see on the screen is in

Markus Sabadello: GS1 identifiers, also don’t support paths. Personally, I think it would be sad if we gave that up. I’ve always liked the symmetry in HTTP URLs, domain plus path query frag… DIDs are path query frag

Daniel Buchner: Wasn’t saying that

Daniel Buchner: oh

Daniel Buchner: but service entries would have IDs

Dave Longley: You would encode the fragment within a parameter value (or perhaps you want to be using a different URL entirely)

Daniel Buchner: so would the frag not be good for matching that?

Dave Longley: you wouldn’t use the top level frag for that.

Drummond Reed: wrt. Daniel’s comment, if you need something more than service name, we decide how to select among multiple services, that would be more acceptable under this mechanism, have defined parameter names in this model.

Daniel Buchner: ok

Manu Sporny: One of the things resonating with me is that this could end out simplifying the overall DID syntax.
…the delimiters for those components could be reserved
…we could achieve two simplifications
…one is eliminating semicolon syntax
…the second is the path
…choose DID encoded query parameters is starting to look like an obvious choice

Daniel Buchner: I agree with Manu - it is uglier in terms of visual appearance, but I now feel like that isn’t enough to justify it

Daniel Burnett: Agree that lack of symmetry is sad w/ new mechanism, but Ivan talking about changing from DID URL to DID Locator, and we decided to not let WHATWG URL only means HTTP URL, if we now make this a URN, do away with paths, do away w/ URL stuff, it increases argument for DID Locator. Something to be aware of.

Dave Longley: we’re doing away with path characters, but there are still path characters.

Drummond Reed: We were coming down to DID URL because it can be used to locate something, what we’d lose from symmetry, we gain from closer parallelism to URNs.
… URN syntax also supports adding things to URN to address within or below resource, so we’ve always had strong parallelism with URNs… URNs on steroids…. it was always an odd duck to begin with.

Dave Longley: path is colon delimited, and rest subsumes it… the only spec that defines a URL is the WHATWG spec.
… Is there an IETF spec that defines URLs?

Dave Longley: https://tools.ietf.org/html/rfc3986#section-1.1.3

Drummond Reed: If we add something to naked DID, if it’s a fragment, you add it, if it’s a service parameter, transform to URL…
… URL, qualified by DID, still appropriate.

Daniel Burnett: RFC3986 defines URL.

Markus Sabadello: Regarding fragment, if you want fragment being passed to service endpoint, fragment will be actual fragment, fragment wouldn’t be encoded in a query parameter… query parameter would have encoded query string, path, fragment would be used, would make more sense, more consistent w/ PURLs and HTTP redirects. Rule of the fragment is it’s always used to dereference a secondary resources.

Dave Longley: “A URI can be further classified as a locator, a name, or both. The term “Uniform Resource Locator” (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network “location”).” <– DID URLs do, in fact, provide a “network location” or a means by which to locate the resource.

Markus Sabadello: That makes this approach less attractive, some parts of final service endpoint encoded in query param, other part is fragment.

Daniel Buchner: I thought we were selecting things out of DID Document… something carrying over seems wrong.

Dave Longley: First point is text in IRC - that was only text I remember coming out of IETF spec… this is exactly what DID URLs do (see text above)
… It’s a stable locator for some other resource on the web, DID URL is the right term, matches IETF, think we should keep query, fragments specific to DID space. The reason we need that is we need to know how to process DID URLs regardless of method.
… DID URLs refer to certain things, regardless of details of DID Method… the only thing between DID URLs is method.

Drummond Reed: +1 to the only difference in two DID URLs referencing a resource should be the method name

Dave Longley: The fact that we’re trying to achieve interop at this level sets us apart from HTTP.

Manu Sporny: wants to make some proposals

Proposed resolution: Use matrix parameter syntax for encoding DID Parameters. (Manu Sporny)

Drummond Reed: 0

Dave Longley: -1

Daniel Burnett: 0

Markus Sabadello: +1

Daniel Buchner: -1, objection would occur only if there was not enough support for URL params

Daniel Buchner: so basically, dependent on the URL vote

Proposed resolution: Use query parameter syntax for encoding DID Parameters, reserving matrix parameter characters for possible use in a future specification. (Manu Sporny)

Dave Longley: +1

Daniel Buchner: +1

Drummond Reed: +1

Daniel Burnett: +0.5

Markus Sabadello: -1

Daniel Burnett: We may want to try to make a consensus call on next Tuesday’s call.

Daniel Buchner: Yeah, URL params this way are definitely ugly, but I think we get to value sooner

Daniel Buchner: and they can technically pull off the same stuff

Drummond Reed: I’m way down the road with matrix params, they’re fine, but what I’ve come to realize is that in the larger world of developers, a simpler adoption path – query parameters encoded in the way we’ve been discussing. Matrix params are great, but adoption path are probably easier w/ URL params.

Daniel Buchner: so that’s why I can’t die on the hill at work

Daniel Burnett: Upon further consideration, I might object if we did NOT reserve path characters and the option for matrix params in the future.

Markus Sabadello: I would never formally object on this - as a WG Member, I don’t have such a strong interest/need for this - not building products/services that need this… reason I’ve put effort into this, as an Editor, one of the obligations is to point out consequences that certain decisions may have… I still feel like something might break w/ query params, where we encode a path, all as one query value… fragment again, entire space, query/fragment

Manu Sporny: reserved for DID spec, we can do whatever we want w/ query string.

Drummond Reed: I agree with @burn that we should reserve both matrix parameters and slash paths for potential future use.

Daniel Burnett: We can’t reserve how fragment works. You are correct

Markus Sabadello: Out of time for that, but I think some things we couldn’t make work - sounds easy, let’s use query params, indirection step, service endpoints, dereferencing, service endpoint construction, I think we’ll run into a problem.

Drummond Reed: Good point, Markus

Daniel Buchner: I can support that

Daniel Burnett: Yes, agree, that’s what we need Editors for… to look out… maybe we suggest that we head in this direction, but if we find some colossal breakdown in that approach, we reconsider this decision.

Drummond Reed: +1

Dave Longley: +1 sure, of course we should be able to move back if we have a big problem

Daniel Buchner: if we find something truly busted, there’s no way we’d block fixing something

Manu Sporny: Yes, if there is new info, we will revisit this decision.

Daniel Burnett: It’s worth in the next call, putting forward the proposal and making clear what the fallbacks are.