Support Credential Request application-layer encryption

[GarethCOliver]

While not relevant when making a direct request form a Wallet to an Issuer endpoint, when going through Wallet Server between the Wallet and the Issuer, application-layer encryption provides a positive privacy benefit to the user.

In particular, for a credential format like mdoc, if the Wallet Server sees the device keys being sent to the issuer, they are able to collude with RPs to track all presentations of the issued credentials. If the credential request is instead encrypted, (and using single-use MSOs) this sort of tracking would only be possible through issue-RP collusion.

[jogu]

I'm not sure if we explicitly say it, but I think there is a current assumption in the spec that calls to the issuer endpoint are made from the wallet app.

I guess the first thing we need to agree on is why there may be a need for these calls to go through a wallet's backend?

[GarethCOliver]

Oh, sure. From prior conversation with others on the spec my understanding was that OpenID4VCI was intended to support both going through some wallet sever infrastructure as well as directly connecting to the issuer. Clearly, there are privacy implications to doing so, and that e2ee was the intended mechanism for closing some of these gap (and why it is available for credential response).

At its heart the reason for going through a wallet server infrastructure is reliability and usability at scale. Functionally, it should be assumed that any Wallet application can never be updated, as in practice users update slowly and inconsistently. Similarly any analytics/monitoring is slow and unreliable, making detection of issues challenging.

Wallet server infrastructure does not face these issues, and allows for working around client version skew issues that would simply be infeasible for issuers to deal with.

My assumption here is that the Wallet in question is distributed to millions or billions of devices, and is intending to contact 100s of different issuers. Similarly, Issuers would assume to interact with multiple wallets that they do not own, control or understand.

If you'd like, I can open a different issue to ask if using wallet server infrastructure is a valid way to use OpenId4VCI? For me to want to use this would be a hard requirement.

[jogu]

Thanks Gareth! I think that's probably fair - I'm not sure it's necessarily intended to support this architecture but it's certainly not prevented. We don't have any privacy considerations for that kind of architecture so potentially we might need to add them.

The credential response encryption unfortunately isn't great at the moment as currently the wallet backend could gain access to the encrypted data (unless there's extra checks in the issuer on the key used for encryption), but adding the kind of encryption you suggest in this issue might solve that some of that issue.

[peppelinux]

Using OpenID4VP we have considered useful the encryption of the presentation response. If we have recognized values in the presentation phase we should recognize the same values in the issuance too.

i don't have aprticular privacy concerns about the request, while I would put our attention about the consistency between the request and the response to preserve confidentiality. if the request is exncrypted, the response should be encrypted too.

with this further awareness and changes I would completely support this

[bc-pi]

As stated on the Mon Oct 28, 2024 OIDF DCP WG Hybrid Meeting at Microsoft, I am opposed to the complexity of more application layer encryption.

[GarethCOliver]

@bc-pi: My understanding of your objection was that you do not agree that a wallet server infrastructure is a valid architecture, and therefore the complexity is not warranted. As a prospective user of OpenID4VCI, with an existing issuance system, I disagree, hence the feature request.

In terms of complexity: I think its a smaller change than credential_response_encryption, but can follow a similar pattern:

add an optional credential_request_encryption parameter in the Credential Issuer Metadata, containing the jwk/alg/enc needed to perform the encryption.

Then, as with credential_response_encryption, require the content-type of credential request to be application/jwt, and require the client to encrypt the CredentialRequest as a jwt using the parameters in Credential Issuer Metadata.

This seems technically sound, relatively straight forward, and then it can be up to profiles/issuers/clients as to whether this is necessary.