— Minutes

Date: 2020-03-26

See also the Agenda and the IRC Log

Attendees

Present: Orie Steele, Justin Richer, Brent Zundel, Joe Andrieu, Phil Archer, Dave Longley, Chris Winczewski, Markus Sabadello, Amy Guy, Michael Jones, Drummond Reed, Daniel Buchner

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Phil Archer, Dave Longley, Brent Zundel

Content:

Brent Zundel: invite rrsagent

Brent Zundel: Purpose is discussion around DID parameters
… I’ll run a queue and step in of needs be
… there is no set agenda
… but let’s try to come to a resolution

Orie Steele: It seems as… based on the GH comments that there are 2 proposals
… query strings only; MPs plus query strings
… So can we get a feel for the balance?

Daniel Buchner: I think there’s a 3rd…

Orie Steele: suggestion: poll for query string only OR query string + matrix params

Daniel Buchner: Ok, let’s just not spend 15 minutes under the wrong impression, because that would be a waste of time

Daniel Buchner: the most major rift presently is some folks wanting parameters that can be used in DID Resolution at all, vs folks who want to eliminate all ability to do so, regardless of what parameters you may implement

Daniel Buchner: once you put that issue to bed, then we can get on to the business of which param scheme(s) you want to support

Markus Sabadello: Some background. We had this matrix parameter syntax in the resolution spec before the group got started
… this became a discussion, we talked about it at the F2F
… We created a google doc about service selection
… following that, there was more discussion in GH https://github.com/w3c/did-core/issues/159
… A question: do we want DID parameters? Params inside a DID URL that control aspects of DID resolution
… versioning etc.
… MPs and Queries both address that

Orie Steele: +1 to having parameters.

Markus Sabadello: So my first question - do we want DID parameters at all?

Manu Sporny: +1 to Markus
… I’m going to propose…
… if we don’t agree to that, then we don’t have to agree on anything else

Daniel Buchner: +1

Daniel Buchner: In fact, a lack will result in formal objection

Manu Sporny: DRAFT PROPOSAL: DID Parameters, regardless of syntax, MUST be defined in DID Core for proper operation of the DID ecosystem.

Drummond Reed: +1

Orie Steele: +1 to phil’s point

Justin Richer: +1 to defining resolution

Phil Archer: gets on high horse about requiring resolution as normative

Daniel Buchner: What do you feel ‘defining resolution’ means?

Daniel Buchner: given it could be very different per method

Daniel Buchner: in terms of the underlying technical workings

Joe Andrieu: Manu - that proposal seems to imply that there will be params. Are there any cross-method params that we should standardise on?

Phil Archer: We should have DID resolution be normative in the spec and take it on in the WG if we’re going to be discussing DID parameters and service endpoints and all that. I could be supportive if we add resolution to the group’s scope.

Markus Sabadello: I agree with Phil that this is closely related to DID resolution. The assumption of this discussion is that we will use them for resolution
… within the WG, resolution and dereferencing hasn’t been discussed
… Lots of sort out [scribe paraphrase]
… Can we make progress on the DID parameters, knowing that there has been a lot of work on resolution but it’s not in the WG
… We haven’t defined how resolution works in the WG

Manu Sporny: I feel as if we’re rapidly expanding the scope of the WG
… As DB, I worry about the scope expanding. We might start to object because we’re running out of time

Orie Steele: +1 we don’t need all of resolution, but its a method implementer specific thing…. we just need to agree to a format.

Manu Sporny: It’s starting to feel like a big distraction
… We don’t have to expand scope to say that params are useful
… If WG members want to suggest a charter expansion, then OK, but I don’t think it will get agreement

Daniel Buchner: I want to focus on should there be DID params?
… IF we don’t get that then we have to think of some other way. I’m working on this 5 days a week

Orie Steele: +1 to dbuc

Drummond Reed: I am going to have to come out as the polar opposite of Manu. I agree with Phil that the reason of parameters are important is that DIDs need to be resolved
… Params without resolution doesn’t seem to make sense

