15:04:09 <RRSAgent> RRSAgent has joined #vcwg
15:04:13 <RRSAgent> logging to https://www.w3.org/2024/12/11-vcwg-irc
15:04:13 <Zakim> RRSAgent, make logs Public
15:04:14 <Zakim> please title this meeting ("meeting: ..."), ivan
15:04:28 <ivan> Meeting: Verifiable Credentials Working Group Telco
15:04:28 <ivan> Date: 2024-12-11
15:04:28 <ivan> Agenda: https://www.w3.org/events/meetings/e133b24e-8245-4ee7-8550-ac14d0334974/
15:04:28 <ivan> chair: brent
15:04:28 <ivan> ivan has changed the topic to: Meeting Agenda 2024-12-11: https://www.w3.org/events/meetings/e133b24e-8245-4ee7-8550-ac14d0334974/
15:51:05 <brent> brent has joined #vcwg
15:58:10 <mandyv> mandyv has joined #vcwg
15:59:26 <brent> present+
15:59:32 <wes-smith> wes-smith has joined #vcwg
16:00:47 <ivan> present+
16:01:05 <wes-smith> present+
16:01:18 <ivan> present+ davidc, mandyv
16:01:25 <ivan> present+ TallTed
16:01:54 <denkeni> present+
16:01:59 <ivan> present+ manu
16:02:18 <hsano> hsano has joined #vcwg
16:02:26 <JoeAndrieu> JoeAndrieu has joined #vcwg
16:02:33 <ivan> present+ denken
16:02:44 <JoeAndrieu> present+
16:02:47 <ivan> present+ dmitriz
16:02:51 <manu> present+
16:02:52 <ivan> present+ joe
16:02:57 <hsano> present+
16:03:01 <wes-smith> scribe+
16:03:48 <DavidC> DavidC has joined #vcwg
16:03:53 <DavidC> present+
16:03:57 <ivan> present+ selfissued
16:04:17 <wes-smith> brent: Agenda today is controller document then status list, if anyone would like to introduce themselves please do
16:04:38 <selfissued> selfissued has joined #vcwg
16:04:45 <selfissued> present+
16:04:54 <brent> Topic: Controlled Identifier Document
16:04:57 <manu> q+
16:05:03 <brent> https://github.com/w3c/controller-document/pulls
16:05:15 <wes-smith> ... Let's get started. First topic - Controlled Identifier Document, the link is outdated but Github magic should still work
16:05:32 <manu> q+
16:05:37 <wes-smith> ... Looking at PRs, we have 3 that are open
16:05:37 <ivan> q+ on renaming practicalities
16:05:42 <manu> q- later
16:05:48 <wes-smith> ... we will take the oldest first.
16:05:50 <brent> ack ivan
16:05:50 <Zakim> ivan, you wanted to comment on renaming practicalities
16:06:05 <decentralgabe> present+
16:06:26 <wes-smith> ivan: 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
16:06:43 <wes-smith> ... 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
16:06:55 <wes-smith> ... if you have such issues or PRs open, please edit them to change to the new repository
16:07:03 <bigbluehat> present+
16:07:04 <wes-smith> ... That is one of the unfortunate consequences of renaming
16:07:18 <wes-smith> brent: starting with PR 120
16:07:22 <manu> q?
16:07:43 <brent> https://github.com/w3c/controller-document/pulls/120
16:07:54 <brent> subtopic: https://github.com/w3c/controller-document/pulls/120
16:08:03 <Wip> Wip has joined #vcwg
16:08:08 <Wip> present+
16:08:33 <wes-smith> manu: 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
16:08:40 <wes-smith> brent: would love to do that today
16:09:17 <wes-smith> manu: 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
16:09:25 <wes-smith> ... I think selfissued is objecting to the change
16:09:57 <wes-smith> ... 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
16:10:06 <wes-smith> ... and in application space you should limit to a single key format
16:10:13 <wes-smith> ... but there are objections to what would need to be changed there
16:10:15 <brent> ack manu
16:10:33 <wes-smith> brent: Any comments or anything that could help us move forward on this?
16:11:10 <manu> q+
16:11:17 <wes-smith> selfissued: I'm unwilling to weaken the meaning of the spec, hence my request for changes, the PR weakened the meaning of the spec
16:11:25 <brent> ack manu
16:11:52 <wes-smith> manu: 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
16:12:05 <wes-smith> ... we are trying to be eventually responsive to the representative from Microsoft
16:12:17 <wes-smith> ... the direct ask to selfissued is, would you be ok with should not vs must not
16:12:22 <manu> q+
16:12:25 <wes-smith> selfissued: no, that changes what it means to conform to the spec
16:12:30 <brent> ack manu
16:12:50 <wes-smith> manu: 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
16:13:06 <wes-smith> selfissued: a normal English reading of the spec says you must not use key formats other than what is in the spec
16:13:17 <wes-smith> brent: where was this issue originally raised?
16:13:21 <wes-smith> manu: in the did core document
16:13:44 <Phil> Phil has joined #vcwg
16:13:51 <Phil> present+
16:14:01 <manu> q+
16:14:03 <ivan> present+ will
16:14:07 <wes-smith> brent: 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
16:14:16 <ivan> present+ bigbluehat
16:14:33 <ivan> present+ gabe
16:14:42 <JoeAndrieu> subtopic: https://github.com/w3c/cid/pull/120
16:14:50 <Wip> q+ to ask if key formats are Multikey vs JWK. Or about specific key types
16:14:59 <wes-smith> manu: 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
16:14:59 <wes-smith> editorial change
16:15:08 <brent> ack manu
16:15:17 <brent> ack Wip
16:15:17 <Zakim> Wip, you wanted to ask if key formats are Multikey vs JWK. Or about specific key types
16:15:32 <manu> q+
16:15:40 <brent> ack manu
16:15:40 <wes-smith> Wip: to clarify, when we are talking about key formats we are talking multikey and jwk, right? Wouldn't want to limit within multikey
16:15:53 <wes-smith> manu: correct, we are talking higher level key format not key type
16:16:24 <wes-smith> brent: selfissued's change would make this PR into a normative change
16:16:30 <manu> q+ to note strong disagreement
16:16:32 <manu> q-
16:16:34 <wes-smith> selfissued: no, it would confirm what is already true, not a normative change
16:16:39 <wes-smith> TallTed: there is disagreement about that
16:16:46 <wes-smith> selfissued: I understand that
16:16:55 <wes-smith> TallTed: I would appreciate adjusting your assertion
16:17:16 <bigbluehat> q+
16:17:21 <wes-smith> brent: People speak from opinions, I don't believe there is a lack of clarity there, selfissued is speaking to his opinions
16:17:30 <ivan> q+
16:17:33 <brent> ack bigbluehat
16:17:45 <wes-smith> bigbluehat: it would be helpful to have some concrete language that clarifies what selfissued is saying
16:18:09 <wes-smith> brent: the ask is for selfissued to show the language in the spec now that is leading to your understanding
16:18:16 <wes-smith> selfissued: I can add that to the issue after the call
16:18:24 <brent> ack ivan
16:18:24 <ivan> 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. "
16:18:50 <manu> Ivan's reading is the same as mine and I agree with it.
16:18:52 <wes-smith> ivan: from the example in the spec, it does not read as a "must" to choose between the two key formats
16:19:13 <ivan> q+
16:19:19 <brent> ack ivan
16:19:49 <wes-smith> Ivan: one more thing, if selfissued finds text in the spec per his understanding the spec is inconsistent as the example I looked at does indicate a must and we have an editorial problem in the spec
16:20:02 <wes-smith> s/does indicate/does not indicate
16:20:13 <ivan> link to the quote: https://www.w3.org/TR/controller-document/#verification-material
16:20:16 <bigbluehat> https://w3c.github.io/cid/#choosing-a-multiformat:~:text=Verification%20material%20is%20any%20information%20that%20is%20used%20by%20a%20process%20that%20applies%20a%20verification%20method.%20The%20type%20of%20a%20verification%20method%20is%20expected%20to%20be%20used%20to%20determine%20its%20compatibility%20with%20such%20processes.%20Examples%20of%20verification%20methods%20include%20JsonWebKey%20and%20Multikey.
16:20:19 <brent> subtopic: https://github.com/w3c/controller-document/pulls/126
16:20:26 <manu> q+
16:20:31 <wes-smith> brent: next PR is 126
16:20:33 <brent> ack manu
16:21:05 <wes-smith> manu: 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
16:21:25 <wes-smith> ... Ivan mentioned we did not have a paragraph around verification method binding, selfissued object when I moved text from another spec here
16:21:26 <ivan> q+
16:21:49 <wes-smith> ... 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
16:21:58 <brent> ack ivan
16:22:55 <manu> q+ to disagree that it's a normative change.
16:22:55 <selfissued> q+
16:22:55 <wes-smith> Ivan: 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
16:23:26 <JoeAndrieu> q+ to suggest the algorithm should be profiled not specified here.
16:23:46 <wes-smith> ... 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
16:23:46 <wes-smith> for a specific application area
16:24:01 <wes-smith> ... but it is not a general method and other areas may use a totally different way to bridge between verification method and controller document
16:24:05 <brent> ack manu
16:24:05 <Zakim> manu, you wanted to disagree that it's a normative change.
16:24:38 <wes-smith> manu: 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
16:24:46 <ivan> q+
16:24:55 <wes-smith> ... this PR just does not make the clarification you are suggesting that this is not a generic algorithm
16:25:08 <brent> ack selfissued
16:25:12 <wes-smith> ... with that said I'm happy to make those non-normative changes if selfissued and Ivan agree on what needs to be written
16:25:35 <wes-smith> selfissued: if you look at the last entry in the PR comments, DavidC agreed and suggested a wording change that we both agree to
16:25:42 <wes-smith> ... but the PR can be updated with his proposed wording
16:25:51 <wes-smith> ... and then the previous section can be marked as resolved
16:26:00 <DavidC> +1 to that
16:26:00 <brent> ack JoeAndrieu
16:26:00 <Zakim> JoeAndrieu, you wanted to suggest the algorithm should be profiled not specified here.
16:27:12 <brent> ack ivan
16:27:14 <wes-smith> JoeAndrieu: 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
16:27:14 <wes-smith> 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.
16:27:49 <wes-smith> Ivan: 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
16:27:53 <manu> q+
16:28:01 <brent> ack manu
16:28:19 <wes-smith> manu: 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
16:28:51 <ivan> q+
16:29:22 <wes-smith> ... 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
16:29:22 <wes-smith> change, and your ask is outside 119, which is about non-normative text.
16:29:36 <wes-smith> ... If we are talking about the algorithm itself and fragment identifier stuff it should be a separate issue.
16:29:39 <brent> ack ivan
16:29:53 <manu> q+ to note he'll proceed that way.
16:30:06 <selfissued> q+
16:31:18 <brent> ack manu
16:31:18 <Zakim> manu, you wanted to note he'll proceed that way.
16:31:21 <wes-smith> Ivan: 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
16:31:21 <wes-smith> putting something in the issue tracker by itself is a blocker for moving to CR.
16:31:34 <wes-smith> manu: would you mind raising an issue and marking it during CR so I can integrate it into the snapshot?
16:31:44 <wes-smith> Ivan: yes, but not sure when
16:31:48 <wes-smith> manu: I will do it right now then
16:31:48 <brent> ack selfissued
16:32:33 <manu> q+ to note we fixed definition of controller earlier, in Joe's PR, IIRC.
16:32:36 <wes-smith> selfissued: 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
16:32:36 <wes-smith> section without more discussion, let's rip that part out and I will approve
16:32:47 <DavidC> +1 to this
16:32:49 <wes-smith> Brent: proposal is to split this PR into multiple PRs
16:32:50 <brent> ack manu
16:32:50 <Zakim> manu, you wanted to note we fixed definition of controller earlier, in Joe's PR, IIRC.
16:32:59 <manu> https://w3c.github.io/cid/#terminology
16:33:24 <wes-smith> manu: 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
16:33:51 <DavidC> q+
16:33:59 <wes-smith> ... 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
16:33:59 <brent> ack DavidC
16:34:35 <wes-smith> DavidC: 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
16:34:51 <wes-smith> manu: JoeAndrieu would need to be onboard, Joe if you can look at DavidC's suggestion I can modify the PR
16:35:16 <wes-smith> Brent: JoeAndrieu do you know what language specifically you are being asked to review?
16:35:23 <brent> subtopic: https://github.com/w3c/controller-document/pulls/131
16:35:24 <wes-smith> JoeAndrieu: yes, looking now
16:35:47 <manu> q+
16:35:52 <brent> ack manu
16:35:54 <wes-smith> Brent: there is a request for changes from TallTed here, looking briefly then moving to bit string status list
16:36:01 <TallTed> my suggested changes were made
16:36:09 <wes-smith> manu: this is straightforward, just adds SM2 to multikey, looks fine to me
16:36:12 <selfissued> q+
16:36:23 <wes-smith> Brent: nothing stopping this PR from being merged, is the PR submitter a member of our group
16:36:25 <wes-smith> Ivan: yes
16:36:29 <brent> ack selfissued
16:36:35 <manu> q+
16:36:48 <brent> ack manu
16:37:01 <wes-smith> selfissued: 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
16:37:07 <manu> https://www.ietf.org/archive/id/draft-dang-webauthn-sm2-00.html
16:37:21 <TallTed> sorry, my changes were *not* made. marked as resolved without application.
16:37:30 <wes-smith> manu: 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
16:37:38 <wes-smith> selfissued: webauthn uses COSE not JOSE
16:37:48 <wes-smith> manu: yes, but the spec I pointed to does
16:37:59 <manu> q+
16:38:04 <wes-smith> selfissued: my point is that it is not registered, until it goes through the IANA registration it's not real
16:38:04 <brent> ack manu
16:38:19 <wes-smith> manu: then what we can do is remove the parts that talk about the JSON web key and how to express it there
16:38:20 <ivan> +1 to manu
16:38:24 <TallTed> re-re-reading. .my suggestions *were* applied, I just overlooked two other locations
16:38:33 <ivan> q+
16:38:39 <wes-smith> Brent: let's move to bitstring status list
16:38:45 <ivan> q-
16:38:52 <wes-smith> manu: would it be possible for us to have the CR discussion around controlled identifier document
16:38:58 <wes-smith> Brent: yes, let's do that
16:38:59 <DavidC> DavidC has joined #vcwg
16:39:05 <ivan> q+
16:39:08 <brent> subtopic: CR proposal for CID
16:39:22 <wes-smith> Brent: do you have draft language prepared
16:39:28 <wes-smith> manu: yes, pulling that up now
16:40:01 <brent> ack ivan
16:41:24 <wes-smith> Ivan: 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
16:41:24 <wes-smith> before we submit at CR request
16:41:36 <manu> q+ to ask why we can't request that w/ a transition request?
16:41:48 <brent> ack manu
16:41:48 <Zakim> manu, you wanted to ask why we can't request that w/ a transition request?
16:41:57 <JoeAndrieu> q+ to comment on #126 if we want to touch on that again today
16:42:27 <wes-smith> manu: 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
16:42:30 <ivan> q+
16:42:39 <wes-smith> JoeAndrieu: I'm on the queue for 126 again, we can defer that
16:42:45 <brent> ack ivan
16:43:28 <wes-smith> Ivan: 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
16:43:49 <manu> q+ to note we asked for this a month ago.
16:43:56 <wes-smith> ... 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
16:44:01 <JoeAndrieu> q later
16:44:09 <wes-smith> ... as I said, the last contact we had was July, that will not work
16:44:31 <wes-smith> wes-smith has joined #vcwg
16:44:34 <wes-smith> present+
16:44:36 <wes-smith> scribe+
16:44:50 <wes-smith> Ivan: we can ping them again and move ahead
16:44:52 <brent> ack manu
16:44:53 <Zakim> manu, you wanted to note we asked for this a month ago.
16:45:31 <wes-smith> manu: 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
16:45:47 <wes-smith> ... accessibility we pinged last month, internationalization got back to us in June
16:45:59 <wes-smith> ... you are asking for a rerequest across the board for horizontal review
16:46:05 <wes-smith> Ivan: with clear changes noted
16:46:28 <wes-smith> manu: 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
16:46:34 <wes-smith> Ivan: not disagreeing, just trying to remove the friction
16:46:44 <brent> q?
16:46:56 <brent> ack JoeAndrieu
16:46:56 <Zakim> JoeAndrieu, you wanted to comment on #126 if we want to touch on that again today
16:47:21 <wes-smith> JoeAndrieu: 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
16:47:32 <wes-smith> Brent: thanks, that conversation should continue in that PR
16:47:33 <brent> Topic: Bitstring Status List
16:47:45 <wes-smith> ... let's move to talking about bitstring status list
16:47:53 <manu> q+ to note we don't have PRs, need discussion on issues.
16:47:57 <brent> https://github.com/w3c/vc-bitstring-status-list/pulls
16:48:03 <brent> ack manu
16:48:03 <Zakim> manu, you wanted to note we don't have PRs, need discussion on issues.
16:48:30 <wes-smith> manu: 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
16:48:33 <brent> subtopic: https://github.com/w3c/vc-bitstring-status-list/issues/173
16:48:43 <wes-smith> Brent: let's look at the issues
16:49:01 <wes-smith> ... 173 add a must statement preventing two entries from having the same purpose
16:49:16 <wes-smith> manu: the question was around having two entries with the same status purpose on one credential
16:49:39 <wes-smith> ... 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
16:49:56 <wes-smith> ... his request to prevent two entries from having the same status purpose would not allow us to meet that use case
16:50:14 <JoeAndrieu> +1 to manu's analysis
16:50:17 <wes-smith> ... 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
16:50:55 <manu> q+
16:50:59 <wes-smith> Brent: 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
16:50:59 <brent> ack manu
16:51:54 <wes-smith> manu: 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
16:52:33 <brent> subtopic: https://github.com/w3c/vc-bitstring-status-list/issues/184
16:52:36 <manu> q+
16:52:48 <wes-smith> brent: next is 184, clarification of multiple items inside credential subject
16:52:49 <brent> ack manu
16:53:32 <wes-smith> manu: 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
16:53:45 <wes-smith> ... the response was that the revocation bit applies to all credential subjects
16:53:49 <JoeAndrieu> q+ to say the subject isn't revoked, the claims are
16:54:02 <wes-smith> ... what we might want to do is clearly state this in the spec
16:54:10 <ivan> +1 to manu, that sounds as the logical way to do it
16:54:15 <brent> ack JoeAndrieu
16:54:15 <Zakim> JoeAndrieu, you wanted to say the subject isn't revoked, the claims are
16:54:35 <wes-smith> JoeAndrieu: +1, it's all the claims, we need to add that language
16:54:49 <wes-smith> ... I can take this PR
16:55:00 <wes-smith> Brent: One more issue, is that worth looking at in our last minute
16:55:07 <ivan> q+
16:55:16 <wes-smith> manu: this last issue is a test suite issue, we need to test a revoked vs non revoked credential
16:55:21 <wes-smith> ... might want to move this issue to the BSSL test suite
16:55:24 <brent> ack ivan
16:55:55 <wes-smith> Ivan: 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?
16:55:58 <wes-smith> Brent: that is my understanding
16:56:11 <wes-smith> manu: I don't know, I don't think so but not sure
16:56:12 <wes-smith> Ivan: let's do it that way
16:57:04 <ivan> rrsagent, draft minutes
16:57:05 <RRSAgent> I have made the request to generate https://www.w3.org/2024/12/11-vcwg-minutes.html ivan
19:50:35 <Zakim> Zakim has left #vcwg