DID Working Group Telco — Minutes

Date: 2020-04-07

See also the Agenda and the IRC Log

Attendees

Present: Amy Guy, Brent Zundel, Manu Sporny, Paul Madsen, Dave Longley, Kyle Den Hartog, Thomas Schwarz, Michael Jones, Ivan Herman, Yancy Ribbens, Justin Richer, Daniel Burnett, Joel Hartshorn, Kaliya Young, Eugeniu Rusu, Drummond Reed, Phil Archer, Daniel Buchner, Joe Andrieu, Tim Cappalli, Dmitri Zagidulin, , Jonathan Holt, Markus Sabadello, Orie Steele

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Manu Sporny, Amy Guy

Content:

Brent Zundel: Going over agenda, cover what Formal Objections means, virtual F2F, a couple of straw polls, then PR, then status check of issues.

Orie Steele: Can we get an updated calendar invite with the correct meeting link?

Brent Zundel: any updates/additions to the Agenda?

Michael Jones: I’d appreciate it if schedule invitation links were sent out to new calls, last schedule has WebEx address which no longer works.

Ivan Herman: The problem is that what Zoom produces and that I could forward to everyone has two flows in it, I can only make it for a year, have to renew in a year, and other issue is that this lounge that we have here, will be used for everything that DID WG wants.
… I can send out calendar for weekly calls, but it’s also same call number for other special calls.

Michael Jones: Not having it in calendar greatly decreases possibility of people finding it.

1. Introductions / Reintroductions

Brent Zundel: Any new folks on the call today?

Tim Cappalli: Hi Tim Capelli, just joined team w/ Daniel and Microsoft, Decentralized is one of my focuses.

Kaliya Young: My name is Kaliya Young, handle is IdentityWoman, been working on identity for 15+ years. I work for Wireline working on decentralized networks, trying to bridge between decentralized networks and this work.
… For example, scuttlebutt uses public keys for everyone in their network, don’t know if that’s the best thing or not. We have the 30th IIW, it’s virtual, same format that we always have, open space, and if you haven’t come and want to, nows your chance because you don’t have to fly this year.

2. Special Topic Call

Brent Zundel: Next special topic call is this Thursday noon eastern time…
… That’s April 9th, 12pm ET - special topic call.

3. What is a Formal Objection?

Daniel Burnett: Just wanted to talk a bit about formal objection, people have used that term on calls a few times, people might not be clear about what that means.
… A formal objection is a step and action that your company, your W3C Member Organization, would take if it’s at the point where they’d block the specification from proceeding.
… This is a statement the entire W3C Membership that you object for a specification to proceed.
… We usually don’t ask that unless there seems to be a strong objection about something. A formal objection is a last ditch effort - official step taken by your organization, toward end of process.

Daniel Buchner: LOL https://www.youtube.com/watch?v=bOnRHAyXqYY

4. Virtual F2F Meeting

Brent Zundel: We have been thinking of organizing a virtual F2F meeting, would people be interested in attending something like that? It would probably consist of 2-3 hours of meetings 2-3 days in a row.

Phil Archer: I’d be there as much as I could, sure

Drummond Reed: Yes, sounds like a good idea. IIW is doing this - 80% of value of being there, if they can do that there, we can certainly do it for a F2F.

Drummond Reed: and drinks! :-)

Brent Zundel: we’ll look into details and chairs will begin planning.

Daniel Buchner: Forget the snacks, who is sponsoring my at-home booze?

Manu Sporny: the virtual f2f - +1 especially if it’s only 2-3hrs out of the day. I do want to be sensitive for people being all zoomed out

Joe Andrieu: TOO MUCH ZOOM

Drummond Reed: “Zoomed out” is a real thing

Manu Sporny: I’ve spoken with a number of people in the wg saying the number of virtual things they’re participating in has skyrocketed
… we should keep that in mind
… the other concern I have is we need a good agenda
… and so my hope is that we have some fairly concrete things to work through
… I’m at a bit of a loss, I don’t know how much progress we’d make if we had those calls like we’ve been having the special topics call and we’ve been making progress there
… just raising those as concerns
… people are getting a bit burnt out by the amount of teleconferencing they’re having to do
… adding another 8 hours in a week doesn’t sound like fun
… but if that’s what’s needed to get the work moving forward, let’s do that

