Verifiable Credentials Working Group TPAC, 2nd day — Minutes

Date: 2021-10-27

Attendees

Present: Ivan Herman, Charles Lehner, Phil Archer, Brent Zundel, Manu Sporny, Wayne Chang, Shigeya Suzuki, Ryan Grant, Ted Thibodeau Jr., Drummond Reed, Juan Caballero, Kevin Dean, Geun-Hyung Kim, Kyle Den Hartog

Regrets:

Guests: Jay Kishigami, Ned Smith, Rachel Yager, John Bradley

Chair: Brent Zundel

Scribe(s): Manu Sporny, Charles Lehner, Juan Caballero

Content:

1. Current Status of Revised Recommendation.
2. Issue Processing (yay).

Brent Zundel: Welcome everyone, we’re going to start in a bit..
… Welcome to our final day at TPAC for VCWG.
… We will need a scribe during the second hour, can pause at that point. Agenda review….
… We will look at current status of revised Recommendation, finalizing of v1.1 vs. v1.2 – then we’re going to spend the bulk doing issue processing. We’ll begin with v1.1 issues… we’ll look to see “Is this issue one we want to address and who is going to do the work?”. If we don’t have a volunteer, we’ll add defer-v2 labels so we can move on to wrapping things up. Any comments/questions about the Agenda?.
… Let’s do some introductions for people that didn’t introduce themselves yesterday. We are in #vcwg IRC channel, please present+ yourselves..
… Anyone that wasn’t able to introduce yourself yesterday?.

Kevin Dean: Hello, I’m Kevin Dean with GS1, joined the WG because we’re working on VCs to support identification and licensing system..

Ryan Grant: Hi I’m the AC Rep for Digital Contract Design, Ryan Grant, DCD makes software that implements the BTCR DID Method, we have libraries for the underlying implementation of the method. I’m also one of the authors of that Method specification, we’re also working on apps that implement an identity wallet type wallet functionality..

Drummond Reed: Hi, Drummond Reed at Evernym, Chief Trust Officer, one of the Editors on the DID Core specification for 5+ years, would love to see that concluded. Also very involved in Verifiable Credentials wrt. Trust Over IP Foundation called AC/DC – Authentic Chained Data Containers, to have chaining properties would love to see part of next generation of VCs..

Juan Caballero: My name is Juan Caballero, work at Spruce with Wayne, happy to be here, also work with DIF, happy to answer any questions about either..

Brent Zundel: Let’s jump into our first topic..

1. Current Status of Revised Recommendation.

Manu Sporny: See email containing links to the latest proposed revised REC.

Manu Sporny: See the document contents.

Manu Sporny: See Diff-marked copy for the entire document.

Manu Sporny: I have prepared a new REC document for review. You can look at the actual document ^ - the latest for review, without markup.
… This is the v1.2 document with all editorial and substantive changes to date.
… Operating under a new process, a new way to update recommendations.
… Will put links for new process later.
… We’re proposing a revised rec with substantive changes - We changed things that would cause implementations to potentially have to change..
… The changes however would not affect existing implementations. Implementations out there today should continue to work just fine..
… We loosened some requirements… don’t need to necessarily update the test suite… It should be made a little less strict….

Ivan Herman: See 2021 version of the process.

Manu Sporny: We made substantive changes to align better with reality..
… Process says it has to go through AC review. We have to request a last call for review of proposed changes, to the advisory committee..
… Have to do four things: 1. say we agree to do this. 2. list the proposed corrections..

Ivan Herman: We are publishing a document that looks like a revised rec… probably the date should be changed to be when we are going to do that. Should make a version where only the substantive changes appear….

Manu Sporny: I get it….
… we are the guinea pigs.
… We have a 60 day comment period basically. If we say by end of this call, 60 days is end of September, a crazy tight timeline for review.
… 4th item: Need to make sure this reflects the latest implementation experience, which it does. Need to call for broad review if it needs it (It doesn’t).
… Need to ask for comments. Set publication date to Jan 18 2022, to set expectations for when we expect it published at the earliest..
… Brent, we should probably go through each change.

Brent Zundel: We made a resolution… that set of changes has not changed. We have a resolution on record for that. As long as that set of 4 substantive changes has not changed, we should be good with that original changes..

