15:11:33 <RRSAgent> RRSAgent has joined #did
15:11:33 <RRSAgent> logging to https://www.w3.org/2019/12/03-did-irc
15:11:34 <ivan> rrsagent, set log public
15:11:34 <ivan> Meeting: DID Working Group Telco
15:11:34 <ivan> Chair: burn
15:11:34 <ivan> Date: 2019-12-03
15:11:34 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2019Dec/0000.html
15:11:34 <ivan> ivan has changed the topic to: Meeting Agenda 2019-12-03: https://lists.w3.org/Archives/Public/public-did-wg/2019Dec/0000.html
15:41:08 <burn> burn has joined #did
15:54:29 <ivan> present+
15:55:31 <burn> present+
15:57:42 <TallTed> TallTed has joined #did
15:58:12 <chriswinc> present+
15:59:41 <ivan> present+ tzviya
15:59:55 <ChristopherA> present+
15:59:55 <TallTed> present+
16:00:04 <brent> brent has joined #did
16:00:06 <tzviya> tzviya has joined #did
16:00:12 <brent> present+
16:00:14 <tzviya> present+
16:00:27 <joel> joel has joined #did
16:00:36 <Orie> Orie has joined #did
16:00:36 <joel> present+
16:00:42 <Orie> present+
16:00:44 <markus_sabadello> markus_sabadello has joined #did
16:01:25 <dlongley> present+
16:01:28 <dezell> dezell has joined #did
16:01:31 <phila> phila has joined #did
16:01:49 <phila> present+
16:01:53 <Orie> Can someone TL;DR how to scribe in case I am called on...?
16:02:00 <dezell> present+
16:02:13 <ahripak> ahripak has joined #did
16:02:19 <daniel> daniel has joined #did
16:02:31 <ahripak> +present
16:02:40 <manu> present+
16:02:42 <brent> scribe+
16:02:45 <manu> present+ ahripak
16:02:50 <burn> Topic: Agenda Review, Introductions, Re-introductions
16:02:55 <Justin_R> Justin_R has joined #did
16:02:57 <brent> topic: agenda review, intros
16:02:59 <manu> s/Can someone TL;DR how to scribe in case I am called on...?//
16:03:01 <Justin_R> present+
16:03:07 <jonathan_holt> jonathan_holt has joined #did
16:03:19 <manu> q+ to make small announcement about public keys discussion, during that part of the agenda.
16:03:27 <jonathan_holt> present+ jonathan_holt
16:03:28 <brent> burn: agenda reviewed, anything else folks want to add
16:03:31 <burn> ack manu
16:03:31 <Zakim> manu, you wanted to make small announcement about public keys discussion, during that part of the agenda.
16:03:34 <sumita> sumita has joined #did
16:03:39 <brent> manu: public keys announcement
16:03:43 <burn> q?
16:03:46 <brent> burn: anything else?
16:03:56 <brent> burn: anyone here for the first time?
16:04:27 <rhiaro> present+
16:04:29 <drummond> drummond has joined #did
16:04:30 <brent> tzviya: this is my first time.  I'm with Wiley, I've worked on the VC group, interested in identity management in particular. I work with Benjamin
16:04:37 <drummond> present+
16:04:42 <mike-lodder> mike-lodder has joined #did
16:04:45 <brent> burn: thank you, that's great
16:04:48 <mike-lodder> present+
16:04:54 <brent> burn: anyone else here for the first time?
16:05:18 <yancy> present+
16:05:55 <burn> q?
16:06:02 <daniel> present+
16:06:22 <brent> burn: reintroductions, how about Phil, would you be willing?
16:06:31 <selfissued> selfissued has joined #did
16:06:42 <sumita> present+
16:06:43 <selfissued> present+
16:07:08 <brent> phila: formerly W3C, now at GS1, barcode folks, supermarkets, cross-border shipments, our interest here is increasing the security and provabulity of our identifiers
16:07:08 <burn> Topic: Announcements: Next key format call. Use Cases FPWD published, VCWG Maintenance charter vote
16:07:29 <manu> q+ to speak to some PRs for key management
16:07:30 <burn> DID Key Management call:  https://lists.w3.org/Archives/Member/member-did-wg/2019Dec/0000.html
16:07:35 <tplooker> tplooker has joined #did
16:07:37 <ChristopherA> q+
16:07:47 <brent> burn: first announcements: key format discussion will be December 4 at Noon ET
16:08:00 <burn> ack manu
16:08:00 <Zakim> manu, you wanted to speak to some PRs for key management
16:08:13 <agropper> agropper has joined #did
16:08:20 <brent> manu: during our last public keys call, there were some suggeestions for refinements around the language. I have made those.
16:08:46 <agropper> present+
16:09:00 <brent> ... I believe the text reflect consensus as of now. My hope is that during the next call we can come to consensus on pulling the PRs in.
16:09:28 <brent> ... there may be some additional changes around base58 vs base64url. Please read the updated PRs.
16:09:47 <brent> ... If you have objections to them, please raise those objections before the call.
16:10:06 <dmitriz> dmitriz has joined #did
16:10:07 <brent> ... My hope is that we can pull the PRs in during the call and then shift to other topics.
16:10:11 <dmitriz> present+
16:10:11 <burn> ack ChristopherA
16:10:43 <brent> ChristopherA: Want everyone to hold the date of MArch 16-20, Buenos Aires, RWoT
16:10:46 <burn> DID Use Cases FPWD Note:  https://www.w3.org/TR/did-use-cases/
16:11:03 <brent> burn: also, we want to remind everyone our FPWD for Use cases was published.
16:11:26 <burn> VCWG Maintenance charter vote:  https://www.w3.org/2002/09/wbs/33280/vcwg-2019/
16:11:43 <brent> ... also, the re-starting of the VCWG as a maintainence group. Please remind your AC reps to vote in favor of that group
16:12:02 <burn> Topic: F2F: boat tour sponsor, # attendees, topics
16:12:17 <brent> burn: we need a sponsor for the boat tour.
16:12:31 <brent> ... hopefully after we get a count we can get that.
16:12:47 <ivan> q+
16:12:53 <brent> ... Microsoft is graciously hosting our location, with meals and snacks
16:13:02 <burn> F2F topics/attendance:  https://docs.google.com/spreadsheets/d/11haGLiY3AYi8uxIQcfndAixmtXjymNTTFbDQWRYkKrQ/edit#gid=0
16:13:20 <brent> ... the chairs put together a draft agenda for F2F topics and attendance
16:13:30 <brent> ... if you expect to attend, please add your name
16:13:49 <brent> ... also, if you have any special requirements, add those on the attendees tab
16:14:10 <brent> ... on the agenda tab, scroll down to the yellow section where you can add potential topics of interest.
16:14:23 <burn> ack ivan
16:14:25 <brent> ... the chairs will figure out where they go in the agenda itself.
16:14:44 <brent> ivan: back to the boat tour, ballpark figure is 20 euros per person
16:14:52 <brent> ... if you can sponsor it.
16:15:18 <brent> ... pleae put in attendance so I can call the company and let them know soon how many will be there.
16:15:51 <brent> burn: quick check on irc, please indicate if you are planning to be there
16:15:52 <burn> I will be there
16:15:53 <ivan> will be there
16:15:55 <brent> I will be there
16:15:58 <dezell> will be there
16:16:00 <selfissued> I will be there
16:16:00 <ChristopherA> maybe
16:16:04 <drummond> will be there
16:16:06 <burn> q?
16:16:17 <yancy> planning to be ther
16:16:27 <yancy> /s/ther/there
16:16:44 <brent> burn: one other thing: Mike Jones sent the instructions for getting to the meeting to the mailing list
16:16:52 <burn> Topic: Rubric document: when to publish FPWD Note?
16:16:53 <brent> ... they are also on the F2F meeting page
16:16:54 <TallTed> highly unlikely to be physically present. will try to join remotely by whatever tech is available.
16:17:17 <burn> https://www.w3.org/2019/09/did-wg-charter.html
16:17:31 <brent> burn: We also agreed to publish a rubric. The charter says we will publish a first draft in december
16:17:57 <gannan> gannan has joined #did
16:18:04 <brent> ... the chairs feel that is unlikely, especially since this call is scheduled for Christmas day and new year's day (so it will be cancelled).
16:18:17 <brent> ... can anyone speak to when they think we might get something together?
16:18:25 <selfissued> Instructions on how to get to the Amsterdam meeting location (in Dutch and English): https://lists.w3.org/Archives/Public/public-did-wg/2019Dec/att-0003/Routebeschrijving_SpacesSchiphol.docx
16:18:30 <brent> drummond: I am one of the folks helping work on that.
16:18:54 <brent> ... We have made steady progress, January is pretty likely for a FPWD
16:19:37 <brent> markus_sabadello: There have been regular calls with a small number of people. It still needs some cleanup before publishing as a note
16:19:56 <brent> ... maybe one or two more calls with that DID Rubric group
16:20:04 <markus_sabadello> Current state of DID Rubric work: https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/
16:20:08 <brent> burn: please add a link to the google doc
16:20:40 <brent> ... the rubric is a collection of criteria to help folks determine the level of decentralization of a particular DID method
16:20:51 <brent> ... Is it decentralized for your use case
16:21:03 <brent> burn: it must be converted into respec
16:21:08 <rhiaro> markus_sabadello: I'm happy to do the respec stuff when needed
16:21:35 <brent> ... work on a google doc does not cut it. So until the doc is in respec and the doc is in our github repo it doesn't count
16:22:02 <burn> q?
16:22:06 <brent> ... doing that will create a first document (not a FPWD) please get that in soon. Thanks for the update
16:22:20 <burn> Topic: Matrix Parameters
16:22:28 <derekmac> derekmac has joined #did
16:22:31 <burn> https://github.com/w3c/did-core/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+matrix
16:22:48 <markus_sabadello> q+
16:23:06 <burn> ack markus_sabadello
16:23:06 <brent> burn: turn the call over to markus_sabadello
16:23:21 <brent> markus_sabadello: quick intro to matrix parameters
16:23:38 <ivan> -> https://w3c.github.io/did-core/#generic-did-parameter-names DID parameter names in the core draft
16:23:44 <brent> ... matrix parameters are a syntactic construct we can use in DID urls
16:24:07 <brent> ... we can accross it as a way to reference specific service endpoints
16:24:40 <brent> ... the DID Core spec doesn't tell you exactly which fragment to select
16:25:08 <brent> ... the service endpoint can be specified with the matrix parameters, then the query fragemnts can be used by that service endpoint
16:25:29 <brent> ... other examples are versioning, version-time, etc.
16:26:03 <brent> ... also want to add, we don't want to overuse matrix parameters, because we also have the idea of resolver options (separate from the DID url)
16:26:14 <ivan> q+
16:26:22 <brent> ... that doesn't need to be a matrix parameter, but could be passed separately to the resolver.
16:26:30 <manu> q+ to note other concerns around matrix parameters and general design patterns of when to use them.
16:26:47 <brent> ... but they are an interesting construct for adding capabilities to the dereferencing the DID url
16:27:05 <burn> q?
16:27:07 <burn> ack ivan
16:27:10 <brent> ... there are currently a number of matrix parameters in the spec already, more are proposed
16:28:05 <brent> ivan: clarification question, from a semantic web background, a url is used for identiciation. so if two different urls have different identifiers they are completely different identifiers.
16:28:24 <markus_sabadello> q+
16:28:29 <brent> ... what do we say? is adding a matrix parameter create a different identifier entirely?
16:28:29 <drummond> q+
16:28:33 <burn> ack manu
16:28:33 <Zakim> manu, you wanted to note other concerns around matrix parameters and general design patterns of when to use them.
16:28:37 <dlongley> q+ to respond to ivan
16:29:07 <markus_sabadello> q-
16:29:20 <brent> manu: I want to bring up some concerns. Matrix parameters, the syntax comes from the early days of the web. They were considered but never really used.
16:29:40 <Orie> Historical context, circa 1996: https://www.w3.org/DesignIssues/MatrixURIs.html
16:29:51 <brent> ... now we are resurrecting them, but haven't really said why. What do regular URLs not allow that matrix parameters do?
16:30:24 <markus_sabadello> q+
16:30:27 <yancy> +1 to concern of using matrix params
16:30:31 <brent> ... every time a new matrix parameter is recommended, it is concerning because we don't have a good design pattern for when to use it or not. there is still a bit of controversy around when to use them
16:30:34 <drummond> Strongly stated as the reason we are using them: we want to be able to control what a DID URL identifies in the authority component of the URI so that we can leave the path, query, and fragment components completely free for DID URL authors to use.
16:30:55 <brent> ... as far as Ivan's question, we have to treat URLs that vary in matrix parameters as different IDs
16:31:28 <brent> ... they point to a very specific instance of a thing at a particular point in time, which may be different from that thing over all of time. just something to keep in mind
16:31:38 <burn> ack drummond
16:31:51 <brent> burn: I had understood that the editors wanted to go over PRs. I will handle queue
16:32:12 <brent> drummond: there is a very specific structural reason for matrix parameters.
16:32:31 <burn> s/PRs./PRs, but if this is a general discussion/
16:32:42 <burn> q?
16:32:56 <brent> ... the general rule of a URL is the scheme is the authority level for the URL. we wanted the path, query and fragment identifier to be free for the methods.
16:33:26 <brent> ... the matrix parameters are for identifying other resources, which is why they are in the authority component.
16:33:50 <ivan> q+
16:33:51 <manu> q+ to ask drummond and markus if that's the only reason, and if so, can we put that in the spec as THE reason and build the logic from there...
16:33:55 <brent> ... to have control over specification, you are aways identifying some other resource with a different identifier.
16:34:14 <burn> ack dlongley
16:34:14 <Zakim> dlongley, you wanted to respond to ivan
16:34:20 <brent> ... from my standpoint both the motivation and structure are clear. So we should talk about specific matrix parameters
16:34:41 <daniel> q+
16:35:08 <brent> dlongley: Each of these URLs is a different identifier. vanilla DID is the DID subject, adding a matrix parameter refers to something else, possible the DID subject at a certain time.
16:35:18 <manu> q+ to also be clear that I'm not arguing against using them, just that they give me the heebie jeebies.
16:35:20 <daniel> I was not under the impression that the presence of a matrix param meant that the base DID and the DID with the param are to be seen as two different DIDs
16:35:37 <daniel> Why is this the case?
16:35:56 <markus_sabadello> @daniel not two different DIDs, but two different URLs
16:35:59 <daniel> Why can't a matrix param simply aid in some aspect of resolution of the same base DID
16:36:02 <daniel> ok
16:36:11 <brent> ... the original use case for matrix parameters was to allow people to refer to things.. Did Docs have services, suych as the DID subject's social media stream, or some other service. The DID subject or controller may want to change those services over time.
16:36:53 <brent> ... the matrix parameters could refer to those services over time, some resource that lives on that server, like facebook or twitter. this would be for creating self-sovereign storage and credential wallets.
16:37:02 <burn> ack markus_sabadello
16:37:07 <brent> ... there's a lot of contextual information in the communtity
16:37:21 <agropper> q+
16:37:44 <brent> markus_sabadello: I want to agree with Dave and Drummond on when to use matrix parameters and when to not. You use them when yuou need a way to identify a different resource.
16:37:49 <drummond> @daniel: one bright line with matrix parameters is that they always identify another resource besides the unadorned DID subject. So they should be used for identification purposes, not for controlling resolution.
16:37:50 <ChristopherA> q+
16:38:14 <brent> ... for example indicating when something is using a cached copy wouldn't use matrix params.
16:38:15 <ChristopherA> q-
16:38:26 <dlongley> another way to think about it is like w3id.org ... a perma ID redirection service...
16:38:30 <burn> ack ivan
16:38:31 <phila> q+
16:38:42 <brent> ... kind of like http headers would be resolver options and also wouldn't be matrix params
16:38:52 <brent> ivan: these should be emphasized more in the doc.
16:39:00 <brent> drummond: I agree that needs to be added
16:39:02 <dlongley> where the redirection in this case happens via changes to a DID Document's service's endpoint
16:39:08 <brent> burn: is that an action on you?
16:39:08 <ChristopherA> Especially what DOESN’T belong
16:39:14 <brent> drummond: Yeahm I guess
16:39:30 <burn> ack manu
16:39:30 <Zakim> manu, you wanted to ask drummond and markus if that's the only reason, and if so, can we put that in the spec as THE reason and build the logic from there... and to also be clear
16:39:33 <Zakim> ... that I'm not arguing against using them, just that they give me the heebie jeebies.
16:39:37 <brent> ACTION: drummond add more clarity on when matrix params should be used and when not
16:39:40 <drummond> +1 to Markus' point that matrix parameters correspond to what would go into an HTTP URL and resolution parameters correspond to what would go into HTTP headers.
16:40:23 <phila> q-
16:40:29 <burn> ack daniel
16:40:30 <brent> manu: we need this for DID implementors who don't have our tribal knowledge. We need to clearly define where they came from, why we are using them now, and some rules around when you should use them and when you shouldn't
16:40:33 <markus_sabadello> there is a green NOTE box here that explains when to use them, but i agree that should be emphasized more: https://w3c.github.io/did-core/#generic-did-parameter-names
16:40:44 <burn> ack agropper
16:40:57 <dlongley> URL `foo` refers to some resource ... and a DID controller can change the server where that resource lives without the URL having to change.
16:41:13 <dlongley> ^matrix parameter use case
16:41:25 <brent> agropper: privacy reltaed question: with a peer did where we have a service enpoint that we don't want to be a point of correlation
16:41:38 <brent> ... would the matrix param apply in this context?
16:41:42 <burn> q?
16:42:08 <drummond> q+
16:42:08 <ivan> s/reltaed/related/
16:42:12 <burn> ack drummond
16:42:13 <brent> manu: I think we don't know yet. It depends on your definition of correlation, etc.
16:42:46 <brent> drummond: I think if you apply what we were saying earlier, if it is only about routing or resolution, that doesn't change the resource being identified
16:42:56 <brent> ... so you wouldn't use a matrix param
16:42:59 <ChristopherA> q+
16:43:03 <manu> q+ to note that privacy engineering needs concrete use cases to analyze.
16:43:09 <manu> q-
16:43:16 <burn> ack ChristopherA
16:43:16 <brent> ... maybe if you're saying its an anonymous version of the identifer ...
16:43:39 <manu> q+ to note that privacy engineering needs concrete use cases to analyze.
16:43:57 <brent> ChristopherA: I wanted to add that it is a privacy concern whether or not the service endpoint recieves the entire DID URL or whether they only receive the content hash.
16:44:08 <manu> q+ to note that we need attack models, and then move on to specific PRs.
16:44:15 <markus_sabadello> q+
16:44:25 <brent> ... as you pass this information on, the client doesn't include the full DID information once they've resolved the matriz param.
16:44:59 <dlongley> wrt to services, matrix parameters don't say anything about service endpoints "receiving" information, they just map one URL to another.
16:45:03 <ivan> s/matriz/matrix/
16:45:04 <brent> ... transitioning or changing services without the identifier changing. There is a privacy concern that implementors will need to keep in mind
16:45:06 <burn> ack manu
16:45:06 <Zakim> manu, you wanted to note that privacy engineering needs concrete use cases to analyze. and to note that we need attack models, and then move on to specific PRs.
16:45:40 <brent> manu: this is a bit cvart before hte horse. We need use cases and modeling before we can do threat and privacy risk modeling
16:45:51 <brent> s/cvart/cart/
16:45:52 <ivan> s/cvart/cart/
16:45:59 <manu> https://github.com/w3c/did-core/pull/59
16:46:04 <manu> did:example:1234;key=mykey
16:46:20 <brent> manu: Let's pick PR 59, relatively easy. suggestion for a "key" matrix parameter
16:46:22 <burn> ack markus_sabadello
16:46:25 <daniel> or issue 70!
16:46:30 <daniel> and*
16:46:40 <brent> markus_sabadello: I agree, let's look at concrete parameters
16:46:44 <dlongley> q+ to say -1 to this PR
16:47:25 <ChristopherA> -1 agree with dlongley.
16:47:32 <burn> q?
16:47:36 <burn> ack dlongley
16:47:36 <Zakim> dlongley, you wanted to say -1 to this PR
16:47:37 <brent> markus_sabadello: key has been suggested as a way to select a particular key (similar as they way the service endpoint could be identified with a serivce matirx parameter
16:47:50 <ivan> i/https:/subtopic: Issue #59/
16:48:04 <brent> dlongley: If you want to refer to something that has an id in the document, we already have a way to do that.
16:48:05 <daniel> Tell me how to pass intermediate state values that can be dropped after anchoring
16:48:09 <Orie> -1 seems like a use for JsonPath... https://goessner.net/articles/JsonPath/
16:48:14 <markus_sabadello> example: use did:ex:1234#keys-1 instead of did:ex:1234;key=keys1
16:48:18 <brent> ... not in my view what matrix parameters are for.
16:48:26 <brent> ... generally for things outside of the DID doc
16:48:38 <daniel> q+
16:48:39 <brent> ... something in the past, or on a different server (redirect)
16:48:56 <burn> ack daniel
16:48:57 <Justin_R> +1 ... fragments are for internal processing, matrix params are for processing things on their way to the document
16:49:03 <brent> .... I haven't seen a use case that requires a matrix param jsut to refer to a key.
16:49:04 <markus_sabadello> q+
16:49:18 <brent> daniel: I agree. the issue I suggest I don't think is solved.
16:49:19 <burn> ack markus_sabadello
16:49:26 <brent> ... we have to have a way to do it.
16:49:32 <manu> +1 to Justin_R's language.
16:49:36 <markus_sabadello> q+ :)
16:49:44 <Orie> to clarify: -1 to adding key matrix param, I'd rather see selection in a document built on an existing syntax
16:49:58 <manu> +1 to what Orie just said.
16:50:01 <brent> ... if there's any other way to do it. I have a intermediary state where some valude must be passed that people can use in lieu of haveing an actual anchor
16:50:02 <markus_sabadello> daniel is talking about https://github.com/w3c/did-core/pull/84
16:50:04 <burn> ack markus_sabadello
16:50:04 <Zakim> markus_sabadello, you wanted to say )
16:50:07 <ChristopherA> That sounds like something else though
16:50:12 <phila> q+
16:50:38 <Justin_R> q+ to talk about why resolution discussion is intertwined here
16:50:44 <dmitriz> q+
16:50:45 <brent> markus_sabadello: just one more time. key matrix parameter. One small different form using the fragment. the matrix parameter would be independent of the mime type of the did doc
16:50:45 <daniel> manu, Chris: if a DID is not anchored in Bitcoin for 10 minutes, how do I pass a resolvable ID to the RP in the meantime
16:50:47 <daniel> ?
16:50:49 <phila> q- later
16:51:22 <daniel> It is not an acceptable answer to say "just wait 10-20 minutes", when clearly we can just allow passage of some values
16:51:23 <drummond> Markus is correct that a "key=" matrix parameter would be a primary resource from a SemWeb standpoint.
16:51:29 <brent> ... if we use did urls with fragments, those would depend on the media type of the did doc, whereas the matrix parameter would allow you to refer to a key independent of the media type of the did doc.
16:51:35 <manu> daniel: add a different matrix parameter... like matrix-unresolved=true or something... we're talking about a specific PR... key one.
16:51:36 <phila> q-
16:51:38 <brent> ... that said, I support closing this PR
16:51:39 <burn> zakim, close the queue
16:51:39 <Zakim> ok, burn, the speaker queue is closed
16:51:42 <burn> ack Justin_R
16:51:42 <Zakim> Justin_R, you wanted to talk about why resolution discussion is intertwined here
16:51:43 <daniel> no
16:51:48 <manu> s/daniel: add/daniel, add/
16:51:50 <daniel> it is not about a boolean
16:52:06 <brent> Justin_R: This is a prime example of why we need to be having the DID resolution and dereferencing conversation here
16:52:07 <daniel> it is about actually passing the values REQUIRED to resolve the DID
16:52:09 <Orie> +1 to justin's point.
16:52:09 <daniel> not some flag
16:52:30 <brent> ... matrix parameters are passed to the resolver, which is a black box as far as this group is concerned.
16:52:39 <manu> daniel, this is issue #70?
16:52:44 <drummond> +1 to matrix parameters being passed into the resolution process. That's also different from fragments.
16:52:49 <daniel> In ION's case, the initial-value is the base64 encoded state of the initial DID document
16:52:55 <brent> ... resolution has different mime types, etc. we should bring resolution into this group.
16:52:56 <daniel> Same in Element
16:52:58 <burn> ack dmitriz
16:52:59 <drummond> +1 to bringing resolution into the scope of the WG
16:53:05 <ChristopherA> what is your proposal again?
16:53:09 <daniel> same in all the methods that use an actual decentralized system
16:53:12 <brent> dmitriz: plus one ot did resolution.
16:53:24 <brent> ... question, why are we giving keys special treatment?
16:53:24 <selfissued> Bringing DID resolution into the WG would require rechartering, as it's a significant increase in scope
16:53:28 <daniel> Chris: https://github.com/w3c/did-core/issues/70
16:53:34 <brent> ... why not a general id parameter
16:53:43 <burn> zakim, open the queue
16:53:43 <Zakim> ok, burn, the speaker queue is open
16:53:44 <brent> burn: what are the next steps?
16:53:48 <jonathan_holt> +1 to `id` seems reasonable compromise
16:53:55 <Justin_R> @selfissued no it is not, there is a phrase in the charter about resolution mechanisms
16:54:09 <markus_sabadello> a generic "id" matrix parameter has been casually talked about, e.g.: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/did-resolution-v2.md
16:54:14 <Justin_R> >  Establish a deterministic mapping between DID method identifiers and the resolution process used to resolve that DID method.
16:54:20 <brent> manu: I think we need folks to weigh in on the PRs. Now that you have the background, tell us why the PRs should or should not be merged.
16:54:35 <daniel> Can folks do a call on the initial-values matrix param?
16:54:52 <brent> markus_sabadello: That is the goal of today's discussion, to introducte matrix parameters so we can get feedbakc on the PRs
16:54:56 <daniel> I see a lot of misunderstanding of what at least our proposed param actually is for/does
16:54:56 <manu> https://github.com/w3c/did-core/pull/59
16:55:00 <manu> https://github.com/w3c/did-core/pull/60
16:55:04 <manu> https://github.com/w3c/did-core/pull/61
16:55:06 <brent> selfissued: can someone drop a link to the matrix parameters?
16:55:08 <manu> https://github.com/w3c/did-core/pull/62
16:55:09 <dlongley> `id` is obviously more general -- but we need a clear use case we can discuss because `id` would be the same as referring to something in the DID Document using `DID#<id>`... we need to be able to analyze the bitcoin use case, etc. to really understand the problem and other potential solutions.
16:55:12 <manu> https://github.com/w3c/did-core/pull/84
16:55:35 <daniel> Not this call
16:55:39 <daniel> a sidebar call
16:56:00 <daniel> That's what I was hoping to do, a separate call
16:56:12 <daniel> ok
16:56:12 <brent> burn: from a chair perspective, there's a point of diminishing returns on somewhat inter-related calls. We've continued the key format calls. we wanted to get this conversation started and see where things went
16:56:30 <rhiaro> +1 doing one thing at a time via extra calls
16:56:41 <brent> ... the chairs are paying attention. what we'd like to see if poeple make some effort to comment on the PRs.
16:57:00 <brent> ... that will make if easier to have the discussion
16:57:05 <burn> q?
16:57:17 <brent> burn: we are at the end, anything else that must be said?
16:57:32 <ChristopherA> I'm hosting CCG today, see you later
16:57:34 <ivan> rrsagent, draft minutes
16:57:34 <RRSAgent> I have made the request to generate https://www.w3.org/2019/12/03-did-minutes.html ivan
16:57:35 <ivan> zakim, bye
16:57:35 <ivan> rrsagent, bye
16:57:35 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2019/12/03-did-actions.rdf :
16:57:35 <RRSAgent> ACTION: drummond add more clarity on when matrix params should be used and when not [1]
16:57:35 <RRSAgent>   recorded in https://www.w3.org/2019/12/03-did-irc#T16-39-37
16:57:35 <Zakim> leaving.  As of this point the attendees have been ivan, burn, chriswinc, tzviya, ChristopherA, TallTed, brent, joel, Orie, dlongley, phila, dezell, present, manu, ahripak,
16:57:35 <Zakim> Zakim has left #did
16:57:38 <Zakim> ... Justin_R, jonathan_holt, rhiaro, drummond, mike-lodder, yancy, daniel, sumita, selfissued, agropper, dmitriz
16:57:40 <brent> ... thanks everyone, remeber the key format discussion tomorrow.