Verifiable Credentials Working Group Telco — Minutes
Date: 2024-12-11
See also the Agenda and the IRC Log
Attendees
Present: Brent Zundel, Ivan Herman, Wesley Smith, David Chadwick, Mandy Venables, Ted Thibodeau Jr., Denken Chen, Manu Sporny, Joe Andrieu, Dmitri Zagidulin, Hiroyuki Sano, Michael Jones, Gabe Cohen, Benjamin Young, Will Abramson, Phillip Long
Regrets:
Guests:
Chair: Brent Zundel
Scribe(s): Wesley Smith
Content:
Wesley Smith: wes-smith has joined #vcwg.
Brent Zundel: Agenda today is controller document then status list, if anyone would like to introduce themselves please do.
1. Controlled Identifier Document.
Brent Zundel: https://github.com/w3c/cid/pulls.
Brent Zundel: Let’s get started. First topic - Controlled Identifier Document, the link is outdated but Github magic should still work.
… Looking at PRs, we have 3 that are open.
… we will take the oldest first.
Ivan Herman: one thing that we hit, when we rename a repository on Github, indeed there is magic to redirect the GitHub itself, but there is no magic to redirect the GitHub.io from the old to the new.
… we had a number of issues, some of them open, that referred to the editor’s draft through the URL and that will not happen.
… if you have such issues or PRs open, please edit them to change to the new repository.
… That is one of the unfortunate consequences of renaming.
Brent Zundel: starting with PR 120.
Brent Zundel: https://github.com/w3c/cid/pulls/120.
1.1. Explain why one key format is not realistic. (pr cid#120)
See github pull request cid#120.
Manu Sporny: should we mention that every PR and every remaining issue is editorial, and we could do it during CR? Fine to process the PRs, just wondering if we can get around to a proposed resolution to transition to CR today.
Brent Zundel: would love to do that today.
Manu Sporny: Ok, let’s do 120, this has to do with issue 115, this is a comment from Travis at Microsoft, he said you should try to do one key format, we are trying to respond to him and say the best we can do is two key formats.
… I think selfissued is objecting to the change.
… and I think that’s where we are, what we are trying to do is hit a balance, the best we can do is two key formats because there are multiple in the ecosystem and we can never really get to a single key format.
… and in application space you should limit to a single key format.
… but there are objections to what would need to be changed there.
Brent Zundel: Any comments or anything that could help us move forward on this?
Michael Jones: I’m unwilling to weaken the meaning of the spec, hence my request for changes, the PR weakened the meaning of the spec.
Manu Sporny: selfissued, you suggested we add text that say that implementations of this specification must not use key formats other than those defined in the spec, but we don’t have consensus on that language, we may be able to say should not.
… we are trying to be eventually responsive to the representative from Microsoft.
… the direct ask to selfissued is, would you be ok with should not vs must not.
Michael Jones: no, that changes what it means to conform to the spec.
Manu Sporny: to be clear, we have always allowed other key formats, it goes with the extensibility model for Data Integrity, I disagree that the spec today says you must not use other key formats.
Michael Jones: a normal English reading of the spec says you must not use key formats other than what is in the spec.
Brent Zundel: where was this issue originally raised?
Manu Sporny: in the did core document.
Brent Zundel: and our original intent for the controlled identifier specification was to take text from documents that were describing things but not otherwise… unclear why this is our issue to change, why we are making normative changes, it feels outside the scope of what we as a group were working towards.
Manu Sporny: the original PR was not making normative changes, I disagree with selfissued’s understanding of what the spec says, the reason the issue moved was because the text it affected moved, this was always an editorial issue and the changes were editorial in nature. selfissued’s change makes it a normative change, I agree we should make it an editorial change.
Will Abramson: to clarify, when we are talking about key formats we are talking multikey and jwk, right? Wouldn’t want to limit within multikey.
Manu Sporny: correct, we are talking higher level key format not key type.
Brent Zundel: selfissued’s change would make this PR into a normative change.
Michael Jones: no, it would confirm what is already true, not a normative change.
Ted Thibodeau Jr.: there is disagreement about that.
Michael Jones: I understand that.
Ted Thibodeau Jr.: I would appreciate adjusting your assertion.
Brent Zundel: People speak from opinions, I don’t believe there is a lack of clarity there, selfissued is speaking to his opinions.
Benjamin Young: it would be helpful to have some concrete language that clarifies what selfissued is saying.
Brent Zundel: the ask is for selfissued to show the language in the spec now that is leading to your understanding.
Michael Jones: I can add that to the issue after the call.
Ivan Herman: Quote from the text: “Verification material is any information that is used by a process that applies a verification method. The type of a verification method is expected to be used to determine its compatibility with such processes. Examples of verification methods include JsonWebKey and Multikey. “.
Ivan Herman: link to the quote: https://www.w3.org/TR/controller-document/#verification-material.
Manu Sporny: Ivan’s reading is the same as mine and I agree with it.
Ivan Herman: from the example in the spec, it does not read as a “must” to choose between the two key formats.
… one more thing, if selfissued finds text in the spec per his understanding the spec is inconsistent as the example I looked at does not indicate a must and we have an editorial problem in the spec.
1.2. https://github.com/w3c/cid/pulls/126.
Brent Zundel: next PR is 126.
Manu Sporny: this one had some back and forth, this had to do with how we define controller and how you bind to a verification method, Joe’s PR did a lot of good updates to clarify this, this one in a more focused way tried to clarify a paragraph.
… Ivan mentioned we did not have a paragraph around verification method binding, selfissued object when I moved text from another spec here.
… there seems to be disagreement between Ivan and selfissued around what text should be in this spec, again this is an editorial PR and we don’t need it to go to CR.
Ivan Herman: I don’t agree it’s editorial, the text that you moved over from Data Integrity refers to an algorithmic section, that section has an algorithm which is not generic, it depends on the usage of fragment IDs for the url of the verification method.
… that’s fine if there is agreement on how we use this, and it’s fine to say that this approach is what we use for Verifiable Credentials, but it’s a specific algorithm not a generic algorithm, which means that section over there should make it clear as additional information that what is described in the algorithmic section is an approach usable for a specific application area.
… but it is not a general method and other areas may use a totally different way to bridge between verification method and controller document.
Manu Sporny: yeah, fine with making all those changes, my issue is that I don’t think selfissued agrees, the other thing I disagree is that this is not a normative change, referring to a normative section is not a normative change, and the changes you are requesting are not normative either.
… this PR just does not make the clarification you are suggesting that this is not a generic algorithm.
… with that said I’m happy to make those non-normative changes if selfissued and Ivan agree on what needs to be written.
Michael Jones: if you look at the last entry in the PR comments, DavidC agreed and suggested a wording change that we both agree to.
… but the PR can be updated with his proposed wording.
… and then the previous section can be marked as resolved.
David Chadwick: +1 to that.
Joe Andrieu: I think this algorithm is not accurate for DIDs, maybe it is oversimplified, it feels to me like this controlled identifier document shouldn’t get to this level of detail, it should be profiled by whatever mechanism you are using to turn the identifier into the document, and so I think what some people are wanting here is “here is an HTTP profile of the controlled identifier document”. We need to not put requirements for using a CID through the web into the spec, that is not what we set out to do when we set out to create a common base.
Ivan Herman: JoeAndrieu made it stronger that this is a normative change, as that would be normative, originally I think this is normative because the algorithm description does not make it clear that the algorithm is not generic for all use cases.
Manu Sporny: I still disagree, I think we need another issue to track this, because 119 is an issue with nothing to do with this stuff, Ivan you are raising a valid concern, but it’s not the issue we are trying to address.
… if you are raising a normative issue, we can’t proceed to CR1 unless you agree that you are going to raise an issue, and we will put that issue marker in the transition to CR. If you are asserting this is a normative change we will not transition to CR today unless you can put it in as an issue marker. This was never meant to be a normative change, and your ask is outside 119, which is about non-normative text.
… If we are talking about the algorithm itself and fragment identifier stuff it should be a separate issue.
Ivan Herman: I have no problem postponing, but I don’t think there would be a problem with an issue tracker, I have more fundamental problems to move to CR. The reason why all these are related is the first comment by selfissued was that this is unnecessary to be moved away and that move should be removed. The two things are related. I don’t think that putting something in the issue tracker by itself is a blocker for moving to CR.
Manu Sporny: would you mind raising an issue and marking it during CR so I can integrate it into the snapshot?
Ivan Herman: yes, but not sure when.
Manu Sporny: I will do it right now then.
Michael Jones: I think we have a simple way forward to be able to merge this, the title of the PR is “fix definition of controller and add verification method binding section”. I proposed some weeks ago to do the first, which is fix the definition of controller, which we are on the threshold of doing, but not add the verification method binding section without more discussion, let’s rip that part out and I will approve.
David Chadwick: +1 to this.
Brent Zundel: proposal is to split this PR into multiple PRs.
Manu Sporny: https://w3c.github.io/cid/#terminology.
Manu Sporny: I’m fine with doing that, we fixed that, selfissued, in Joe’s PR, but the current definition of controller is aligned with what DavidC proposed, if not exactly what he proposed, so we already fixed that definition in another PR.
… the only thing we’re talking about at this point is the other thing, we should move on, this is now purely editorial, we will raise an issue to track Ivan’s other concern, the issues with this one are purely editorial and can be done during CR.
David Chadwick: Thank you for the pointer to the revised text, the definition of controller is not the same as my definition, I second selfissued’s suggestion.
Manu Sporny: JoeAndrieu would need to be onboard, Joe if you can look at DavidC’s suggestion I can modify the PR.
Brent Zundel: JoeAndrieu do you know what language specifically you are being asked to review?
Joe Andrieu: I don’t particularly like DavidC’s edits, the language implies that the controller of a verification method could update it, that’s not how it works, we would have to tease those things out to get it approved.
Brent Zundel: thanks, that conversation should continue in the PR.
1.3. https://github.com/w3c/cid/pulls/131.
Brent Zundel: there is a request for changes from TallTed here, looking briefly then moving to bit string status list.
Ted Thibodeau Jr.: my suggested changes were made.
Manu Sporny: this is straightforward, just adds SM2 to multikey, looks fine to me.
Brent Zundel: nothing stopping this PR from being merged, is the PR submitter a member of our group?
Ivan Herman: yes.
Michael Jones: there is no JSON web key definition for SM2, so I don’t know how one would do that unless you are going to write an algorithms section for JOSE, so I disagree that this is straightforward, I will say that in the PR.
Manu Sporny: https://www.ietf.org/archive/id/draft-dang-webauthn-sm2-00.html.
Ted Thibodeau Jr.: sorry, my changes were not made. marked as resolved without application.
Manu Sporny: I’m fine to remove the JOSE thing, this thing is not an RFC but it is through the webauthn working group, how to express SM2 in JOSE and COSE.
Michael Jones: webauthn uses COSE not JOSE.
Manu Sporny: yes, but the spec I pointed to does.
Michael Jones: my point is that it is not registered, until it goes through the IANA registration it’s not real.
Manu Sporny: then what we can do is remove the parts that talk about the JSON web key and how to express it there.
Ivan Herman: +1 to manu.
Ted Thibodeau Jr.: re-re-reading. .my suggestions were applied, I just overlooked two other locations.
Brent Zundel: let’s move to bitstring status list.
Manu Sporny: would it be possible for us to have the CR discussion around controlled identifier document.
Brent Zundel: yes, let’s do that.
1.4. CR proposal for CID.
Brent Zundel: do you have draft language prepared.
Manu Sporny: yes, pulling that up now.
Ivan Herman: we have a problem and may face objections, I have gone through the horizontal review tracking, I don’t remember if it was privacy or security but from June/July, what we discussed at TPAC I am sure that we will get a request from management to re-ask for horizontal review or ask them to reinforce their approval, I would prefer to do that before we submit at CR request.
Manu Sporny: I’m concerned about putting an unknown timeline on a request, it can take months for horizontal review, we want to transition to CR and use that as a way to have them get back to us, if we make this proposal to transition as soon as we can we can ping them, without that we will be waiting another three months.
Joe Andrieu: I’m on the queue for 126 again, we can defer that.
Ivan Herman: submitting it to the transition is at this moment a futile exercise, we will get a response back saying “go and get reinforcement of the horizontal review request” and that will result in the same delays.
… we can go back to those who have/haven’t answered, show them what has changed, and ask if they have any concerns with what has changed, and give them a 2-3 week deadline.
… as I said, the last contact we had was July, that will not work.
Wesley Smith: wes-smith has joined #vcwg.
Ivan Herman: we can ping them again and move ahead.
Manu Sporny: I checked all of them, I take your point on the “we checked with them months ago” and we can ping them again, the TAG we pinged last month, they are non responsive, PING engaged on Sep 16, we can ask them again, Brent pinged security on Aug 5, we are meeting with them tomorrow.
… accessibility we pinged last month, internationalization got back to us in June.
… you are asking for a re-request across the board for horizontal review.
Ivan Herman: with clear changes noted.
Manu Sporny: I’ll take this moment to express my deep frustration with the horizontal review process, it feels like moving goalposts with groups that are unresponsive.
Ivan Herman: not disagreeing, just trying to remove the friction.
2. Bitstring Status List.
Ivan Herman: let’s move to talking about bitstring status list.
Brent Zundel: https://github.com/w3c/vc-bitstring-status-list/pulls.
Manu Sporny: the good news here is that we don’t have any PRs, only 3 issues left, 2 are normative and we have answers for both, want to confirm with the WG that there is agreement.
2.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: let’s look at the issues.
… 173 add a must statement preventing two entries from having the same purpose.
Manu Sporny: the question was around having two entries with the same status purpose on one credential.
… my answer was that is perfectly fine, you can have multiple certifying organizations that have the ability to revoke a credential, for example medical licenses.
… his request to prevent two entries from having the same status purpose would not allow us to meet that use case.
Joe Andrieu: +1 to manu’s analysis.
Manu Sporny: and we don’t need the entries to have different ID fields because we don’t need that either, this is a no-op, I’m suggesting we don’t change the spec.
Brent Zundel: the current path forward is to say we don’t believe that suggestion allows certain use cases, I’m expecting this to become a pending closed issue unless folks feel strongly otherwise.
Manu Sporny: mahmoud 20 hours ago put in a statement that said as long as the status list URL is unique we shouldn’t have an issue, it’s fine if we have duplicates with the same status list URL, if any of them have bits flipped it’s revoked.
2.2. Clarification on multiple items inside BitstringStatusListCredential.credentialSubject (issue vc-bitstring-status-list#184)
See github issue vc-bitstring-status-list#184.
Brent Zundel: next is 184, clarification of multiple items inside credential subject.
Manu Sporny: this issue, the issue submitter was unclear which credential subject a BSSL applies to, this person said they don’t know which subject the revocation bit applies to.
… the response was that the revocation bit applies to all credential subjects.
… what we might want to do is clearly state this in the spec.
Ivan Herman: +1 to manu, that sounds as the logical way to do it.
Joe Andrieu: +1, it’s all the claims, we need to add that language.
… I can take this PR.
Brent Zundel: One more issue, is that worth looking at in our last minute.
Manu Sporny: this last issue is a test suite issue, we need to test a revoked vs non revoked credential.
… might want to move this issue to the BSSL test suite.
Ivan Herman: I have a general question before we end the call, is it correct that since the CR transition of BSSL, nothing substantial has happened, so we don’t need CR2?
Brent Zundel: that is my understanding.
Manu Sporny: I don’t know, I don’t think so but not sure.
Ivan Herman: let’s do it that way.