Manu Sporny: Apologies I was not there.

Brent Zundel: You were on vacation….

Brent Zundel: link to resolution: https://www.w3.org/2017/vc/WG/Meetings/Minutes/2021-10-06-vcwg#res.

Manu Sporny: So we’re good to go… need to make some manual changes.

Brent Zundel: Process-related changes to the document will be required before sending out for review.

Manu Sporny: Just to make sure I’m clear about what needs to be done… Ivan, I’m planning to take the raw document as we expect it to exist, take the full diff-marked version, splice pieces of that into the final REC..
… There will be 4 diff-marked sections that I move over to the clean version. Is my understanding correct?.

Ivan Herman: I think that’s our common understanding indeed..
… I think that because we are guinea pigs, we should CC Phillip on each step we do on that, as he is the final arbiter. For the others this is the first document to be published under the proposed amendment… that’s why we’re guinea pigs.
… Note that Respec will be updated when the new process date comes into the picture… I don’t know if there is a separate spec status… Need to check that as well..

Manu Sporny: I checked and there wasn’t one.

Ivan Herman: But that was not the new one..

Manu Sporny: OK, it’s clear to me what needs to be done. I think we should complain loudly….

Ivan Herman: I have already… that we need tooling for that… Everybody agrees, it’s on the TODO list of whoever is to do that.

Manu Sporny: Other issue, if don’t have a full diff-marked copy to send for AC review, things could slip through….
… So many times I caught issues when generating a full diff… very concerned to get rid of that part of the process.

Ivan Herman: I think we can keep a pointer to the diff somewhere.

Manu Sporny: OK, crystal clear. Ivan, do you have timing… I’ll let you know…?.

Ivan Herman: I will be out on a trip….

Manu Sporny: If slips past 30th of October, 60 days goes into January….

Ivan Herman: I don’t like it to be so tight… something could go wrong.

Manu Sporny: Could it go out before the 15th of November?.
… In the document I have to say when we expect review comments by… January 15th.

Ivan Herman: The publication date should be 16th, a Tuesday. Let’s try to get that… that should be realistic..
… I don’t know how long the transition request will be….

Manu Sporny: I’m saying expect comments by 15th/16th, and put the REC publication date by end of January.

Ivan Herman: I agree, let’s not make it too tight, it doesn’t help.

Manu Sporny: OK, I’ve got those dates..
… Comments in by January 14th. Review request….

Ivan Herman: Review request should go out by end of next week.

Manu Sporny: … and then we will publish on January 25th.

Ivan Herman: But don’t have to set that yet….

Manu Sporny: Has to be put in the REC.

Ivan Herman: That’s not cast in concrete.

Brent Zundel: Thanks, a fantastic review of where we are.

Manu Sporny: I looked and didn’t find anything.

Brent Zundel: It looks cool, just wanted to share that.
… Ok, what we want to finalize is now that we have done all substantive changes that we’ve been able to, what does that mean as far as what version are we working on?.
… v1.1 is editorial, v1.2 is substantive..
… My suggestion is that we continue to call v1.1 editorial… v1.1 – when we have body of that work complete, we just fold it into revised recommendation that is published, editorial, don’t require review. My feeling on where we could go..

Ivan Herman: I am officially and on record, mixed up… the one that we will publish, which version is that v1.2?.

Brent Zundel: We’re calling it v1.2.

Manu Sporny: Yes, the document we were just talking about is v1.2.
… My suggestion is I think aligned with what Brent is saying, that is… the editorial thing is v1.1. we’ve been talking about it being v1.1 for a while.
… it will take a while to publish v1.2… 3 months from now.
… We have the opportunity in the interim to publish v1.1… that will last a few months.
… If v1.2 is approved by the AC, we will publish v1.2..
… We should talk about the challenges of doing 2 parallel tracks… But I think we have the ability to keep doing 1.1 changes, editorial things… and publish v1.2 in January.
… I note it will be a massive pain for the editors to keep everything straight.
… The only branch I’m confident about is the v1.2 branch.
… We will have to go through the changelog in v1.2 and make sure we apply everything in v1.1 that makes sense..
… I made changes to v1.2, those need to be backported to v1.1, I can do that….
… But it’s a pain to keep these two parallel tracks aligned… We should talk about that in the future.
… My suggestion is to get v1.1 quickly - purely editorial..
… Then wait to get 1.2 out at end of January.

