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.
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
keysarray of thewallet_metadata.jwksparameter if it supports request encryption. The key encryption algorithm can thus be inferred from thealgfield of the JSON Web Key, but I currently miss any negotiation/advertisement option to agree on a content encryption algorithm (encvalue).This differs from how response encryption is handled, where
wallet_metadataallows negotiation of both key as well as content encryption algorithms viaauthorization_encryption_alg_values_supportedandauthorization_encryption_enc_values_supported. Without external ecosystem requirements or additional out-of-band exchange mechanisms, this leaves the verifier assuming a defaultencalgorithm.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_supportedfrom the RFC 9101 Authorization Server metadata parameters towallet_metadata.