DID WG Telco — Minutes

Date: 2020-08-11

See also the Agenda and the IRC Log

Attendees

Present: Michael Jones, Amy Guy, Drummond Reed, Dave Longley, Markus Sabadello, Brent Zundel, Joe Andrieu, Manu Sporny, Justin Richer, Jonathan Holt, Adrian Gropper, Wayne Chang, Oliver Terbu, Daniel Burnett, Kaliya Young, Dmitri Zagidulin, Pamela Dingle, Orie Steele, Phil Archer, Daniel Buchner

Regrets: David Ezell

Guests:

Chair: Brent Zundel

Scribe(s): Michael Jones

Content:

Brent Zundel: Will have a conversation about URL dereferencing

Manu Sporny: Not progressing on the test suite
… Don’t have an ETA
… Will delay our ability to enter CR
… Asking for volunteers with development time

Michael Jones: Wayne Chang volunteered to work on the test suite

Manu Sporny: Was discussed at virtual F2F
… Can also look at VC test suite for an example

Ivan Herman: We don’t need the whole test suite to go to CR

Manu Sporny: I’m hoping we can minimize churn in CR by having a mostly-complete test suite

1. next topic call

Brent Zundel: Sent e-mail asking to reserve space in calendar for next special topic call
… Not clear what the topic will be yet
… Hopefully we’ll know what the topic will be by the end of this call

2. URL dereferencing

Manu Sporny: webauthn: Is the question, do we understand what it is?

Drummond Reed: +1

Michael Jones: 0

Adrian Gropper: I don’t understand the question

Ivan Herman: 0

Joe Andrieu: 0

Adrian Gropper: 0

Dave Longley: 0

Wayne Chang: -0

Markus Sabadello: +1

Dmitri Zagidulin: -0

Manu Sporny: +1 let’s do it! (whatever it is)

Oliver Terbu: +1

Jonathan Holt: 0

Adrian Gropper: what and why?

Manu Sporny: +1 include a section on URL Dereferencing as a formal part of the spec

Drummond Reed: +1

Ivan Herman: +1

Markus Sabadello: +1

Oliver Terbu: +1

Dmitri Zagidulin: -0

Dave Longley: 0

Brent Zundel: Should we include URL dereferencing as part of the spec?

Michael Jones: -0

Wayne Chang: -0

Joe Andrieu: -1

Brent Zundel: We will definitely need to verify the scope
… The purpose of the next block of time is to discuss URL dereferencing

Brent Zundel: https://github.com/w3c/did-core/issues/364

Ivan Herman: +1

Adrian Gropper: Use case?

Markus Sabadello: We have an empty section on dereferencing that we added when we added DID Resolution
… dereferencing is a key part of the Web architecture

Jonathan Holt: jonathan_holt: just to clarify what is DID URL dereferencing. My understanding is that we take a DID URL, chop it up and reattached it to a section in say the service endpoint that is in the DID document to have a full re-concatenated URL with another endpoint that is performed in a deterministic fashion.

Markus Sabadello: It is a means of retrieving the URL content
… Do we want abstract functions again?
… Selecting service endpoints would be out of scope - at least for now

Ivan Herman: +1 for consistency in document issues
… We do define a DID URL
… Someone asked for use cases
… If we do have it, we must say what these are and how they are used
… One doesn’t go without the other

Drummond Reed: As soon as you add a fragment to a DID, you have a DID URL
… You use DID URLs to reference parts of DID documents
… There are more complex URLs that can redirect to a service endpoint

Orie Steele: DID_URL = did:example:123/path/values?query=values#fragment-values

Adrian Gropper: Asked who benefits from DID URL dereferencing

Markus Sabadello: We are already dereferencing DIDs in many cases, for instance VCs
… We resolve the DID to a DID document then use the fragment to select a key

Dave Longley: People may have different opinions about referencing something that is in the document vs. referencing an external resource via services

Joe Andrieu: Dereferencing something in the document versus ??? seem very different