Daniel Buchner: Depends on how far down the resolution rabbit hole we need to go

Daniel Buchner: if all you did was say “These params are DID params, they need to be used by the resolution code to do something, and pulled from any resulting output”

Daniel Buchner: go beyond that, and it will be a pandora’s box

Phil Archer: I know it’s going to be painful. may not be in the scope of today’s discussion, but we need this in scope

Phil Archer: I’m not advocating we don’t talk about resolution, but we need to take it out of the core, and then bring it in.
… there’s a lot of enthusiasm
… Just to reassure Manu, I’m not advocating we don’t talk about DID parameters or resolution. We should just take them out of the call and get the call done and get consensus rapidly then. Parameters become part of the resolution and take it over there. We should take parameters out of the work with core and get core done and then do a rechartering and do resolution.

Drummond Reed: +1 to finishing DID Core ASAP.

Drummond Reed: And then tackling the resolution spec second.

Manu Sporny: That was helpful, Phil, Let’s put it at the end. What I object to, is to put resolution in the middle of all the DID-core stuff
… officially pulling the work in into the group before we’re done with the core, is a mistake

Orie Steele: +1 to manu… we need to agree if we will have parameters… and then what formats… and then what to do with them (or leave that up to implementations, as is the case today)

Drummond Reed: +1 to version being a prime example of a generic DID parameter needed across multiple methods

Manu Sporny: It’s arguable… difficult to say that we don’t need DID params
… if the foundation is that we need to do resolution I don’t think we’ll male progress

Brent Zundel: +1

Drummond Reed: Again, can someone post the “proposal”?

Justin Richer: This conversation keeps coming up. Not just because people want to work on resolution, but because the things that people want to do require resolution
… So I would caution against rushing ahead with DID URLs and Docs - or we’re going to end up with assumptions that can’t work

Orie Steele: DRAFT PROPOSAL: DID Parameters, regardless of syntax, MUST be defined in DID Core for proper operation of the DID ecosystem.

Joe Andrieu: I want to caution us about referring to the existing proposal as dogma
… The work done in CCG and then adopted is a draft that we’re working through
… The task I took on at the F2F was to look at MPs from the lens of use cases
… I though we had identified a Use Case that required MPs
… but there was an implied assumption that turned out that the hierarchical use case needed MPs, but … select from multiple service endpoints

Orie Steele: … we are jumping ahead… we should agree that we will have parameters or not… regardless of format.

Joe Andrieu: We may say we have a use case that requires service endpoints

Manu Sporny: It sounds like you have an idea where… there’s no information, but I don’t know what that is.
… I’d like something concrete to discuss
… Are you suggesting that we don’t need params at all

Markus Sabadello: The use case document worked on after the F2F: https://docs.google.com/document/d/1ttRWB2lwYSw7bZMRY6wTY9lzGaHcSvOKFYfNZaBBS_4/

Joe Andrieu: The use case… we don’t have consensus on a use case that requires MPs. If we did, then, OK, we can look at where the params go
… There are UCs where they make things easier, but we haven’t documented such a UC yet and got consensus on it

Orie Steele: +1 to markus’s clarification… we should agree to did params in general first….

Markus Sabadello: Are you saying, JoeAndrieu, that we don’t have an agreed UC for DID parameters in general? I thought at the F2F that there was unanimous support for it

Joe Andrieu: We had agreement that the data hierarchical UC seemed like it needed MPs, but only if you want to select from multiple service endpoints
… I don’t know the use case that justifies that complexity

Manu Sporny: I’m putting these down to get a temperature of the room…

Proposed resolution: DID Parameters do not need to be defined in DID Core for version 1.0. (Manu Sporny)

Manu Sporny: proposal one - DID params do not need to be defined in DID core 1.0 (for whatever reason)

Orie Steele: -1 formal objection from Transmute will follow.

Daniel Buchner: -1

Manu Sporny: -1

Phil Archer: +1

Markus Sabadello: -1