Daniel Burnett: Just wanted to say that while I understand the complain about Zoom, the intent here is to replace a F2F meeting, should replace your other Zoom calls. Participation would be replacing other meetings at that time. Obviously, if we don’t need a meeting, we won’t have a meeting.

Drummond Reed: Wanted to speak in favor of … trajectory of specs, in Amsterdam, breaking back of biggest problems, take remaining issues, give sufficient energy to break through whatever blockers are to that. Organize work for whatever work becomes, final push to finish complete draft that goes into next stage.
… I think it’s something we need to do - 3 hours a day doesn’t have to be disruptive.

Michael Jones: Something for the Chairs to think about, based on, trying to have IETF BOF to create new WG - the huge difference between doing that virtually is that when you’re F2F, you can read people’s body language and get a sense w/o having official questions, know what people are thinking. In AMS Brent and Dan used that to great benefit… tried to steer conversation in productive directions. Virtual F2F will miss that, which is essential to making that work at

Manu Sporny: all. I’m not opposed to doing it, but Brent, Dan, you’re going to have to come up w/ a mechanism to replace that.

Kaliya Young: twinkle hands :)

Michael Jones: I sure hope it isn’t +1/-1 in IRC, otherwise, not nearly productive.

Manu Sporny: I agree w/ Mike.

Michael Jones: It’s hard to get consensus w/o body language.

Brent Zundel: Yes, other helpful parts are side discussions / hallway discussions.

Amy Guy: yeah, having dialled in to real f2fs, there’s a lot missing

Drummond Reed: +1 to Brent’s point about the most productive part of F2Fs is between the sessions

Joe Andrieu: Not a matter of if, juts a matter of when – we don’t know how long this will impact appropriateness of international travel, I don’t think there’s any rush to have one.

Kaliya Young: it is likely to be a long long time 1-2 years.

Manu Sporny: +1 no rush to have one.

Daniel Burnett: Thanks all - just looking for group feedback

5. Straw Poll for DID Parameters / Matrix Parameters

Manu Sporny: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-04-01-did

Manu Sporny: we have had a number of calls at this point talking about did parameters and matrix parameters
… our last call, we had a pretty sharp drop off of people participating to the point where we really couldn’t make a definitive decision to put forward to the group so we’re bringing it to the group now
… there was general agreement that we’re going to support did parameters, they are in scope for the wg
… if you disagree with that you should really let it be known
… but the time to disagree with that has passed
… what we’re trying to figure out now is if matrix params will be in there or not
… there seemed to be more support for using query param syntax vs using matrix param syntax for encoding did parameters
… but when we called the question there were only 5 people weighing in, not enough
… today on the call we need the group to weigh in on an official basis
… if you don’t know what’s going on, i’m deferring to the chairs, but I’d really prefer you do not weigh in and tilt the conversation because it would be an unedcuated vote and those can be very harmful
… if you have been following the discussion, we need you to weigh in
… there were two proposed resolutions on the previous call, we’re going to put them forward again now
… after we get any clarifying questions
… I’m going to emote those in the irc channel so people know what’s coming up
… we will be looking for people to +1/-1 them
… any questions, concerns?

Markus Sabadello: to clarify, manu I think the first proposal doesn’t say that query params would be removed, right? says there will be matrix params AND query params
… the second propsoal says there will be only query params

Manu Sporny: I can change the proposal, I thought we were going to call the same ones

Markus Sabadello: it’s fine, just so people know the first one doesn’t imply query params are going to be removed

Manu Sporny: do the chairs agree?

Brent Zundel: I’m fine either changing it or leaving it the same, as long as that’s the meaning of the first one
… the first proposal is not to remove anything, it would be to use matrix param syntax for encoding did params

Daniel Buchner: Just change it, so we don’t have some inferred understanding

Brent Zundel: if the group prefers more clarified language then do that

Manu Sporny: updated proposal

