Add security considerations around retrieval of jwks (and possibly server usage as a whole)

[GarethCOliver]

Issues from PR #505, adding security considerations around the retrieval of jwks for encryption (particularly in the context of a wallet backend).

[jogu]

Discussed on today's WG call, Gareth to add a comment with some suggestions.

[GarethCOliver]

Retrieval of jwks is being addressed in PR #569.

If we want to include specific about split-architecture wallets that include a server component and security considerations it should address the following:

• A server component can provide benefits (such as reliability, security and privacy benefits), but it often has different risks associated with it due to the increased difficulty of audits (especially by external security experts), the ease of opaque updates and the increased insider risk.
• For a server architecture to be at all useful while preserving user privacy, a minimum trust model should be used where some information (such as knowledge of the user having credentials and the issuers of those credentials) has to be known by the server component, while unnecessary information remains opaque to it.
• Request/Response encryption from the device the server component can be used to provide confidentiality of user data from the server component to reduce the attack surface.
• If the server component is the source of trust (e.g. for Wallet Attestations or Key Attestations) then that can not be used to protect against the server component.
• If the server component has access to access codes, pre-auth codes or other bearer tokens then it can trivially impersonate the app and access the confidential information (and must be trusted not to do so), else not be allowed access to them. (today, there is no mechanism in openid4vci to allow this to go through the server without placing trust in it, so you'd have to use a hybrid model, though you could imagine one).

[jogu]

Seems reasonable to me - though I'm not sure what "access codes" in the final bullet is preferring to? I don't think the problem is limited to 'bearer tokens' either as in the case of sender-constrained tokens the server likely has access to (for example) the dpop proofs.

I think the language in the second and final bullets could be improved, maybe:

• For the server component to provide useful functional whilst preserving user privacy, a minimum trust model should be used where some information (such as knowledge of the user having credentials and the issuers of those credentials) has to be known by the server component, whilst unnecessary information (such as the claims in the credentials) remains opaque to it.

and:

• If the server component has access to access codes, pre-auth codes or other tokens/proofs then it can potentially trivially impersonate the app and access the confidential information. If the server component cannot be trusted in this way then these items must not be passed to/via the server component.

[GarethCOliver]

sorry 'authorization code', always get that one named wrong.

I like bullet one text.

For second I'd like to add some text 'around without additional security measures (maybe not described here?)'. Today, a dpop token can be used to impersonate the client with a different encrypted credential request because the credential request content is not bound to the dpop key. #507 would solve that particular issue, for instance (but would not solve anything of the ones, requiring hybrid solutions, trust, or other additional security measures). I think fully detailing this is outside the scope of what we've done here today (and if we want OpenId4VCI to work out of the box for server-to-server we do need to spend proper time considering this), but given this is a considerations section leaving the nuance between 'can't be solved' and 'we haven't solved'.

Otherwise SGTM.

[jogu]

I think I'm fine with your second suggestion. Although I think basically it's not possible in what we define in VCI 1.0 (whilst remaining interoperable / not using proprietary extensions).