Clarify that authorization response encryption is not required for FAPI2 + Message signing / JARM

It might be a good idea to be explicit that auth response encryption is not required when using FAPI2 security profile + FAPI 2 Message signing.

This question came up in Australian discussions on transition to FAPI 2 and the default position was to use full JARM (signing and encryption).

FAPI 2 security profile (ex-Baseline, https://openid.net/specs/fapi-2_0-baseline-01.html) only requires authorization responses to be transmitted via encrypted network connections (which is taken care of by mandating TLS). No signing or encryption is required.

FAPI 2 Message signing profile (ex-Advanced, https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Advanced_Profile.md) only requires signing of the authorization response. No encryption is required (implied).

JARM (https://bitbucket.org/openid/fapi/src/master/Financial_API_JWT_Secured_Authorization_Response_Mode.md) being a generic specification allows for both signing and encryption. It doesn't take FAPI 2 assumptions into account (e.g. use of PKCE or sender constrained tokens). It says that: "Authorization servers MAY encrypt the authorization response therewith providing a means to prevent leakage of authorization codes in the user agent (e.g. during transmission, in browser history or via referrer headers)." In FAPI 2, only auth code plus iss are potentially exposed and it is protected by PKCE.

Conclusion: Authorization response encryption is not required for security reasons for ecosystems using FAPI 2 security profile (with auth code only flow, only auth code and iss in the response, PAR, PKCE, sender constrained tokens among other protections).

Comments (4)