Drummond Reed: i want to make sure that folks that are not as deep into this but still would have an opinion about it, if the terminology is clear? when using the term DID parameters, we’re talking about any form of params for dids, whether they’re encoded in the query string or the authority component with the ; syntax (in the spec today)
… when we’re talking about matrix parameters we’re just talking about the authority component semicolon
… query params are a special encoding in the query string
… DID parameters are any of the above

Joe Andrieu: I was surprised to see these two exactly as presented because there was pushback structurally on the last call
… there isn’t the option to support query parameters without reserving matrix parameters
… I’d like to see the third option on the table

Manu Sporny: could you type that?

Joe Andrieu: yep

Joe Andrieu: third proposal: Use query parameter syntax for encoding DID Parameters, making no statements about matrix parameter characters at this time

Markus Sabadello: I don’t want to confuse people even more but my understanding of the DID parameters was different than what drummond said
… in my mind DID parameters are ones that we as the WG/registry maintainers specify and that have known behaviour for the did resolution process, things like service selection, versioning and so on
… these ones are did parameters which right now are encoded using matrix parameters, the proposals are about that

Daniel Buchner: I think there’s a simpler way to convey this

Markus Sabadello: we also have query params that are not specified by the WG but are up to the developers and users

Daniel Buchner: yes

Daniel Buchner: exactly

Markus Sabadello: in my mind the DID parameters are the ones we as the WG define and control, and the question is whether those are expressed as matrix or query parameters, with the understanding that there are other parameters that are left to the user

Brent Zundel: this is turning into more of a discussion… come to our call on thursday where we will talk about this

Daniel Buchner: when they say using url parameters for DID parameters, at the top level of your string all the parameters will be resolution-used parameters. They’ll be stripped out and used by the process of resolution. Everything left is a DID parameter, even if it’s not in the specification but tacked on as a method to do something
… the top level string, all the parameters are for the DID itself

Brent Zundel: are we ready for a straw poll?

Orie Steele: +1 to an exhaustive example: did:example:21tDAKCERh95uGgKbJNHYp;service=agent;foo:bar=high/mypath?myquery#myfragment

Manu Sporny: in general this is about expressing the DID parameter, the syntax for expressing the DID param is what we’re talking about
… we’re not talking about if they exist, but how we type them out
… one option is matrix params, the other is query params, that’s what we’re trying to figure out
… do the chairs feel comfortable calling this question? it has been dragging out for 3 weeks
… but it looks like people may still be confused

Brent Zundel: the goal of this topic during this meeting today was a straw poll to gauge the general opinions of the group in order to inform the discussion moving forward
… not to achieve any sort of final resolution

Daniel Buchner: not confused, let’s just vote - we could probably chase our tail on this for weeks/months more

Manu Sporny: joe, does yours need to go in a certain order?

Joe Andrieu: if all three are to be considered as options that’s fine
… the point was to separate the decision to use matrix params from the decision to use query params
… reserving matrix params when we don’t have a use for them seems to be a separable issue

Proposed resolution: Use matrix parameter syntax for encoding DID Parameters with the possibility of also using query parameters. (Manu Sporny)

Markus Sabadello: +1

Dave Longley: -1

Manu Sporny: -1

Orie Steele: -1

Drummond Reed: 0

Michael Jones: -1

Kyle Den Hartog: +1

Joe Andrieu: -1

Daniel Buchner: -1

Brent Zundel: 0

Eugeniu Rusu: 0

Dmitri Zagidulin: -1

Tim Cappalli: -1

Daniel Burnett: 0

Phil Archer: -1

Ivan Herman: 0

Manu Sporny: seeing -1s and 0s, not a lot of +1s

Daniel Buchner: 3 are from our org - have to say that just to be legit about things

Proposed resolution: Use query parameter syntax for encoding DID Parameters, making no statements about matrix parameter characters at this time (Joe Andrieu)

Manu Sporny: note we have another one coming that does make statements about matrix params

Manu Sporny: +0.4

Markus Sabadello: -1

Michael Jones: +1

Drummond Reed: -1

Joe Andrieu: +1

Daniel Buchner: what would the effect of this be?

Orie Steele: unclear

Kyle Den Hartog: -1

Dave Longley: +1

Tim Cappalli: +1

Manu Sporny: this says we’re not going to reserve matrix params

Orie Steele: -1

