W3C

– DRAFT –
SING review of VCWG specifications

12 December 2024

Attendees

Present
brentz, gregb, innotommy, ivan, simone
Regrets
-
Chair
-
Scribe
manu

Meeting minutes

<simone> [round table introduction]

<simone> https://docs.google.com/document/d/1fPEHZYH9pKhq4rNPdVuGs_rfteYEMHF3oaFeOvMoinA/edit?tab=t.0#heading=h.hzz2l1t6gpqq

simone: We have put a general thread model together for VCDM v2.0 at the document above.

simone: We've put this together to think through what could go wrong, and we have some questions for you, as a group

manu: What are we focusing on today?

simone: VCDM v2.0

innotommy: Yes, let's start w/ VCDM v2.0 and move to other specs.

simone: speaking to file format, there can be two kinds of threats -- parsing and rendering -- biggest concern is with context, when parsed/rendered, there might be requests to get external resources, external resource is out of control of data model but can contain bad things. This is a discussion w/ JSON-LD people, SRI might help here.

simone: For bitstring, notes about hash of specific file, which is good, but might not be something for VCDM -- can it be added to spec? Might be delegated to JSON-LD folks?

ivan: That is one of the questions that comes up regularly. The general question of @context is something that should go to JSON-LD folks, in VCDM, we are just "users" of a technology, we don't define it. That being said, we make it very clear when processing a VCDM that you are supposed to cache the context, you are not required to go out to the network and get it.

ivan: This is emphasized in many different places, implementers are expected to not load from the network.

ivan: In addition, for each specific context file, we publish in the spec the hash value for those context files. Even if they get it through the network, implementers are required to compare hash values w/ what's published.

ivan: As maintainers of spec, when REC is published, we don't change context files. There is a check.

ivan: Goign to JSON-LD, there are discussions which are trying to address this issue around context security, not in JSON-LD standard, we are talking about how to refer to context file and put in hash value of file that you expect... SRI-approach in HTML. Considered to be done for JSON-LD in general, we took melody into VCDM spec as well as all the other spec.

ivan: If you look at any spec we publish that has context file, we have table that lists context files and list exact hash value that implementers are suppsoed to look at.

Explains that https://w3c.github.io/vc-data-model/#base-context and https://w3c.github.io/vc-data-model/#integrity-of-related-resources are there to address the concerns above.

simone: WebAuthn might update their spec for dynamic content to sign dynamic content.

simone: That might be interesting to include or consider.

simone: That was result of TPAC conversations w/ them. Providing integrity of dynamic resources.

Rendering

simone: We were wondering about rendering, some JSON might be rendered in HTML contexts, we have to consider in security considerations...

ivan: What do you mean by rendering?

simone: Credential in JSON -- name, surname, picture, application will parse and then display picture, name, and surname.

ivan: Yes, understood, but that's out of scope.

simone: correct, but this has to do with parsing, there might be warnings -- maybe this is already specified -- take care that there is no injection of other JSON or HTML code or other things that might be brought inside the data model.

manu explains that we have a security consideration around code injection in section 9.10 and that digestSRI/digestMultibase mechanisms also provide protections. We do warn about issuer being attacker and injecting tracking code.

<simone> akc iv

simone: Yes, we think it's important to talk about those things in the specification, as you do.

Cryptography

simone: We discussed quantum-ready specifications -- apart from BBS, no alternative for quantum-ready. All Data Integrity specs are not quantum ready, but DI CCG report on post-quantum signatures.

manu: Yes, we are working on post-quantum schemes for DI in CCG ... vc-jose-cose could also support it... that will work on full disclosure and selective disclosure, but the cryptography community doesn't have a solution for a post-quantum unlinkable disclosure scheme, we are actively working on that w/ the BBS community. Work on post-quantum crypto needs to be done, we look forward to SING's support on that.

simone: Yes, if we know that need is there, we can work on recharters to produce different DI for post-quantum, we know that work is being done, so important to point that out.

