Add support for request encryption to credential endpoint and request/response encryption to deferred credential endpoint

[GarethCOliver]

Resolves #339
Resolves #286
Resolves #506
resolves #480
Resolves adding support for zip to support #480

The adds in a new credential issuer metadata parameter to support Credential Request encryption. Additionally it updates Deferred Credential Endpoint to support encryption in the same manner as Credential Endpoint.

Merging this with the existing credential response encryption was considered, but given we allow all permutations of mandatory/optional/not supported for both request and response independently, there isn't a great way to do this.

If we required issuers to be consistent on support or not then these would be cleaner as single parameter (but perhaps something we should leave to HAIP).

To be consistent with HAIP, alg is now required in the jwk, a common section on how to perform selection is included and kid must be included if available.

The removal of alg is a breaking change but IMO is worth while to be consistent across the specs.

[babisRoutis]

The PR indeed, adds the credential_response_encryption to the deferred request, which is great.

I have some questions. Assume the following:

• An issuer that doesn't strictly require encryption (encryption_required is set to false)
• A wallet that sends a credential request that includes credential_response_encryption
• The issuer replies with a transaction_id

In the above scenario, wallet has to place a deferred request.

a) Should this differed request include also credential_response_encryption, because the initial request included one, or it can be omitted.
b) If the answer to the above question is yes, then can the wallet send a new encryption key or does it have to use the key used in the initial request.

I am trying to understand, whether
The wallet must "store" the encryption key when it receives a differed issuance response and similarly,
Whether issuer has to "remember" the wallet's encryption key, in case of differed issuance

[GarethCOliver]

a) Yes, it must, will update to add text to that effect.
b) Yes, the wallet may send a new key (though they may send the same key if they wanted to, for some reason). The issuer must encrypt to the newly provided key. This is intentionally to allow the wallet to avoid requiring the issuer and the wallet to have to do key management over what is potentially a long interval.

Architecturally, the only downside to this approach is that the issuer would need to store the pending credential somewhere securely (whereas if the key is managed, they could encrypt it and store it anywhere). IMO avoiding key management is more important.

I'll update the text a bit.

[jogu]

I think we should have some security & privacy considerations added too, albeit I don't mind if we open an issue to do that in another PR so long as it gets into 1.0 - the effectiveness of this mechanism seems to be highly dependent on the wallet frontend fetching the issuer metadata directly rather than through the backend.

I think it would also be worthwhile to actually state the intended advantages of the encryption mechanism in the specification itself.

[GarethCOliver]

I think we should have some security & privacy considerations added too, albeit I don't mind if we open an issue to do that in another PR so long as it gets into 1.0 - the effectiveness of this mechanism seems to be highly dependent on the wallet frontend fetching the issuer metadata directly rather than through the backend.

I think it would also be worthwhile to actually state the intended advantages of the encryption mechanism in the specification itself.

Makes sense. Probably two sections: One for what encryption can protect against and what it doesn't (particular in regard to TLS already existing). The second is the one christian is starting for wallet backend considerations. The problem you are describing is definitely true for retrieving the keys (you have to have some way, on the device, to trust them (the most obvious of which is fetching them directly). I think you would have the same issue with any other client metadata you are trusting (i.e. if it isn't fetched directly you can't trust it, e.g. if I pulled the endpoint from a wallet backend, even if I directly connected to it, it'd be a problem).

Filed two issues on these.

[Sakurann]

WG discussion:

• Gareth to pull the main, folks to re-review after that.
• nothing technically blocking the PR

[jogu]

Couple of suggestions, and a couple of comments where I couldn't come up with suggestions (sorry!).

[jogu]

Discussed on WG today: consensus to merge this once a small non-normative sentence is added to address Christian's comment re: compression.

[paulbastian]

retracting request changes (as GH doesn't allow that)

As per Paul's comment here: #505