Integrity of the JWK used for Credential Response encryption

[GarethCOliver]

Currently, there is nothing that ensures the integrity of the JWK used for Credential Response encryption. When not using credential request encryption, a party in the middle that can mutate the request can easily replace the jwk without the Client or the Issuer being aware. Credential Request encryption helps, but in principle encryption should not be used for integrity.

Conceptually, there are two solutions here:

1. provide a proof over the key (a key_attestation or other proof mechanism as used for other credential keys could work.)

2. provide an optional signature over the request using an already known key (dpop key would be an example)

[tplooker]

I think option 2 is a bit more generalised here given the JWK used for response encryption isn't the only aspect of the request that benefits from integrity guarantees. In effect it would mean adding support for signed credential requests, which depending on the shape that #505 takes it could be relatively easy to achieve as we could leverage JWT's to provided either (or both) signed and encrypted requests. .

[tplooker]

Beyond the credential response encryption key the public key supplied to issue the credential could also be substituted if one were using the JWT proof type and hence would benefit from being able to be integrity protected in the credential request in certain situations.

[Sakurann]

WG discussion:

• in most cases, TLS is what guarantees integrity of the JWK used for Credential Response encryption
• option 1: address this in 1.1. but if we do that we want to remove all credential request & response encryptions in 1.0
• option 2: fix it in 1.0. (seems to be preferred also because this is an ISO requirement)
  • in VCI, define how to sign the credential request and in HAIP mandate it to be DPoP key (does DPoP key being HW bound matter? key integrity and strength of encryption are related)
  • bind DPoP or wallet attestation to the encryption key attestation here
• another option might be mandating encrypting credential request when credential response encryption.

[jogu]

I think my worry about the "wallet attestation" and "dpop" type ideas is that we're just moving the trust around, without being clear what we do and don't trust in the first place.

So for example if we say "a wallet attestation is sufficient for the encryption key", I believe that we're saying (based on wallet attestation as per https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#appendix-E ) is that we trust the wallet backend to provide a correct attestation for the key, but we don't trust it to not alter the request from the wallet.

Or put another way, the wallet backend would be free to generate whatever attestation it wanted for the key it wants to be used for the encryption, and hence it could still man-in-the-middle the request without the wallet frontend being aware of it.

Or put yet another way, this only adds value when the attester is an entity other than the wallet backend?

[c2bo]

We had a bit more discussion on this after the call and I think the cleanest solution would be to include the encryption key in the proof types (jwt proof / key attestation). That is probably the best point to make sure decryption happens at the point you want it to: the same point where you generate PoPs for the credential request.

--> We could add an optional parameter to all proof types to carry the encryption key. If you have more than one (jwt proof), then only one (the first) carries the encryption key.

[GarethCOliver]

We had a bit more discussion on this after the call and I think the cleanest solution would be to include the encryption key in the proof types (jwt proof / key attestation). That is probably the best point to make sure decryption happens at the point you want it to: the same point where you generate PoPs for the credential request.

--> We could add an optional parameter to all proof types to carry the encryption key. If you have more than one (jwt proof), then only one (the first) carries the encryption key.

I think this is reasonable, though if we are going to have specialized rules around 'only include it in the first one', I'd rather it was a stand alone field to make processing more obvious. But that is mostly bike-shedding.

[Sakurann]

WG discussion:

• seems to be agreement with this approach: adding an optional parameter to all proof types to carry the encryption key. If you have more than one (jwt proof), then only one (the first) carries the encryption key.
• requires good security considerations? and be very clear on limitations.
  • using key attestation does not guarantee that the key was provided by the front end and was not changed by the backend.
  • encryption terminates where the key is created. if backend is not trusted for the encryption key but not for the rest.