Support negotiation of JWE content encryption (enc) algorithms for encrypted Authorization Requests

To enable Request Encryption, the verifier can advertise usage of the POST method to receive wallet metadata, in particular a wallet-provided encryption key, which will be specified by the wallet as a JSON Web Key in the keys array of the wallet_metadata.jwks parameter if it supports request encryption. The key encryption algorithm can thus be inferred from the alg field of the JSON Web Key, but I currently miss any negotiation/advertisement option to agree on a content encryption algorithm (enc value).

This differs from how response encryption is handled, where wallet_metadata allows negotiation of both key as well as content encryption algorithms via authorization_encryption_alg_values_supported and authorization_encryption_enc_values_supported. Without external ecosystem requirements or additional out-of-band exchange mechanisms, this leaves the verifier assuming a default enc algorithm.

If this is indeed a gap in the current spec that is not intended, I would propose adding an additional parameter analogous to request_object_encryption_enc_values_supported from the RFC 9101 Authorization Server metadata parameters to wallet_metadata.

Start by comparing the existing wallet_metadata response-encryption parameters with the request-encryption flow described in the issue, then review the RFC 9101 request_object_encryption_enc_values_supported parameter. Done means the specification clearly establishes whether wallet_metadata advertises request-object content-encryption algorithms and defines the corresponding parameter and negotiation behavior.