Joe Andrieu: +1

Michael Jones: +1

Drummond Reed: -1 formal objection from Evernym will follow

Dave Longley: +0 we could reserve them without defining them

Daniel Buchner: Formal objection from Microsoft will follow as well

Brent Zundel: When you say DID params, do you mean query and/or MPs?

Manu Sporny: Yes
… Let me try again…

Proposed resolution: DID Parameters, regardless of syntax, MUST be defined in DID Core for proper operation of the DID ecosystem. (Manu Sporny)

Orie Steele: DID Parameters will be defined in did core (regardless of format)

Manu Sporny: +1

Daniel Buchner: +1

Drummond Reed: +1

Orie Steele: +1

Phil Archer: -1

Michael Jones: -1

Joe Andrieu: -1

Markus Sabadello: +1

Dave Longley: +1 at least reserving them

Michael Jones: I wanted to respond to Markus’ comment about what happened at the F2F. I agree that there was interest in the use case, but I disagree that there was consensus that they required parameters
… Those things shouldn’t be conflated

Markus Sabadello: true, Mike. There were diff opinions on how to achieve it.

Drummond Reed: I’ve reviewed the doc… it doesn’t even talk about versioning. Version params are already in the spec. Evernym will object if that comes out of the core
… Saying that we don’t need DID params because they’re only about service selection, ignores versioning
… I thought it was in the doc, I’m adding it now

Daniel Buchner: And let’s please not hinge everything on GENERIC parameters

Daniel Buchner: vs allowing method-specific params of some sort

Manu Sporny: I was confused by what some people said
… There’s a big diff between matrix params and DID params
… I remember asking … I didn’t hear any objections to including params at the F2F. We’re not talking about syntax

Dave Longley: “the mere existence of the ability to specify” requires reserving syntax, IMO.

Manu Sporny: I have another proposal in the +ve

Joe Andrieu: I want to respond to Drummond’s comment
… I believe … we wanted to unpack one use case that seemed to need MPs. That wasn’t meant to capture all the UCs that might need them
… On the version param specifically… I said let’s talk about the UC. We found that simply having the version param did not meet the use case

Brent Zundel: We’re not talking about MPs

Joe Andrieu: I meant DID params

Manu Sporny: let me put a use case forward
… The UC is - I want to be able to write a DID to a DB entry, some sort of serialisation that conveys the version I used for that DID and I din’t want to separate it from the DID itself
… We don’t want it just in metadata as it can easily get lost/not-transmitted

Drummond Reed: I didn’t realise that that doc was just about the service param
… The oldest UC… is to be able to reference a specific public key at a point in time used for a specific signature and we need to be able to reference that in perpetuity
… if you can’t access a specific version, that’s a problem

Markus Sabadello: I think Manu pointed out an important topic, when we resolve DIDs there are resolver options
… Just like we have headers in HTTP
… We’ve always assumed the same for DID resolution
… There can be DID param
… We shouldn’t spend too long talking about individual DID parameters, limiting to a single service endpoint etc.

Joe Andrieu: A comment triggered by Drummond… what I didn’t hear was the value of that test
… To be able to get a proof that, for example, a credential was issued at a particular time
… You don’t know if it was revoked or compromised

Orie Steele: from the current spec, version-id:id Identifies a specific version of a DID document to be resolved (the version ID could be sequential, or a UUID, or method-specific). Note that this parameter might not be supported by all DID methods.

Joe Andrieu: I can always reference a previous version
… To me, the structure of teasing out a particular version… we’re now saying that there could be different versions of that DID doc

Orie Steele: also from the current spec, hl: A resource hash of the DID document to add integrity protection, as specified in [HASHLINK].

Phil Archer: I heard compelling things around pulling the version number into the DID
… to me that is different from parameters used for resolution
… which brings us back to needing to talk about resolution
… I have no problem with version numbers in DIDs, but have trouble with discussing parameters in absence of talking about resolution

Orie Steele: versions in dids are expressed as parameters… in some format (query strings or matrix params).

