Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requirement of kid in JARM response header? #441

Open
TimoGlastra opened this issue Mar 3, 2025 · 1 comment
Open

Requirement of kid in JARM response header? #441

TimoGlastra opened this issue Mar 3, 2025 · 1 comment

Comments

@TimoGlastra
Copy link
Member

TimoGlastra commented Mar 3, 2025

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.

@awoie
Copy link
Contributor

awoie commented Mar 3, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants