Verifiable Credentials Working Group Telco — Minutes

Date: 2024-12-18

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Dmitri Zagidulin, Brent Zundel, Ted Thibodeau Jr., Mandy Venables, Wesley Smith, Manu Sporny, David Chadwick, Denken Chen, Dave Longley, Hiroyuki Sano, Will Abramson, Phillip Long, Michael Jones, Jennie Meier, David Lehn, Benjamin Young

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Wesley Smith

Content:

Brent Zundel: welcome everybody to the 12/18 VCWG meeting, we will not be holding a meeting on 12/25 or 1/1, after today our next meeting will be 1/8.

Brent Zundel: our agenda today consists of talking through the Controlled Identifier Document, and as time permits the status list document.

Manu Sporny: I would like to talk about where we are with the test suites and what is at risk of being removed from the specifications.

1. Test Suites.

Manu Sporny: We’re largely in good shape for VCDM 2.0, ECDSA/EDDSA cryptosuites, data integrity - the at-risk things for those specs are in progress with multiple implementers. For bitstring status list, of all the implementations that are currently in the test suite, and we have 7, none of them are implementing the variable size status mechanism.
… That is at-risk, and if we don’t have at least two independent implementations for that feature it will need to be removed from the spec. I don’t know where we are with VC JOSE-COSE and VC JSON schema, and BBS won’t be transitioned to rec in Q1 next year.

Brent Zundel: I know that mesur is intending to show support for multiple status lists, VC JOSE-COSE test suite just got a major update by decentralgabe and should be ready to receive implementations, for JSON schema it’s just a matter of getting the implementers to interface with the test suite.

Ivan Herman: Do we have new information about the normative status of SD-JWT?

Michael Jones: It has completed working group last call, there was a formal protest made by an individual, the area director responded, the editors incorporated the changes suggested by the area director, therefore it is probably within 1-2 weeks of the shepherd writeup and requested publication by the IETF.
… That means it undergoes review then goes to a group of area directors, then to the RFC editor. This usually takes about 4 months.

Ivan Herman: The idea is to go to proposed rec in the first half of Feb. SD-JWT must be recommendation level when we go to proposed rec for us to reference it.

Manu Sporny: If we don’t have some of these at-risk things done or specs are not in the proper place it will delay our ability to get to proposed recommendation. The other risk is Controllable Identifier Document, the publication of that has been delayed indefinitely until we get reviews back. We can go to PR with that in CR, but ideally we have CID in PR at the same time as the other documents.

2. CID.

2.1. Explain why one key format is not realistic. (pr cid#120)

See github pull request cid#120.

Brent Zundel: looking at CID PR 120.

Michael Jones: I now have more context on why 120 was written in the first place. It was written as a result of issue 115. Issue 115 is a clear request to choose one key format.
… now as I wrote in the issue, I realized there is not going to be WG consensus to remove either key format, that issue should be closed as “won’t fix”.

See github issue cid#115.

Michael Jones: Secondarily, PR 120 ironically would take the spec in the opposite direction as requested in the issue by sanctioning the use of additional key formats rather than choosing one. Therefore that should not be merged. My proposal is that only the key formats specified in the documents should be used, and if that language is used I would be OK merging it. We should close them both on the call today.

Manu Sporny: disagree with the notion that the PR went in the opposite direction. The request was “do 1 key format”. I agree that we aren’t going to do that. As a result the PR was attempting to explain why we are not going to get to one key format. The PR tries to document why that is not realistic, I won’t object to use saying we won’t fix it and closing it, but the spec would benefit from us explaining why we have made the decision we have made.
… The reality is that there are more than one key format in use, it’s an application specific choice.
… If we can’t get to agreement on writing that in the spec I’m fine with closing the PR and the issue.

Michael Jones: the problem with the PR is that it does two things - it explains why we don’t have consensus on a single format, and it adds new language saying implementations should use key formats defined by the specification rather than must. That’s a weakening of the normative requirements and I can’t support that. We can close them both, it’s the best we’re gonna do.

Brent Zundel: would anyone else in the group be opposed to closing PR 120 and issue 115?

Dave Longley: not opposed to closing, disagree that the spec isn’t more open world already.

Ivan Herman: I am fine with closing both.

Brent Zundel: not hearing any objections, that is our path forward. The plan is to close PR 120 after the call today and close 115 after the call today with the minutes as an explanation for our reasoning. With that, let’s look at the other PRs.

2.2. Fix definition of controller and add verification method binding section (pr cid#126)

See github pull request cid#126.

Brent Zundel: PR 126, fix the definition of controller and add verification method binding section. There are changes requested. Let’s talk about it. If your changes have been addressed please let us know.

Manu Sporny: I think this was just up to Joe and David to find the proper wording, I think we added wording to the specification, David’s wording is slightly different, Joe is disagreeing with that new wording, I think that’s where we are. If we can’t get to consensus I suggest we close PR 126 and resolve that 119 is either done or won’t fix based on differing opinions.

Michael Jones: I had two change requests, one was not to take DavidC’s wording change, which hasn’t been taken, the other was that this PR did two things, fixed the definition of controller, which I support, but it also added a verification method binding section, which is not related to the purpose of the PR and is extra text that was not in the specifications, I will support merging or closing this PR if that section is removed.

David Chadwick: there was a disagreement because the controller of the verification method is in control of the verification method, but putting text to that effect was objected to by Joe because the verification method cannot be updated in that document. There is a possibility to allow these documents to sync.

Manu Sporny: to selfissued, if we remove the thing you want to remove we are left with just a definition, this continued wordsmithing will go on around the definition of controller. I take DavidC’s point, we are searching for language everyone can agree to, it might be easiest to use a new PR to do that. I’ll note that the text Ivan wanted me to move over would be removed.
… we can close the PR and try again, and maybe DavidC can raise that PR and we can all look at it.

Ivan Herman: if I understood what DavidC was saying, the problem is that we are all influenced by a particular way a verification method and controller document are used within this community where the verification method is part of the controller document. However, these two can be distinct documents linked by a URL. These settings are different, that is one of the reasons there is disagreement, this is also my issue all along.
… If the two are separated they need to be treated as such, that is not really done in the spec.

See github pull request cid#119.

Brent Zundel: At this point, the suggestion before us is to close 126, and if there is still a desire to continue on tweaking language to address issue 119 a new PR must be raised. My suggestion is that after the call we close 126. If, by the time we return in January, there is not a new PR that will lead us to consensus, we will close 119. Is that acceptable to folks?

David Chadwick: I commit to producing a new PR for issue 119.

Manu Sporny: +1 for the proposed plan forward.

Phillip Long: +1.

2.3. Add SM2 Algorithm Support (pr cid#131)

See github pull request cid#131.

Brent Zundel: add SM2 algorithm support. Has a couple requests for changes.

Manu Sporny: I put a change suggestion in there to see if the original person that raised the issue would have any objections. If they don’t, we can merge it after. I’ll remove the JSON web key expression and merge it after a day or two of waiting.

Brent Zundel: I believe the changes requested by TallTed have gone in. Path forward is the SM2 algorithm that’s being added will be added for Data Integrity, on the JWK side it would be handled at IETF.
… with that all concerns will have been addressed and the PR can be merged. If folks disagree with this plan please speak up, otherwise we will move to our final PR.

2.4. Changed the leftover CD terms (pr cid#134)

See github pull request cid#134.

Ivan Herman: there are a bunch of places where the controller document term was still used, and I changed them to the new name, nothing earthshaking. One thing which is there, for example, the old error message names are “Invalid Controller Document”, and that kind of thing.

Brent Zundel: This sounds very straightforward, I encourage folks to review it if they like, I anticipate this PR will be merged by the end of the week.
… With these decisions we will have addressed all the open PRs. We plan to close issue 115, and we are fully editorial with our remaining issues, even including trying to address 119, as that won’t introduce normative language.
… I believe that after the PRs are processed as we have discussed the document is in a stable place. If you disagree please speak up. With that we could entertain a proposal to move to CR.

2.5. CID as CR.

Manu Sporny: we have one normative item that jyasskin raised two days ago. We will state that we will define the fragment resolution algorithm in CR1, or we can wait until that is in to go to CR1.

Brent Zundel: the suggestion is that we propose to go to CR after adding language to the spec that we plan to make the single change of defining the fragment resolution algorithm.

Ivan Herman: I am not opposed to doing a resolution today, but at the moment I cannot pick it up and raise an issue to do a transition request, because we have to get at least some answers from the horizontal reviews. I cannot act on a resolution before January.
… there is no rush, unfortunately.

Brent Zundel: If we were to resolve today, would things be able to move before our meeting on 1/8?

Ivan Herman: provided we get at least some horizontal review, and there is nothing to act on in the document as a result, that’s possible.

Brent Zundel: Could resolving inhibit this progress?

Ivan Herman: No.

Brent Zundel: Then there is some possibility of some small benefit of resolving now and no risk.

Manu Sporny: On the horizontal review, Ivan the TAG has finished their review, so we are just waiting on security and accessibility. Just noting there are only 2 that have not been done.
… We also need to pick a short name.

Ivan Herman: We need to formally agree on the new short name.

Brent Zundel: Does anyone have draft language for a proposal?

Ivan Herman: we should say as soon as possible rather than saying a specific date.

Proposed resolution: Publish the Controlled Identifier Document v1.0 specification as a First Candidate Recommendation (https://w3c.github.io/cid/transitions/2025/CR1/index.html) with a new short name of cid-1.0, a preferred publication date as soon as possible, and a CR period of one month. Two independent implementations of each mandatory normative feature are required to proceed this specification to the Proposed Recommendation phase. (Brent Zundel)

Brent Zundel: +1.

Dave Longley: +1.

Ivan Herman: +1.

Ted Thibodeau Jr.: +1.

Phillip Long: +1.

Will Abramson: +1.

David Chadwick: +1.

Wesley Smith: +1.

Hiroyuki Sano: +1.

Manu Sporny: +1.

Resolution #1: Publish the Controlled Identifier Document v1.0 specification as a First Candidate Recommendation (https://w3c.github.io/cid/transitions/2025/CR1/index.html) with a new short name of cid-1.0, a preferred publication date as soon as possible, and a CR period of one month. Two independent implementations of each mandatory normative feature are required to proceed this specification to the Proposed Recommendation phase.

Ivan Herman: Manu I prepared the transition request, a draft of it, as usual I would like you to look at it, mainly on the horizontal review section to make that precise.

Manu Sporny: will do.

Brent Zundel: final topic is status list.

Manu Sporny: I want to quickly note to the group that I requested a final review of all 7 of the specs, just want to make sure the group knows.

Manu Sporny: for example: https://github.com/w3ctag/design-reviews/issues/1029.

3. Status List.

Brent Zundel: https://github.com/w3c/vc-bitstring-status-list/issues?q=is%3Aissue+is%3Aopen+label%3Anormative+sort%3Aupdated-asc.

Brent Zundel: status list. Here is the link to the issues. There are 4 open issues on BSSL.

3.1. Add a MUST statement preventing 2 entries from having the same statusPurpose (issue vc-bitstring-status-list#173)

See github issue vc-bitstring-status-list#173.

Brent Zundel: we are looking at issue 173. Add a MUST statement preventing two entries from having the same status purpose.
… We discussed this, I believe we decided we are not going to do this.

Manu Sporny: Correct, should we mark this pending close, or should we just close it now?

Brent Zundel: let’s add the pending close tag and hopefully it will disappear over the break.
… Next is 184.

3.2. Clarification on multiple items inside BitstringStatusListCredential.credentialSubject (issue vc-bitstring-status-list#184)

See github issue vc-bitstring-status-list#184.

Brent Zundel: clarification on multiple items inside BSSL credential subject. We talked about this last week. The suggestion was to say clearly that the revocation bit applies to all the credential subjects, we don’t differentiate between multiple credential subjects in a status entry.
… I believe this should be a totally editorial change. Did Joe volunteer to raise a PR with some text? I think we are still awaiting that, I will ping Joe in the issue and we can move on unless folks have comments.

3.3. Implementer’s feedback on multiple status entries in a single list (issue vc-bitstring-status-list#194)

See github issue vc-bitstring-status-list#194.

Brent Zundel: Next is 194, implementer feedback on multiple status entries in a single list. Pat St Louis wants that feature to remain.

Manu Sporny: This is good input, it’s enough for us to use this as a reason to not remove the feature. I don’t think we need anything new in the test suite or the implementation report, you can do this today and we don’t need new tests. The only change is to remove the at risk features and say we had an implementer that liked this and the other implementations support it by default.

Brent Zundel: The response to this is now we can close the issue because we agree and we will not have to do anything other than make the change to the at risk notification, at which point we can close this.
… The last issue is final horizontal review for BSSL, raised by manu and tracks the last horizontal reviews required before we go to PR.
… I believe it is still the case that BSSL has not undergone normative/substantive changes after going into CR and so the next step is proposed rec.
… With that we are expecting one more editorial PR on BSSL and then it’s in a good spot. I think we’re done for today, we have talked about everything we can and everything is in as good a place as it can be. There are a couple PRs we are hoping to see over the break, other than that we are ready to move forward when we get reviews.

4. AOB.

Ivan Herman: We have good chances that CR2 will be published tomorrow for VCDM 2.0, the cryptosuites, and JOSE-COSE.

Brent Zundel: As usual we anticipate some additional review/issues on these specs, this feedback is welcome and is the purpose of going into CR2. Happy holidays all, looking forward to seeing you in three weeks.

5. Resolutions