Add encrypted credential response

[Oliver Terbu]

OpenID allows UserInfo to be signed and/or encrypted.

IMO, the credential endpoint deserves the same functionality. I know that TLS will be ok in 90% of all cases but there are state-level issuers that have such requirements. To satisfy those requirements, it would make sense to add app-level encryption.

I suggest using JWE to optionally encrypt the credential response to the client (wallet) if the Client Metadata contains an encryption key. But that might be not good enough.

We could define the following:

If the Credential Response or Batch Credential Response is encrypted, then the Credential Response is returned in a JWT and the content-type MUST be application/jwt. The response MAY be encrypted without also being signed.

The only thing that we would need to decide is when to encrypt the Credential Response. For example if we would need to advertise this in the Client Metadata as a new parameter. How is this done in OpenID Connect Core?

[David Luna]

Could the issuer indicate in its credentials_supported issuer metadata block the set of credentials that if included in a credential response indicate it must be encrypted?

[Torsten Lodderstedt]

Who would determine whether the response (not the credential!) is encrypted?

[Torsten Lodderstedt]

How do you want to handle batch issuance?

[Kristina Yasuda]

SIOP May 25th call. Brian suggested using metadata is not a good approach because in VCI, there is a clearer separation between RS and AS. Giuseppe share experience from Italy's implementation. Oliver talked about using ephemeral keys. Taka suggested introspection endpoint so that RS can obtain the keys.

[Oliver Terbu]

It seems that most people are in favor of using an additional parameter in the credential request which is the JWKS/JWK of the encryption key of the wallet.

People are not in favor of using the client_metadata because the AS can be decoupled from the Issuer and in that case the credential endpoint wouldn’t have access to the client_metadata.

It was also mentioned that we could leverage the OAuth introspect endpoint after we associated the JWK with the access_token but that seems to have too many steps for what we actually want to achieve and it would not easily support ephmeral encryption keys.

[Giuseppe De Marco]

In Italy the encryption of the userinfo response made the payload be accessible only by its audience (RP), using a NEsted JWT.
Even if the access token might be stolen the adversary is then able to get the response but not to decrypt it.
We assume that the OpenID access token is not protected by DPoP

I see a useful use case in this issue, where a Wallet Instance can be intermediated by a Wallet Cloud backend in the request of a credential and then this latter wouldn’t be able to decrypt the response but just give this to the wallet instance. I assume that the Wallet Instance Attestation, with the public key of the instance, is submitted to the credential issuer and this latter uses the instance’s public key to encrypt the response

[Kristina Yasuda]

PR #557

[Kristina Yasuda]

PR merged.