Securing the VC Data Model with JOSE

[OR13]

I created this draft a while ago for discussion:

https://github.com/OR13/draft-osteele-vc-jose

The key point of this document was to clarify the boundary between the "Core Data Model" and the "Securing the Core Data Model".

In particular, I think that securing a JSON data model is best accomplished with JSON Web Signatures... not JSON Web Tokens.

Similarly, I think Verifiable Presentations are best secured with JSON Web Encryptions not JSON Web Tokens.

It's my understanding, that there was interest in creating a new form of "securing the core data model" at TPAC, oriented towards JOSE more generally, and not relegated to JSON Web Tokens only.

I've done implementations of both, I find the mappings massively simpler... In part because of the unfortunate mapping that shipped for VC-JWT... specifically the. "instead of or in addition to" language.

It's very tempting to create a clean new format that sidesteps some of the mistakes made in the VC-JWT mapping, and is not encumbered by "breaking changes" since vc-jws and vp-jwedo not exist yet.

[OR13]

I would like to develop an experimental spec for vc-jws and vp-jwe to pair with the open source implementation we have developed here: https://github.com/transmute-industries/verifiable-credentials

The spec would map the core data model to vc-jws and vp-jwe similar to the current spec for:

https://github.com/w3c/vc-jwt

[mprorock]

I am a big fan of this approach - it seems well formed enough already that we will likely get started on an implementation in go to test viability

[David-Chadwick]

I also like this approach. In particular it clearly differentiates between a credential and a signed (verifiable) credential and further confirms the VCDM view that a credential can be proofed in many different ways.

In our current NGI Atlantic project we have said we will develop a mechanism for sending encrypted VCs to the verifier, and this draft does this for us. (My original thought was to encrypt the VC and enclose the encrypted VC in a plain VP thus not changing the current VP spec, and allowing the verifier to determine if the VC is encrypted or not. Comments?).

One minor change. I would like you to introduce the role of issuee - the entity that receives the VC from the issuer. Then there is no need to talk about the first holder. The holder is then the entity that presents the VP to the verifier. So we would have 4 roles not 3, each with a clearly specified role to play.

[TallTed]

[@David-Chadwick] The holder is then the entity that presents the VP to the verifier.

This implies that there is only ever one VC holder, who presents a VP to a verifier. There is no allowance in this framing for holder-(or issuee)-to-holder-...-to-holder-(or presenter) transfer, which has been discussed and agreed to be a legitimate part of the VC/VP ecosystem many times.

I'm confident you'll immediately agree that my complicated transfer is legit.

I hope you'll also agree that we all need to take great care to consistently use correct terminology -- including flagging where there isn't yet a settled term, and using sufficient descriptive language there to make plain what is meant. Such care is necessary not only with outside parties, but also within the groups doing this work, as misunderstandings are too easy, and lead to flawed (at best) output documents.

[David-Chadwick]

Of course I agree that any entity can pass on a VC to any other entity. But the point is that an entity that never presents a VC to anyone else is never known by the outside world to be the holder. i.e. it never performs the holder role. So the holder (role) is always the role played by the entity that presents the VC to the verifier (role) and the only entity that ever plays this role. Likewise the verifier (role) is the only role that receives a VC (or VP). So I repeat, we need 4 roles that any entity can play (issuer, issuee, holder, verifier), and any entity can switch between these roles according to the role it is playing at any particular time.
For example, using the existing OID4VCI draft protocol, in which A issues VCi to B.
B, playing the issuee role, contacts A, who plays the issuer role.
A asks B to present VCx to identify itself
B, now playing the holder role, presents the VCx to A, who plays the verifier role.
A verifies VCx.
A, now playing the issuer role again, mints the new VCi and gives it to B, who again plays the issuee role
I hope this clarifies why 4 roles are needed and how entities can switch roles midway during a transaction.
Note that the subject never occurs in this role model.

[msporny]

Digital Bazaar is supportive of vc-jose, feels like a much cleaner mapping than vc-jwt. In addition to the concerns that @TallTed has raised, there are some questions we have -- such as what signing algorithm is used, if there is a canonicalization step, how many values are allowed in the signature field, whether the entire payload is base64-encoded, etc. There are also a few concerns we have, such as the media-types needing a +jose extension (or something similar). That said, the spec is intriguing enough for us to support its incubation to see where things go -- feels like it's already a better solution than vc-jwt.

[OR13]

AFAIK, application/jose would apply to all well formed compact JWS / JWE... and its already registered:

https://www.iana.org/assignments/media-types/media-types.xhtml

So we don't technically need a new media type that is specific to VCs.

We could write a small IETF RFC to request application/jose+vc or application/jose+vp if W3C cannot register for us, or we thought that was a really good idea to do.

My proposal on this issue, also aligns with this proposal to protect the W3C Verifiable Credential Data Model with COSE Sign1, which I made here: #978

[TallTed]

application/jose+vc and application/jose+vp are backwards. If something like these are to be pursued, they should be application/vc+jose and/or application/vp+jose.

[letmaik]

I like this. For it to respect IETF, someone would have to register nbf and exp as JOSE header parameters. Similarly, iss is currently only allowed for JWEs. Note that this isn't an issue with COSE once draft-ietf-cose-cwt-claims-in-headers is done.

I'm not a huge fan of the duplication of fields in the header and payload, e.g. "iss" and "issuer" or "exp" and "expirationDate". Especially for "iss" this would have to be matched to "issuer" to avoid security issues.

[David-Chadwick]

See issue w3c/vc-jose-cose#39 for why I think exp should not always be equated to expirationDate.
i) expirationDate is optional but exp should be mandatory as crypto does not last forever
ii) expirationDate could be decades in the future, but the crypto will most likely expire long before that

[OR13]

Perhaps we should skip to COSE and HPKE?

https://github.com/WICG/mobile-document-request-api

[OR13]

Here is a more recent draft that focuses only on securing the core data model with a JWS:

https://transmute-industries.github.io/vc-jws/

[OR13]

I will be developing a direct analog in COSE shortly.