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

clarify when authorization_signed_response_alg is omitted, do not sign #410

Merged
merged 2 commits into from
Feb 6, 2025
Merged

clarify when authorization_signed_response_alg is omitted, do not sign #410

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
23c58d5
clarify the behavior is not to sign when authorization_signed_respons…
bc-pi Jan 31, 2025
02e705c
per Sakurann - make it one sentence so more clear the adjustment is
bc-pi Feb 4, 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
8 changes: 6 additions & 2 deletions openid-4-verifiable-presentations-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -295,7 +295,7 @@ Exactly one of the following parameters MUST be present in the Authorization Req

* `jwks`: OPTIONAL. A JWKS as defined in [@!RFC7591]. It MAY contain one or more public keys, such as those used by the Wallet as an input to a key agreement that may be used for encryption of the Authorization Response (see (#jarm)), or where the Wallet will require the public key of the Verifier to generate the Verifiable Presentation. This allows the Verifier to pass ephemeral keys specific to this Authorization Request. Public keys included in this parameter MUST NOT be used to verify the signature of signed Authorization Requests.
* `vp_formats`: REQUIRED when not available to the Wallet via another mechanism. As defined in (#client_metadata_parameters).
* `authorization_signed_response_alg`: OPTIONAL. As defined in [@!JARM].
* `authorization_signed_response_alg`: OPTIONAL. As defined in [@!JARM], with an adjustment to the default behavior when this parameter is absent. Instead of defaulting to `RS256`, the Authorization Response is not signed.
bc-pi marked this conversation as resolved.
Show resolved Hide resolved
* `authorization_encrypted_response_alg`: OPTIONAL. As defined in [@!JARM].
* `authorization_encrypted_response_enc`: OPTIONAL. As defined in [@!JARM].

Expand Down Expand Up @@ -1146,7 +1146,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 Down Expand Up @@ -2791,6 +2791,10 @@ The technology described in this specification was made available from contribut

[[ To be removed from the final specification ]]

-25

* clarify the behavior is not to sign when authorization_signed_response_alg is omitted

-24

* add mdoc specific `intent_to_retain` mechanism, using the definition from 18013-5
Expand Down