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

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
+10 −1
Open

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

Changes from all commits
Commits
Show all changes
3 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
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
11 changes: 10 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,14 @@ 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.

Whenever the response is encrypted, the following additional processing directives apply to JWE. This enables binding response encryption to the Verifier's identifier and its respective transaction with the End-User:

- The `apu` (Agreement PartyUInfo) header parameter MUST be set to the value of the `nonce` from the Authorization Request.
- The `apv` (Agreement PartyVInfo) header parameter MUST be set to the value of the `client_id` of the Verifier.
awoie marked this conversation as resolved.
Show resolved Hide resolved
Comment on lines +1155 to +1156
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In ISO18013-7 the apv is the nonce instead of apu, does that make more or less sense?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

None of this makes much sense to me, to be honest. Per JWA - apu is information about the producer and apv is information about the recipient. ISO18013-7 has (or so I'm told) mdocGeneratedNonce for apu and nonce for apv which makes a certain amount of sense if you squint at it right. The wallet creates the mdocGeneratedNonce/apu so I guess it's information about the producer while the nonce/apv is generated by the verifier so I guess it's information about the recipient. If you squint at it a different way, it doesn't make any sense at all. I went with nonce as apu because it's about the the transaction or session the producer (Wallet) has with the Verifier and so seemed close enough to being about the producer and there are only two KDF contributing headers and client_id in apv made sense to me as information about the recipient because it's an identifier for the recipient.

That's a lot of words that probably don't make much sense either.

The upside though, as I said in #380 (comment), is that I don't think any of this is needed or useful.


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. However, regardless of algorithm used, the values are always part of the AEAD tag computation so will still be bound to the encrypted response.

Comment on lines +1153 to +1160
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Whenever the response is encrypted, the following additional processing directives apply to JWE. This enables binding response encryption to the Verifier's identifier and its respective transaction with the End-User:
- The `apu` (Agreement PartyUInfo) header parameter MUST be set to the value of the `nonce` from the Authorization Request.
- The `apv` (Agreement PartyVInfo) header parameter MUST be set to the value of the `client_id` of the Verifier.
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. However, regardless of algorithm used, the values are always part of the AEAD tag computation so will still be bound to the encrypted response.
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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That'd be okay by me FWIW

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 +2775,7 @@ The technology described in this specification was made available from contribut

-24

* Mandate the use of apu/apv in the JWE header of encrypted responses
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Mandate the use of apu/apv in the JWE header of encrypted responses
* add a note on the use of apu/apv in the JWE header of encrypted responses

also needs to be moved to -25

* 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
Loading