ivan: No disagreement here, going back to administrative situation -- the modularity of the documents on the VC level are such that post-quantum crypto is not a comment on the VCDM because things specific to crypto live in DI and vc-jose-cose.

ivan: We are talking about cryptosuites here, that's where specific cryptography algorithms live. The remarks you have, only place we can put them is DI spec and not VCDM spec, VCDM spec doesn't get into details of cryptography algorithms at all. That's the way the structure of the documents are.

ivan: If we are talking about exclusively the VC spec, if we are talking about VCDM /and/ others, then it is in scope. Not clear exactly where this comment should go.

manu: Maybe we put it in DI and vc-jose-cose?

ivan: Or overview spec.

simone: Ok, will have to think about where to put this, if I'm a regulator, I'll probably care about seeing something about this. Maybe in VCDM say cryptography is delegated, look there.

https://w3c.github.io/vc-data-model/#securing-mechanisms

manu: Maybe we warn people in each cryptosuite to just say if a suite is post-quantum secure or not.

simone: Ok, that might make sense.

ivan: Yes, maybe we add text in overview as well...

simone: Yes, we might want to tell people to not invent new crypto primitives... use standards and recognized standards, not reinventing things that are weak. We might want to put that in same area.

Serialization

simone: use specific canonicalization algorithms to serialize and deserialize, that should be covered, that is covered by RDF Dataset Canonicalization.

manu: RDF Dataset Canonicalization is a W3C REC now...

simone: Good that we have a standard way to canonicalize to data to be signed.

Threat Actors

simone: We list Holder and Verifier as threat actors.

simone: What can go wrong if Holder can be attacked? What if format can be malformed? What does it do to the wallet/holder?

simone: Can large files difficult to parse be used to attack. By design, is it possible to avoid?

simone: thoughts?

manu: We think that every actor can be an attacker and a victim -- issuers can put tracking identifiers in VCs, holders can resell credentials, verifiers can ask for credentials they shouldn't have... we speak to a lot of these attacks security / privacy considerations.

simone: Ok, yes, now I understand why you have all these protocol related things in privacy/security.

manu: We should have something higher level for digital credentials at W3C on this.

manu: Like FedID WG should care about these attacks on digital credentials, higher level threat model for digital credentials.

simone: Yes, agreed that these are general concerns.

simone: Ok, makes sense... on to CSRF forgeries? sharing security considerations w/ other formats?

simone: In general, focus on format issues -- let's focus on those.

innotommy: I think we covered much of the content of the document, can we move to trust section?

Trust

innotommy: A lot of protection is delegated to the protocol, it's mentioned, we would like to have it addressed more explicitly -- what type of consideration or security aspect are not part of data model, cannot be addressed in data model, what type of delegation is given to the protocols -- to OID4Vp for instance

manu: We do speak to preventing replay, spoofing, etc. in VCDM in security considerations.

innotommy: I do like you say things about this in security/privacy considerations. Can we make it more prominent -- it was an assumption that what was provided in the spec need to use these features in the protocols. These things needs to be checked to ensure that security checks are done before.

manu: Yes, we talk about a lot of this stuff across all the specs, but not clear specifically where we put the text so people pay attention to them.

GregB: Yes, we do put some of this stuff in DI... data model vs. data integrity vs. protocol -- where is the best place to put this stuff so they pay attention to it? How much should we put on data model vs. data integrity vs. protocol.

simone: Yes, we will try to also help by writing suggestions -- security assumptions paragraph, you assume certain types of attacks are mitigated at certain levels.

simone: I think a lot of this can be addressed by stating where in the software layer these attacks are being mitigated.

simone: We need to say something like: "This type of communication is done over a TLS layer or similar", for example.

simone: We need to document assumptions, like "storage of data is stored encrypted".

simone: Might want to look at C2PA for security assumptions. Just list all threats identified and mitigations and where the mitigation is handled.

manu: Perhaps we can put the security assumptions and mitigations in the VCDM to start and move it out to digital credentials in the future.

simone: Yes, we can just start it there, talk about a small model to start and then grow it over time -- it'll be an iterative process.

