DID Working Group Telco — Minutes

Date: 2020-04-21

See also the Agenda and the IRC Log

Attendees

Present: Nat Holloway, Brent Zundel, Daniel Burnett, Markus Sabadello, Amy Guy, Daniel Buchner, Manu Sporny, Ivan Herman, Orie Steele, Dmitri Zagidulin, Michael Jones, Dave Longley, Justin Richer, Phil Archer, Joe Andrieu, Paul Madsen, Drummond Reed, Adrian Gropper, Tim Cappalli, Brett McDowell, Kaliya Young, Chris Winczewski, Yancy Ribbens, Jonathan Holt, Joel Hartshorn

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Michael Jones, Manu Sporny

Content:

Brent Zundel: Reviewed proposed agenda

Tim Cappalli: Introduced himself. On the Microsoft identity standards team.

Drummond Reed: Welcome Tim

Brent Zundel: Next topic call at 6pm US Eastern
… E-mail sent last week
… Same zoom link

Brent Zundel: The IRC channel will be did-topic

1. Editorial trust

Brent Zundel: There have been concerns about whether some editorial actions were taken in a trustworthy way
… The chairs have confidence in the editors
… We strive for transparency. Everything is done in public.

Daniel Burnett: I agree

2. DID Resolution

Manu Sporny: Proposal from Justin on DID Resolution
… PRs by Marcus and Justin refined by Manu
… Special call last week on this topic
… The DID Resolution contract is in scope
… Goal to get clarity from the WG that this work is in scope
… We want to be able to write tests for the resolution contract
… Do the chairs want to consider them one-by-one or as a batch

Brent Zundel: Let’s take them in bite size chunks

Justin Richer: I have an alternative proposal for testing ones

Manu Sporny: I have three proposals and then Justin has another proposal

Proposed resolution: It is in scope for the DID WG to normatively define the parameters of a concrete set of processes that take a DID as input and provides a DID Document as output. (Manu Sporny)

Drummond Reed: +1

Manu Sporny: +1

Justin Richer: +1

Ivan Herman: +1

Dave Longley: +1

Daniel Buchner: What is a process?

Phil Archer: +1

Orie Steele: +1

Markus Sabadello: +1

Kaliya Young: +1

Daniel Burnett: +1

Brent Zundel: +1

Michael Jones: +1

Dmitri Zagidulin: +1

Joe Andrieu: +1

Daniel Buchner: +1

Paul Madsen: +1

Tim Cappalli: +1

Justin Richer: @dbuc process is what we define, as I would interpret it, fwiw

Resolution #1: It is in scope for the DID WG to normatively define the parameters of a concrete set of processes that take a DID as input and provides a DID Document as output.

Proposed resolution: It is in scope to normatively define the parameters of a concrete set of processes that take a DID URL as input and provide a resource result as output. (Manu Sporny)

Justin Richer: for the notes, this is my proposed list: https://lists.w3.org/Archives/Public/public-did-wg/2020Apr/0017.html

Ivan Herman: +1

Manu Sporny: +1

Drummond Reed: +1

Michael Jones: No objections heard

Markus Sabadello: +1

Dave Longley: +1

Justin Richer: +1

Orie Steele: +1

Daniel Burnett: +1

Michael Jones: +1

Phil Archer: +1

Daniel Buchner: +1

Brent Zundel: +1

Tim Cappalli: +1

Joe Andrieu: -1

Joe Andrieu: The term “resource result” could have many interpretations, some of which I wouldn’t support

Ivan Herman: +1 to markus_sabadello

Daniel Buchner: When this says ‘parameters’, does it refer to DID URL Parameters, or parameters in some other sense?

Drummond Reed: +1 to what Markus is saying

Markus Sabadello: Clarified

Justin Richer: +1 to markus’s clarification

Manu Sporny: “Resource” is defined in the spec

Joe Andrieu: It’s “resource result” that is the issue

Brent Zundel: Asks if there a concrete proposed modification to the proposal

Michael Jones: ?

Justin Richer: This is intended to include dereferencing
… It’s the thing what comes out the end
… It’s explicitly parameters outside the DID URL itself
… There’s a concept called input options
… It’s within our scope to include these input options

Brent Zundel: I’m giving us 5 more minutes for all of this

Joe Andrieu: There isn’t language including dereferencing that I would support
… But I understand that I’m an outlier on this one
… I might consider a formal objection but I’m trying to understand how to avoid the privacy problems we’re headed towards

Ivan Herman: We are not defining the contracts at this moment
… Simply, if we go in that direction, is it in scope?
… The only thing we’re clearing up here is whether considering this is within scope of the charter

Brent Zundel: Let’s consider the next proposal

Manu Sporny: FAILED RESOLUTION: It is in scope to normatively define the parameters of a concrete set of processes that take a DID URL as input and provide a resource result as output.

Proposed resolution: It is in scope to make these processes take in options and provide back a document along with different classes of metadata (e.g., document metadata and resolution metadata). (Manu Sporny)

Daniel Buchner: What does “take in options” mean?

Dave Longley: “take in options” => additional parameters?

Daniel Buchner: ok, so URL Params?

