W3C WG Telco — Minutes
Date: 2020-05-26
See also the Agenda and the IRC Log
Attendees
Present: Dave Longley, Manu Sporny, Dmitri Zagidulin, Daniel Burnett, Brent Zundel, Justin Richer, Orie Steele, Jonathan Holt, Adrian Gropper, Drummond Reed
Regrets:
Guests: Adrian Gropper, gropper
Chair:
Scribe(s): Dmitri Zagidulin, Manu Sporny
Content:
1. Horizontal Review
Brent Zundel: Horizontal review is a process we go through in W3C where we invite specific groups to look through our spec and raise issues
… most of the horizontal review is specific to various aspects. Security & privacy reviews from PING
… review of i18n from that group. Also from Accessibility group, from Architecture group, etc.
… they review our spec, raise concerns & issues, and ensure we have time to do something about those
… the hold-up so far for inviting horiz. review has been the “Front Matter” to our spec issue
… there’s been a PR that recommends some new front matter for the spec. PLEASE check it out
… and review. Once it’s in, we can kick off the process
… in order to proceed down the Horizontal Review path,
Brent Zundel: https://github.com/w3c/did-core/labels/horizontal%20review
Brent Zundel: follow ^ link, to see issues & PRs with the ‘hr’ label
… these are all tracking tickets for the ‘process.
… we have the over-arching tracking issue 292. And then we have review-specific sub-issues for TAG, accessibility, internationalization,
… in addition to those groups, we need to create the Explainer Document, which is specifically requested by the TAG,
… because they get these review requests all the time, and it gives them context for the review
… what this comes down to, ultimately — we need people to agree to be in charge of these things
… to work on them, bother people to work on them, and server as general task leads, on these.
… for some of them, there’s questionnaires that have been filled out (and just need finalization), for others, not started,
… and all of these items need volunteers.
… we have the core group here today. Who will step forward and volunteer?
… does anyone have questions on what it means to volunteer?
… so, the specific tasks we’re looking for: 1) DID Explainer document
… 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)
… 2) Security and Privacy Questionnaire
… that one hasn’t been started, needs to be worked through.
… many of the questions may not apply; many of them are web- and browser-centric
… so we need somebody to fill it out, others to review it, etc.
… 3) Each of the other groups has a questionnaire of their own
… Ivan answered most of the Internationalization issues except for one.
… Accessibility also - Ivan did the bulk of it
… So, those are the tasks that we’re looking for volunteers for. right now.
… Well, these things can’t move forward without help.
… ah, here we go, jonathan holt / jonnycrunch has volunteered for the Security item!
… that’s issue 291 is the Ping Review issue, and there’s a link there to the Security & Privacy questionnaire
Dmitri Zagidulin: I volunteer to take a stab at the Internationalization item / issue 104
… this worked last time – https://www.w3.org/TR/vc-data-model/#internationalization-considerations
Brent Zundel: please reach out to everyone to get this done
2. Issue Status Check
Brent Zundel: akck manu
Brent Zundel: manu is on the queue
Manu Sporny: just to set up the Special Topic call, so we can be productive –
… chairs/editors had a discussion on how to move the DID Resolution stuff forward in the spec
… some of Justin’s non-normative made it into the spec,
… and now we’re debating the normative parts
… there are currently 3 PRs to move the discussion forward,
… and the general consensus was that none of them are headed in the right direction
… so, we need a fresh PR to move the discussion forward
… the Editors also felt like there were not in a position to author that new PR.
… so, Justin - would you be able to create a new PR that dials back the normative requirements, just focuses on the input/output stuff
… ?
Justin Richer: I’m going to try to put something together
… but I am very confused as to what is being requested
… my view of what was happening last week was - there was pushback on the Algorithm portion specifically, which was unique to the third PR
… and so I can submit PR 253 again, effectively. I’m not sure of what is being asked here
Manu Sporny: Orie - can you clarify?
Orie Steele: I think the thing that I’d like to see from this set of open PRs is -
… I’d like to see a small PR that just defines the contract interface for DID Resolution,
… without the other definitions and normative text
… just something that says “the WG is committed to building out this contract / interface”
… it’s the interface that we all want. The specifics of it will take longer to achieve
… without getting too much into the weeds, I think we can just borrow the same model as the fetch() spec
… and we should close the other PRs
Justin Richer: 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
… so, is that really what we want? Will that be actually be useful?
… because we’re agreeing to name variables, but not defining what those variables /are/
… that’s the part I’m missing
Orie Steele: maybe the contract definition is not the right term
… what I’m hoping to see is - what you described in the last WG call.
… so, there’s a DID Doc of type Buffer.
… and there’s a resolve() function,
… it’s that kind of definition that we can get agreement on
Dave Longley: i will object to “a didDocument of type buffer” right away, btw :)
Orie Steele: without error handling, or buffer parsing rules
… I agree that a function signature is not super useful by itself.
… but once people see those pieces, it will give us a structure for fleshing out the other pieces
Justin Richer: https://github.com/w3c/did-core/pull/263
Justin Richer: 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?
… 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
Dmitri Zagidulin: Just wanted to respond…
… 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.
… The input to resolution is a content type, and a body, here’s what the body contains in IDL-like language.
3. DIDCore Issues
Brent Zundel: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
Brent Zundel: first issue - 176
Brent Zundel: https://github.com/w3c/did-core/issues/176
Brent Zundel: assigned to Mike Jones, who is not on the call
… is anyone able to comment on it? (it’s got the Editorial label)
Dmitri Zagidulin: .. next, 157. assigned to Orie
Brent Zundel: https://github.com/w3c/did-core/issues/157
Brent Zundel: why are we using (?) in our Core Context?
Orie Steele: I don’t understand why we’re using ‘didv’ in our core context
Brent Zundel: Orie, please leave a comment on the issue, link to the new issue you’ll open on the DID Spec Registries
Brent Zundel: https://github.com/w3c/did-core/issues/122
Brent Zundel: next issue is 122 - When is Subject not a DID Controller, if ever?
… assigned to rhiaro, who I do not see on the call
… the only person in that comment thread is dlongley
Dave Longley: ok, this is more like an open question, not sure if it’s actionable
… there’s a lot of content that could potentially be added to the spec, if we want
… otherwise, it’s just a question that (hopefully) has been answered
Brent Zundel: can we comment to that end?
Dave Longley: yep
Daniel Burnett: dlongley, you can also ask in there ‘is there any reason this issue should stay open / any action that needs to be taken?’
Brent Zundel: next up, issue 190. Clarification on Term X
Brent Zundel: https://github.com/w3c/did-core/issues/190
Brent Zundel: very long conversation
… only person on the call who can comment is dlongley or dmitriz — either of you want to comment?
Manu Sporny: Eric said he’s fine to close this. I’ll mark it ‘Pending Close’ unless there are objections
Daniel Burnett: 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.”
Brent Zundel: great
… next up, issue 210
Brent Zundel: https://github.com/w3c/did-core/issues/210
Brent Zundel: who or what is a DID Controller? opened by Kyle
Manu Sporny: I saw something fly by from Kyle
… it is a modification to the intro that Drummond and Amy put together
… he’s made two suggestions, and said that this issue will be addressed if those two comments are taken into account
Brent Zundel: he refers to 288 (the Front Matter PR), also 261
… so, sounds like we have a way forward with this, just need to get those PRs reviewed & merged
Brent Zundel: https://github.com/w3c/did-core/issues/72
Brent Zundel: next, issue #72, Privacy Considerations (calls out GDPR)
… assigned to Drummond
… what’s the action on this?
… or has it already been addressed by a merged PR?
Manu Sporny: the thing that Amy pointed to was expanded upon (the GDPR part)
… so, I think we should mark it Pending Close and have Drummond whether or not it’s been addressed
Daniel Burnett: I thought we reserve the label for when we believe it’s done, not when we’re just checking whether it should be closed
Brent Zundel: https://github.com/w3c/did-core/issues/72
Orie Steele: https://github.com/w3c/did-core/issues/72
Brent Zundel: https://github.com/w3c/did-core/issues/168
Brent Zundel: can you leave a comment in the issue, saying it stils needs actions?
Drummond Reed: will do
Brent Zundel: 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”
… there is a “simplified description of the public keys” PR. which hopefully addresses Mike’s issue?
Brent Zundel: https://github.com/w3c/did-core/pull/279
Brent Zundel: I encourage everyone to take a look at PR #279,
Orie Steele: please merge, we have 11 open PRs many of which are drafts… so its not clear if they should be reviewed
Brent Zundel: Joe Andrieu has been pinged 10 days ago, he’s had plenty of time to respond
Manu Sporny: I pinged him once again, mentioned we’ll merge the PR unless he objects
Orie Steele: 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
… or moving them out of the Draft stage (so that people know they can be reviewed)
… 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
Dave Longley: 2 points about this pR. not sure we can say ‘MAY NOT’, we need to say ‘MUST NOT’.
… plus I have a comment which I’ll propose in the issue
Justin Richer: while in general, I agree with Orie about closing & managing PRs, there is at least one, namely 253,
… which has a lot of contents that is being split and merged into other places, which has been useful for now
… I agree about the ‘Draft PR’ mechanism - I tend to not use them,
Orie Steele: I use drafts when I want someone to NOT review my PR yet :)
Justin Richer: but that’s really up to the submitter (to indicate what state they think the PR is in)
… so, some old PRs are deservedly so.
Justin Richer: Orie: I do the same, that’s not how everyone uses that funciton though.
Manu Sporny: 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,
… and still want them to be processed. Or they’re still being discussed.
… fwiw, I think it’s perfectly healthy to have many open PRs.
… especially ones that examine the same problem in multiple ways. so the group can look at the alternatives, and decide
… so, 6 of these, are PRs that people are actively debating (or people have requested they not be closed)
… others are waiting on the PR submitter to respond, or waiting on reviews
Daniel Burnett: +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.
Manu Sporny: really, there are only 2-3 are ready to go in. the rest are still active
… I’m always wary of when the group starts saying “we should just close PRs” when they’re under active discussion.
Brent Zundel: https://github.com/w3c/did-core/issues/202
Brent Zundel: thank you everybody.
Justin Richer: +1 to burn, I expect a number of these to disappear once the issues they are addressing are done
Brent Zundel: next up, issue #202
Justin Richer: This is something being worked on in the Registries spec.
… and I believe the special topic call the other week came to a resolution on that. Orie, can you comment?
… I think the idea was to /not/ have that type of catch-all thing in the context
… which would mean we need to alter the consumption language in the current DID Core for json-ld
… is that were things were?
Orie Steele: pretty close
… we’ll clean up the presentation of the Registries’ HTML, and clean up the contexts etc
… so, waiting for a better version
Justin Richer: Ok, then next step is - update to the consumption language of JSON-LD.
… if somebody else can update the consumer language, in the Representations section, we’ll be all set
Brent Zundel: next up, #153, embedded custom contexts
… assigned to Orie
Brent Zundel: https://github.com/w3c/did-core/issues/153
Orie Steele: my recommendation is to .. not ever do this.
… I’ll make that clear on the issue, maybe we can close it at some point
Brent Zundel: next, issue 23, a classic.
Brent Zundel: https://github.com/w3c/did-core/issues/23
Dmitri Zagidulin: .. PublicKeyJWK, Hex, Base64, etc, missing from context
Brent Zundel: raised originally in the CCG by Orie, moved here, currently assigned to Mike Jones and Oliver Terbu
… last comment was - it’s blocked by the DID Spec Registries
… is that still the case?
Orie Steele: JWK portion is not blocked. Hex is blocked, pending the facelift (I’ll leave a note)
Manu Sporny: Orie, can I reassign you and Amy to this issue?
Orie Steele: yep
Brent Zundel: next, issue #58, registry handling
Brent Zundel: https://github.com/w3c/did-core/issues/58
Brent Zundel: is this something that’s blocked by lack of clarity around W3C registry handling process?
Manu Sporny: we discussed this lightly on the CCG call; it’s still in process
… 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,
… and hopefully that’ll lead to a resolution of this issue. I’ll add it to the issue thread
Brent Zundel: https://github.com/w3c/did-core/issues/152
Brent Zundel: next, issue 152, Do we need a ‘did method type’ feature?
Drummond Reed: Markus and I talked about this earlier this week, actually,
… 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.
Brent Zundel: is that PR 215, colon in method-specific ID?
Drummond Reed: I think it’s the PR about switching to query-based params
Brent Zundel: 285
Drummond Reed: I’ll add a comment
Brent Zundel: folks, please take a look at it. This is one of the core decisions we made as a group
… ok, one more
Brent Zundel: https://github.com/w3c/did-core/issues/200
Brent Zundel: next up, #200. DID URL de-referencing and rel’ship to different encodings & representations
… assigned to Tobias
… some conversation on it, associated with a merged PR
Daniel Burnett: I’ll ping Tobias and ask him if it’s resolved
Brent Zundel: and with that, we are done with issue review and the call!
… see you on the special topic meeting on Thurs