22:06:35 <RRSAgent> RRSAgent has joined #did
22:06:35 <RRSAgent> logging to https://www.w3.org/2020/05/26-did-irc
22:06:38 <Zakim> Zakim has joined #did
22:06:39 <dmitriz> topic: Horizontal Review
22:06:57 <dlongley> present+
22:07:02 <agropper> present+
22:07:07 <manu> present+
22:07:10 <manu> rrsagent, make logs public
22:07:17 <manu> rssagent, draft minutes
22:07:17 <dmitriz> brent: Horizontal review is a process we go through in W3C where we invite specific groups to look through our spec and raise issues
22:07:22 <manu> rrsagent, draft minutes
22:07:22 <RRSAgent> I have made the request to generate https://www.w3.org/2020/05/26-did-minutes.html manu
22:07:26 <burn> q?
22:07:31 <manu> s/rssagent, draft minutes//
22:07:33 <dmitriz> … most of the horizontal review is specific to various aspects. Security & privacy reviews from PING
22:07:40 <manu> q+ to request things that could happen to help special topic call along.
22:07:50 <dmitriz> … review of i18n from that group. Also from Accessibility group, from Architecture group, etc.
22:08:08 <dmitriz> … they review our spec, raise concerns & issues, and ensure we have time to do something about those
22:08:09 <manu> scribe+ dmitriz
22:08:12 <manu> scribe+ manu
22:08:17 <manu> present+ dmitriz
22:08:19 <manu> present+ burn
22:08:21 <dmitriz> … the hold-up so far for inviting horiz. review has been the "Front Matter" to our spec issue
22:08:22 <manu> present+ brent
22:08:28 <gannan> gannan has joined #did
22:08:31 <dmitriz> … there's been a PR that recommends some new front matter for the spec. PLEASE check it out
22:08:39 <dmitriz> … and review. Once it's in, we can kick off the process
22:08:40 <manu> present+ Justin_R
22:08:44 <manu> present+ orie
22:08:51 <dmitriz> … in order to proceed down the Horizontal Review path,
22:08:53 <brent> https://github.com/w3c/did-core/labels/horizontal%20review
22:08:54 <Justin_R> present+
22:08:55 <manu> present+ gropper
22:09:02 <manu> present+ jonnycrunch
22:09:11 <dmitriz> … follow ^ link, to see issues & PRs with the 'hr' label
22:09:11 <manu> rrsagent, draft minutes
22:09:11 <RRSAgent> I have made the request to generate https://www.w3.org/2020/05/26-did-minutes.html manu
22:09:12 <burn> present+ agropper
22:09:26 <dmitriz> … these are all tracking tickets for the 'process.
22:09:45 <dmitriz> … we have the over-arching tracking issue 292. And then we have review-specific sub-issues for TAG, accessibility, internationalization,
22:10:04 <dmitriz> … in addition to those groups, we need to create the Explainer Document, which is specifically requested by the TAG,
22:10:05 <manu> Meeting: DID WG call (America/Asia)
22:10:19 <dmitriz> … because they get these review requests all the time, and it gives them context for the review
22:10:41 <dmitriz> … what this comes down to, ultimately — we need people to agree to be in charge of these things
22:10:53 <dmitriz> … to work on them, bother people to work on them, and server as general task leads, on these.
22:11:10 <dmitriz> … for some of them, there's questionnaires that have been filled out (and just need finalization), for others, not started,
22:11:15 <dmitriz> … and all of these items need volunteers.
22:11:19 <manu> rrsagent, draft minutes
22:11:19 <RRSAgent> I have made the request to generate https://www.w3.org/2020/05/26-did-minutes.html manu
22:11:34 <dmitriz> … we have the core group here today. Who will step forward and volunteer?
22:11:38 <brent> q?
22:11:42 <dmitriz> … does anyone have questions on what it means to volunteer?
22:11:42 <brent> ack manu
22:11:42 <Zakim> manu, you wanted to request things that could happen to help special topic call along.
22:12:13 <manu> q+ to request things that could happen to help special topic call along.
22:12:22 <dmitriz> … so, the specific tasks we're looking for: 1) DID Explainer document
22:12:40 <dmitriz> … which is a summary of what a DID is. (you can borrow text from the spec if you need to, but this is at a higher/simpler level)
22:12:47 <dmitriz> … 2) Security and Privacy Questionnaire
22:12:57 <dmitriz> … that one hasn't been started, needs to be worked through.
22:13:08 <dmitriz> … many of the questions may not apply; many of them are web- and browser-centric
22:13:22 <dmitriz> … so we need somebody to fill it out, others to review it, etc.
22:13:34 <dmitriz> … 3) Each of the other groups has a questionnaire of their own
22:13:45 <dmitriz> … Ivan answered most of the Internationalization issues except for one.
22:13:52 <dmitriz> … Accessibility also - Ivan did the bulk of it
22:14:07 <dmitriz> … So, those are the tasks that we're looking for volunteers for. right now.
22:15:13 <dmitriz> … Well, these things can't move forward without help.
22:15:27 <dmitriz> … ah, here we go, jonathan holt / jonnycrunch has volunteered for the Security item!
22:15:45 <manu> present+ jonathan_holt
22:15:48 <dmitriz> … that's issue 291 is the Ping Review issue, and there's a link there to the Security & Privacy questionnaire
22:18:24 <brent> q?
22:18:28 <dmitriz> dmitriz: I volunteer to take a stab at the Internationalization item / issue 104
22:18:44 <manu> dmitriz: this worked last time -- https://www.w3.org/TR/vc-data-model/#internationalization-considerations
22:18:47 <dmitriz> brent: please reach out to everyone to get this done
22:18:56 <dmitriz> topic: Issue Status Check
22:19:00 <brent> akck manu
22:19:03 <dmitriz> … manu is on the queue
22:19:03 <brent> ack manu
22:19:03 <Zakim> manu, you wanted to request things that could happen to help special topic call along.
22:19:11 <dmitriz> manu: just to set up the Special Topic call, so we can be productive --
22:19:21 <dmitriz> … chairs/editors had a discussion on how to move the DID Resolution stuff forward in the spec
22:19:29 <dmitriz> … some of Justin's non-normative made it into the spec,
22:19:33 <dmitriz> … and now we're debating the normative parts
22:19:39 <dmitriz> … there are currently 3 PRs to move the discussion forward,
22:19:49 <dmitriz> … and the general consensus was that none of them are headed in the right direction
22:19:56 <dmitriz> … so, we need a fresh PR to move the discussion forward
22:20:06 <Justin_R> q+ to respond to me being assigned something
22:20:10 <dmitriz> … the Editors also felt like there were not in a position to author that new PR.
22:20:29 <dmitriz> … so, Justin - would you be able to create a new PR that dials back the normative requirements, just focuses on the input/output stuff
22:20:36 <dmitriz> … ?
22:20:51 <brent> q?
22:20:57 <brent> ack Justin_R
22:20:57 <Zakim> Justin_R, you wanted to respond to me being assigned something
22:21:04 <dmitriz> Justin_R: I'm going to try to put something together
22:21:12 <dmitriz> … but I am very confused as to what is being requested
22:21:28 <dmitriz> … my view of what was happening last week was - there was pushback on the Algorithm portion specifically, which was unique to the third PR
22:21:46 <dmitriz> … and so I can submit PR 253 again, effectively. I'm not sure of what is being asked here
22:21:54 <dmitriz> manu: Orie - can you clarify?
22:22:04 <brent> q?
22:22:12 <dmitriz> Orie: I think the thing that I'd like to see from this set of open PRs is -
22:22:25 <dmitriz> … I'd like to see a small PR that just defines the contract interface for DID Resolution,
22:22:31 <dmitriz> … without the other definitions and normative text
22:22:47 <dmitriz> … just something that says "the WG is committed to building out this contract / interface"
22:23:11 <dmitriz> … it's the interface that we all want. The specifics of it will take longer to achieve
22:23:33 <dmitriz> … without getting too much into the weeds, I think we can just borrow the same model as the fetch() spec
22:23:43 <dmitriz> … and we should close the other PRs
22:24:05 <dmitriz> Justin_R: that's slightly helpful. Reading through the fetch() doc, I want to note that the function definition is in fact meaningless without the surrounding explanations of what the parts mean
22:24:15 <dmitriz> … so, is that really what we want? Will that be actually be useful?
22:24:29 <dmitriz> … because we're agreeing to name variables, but not defining what those variables /are/
22:24:33 <manu> q+ to note that it's not useful, but people are pushing back on doing more.
22:24:33 <Orie> q+
22:24:33 <dmitriz> … that's the part I'm missing
22:24:37 <manu> q- later
22:24:45 <dmitriz> q+
22:24:53 <manu> q- later
22:25:07 <brent> q?
22:25:11 <brent> ack Orie
22:25:12 <dmitriz> Orie: maybe the contract definition is not the right term
22:25:21 <dmitriz> … what I'm hoping to see is - what you described in the last WG call.
22:25:27 <dmitriz> … so, there's a DID Doc of type Buffer.
22:25:40 <dmitriz> … and there's a resolve() function,
22:25:48 <dmitriz> … it's that kind of definition that we can get agreement on
22:25:55 <dlongley> i will object to "a didDocument of type buffer" right away, btw :)
22:25:58 <dmitriz> … without error handling, or buffer parsing rules
22:26:07 <dmitriz> … I agree that a function signature is not super useful by itself.
22:26:19 <dmitriz> … but once people see those pieces, it will give us a structure for fleshing out the other pieces
22:26:37 <manu> q-
22:26:40 <Justin_R> https://github.com/w3c/did-core/pull/263
22:26:51 <dmitriz> Justin_R: I just want to point out - like I said previously, most of what you're asking for is already in #263. what's the delta?
22:27:20 <dmitriz> … we can take the discussion to the issue tracker. I can try to do a more slimmed-down version that's just the type contract by Thurs. But I'm at a loss as to how thinly we're slicing this
22:27:27 <brent> ack dmitriz
22:27:29 <manu> dmitriz: Just wanted to respond...
22:27:50 <manu> dmitriz: There is a lot of value in just the type definitions that the fetch spec provides. I don't think it's useless, it's fairly self contained.
22:28:07 <manu> dmitriz: The input to resolution is a content type, and a body, here's what the body contains in IDL-like language.
22:28:18 <brent> Topic: DIDCore Issues
22:28:21 <brent> https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
22:28:40 <dmitriz> brent: first issue - 176
22:28:46 <brent> https://github.com/w3c/did-core/issues/176
22:28:52 <dmitriz> … assigned to Mike Jones, who is not on the call
22:29:12 <dmitriz> … is anyone able to comment on it? (it's got the Editorial label)
22:29:44 <dmitriz> .. next, 157. assigned to Orie
22:29:52 <brent> https://github.com/w3c/did-core/issues/157
22:29:53 <dmitriz> … why are we using (?) in our Core Context?
22:30:20 <dmitriz> Orie: I don't understand why we're using 'didv' in our core context
22:30:57 <dmitriz> brent: Orie, please leave a comment on the issue, link to the new issue you'll open on the DID Spec Registries
22:31:10 <brent> https://github.com/w3c/did-core/issues/122
22:31:13 <dmitriz> brent: next issue is 122 - When is Subject not a DID Controller, if ever?
22:31:24 <dmitriz> … assigned to rhiaro, who I do not see on the call
22:31:35 <dmitriz> … the only person in that comment thread is dlongley
22:31:52 <dmitriz> dlongley: ok, this is more like an open question, not sure if it's actionable
22:32:03 <dmitriz> … there's a lot of content that could potentially be added to the spec, if we want
22:32:12 <dmitriz> … otherwise, it's just a question that (hopefully) has been answered
22:32:17 <dmitriz> brent: can we comment to that end?
22:32:19 <dmitriz> dlongley: yep
22:32:38 <dmitriz> burn: dlongley, you can just ask in there 'is there any reason this issue should stay open / any action that needs to be taken?'
22:32:55 <dmitriz> brent: next up, issue 190. Clarification on Term X
22:32:58 <brent> https://github.com/w3c/did-core/issues/190
22:32:58 <burn> s/can just ask/can also ask/
22:33:20 <dmitriz> brent: very long conversation
22:33:36 <dmitriz> … only person on the call who can comment is dlongley or dmitriz — either of you want to comment?
22:33:50 <dmitriz> manu: Eric said he's fine to close this. I'll mark it 'Pending Close' unless there are objections
22:33:59 <burn> On Mar 18 Eric said "I'll close this in a few days if there is no objection or if there is any concern that needs to be addressed."
22:34:07 <dmitriz> brent: great
22:34:22 <dmitriz> … next up, issue 210
22:34:25 <brent> https://github.com/w3c/did-core/issues/210
22:34:32 <dmitriz> … who or what is a DID Controller? opened by Kyle
22:34:44 <dmitriz> manu: I saw something fly by from Kyle
22:34:52 <dmitriz> … it is a modification to the intro that Drummond and Amy put together
22:35:05 <dmitriz> … he's made two suggestions, and said that this issue will be addressed if those two comments are taken into account
22:35:19 <dmitriz> brent: he refers to 288 (the Front Matter PR), also 261
22:35:33 <dmitriz> … so, sounds like we have a way forward with this, just need to get those PRs reviewed & merged
22:35:48 <brent> https://github.com/w3c/did-core/issues/72
22:35:50 <dmitriz> … next, issue #72, Privacy Considerations (calls out GDPR)
22:35:57 <dmitriz> … assigned to Drummond
22:36:27 <dmitriz> … what's the action on this?
22:36:36 <dmitriz> … or has it already been addressed by a merged PR?
22:37:10 <dmitriz> manu: the thing that Amy pointed to was expanded upon (the GDPR part)
22:37:26 <dmitriz> … so, I think we should mark it Pending Close and have Drummond whether or not it's been addressed
22:38:02 <dmitriz> burn: I thought we reserve the label for when we believe it's done, not when we're just checking whether it should be closed
22:38:09 <dmitriz> Drummond: I am here!
22:38:30 <drummond_> drummond_ has joined #did
22:38:33 <drummond_> present+
22:38:33 <brent> https://github.com/w3c/did-core/issues/72
22:38:33 <Orie> https://github.com/w3c/did-core/issues/72
22:40:02 <brent> https://github.com/w3c/did-core/issues/168
22:40:03 <dmitriz> brent: can you leave a comment in the issue, saying it stils needs actions?
22:40:07 <dmitriz> drummond_: will do
22:40:36 <dmitriz> brent: next up, 168, raised by Mike Jones. healthy conversation around it. the last comment by manu says "the only thing that's crystal clear is we don't have consensus"
22:40:56 <dmitriz> … there is a "simplified description of the public keys" PR. which hopefully addresses Mike's issue?
22:41:03 <brent> https://github.com/w3c/did-core/pull/279
22:41:06 <dmitriz> … I encourage everyone to take a look at PR #79,
22:41:26 <dmitriz> s/#79,/#279,/
22:41:32 <Orie> q+
22:41:43 <dlongley> q+
22:42:01 <Orie> please merge, we have 11 open PRs
22:42:08 <dmitriz> brent: Joe Andrieu has been pinged 10 days ago, he's had plenty of time to respond
22:42:10 <Orie> many of which are drafts...
22:42:19 <dmitriz> manu: I pinged him once again, mentioned we'll merge the PR unless he objects
22:42:20 <Orie> so its not clear if they should be reviewed
22:42:24 <brent> q?
22:42:31 <brent> ack Orie
22:42:46 <dmitriz> Orie: I'm glad Joe got pinged. We have 11 PRs, some of them are drafts. I'd love to focus us on PRs that won't make it through
22:42:50 <Justin_R> q+ to talk about state of pull requests
22:42:57 <dmitriz> … or moving them out of the Draft stage (so that people know they can be reviewed)
22:43:18 <dmitriz> … there are some really long-lived PRs; I'd love to move a bit faster. Anything we can do, from a process perspective, to encourage reviews
22:43:18 <brent> ack dlongley
22:43:32 <dmitriz> dlongley: 2 points about this pR. not sure we can say 'MAY NOT', we need to say 'MUST NOT'.
22:43:37 <brent> ack Justin_R
22:43:37 <Zakim> Justin_R, you wanted to talk about state of pull requests
22:43:40 <dmitriz> … plus I have a comment which I'll propose in the issue
22:44:07 <dmitriz> Justin_R: while in general, I agree with Orie about closing & managing PRs, there is at least one, namely 253,
22:44:21 <manu> q+ to talk about why these PRs have been open for so long.
22:44:25 <dmitriz> … which has a lot of contents that is being split and merged into other places, which has been useful for now
22:44:35 <dmitriz> … I agree about the 'Draft PR' mechanism - I tend to not use them,
22:44:46 <Orie> I use drafts when I want someone to NOT review my PR yet :)
22:44:49 <dmitriz> … but that's really up to the submitter (to indicate what state they think the PR is in)
22:45:02 <brent> ack manu
22:45:02 <Zakim> manu, you wanted to talk about why these PRs have been open for so long.
22:45:04 <dmitriz> … so, some old PRs are deservedly so.
22:45:23 <Justin_R> Orie: I do the same, that's not how everyone uses that funciton though.
22:45:28 <dmitriz> manu: the issue here is not that we can't process PRs quickly. It's because the folks that raised some of these PRs have requested they not be closed,
22:45:38 <dmitriz> … and still want them to be processed. Or they're still being discussed.
22:45:46 <dmitriz> … fwiw, I think it's perfectly healthy to have many open PRs.
22:45:56 <agropper> agropper has joined #did
22:46:04 <dmitriz> … especially ones that examine the same problem in multiple ways. so the group can look at the alternatives, and decide
22:46:35 <dmitriz> … so, 6 of these, are PRs that people are actively debating (or people have requested they not be closed)
22:46:44 <dmitriz> … others are waiting on the PR submitter to respond, or waiting on reviews
22:47:03 <burn> +1 Manu.  As long as discussion on the overall topic is continuing and moving forward, it is not appropriate to close them.  Likely we will be able to close them in bunches as the issues resolve.
22:47:18 <dmitriz> … really, there are only 2-3 are ready to go in. the rest are still active
22:47:48 <dmitriz> … I'm always wary of when the group starts saying "we should just close PRs" when they're under active discussion.
22:47:52 <brent> https://github.com/w3c/did-core/issues/202
22:47:52 <dmitriz> brent: thank you everybody.
22:47:56 <Justin_R> +1 to burn, I expect a number of these to disappear once the issues they are addressing are done
22:48:00 <dmitriz> … next up, issue #202
22:48:26 <dmitriz> Justin_R: This is something being worked on in the Registries spec.
22:48:41 <dmitriz> … and I believe the special topic call the other week came to a resolution on that. Orie, can you comment?
22:48:52 <dmitriz> … I think the idea was to /not/ have that type of catch-all thing in the context
22:49:02 <dmitriz> … which would mean we need to alter the consumption language in the current DID Core for json-ld
22:49:08 <dmitriz> … is that were things were?
22:49:10 <brent> q?
22:49:10 <dmitriz> Orie: pretty close
22:49:26 <dmitriz> … we'll clean up the presentation of the Registries' HTML, and clean up the contexts etc
22:49:31 <dmitriz> … so, waiting for a better version
22:49:43 <dmitriz> Justin_R: Ok, then next step is - update to the consumption language of JSON-LD.
22:50:02 <dmitriz> … if somebody else can update the consumer language, in the Representations section, we'll be all set
22:50:25 <dmitriz> brent: next up, #153, embedded custom contexts
22:50:34 <dmitriz> … assigned to Orie
22:50:34 <brent> https://github.com/w3c/did-core/issues/153
22:50:57 <dmitriz> Orie: my recommendation is to .. not ever do this.
22:51:06 <dmitriz> … I'll make that clear on the issue, maybe we can close it at some point
22:51:20 <dmitriz> brent: next, issue 23, a classic.
22:51:22 <brent> https://github.com/w3c/did-core/issues/23
22:51:39 <dmitriz> .. PublicKeyJWK, Hex, Base64, etc, missing from context
22:51:49 <manu> q+
22:51:51 <dmitriz> … raised originally in the CCG by Orie, moved here, currently assigned to Mike Jones and Oliver Terbu
22:52:03 <dmitriz> … last comment was - it's blocked by the DID Spec Registries
22:52:10 <dmitriz> … is that still the case?
22:52:22 <dmitriz> Orie: JWK portion is not blocked. Hex is blocked, pending the facelift (I'll leave a note)
22:52:34 <dmitriz> manu: Orie, can I reassign you and Amy to this issue?
22:52:36 <dmitriz> Orie: yep
22:52:44 <brent> ack manu
22:53:03 <dmitriz> brent: next, issue #58, registry handling
22:53:05 <brent> https://github.com/w3c/did-core/issues/58
22:53:39 <dmitriz> … is this something that's blocked by lack of clarity around W3C registry handling process?
22:53:47 <dmitriz> manu: we discussed this lightly on the CCG call; it's still in process
22:54:12 <dmitriz> … the hope is - it'll be some combination of - the best of DID Spec Registries, VCWG Maintenance Charter, and it looks like things are converging,
22:54:24 <dmitriz> … and hopefully that'll lead to a resolution of this issue. I'll add it to the issue thread
22:54:46 <brent> https://github.com/w3c/did-core/issues/152
22:54:50 <dmitriz> brent: next, issue 152, Do we need a 'did method type' feature?
22:56:06 <dmitriz> drummond_: Markus and I talked about this earlier this week, actually,
22:56:32 <dmitriz> … now that Matrix Params issue is settled — I don't know if Markus's PR has been pulled in. If it is, we can tackle this.
22:56:44 <dmitriz> brent: is that PR 215, colon in method-specific ID?
22:57:05 <dmitriz> drummond_: I think it's the PR about switching to query-based params
22:57:15 <dmitriz> brent: 285
22:57:32 <dmitriz> drummond_: I'll add a comment
22:57:57 <dmitriz> brent: folks, please take a look at it. This is one of the core decisions we made as a group
22:57:59 <dmitriz> … ok, one more
22:58:15 <brent> https://github.com/w3c/did-core/issues/200
22:58:17 <dmitriz> … next up, #200. DID URL de-referencing and rel'ship to different encodings & representations
22:58:24 <dmitriz> … assigned to Tobias
22:58:34 <dmitriz> … some conversation on it, associated with a merged PR
22:59:08 <dmitriz> burn: I'll ping Tobias and ask him if it's resolved
22:59:18 <dmitriz> brent: and with that, we are done with issue review and the call!
22:59:28 <dmitriz> … see you on the special topic meeting on Thurs
23:00:09 <manu> rrsagent, draft minutes
23:00:09 <RRSAgent> I have made the request to generate https://www.w3.org/2020/05/26-did-minutes.html manu
23:00:17 <dlongley> delish
23:00:23 <dlongley> s/delish//
23:32:00 <chriswinc> chriswinc has joined #did