VC WG Telco — Minutes
Date: 2021-11-03
See also the Agenda and the IRC Log
Attendees
Present: Brent Zundel, Shigeya Suzuki, Wayne Chang, David Chadwick, Manu Sporny, Dmitri Zagidulin, Ted Thibodeau Jr., Dave Longley, Kyle Den Hartog, Logan Porter, Gregory Natran
Regrets:
Guests:
Chair: Brent Zundel
Scribe(s): Wayne Chang, Manu Sporny
Content:
1. Agenda Review.
Brent Zundel: agenda is talk about TPAC, recap of those meetings, update of v1.1, PR review, triage issues for v1.1 editorial issues.
… anyone have something to change or add to the agenda?.
2. TPAC Review.
Brent Zundel: folks here were in TPAC last week. we spent 2 days meeting. day 1 was focused on a wish list for v2 and reviewing the charter to ensure they were in scope. invitation to review draft of charter..
… day 2 was spent primarily in issue processing. had a good conversation about v1.1 vs v1.2, will talk about this soon..
… also evaluated interest in driving forward existing issues in this charter or defer to next.
… welcome back to greg.
Manu Sporny: Microsoft mentioned they may be interested in pursuing mDL work within W3C, using HTTP API and other relevant components to demonstrate a full flow..
Logan Porter: from mattr, working with VCs.
Manu Sporny: We might want to consider putting some of the mDL work for Web in scope for the charter, nothing official, just work on NOTEs and vocabularies and some liason activities..
David Chadwick: i would have said yes to address 2 issues in v1.1 if i were at TPAC.
… with respect to mDL, i’ve been attending the meetings on and off for 2+ years. my strong belief is that we should work together, and v2 of mDL will support VC data structure within SC-17.
… working together is the far better strategy, especially because OpenID is the transport for the next version. there would be a lot of benefit if we work together and have the VC data model accepted as a formal for mDL.
Manu Sporny: +1 to DavidC, definitely not working against. complementary to, and in support of mDL.
… as a WG, we can put some of the work in scope, but not make it an official standard thing, as to prevent miscommunication that it’s unaligned.
Brent Zundel: pleasantly surprising how compatible the two efforts are moving forward. any other TPAC comments?.
Manu Sporny: +1 to brent.
3. Current Status v1.1.
Brent Zundel: over to manu.
Manu Sporny: latest status of v1.1 publication is here: https://lists.w3.org/Archives/Public/public-vc-wg/2021Nov/0002.html.
… they have pinned 5 versions of this email, we keep learning things about the 2021 process which just went live yesterday. we’re the first through the 2021 process given our timing. there are a number of things that weren’t clear, that we should’ve been doing over the past 2 years that we weren’t doing..
… we think we negotiated everything we have to do with the latest documents. the things that will be new to everyone in the REC update process is (1) when we publish the rec, we just publish it out there in place of the old rec.
Manu Sporny: Example of Candidate Correction: https://htmlpreview.github.io/?https://github.com/w3c/vc-data-model/blob/main/REC/2021-11-09/index.html#c1.1.
Manu Sporny: so when people go to the vc spec, they will see the v1.1. in that spec, there will be highlighted markers of the candidate corrections..
… that should be proposed correction instead of candidate corrections. there are 8 different phrases we could use, i think we’re using a proposed correction. instead of a proposed recommendation, we are doing a proposed correction..
… that means the email must be updated. there are markers all throughout the document that say stuff like that. so that’s new. in the future, they will require a diff between the old and new spec..
… anything that is pulled in that could be a proposed correction, needs that section. the editors have to go in to manually add it today, meaning a lot more effort than before. there’s no easy solution to this, and doing these types of proposed correction document is a difficult thing right now..
… it’s not as lightweight of a process that everyone thought it was supposed to be. it’s out there and will be published november 9th.
… it will go out, and take the place in TR of the 1.0 spec, and we will have 70 days minimum before these things are actually ratified by the AC, so the AC can review and have formal objections. once that happens, we have to go back into the document, and remove all the candidate correction language + diffs, into a normal spec..
… so DavidC that’s why i wanted to mention the new process, because it makes it very difficult to do that. i think we’re good, but just found one more thing that we need to fix, unless the publication team comes back another time with more items to correct.
… i think we’re good to go for a november 9th publication. brent, you may want to call for objections to see if people are okay with this approach. i don’t think i changed anything of substance–i think it would be good to not have any surprises from the working group, so perhaps we should ask them if there are any changes we can talk through now..
Brent Zundel: thank you manu. the process certainly is heavy, and thanks for getting us to this point. part of the difficulty that manu and kyle have so adeptly handled is going to assemble our working mode moving fwd. we’ll talk about this throughout the rest of the meeting..
3.1. Clarification of JWT encoding (pr vc-data-model#828)
See github pull request vc-data-model#828.
David Chadwick: what i need to understand is what happens to the existing PR for v1.1 not in the text manu has pointed to..
… manu said that anything new will be exceedingly difficult. in that case, the outstanding PR needs to go in before the 9th of november. the other day, talking about the VC-HTTP-API working group, manu said there’s no problem making changes in v1 through january..
Manu Sporny: let me try to explain. my understanding of the whole process has been changing every 2 days, because the process document doesn’t outline everything that comes into play..
… we should merge in editorial things into 1.1 as soon as we can, which is almost immediately. these will go into the active working draft, so if people look at the editor’s draft it’ll be there. after january 14th, if those things are purely editorial, we will be able to publish those changes..
… we have to freeze things for the AC to review then. if it is truly editorial, then it will get in there. what we learned was about how difficult it was to get things into the document as the AC was reviewing..
… before, we decided 1.1 and 1.2 path, and then we decided not to have two branches. because there is only one path now, we cannot easily push out editorial changes into the space, until january 14th.
… we can merge editorial changes into the 1.1 branch, and once jan 14th hits, we can push it out as an editorial update and good to go.
David Chadwick: is 1.1 containing the normative changes in there from 1.2?.
Manu Sporny: yes.
David Chadwick: we should put in the changes this week then.
Brent Zundel: we can merge any PRs that are editorial and within scope of 1.1, we can merge into the v1.1 branch, and accumulate a body of editorial changes..
… the TR space recommendation that is currently under review, we’re not gonna touch that..
… once the review period is over, regardless of the outcome, we will have the option of then merging the body of the editorial changes into the 1.1 branch. the work we’re doing isn’t going to be lost..
… the PRs in the queue to merge into 1.1, we can refine those and merge in them in, but the precise time they will be published into TR space will not happen until jan..
Kyle Den Hartog: with the intent of doing a V2 spec pretty soon after, we have to work through the chartering stuff. the intent of any of these substantive changes that are coming in is to have them fit into the pure view of the v2 scope. some of the more substantive changes we’ve been looking at, related to jwt work, we’re talking about separating out the proof suites into separate documents about them specifically.
Kyle Den Hartog: so it could be useful to hold off on the jwt work, because we would want to see jwt into its own document. in that case it would make sense for those things to work together. while it’s difficult for us to get stuff into 1.1, it’s not the intent of the WG to stall the work, there’s just a slight delay due to rechartering..
David Chadwick: that’s fine, i don’t mind a separate document for JWT next time around, but the situation we’re in at the moment, is that the current JWT section in the spec lacks clarity, and the PR brings the clarity. in my opinion, it’s imperative that those changes go in the 9th of november..
… the key aspects of that PR must go into the spec by the 9th of november. people have been saying there’s a lack of clarity, and there’s no reason for that not to be included except for slow responsiveness..
… i feel very strongly about this, because we’re doing a disservice to the world community without the clarity.
Kyle Den Hartog: is this actually editorial?.
David Chadwick: the current spec doesn’t say anything about how bearer credentials are dealt with. this PR clarifies what people can infer but may have inferred wrongly..
Manu Sporny: pull 828?.
Brent Zundel: yes.
David Chadwick: the one to do with JWT is the important one, which adds text.
… feedback from orie that this is really good.
Manu Sporny: just on the responsiveness, you raised the PR days ago, responses from ted and markus on the day. i retargeted the branch, there were merge conflicts. orie said it was good but don’t merge, 2 days ago, esp. with the removal of nonce.
Manu Sporny: See latest commit diffs.
Manu Sporny: there is a change to normative language, like 3455, you’re changing a MAY to a SHOULD.
… if you remove that line, i think it’d be editorial, and with that and merge conflicts fixed, we could see it in. please don’t merge it before november 9th, but it’s many hours of work for the editors. so either it’s a normative change and that’s problematic, or it’s an editorial change and doesn’t affect implementers..
… we do get this into the publication, in the editorial version, as soon as the merge conflicts are resolved, we can merge that into 1.1 so it’s live on the editorial branch. once jan 14th hits, it’ll go out in the live version and get the changes you want in the spec in there..
Brent Zundel: making an assertion and asking a response to you DavidC. i am asserting that further editorial changes will not be made to the document that is being reviewed by the AC. and having made that assertion, i must ask, in light of that, is it your intention to formally object to the document that is under review?.
David Chadwick: i’d like the changes in.
Brent Zundel: if that doesn’t happen, would you formally object?.
David Chadwick: i will discuss with the people who have asked for the changes and see if it’s acceptable or not. i was in the fortunate position of understanding the JWTs because i was part of the VC drafting process. but the majority of the people implementing do not have the background and knowledge..
… if they say they would like it in the document, i will object. it depends on what other stakeholders who have had problems figuring out exactly how to do it..
Brent Zundel: no one is saying we don’t want these changes. it’s about timing-wise.
… either we ask our editors to spend hours and hours of work to merge in the changes outstanding, or publish what we have already documented on the 9th, while continuing to refine your PR, and as soon as it’s ready merge into the 1.1 branch. as soon as review period over, and candidate merged into the rec, we can take that candidate 1.1 branch and merge into the recommendation as needed..
David Chadwick: will the draft be visible to people?.
Brent Zundel: yes, it will be possible to point to people to a published document that we can say will be coming on jan 15th.
David Chadwick: are you saying that the pointer in the document which manu pointed us to, which is w3c recommendation 9th of november, 1.1, where it says latest editor’s draft, that will have the PR in it for JWT once it’s been agreed to. is that right?.
Brent Zundel: yes.
David Chadwick: so people will have that visible?.
Brent Zundel: yes, it won’t be TR space.
David Chadwick: that may be acceptable.
… i just want people to know it’s not hidden, because it’s important that people can see it.
Brent Zundel: totally agreed, it’s just about the timing & process.
David Chadwick: i don’t want to give you hours of work, that’s not fair. it’s just sad that this wasn’t done more quickly.
Brent Zundel: no disagreement.
… anything else?.
Kyle Den Hartog: when you’re in conversations with these people who may object, the solution we’ve put forward, can you be sure to mention that the text going into v1.1 editor’s draft will be there. i’ll put a link before closing the PR so it’s easier for people to find in the editor’s draft in the intermediary..
David Chadwick: they will just need to see the v1.1, click the “latest editor’s draft” and see it anyway. that’s what brent said.
Manu Sporny: quick reminder, it came from “i’m representing…” it’s problematic to potentially cross anti-trust boundaries at W3C. big companies have been known to hire small companies to pack a room, not saying you’re doing that, but it’s really that kind of behavior that’s frowned upon at w3c. these people can jump on the issue tracker and provide the feedback to this group, and they should not be doing it through you.
Manu Sporny: it makes it difficult to have a direct conversation with people who have the issue…
4. Review PRs.
Brent Zundel: https://github.com/w3c/vc-data-model/pulls.
Brent Zundel: 3 prs as editorial, 3 prs not yet labeled.
… we’ll focus on those, not the v2.0 ones.
… i’ll follow the numerical order for this conversation.
4.1. add section in privacy considerations about issuer (pr vc-data-model#830)
See github pull request vc-data-model#830.
Brent Zundel: 830: adds a privacy consideration with issuer participation related to the possible privacy protections. encourage folks to jump in and review.
Kyle Den Hartog: no normative changes, makes sense.
Manu Sporny: agree, it’s editorial..
Kyle Den Hartog: let’s manage it as an editorial change into 1.1.
Brent Zundel: any opposition to adding the v1.1 label?.
… if we have a issue already tagged errata, we don’t need to tag it as such. it’s attached to 209.
4.2. Add clarification about verifiability (pr vc-data-model#829)
See github pull request vc-data-model#829.
Brent Zundel: next PR is 829, clarification about verifiability from charles lehner.
… don’t see charles on the call today, but would encourage folks to review this PR.
Kyle Den Hartog: anytime those SVGs are included, that’s a mistake as the SVG changes haven’t been merged into main, we may work with ivan to clean this up prior to merge.
Brent Zundel: for other folks creating PRs, since we’re merging into the v1.1 branch, rather than basing your changes off of main, base it off of v1.1.
Manu Sporny: once charles fixes the svg, it should be editorial.
Brent Zundel: would anyone object to labeling this as v1.1 editorial?.
4.3. Clarification of JWT encoding (pr vc-data-model#828)
See github pull request vc-data-model#828.
Brent Zundel: david’s PR, 828, you’re welcome to walk us through this set of changes.
David Chadwick: i don’t see the same text i saw when manu said it…the MAY/SHOULD is not visible to me.
Brent Zundel: sharing my screen. on 3455, we have may going to should.
David Chadwick: this is the only one that is still contentious. i didn’t think this was a normative change from the implementation perspective, therefore there’s no mandatory requirement. ted, are you available to comment on this?.
… it was the fact that changing a MAY to a SHOULD, is that a normative change? it doesn’t affect implementors.
Ted Thibodeau Jr.: it is a normative change but does not make an implementation of the MAY non-compliant..
… it is normative, but does not force implementation change.
David Chadwick: so the real issue is: is this prohibited from the v1.1 editorial?.
Kyle Den Hartog: the precedent we’ve held throughout this WG is any change to normative text requires it to be a substantive change, based on my reading of the different classification of changes in the W3C process, so my preference is to leave it as a MAY for now, SHOULD later when it’s easier.
Manu Sporny: the danger DavidC is that if we make that an editorial change, any W3C member can force us to put everything through a candidate correction, making all the editorial changes we’ve made under review, adding months to timeline.
… we should probably do MAY.
… we don’t let any of the other PRs to touch normative language if they were editorial.
… it doesn’t make a difference at that particular line, the rest of the stuff is very easy, we can merge it sooner than later.
David Chadwick: agreed, we will keep the normative text as-is.
… the other issue brought up by Orie, was removal of the nonce.
… there is no nonce as a JWT claim, it doesn’t exist. there’s no text anywhere in the spec.
… we put the nonce in the VP claim.
Brent Zundel: we are out of time.
… the text of this conversation will go into the PR.
… you need to have the conversation w/ Orie.
David Chadwick: already in the PR.
Brent Zundel: the process of determining this is still ongoing..
… Agree that changing may to should is probably not substantive, but don’t know if we need to go down that road..
… MAY -> SHOULD is arguably not substantive, but we’re not sure if we want to go down that road.
David Chadwick: yeah probably not.
Brent Zundel: Thanks to everyone that came, still have v1.1. issues.
… you’re all fantastic bye.
… Hopefully we have a chance to look at that next time, thanks to wayne for scribing, see you next week..