JWT encoding

[David-Chadwick]

This is a placeholder to ensure that any ambiguities in how to create JWT encoded verifiable credentials and verifiable presentations from credentials and presentations respectively are removed in V1.1. This issue has been raised with the DIF, the OIDF, as well as the VC WG so that everyone with experience in JWT encoding can say where their implementation issues arose.

[kdenhartog]

I've not had enough implementation experience directly with JWT based VCs to help out on this one. @OR13 is this something that you might be able to help out with?

[OR13]

I am happy to help, I've got some strong opinions on where JOSE should be respected, and where it should be hands off defining how a VC looks.

Of particular interest is JOSE support for multi message proofs, specifically to support BLS12381 and Merkle Proofs.

[David-Chadwick]

Discussions in the OIDC group indicated that if a user has multiple credentials from multiple issuers, with different DIDs identifying him/her in each one, and the claims request them all be presented, then multiple JWT VPs will need to be created, one VP per VC. This is because a JWT can only have a single signature proving ownership of one DID.
Other clarifications that might be needed are either to describe how JWTs could identify one of the subjects when there are multiple subjects in the VC, or to indicate that JWTs cannot be used to issue multi-subject VCs.
Finally some people have suggested that which properties should be copied from the Credentials into JWT claims (issuanceDate etc) should be more strictly specified leaving no room for duplication of values

[TallTed]

Presenting claims (from multiple VCs) about multiple DIDs, where all the DIDs identify the same entity, would seem to be a major privacy issue which should be warned about, if nothing else.

[peacekeeper]

One question that still keeps confusing implementers is whether to use nbf (which is what the spec says) or iat (which feels closer to issuanceDate), or both.

Of course this has been discussed quite a bit in the WG, but I don't think it's clear for implementers.

[OR13]

Its helpful to be able to prove something at a time, and also say when it will be valid to use the proof...

`vc.issuanceDate` -> `nbf` 
`vc.expirationDate` -> `exp` 
`vc.proof.created` -> `iat`

... at least as I would hope for them to be interpreted....

Note the directionality is important... we must map from a common data model to and from a serialization, and not confuse the two by trying to pretend the serialization is the data model... the VC Data Model is useful without JWT / JWS... just like JWT / JWS are useful without the VC Data Model.

[David-Chadwick]

There is no proof property in JWT VCs (even though I preferred that there had been). So we cannot do the third of your mappings. So I suggest that issuanceDate maps into both nbf and iat.

[OR13]

@David-Chadwick then there will be no way to "use VC-JWT for a post dated check"... which seems pretty sad... and also like a way of limiting use cases by assuming a serialization is more important than the data model...

IMO a valid use case for VC-JWT would be a "post dated check"... with iat ~ right now and nbf ~ 1 week so my bank acccount has enough money in it.

[David-Chadwick]

@OR13 I don't disagree with you. If Manu had not rejected the idea of all VCs having a proof property (which I advocated) then this could have been solved by having a proof property for JWT signed VCs. I am happy to support this in V2 of the standard, but it is a breaking change.

[dlongley]

There are also the validFrom, validUntil, and issued properties that we hoped to use instead that were mentioned in notes here:

https://www.w3.org/TR/vc-data-model/#issuance-date
https://www.w3.org/TR/vc-data-model/#expiration

With those properties, the mappings would be:

vc.issued => iat
vc.validFrom => nbf
vc.validUntil => exp

[David-Chadwick]

Thanks @dlongley. This solves the issue in the next breaking change of the standard. We can put a note in v1.1 to say that this is what will be anticipated in a future version

[David-Chadwick]

PR #828 has been produced to address the JWT ambiguities issue in v1.1 (clarifications only and no breaking changes)so as yet it does not contain any changes to the time stamps.

[iherman]

The issue was discussed in a meeting on 2021-10-27

• no resolutions were taken

View the transcript

2.12. JWT encoding (issue vc-data-model#809)

See github issue vc-data-model#809.

Manu Sporny: but these changes look a tiny bit normativeA?.

Kyle Den Hartog: I think we should discuss it on a call in more detail, this is hard to understand across all the requested changes....
… so i would propose we defer to v2.

Brent Zundel: it sounds like there are editorial changes this issue could track, and also normative changes that should wait for v2.
… manu: i think we should move the signing mechanics into a distinct spec per encoding, as we have discussed chartering the next WG to be able to do.
… i think we cleaned up well here and we should end on this tidy note.
… thanks to scribes and ivan and editors, see everyone next week!.

---

[Sakurann]

I believe this has been addressed by the existence of a JWT-VC deliverable in a rechartered VC WG.
Suggest people to translate their concerns raised in this thread into the issues in a vc-jwt Github repository.

[brentzundel]

No response since marked pending close, closing.