Kyle Den Hartog: +1.

Manu Sporny: And then my strong suggestion is to defer everything to v2… Other changes are hard to manage.

Kyle Den Hartog: Well put there manu.

Ivan Herman: From my point of view, this sounds like – why make it simple if we can make it complicated. :) – what is the real value of publishing v1.1 right now when in a few weeks we’ll publish another version?.
… I would propose to just publish one thing in January, which would include both the editorial and substantive changes – call that v1.1 and then call it a day. I don’t see the value of over complicating things..
… What we will submit to the AC for review that must be a branch out of whatever we publish under v1.1 otherwise, for the AC that will be lost. v1.1 will be live for a few weeks, is really not interesting..
… So, for the community, we publish v1.1 that has substantive changes, then we move to v2.0 and that’s a different thing..
… There would be several months gap between purely editorial and something that has a revision… that didn’t happen for whatever reason, now it doesn’t make sense to have v1.1 live for 3 weeks..

Brent Zundel: Do we need to publish a v1.1, or can we fold everything into v1.2 in january..

Ivan Herman: re: 3 months – whatever we publish for AC Review is a REC except for where there is a difference. As soon as that goes out, the authoritative source is version that goes to review. Remember, if we republish REC, that one will be authoritative, v1.1 will literally only be alive for a few weeks only..

Ryan Grant: +1 to taking the implementor’s perspective.

Kyle Den Hartog: In the grand scheme of things….
… Looking a few years down the track, simplest thing wrt. relying on this or read the spec is to combine everything together… turn v1.2 into v1.1 and treat them all together. Only aspects that remain hard is to figure out how we go commit by commit to add things into changelog. I think we can get Editorial spin on it to group things together… keep changelog to a high level, advantage here is down the track… v1.1 vs. v1.2 isn’t going to run into problem wrt. interop w/ v1.1 and v1.2?.
… I think we’re in a tough situation here, probably what Ivan is proposing is a good middle ground solution when thinking about it in a long term way..

Manu Sporny: I’m a bit torn… I wouldn’t object to us just doing a v1.1, and what we were talking about as v1.2 is really v1.1 and it simplifies everything… However, what that would cause is to defer everything to v2. No editorial changes, nothing new going into spec, until 2.0 happens. So basically we’re done if we make that decision..
… Keep in mind that we turned off auto-publishing in the main spec..
… This raises a questions, what exactly is our interim every-6-month publishing strategy?.
… What happens when people find a bug and want to push a fix….
… My concern is that we tried to use the new process, it didn’t work out, due to a variety of factors. Now we’re making a decision making it impossible to get out anything..
… We’re not using the new process to get editorial changes into the latest REC spec, because that would be the old 1.1… saying not do that, too difficult, next version will be 1.2, locked out of editorial changes - not getting anything in before end of January.
… then have to make decision to defer everything to v2. that would make today’s meeting short..
… Sounds like a simple decision but has huge ramifications for how the WG would operate until end of January..

Phil Archer: I wasn’t expecting Manu to say all that – needs listening to – not as familiar with new process… if any new version has to go through AC Review, concerned about current political situation..
… The more chances we give the AC to do that, given the current sensitivities, I think we do need to be careful that we don’t stir the hornets nest more than necessary..

Ivan Herman: I’ll come back to what you said, Phil..

Drummond Reed: +1 to Phil’s point.

Ivan Herman: Back to what Manu said – what we are freezing is the period between now and 2nd half of January – once that’s out, I’m not sure what we call v2.0? If we have editorial changes that come up at beginning of Feb, we can republish v1.1 as much as we want, substantive changes require W3C AC Review, but v1.1 requires editorial changes. Yes, we would have to freeze between now and 2nd half of January. I don’t know what we call v2.0 - major technical changes, that will take a long time..
… in between, editorial can be taken care of at any time, just to moderate a bit what Manu said..
… Phil, what you say is absolutely correct, this is a question I had to W3C management – yes, any AC Rep is in position to raise issues and Formal Objections, even against features that are not subject to review right now. They have the ability to raise comments on the REC as it will become as a whole..
… That in the current situation is a dangerous thing….

Kevin Dean: As a general rule in GS1 standards development, minor revisions are expected to not introduce breaking changes. Major revisions don’t have that guarantee..

Brent Zundel: My understanding of process that we’re following for revising recommendation, submitting Candidate Corrections for review, if they pass review, we can fold it into REC. We can also make any set of editorial changes and we can fold those into REC at any time. My understanding is that when we request publication in Jan of v1.1, we passed review of Candidate Corrections, along with this set of editorial changes, publishing in January. I don’t see why we can’t continue to curate set of items that can go into REC when published..
… That’s my reading of 2021 Process..

Phil Archer: The other thing about timing of each thing, of course it’s correct, finishing v2.0 will take 18 months… but you get your FPWD out much sooner than that, that might mitigate from having version out there..

Manu Sporny: All good things. Agree with Ivan, and with Phil. My concern is, let’s say we do this and say we are going to publish a v1.1, and get a formal objection. That will invoke the new FO process..
… DID Core is already the second-longest-delayed REC, and we have no ETA on when they will take up that FO as there are two in front of it..
… If there is a FO on VC, that will go in the queue behind that. Talking about a delay at least 60 days….
… Director could make a decision, not to go to the council….
… (I think Ivan disagrees.) That’s part of my concern - I’m fine with any variation of these. I’m concerned we’ve had a long time to publish v1.1 things and we continue to not do that, and may skip doing it, to just start over with a new v1.1 and do editorial things then….

Brent Zundel: +1 to manu, unfortunately.

Manu Sporny: I’m concerned we don’t have a process for editorial changes… Kicking the can down the road… Need a process… And we don’t tie success of one to the other.
… We should be making fairly regular updates….
… If we tie it to publication, that affects the rhythm..
… Need to get clear on how we’re publishing editorial updates to the recommendation, since we have not done that do date, and should figure out how to do that..

Kyle Den Hartog: I think what manu is suggesting is an important point, there’s a fine balance here, specs aren’t meant to be as agile as a library… v1.1.67 for example, every six months some editorial changes put in place. We probably need to firm up within the process irregardless..
… The reason I’m ok w/ combining is because I want to make sure the substantive changes make it in, especially because of the politics around DID Core… not sure what’s going to happen to objection to v2.0 chartering, so would rather have something in, rather than just editorial things in… but then getting blocked because we can’t recharter VCWG 2.0. Because we don’t have the process in place firmly, because we have v2.0 ready to go, I feel like it makes sense to publish everything together right now and then come back to reconvene, if we’re allowed to, firm up editorial aspects then..

Phil Archer: This is difficult, I agree with everyone – Manu’s point is well taken, so is kyle’s – frustrated that we are spending so much time on this. I think I am persuaded, if Editors are willing to do it, difference in purpose between v1.1 editorial… v1.2 substantive… those are good reasons to publish, publishing them separately… good reason..
… It’s ridiculous to publish a document when you have next version ready… but they do have different purposes, I’m torn..

Ivan Herman: When you publish an Editorial version, webmaster does that and no formal objections possible..
… There is no way process-wise to formally object to v1.1 if it’s purely editorial..
… For a v1.2 if its substantial, that can be formally objected to..

Brent Zundel: In the event that formal objections are raised to substantive items and they’re upheld, then you go back to v1.0..
… I think we’ve come to some conclusions – to kyle and manu – do you have a clear picture of what is going to happen moving forward..

Kyle Den Hartog: I think so… we are going to try v1.1 quickly, and then propose v1.2 after..

Manu Sporny: I’m confused.
… I think I agree with what Kyle said, but to modulate… I think we can do it in parallel. v1.2 request is important to get into the pipeline. Send to Ivan, as discussed, to send to AC..
… In the meantime we can try to work 1.1 in parallel..

Ivan Herman: We went through that in DID WG, for CR, that led to problems… once we give a version to Director to decide if it can go on, that’s it. We can only publish v1.1 is between now and time we submit request to Director to review..
… We did that once for DID CR snapshot, and in parallel thanks to echidna, new versions coming up… let’s not go there..

Manu Sporny: Let me try to simplify. We’ll take v1.2 branch, rename to v1.1, put in the transition request. Everything else, if we want editorial changes, will go on top of v1.1. No more v1.2..