Markus Sabadello: When dereferencing a URL, there can be additional inputs considered as part of the dereferencing process

Justin Richer: no, not URL parameters

Dave Longley: “additional” here means beyond just the URL, i believe.

Markus Sabadello: For instance, header parameters can influence HTTP URL resolution

Drummond Reed: +1

Manu Sporny: +1

Justin Richer: +1

Ivan Herman: +1

Phil Archer: +1

Markus Sabadello: +1

Dave Longley: +1

Joe Andrieu: +1

Daniel Burnett: +1

Brent Zundel: +1

Michael Jones: +1

Orie Steele: +1

Daniel Buchner: +1

Tim Cappalli: +1

Dmitri Zagidulin: +1

Nat Holloway: +1

Paul Madsen: +1

Resolution #2: It is in scope to make these processes take in options and provide back a document along with different classes of metadata (e.g., document metadata and resolution metadata).

Brent Zundel: Seeing no -1s, this is resolved

Justin Richer: Pointed out a cut-and-paste error in the notes
… Back away from language about how things are tested - just that they are tested

Michael Jones: I asked that Justin paste his language into the chat

Manu Sporny: I will paste it in

Proposed resolution: It is in scope to add tests to the test suite that exercise these processes to test the inputs (DIDs, DID URLs, and input metadata) as well as the outputs (DID Documents, resources, and output metadata). (Manu Sporny)

Ivan Herman: +1

Markus Sabadello: +1

Phil Archer: +1

Justin Richer: +1

Daniel Buchner: +1

Dave Longley: +1

Manu Sporny: +1

Daniel Burnett: +1

Brent Zundel: +1

Brent Zundel: I hear no objections

Tim Cappalli: +1

Orie Steele: +1

Michael Jones: +1

Manu Sporny: Here’s the current test suite – https://w3c-ccg.github.io/did-test-suite/

Joe Andrieu: +1

Daniel Buchner: Probably did:key, I would imagine, if we want to really mail it in

Manu Sporny: Here’s the current implementation report – https://w3c-ccg.github.io/did-test-suite/implementations/

Dmitri Zagidulin: Which DID methods will we be testing?

Brent Zundel: That’s still to be determined
… Seeing no objections, this is resoloved

Resolution #3: It is in scope to add tests to the test suite that exercise these processes to test the inputs (DIDs, DID URLs, and input metadata) as well as the outputs (DID Documents, resources, and output metadata).

Brent Zundel: We have three more of these, which we will consider even though we are over the time originally allocated

Daniel Burnett: The plan is to get resolutions here and then confirm them on the mailing list - because this has to do with the charter

Proposed resolution: It is out of scope to normatively define DID Method specific details of implementing DID resolution. (Manu Sporny)

Manu Sporny: selfissued: I have no idea what this means or how to make it actionable.

Daniel Buchner: Me either

Michael Jones: I do not know what is being ruled in or out of scope.
… This seems like… inputs and outputs are in scope… how are the details in scope or out of scope.

Brent Zundel: I believe it’s the details of DID Method details.

Drummond Reed: This wording doesn’t necessarily say that.
… I think I know what this means, but that’s not what it says

Justin Richer: The keyword is details

Daniel Burnett: Justin said the keyword here was details, but actually the keyword is “DID Method specific details”
… What’s not is scope would be DID Method-specific details

Justin Richer: +1 to brent’s interpretation

Daniel Buchner: We’re not going to impose on DID Methods - that would create a minefield

Drummond Reed: An alternative wording would be, “It is out of scope to normatively define how any specific DID method implements method-specific details of DID resolution.”

Michael Jones: I would propose that we not consider this proposal because the wording is so ambiguous that it ends up being meaningless. Let’s revisit it on another call.

Daniel Buchner: +1 to that wording

Manu Sporny: I suggest we consider Drummond’s wording

Proposed resolution: It is out of scope to normatively define how any specific DID method implements method-specific details of DID resolution. (Manu Sporny)

Daniel Buchner: +1

Manu Sporny: +1

Ivan Herman: +1

Orie Steele: +1

Markus Sabadello: +1

Drummond Reed: +1

Brent Zundel: +1

Dave Longley: +1

Daniel Burnett: +1

Justin Richer: +1

Michael Jones: +1

Joel Hartshorn: +1

Tim Cappalli: +1

Dmitri Zagidulin: +1

Joe Andrieu: +1

Nat Holloway: +1

Resolution #4: It is out of scope to normatively define how any specific DID method implements method-specific details of DID resolution.

Brent Zundel: I hear no objections
… This is resolved

Proposed resolution: It is out of scope to normatively define DID Resolution protocols. (Manu Sporny)

Daniel Buchner: What does that mean?

Michael Jones: Again, I do not know what’s referred to as “DID Resolution Protocols”.

Daniel Buchner: What is an example of the thing exactly that we won’t do?

Brett McDowell: Can we get an example for how each of these proposals would manifest in a real world implementation (as each proposal is discussed)?

Markus Sabadello: We also refer to DID resolver Bindings

Manu Sporny: An HTTP Protocol would be one such example (as out of scope)

