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.

Sign up for GitHub

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

discuss the use of apu/apv in the JWE header of OpenID4VP encrypted responses #380

Merged
merged 6 commits into from
Feb 11, 2025
Merged

discuss the use of apu/apv in the JWE header of OpenID4VP encrypted responses #380

Changes from 4 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
cbaaa45
Mandate the use of apu/apv in the JWE header of encrypted responses
bc-pi Jan 10, 2025
e3a3bd3
per @Sakurann's suggestion to split into multiple sentences
bc-pi Jan 14, 2025
747a17f
Merge branch 'main' into apu-apv-jarm-and-aead-jwe
bc-pi Jan 16, 2025
fc1626a
Apply suggestions from code review
Sakurann Feb 6, 2025
afd9ff7
Merge branch 'main' into apu-apv-jarm-and-aead-jwe
Sakurann Feb 6, 2025
025f15b
fix version to -25
c2bo Feb 6, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion openid-4-verifiable-presentations-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1141,7 +1141,7 @@ This section defines how an Authorization Response containing a VP Token can be

To sign, encrypt, or both sign and encrypt the Authorization Response, implementations MUST use the JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) [@!JARM], and when only encrypting, the JARM extension described below.

This specification also defines how to encrypt an unsigned Authorization Response by extending the mechanisms defined in [@!JARM]. The JSON containing the Authorization Response parameters can be encrypted as the payload of the JWE.
This specification also defines how to encrypt an unsigned Authorization Response by adapting the mechanisms defined in [@!JARM]. The JSON containing the Authorization Response parameters can be encrypted as the payload of the JWE.

The advantage of an encrypted but not signed Authorization Response is that it prevents the signing key from being used as a correlation factor. It can also be a challenge to establish trust in the signing key to ensure authenticity. For security considerations with encrypted but unsigned responses, see (#encrypting_unsigned_response).

Expand All @@ -1150,6 +1150,8 @@ If the JWT is only a JWE, the following processing rules MUST be followed:
- `iss`, `exp` and `aud` MUST be omitted in the JWT Claims Set of the JWE, and the processing rules as per [@!JARM] Section 2.4 related to these claims do not apply.
- The processing rules as per [@!JARM] Section 2.4 related to JWS processing MUST be ignored.

Note that for the ECDH JWE algorithms (from section 4.6 of [@!RFC7518]), the `apu` and `apv` values are inputs
into the key derivation process that is used to derive the content encryption key. Regardless of algorithm used, the values are always part of the AEAD tag computation so will still be bound to the encrypted response.
The following is a non-normative example of the payload of a JWT used in an Authorization Response that is encrypted and not signed:

<{{examples/response/jarm_jwt_enc_only_vc_json_body.json}}
Expand Down Expand Up @@ -2767,6 +2769,7 @@ The technology described in this specification was made available from contribut

-24

* add a note on the use of apu/apv in the JWE header of encrypted responses
* require `typ` value in request object to be `oauth-authz-req+jwt`
* add `SessionTranscript` requirements
* use claims path pointer for mdoc based credentials
Expand Down