Add encrypted credential response
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?
Comments (8)
-
-
Who would determine whether the response (not the credential!) is encrypted?
-
How do you want to handle batch issuance?
-
- changed status to open
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.
-
reporter 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.
-
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 DPoPI 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
-
-
- changed status to resolved
PR merged.
- Log in to comment
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?