Weaken JARM Encryption Requirements for ADRs

[benkolera]

Description

Currently, encryption of JARM responses is optional for Data Holders but mandatory for ADRs, as ADRs are forced to support JARM encryption due to the following part of the CDS:

If the Data Holder supports authorisation response encryption and the authorization_encrypted_response_alg is
omitted from the registration request, the Data Holder MAY require response encryption by returning a client 
registration response with the chosen “authorization_encrypted_response_alg” value.

This requirement seems to be an historical compromise of the specification due to some prior ambiguity of the JARM registration and discovery document specifications and that some Data Holders had already implemented JARM with forced JWE prior to the clarifying standards changes.

Intention and Value of Change

I believe that this places an undue burden on the recipients supporting a complicated and not widely supported spec (JWE) for what might be an extreme edge case that may or may not be required in 2024. This places additional implementation and testing burdens on ADRs to support and validate these features. Features of which are not currently verified by the CTS.

Removing this ADR requirement would remove a barrier to entry for new ADRs and ongoing maintenance of implementations, so it feels important and valuable to question whether this compromise is still in the best interests of the ecosystem.

Area Affected

Infosec profile, which impacts DCR and Authorization Redirects in particular.

Change Proposed

Removing this abovementioned requirement and making JARM encryption truly optional for both ADRs and DH.

[CDR-API-Stream]

This issue was discussed in the Maintenance Iteration Call on 24 July. A participant offered to compile information on Data Holders who require encryption on JARM responses for discussion in a later meeting.

[CDR-API-Stream]

This issue was discussed in the MI 21 meeting.

In addition to the quoted component of the standards provided by @benkolera, the standards also state the following

JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) Data Holders MAY support Authorisation Response encryption. However, at present, there is no confidential information in the authorization response, hence encryption of the authorization response is not required for the purposes of security or confidentiality. In addition, whilst response encryption MAY be used, to achieve greater interoperability, it is not recommended to use encryption in this case at this time.

These statements were provided in alignment with the FAPI 2.0 Message Signing profile:

6.1. Authorization response encryption

In FAPI2, there is no confidential information in the authorization response, hence encryption of the authorization response is not required for the purposes of security or confidentiality. In addition, to achieve greater interoperability, it is not recommended to use encryption in this case.

Usage of PKCE in FAPI 2 provides protection for code leakage described in Section 5.4 of [JARM].

Currently the Data Standards do not require confidential information being passed in the JARM response which is aligned to the FAPI 2.0 Message Signing profile. #649 is considering changes to error responses which may disclosure additional information through error responses. The current proposals do not currently propose any confidential information is shared within error descriptions, however this is a factor for consideration.

In the MI 21 meeting, it was noted that very few Data Holders currently require authorization response encryption. Three options could be considered. The first is proposed by @benkolera in the original issue.

The second option is to constrain dynamic client registration such that Data Holders honour any ADR client registration requests which submit a a client update without requesting authorization response encryption.

The third is to constrain the Data Standards profile to not allow authorization response encryption.