Manu Sporny: the next one reserves them

Daniel Buchner: +1

Phil Archer: +1

Ivan Herman: 0

Daniel Burnett: -1

Daniel Buchner: sorry, i’ll go 0 to abstain

Manu Sporny: almost half and half

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

Orie Steele: +1

Dave Longley: +1

Daniel Burnett: +1

Daniel Buchner: +1

Drummond Reed: +1

Eugeniu Rusu: +1

Brent Zundel: +1

Manu Sporny: +1

Joe Andrieu: -1

Phil Archer: 0

Markus Sabadello: 0

Manu Sporny: this says we’re going to use query params for DID params but in case we make a mistake we can use matrix params in the future

Kyle Den Hartog: 0

Michael Jones: +1

Tim Cappalli: +1

Ivan Herman: 0

Manu Sporny: joe do you want to talk to your -1?

Joe Andrieu: I already did. Happy to go with consensus

Manu Sporny: this is looking like this is where consensus is
… do chairs want to call it or give 7 days? and we can start putting in PRs for this approach

Brent Zundel: call it

Resolution #1: Use query parameter syntax for encoding DID Parameters, reserving matrix parameter characters for possible use in a future specification.

Manu Sporny: we have 7 days for people not on the call to object and hopefully bring new evidence on why they’re objecting

Orie Steele: what issue tracks this resolution?

Manu Sporny: This clarifies what the editors need to do as a next step

Markus Sabadello: https://github.com/w3c/did-core/issues/159

6. Meeting invitations (redux)

Ivan Herman: Regarding DID WG meetings - quick side bar - don’t use Zoom invite, please use the previous calendar invite I sent out.

Daniel Burnett: Ivan, can you please send a brand new email to the members’ list with the zoom room, etc?

Michael Jones: Can’t you use calendaring system, create manual recurring invitation, then send to WG members list?

Ivan Herman: not sure Apple calendar invite would work for everyone, created more problems than not.

Drummond Reed: It’s true that an Apple calendar invite has interop issues

Michael Jones: Can someone create it and send it out to the WG?

Brent Zundel: I will look into it.

7. DID Resolution Contract PR

Markus Sabadello: PR about DID Resolution: https://github.com/w3c/did-core/pull/247

Markus Sabadello: Just pasted link to new PR about DID Resolution, based on two action items, two topics that came out of F2F meeting… one of the topics was DID Resolution, general sense at F2F meeting that some parts of what is currently covered by DID Resolution spec, not in DID WG in CCG, that some content from that document should be in scope for DID Core spec.
… Interface, DID Resolution… what are inputs, outputs, data structures that we want. From time to time we’ve had discussions in DID Core spec instead of DID Resolution in more detail. What’s the point of defining DID Parameters if you can’t do that in resolution?
… The group wanted to include the contract… DID Resolution, Dereferencing… second topic at F2F is entire metadata discussion, when we have DID Documents but also have certain other pieces of data, didn’t know what to do with them, had this Google Doc at F2F meeting, collected properties, proofs, and other things, had ongoing discussion on go into DID Document or other data structures should go.
… We’ve been trying to discuss what different buckets for those pieces of data should be.

Markus Sabadello: https://github.com/w3c/did-core/issues/65#issuecomment-597030882

Markus Sabadello: This attempts to discuss metadata discussion and DID Resolution discussion, PR 247 - adds content to two sections in DID Core spec.
… these sections have been empty to date, one of that section, DID Resolvers/Resolution - section 3 - overall architecture.

Michael Jones: I wasn’t asking for a hand-crafted ical file, per se. I was asking for a working calendar invitation - to help all the WG members join the calls.

Markus Sabadello: subsection called did resolvers/resolution - PR proposes content there - stating that DID Resolution isn’t a concrete protocol… abstract function that can be implemented in different ways - second section, filled by PR – section 10
… Resolution section has sections that PR adds, resolving a DID, dereferencing… PR doesn’t specify concrete data formats or protocols, abstract functions. Subsections about resolver options and metadata. Doesn’t try to define what data structures look like, JSON, CBOR, how do you express metadata in concrete network protocol, PR doesn’t say that, just says what buckets of metadata are and implements different ways.
… There have already been two -1 comments, suggestions, justin added some fixes/improvements that I’ve incorporated.
… given that it’s significant to input to spec, it would be good to have more discussion and review.

