You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Initially we supported the encryption rules for JARM based on 18013-7. The new definition in OID4VP is less strict (other related issue to this: #438).
For JARM responses we used the kid in the encrypted JWE header to determine which key should be used for decryption. There is no requirement on the kid in HAIP / OID4VP, meaning this approach won't work anymore.
The JARM spec defines:
(OPTIONAL) The client decrypts the JWT using the key determined by the kid JWT header parameter. The key might be a private key, where the corresponding public key is registered with the expected issuer of the response ("use":"enc" via the client's metadata jwks or jwks_uri) or a key derived from its client secret (see section 4.2).
But since this step is marked as optional, I'm not 100% sure whether we can expect a kid in the response (is it optional because encryption is optional, or is it optional even if encryption is used?). Also Since there is no requirement to include the kid in the client metadata JWKs AFAIK.
I think it can be useful to make kid required to identify the encryption key used, but otherwise there might need to be some guidance on how to associate the encrypted response to the created request. For DC API it's easier (as the response is submitted by the frontend). For non-DC API requests I could see an unique response_uri per request working, however this conflicts with e.g. the requirements around x509_san_uri (which it seems is about to be removed in #430) where the response_uri must match a uniformResourceIdentifier in the x509 cert. It doesn't seem feasible to generate a new cert for every request.
The text was updated successfully, but these errors were encountered:
We ran into the same issue. I think we would at least need some language that says if the kid is provided by the verifier (client) in the jwks, the wallet MUST add the kid to the JWE. There are other ways to determine which ephemeral key was used by the verifier but having kid as an option would be nice for some implementations, including ours.
Initially we supported the encryption rules for JARM based on 18013-7. The new definition in OID4VP is less strict (other related issue to this: #438).
For JARM responses we used the
kid
in the encrypted JWE header to determine which key should be used for decryption. There is no requirement on thekid
in HAIP / OID4VP, meaning this approach won't work anymore.The JARM spec defines:
But since this step is marked as optional, I'm not 100% sure whether we can expect a
kid
in the response (is it optional because encryption is optional, or is it optional even if encryption is used?). Also Since there is no requirement to include thekid
in the client metadata JWKs AFAIK.I think it can be useful to make
kid
required to identify the encryption key used, but otherwise there might need to be some guidance on how to associate the encrypted response to the created request. For DC API it's easier (as the response is submitted by the frontend). For non-DC API requests I could see an unique response_uri per request working, however this conflicts with e.g. the requirements aroundx509_san_uri
(which it seems is about to be removed in #430) where theresponse_uri
must match auniformResourceIdentifier
in the x509 cert. It doesn't seem feasible to generate a new cert for every request.The text was updated successfully, but these errors were encountered: