Meeting minutes
Brent Zundel: 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?
Michael Jones: Fix to VC JOSE COSE?
Recommendation next steps
Brent Zundel: 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 Zundel: 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 Herman: 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 Zundel> w3c/
<Brent Zundel> "§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 Zundel> comment source
Brent Zundel: For each of these comments, I will provide text and link to source of comment.
Brent Zundel: 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 Herman: Any response we make is better to send via email.
Brent Zundel: I will do that.
Kevin Dean: Is there something we can add to the response to provide reasoning? Out of scope for current scope of work?
Brent Zundel: 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.
Michael Jones: That's fine.
Data Integrity comments
<Brent Zundel> "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 Zundel> comment source
Brent Zundel: The one comment on data integrity made by Torsten of SPRIND, they do not support the specification but are not formally objecting.
Brent Zundel: This should be familiar to everyone in the meeting, we had long conversations about this as we were developing data integrity.
Brent Zundel: 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 Zundel> w3c/
<Brent Zundel> "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 Zundel> comment source
Brent Zundel: We have two comments, both suggest publication... one comment is about COSE examples being incorrect -- we have fixed this issue.
Ivan Herman: This is waiting in a PR, correct?
Brent Zundel: We plan to merge that PR after the call today.
<Brent Zundel> "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 Zundel> comment source
Brent Zundel: 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 Herman: 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.
Michael Jones: We will consider addressing this concern, consensus might not result in a change.
Brent Zundel: Any other comments on VC JOSE COSE before we move on?
CID
<Brent Zundel> w3c/
Michael Jones: I registered the media type.
Brent Zundel: We had a number of comments on this one.
<Brent Zundel> "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 Zundel> comment source, answered by team contact
Brent Zundel: Ivan has responded to this comment, it is a superset of DIDs.
<Brent Zundel> "§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 Zundel> comment source
Brent Zundel: They've asked for justification of the technology.
Brent Zundel: We thank the commenter, we will try to address the concern in a future version of the specification.
Ivan Herman: Can we make a minor change to address this issue?
Manu Sporny: We should take our time to pick wording that's not controversial.
Brent Zundel: Agree with that approach.
<Brent Zundel> "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 Zundel> comment source
Brent Zundel: 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 Zundel: Any other comments on this one?
BSL
<Brent Zundel> w3c/
Brent Zundel: 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 Zundel> "§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 Zundel> comment source
Brent Zundel: There is a table without a title, raised issue 204 to track that.
Brent Zundel: The second comment was about ZKPs and anti-correlation and if we could figure out a way to do this using a ZKPs.
Brent Zundel: 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 Herman: can we add the title and get rid of issue 204?
Manu Sporny: yes
Brent Zundel: I will convey that to the commenter.
further steps towards REC
Brent Zundel: I think we have actions for Manu Sporny, mike, and me -- we'll get those items done.
Ivan Herman: We need a date for the final version -- what is it going to be?
Ivan Herman: Manu Sporny, before you create final versions, final redirections need to be in place, right?
Manu Sporny: yes. put the final redirections in place
… hopefully the hashes won't change
Ivan Herman: there may be a new line feed…
Manu Sporny: ok.
Ivan Herman: it will be done by the end of the week
Manu Sporny: for the date: May 15th? May 22nd?
Ivan Herman: how much time do you need to make the final versions?
Manu Sporny: a weekend? maybe?
Ivan Herman: 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 Zundel: ok, anything else on recommendation next steps before we move on?
Brent Zundel: anything more on recommendations next steps topic?
Press Release
Ivan Herman: 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 Sporny: usually there are testimonials
… are you looking for those too?
Manu Sporny: usually there are testimonials -- are we looking for that?
Ivan Herman: Yes, we usually ask the group members for testimonials -- let's try to collect them in one place.
Manu Sporny: Why don't we cast a wide net, asking WG members, CCG members, etc?
Ivan Herman: Let's start with WG Members first, just personal opinion. I would hope several testimonials in from WG Members.
<Brent Zundel> Collection point on GDoc for testimonials
Brent Zundel: 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 Zundel: Good news is we got security reviews... timing wise, they came in during Proposed Rec.
Brent Zundel: 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 Herman> +1
Manu Sporny: +1 to the proposed approach, fwiw.
Meeting Cadence moving forward
Brent Zundel: would love to hear proposals on how often we should meet.
Brent Zundel: We can always change the cadence.
Manu Sporny: 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 Herman: 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 Sporny: 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 Zundel> https://
Ivan Herman: 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 Herman: You are referring to thing that are much heavier work -- new cryptosuites, for example.
Manu Sporny: 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 Herman: ah. that wasn't clear earlier
Brent Zundel: 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 Zundel: Something to be aware of.
Joe Andrieu: 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 Herman: Scope in charter specifically says "in VCDM"
Manu Sporny: my fear is that we'd do a short term thing, with long term negative consequences
<Dave Longley> +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 Sporny: like stuffing Render Method content into the VCDM and then later needing to extract it
<Dave Longley> +1 to Brent Zundel, we can do the rechartering when its time to reorganize and fold these things in with the other items we might take on.
Brent Zundel: 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 Zundel: 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 Herman: When should the responses go out?
Brent Zundel: The aim is by the end of the week.
Brent Zundel: Thanks everyone, good to be with everyone again, see you soon!