FAPI 1.0 Final Phase 3 Obligation example for authorisation request using the Authorisation Code Flow does not have "response_mode" attribute

[AG-IAM]

Description

For FAPI 1.0 Final Phase 3 Obligations, the Non-Normative Example Utilising FAPI 1.0 Final, PAR RFC9126, PKCE, JARM and Authorization Code Flow does not have "response_mode" attribute in the decoded request. The "response_mode" attribute will be identified by Authorisation server to provide the corresponding authorisation response. Without this attribute, the code will be sent directly as a query parameter and not in a signed/encrypted JWT. Is this the expected behaviour? if yes, the documentation needs to be updated with the attribute "response_mode" as Optional and expected response for authorisation code Flow and authorisation code Flow with JARM.

Area Affected

https://consumerdatastandardsaustralia.github.io/standards/?examples#security-endpoints > Pushed Authorisation End Point > Decoded Request - FAPI 1.0 Final Phase 3 Obligation

Change Proposed

Update non-normative example for FAPI 1.0 Final Phase 3 Obligations to include "response_mode" in the Decoded Request or update the documentation with the expected response for authorisation code Flow and authorisation code Flow with JARM.

DSB Proposed Solution

The current DSB proposal for this issue is in #559 (comment)

[CDR-API-Stream]

Hi @AG-IAM, this looks like a documentation fix to include the response_mode. Aligning to the FAPI 1 Advanced profile, the response_mode is jwt.

[markverstege]

This change has been staged for review: ConsumerDataStandardsAustralia/standards-staging@release/1.24.0...maintenance/559

Note it is compared against the previous release. At present no draft 1.25.0 release has been staged but it is expected this change will target 1.25.0 for release at the end of maintenance iteration 15.

[biza-io]

Biza accepts this non-normative example update to reflect a valid request for a response_type=code authorisation in FAPI. The default response_mode for response_type=code is fragment as per Final: OAuth 2.0 Multiple Response Type Encoding Practices which makes the current example invalid for authorisation servers complying with FAPI 1.0 Advanced profile.

[markverstege]

Hi @biza-io, the staged non-normative example should address your feedback when JARM is used in combination with Authorization Code Flow. FAPI 1.0 Advanced states that response_mode of jwt be used which is reflected in the staged non-normative example.

[nils-work]

Staging link for 1.25.0 - ConsumerDataStandardsAustralia/standards-staging@release/1.25.0...maintenance/559

[nils-work]

Standards version 1.25.0 has now been published, incorporating this change.