Unclear semantics wrt. JWT claims vs. VC properties

[msporny]

The semantics for at least the follow JWT/VC claims/properties are unclear:

• iss/issuer (edit: This is defined in Section 5.1.2)
• sub/id
• aud/domain
• iat/nbf/validFrom (edit: Looks like the clarification for iat, but not nbf?, exists in Section 3.3)
• exp/validUntil (edit: Looks like the clarification exists in Section 3.3)

Specifically, it's not clear:

• if these properties MUST be the same values
• what happens when validFrom has more precision than iat or nbf
• what happens when validUntil has more precision than exp
• if you can not provide one value, but provide the other

These same issues existed in v1.0 and v1.1, which led to interoperability failures. The issue seems to be worse now given that the properties are now co-mingled among each other, and don't exist in a vc or vp subtree of the JWT.

At a minimum, the specification needs to clarify the things above that are not clear.

[selfissued]

There was pretty uniform agreement that the requirement to have a mapping between VC body claims and securing method claims was a mistake. Not having this mapping is one of the major improvements of 2.0 over 1.1.

It seems that you're asking for some of this mapping to be restored. In my view, that would be a big step backwards.

[msporny]

There was pretty uniform agreement that the requirement to have a mapping between VC body claims and securing method claims was a mistake. Not having this mapping is one of the major improvements of 2.0 over 1.1.

The mistake was having two ways of doing it. There was broad agreement on that.

There wasn't broad agreement on saying nothing about the expectations here.

It seems that you're asking for some of this mapping to be restored. In my view, that would be a big step backwards.

No, I'm requesting that the specification clearly state expectations. At present it doesn't. Documentation needs to be added to clarify the remaining points above.

[decentralgabe]

It's reasonable to think of how implementers answer the question "do the fields x and y need to match?" where x and y can be issuer and iss, for example. Or we could say it doesn't matter, but there are likely repercussions for that. We need to find a delicate balance between not providing optionality (make a clear decision) and reducing the burden of mapping.

My view is that the simplest thing would be to state that securing provided by VC-JOSE-COSE is independent of the semantics in the embedded VC.

[iherman]

The issue was discussed in a meeting on 2024-01-09

• no resolutions were taken

View the transcript

1.2. Unclear semantics wrt. JWT claims vs. VC properties (issue vc-jose-cose#205)

See github issue vc-jose-cose#205.

Manu Sporny: one of the big mistakes with the jwt stuff in v1 and 1.1. was the mapping or not of iss to issuer.
… we should not provide two ways to do this mapping this time round. We should be consistent.
… hoping for text that makes this very clear.
… think there are only three fields that we need to provide explicit guidance on.
… raised issue 205 to track this.

Michael Jones: gabe has agreed to take this on. we agree there should be one way to do the mapping.
… agree there is a small number of fields we want to say something about.
… think we are on track.

See github issue vc-jose-cose#195.

Michael Jones: moving on to issue 195. To do with horizontal review.
… more of a progress report.