Meeting minutes
brent: Let's get started -- today we have our agenda, talk through next steps for REC, press release, security reviews, decision on meeting cadence moving forward. Any additional items to cover today?
selfissued: Fix to VC JOSE COSE?
Recommendation next steps
brent: We have a set of comments that were made as a part of the AC review during Proposed Rec, process requires us to have a response to the comments.
brent: The plan for the next bit is to share the comments and indicate what the response is planned to be to make sure we're on the same page.
ivan: As a general rule, we should know that (in theory) we're not supposed to change the specifications beyond the administrative items beyond PR and REC, except when it's explicitly asked for by a commenter. For those cases, it's better to postpone changes to the next minor release than make changes. If we make changes on the documents, we have to go back to the AC to ask for a second approval on changes to be made. We have to go back to AC reps to see if it would change their vote, we would prefer to not do that at this point.
VCDM comments
<brent> w3c/
<brent> "§5.11 Ecosystem Compatibility should explicitly list SD-JWT and SD-JWT-VC to paragraph 1 which lists digital credential formats that do not natively use the VCDM. SD-JWT-VC even explicitly specifies it does not use the VCDM v1.0, v1.1, or v2.0. As SD-JWT(-VC) is a popular VC format for eIDAS it should be explicitly stated like the others."
<brent> comment source
brent: For each of these comments, I will provide text and link to source of comment.
brent: comment on VCDM, text suggests say we list SD-JWT-VC to the ecosystem compatibility section. The suggested response will be that we plan to address comment in future version of specification.
ivan: Any response we make is better to send via email.
brent: I will do that.
KevinDean: Is there something we can add to the response to provide reasoning? Out of scope for current scope of work?
brent: This is an editorial change, we can address it under our current charter, seeing how ideally we shouldn't change text of REC, we can address this later.
selfissued: That's fine.
Data Integrity comments
<brent> "In our opinion, one of the lessons learned from XML Signatures was that complex canonicalization tied to a signature mechanism tends to lead to complex implementations and a higher likelihood of security vulnerabilities. Those lessons learned lead to the design of simpler signature mechanisms like those in JWT/CWT to avoid the complexity of canonicalization at least when doing cryptographic operations. We understand the general appeal of the ideas behind Data Integrity Proofs but fear that it will lead to overly complex and insecure implementations by forcing implementations to perform rather complex RDF Dataset Canonicalization before any basic signature operation (sign, prove, verify) as is the case for some of the DI Cryptosuites, e.g., the ECDSA one. Semantics and signature mechanisms should be in their own respective layers to facilitate robust and secure implementations."
<brent> comment source
brent: The one comment on data integrity made by Torsten of SPRIND, they do not support the specification but are not formally objecting.
brent: This should be familiar to everyone in the meeting, we had long conversations about this as we were developing data integrity.
brent: At this point it's probably appropriate to note that while RDFC is more complex, JCS is also possible, there is the option to use JWS and CWS, we can point them to issue 272 where the group discussed this extensively.
VC JOSE COSE
<brent> w3c/
<brent> "Since it is not a normative portion in this specification, it may not be a particular issue to change, but I would like to confirm one thing for the correctness of spec before publishing. I understand that all examples of COSE Sign1 within the CR (for example, EX-7) are protected by ES384. However, it appears that the signature is only 64 bytes, rather than the typical 96 bytes for P-384 signature. I am not an expert in COSE, so if such pruning or bit truncation is correct in the viewpoint of COSE, there should be no problem."
<brent> comment source
brent: We have two comments, both suggest publication... one comment is about COSE examples being incorrect -- we have fixed this issue.
ivan: This is waiting in a PR, correct?
brent: We plan to merge that PR after the call today.
<brent> "The way this specification utilizes SD-JWT is sub-optimal as it double base64 encodes credentials in order to present them and it is more complex than needed as it uses SD-JWT as container for the presentation where there is no need for the SD-JWT capabilities."
<brent> comment source
brent: We could respond by pointing to issue 340, there is a point here, closer examination on SD-JWT interacts w/ VCDM and presentations, we could explore this further. At this point, we plan to address this in future versions of the specification.
ivan: In the previous case, future versions are editorial... any change for this case is normative, not chartered to make this change (class 4). "Future version" would be next major version.
selfissued: We will consider addressing this concern, consensus might not result in a change.
brent: Any other comments on VC JOSE COSE before we move on?
CID
<brent> w3c/
selfissued: I registered the media type.
brent: We had a number of comments on this one.
<brent> "Too similar to the code did specification. I wish it were presented as a clear extension of the did core specification that was clear about what’s different"
<brent> comment source, answered by team contact
brent: Ivan has responded to this comment, it is a superset of DIDs.
<brent> "§1 Introduction should note why the CID specification is necessary as those with less experience might see it as a recommendation over Decentralized Identifiers (DIDs) v1.0 rather than providing an abstraction to further make the case of DIDs."
<brent> comment source
brent: They've asked for justification of the technology.
brent: We thank the commenter, we will try to address the concern in a future version of the specification.
ivan: Can we make a minor change to address this issue?
manu: We should take our time to pick wording that's not controversial.
brent: Agree with that approach.
<brent> "As stated in the Revision History section, this specification was created "to use non-decentralized identifiers and systems". Those are already inclusively supported in DIDs, which chose a federated approach. If the editors wish to propose any other reason for this specification's existence, they should add a Motivation section in the Introduction explaining the reason."
<brent> comment source
brent: The commenter here has pointed out that DIDs support this already -- we should add a motivation section. This is similar to the previous comment, but again, we should take our time to address this in the next version of the spec to make sure we pick language carefully.
brent: Any other comments on this one?
BSL
<brent> w3c/
brent: First comment is about usefulness, but privacy section is useful. We don't need to respond to this because there are no changes requested.
<brent> "§2 Data Model has a table that is not titled/labeled. Additionally, it should consider the factor of a scheme that proves status without revealing correlatable global identifiers. The authors do indirectly acknowledge this later in §6 but it is a very desirable trait and should be mentioned upfront in the overview. §6 Privacy Considerations should also discuss the ability/inability of using Zero-knowledge proofs for proving status."
<brent> comment source
brent: There is a table without a title, raised issue 204 to track that.
brent: The second comment was about ZKPs and anti-correlation and if we could figure out a way to do this using a ZKPs.
brent: proposed response is to acknowledge that this would be useful and we will continue to explore this in a future version of the spec.
ivan: can we add the title and get rid of issue 204?
manu: yes
brent: I will convey that to the commenter.
further steps towards REC
brent: I think we have actions for manu, mike, and me -- we'll get those items done.
ivan: We need a date for the final version -- what is it going to be?
ivan: Manu, before you create final versions, final redirections need to be in place, right?
manu: yes. put the final redirections in place
… hopefully the hashes won't change
ivan: there may be a new line feed…
manu: ok.
ivan: it will be done by the end of the week
manu: for the date: May 15th? May 22nd?
ivan: how much time do you need to make the final versions?
manu: a weekend? maybe?
ivan: so, we could get the transition request in on the 2nd
… they'll likely take some time, so the 15th is a safe bet
… let's start with May 15th
brent: ok, anything else on recommendation next steps before we move on?
brent: anything more on recommendations next steps topic?
Press Release
ivan: I talked to Coralie, gave her all the material that the press release might have in it -- overview, slides, etc. She will pick that up and make a first version of press release. Thought maybe 15th for press release, that's it.
manu: usually there are testimonials
… are you looking for those too?
manu: usually there are testimonials -- are we looking for that?
ivan: Yes, we usually ask the group members for testimonials -- let's try to collect them in one place.
manu: Why don't we cast a wide net, asking WG members, CCG members, etc?
ivan: Let's start with WG Members first, just personal opinion. I would hope several testimonials in from WG Members.
<brent> Collection point on GDoc for testimonials
brent: There is the Google doc, shared to member mailing list to invite people to add things and then pass things on to Coralie -- we need these within a week.
Security Reviews
brent: Good news is we got security reviews... timing wise, they came in during Proposed Rec.
brent: If you look in VCDI, ecdsa, plan with these is to take these issues as we take issues with maintenance mode, whether issue can be addressed non-normatively, or in security (if there is a vuln that needs to be addressed), do the triage as a part of our normal process moving forward. That's the plan as I see it -- happy to take comments on proceeding differently. We are grateful that they came in, but will be processing based on our maintenance charter.
<ivan> +1
manu: +1 to the proposed approach, fwiw.
Meeting Cadence moving forward
brent: would love to hear proposals on how often we should meet.
brent: We can always change the cadence.
manu: we should meet at least once a month for maintenance items
… the other thing happening now is the CCG work item promotion call
… happens at the same time as this call -- while we were on our break
… we're discussing things like Confidence Method, Render Method, VC API, etc.
… some of those are already in our charter, others are not yet.
… a few of those need a couple more months to be ready to bring in
… we could also choose to spend a bit more time on them in the CCG
… the suggestion is that VCWG meet once a month, and the CCG meets more often to finish off those specs a bit more
… just a proposal
ivan: Two things, I would propose we keep current timing until we publish RECs, let's not take a break now... maintenance, publish working notes, etc.
manu: my recollection was that we were chartered for at least Render Method and Confidence Method
… I believe there's also a number of specs heading into production like Verifiable Credential Barcodes and the like
… which are nearing production deployments
… and official standardization hasn't even formally started
… we've mostly been focused on maintaining things, but I think we need a pathway for what new work might be and how we charter for it
… it's all stuff that's been in the CCG for awhile
<brent> https://
ivan: Unfortunately, that's not that simple -- scope of the charter says that we maintain, no class 4, security issues -- then there is a separate section that says non-normative documents -- test suites, presentation requests, storage sharing, etc...
ivan: You are referring to thing that are much heavier work -- new cryptosuites, for example.
manu: right. I'm talking about changing the charter
… I'm saying there's a small amount of work we can continue doing
… Confidence Method and Render Method
… but that we also have new work for which we should recharter
ivan: ah. that wasn't clear earlier
brent: One nuance to this -- even for render method and confidence method, our current charter allows us to add those sections and add normative language in that sections in VCDM spec, but scope says "no new RECs" are planned. We could put stuff in VCDM, but not new Render Method spec.
brent: Something to be aware of.
JoeAndrieu: I think Ivan mentioned that as long as work is chartered, we can put it in other specs -- we might be able to create separate document.
ivan: Scope in charter specifically says "in VCDM"
manu: my fear is that we'd do a short term thing, with long term negative consequences
<dlongley> +1 that rechartering can also allow confidenceMethod/renderMethod to be moved to its own spec if the consensus is that current charter interpretation requires different organization
manu: like stuffing Render Method content into the VCDM and then later needing to extract it
<dlongley> +1 to brent, we can do the rechartering when its time to reorganize and fold these things in with the other items we might take on.
brent: I'm bringing it up to inform the group that the charter language is explicit, maybe the group should recharter to more appropriately handle it. Our current charter can be rechartered before Oct 2026... I was remembering our charter as not being this constrained. When those things are ready to move on, maybe we have a serious conversation around rechartering.
brent: We will keep meeting until we get through REC -- once we get through May 15th, you should see a whole new invitation for a monthly meeting -- 2nd Wednesday of the month (to just pick something). That will work until we have more work than a monthly meeting will handle.
ivan: When should the responses go out?
brent: The aim is by the end of the week.
brent: Thanks everyone, good to be with everyone again, see you soon!