Clarify keys in encrypted credential response

[awoie]

The current spec does not say anything about which keys the issuer uses for encrypting the response. It probably makes sense, that the keys in the credential request are treated as ephemeral keys while the issuer exposes static keys in their metadata.

IMO, it would make sense to say that if the credential response encryption is supported, the algorithms SHOULD be limited to hybrid encryption schemes such as ECDH-ES and the issuer MUST expose their public encryption key in the jwks metadata parameter.

We might also want to add a security consideration that issuers can implement measures to get more trust in the key provided by the wallet sent in the request. For instance, a profile like HAIP might want to say that the public encryption key of the wallet in the credential request must be listed in the wallet attestation sent via the client attestation in the credential request.

[jogu]

the issuer MUST expose their public encryption key in the jwks metadata parameter.

I don't understand how this is related to response encryption. Did you mean "the wallet MUST expose ..."?

For instance, a profile like HAIP might want to say that the public encryption key of the wallet in the credential request must be listed in the wallet attestation sent via the client attestation in the credential request.

We need to be very careful about this for privacy reasons, and I think currently there's no plan to pass a wallet attestation in the credential endpoint request?

[awoie]

the issuer MUST expose their public encryption key in the jwks metadata parameter.

I don't understand how this is related to response encryption. Did you mean "the wallet MUST expose ..."?

I guess what I was trying to say is that to make encryption meaningful we would need the following two things:

1. wallet has to get confidence that the response was encrypted by the issuer -> by using jwks metadata of the issuer to derive a shared secret.
2. issuer has to get confidence that they encrypt to the intended audience -> wallet attestation (see my comment below).

For instance, a profile like HAIP might want to say that the public encryption key of the wallet in the credential request must be listed in the wallet attestation sent via the client attestation in the credential request.

We need to be very careful about this for privacy reasons, and I think currently there's no plan to pass a wallet attestation in the credential endpoint request?

Re 2.
Sorry, I meant the token request. I know that this is probably not a good example but ISO 23220-3 currently follows this approach where the issuer remembers the keys from the wallet attestation and matches them against the keys in the PoP of the credential request.

In the context of encryption, this could help the issuer to understand whether the wallet key is from a trusted wallet and whether the response is encrypted to the intended recipient. Encryption and signing keys should be obviously not mixed.

It is possible to combine 1 and 2. Does this make sense?

[awoie]

the issuer MUST expose their public encryption key in the jwks metadata parameter.

I don't understand how this is related to response encryption. Did you mean "the wallet MUST expose ..."?

I guess what I was trying to say is that to make encryption meaningful we would need the following two things:

1. wallet has to get confidence that the response was encrypted by the issuer -> by using jwks metadata of the issuer to derive a shared secret.
2. issuer has to get confidence that they encrypt to the intended audience -> wallet attestation (see my comment below).

For instance, a profile like HAIP might want to say that the public encryption key of the wallet in the credential request must be listed in the wallet attestation sent via the client attestation in the credential request.

We need to be very careful about this for privacy reasons, and I think currently there's no plan to pass a wallet attestation in the credential endpoint request?

Re 2. Sorry, I meant the token request. I know that this is probably not a good example but ISO 23220-3 currently follows this approach where the issuer remembers the keys from the wallet attestation and matches them against the keys in the PoP of the credential request.

In the context of encryption, this could help the issuer to understand whether the wallet key is from a trusted wallet and whether the response is encrypted to the intended recipient. Encryption and signing keys should be obviously not mixed.

It is possible to combine 1 and 2. Does this make sense?

I guess 1. is already achieved by relying on TLS, so there is probably no need for jwks and ephemeral issuer keys are fine.

[Sakurann]

reads like the issue author agrees there is no action here? closing in a week unless objections.

[Sakurann]

we might come back and add security considerations. closing for now