Dave Longley: Dereferencing can refer to DID URLs that reference something internally to the DID Document – or to DID URLs that reference an external resource via service query parameters.

Manu Sporny: We have to put something in to complete this section
… Otherwise this is a half measure
… I also agree with Joe and Dave
… We should have an abstract function defining inputs and output
… We shouldn’t say how this function works internally

Dave Longley: -1 to talking about following redirects to external resources (the service query parameters can talk about what URL is referenced and how that works, but without doing deref text), +1 to talking about referencing things within the DID Document

Ivan Herman: dlongley the way I can translate what you say is that the DID spec should define a fragment id only…

Markus Sabadello: The output of dereferencing a DID is a DID document
… With a fragment, the output can be other things
… Noone has spoken strongly against this

Drummond Reed: To save Mike typing, I’ll just pre-enter my comment that I’m about to share: specifying in the abstract function how a redirect to a service endpoint is done is an essential part of that function. We don’t have to specify the rest of the resolution function, but we do have to specify that much.

Drummond Reed: I totally support specifying the abstract function
… Saying that anything in the DID document can be referenced
… Specify the basic transformation to the DID parameters to dereference something outside the DID document
… Interop requires all implementations doing this the same way
… This is a valuable use of DID URL dereferencing

Markus Sabadello: See DID URL Dereferencing algorithm in the DID Resolutions spec: https://w3c-ccg.github.io/did-resolution/#dereferencing-algorithm

Drummond Reed: (Drummond now has to go to another call)

Dave Longley: +1 to drummond, if we’re going to have “service query params” in the spec, then we should define what they mean and how to interpret them, but do that in that section, and not define all the actual redirection and so on

Ivan Herman: We could keep it simple and define what the fragment means - and that’s all we do
… This could result in a consistent view of the world

Brent Zundel: It sounds like if we can come to consensus on a constrained scope for dereferencing
… that we could also get consensus on having a dereferencing function in the spec

Ivan Herman: Trying to understand what you proposed
… Should it be limited to properties in the DID document?
… If so, the fragment should be specified, and everything else should be informal.

Brent Zundel: Everything else would be method specific.

Markus Sabadello: We can’t change the DID URL syntax to only allow fragments
… People are using DID Parameters in the DID URL syntax
… The dereferencing function would take the DID URL as an input
… It’s not realistic to restrict to just DID+fragment
… We should define the abstract function to allow non-fragment syntax but only define the semantics for fragments
… The non-fragment parameters could be out of scope

Brent Zundel: This is the first of 2 1/2 proposals

Manu Sporny: I tried to split your proposal into two to get focus
… I think Ivan agrees with it
… Could we use the two split proposals?

Brent Zundel: Your second proposal needs to come first

Markus Sabadello: I don’t agree with the “anything else” clause

Brent Zundel: It may just be the HTTP dereferencing

Daniel Buchner: mumbles: we’re gonna need a bigger registry

Proposed resolution: Define how fragment identifiers are dereferenced within the DID Core specification, anything else is defined elsewhere. (Brent Zundel)

Brent Zundel: Is there anyone who would recommend specific changes to the proposal?

Manu Sporny: +1

Daniel Buchner: +1

Dave Longley: +1

Ivan Herman: +1

Orie Steele: +1

Markus Sabadello: +1

Joe Andrieu: +1

Dmitri Zagidulin: +1

Michael Jones: 0

Resolution #1: Define how fragment identifiers are dereferenced within the DID Core specification, anything else is defined elsewhere.

Proposed resolution: Define an DID Dereferencing abstract function with inputs and outputs in the specification. (Brent Zundel)

Manu Sporny: +1

Ivan Herman: +1

Markus Sabadello: +1

Orie Steele: +1

Daniel Buchner: +1

Phil Archer: +1

Dave Longley: +1

Michael Jones: +1

Joe Andrieu: +1

Resolution #2: Define an DID Dereferencing abstract function with inputs and outputs in the specification.

