search

ConsumerDataStandardsAustralia / standards-maintenance

This repository houses the interactions, consultations and work management to support the maintenance of baselined components of the Consumer Data Right API Standards and Information Security profile.
41 stars 9 forks source link

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

Closed AG-IAM closed 1 year ago

AG-IAM commented 1 year ago

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 image

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 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/559#issuecomment-1491214909

CDR-API-Stream commented 1 year ago

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 commented 1 year ago

This change has been staged for review: https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Staging link for 1.25.0 - https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/release/1.25.0...maintenance/559

nils-work commented 1 year ago

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