16:00:33 <RRSAgent> RRSAgent has joined #did
16:00:33 <RRSAgent> logging to https://www.w3.org/2020/03/26-did-irc
16:00:33 <brent> invite rrsagent
16:00:52 <brent> rrsagent, draft minutes
16:00:52 <RRSAgent> I have made the request to generate https://www.w3.org/2020/03/26-did-minutes.html brent
16:01:03 <Orie> Orie has joined #did
16:01:06 <brent> rrsagent, make logs public
16:01:29 <Orie> present+
16:01:32 <phila> phila has joined #did
16:01:40 <brent> brent has changed the topic to: DID WG - Parameters Special Call
16:02:51 <brent> zakim, this is did
16:02:51 <Zakim> got it, brent
16:02:56 <Justin_R> present+
16:03:01 <JoeAndrieu> JoeAndrieu has joined #did
16:03:13 <brent> present+
16:03:14 <JoeAndrieu> present+
16:03:15 <phila> present+
16:03:17 <dlongley> present+
16:03:19 <chriswinc> present+
16:03:21 <markus_sabadello> present+
16:03:41 <phila> scribe: phila
16:03:48 <phila> scribenick: phila
16:03:59 <phila> chair: Brent
16:04:11 <phila> brent: Purpose is discussion around DID parameters
16:04:21 <phila> ... I'll run a queue and step in of needs be
16:04:26 <phila> ... there is no set agenda
16:04:37 <Orie> q+
16:04:37 <phila> ... but let's try to come to a resolution
16:04:37 <markus_sabadello> q+
16:04:41 <phila> ack Orie
16:04:42 <brent> ack Orie
16:04:56 <rhiaro> present+
16:05:02 <phila> Orie: It seems as... based on th GH comments that there are 2 proposals
16:05:12 <manu> q+ to get agreement on DID Parameters.
16:05:15 <selfissued> selfissued has joined #did
16:05:17 <phila> ... query strings only; MPs plus query strings
16:05:18 <selfissued> present+
16:05:29 <phila> Orie: So can we get a feel for the balance?
16:05:49 <dlongley> q?
16:05:54 <phila> daniel: I think there's a 3rd...
16:06:17 <dbuc> dbuc has joined #did
16:06:18 <brent> ack markus_sabadello
16:06:20 <phila> ack markus_sabadello
16:06:31 <Orie> suggestion: poll for query string only OR query string + matrix params
16:06:33 <dbuc> Ok, let's just not spend 15 minutes under the wrong impression, because that would be a waste of time
16:06:42 <phila> markus_sabadello: Some background. We had this matrix parameter syntax in the resolution spec before the group got started
16:06:57 <phila> ... this became a disussion, we talked about it at hte F2F
16:07:17 <phila> markus_sabadello: We created a google doc about service selection
16:07:23 <brent> q?
16:07:25 <dbuc> 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
16:07:38 <phila> ... following that, there was more discussion in GH https://github.com/w3c/did-core/issues/159
16:08:07 <phila> markus_sabadello: A question: do we want DID parameters? Params inside a DID URL that control aspects of DID resolution
16:08:10 <dbuc> once you put that issue to bed, then we can get on to the business of which param scheme(s) you want to support
16:08:14 <phila> ... versioning etc.
16:08:25 <phila> markus_sabadello: MPs and Queries both address that
16:08:39 <Orie> +1 to having parameters.
16:08:40 <phila> markus_sabadello: SO my first question - d we want DID parameters at all?
16:08:46 <brent> ack manu
16:08:46 <Zakim> manu, you wanted to get agreement on DID Parameters.
16:08:53 <phila> manu: +1 to Markus
16:09:03 <phila> ... I'm going to propose...
16:09:16 <phila> manu: if we don't agree to that, then we don't have to agree on anything else
16:09:26 <dbuc> +1
16:09:35 <dbuc> In fact, a lack will result in formal objection
16:09:38 <phila> q+
16:09:39 <JoeAndrieu> q?
16:09:41 <JoeAndrieu> q+
16:09:47 <manu> DRAFT PROPOSAL: DID Parameters, regardless of syntax, MUST be defined in DID Core for proper operation of the DID ecosystem.
16:09:48 <drummond> drummond has joined #did
16:09:51 <brent> ack phila
16:09:52 <drummond> present+
16:10:02 <drummond> q?
16:10:33 <drummond> +1
16:10:33 <markus_sabadello> q+
16:10:37 <Orie> +1 to phil's point
16:10:38 <manu> q+ to note that we got objections from W3C Members on resolution being in scope.
16:10:41 <Justin_R> +1 to defining resolution
16:10:44 <phila> phila: gets on high horse about requiring resolutoion as normative
16:10:46 <dlongley> scribe+
16:10:47 <dbuc> What do you feel 'defining resolution' means?
16:10:55 <dbuc> given it could be very different per method
16:10:57 <brent> q?
16:11:08 <dbuc> in terms of the underlying technical workings
16:11:27 <brent> ack Justin_R
16:11:29 <phila> JoeAndrieu: Manu - that proposal seems to imply that there will be params. Are there any cross-method params that we should standardise on
16:11:30 <brent> ack JoeAndrieu
16:11:33 <manu> q+ to note that we already have cross-DID Method params
16:11:39 <brent> ack markus_sabadello
16:11:43 <dlongley> phila: 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.
16:11:49 <dbuc> q+
16:11:59 <drummond> q+
16:11:59 <phila> 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
16:12:01 <manu> q+ to object to expanding scope - let's just not do DID Parameters if that's where this is going to go. We have a spec to finish, we're running out of time.
16:12:25 <phila> ... within the WG, resolution and derferencing hasn't been discussed
16:12:36 <phila> markus_sabadello: Lots of sort out [scribe paraphrase]
16:12:52 <phila> markus_sabadello: 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
16:13:16 <phila> markus_sabadello: We haven't defined how resolution works in the WG
16:13:17 <brent> ack manu
16:13:17 <Zakim> manu, you wanted to note that we got objections from W3C Members on resolution being in scope. and to note that we already have cross-DID Method params and to object to expanding
16:13:20 <Zakim> ... scope - let's just not do DID Parameters if that's where this is going to go. We have a spec to finish, we're running out of time.
16:13:34 <phila> manu: I feel as if we're rapidly expanding the scope of the WG
16:13:58 <phila> ... As DB, I worry about the scope expanding. We might start to object because we're running out of time
16:14:06 <Orie> +1 we don't need all of resolution, but its a method implementer specific thing.... we just need to agree to a format.
16:14:11 <phila> manu: It's starting to feel like a big distraction
16:14:20 <brent> q?
16:14:21 <phila> ... We don't have to expand scope to say that paramsd are useful
16:14:24 <phila> q+
16:14:47 <brent> ack dbuc
16:14:49 <phila> manu: If WG members want to suggest a charter expansion, then OK, but I don't think it will get agreement
16:14:57 <Orie> +1 to dbuc
16:15:04 <phila> dbuc: I want to focus on should there be DID params?
16:15:21 <phila> ... IF we don't get that then we have to think of some other way. I'm working on this 5 days a week
16:15:26 <brent> ack drummond
16:15:59 <phila> drummond: 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
16:15:59 <dbuc> Depends on how far down the resolution rabbit hole we need to go
16:16:11 <phila> ... Params without resolution doesn't seem to make sense
16:16:28 <dbuc> 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"
16:16:30 <brent> ack phila
16:16:35 <phila> I know it's going to be painful. may not bein the scope of today's discussion, but we need this in scope
16:16:51 <dbuc> go beyond that, and it will be a pandora's box
16:16:57 <manu> q+ to note wait, maybe phil and I agree.
16:17:10 <brent> scribe
16:17:13 <brent> scribe+
16:17:18 <brent> phila: 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.
16:17:24 <brent> ... there's a lot of enthusiasm
16:17:27 <dlongley> phila: Just to reassure Manu, I'm not advocating we dont' 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.
16:17:33 <drummond> +1 to finishing DID Core ASAP.
16:17:39 <brent> ack manu
16:17:39 <Zakim> manu, you wanted to note wait, maybe phil and I agree.
16:17:48 <drummond> And then tackling the resolution spec second.
16:17:57 <phila> manu: 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
16:18:07 <Justin_R> q+ to talk about the place of resolution
16:18:28 <phila> manu: officially pulling the work in into the group before we're done with the core, is a mistake
16:18:34 <Orie> +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)
16:18:48 <JoeAndrieu> q+ to refute that foundation
16:18:48 <phila> manu: It's arguable... difficult to say that we don't need DID params
16:19:01 <drummond> +1 to version being a prime example of a generic DID parameter needed across multiple methods
16:19:02 <phila> ... if the foundation is that we need to do resolution I don't think we'll male progress
16:19:08 <brent> q?
16:19:17 <brent> ack Justin_R
16:19:17 <Zakim> Justin_R, you wanted to talk about the place of resolution
16:19:17 <phila> brent: +1
16:19:22 <drummond> Again, can someone post the "proposal"?
16:19:41 <phila> Justin_R: This conversation keeps coming up. Not just because people want to work on resolution, but bc the things that people want to do require resolution
16:20:02 <Orie> DRAFT PROPOSAL: DID Parameters, regardless of syntax, MUST be defined in DID Core for proper operation of the DID ecosystem.
16:20:12 <phila> Justin_R: So I wold caution against rushing ahead wth DID URLs and Docs  - or we're going to end up with assumptions that can't work
16:20:26 <brent> ack JoeAndrieu
16:20:26 <Zakim> JoeAndrieu, you wanted to refute that foundation
16:20:44 <phila> JoeAndrieu: I want to caution us about referring to the existing proposal as dogma
16:21:00 <phila> JoeAndrieu: The work done in CCG and then adopted is a draft that we're working through
16:21:27 <phila> JoeAndrieu: The task I took on at the F2F was to look at MPs from the lens of use cases
16:21:36 <phila> ... I though we had identified a Use Case that required MPs
16:22:07 <phila> ... but there was an implied assumption that turned out that the hierarchical use case needed MPs, but ... select from multiple service endpoints
16:22:15 <Orie> ... we are jumping ahead... we should agree that we will have parameters or not... regardless of format.
16:22:16 <manu> q+ to put forward two proposals -- remove DID Parameters completely and accept that we need them.
16:22:24 <phila> ... We may say we have a use case that requires service endpoints
16:22:26 <brent> ack manu
16:22:26 <Zakim> manu, you wanted to put forward two proposals -- remove DID Parameters completely and accept that we need them.
16:22:31 <markus_sabadello> q+
16:22:41 <phila> manu: It sounds like you have an idea where... there's no information, but I don't know what that is.
16:22:48 <phila> manu: I'd like something concerete to discuss
16:22:57 <phila> ... Are you suggesting that we don't need params at all
16:23:00 <markus_sabadello> The use case document worked on after the F2F: https://docs.google.com/document/d/1ttRWB2lwYSw7bZMRY6wTY9lzGaHcSvOKFYfNZaBBS_4/
16:23:06 <drummond> q?
16:23:28 <manu> q+ to say you keep saying matrix parameters, is that what you mean?
16:23:28 <phila> JoeAndrieu: 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
16:23:49 <phila> JoeAndrieu: There are UCs where they make things easier, but we haven't documented such a UC yet and got consensus on it
16:23:53 <brent> ack markus_sabadello
16:24:15 <manu> q+ to put two concrete proposals forward.
16:24:16 <Orie> +1 to markus's clarification... we should agree to did params in general first....
16:24:27 <phila> markus_sabadello: Are you saying, JoeAndrieu, are you saying we don't have an agreed UC for DID parameters in general? I thought at the F2F that there was unanimous support for it
16:24:29 <selfissued> q+
16:24:54 <phila> JoeAndrieu: We had agreement that the data hierarchical UC seemed like it needed MPs, but only if you want to select from multiple service endpoints
16:24:58 <markus_sabadello> q+
16:25:03 <brent> ack manu
16:25:03 <Zakim> manu, you wanted to say you keep saying matrix parameters, is that what you mean? and to put two concrete proposals forward.
16:25:04 <phila> ... I don't know the use case that jystifies that complexity
16:25:10 <drummond> q+
16:25:21 <phila> manu: I'm putting these down to get a temperature of the room...
16:25:47 <manu> PROPOSAL: DID Parameters do not need to be defined in DID Core for version 1.0.
16:25:50 <phila> manu: proposal one - DID params do not need to be defined in DID core 1.0 (for whatever reason)
16:25:52 <Orie> -1 formal objection from Transmute will follow.
16:25:52 <dbuc> -1
16:25:53 <manu> -1
16:25:57 <phila> +1
16:25:59 <markus_sabadello> -1
16:26:01 <JoeAndrieu> +1
16:26:11 <selfissued> +1
16:26:13 <drummond> -1 formal objection from Evernym will follow
16:26:13 <dlongley> +0 we could reserve them without defining them
16:26:28 <dbuc> Formal objection from Microsoft will follow as well
16:26:28 <phila> brent: When you say DID params, do you mean query and/or MPs?
16:26:31 <phila> manu: Yes
16:26:47 <phila> manu: Let me try again...
16:27:14 <manu> PROPOSAL: DID Parameters, regardless of syntax, MUST be defined in DID Core for proper operation of the DID ecosystem.
16:27:18 <Orie> DID Parameters will be defined in did core (regardless of format)
16:27:21 <manu> +1
16:27:22 <dbuc> +1
16:27:23 <drummond> +1
16:27:24 <Orie> +1
16:27:25 <phila> -1
16:27:27 <selfissued> -1
16:27:29 <JoeAndrieu> -1
16:27:29 <markus_sabadello> +1
16:27:34 <dlongley> +1 at least reserving them
16:27:46 <brent> ack selfissued
16:28:16 <phila> selfissued: 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
16:28:24 <brent> ack markus_sabadello
16:28:27 <phila> ... Tjose things shouldn't be conlfated
16:28:44 <brent> ack drummond
16:28:51 <phila> markus_sabadello: true, Mike. There were diff opinions on how to achieve it.
16:28:51 <manu> q+ to ask if people are talking about matrix parameters or DID parameters? feature or syntax?
16:29:19 <JoeAndrieu> q+ to talk about versioning
16:29:20 <phila> drummond: I've reviewed the doc... it doesn't even talk about versioning. Version params are already in the spec. Evrynym will object if that comes out of the core
16:29:46 <phila> drummond: Saying that we don't need DID params bc they're only about service selection, ignores versioning
16:29:52 <brent> ack manu
16:29:52 <Zakim> manu, you wanted to ask if people are talking about matrix parameters or DID parameters? feature or syntax?
16:29:57 <phila> ... I thought it was in the doc, I'm adding it now
16:30:04 <dbuc> And let's please not hinge everything on GENERIC parameters
16:30:06 <phila> manu: I was confused by what some people said
16:30:19 <dbuc> vs allowing method-specific params of some sort
16:30:21 <phila> manu: There's a big diff between matrix params and DID params
16:31:08 <phila> manu: I remember asking ... I didn't hear any objections to including params at the F2F. We're not talking about syntax
16:31:15 <dlongley> "the mere existence of the ability to specify" requires reserving syntax, IMO.
16:31:21 <phila> manu: I have another proposal in the +ve
16:32:04 <brent> ack JoeAndrieu
16:32:04 <Zakim> JoeAndrieu, you wanted to talk about versioning
16:32:12 <phila> JoeAndrieu: I want to respond to Drummond's comment
16:32:40 <phila> JoeAndrieu: 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
16:32:58 <manu> q+ to talk about use case again
16:33:13 <manu> q+ to note simpler version parameter use case.
16:33:13 <phila> JoeAndrieu: 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
16:33:21 <phila> brent: We're not talking about MPs
16:33:25 <phila> JoeAndrieu: I meant DID params
16:33:27 <drummond> q+
16:33:27 <brent> ack manu
16:33:28 <Zakim> manu, you wanted to talk about use case again and to note simpler version parameter use case.
16:33:29 <markus_sabadello> q+
16:33:36 <phila> manu: let me put a use case forward
16:34:08 <phila> manu: The UC is - I want tobe 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
16:34:33 <phila> manu: We don't want it just in metadata as it can easily get lost/not-transmitted
16:34:37 <JoeAndrieu> q+
16:34:43 <phila> q+ to talk about diff params
16:34:51 <brent> ack drummond
16:35:08 <phila> drummond: I didn't realise that that doc was just about the service param
16:35:37 <phila> drummond: 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
16:35:49 <phila> drummond: if you can't access a specific version, that's a problem
16:35:58 <brent> ack markus_sabadello
16:36:00 <manu> q+ to put counter proposal forward.
16:36:14 <phila> markus_sabadello: I think Manu pointed out an important topic, when we resolve DIDs there are resolver options
16:36:21 <phila> ... Just like we have headers in HTTP
16:36:24 <dbuc> q+
16:36:33 <phila> markus_sabadello: We've always assumed the same for DID resolution
16:36:41 <phila> markus_sabadello: There can eb DID parama
16:37:07 <phila> markus_sabadello: We shouldn't spend too long talking about individual DID parameters, limiting to a single service endpoint etc.
16:37:35 <brent> q+ to ask if this discussion is blocked by lack of clarity around resolution
16:37:40 <brent> ack JoeAndrieu
16:37:58 <phila> JoeAndrieu: A comment triggered by Drummond... what I didn't hear was the value of that test
16:38:13 <manu> q- later
16:38:14 <manu> q- later
16:38:15 <phila> JoeAndrieu: To be able to get a proof that, for example, a credential was issued at a particular time
16:38:28 <phila> JoeAndrieu: You don't know if it was revoked or compromised
16:38:33 <drummond> q+
16:38:37 <Orie> 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.
16:38:41 <phila> JoeAndrieu: I can always reference a previous version
16:39:16 <phila> JoeAndrieu: To me, the structure of teasing out a particular version... we're now saying that there could be differnet versions of that DID doc
16:39:18 <brent> ack phila
16:39:18 <Zakim> phila, you wanted to talk about diff params
16:39:39 <brent> phila: I heard compelling things around pulling the version number into the DID
16:39:46 <Orie> also from the current spec, hl: A resource hash of the DID document to add integrity protection, as specified in [HASHLINK].
16:39:53 <brent> ... to me that is different from parameters used for resolution
16:40:10 <brent> ... which brings us back to needing to talk about resolution
16:40:13 <markus_sabadello> q+
16:40:47 <brent> ... I have no problem with version numbers in DIDs, but have trouble with discussing parameters in absence of talking about resolution
16:40:49 <brent> q?
16:40:52 <Orie> versions in dids are expressed as parameters... in some format (query strings or matrix params).
16:40:54 <brent> ack dbuc
16:40:58 <drummond> 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.
16:41:00 <phila> dbuc: I was trying to stay away from UCs..
16:41:20 <phila> dbuc: In terms of one use case where there is an inextricable linkage to initial state.
16:41:45 <phila> dbuc: There's no assured way of saying that this will resolve...
16:41:51 <phila> [Sorry, losing some of this]
16:42:03 <Orie> please don't bring up any more use cases... we have enough justification, that people want to have did parameters IMO.
16:42:04 <JoeAndrieu> q+ to talk about DID creation time, communication time, resolution time
16:42:10 <phila> dbuc: Sounds like theres some stuff here that could be done but assumes knowledge/methods
16:42:32 <brent> q?
16:42:41 <phila> dbuc: If I don't have a way to do that, then we have to bring into the spec how to pass those details
16:42:43 <brent> ack brent
16:42:43 <Zakim> brent, you wanted to ask if this discussion is blocked by lack of clarity around resolution
16:43:02 <Orie> No
16:43:04 <manu> This conversation isn't blocked by resolution.
16:43:10 <Orie> This conversation isn't blocked by resolution.
16:43:15 <drummond> 0
16:43:17 <selfissued> 0
16:43:17 <phila> brent: is this conversation blocked by our lack of normative work on resolution?
16:43:17 <manu> -1, not blocked
16:43:18 <JoeAndrieu> 0
16:43:22 <dbuc> This conversation isn't blocked by resolution.
16:43:23 <Orie> -1, not blocked
16:43:25 <markus_sabadello> -1
16:43:30 <phila> phila: I think it is blocked in most cases
16:43:35 <dlongley> -1
16:43:48 <phila> drummond: One of the things we talked about was the resolution contract which I think is a minimum
16:43:54 <JoeAndrieu> I think this drives resolution
16:43:59 <JoeAndrieu> -1
16:44:11 <phila> brent: Consensus seems to be that it is not blocked
16:44:13 <brent> ack manu
16:44:13 <Zakim> manu, you wanted to put counter proposal forward.
16:44:18 <phila> manu: So another temperature check
16:44:50 <phila> manu: So the proposal is that DID parameters are removed from DID-core
16:45:00 <JoeAndrieu> +1
16:45:00 <manu> PROPOSAL: Remove DID Parameters from DID Core 1.0.
16:45:07 <dbuc> -1, formal objection
16:45:07 <Orie> -1, Transmute will formally object to the removal of did params from 1.0.
16:45:08 <drummond> -1 with formal objection
16:45:08 <phila> +1
16:45:10 <selfissued> q+ to clarify
16:45:10 <manu> -1 Digital Bazaar would formally object
16:45:22 <dlongley> -1
16:45:36 <phila> drummond: I liked it when we started using DID params to be syntax-neutral
16:45:41 <dbuc> To dumb this down: Passing key/value thingys in a DID URI/URL
16:45:41 <brent> ack drummond
16:45:55 <brent> ack markus_sabadello
16:45:59 <manu> q+ to get FOs to the counter proposal, then move on.
16:46:02 <brent> ack JoeAndrieu
16:46:02 <Zakim> JoeAndrieu, you wanted to talk about DID creation time, communication time, resolution time
16:46:45 <markus_sabadello> q+
16:46:50 <phila> JoeAndrieu: There's something happening here around the fact that we don't have a protocol spec, and so people are advoacting that in the absence of that, we're saying that the URL will be transmitted
16:47:05 <manu> No, that presumes that we care about proptocol wrt. DID Parameters... which we don't. It's about addressing, not protocol.
16:47:06 <drummond> q+ to talk about why identification of resources that is PROTOCOL INDEPENDENT needs to be in the DID URL
16:47:08 <dbuc> 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
16:47:17 <brent> this is why I asked if this discussion was blocked by resolution
16:47:18 <phila> ... 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
16:47:23 <Orie> Time check
16:47:31 <dbuc> IOT devices that never have published DIDs
16:48:05 <dbuc> q+
16:48:17 <phila> JoeAndrieu: 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"
16:48:21 <brent> ack selfissued
16:48:21 <Zakim> selfissued, you wanted to clarify
16:48:25 <dbuc> q-
16:48:57 <phila> selfissued: 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
16:49:04 <Justin_R> I did not misunderstand
16:49:08 <Orie> selfissued https://github.com/decentralized-identity/sidetree/blob/master/docs/protocol.md#unpublished-did-resolution
16:49:10 <Justin_R> I also did not vote
16:49:11 <phila> manu: The entire mechanism
16:49:12 <brent> i understood
16:49:36 <phila> manu: I think you might have been the only one to be unsure with that Mike
16:49:55 <phila> manu: Given that, what wojud your vote be?
16:50:13 <phila> selfissued: I'm frustrated because I agree with some of Joe and Drummond's points
16:50:25 <Orie> 10 minutes remaining.
16:50:29 <dlongley> I also agree with some of Joe's points and some of Drummond's points :)
16:50:33 <phila> selfissued: We're ot doing architecture, we're working on a narrow point, so I find this whole thing frustrating
16:50:34 <dmitriz> dmitriz has joined #did
16:50:47 <brent> ack manu
16:50:47 <Zakim> manu, you wanted to get FOs to the counter proposal, then move on.
16:50:51 <phila> brent: Any proposals for what we should be focusing/moving forward
16:51:01 <phila> manu: I think everyone's getting frustrated
16:51:18 <phila> manu: I think we saw several formal objections if we removed all parameters
16:51:46 <phila> manu: It doesn't mean that anyone's concerns aren't valid but we need to start moving without expanding scope beyond what's possible
16:51:50 <manu> PROPOSAL: DID Parameters, regardless of syntax, MUST be defined in DID Core for proper operation of the DID ecosystem.
16:51:56 <dbuc> +1
16:51:56 <brent> four separate companies indicated they would formally object to removing all DID paramter mechanisms from the spec
16:51:57 <Orie> +1
16:51:58 <manu> +1
16:51:58 <drummond> +1
16:52:01 <JoeAndrieu> -1 maybe
16:52:04 <markus_sabadello> +1
16:52:05 <brent> +1
16:52:06 <phila> 0
16:52:07 <dmitriz> +1
16:52:14 <dlongley> +1
16:52:23 <brent> q?
16:52:39 <brent> ack markus_sabadello
16:52:47 <phila> manu: I think that's clear - we should put DID params in scope and talk about syntax with 7 minutes left
16:53:00 <phila> markus_sabadello: I wanted to respond to Joe's point
16:53:23 <dbuc> 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.
16:53:25 <brent> q?
16:53:33 <phila> 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
16:53:35 <Orie> DRAFT PROPOSAL: DID Parameters will support query string only, NO SUPPORT FOR MATRIX params.
16:53:52 <Orie> DRAFT PROPOSAL: DID Parameters will support query string only AND matrix params.
16:53:54 <brent> ack drummond
16:53:54 <Zakim> drummond, you wanted to talk about why identification of resources that is PROTOCOL INDEPENDENT needs to be in the DID URL
16:53:56 <JoeAndrieu> q+
16:54:01 <dbuc> Is it impossible to do that? No, it's possible just like colonizing Pluto is possible
16:54:20 <phila> drummond: 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
16:55:06 <Orie> 5 minutes remaining.
16:55:09 <phila> drummond: 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
16:55:19 <Orie> manu: please que and go with that
16:55:42 <dlongley> specifying how to reference something is different from saying specifically how to go retrieve it
16:55:43 <manu> q+ to propose two options forward.
16:55:56 <dbuc> YES!!!
16:56:04 <phila> drummond: ... 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
16:56:05 <brent> ack JoeAndrieu
16:56:18 <dbuc> thank you drummond, I will buy you a long-distance crona-isolating drink
16:56:26 <phila> JoeAndrieu: PRs are accepted for the UCs, but we don't have any that demand what you're talking about
16:56:37 <manu> +1 to objecting to security/privacy implications.
16:56:42 <brent> +1
16:56:43 <dlongley> +1
16:56:53 <phila> JoeAndrieu: There are privacy implications here and I may end up raising an FO in future around the harms
16:56:55 <Orie> we are already required to do that by the charter
16:56:56 <brent> ack manu
16:56:56 <Zakim> manu, you wanted to propose two options forward.
16:57:03 <phila> manu: rapid fire proposals
16:57:14 <manu> PROPOSAL: DID Parameters MUST be encoded using matrix syntax.
16:57:16 <manu> -1
16:57:17 <dlongley> -1
16:57:17 <Orie> -1
16:57:18 <dbuc> 0
16:57:19 <phila> -1
16:57:20 <brent> -1
16:57:20 <drummond> 0
16:57:22 <markus_sabadello> +1
16:57:23 <dmitriz> -1
16:57:24 <selfissued> -1
16:57:24 <JoeAndrieu> -1
16:57:38 <manu> PROPOSAL: 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.
16:57:45 <Orie> +1
16:57:48 <markus_sabadello> -1
16:57:49 <manu> +1
16:57:49 <dlongley> +1
16:57:49 <dbuc> +1
16:57:52 <drummond> 0
16:57:57 <dmitriz> +1
16:58:01 <phila> phila: Too much in one proposal to come to a view
16:58:01 <selfissued> +1
16:58:01 <JoeAndrieu> -1
16:58:03 <selfissued> q+
16:58:06 <brent> +1
16:58:20 <brent> ack selfissued
16:58:25 <phila> selfissued: This is a strange question as it conflates 2 things
16:58:30 <markus_sabadello> q+
16:58:46 <phila> selfissued: I think we should just not reserve the ; syntax as it's not part of normal resolution
16:58:48 <manu> Let's discuss that on the next call, selfissued ! :)
16:58:58 <brent> ack markus_sabadello
16:59:03 <manu> yes, and Markus is technically correct :)
16:59:15 <Orie> +1 to markus point..
16:59:16 <phila> 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
16:59:24 <phila> brent: And we're at the end of our time
16:59:35 <phila> ... WE have accomplished enough to go forward to the next meeting
16:59:48 <phila> zakim, close meeting
16:59:48 <Zakim> I don't understand 'close meeting', phila
16:59:55 <phila> zakim, end meeting
16:59:55 <Zakim> As of this point the attendees have been Orie, Justin_R, brent, JoeAndrieu, phila, dlongley, chriswinc, markus_sabadello, rhiaro, selfissued, drummond
16:59:57 <Zakim> RRSAgent, please draft minutes
16:59:57 <RRSAgent> I have made the request to generate https://www.w3.org/2020/03/26-did-minutes.html Zakim
17:00:00 <Zakim> I am happy to have been of service, phila; please remember to excuse RRSAgent.  Goodbye
17:00:04 <Zakim> Zakim has left #did
17:00:12 <phila> RRSAgent, please excuse us
17:00:12 <RRSAgent> I see no action items