Normative Standards Review (2021)

[CDR-API-Stream]

This issue has been created to consult on the normative standards review outlined in the DSB Future Plan. The purpose of this review process is to review and uplift the CDS where changes in upstream standards are identified. The CDS relies upon a number of external standards, and over time these standards can be revised and newer versions issued. To remain current, this review process seeks to consider the impact of any changes and the approach to align the CDS as required.

A high level overview of the standards under review can be found here:
https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/tree/master/reviews/2021-05

This issue is not a Decision Proposal. Rather it provides a mechanism for feedback to this initial analysis. Targeted Decision Proposals will be created after reviewing feedback of implementation impacts. There is currently no closing date currently planned for this analysis.

[CDR-API-Stream]

FAPI Part 1 Analysis has been published. The DSB has not made any recommendations regarding transition phasing or adoption of each change. The DSB welcomes feedback from the community regarding these aspects and any other changes the community identify.

[CDR-API-Stream]

FAPI Part 2 Analysis has been published. The DSB has not made any recommendations regarding transition phasing or adoption of each change. The DSB welcomes feedback from the community regarding these aspects and any other changes the community identify.

[CDR-API-Stream]

Please also note the OIDF has conducted an analysis of FAPI ID2 (essentially what the CDS refers to as Draft 06) to FAPI 1.0.

[CDR-API-Stream]

Requirements Levels analysis has been published. Due to the simplicity of the overall change, the DSB has made recommendations regarding adoption of the change.s The DSB welcomes feedback from the community regarding these recommendations and any other changes the community identify. Further analysis of the changes to the CDS will be provided in due course.

[CDR-API-Stream]

Please note the issue description has been updated. This issue has been raised as a way to track review progress across all normative standards. It is not a Decision Proposal but instead presents the initial analysis. It is expected that targeted Decision Proposals will be created once feedback from the community on impacts to implementation are discussed.

[CDR-API-Stream]

Pushed Authorization Requests (PAR) analysis has been published for review and feedback. This analysis compares Draft 02 to Draft 09.

[spikejump]

In the FAPI Part 2 Analysis above, we note the below:

5.2.3. (9): NEW No change unless using PAR, in which case the additional claims outside the request object aren't required. For backwards compatibility, it doesn't hurt if the client continues to send these to the authorisation endpoint.

It might be worthwhile to call out that when the standard is adopted by the CDS ecosystem and when PAR is being used, the Data Holder's Authorisation Server must not throw an error when ADRs do not send the additional claims (response_type and scope). This is because there's discrepancy in existing Data Holders implementation where some throws an error and some don't.

[da-banking]

Thanks @CDR-API-Stream
The oauth standard and FAPI 1.0 both have the scope response optional unless the requested scopes is different from the granted scopes, while FAPI Draft 6 has it as mandatory – so to be fully compliant with FAPI draft 6, a change away from default oauth behaviour needs to be made that would not be required with FAPI 1.0. I.e. when the scope response field is present, it’s implied that it’s because there’s a discrepancy between the requested scopes and the granted scopes that the client may need to handle. So while it’s technically valid to always return the scopes, it’s not exactly in the spirit of how that field was specified.