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

Change Request to make 'scope' optional in the token end-point response in FAPI #406

Closed da-banking closed 2 years ago

da-banking commented 3 years ago

Description

Our concern is regarding the CTS testing 3.3, the 'scope' from the token end-point response is listed as mandatory in FAPI draft 6. However, we see that it's optional in FAPI v1.0. Having to change the code and later down the track change it again to what it was originally seems superfluous. Please be aware that this issue impacts ALL 15 of our clients, as our solution fails on the last step of CTS 3.3 Scenario 13. Based on the significant impact this would have, please advise if Data61 can treat the 'scope' from the token end-point response as optional?

Area Affected

The 'scope' from the token end-point response in FAPI

Change Proposed

We propose making the 'scope' from the token end-point response optional in FAPI draft 6.

RalphBragg commented 3 years ago

The FAPI Final Specification allows you to continue to include this attribute if you want to. It's optional, meaning that if your OpenID Provider wants to include this attribute it can even if the value hasn't changed.

I'm unsure what you're querying.

perlboy commented 3 years ago

@RalphBragg @da-banking is proposing to remove the requirement from the existing spec, essentially front-running a FAPI 1.0 vs. ID2 difference.

@da-banking All other participants have been required to comply with the specification as it exists right now. Whether the CTS tests was testing it or not is fairly irrelevant - it should have been verified away from the CTS. Coming in at the eleventh hour, 3 months after the original compliance date and requesting a change, after it was announced that FAPI 1.0 was the pathway, seems more like a realisation your implementation was never compliant to begin with, that active ecosystem participants are non-compliant and now the ecosystem is expected to bend to an individual organisations will because "ALL 15" of their clients are impacted.

If the DSB chooses to agree to this change it sets a dangerous precedent that any organisation can suggest that "what we are asking for is coming anyway" and use this as justification why they don't need to comply to the specification as stated now.

On this basis alone I oppose this change.

RalphBragg commented 3 years ago

@perlboy - And so the problems start, this is the problem with trying to remain on specifications that aren’t final when there are newer versions published. This is increasingly going to cause everyone in the ecosystem challenges as vendors, libraries and developers start using fapi specifications not implementers drafts as their reference.

Saying this, i agree with you, if the request is to start pulling bits of specs back into ID2 Draft 6 then this isn’t a good idea. DRs have been told that the scope will always be in the token response and so to stop including it would be a breaking change one which needs to be planned, communicated as part of a security profile uplift.

Deprecation and breaking change need to be communicated and managed.

CDR-API-Stream commented 3 years ago

This issue was discussed in the 9th maintenance iteration call. The preference is not to backport FAPI 1.0 text into the current CDS InfoSec profile. The proposed change will be accommodated in the migration to FAPI 1.0 consulted under Decision Proposal 209. In the meantime, Data Holders must continue to comply with the current CDS InfoSec profile which refers to FAPI ID2 (Draft 06).

CDR-API-Stream commented 2 years ago

DP209 changes were incorporated into release v1.15.0. Refer to Decision 209 for further details.