Brent Zundel: That was excellent!
… Is there anything else on dereferencing that we need to discuss today?

Daniel Buchner: Can we talk about having a registry for params?

Manu Sporny: dbuc, the DID Spec Registry already covers DID parameters, IIRC.

Daniel Buchner: ok, then we’re set, assuming they are registered there?

Manu Sporny: dbuc, yes, you register them there.

Joe Andrieu: I’m still trying to understand the impact of this
… (said something about URLs)

Markus Sabadello: This means that we would not define service endpoint selection

Daniel Buchner: Are those the rough high-level things?
… Is this the rough blueprint for the function we’re talking about?: resolveURL(DID_URL) -> resolve doc -> apply registered abstract param functions -> apply fragment selection, if present -> return result

Ivan Herman: We have fragments in DID URLs. The behavior of them is something we care deeply about.
… But if the fragment comes after a bunch of other DID parameters, we probably can’t say what the fragment means or does

Daniel Buchner: I don’t think that’s really true, because fragments that don’t match an ID in a result simply don’t have effect

Daniel Buchner: that’s the way the Web handles it today

Manu Sporny: Daniel and Ivan - you’re exactly right
… We’ll have to some dancing in the PR to address this
… It’s not clear what we’ll say about the complex cases but we can come up with language for this
… Does the DID registry support DID parameters? Yes
… That will tell people how to utilize that DID parameters

Daniel Buchner: For parameter presence in the abstract function, do we need normative language in the parameter registration?

Manu Sporny: It will be difficult for us to have normative language because that presumes that we know what will happen
… We should be vague for the first few years until a pattern emerges

Orie Steele: dbuc i think your spec for your param is responsible for defining that.

Daniel Buchner: orie: I think we have to set some guardrails, because if you don’t, we’ll see nasty collisions

Daniel Buchner: like if one param puts out binary, and is eval’d in the middle of 5 different params, it might brick the rest

Orie Steele: Here is an example of a param spec, that defines such behavior: https://github.com/decentralized-identity/did-spec-extensions/blob/master/parameters/signed-ietf-json-patch.md

Daniel Buchner: we should ensure that we are outputting something every param can at least ingest into its own abstract evaluation space

Daniel Buchner: that could be as simple as the format of the data

Daniel Buchner: like “Your param will be handed JSON, JSON-LD, or CBOR, and must either perform its additional processing or pass through the value to the next param function”

Daniel Buchner: yeah, I think we should mandate failures are silent and purely success-based outputs, else the original input value is passed forward

Daniel Buchner: Basically affect the input data and succeed, or pass without modification

Daniel Buchner: ok, makes sense

Manu Sporny: We don’t have a clear idea of the specifics yet

Markus Sabadello: We see parameters emerging
… Some are method-independent
… Some are method-specific
… Some are mutually exclusive
… We already have language about some of this - fragments

Brent Zundel: The next steps are for someone to raise a PR
… Who is going to submit initial text?
… I would prefer that it be someone other than the editors

Markus Sabadello: I would also prefer if someone else would do this
… There’s existing text in PRs related to resolution, linked from https://github.com/w3c/did-core/issues/364

Brent Zundel: My call for volunteers is still outstanding

Wayne Chang: Please restate the scope of the requested work

Brent Zundel: Write text specifying inputs and outputs for DID dereferencing
… There might be text in closed PRs that we can borrow from

Wayne Chang: I will do that sometime this week

Markus Sabadello: E.g. here is previously proposed text for this section: https://github.com/w3c/did-core/pull/253/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR2693

Brent Zundel: We have 4 minutes left
… I feel like we’ve had an excellent meeting

Joe Andrieu: +1

Orie Steele: +1

Brent Zundel: Thank you to Mike for scribing
… Daniel, show up early next time, because you’re #1 on the scribe list
… We will send e-mail about the upcoming DID topic call

Manu Sporny: +1 thanks brent - we <3 you

3. Resolutions