Justin Richer: For example, we don’t want to define how to do proxy resolution or make a network call to a remote resolver
… All these are protocol-level things that are up to particular DID method implementations

Drummond Reed: Possible alternative wording: “It is out of scope to normatively define bindings between the DID resolution contract and any specific DID resolution protocols.”

Justin Richer: This is creating layers of abstraction
… We’re not going to assume whether you can make a network call or not

Daniel Buchner: Aside from inputs into the resolution mechanism, all functions internal to it performing that resolution will not be defined by this group?

Michael Jones: Why don’t we reword this to “It is out of scope to specify how DID Methods are implemented”

Justin Richer: Again, this isn’t charter text, this is interpretation of charter text and specifically it is out of scope to define protocol.

Markus Sabadello: Talked about the relationship between bindings and DIDcomm

Justin Richer: It is out of scope to normatively define the details of invoking the DID resolution process and any protocols associated with that implementation.

Michael Jones: WHy don’t we make it simple - it is out of scope to define whether protocols are used for DID Method implementations or to define those protocols.

Michael Jones: I agree with this wording

Proposed resolution: it is out of scope to define whether protocols are used for DID Method implementations or to define those protocols. (Brent Zundel)

Ivan Herman: +1

Brent Zundel: Asked for objections

Daniel Buchner: +1

Phil Archer: +1

Manu Sporny: +1

Drummond Reed: +1

Brent Zundel: +1

Brett McDowell: Are there proposals currently that would be dismissed as out-of-scope as the result of these new “out of scope” statements?

Michael Jones: +1

Joe Andrieu: +1

Dave Longley: +1

Markus Sabadello: +1

Dmitri Zagidulin: +1

Justin Richer: +1

Brent Zundel: Seeing no objections, this one is resolved

Resolution #5: it is out of scope to define whether protocols are used for DID Method implementations or to define those protocols.

Proposed resolution: It is out of scope to test concrete DID Resolution protocols and data formats beyond the necessary process to demonstrate interoperability between the test suite and an implementation. (Manu Sporny)

Justin Richer: I changed protocols to implementations

Ivan Herman: +1

Manu Sporny: +1

Drummond Reed: +1

Dave Longley: +1

Justin Richer: +1

Markus Sabadello: +1

Joe Andrieu: I’m still trying to understand it

Phil Archer: Looks very woolly to me but OK +1

Brent Zundel: +1

Orie Steele: +1

Joe Andrieu: +0

Michael Jones: I agree that this seems wordy

Nat Holloway: +1

Michael Jones: I also agree that it’s fairly vacuous, as dlongley wrote

Phil Archer: Word of the day: vacuous

Resolution #6: It is out of scope to test concrete DID Resolution protocols and data formats beyond the necessary process to demonstrate interoperability between the test suite and an implementation.

Brent Zundel: Seeing no negatives, this is resolved
… This took longer than budgeted but it was time well spent

Manu Sporny: I want us to outline what happens next

Manu Sporny: https://github.com/w3c/did-core/pulls

Manu Sporny: I have attempted to take the PR that Justin did using Markus’ text and split it into multiple different portions

Jonathan Holt: github appears to be down for me. 500 error. anyone else?

Markus Sabadello: justin_r’s PR: https://github.com/w3c/did-core/pull/253 based on my earlier PR: https://github.com/w3c/did-core/pull/247

Manu Sporny: https://github.com/w3c/did-core/pull/262

Manu Sporny: There is a normative section on DID resolution

Manu Sporny: https://github.com/w3c/did-core/pull/263

Manu Sporny: https://github.com/w3c/did-core/pull/264

Manu Sporny: https://github.com/w3c/did-core/pull/265

Manu Sporny: 264 is blocked

Brent Zundel: Asked Joe to look at 264

Phil Archer: I made comments on these. I look forward to responses.

Markus Sabadello: Should we be discussing this in Justin’s PR or in the split ones?

Justin Richer: I am concerned that these are intertwined
… There are comments in 253 that are not reflected in the split ones
… 252 is incomplete

Markus Sabadello: my original PR https://github.com/w3c/did-core/pull/247 will be closed soon, any outstanding content from that one can potentially be re-introduced to the new PRs

Drummond Reed: +1 to working on the split PRs. Thanks to Justin for helping move his PR over.

Justin Richer: It’s going to take effort to ensure that things remain consistent

Manu Sporny: When I split the PR apart, I made sure that the internal references continue to work
… As long as we don’t rename sections, things should keep working
… If something didn’t make it over, let’s bring it in

Brent Zundel: My dream of considering issues has been dashed

3. Regarding issue #204

Phil Archer: See Issue 204

Brent Zundel: This work is closely related to the work that the VC group did
… We will use common terminology unless a specific terminology change is approved by the working group

Justin Richer: +1 for property, property name, property value

Brent Zundel: This is the chairs’ position

Phil Archer: phila: Thanks to selfissued for scribing today

Drummond Reed: Thank you for scribing Mike

Brent Zundel: Thanks us for the good discussion and thanks Mike Jones for scribing
… We will continue some of this on the special topic call today

Orie Steele: github is down.

4. Resolutions