[Interoperability] Support for unencrypted direct_post authz response mode

[Zicchio]

Currently in this project, in the opanid4vp flow we provide support exclusively for direct_post.jwt encrypted authorization response (accordingly with italian specs).

It appears that, as of today, the only authorization response mode supported in Potential interoperability D2.2 is the (unecrnytped) direct_post mode.
It is not clear if or when this requirement will be relaxed to also include encrypted direct_post.jwt mode, hence if we want to comply with interoperability goals we might need to support direct_post mode and provide configurations in order to enable it.

I think that no immediate action is required, but I still want to highlighting this fact so that one day we are ready to develope this feature if its necessity actually emerges.

[peppelinux]

@Zicchio the solution for a proper interoperability is to always encryopt the response if the RP provide the public keys intended fro the encryption usage

the normative language in the italian specs should mandate the RP to have encryption JWKs in their metadata, while wallet units should try to encrypt if the rp allow them to do so

for our implementation we therefore newed to do encryption if the RP provide the public enc material suitable for this

[peppelinux]

for instance, in our implementation the RP configures its private keys (and intended usage) here:
https://github.com/italia/eudi-wallet-it-python/blob/dev/example/satosa/pyeudiw_backend.yaml#L136

[Zicchio]

So, if I understand correctly, we require that the authorization response MUST be encrypted IF AND ONLY IF the relying party has a configured (public) encryption key.

Looks good to me.