Verifiable Credentials Working Group Telco — Minutes

Date: 2024-07-10

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Brent Zundel, Kevin Dean, Hiroyuki Sano, David Chadwick, Will Abramson, Benjamin Young, Dmitri Zagidulin, Joe Andrieu, Greg Bernstein, Ted Thibodeau Jr., Dave Longley, Gabe Cohen, Manu Sporny, Steve McCown, Jennie Meier, Phillip Long, Anil John, David Lehn

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Will Abramson, Manu Sporny

Content:

Brent Zundel: agenda possible convo with ebsi, conversation about media types and conversation about data integrity.

Benjamin Young: Test suites nearing ready integration points. Hope to have test suite office hours next week.
… hope to get lots of people involved.

Greg Bernstein: update on BBS, base spec has been updated and released.
… awaiting cryptographic review.
… slight change in the ordering of things to do with the hash. Is a breaking change to the sigs.

Greg Bernstein: Blind BBS signatures update: https://www.ietf.org/archive/id/draft-kalos-bbs-blind-signatures-01.html#.

Greg Bernstein: BBS signature scheme update: https://www.ietf.org/archive/id/draft-irtf-cfrg-bbs-signatures-06.html.

Greg Bernstein: BBS Per Verifier Id (Pseudonyms) update: https://www.ietf.org/archive/id/draft-vasilis-bbs-per-verifier-linkability-01.html.

Manu Sporny: No word from ebsi.

1. Media types for vc-jose-cose.

1.1. reconcile media types with VCDM media types (issue vc-jose-cose#282)

See github issue vc-jose-cose#282.

Brent Zundel: good news, vc data model has media types registered!
… need to reconcile media types in vc jose cose with these media types in iana.
… do we need to do something about this.

Manu Sporny: Strange for WG to register a different media type for jose cose. We should use the base media types.
… expect application/vc+jwt and vc+sdjwt vc+cose.
… Requested to avoid application/vc+sd-jwt.
… This is being used elsewhere.
… it is confusing to hear the work verifiable credential in a spec if unsure if it is a W3C or IETF VC.

Dave Longley: +1 to everything Manu said, other groups shouldn’t add confusion to VCs and we should register application/vc+sd-jwt and application/vc+jwt here.

Brent Zundel: use application/vc and /vp as the base media types. Extend as usual with +jwt +cose etc.

See github pull request vc-jose-cose#283.

Gabe Cohen: I agree.
… Raise a PR to address this.

Brent Zundel: Thanks!

See github pull request vc-jose-cose#283.

Ivan Herman: Gabe, check the two diagrams in the VCDM for jwt and let me know what needs changing.
… there are media types there that need adapting.

Manu Sporny: supportive of the PR.
… searching for +cose and +cwt suffix in the registry and not seeing anything, we would be the first ones to register.
… sounds like +cose is the right thing to do.

Gabe Cohen: https://datatracker.ietf.org/doc/html/rfc9052#name-iana-considerations.

Manu Sporny: wondering why we would be the first to register a media type with +cose.

Gabe Cohen: believe +cose is registered in above link.

Brent Zundel: cose is registered, but nothing with a +cose registered.

Manu Sporny: yes, what Brent said… that’s what’s confusing to me.

Ted Thibodeau Jr.: decentralgabe – RFC 9052 registered media type application/cose. It did not register structured suffix +cose.

Manu Sporny: yet, +cose is in the structured suffix registry :) ^.

Brent Zundel: hearing no opposition to proposed change.
… please indicate approval on the PR.
… moving into data integrity conversation.

2. Data Integrity.

