RSA-OAEP is the hardcoded default JWE alg and is allowed in the sample RP config, but the IT-Wallet specs list it as MUST NOT be supported

Hi! Apologies if this is not the right audience or issue to raise, I am approaching the topic as a newcomer.

**Summary**

RSA-OAEP (RSAES-OAEP with default parameters, RFC 7518 §4.3) is accepted for authorization response encryption by the sample Relying Party configuration shipped with this repository, is documented as the default in the backend and frontend docs, and is the algorithm used by the integration test harness. The Italian eID Wallet Technical Specifications list RSA-OAEP in the "MUST NOT be supported" table.

This is strictly about RSA-OAEP. The distinct JOSE identifier RSA-OAEP-256 (RSAES-OAEP using SHA-256 and MGF1 with SHA-256) is listed under "MUST be supported" and is not affected.

**Specification reference**

italia/eid-wallet-it-docs, release 1.4.6 (latest LTS, 2026-08-06), docs/en/algorithms.rst — identical on branch versione-corrente, on tag 1.4.6, and on branch eudiw:

L128 — "The following algorithms MUST NOT be supported:"
L147-L150 — RSA-OAEP | "RSA Encryption Scheme with Optimal Asymmetric Encryption Padding (OAEP) using default parameters." | Operations: Key Encryption | refs: RFC 7518, [SOG-IS]
For contrast, L43-L46 lists RSA-OAEP-256 under "The following algorithms MUST be supported:", also with operation Key Encryption.

**Where it occurs**

Commit 3679f381a39f22b775c6d966dd05e842e34a4b35 (main).

**1. The sample Relying Party configuration accepts it at runtime**

integration_test/conf/pyeudiw_backend.yaml, L45 and L49:

default_enc_alg: RSA-OAEP
enc_alg_supported:
- RSA-OAEP
- RSA-OAEP-256
- ECDH-ES
...
That list is the accept-list applied to incoming authorization responses in pyeudiw/satosa/backends/openid4vp/authorization_response.py, L148-L150:

if not header.get("alg") in self.enc_alg_supported:
raise AuthRespValidationException(
"invalid data in direct_post.jwt: alg not supported"
)
A deployment started from this sample therefore accepts an authorization response encrypted with RSA-OAEP. The same values appear as documented defaults in docs/OPENID4VP-SATOSA-BACKEND.md L78 and L81, and in docs/OPENID4VCI-SATOSA-FRONTEND.md L82 and L85.

**2. The integration test harness encrypts with it**

integration_test/initializer/commons.py, L228-L231, where the harness plays the Wallet role and encrypts the authorization response towards the RP:

encrypted_response = JWEHelper(
# RSA (EC is not fully supported to date)
JWK(encryption_key).as_dict()
).encrypt(response)
The resulting alg comes from pyeudiw/jwt/jws_helper.py L37:

DEFAULT_ENC_ALG_MAP = {"RSA": "RSA-OAEP", "EC": "ECDH-ES+A256KW"}
used at pyeudiw/jwt/jwe_helper.py L62. The integration suite therefore exercises the encrypted response flow with an algorithm the profile lists as MUST NOT be supported, which is also why the discrepancy is not caught by the tests.

**Questions**

Should RSA-OAEP be removed from enc_alg_supported in the shipped sample configuration and from the documented defaults, leaving RSA-OAEP-256?
Should the integration harness encrypt with RSA-OAEP-256, so the suite exercises a profile-conformant algorithm?
Do the algorithm tables bind the Relying Party as well as the Wallet Instance? The section states it lists "algorithms used in the IT Wallet ecosystem" but does not name the entities each table applies to. This decides whether the above is a conformance defect or a hardening suggestion.
Is RSA-OAEP retained deliberately for interoperability with already deployed wallets? If so, would documenting that rationale — rather than shipping it as an accepted default — be acceptable?
Thanks!

Start by checking the referenced IT-Wallet algorithm tables and whether they apply to the Relying Party, then inspect integration_test/conf/pyeudiw_backend.yaml, the two backend/frontend docs, pyeudiw/jwt/jws_helper.py, pyeudiw/jwt/jwe_helper.py, and integration_test/initializer/commons.py. Run the relevant integration authorization-response tests. Done means the specification decision is recorded and the shipped defaults, accepted algorithms, documentation, and harness behavior are consistently aligned.

Written by the indexing model from the issue text.