Drummond Reed: To be specific, the version number (or any type of version identifier) cannot be “in the DID”, but only in a DID URL. The DID itself must not change over time, i.e. across different versions.

Daniel Buchner: I was trying to stay away from UCs..
… In terms of one use case where there is an inextricable linkage to initial state.
… There’s no assured way of saying that this will resolve…

Phil Archer: [Sorry, losing some of this]

Orie Steele: please don’t bring up any more use cases… we have enough justification, that people want to have did parameters IMO.

Daniel Buchner: Sounds like theres some stuff here that could be done but assumes knowledge/methods
… If I don’t have a way to do that, then we have to bring into the spec how to pass those details

Orie Steele: No

Drummond Reed: 0

Michael Jones: 0

Brent Zundel: is this conversation blocked by our lack of normative work on resolution?

Manu Sporny: This conversation isn’t blocked by resolution.

Orie Steele: This conversation isn’t blocked by resolution.

Manu Sporny: -1, not blocked

Joe Andrieu: 0

Daniel Buchner: This conversation isn’t blocked by resolution.

Orie Steele: -1, not blocked

Markus Sabadello: -1

Phil Archer: I think it is blocked in most cases

Dave Longley: -1

Drummond Reed: One of the things we talked about was the resolution contract which I think is a minimum

Joe Andrieu: I think this drives resolution

Joe Andrieu: -1

Brent Zundel: Consensus seems to be that it is not blocked

Manu Sporny: So another temperature check
… So the proposal is that DID parameters are removed from DID-core

Joe Andrieu: +1

Proposed resolution: Remove DID Parameters from DID Core 1.0. (Manu Sporny)

Daniel Buchner: -1, formal objection

Orie Steele: -1, Transmute will formally object to the removal of did params from 1.0.

Drummond Reed: -1 with formal objection

Phil Archer: +1

Manu Sporny: -1 Digital Bazaar would formally object

Dave Longley: -1

Drummond Reed: I liked it when we started using DID params to be syntax-neutral

Daniel Buchner: To dumb this down: Passing key/value thingys in a DID URI/URL

Joe Andrieu: There’s something happening here around the fact that we don’t have a protocol spec, and so people are advocating that in the absence of that, we’re saying that the URL will be transmitted
… In the UCs, where I get confused about why it needs to be in the URL, as there is a diff when it’s created, communicated and resolved

Manu Sporny: No, that presumes that we care about proptocol wrt. DID Parameters… which we don’t. It’s about addressing, not protocol.

Daniel Buchner: It’s not about having a protocol, it’s about the fact that I would have to define the same thing over all other types of exchange mediums, which is absolutely untenable

Brent Zundel: this is why I asked if this discussion was blocked by resolution

Orie Steele: Time check

Daniel Buchner: IOT devices that never have published DIDs

Joe Andrieu: We’re getting params stuck in the URL so that we can communicate it, but it’s an open-ended for “oh I need this in the protocol so let’s stick it in the URL”

Michael Jones: before people voted on that poll, I was hoping to ask… It wasn’t clear to me whether we were thinking about removing the specific parameters, or the entire mechanism

Justin Richer: I did not misunderstand

Orie Steele: selfissued https://github.com/decentralized-identity/sidetree/blob/master/docs/protocol.md#unpublished-did-resolution

Justin Richer: I also did not vote

Manu Sporny: The entire mechanism

Brent Zundel: i understood

Manu Sporny: I think you might have been the only one to be unsure with that Mike
… Given that, what would your vote be?

Michael Jones: I’m frustrated because I agree with some of Joe and Drummond’s points

Dave Longley: I also agree with some of Joe’s points and some of Drummond’s points :)

Michael Jones: We’re not doing architecture, we’re working on a narrow point, so I find this whole thing frustrating

Brent Zundel: Any proposals for what we should be focusing/moving forward

Manu Sporny: I think everyone’s getting frustrated
… I think we saw several formal objections if we removed all parameters
… It doesn’t mean that anyone’s concerns aren’t valid but we need to start moving without expanding scope beyond what’s possible