manu: Ok, we can do something like that in the VCDM -- current security assumptions, list something simple, and then go from there and iterate.

simone: Ok, we can talk about threats and attacks in that section, that we've written up.

simone: About CBOR injection attacks, useful to point to CBOR security considerations section. We did analyze CBOR considerations, in the end it's a format, similar from parsing, specific to JSON -- may be the same point, lots of attacks on image formats. For example, WhatsApp attack -- receive image, vuln in parser for JPEG in WhatsApp -- just to note that those sorts of bad things can happen.

ivan: ok, where do we go from here?

simone: There will be a message from us, we don't think there are blockers to transition -- there is already a lot of security work done in specification. There are just two issues: 1) add security assumptions section, and 2) mapping attacks to threats/mitigations -- these are editorial things.

Simone: We will follow up with the other specs. Which is the best one to do next?

ivan: Data Integrity

manu: Agreed

GregB: Yes

ivan: There is vc-jose-cose next, but a lot of that refers to IETF specs, it's minimal.

simone: Yes, maybe we can check -- look at security considerations section -- picky with security considerations, papers that say that web extensions and relying parties, it's outside threat model -- but this is not helpful, references in FIDO threat model -- sometimes if there are links, it's quicker.

ivan: With my admin hat on, we have at this moment, 5 documents waiting for CR2 -- I am uneasy publishign them one by one, I'd prefer to publish them in one step. No requirement for that. Question is, when will we get to the point where we can publish all of them, from your point of view? Need realistic time frame.

ivan: Our end goal is RECs by Feb 2025, that will be tight.

simone: So, TRs for VCDM, other specs in same transition requests?

ivan: There are 3 that are waiting... VCDM, DI + cryptosuites, and vc-jose-cose.

ivan: All of those are waiting for security review. All of these things are related, we would have preferred to publish all of them in one go. We need all three transition requests to get accepted at some point.

ivan: We want to publish ALL of these specs in Feb 2025 -- they need to all be sync'd -- they all cross-reference each other.

ivan: To make this even more complicated ( :) ) -- we are planning to publish Controlled Identifier Document, as a CR, which also needs a security review -- it had a security review request a long time ago, we discussed it at TPAC, it has to be finalized and have a green light so we can have that as a CR as well.

ivan: We are under enormous pressure here, all of us, need to find the best way to get out of the pressure.

simone: Ok, we will discuss and get back to you, will call for reviews in SING call next week. Will focus on things for tomorrow :) -- we will discuss with Tommaso, will provide feedback, we don't see any blockers for VCDM v2.0 -- that is good.

simone: There are just two issues to just specify things, something can be done w/o blocking CR -- for others, some additional questions to Greg -- but also linked to threats, one threat we're analyzing from admin perspective, clear the transition request for VCDM others need to talk w/ Tommaso

ivan: Ok, we are waiting for your feedback.

<simone> https://digital.gob.es/dam/es/portalmtdfp/especificaciones_tecnicas/2024-06-30_Presentacion_ecosistema_de_verificacion_de_edad-v1_0eng.pdf.pdf

Analysis of Spanish Wallet of VCs

simone: This is using OID4VP, using VP and VC for W3C. They are using did:key, one problem we see here, there is an important thing about linkability, which is issuer signature.

simone: with BBS or something similar, from cryptographic perspective, blind signature -- look at infra, one issuer, spanish government, also idea ... 3rd party credentials generated by KYC -- give info about issuer you're using. Leaking information that you're using spanish vs. italian government.

simone: Cryptography as a solution for that, maybe BBS, or something else? Is this something solveable.

simone: Interested to learn something about this.

greg: I can bring it up w/ BBS folks, depends on how much unlinkability you want here, more or less unlinkability.

Minutes manually created (not a transcript), formatted by scribe.perl version 240 (Tue Dec 10 03:59:59 2024 UTC).

Diagnostics

Maybe present: greg, manu

All speakers: greg, GregB, innotommy, ivan, manu, simone

Active on IRC: ivan, manu, simone