Drummond Reed: Nice work, Markus!

Daniel Burnett: This document is a starting strawman just to get discussion going

Phil Archer: I see text like Implementation details and a concrete algorithm for this function can be found in [[?DID-RESOLUTION]].

Phil Archer: If I were Ivan, I wouldn’t let this PR happen - there are multiple sections that are normative in core spec that talk about resolver as this as input, that as output, that’s very close to a specification.
… As copy in there, it talks about non-normative to normative pointer… we shouldn’t pretend that we’re not putting in details of resolution. I’m considering formal objection on this, it’s bad that we got into this state, either we make this normative, or it’s taken out.

Justin Richer: From my perspective, this is really a good start at getting at things we talked about in AMS - it’s not fully polished, moving in right direction.

Drummond Reed: I have to say I agree with Phil that we need to pull resolution into scope at some point.

Justin Richer: I do think it’s viable to have the definitions of the functions in the spec w/o getting into the details. There are parts of this PR that go into too much detail, and parts that don’t go into enough detail. I’m trying to correct those w/ PRs. Think we can do a little bit more.
… For example, a little too much said on “binding”. The notion of what a binding is and what a binding has to define is important, need that in order to reference this. I do think these bits should be normative - my suggestions was to make this stuff MUSTs instead of SHOULDs. Important to define what resolution output is combination of input+resolution output.
… What I’m calling dereferencer/resolver, get metadata, expect it in a particular form.

Markus Sabadello: Just to also confirm, this is meant to be a start - things to be improved, formal mistakes - non-normative section referencing normative section… trying to understand if this is completely wrong, workable, good direction? Should Resolution be completely out of scope? Or should it be in scope?
… At F2F Meeting, thought we wanted something in between… what do we want? I don’t have a strong opinion, could work either way. Attempt to capture where consensus was.

Brent Zundel: This is a good start, if you want tex to be different, propose different text.

Orie Steele: We have a lot of open PRs with approvals… and a few old / stale PRs with changes requested…

Manu Sporny: I think it’s a good start
… I share phil’s concern and I also share justin’s concern
… and I think that’s why we tried to do something in the middle
… if we start talking in a strongly normative way about the resolution process I think that’s going to be a problem
… resolution is not in scope for the wg
… it’s not in our charter, I know some disagree
… speaking as an editor, it expands our scope beyond what the group signed up to do
… but at the same time I do agree that having some language in there to talk about resolution is helpful, as long as we don’t go too far down the normative rabbithole
… there is also a strong argument for pointing to the did resolution spec in a non-normative way and saying you need to understand did resolution and this document explains it
… we can’t use that language in the spec, i think phil would agree with that more? i would be more comfortable with that
… to be clear, I think markus has done really good work, I don’t think the tetx is going to be destroyed, it’s just where should it belong
… that’s going to be a discussion we end up having over the next couple of weeks
… . I don’t think this needs to turn into an all or nothing thin
… we just need to strike a balance
… please put comments in the PR

Kyle Den Hartog: Speaking from perspective on someone that’s implemented resolution, the thing I’ve cared about most is the contract – what should I be doing w/ the DID vs. DID URL, that’s why I liked how we were defining it w/ contract - question is: Why can’t we define contract to say “when you pass in DID, here’s what you get…” then change DID Resolution spec into an implementation guide.

Daniel Burnett: Manu said some of what I wanted to, but we need to be careful about formally objecting.
… I think we are having a proper discussion about what belongs in this group and what doesn’t, this PR is helping us have that discussion.
… This PR is probably not going to make it in its current state, we’re not going to put in PR that violates charter… but we do want people to have a good discussion about this.

Markus Sabadello: One quick detail, before I did this PR, we already agreed to restructuring of ToC - added two sections w/o adding content - overall architecture - new DID Resolution - please comment on PR, if you disagree on PR and content, or overall structure of spec.
… Do we disagree w/ content, or having those sections at all.

Brent Zundel: Thanks all, end of call, see you Thursday noon ET for special call.

8. Resolutions