2.1. Multiple significant security vulnerabilities in the design of data integrity (issue vc-data-integrity#272)

See github issue vc-data-integrity#272.

Brent Zundel: See Gabe’s comment within the thread.

Brent Zundel: concerns about security implications of data integrity signatures.
… extensive conversation on the issue.
… Original poster of issue as signaled acceptance of the proposal to address the issue.

Phillip Long: +1 for Gabe to walk us through it.

Brent Zundel: pending a P.R to address the issue.
… gabe could you walk us though the proposal.

Gabe Cohen: spent a long time trying to understand this issue.
… First proposal is adjustment to @vocab. This seems uncontroversial. P.R already open.
… Second thing is we need some text about @context validation, we need to be very clear about how to handle untrusted contexts.
… There is some discussion around a proposal to add signatures to context to make them tamper evident.

Dave Longley: +1 to changes to @vocab, +1 to some clarifying text around validation requirements, +1 to some tests if we can make them make sense – validation is application-level and maybe really for a “best practices doc” but fine if we can make it work.

Dave Longley: -1 to locking contexts for all the reasons listed in the issue already.

Gabe Cohen: The outcome of the proposal would be 2 or 3 issues to address these points and associated PRs.

Manu Sporny: Agree that 0,1,3,4 parts of the proposal are good ideas.

Dave Longley: +1 to Manu.

Manu Sporny: 0 is easy, 1 will take some work.
… need to be careful not to pass into application space.

Anil John: +1 to 0,1,3,4 … Have a question regarding 2. Will put myself on the queue to ask.

Dave Longley: +1 to Manu, important not to go into the application layer.

Manu Sporny: will come back to 2, that one is controversial.
… 3 is a variation of 1 should be fin.
… For test suites, we can improve them to check this. Need to tell implementers to check for bad contexts.

Dave Longley: +1 that we’re telling implementers to essentially create a special application-level rule, but it could work.

Manu Sporny: Telling issuers and verifiers to implement business logic to pass the test suites.
… +1 to almost all of the things.
… we should not mix context integrity with signatures.
… it limits some use cases the people are relying on.
… Forces disclosure of all of the contexts.
… Forced to leak data if mix cryptographic hash with the context.
… There are other ways to prevent this attack, would be a strong -1 for mandated context integrity protection.

Dave Longley: +1 to not locking contexts for all those reasons and because it doesn’t fix the problem :).

Brent Zundel: For number 2, the integrity of contexts. Is it sufficient to recommend people to use the related resource property.
… use related resource for context integrity for people who want it.

Joe Andrieu: When talking about context integrity, we are talking about some hash. Not that the context is signed over.

Gabe Cohen: for 2 I intended to mean a signature, for 1 I mean a hash.

Manu Sporny: I think they are the same. We aren’t talking about signing over the property and the value. We are talking about including the hash of every context in the @context property.

Joe Andrieu: We do not currently sign over the @context property.

Anil John: Is option 2 not a secure meta data distribution problem.
… What is the problem we are solving here.
… Seems to be multiple options regarding trust registries, having pointers from DID documents.

Dave Longley: Let someone else speak to aniltj.
… Believe option 2 does not solve the problem raised in that issue. That issue is about a validation problem.
… where terms are read from a context that is not known.

Anil John: Is not (2) a secure metadata (@context files being such a thing) distribution problem?

Dave Longley: even if contexts never changed and were integrity protected, you can still make these mistakes if you don’t know the context.

Gabe Cohen: responding to aniltj, yes secure meta data is part of it.
… folks advocating for 2 are concerned that the issuer signed over the context and its properties so they remain untampered for any verifier.
… building on brent, wondering if we could have a new data integrity suite to includes signing over context.
… still a discussion to be had about whether it addresses the concerns.

David Chadwick: commenting on the idea of using the related resource property, that is signed over. Noting to stop issuer adding relatedResource property to any URI.

Dave Longley: +1 David is correct.

Manu Sporny: DavidC is correct.

David Chadwick: Cannot stop an issuer from using this.

Brent Zundel: question is do we want to encourage people to use this as a means of addressing this issue.

Dave Longley: -1 it does not address the issue for the reasons I stated, this is a validation issue, not a security issue.

Greg Bernstein: part of this issue from a security point of view comes down to understanding who controls what inputs.
… When we talk about this context value, we dont secure the value of the context, we secure all the quads.
… do we want to secure the value of the context?