Ted Thibodeau Jr.: (could just delete 1.1 “this was never published” and move on with 1.2).

Manu Sporny: That simplifies everything, and just hold our noses that we did not get editorial changes in before the substantive ones. Kyle, does that work?.

Kyle Den Hartog: Ok, works for me..

Brent Zundel: We’re going to, like yesterday, stop at 10 before the top of the hour… let’s meet back in 5 minutes… see if we can get a scribe..
… We’re going to dive back into v1.1 editorial issues, see what we can get accomplished there… see you in 5 minutes..

Manu Sporny: yw, no worries.

2. Issue Processing (yay).

Brent Zundel: review of issues filtering by 1.1 tags, trying to defer as many as reasonable to 2.

Manu Sporny: given the decision we just made about 1.1, everything non-editorial should be deferred to v2, yes?.

Brent Zundel: correct.
… with the recognition that this process could still produce issues and PRs that hang in the repo until group reboots.
… and that no work will be lost, even if substantive changes are moratoriumed.

Manu Sporny: are we basically getting rid of v1.2 tag? do editorial v1.2s –> v1.1 and non-ed v1.2s –> defer v2?.

Brent Zundel: mostly, yes; editors reserve the right to re-tag for simplicity and timeline reasons.

Kyle Den Hartog: i think we need to remember that open issues display as errata.
… and closed issues with related open PRs can be confusing….

Kyle Den Hartog: This is the document I’m referencing: https://w3c.github.io/vc-data-model/errata.html.

Brent Zundel: to clarify, there are two labels: possible-errata and errata – the latter means WG agreed to consider this as errata and they CAN be addressed before v2; your comment about related PRs being tagged errata seems like a good process change to consider for the reasons you describe.

Ivan Herman: +1 to brent.

Kyle Den Hartog: yup, let’s clean up those tags, then.
… do we want to keep the errata label even where defer-v2 is also tagged?.

Brent Zundel: yes, future group could remove errata when it processes the v2 queue.

Ivan Herman: when we publish 1.1, we should be careful about removing the errata tags for the issues already addressed; errata file should only include errata that remain open/unresolved at time of 1.1 closure.

Manu Sporny: i have redone all the labels during the 5min break: v1.1 –> v1.1-editorial; v1.2 –>v1.1-substantive, defer-v2 –> v2.0.

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3A%22v1.1+%28editorial%29%22+sort%3Aupdated-asc.

Kyle Den Hartog: +1 thanks manu.

Kyle Den Hartog: i think there are PRs hanging open that I could/should have closed, should I commando them or wait for the group?.

2.1. DVCG references in bibliography need to be updated (issue vc-data-model#746)

See github issue vc-data-model#746.

Brent Zundel: the latter.

Manu Sporny: errata works how again?.

Brent Zundel: leave errata on issue, remove errata from PR, and remove errata from issue IF ADDRESSED at 1.1 closure time.

Kyle Den Hartog: i’ll close this issue and fix labels now.

Manu Sporny: close-comment with link to related PR would be good BEFORE relabel.

Brent Zundel: and these minutes will get autolinked anyways.

2.2. Example uses DriversLicense as evidence for a UniversityDegreeCredential (issue vc-data-model#754)

See github issue vc-data-model#754.

Kyle Den Hartog: quick report-out, no controversy, already addressed, cleaning up now.

2.3. V1 specification doesn’t definitively state that the credentialSubject.id, if specified, is always the id of the Subject of the Credential (issue vc-data-model#792)

See github issue vc-data-model#792.

Manu Sporny: one PR opened but closed, and related changes made in a bigger, still-open PR….

Brent Zundel: I think this needs to be deferred because it’s more than we can get to quickly.
… and should be considered by the v2 group.
… objections?.

Juan Caballero: (none).

2.4. Clarify the difference between Credential and Verifiable Credential (issue vc-data-model#798)

See github issue vc-data-model#798.

Manu Sporny: i remember a PR merged that addressed this, i think we’re done and good to close here.

Brent Zundel: kyle, i see you commenting on the thread, anything to add?.

Kyle Den Hartog: i can’t remember what happened with pull 808.

Manu Sporny: I remember, this PR was mis-targeted to main, commits had to be cherry-picked before walking back from main.
… in 824… i want us to make sure we’re linking the right PR and the PR got merged to the right branch.

Kyle Den Hartog: yup i’m looking at the commit right here, it’s on the v1.1 branch, we’re good to close.

2.5. Inconsistencies between Figures and examples (issue vc-data-model#727)

See github issue vc-data-model#727.

Kyle Den Hartog: +1.

phil: assumes intent that this WG never committed to.

Kevin Dean: matching them up would imply more causal or explanatory logic, would be an anti-pattern.

Brent Zundel: as editor, i would say that if someone thinks examples SHOULD line up to figures, they should open a PR but that was never work the group committed to.
… marking as pending close, not worrying about labels.

2.6. Can a credentialSubject be only a string value? (issue vc-data-model#762)

See github issue vc-data-model#762.

Kyle Den Hartog: no PR addressed to this, WG agreed it was editorial, was deprioritized.
… but could be deferred, which would be my leaning here.

Brent Zundel: any objections to labelling v2?.

Juan Caballero: (none).

2.7. Remove proof property from most examples (issue vc-data-model#811)

See github issue vc-data-model#811.

Manu Sporny: seems a lot of work, more than 1.1 timeline allows.

Kyle Den Hartog: +1 from me, manu speaks my mind.

Brent Zundel: for the record, any issue labeled as editorial can be PRd at any time, regardless of version timelines! feel free to do this, if you’re listening/reading this and have strong feelings.

2.8. [VC-DATA-MODEL] This recommendation has no stated purpose, goals, or intended audience statements. (issue vc-data-model#813)

See github issue vc-data-model#813.

Brent Zundel: most of this conversation is between me and issue-raiser, it gets kinda meta at times….

Kyle Den Hartog: +1 with that plan.

Manu Sporny: i would recommend marking it v2 and assign a PR to michael (the raiser).

Brent Zundel: objections?.

Juan Caballero: (none).

2.9. VC-DATA-MODEL: adding more examples of non json-ld credentials (issue vc-data-model#815)

See github issue vc-data-model#815.

Brent Zundel: sidebar: as yet no volunteers for v1.1 PRs, for better or for worse!.
… overview: anyone here who chimed in wants to comment?.

Manu Sporny: it feels like this is one in a series of similar issues asking for more things; also, i’m not sure a “non-LD credential” exists?.
… in the sense its used in this issue?.

Ted Thibodeau Jr.: +1 to manu’s comments.

Manu Sporny: this seems like it would be addressed by a tabbed layout for examples in v2.

Ryan Grant: +1.

Phil Archer: I would like to say that a tabbed example layout in v2 would be great and i’d volunteer to contribute.
… and support it.

Kyle Den Hartog: i think the lift of tabbed parallel-examples is large and that justifies deferring, we should tag it in a way that it gets considered as part of that in v2.

Manu Sporny: i have an idea how it could work, so soft-assign it to me?.

2.10. Example 45 contains “revocation” property not defined in LD contexts (issue vc-data-model#761)

See github issue vc-data-model#761.

Kyle Den Hartog: i think i know how to do it too, so i could do it if we need to re-distribute PR work later.

Brent Zundel: update from kyle?.

Kyle Den Hartog: i think there is an addressing PR here, we can definitely close this.

2.11. Clarify schema (issue vc-data-model#812)

See github issue vc-data-model#812.

Brent Zundel: David says here in the thread that it is address in 816, which is open….

Manu Sporny: what’s going on here? seems ready, but merge conflicts.
… already assigned to david, work already done, maybe just ping him again?.

Brent Zundel: I’ll just assign David and see if this can get done before 1.1.

2.12. JWT encoding (issue vc-data-model#809)

See github issue vc-data-model#809.

Manu Sporny: but these changes look a tiny bit normativeA?.

Kyle Den Hartog: I think we should discuss it on a call in more detail, this is hard to understand across all the requested changes….
… so i would propose we defer to v2.

Brent Zundel: it sounds like there are editorial changes this issue could track, and also normative changes that should wait for v2.
… manu: i think we should move the signing mechanics into a distinct spec per encoding, as we have discussed chartering the next WG to be able to do.
… i think we cleaned up well here and we should end on this tidy note.
… thanks to scribes and ivan and editors, see everyone next week!.