Closed msporny closed 6 months ago
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.
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.
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.
The issue was discussed in a meeting on 2024-01-09
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 foriat
, but notnbf
?, exists in Section 3.3)exp
/validUntil
(edit: Looks like the clarification exists in Section 3.3)Specifically, it's not clear:
validFrom
has more precision thaniat
ornbf
validUntil
has more precision thanexp
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
orvp
subtree of the JWT.At a minimum, the specification needs to clarify the things above that are not clear.