Manu Sporny: yes, +1 to Greg – it’s the verifier that controls the input wrt. @context.

Dave Longley: +1 to GregB, with the rdfc cryptosuites, the underlying information is secured, not the specific expression, allowing alternative expressions.

Greg Bernstein: or do we accept that the context is under the control of the verifier. E.g. the verifier idicates the context values they accepts.
… Verifier says they wont take a context that they dont understand.
… Don’t protect the context value, because that isn’t part of the inputs that need to be protected. The verifier controls the context.

Anil John: +1 to Greg regarding the Verifier doing due diligence on the @context’s @did’s it finds acceptable. In fact, that is what we are doing in practice.

Manu Sporny: brent said could we just use relatedResource. We could, but how normative would we want to get with that.
… is it mandated that if you have a relatedResource with a context, the verifier must through an error if the hashes dont match.
… We would end up getting to a lot of the same issues.
… GregB is right, the verifier determines the contexts and the hashes of contexts that they accept.
… security model is different from the way jose cose do things.
… confusion in this thread. JCS does sign over the context values.
… but that in itself is not enough, verifier has to choose the contexts they accept. This is a validation layer. An application issue.
… if we try to solve this at the crypto layer, you make use cases not possible and it doesn’t solve the problem.

Dave Longley: you can’t know how to interpret JSON from just reading its key names (a JSON key of “firstName” may as well say “asdf”).

Manu Sporny: Things to consider. This can be viewed as a meta data distribution problem.
… We tell people do not ever load contexts over the network.
… once a spec is published, verifiers and issuers can lock to very specific contexts if they want to do that. This is expected.

Dave Longley: you need to know context to properly interpret JSON (whether it’s explicitly given like in JSON-LD via @context or you get it out of band somehow).

Manu Sporny: never have to go to the internet. You should not be doing that. Should have a local copy.
… When you get data in, you should check every context and know that you understand these.
… This addresses the attack.

Brent Zundel: Need to start transition to what the next steps are.
… if relatedResource as a property doesn’t fully address this, we did come up with a mechanism for providing tamper evident information. A VC.
… What if you are concerned about this, issuers can provide a VC of the context file.
… Next, is concern about the context, the same as concern about the public key. Is this key related to this issuer.

Joe Andrieu: conflating issues between the integrity of the property. Not convinced data integrity does not secure the value of the context.
… If I can manipulate the context and still have the VC validate that feels like a huge problem with data integrity.

Gabe Cohen: Joe - please review the presentation which has examples to prove that if you manipulate the context verification can still succeed https://docs.google.com/presentation/d/1MxLMIjubCVykDux8fBWcisXLu9WeE0LxZzU_xlANUMc/edit.

Dmitri Zagidulin: and integrity of the file is addressed by the digest mechanism.

Anil John: not a tech provider or tool user. I am an user of this technology.
… We rely on the recommendations of this group.
… As a verifier, what we are doing is manually verifying and reviewing the context to ensure it is acceptable.
… Ensure it is coming from an entity whose attestations we want to use in our business processes.
… Just signing the context itself, doesn’t solve this problem for me. Just gives confidence that the context has not changes and is coming from an specific entity.

Dave Longley: +1 a signature on a context tells you nothing about what it is/what it means, context must be processed (at runtime or understood before that and coded against).

Anil John: Struggling to reconcile what is important and relevant to what we are trying to do.

Greg Bernstein: The VC-DI-EdDSA and VC-DI-ECDSA specs allow two different canonicalization approaches. One (JCS) signs over the “JSON”, the other (RDFC) signs over “quads” which include complete “term definitions” (URIs) expanded from context.

Ted Thibodeau Jr.: First, data integrity signs over quads which is the result of applying the context to the json being signed over.

Manu Sporny: yes, exactly, TallTed is exactly right.

Ivan Herman: +1 to ted.

Benjamin Young: +1 good summary, Ted.

Joe Andrieu: thanks, Ted.

Dmitri Zagidulin: @decentralgabe - I missed the previous discussion of – doesn’t relatedResources securing the context address this concern?