Proposed resolution: DID Parameters, regardless of syntax, MUST be defined in DID Core for proper operation of the DID ecosystem. (Manu Sporny)

Daniel Buchner: +1

Brent Zundel: four separate companies indicated they would formally object to removing all DID parameter mechanisms from the spec

Orie Steele: +1

Manu Sporny: +1

Drummond Reed: +1

Joe Andrieu: -1 maybe

Markus Sabadello: +1

Brent Zundel: +1

Phil Archer: 0

Dmitri Zagidulin: +1

Dave Longley: +1

Manu Sporny: I think that’s clear - we should put DID params in scope and talk about syntax with 7 minutes left

Markus Sabadello: I wanted to respond to Joe’s point

Daniel Buchner: Let’s be real: if, to achieve a normalized outcome, I need to go define a means of passing an inextricably linked resolution-required param as a custom mechanism for every exchange medium (HTTP, Bluetooth, NFC, etc.), it’s a nonstarter.

Markus Sabadello: I just wanted to mention that we’ve had a few proposals for DID params that have been rejected because they can be handled with resolver functions

Orie Steele: DRAFT PROPOSAL: DID Parameters will support query string only, NO SUPPORT FOR MATRIX params.

Orie Steele: DRAFT PROPOSAL: DID Parameters will support query string only AND matrix params.

Daniel Buchner: Is it impossible to do that? No, it’s possible just like colonizing Pluto is possible

Drummond Reed: I wanted to make sure it was clear that when Joe brought up the issue… I agree that there’s a pattern about putting stuff in the params in the absence of a protocol
… DID are about a new capability for identity. being able to have an immutable entity identifier - to have that as an anchor point and then be able to use that anchor point to get to sometehing relevant to that
… … and then get into DID doc versions etc… it’s an architectural thing to say that there’s a whole case being able to construct DID URLs that are protocol-independent

Orie Steele: manu: please queue and go with that

Dave Longley: specifying how to reference something is different from saying specifically how to go retrieve it

Joe Andrieu: PRs are accepted for the UCs, but we don’t have any that demand what you’re talking about

Manu Sporny: +1 to objecting to security/privacy implications.

Brent Zundel: +1

Dave Longley: +1

Joe Andrieu: There are privacy implications here and I may end up raising an FO in future around the harms

Orie Steele: we are already required to do that by the charter

Manu Sporny: rapid fire proposals

Proposed resolution: DID Parameters MUST be encoded using matrix syntax. (Manu Sporny)

Manu Sporny: -1

Dave Longley: -1

Orie Steele: -1

Daniel Buchner: 0

Phil Archer: -1

Brent Zundel: -1

Drummond Reed: 0

Markus Sabadello: +1

Dmitri Zagidulin: -1

Michael Jones: -1

Joe Andrieu: -1

Proposed resolution: DID Parameters MUST be encoded using query parameter syntax. Matrix syntax MUST be reserved in the ABNF in DID Core, but not used in DID Core v1.0. (Manu Sporny)

Orie Steele: +1

Markus Sabadello: -1

Manu Sporny: +1

Dave Longley: +1

Daniel Buchner: +1

Drummond Reed: 0

Dmitri Zagidulin: +1

Phil Archer: Too much in one proposal to come to a view

Michael Jones: +1

Joe Andrieu: -1

Brent Zundel: +1

Michael Jones: This is a strange question as it conflates 2 things
… I think we should just not reserve the ; syntax as it’s not part of normal resolution

Manu Sporny: Let’s discuss that on the next call, selfissued ! :)

Markus Sabadello: The URI spec does have the semi-colon for sub-delimiting the primary components of the URI. Nothing wrong with it and it’s not non-standard

Manu Sporny: yes, and Markus is technically correct :)

Orie Steele: +1 to markus point..

Brent Zundel: And we’re at the end of our time
… WE have accomplished enough to go forward to the next meeting