Verifiable Credentials Working Group Telco — Minutes

Date: 2024-09-11

Attendees

Present: Ivan Herman, David Chadwick, Brent Zundel, Kevin Dean, Hiroyuki Sano, Joshua Thomas, Will Abramson, Michael Jones, Joe Andrieu, Manu Sporny, Dave Longley, Wesley Smith, Ted Thibodeau Jr., Benjamin Young, Rob De Feo, Jennie Meier, Phillip Long

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Wesley Smith

Brent Zundel: See TPAC Participation sheet.

Joe Andrieu: want to sync about dinner for TPAC, get headcount and make reservation.

Manu Sporny: want to discuss European digital wallet work with the group and how it impacts our standards work.

Brent Zundel: if you are here for the first time and want to introduce yourself please do so.

Rob De Feo: not my first time but not fully joined, hi everyone, one of the integrators of this work.

Manu Sporny: welcome RobDeFeo to the group.

Brent Zundel: will talk today about TPAC, VCDM, EUDI wallet, controller document.

1. TPAC attendance.

Brent Zundel: See TPAC Participation sheet.

Brent Zundel: if you haven’t yet please sign up for TPAC attendance.
… for those attending, reminder that masking policy is no requirement for common areas, and up to working group for working group areas.
… if anyone would prefer that the group meet while masked please reach out to me.
… otherwise there will be no mask requirement.
… thanks to JoeAndrieu for finding dinner location Thurs evening, please indicate on sheet if planning to join.
… should have agenda proposed by next meeting.

2. EUDI Wallet.

Manu Sporny: the European Commission came out with some regulation language around what is going to be included, some of you in openId group know that the OID4 specs are no longer included.
… EUDI cannot include non-standards, as a result OID4 group aggressively trying to finalize specs.
… VCDM 1.1 is in the regulation, however if we want 2.0 to be in the regulation, we need to be done by end of year.
… we will miss current window, new window opens Jan/Feb, if we had gotten to rec by Nov it would have been great. It would still be great if that happens.
… Us being done sooner than later with set of docs that are ready would allow European regulation to cite the 2.0 stuff instead of the old 1.1 stuff.
… heads up to the group that there is time pressure on us being done, but shouldn’t rush if we end up in a bad state.

Ivan Herman: did you think of publishing VCDM earlier than the others? As that is not the critical one anymore, it is more or less done.
… delay is due to the controller document and dependencies is the issue.

Manu Sporny: that is an option, I am not suggesting a concrete plan, just sharing info for the group to discuss.
… the thing cited now is VCDM 1.1, 2.0 is very close if not done, haven’t been getting new issues for weeks now.
… VCDM by itself is an option, do other securing specs later, can see how far we get with controller document today.

3. VCDM Wrap Up.

Brent Zundel: https://github.com/w3c/vc-data-model/pulls.

Brent Zundel: we have 2 PRs we should briefly look at.
… will start with 1557.

3.1. Fix #1556 (pr vc-data-model#1557)

See github pull request vc-data-model#1557.

Brent Zundel: going to merge this one after the call, lots of approvals, has been open for a long time.
… minor but necessary changes.
… next is 1554.

3.2. Proof reading for Section 8 - Privacy (pr vc-data-model#1554)

See github pull request vc-data-model#1554.

Brent Zundel: editorial overview of the privacy considerations section done by gabe.

Manu Sporny: 100% OK with the PR before but then the abstract for the document got changed. The group has spent a lot of time getting the abstract language right, please look at the new abstract and decide if you prefer the new language.

Ted Thibodeau Jr.: an abstract is supposed to roughly summarize the whole document, not introduce you to the document. The current abstract is replicated 100% in the intro that follows. It is fine in the intro but not an abstract, so that is why I made the changes.

Manu Sporny: can we break that PR into a different PR so we can get the privacy changes in then discuss the abstract changes?

Joe Andrieu: +1 for a separate PR. I like updating the abstract, but let’s separate.

Manu Sporny: the new abstract might be inscrutable to someone not familiar with the document.

Ted Thibodeau Jr.: sure, can split PRs.

Brent Zundel: any other comments on this PR?

Ted Thibodeau Jr.: currently the abstract also exists 100% in the intro, in my change requests it has been changed in the intro but retained as the intro, if we are going to do the pull out of the abstract change, my revised paragraph should move to replace the existing abstract, any objection?

Joe Andrieu: +1 to that TallTed.

Brent Zundel: the fact that the abstract is a problem is a separate issue from privacy considerations, would like to see that resolved in separate PR.

Ted Thibodeau Jr.: I think this PR is broader than that but will see what I can do.
… it is broader than that, the initial comment on this is not proofreading privacy, it is that plus changes from a previous PR which is more broadly scoped.

Brent Zundel: thank you for the clarity, but my desire remains for a separate PR.

Ted Thibodeau Jr.: I will put my big block on the abstract in a separate PR, the remaining changes are to the introduction.

Manu Sporny: no issue with you doing that with a separate PR, Gabe started with privacy section and then began modifying other sections of the document.
… makes PR less focused.
… the current concern is that there are no objections to other text, but I am objecting to changes to abstract and introduction.
… I agree that there should be differences between abstract and intro, no issue with preserving what you have written into the introduction, needs to be in separate PR so the group can wordsmith.

Ted Thibodeau Jr.: I will adjust my change suggestions in this PR for the abstract and the intro.

Brent Zundel: moving to issues.

3.3. VCDM Issues.

Brent Zundel: See Open Issues.

Brent Zundel: we have 6 open issues, all are normative except for 1, the 1 normative one follows the conversation we had on hold-your-nose consensus on making the terminology section normative.
… let’s get status update on these.

3.4. Respec’s VC plugin still does not work (issue vc-data-model#1538)

See github issue vc-data-model#1538.

Brent Zundel: 1538, respec plugin still does not work, what is the status.

Benjamin Young: I believe it mostly works, just the jose-cose bit needs to be tested.

Brent Zundel: looking forward to the PR.

3.5. Rename VC Specifications Registry to VC Extensions (issue vc-data-model#1551)

See github issue vc-data-model#1551.

Brent Zundel: next up is 1551, which was a proposal to rename VC specs registry to VC extensions.
… I think this happened, is that right?

Manu Sporny: correct, that happened, waiting for redirects to be set up in TR space, let me know if you are waiting on something.

Ivan Herman: I put a long comment on that more than a week ago, the problem is that it is not that simple, I cannot change the redirect, need to republish the node, making clear that we are changing the name.
… I was not here when it was decided to change the repo/doc.
… I would have said that changing docs short name is not an easy business.
… not a matter of proposal/resolution, there is a proposal I wrote there to change things that I need to submit for administration, you have not commented.
… we are getting into publication moratorium now, all of this is now postponed until next week.
… sorry, but not my decision.

Manu Sporny: I think all of that is fine as long as it happens eventually.

Ivan Herman: ‘eventually’ is keyword, I will need your input.

3.6. A wrong VCDM 2.0 context URL (issue vc-data-model#1556)

See github issue vc-data-model#1556.

Brent Zundel: next is 1556, allowing VCDM 2.0 context URL, fixed in PR 1557, issue will be closed today.

3.7. Can we change `Usage Patterns` to `Patterns of Use` throughout? (issue vc-data-model#1555)

See github issue vc-data-model#1555.

Brent Zundel: next is 1555, last time we talked nobody objected to change “usage patterns” to “patterns of use”.
… waiting for that PR.

Manu Sporny: yes, I will do that PR :).

Manu Sporny: (or anyone else can too! ) :).

Manu Sporny: last week was controller document focused, this weekend hopefully can get back to VCDM queue.

Brent Zundel: editorial change, straightforward, anyone can take this PR.

Will Abramson: I can take that one.

3.8. Make Terminology section normative (issue vc-data-model#1558)

See github issue vc-data-model#1558.

Brent Zundel: next up 1558, summary of discussion is that it doesn’t really matter but might as well do it since it will make some people happy.

Michael Jones: PRs are done.

Manu Sporny: can I make this change across all specs.

Brent Zundel: any objections to manu making this change across all specs.
… hearing no objections, that is a reasonable course of action, thanks manu, please make a note when it is done so we can close the issue.

3.9. Remove ProblemDetails integer error codes, no implementations seem to use them (issue vc-data-model#1559)

See github issue vc-data-model#1559.

Brent Zundel: last issue to look at is 1559, remove problem details integer error codes.

Manu Sporny: we were having some discussions with implementers in the VC API group and it turns out that, we added integer error codes in an attempt to say, if you have an IOT device/software library that cannot return strings or objects in a verify call, we will give well known integer codes that you can respond with.
… none of the implementers that we know of use these integer error codes, and the issue is that we need to allocate them, theory was to allocate them based on level of library (low-high).
… people were like, what’s the use of having 32-64 be implementation defined, you cannot depend on the error code you get back.
… people unsure that this was needed, nobody spoke up, suggestion to remove this, doesn’t mean implementers cannot do it.

Brent Zundel: I love removing things from the spec.

Ivan Herman: yes that is no problem, just one warning, if you do that in the spec ideally you have to do it in the vocabs as well.
… these objects are defined as terms in the vocabulary as well.
… keep that in mind.

Rob De Feo: just a note on this, from implementer perspective, when reading through the spec and looking at verification endpoints/response, it states that response should be an array of strings, there is a mention further down for problem details, but we couldn’t figure out how to return it.
… that was partly why we didn’t do it, don’t know if other implementers have the same problem.

Manu Sporny: could you point out exactly where in the spec you read that.
… RobDeFeo if you could post this to Zoom we can raise an issue.

Brent Zundel: next topic, we can post link later.
… next on agenda is controller document.

4. Controller Document.

Brent Zundel: first will look at some PRs.

Brent Zundel: https://github.com/w3c/controller-document/pulls.

Brent Zundel: we have 4 open PRs.
… I believe all of them could benefit from some conversation, will start with 96.

4.1. Added an expiration property (pr controller-document#96)

See github pull request controller-document#96.

Brent Zundel: ivan, you have raised this PR, has been open for 4 hours, talk us through the changes.

Ivan Herman: dlongley updated the context file which I put in another PR, by looking at that I realized that with all the changes, the expire property is not mentioned as a potential property for verification methods, I believe it was in DI origin but got commented out in controller document, I believe that is a transition bug, I removed the comments to put it back.
… two comments, if this gets accepted I will have to make some changes in the vocabulary, and also the text that is there, which I did not write, is the same as for another property.
… I understand the difference between the two but the specification should make it clearer.

Manu Sporny: +1 to the PR, the differences are: expires is set before the thing expires as just a window, the revoked thing is that you must pay attention to revoked as the key was deactivated on a certain date for a very specific reason, while you should pay attention to expires.

Ivan Herman: I will modify the PR to make that difference clear and we can come back to it.

Michael Jones: the history of that comment and similar comments is that when I was sorting out what was common between controller document section in vc-jose-cose and that section in DI, anything that was not in both I put in comments, only put in stuff from both documents.

4.2. Demonstrate how ReSpec auto-generates RFC 2119 language. (pr controller-document#95)

See github pull request controller-document#95.

Brent Zundel: moving to PR 95.
… demonstrate how respect auto-generates RFC 2119 language.

Manu Sporny: all specs that W3C releases have a block of text in them that tells you how to interpret certain language (e.g. MUST, MAY). Respect autogenerates that paragraph, if you don’t use a word like SHALL, respect will not put that language in the boilerplate.

Dave Longley: -1 to deviate from W3C standard practice.

Manu Sporny: selfissued you feel like we should include all RFC language.
… I am suggesting we should not do that, as that is not how other specs work, respect generates the text when you use that language, I have raised a PR to demonstrate that is true.
… the diff for the PR shows that NOT RECOMMENDED was added by respec to the boilerplate language, we should not make this change, we should follow W3C policy.

Michael Jones: part of my issue was that we are not following policy, I now understand that respec is only generating the parts that we use, not a terrible problem, I think the tool is doing the wrong thing, but that is a tooling issue.

4.3. Alternative version of the “context and vocabulary” section (pr controller-document#92)

See github pull request controller-document#92.

Brent Zundel: for clarity, this PR and the related issue will be closed.
… next PR is 92, alternative version of the context and vocabulary section.
… some review, change requests, comments, they have not been addressed at this point.

Ivan Herman: there were several things happening in this PR, I don’t want to go to things that have been closed, have already mentioned dlongley for his contribution to the context file.
… two open things, one is that there are strange things happening, there were merge problems last week that I had to take care of, somehow the PR was referring to text in the document that was not my making and not in the changes.
… TallTed put editorial comments that I have no problems with against those parts, which is not the topic of this PR.
… those changes should be put in a separate PR.
… the other thing is that I took over Jeffery’s comment on context injection into this PR so that it is not lost, and I am not really sure what to do about the text.
… dlongley came up with a change suggestion that I found fine, Jeffery is still not happy.
… other than that it is ready to go.

Manu Sporny: thanks for the PR ivan, it strikes a good compromise, an hour ago I rebased the PR onto main and tried to address the merge conflicts, should be clean if TallTed does a re-review.
… another re-review from TallTed would be appreciated, I will also re-review and take another look at Jeffery’s issue, I can’t remember what the solution is there but it is a workable issue.

Ted Thibodeau Jr.: to be clear about what I make suggestions on, when I look at a PR in the files presentation, there are red sections that are deleted and green sections that are added, I focus on green sections. When there are unchanged sections that are contextually relevant I bring them in as well. With the rebase, some of the text that I have changed is not part of the PR, and I need to make another PR to figure out where my changes need to go.

Ivan Herman: your comment has been marked outdated as an effect of what manu has done, but I don’t want to remove them, I would prefer you close those when you move them to a new PR.
… this is what happens when he have 25 overlapping PRs that we merge, some of them create problems.

Ted Thibodeau Jr.: I will make the required changes.

Manu Sporny: just to be clear about what happened, whenever anyone merges things down to the main branch, make sure that all the commits make sense and do not say things like “fix typo”, please try to keep the history clean so the changelog is contained.
… when the commit history is unclear it makes things difficult, I had to rewrite sloppy commits and push it, in which case it disconnected all 18 PRs that we had, I needed to rebase all of them, that took 6 hours, please when you do a commit or pull in changes, make sure that commit makes sense when somebody else reads it. The reason TallTed’s changes got disconnected is automatic GitHub process.
… nobody actually went in and manually marked TallTed’s changes outdated, GitHub did it automatically. It’s not necessarily having 18 PRs in flight, it is when we are sloppy with the history and commit stuff to main that should not be committed, that is what creates that problem.

Brent Zundel: manu if you want to ping me with my chair hat on if we need to further discuss that’s fine.

Manu Sporny: honest mistake, happens once in a blue moon, just unfortunate when it happens when there are a lot of PRs in flight.

Brent Zundel: in general, don’t do merges to main, raise a PR.

4.4. Specify that controller overrides subject control. (pr controller-document#42)

See github pull request controller-document#42.

Brent Zundel: next PR #42, we have discussed this before, where we left off was that JoeAndrieu was going to propose different language, where are we at here?

Joe Andrieu: I haven’t done anything on this, will rehydrate and see where we are, but I did not meet your expectation.

See github issue controller-document#75.

Dave Longley: ^there’s some useful text there.

Brent Zundel: no worries, thank you for continuing to do the work.

Dave Longley: JoeAndrieu you did propose some alternate text that may or may not be reusable, just a reminder that that text is out there in the above linked issue.

Brent Zundel: we have some wording suggestions in issue 75 which I believe would help either modify PR 42 or result in a new PR, folks please look at issue 75.
… that will guide changing PR 42 or help us determine a resolution.

Manu Sporny: I was expecting to close 42 in favor of whatever PR JoeAndrieu raises, I’m fine to close this now, any objections?

Manu Sporny: I’ll leave PR 42 open if we’re unsure then.

Joe Andrieu: not sure we should close it but not sure that I want to stand in the way either, the issue has some language we can use, but there is disconnect between manu and I on meaning of controller property, looking forward to talking this out at TPAC.

Brent Zundel: going forward are we leaving PR 42 open for comparison? who is taking the action to move the proposed language into the spec?

Manu Sporny: I will work with JoeAndrieu to do that.

Brent Zundel: whatever we don’t solve next week on controller document we will talk about at TPAC.