Ted Thibodeau Jr.: This is open world, VCs can go anywhere at any time, I’ve never verified a VC from issuer X… I need to get context file that’s relevant for their VCs – this is not the /default/ context, this is the Verifier X context, in addition – I have to retrieve it and make use of it and have assurance that context file that I retrieve is the same as the context file that was used when generating the VC.

Dave Longley: to respond to TallTed, I think it is the question around secure meta data delivery.
… Able to get some context from some source and have confidence it is the context you intended.
… on the queue to discuss whether to context value is secured.
… the original string of the context is not secured. The context property is fully processed to generate the nquads from jsonld.

Joe Andrieu: so the property is secured. It probably shouldn’t be dropped.

Dave Longley: These quads are secured.
… If you were to manipulate the context in any meaningful way the sig would fail.

Manu Sporny: happy to raise PRs for 0,1,3,4. Everything except context integrity protection.
… Think I have enough from the group for this.
… will take a week or two.
… On the queue to respond to brent, we provide an algorithm for how to retrieve the public key but someone could still say you didn’t sign over the public key.
… This would be the same security disclosure we are discussing here.
… You have to as a verifier vet certain things. The context. The public key. Other types of meta data.
… This is a good analogy.

Ivan Herman: related to manu around the PRs to come.
… manu said, you have to publish the hash of the contexts they create.
… Are we sure we really make it clear that authors of new contexts have to publicly disclose the hash.
… if this isn’t there then it should be.

Gabe Cohen: question about the use of JCS.
… This could be a way out if JCS is signing over the context value.
… How is this communicated.

Greg Bernstein: Its in the cryptosuite name…

Gabe Cohen: What about nested contexts. Contexts that reference other contexts. How do we secure those.
… For 2 it may be worth continuing this in a new issue.
… Some people not present who might still need convincing.

Ted Thibodeau Jr.: it seems that along with disclosure of context hashes, the context hash should (maybe must) be included in the VC, somehow.

Dmitri Zagidulin: Main question is doesn’t the relatedResource mechanism address a lot of these concerns.

Greg Bernstein: See for example: ecdsa-jcs-2019 and ecdsa-rdfc-2019 in the VC-DI-ECDSA spec.

Brent Zundel: relatedResource exists inside of the data model. Would work only when data integrity is signing VC data models that include related resource.

Gabe Cohen: thanks, makes sense.

Manu Sporny: ivan asked if we should add language around providing hashes of finalized contexts.
… Think it is fine to say they should. Concerns around using MUST.
… There are other reasons why you may not need to publish a has.
… schema.org is well known. They don’t need to publish hashes for there contexts.
… I might as a verifier, retrieve something and lock to a specific hash that I retrieved.

Joe Andrieu: schema.org is a canonical example of semantic drift.

Manu Sporny: We need to think about the use cases deeply before saying MUST around providing context hashes.
… The text we have in the spec is enough to address the attack raised in the issue.

Dave Longley: note: if a context changes in a way that de-syncs it from the originally signed information, the signature will fail – because the original context contents are “baked into” the originally signed information.

Manu Sporny: A known bad context was included in the verifier as a good context. The end.
… it was misconfigured software.
… We already have that language in there.

Dave Longley: so if a dynamic context is used – signatures on existing VCs will start to fail – and that would need to be ok with people taking that approach.

Manu Sporny: We can clean it up and clarify.
… many of these solutions are problematic. The relatedResource and including the hashes in the signature is not solving the problem.

Dave Longley: fundamentally: you can’t read a term defined by a context without understanding that context.

Joe Andrieu: I don’t agree, I think today people defining contexts can create a URL for a context that has a hash in it.
… We don’t have to change the VCDM to support that.

Phillip Long: +1 to Joe’s use hashes in @context files if you want them secured.

Brent Zundel: we have a path forward. Thanks for that. look forward to seeing those PRs.

Dave Longley: +1 to Joe’s suggestion as a layered way to do things people may want.