Add encryption details parameter

openid-4-verifiable-presentations-1_0.md

@@ -287,6 +287,7 @@ In the context of an authorization request according to [@RFC6749], parameters c
     * `jwks`: OPTIONAL. A JSON Web Key Set, as defined in [@!RFC7591], that contains 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 (#response_encryption)), or where the Wallet will require the public key of the Verifier to generate a 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. Each JWK in the set MUST have a `kid` (Key ID) parameter that uniquely identifies the key within the context of the request.
     * `encrypted_response_enc_values_supported`: OPTIONAL. Non-empty array of strings, where each string is a JWE [@!RFC7516] `enc` algorithm that can be used as the content encryption algorithm for encrypting the Response. When a `response_mode` requiring encryption of the Response (such as `dc_api.jwt` or `direct_post.jwt`) is specified, this MUST be present for anything other than the default single value of `A128GCM`. Otherwise, this SHOULD be absent.
     * `vp_formats_supported`: REQUIRED when not available to the Wallet via another mechanism. As defined in (#client_metadata_parameters).
+    * `encryption_details_supported`: OPTIONAL. A non-empty array of strings, where each string references a profile of encryption details that the Verifier supports. The meaning and expected behavior of the Verifier and Wallet is profile-specific and out of scope of this specification. When the Verifier includes this parameter in a request, the Wallet MUST either reject the request or include one of the referenced profiles in the response and implement all of the requirements defined by the referenced profile (see (#response_encryption) for details of how to include it in the JWE in the response). When the Verifier includes this parameter in a request, the Verifier MUST verify that one of the referenced profiles is included in the response and MUST implement all of the requirements required by the profile included in the response.
 
     Authoritative data the Wallet is able to obtain about the Client from other sources, for example those from an OpenID Federation Entity Statement, take precedence over the values passed in `client_metadata`.
 
@@ -1301,6 +1302,8 @@ The JWE `alg` algorithm used MUST be equal to the `alg` value of the chosen `jwk
 If the selected public key contains a `kid` parameter, the JWE MUST include the same value in the `kid` JWE Header Parameter (as defined in [@!RFC7516, Section 4.1.6]) of the encrypted response. This enables the Verifier to easily identify the specific public key that was used to encrypt the response.
 The JWE `enc` content encryption algorithm used is obtained from the `encrypted_response_enc_values_supported` parameter of client metadata, such as the `client_metadata` request parameter, allowing for the default value of `A128GCM` when not explicitly set.
 
+When the `encryption_details_supported` parameter is present in the `client_metadata` parameter of the request (see #new_parameters) and requires the Wallet to include a referenced profile in the response, the selected profile SHOULD be included in the JWE protected header using the `encryption_details` header. When present, the `encryption_details` header MUST contain a string of the selected profile.
+
 The payload of the encrypted JWT response MUST include the contents of the response as defined in (#response-parameters) as top-level JSON members.
 
 The following shows a non-normative example of the content of a request that is asking for an encrypted response while providing