Comments (8)
How is this any different to the existing CX Standard?
The following standards apply when a Data Holder invites a CDR consumer to amend a current authorisation as per rule 4.22A and the ADR has supplied a cdr_arrangement_id
This proposal just seems to rewrite what's already there in reverse. Coming from a Standards writing background, writing the same thing in two different ways, while fun, isn't a great idea, less is more.
from standards-maintenance.
Hi @perlboy,
Thanks for this feedback.
The existing authorisation amendment standard specifies what data holders must do when an ADR has supplied a cdr_arrangement_id. This is a mandatory requirement on data holders.
The newly proposed standard clarifies what data recipients must do to trigger the simplified amending authorisation flow. A data recipient is not required to implement this standard, but if they do not they will only be able to receive a new collection consent, and the consumer will be required to complete the full authorisation flow.
from standards-maintenance.
This addition is implied by the statement "and the ADR has supplied a cdr_arrangement_id". This proposal is essentially implementation guidance, not Standards.
The RFC style recommendations state "concise language is the goal". As such, I suggest actually the reverse, the removal of statements within the CX Standards related to cdr_arrangement_id
as this is overlapping with existing statements within the InfoSec profile and then compartmentalising the technical parameter away from the CX Standard.
To provide context, the Recipient supplying cdr_arrangement_id
is already mentioned in various ways in the following sections:
- In
Amending Authorisation Standards
- In
Data Holder Dashboards
- In
Specifying an existing arrangement
- In
Request Object Submission
All of these sections describe it in different ways, some of which relate to the Rules in question.
Given the CX Standards relate to the optimisation of the consent flow I instead suggest:
- Removing the existing statement "The following standards apply when a Data Holder invites a CDR consumer to amend a current authorisation as per rule 4.22A and the ADR has supplied a cdr_arrangement_id" replacing with "The following Standards apply when requesting to amend a current authorisation:"
- Update the statement within the infosec profile:
"Provided a Data Holder supports PAR, they MUST also support the cdr_arrangement_id claim provided in the Request Object sent to the [PAR End Point]https://consumerdatastandardsaustralia.github.io/standards/#pushed-authorisation-end-point). The Data Recipient Software Product MAY provide the cdr_arrangement_id claim in the Request Object sent to the PAR End Point."
to
"Provided a Data Holder supports PAR, they MUST also support the cdr_arrangement_id claim provided in the Request Object sent to the PAR End Point. The Data Recipient Software Product, if requesting to amend a current authorisation under Rule 4.22A, MUST provide the cdr_arrangement_id claim in the Request Object sent to the PAR End Point. A Data Holder MUST treat the request under the Amending Authorisation Standards If the cdr_arrangement_id claim is provided"
Finally, on a point of applicability, the proposal expands the references from 4.22A to include 4.18C and 4.20S. Both 4.18C and 4.20S relate to notification by a recipient to both Data Holder and another Data Recipient. They are also presented as past tense (i.e. after the collection consent is updated) and in fact referenced directly in 4.22A introducing a possibility that the Standard is in fact rewriting the Rules. As such making it applicable to the Amending Authorisation Standards appears to not only be technically impossible but invalid.
from standards-maintenance.
As an ADR, we had always intended on passing the arrangement id
from standards-maintenance.
The ACCC supports making a standard to clarify that an accredited data recipient must provide a CDR_arrangement_ID when making a notification to a data holder that a collection consent has been amended (as required by rule 4.18C or 4.20S). Supplying the cdr_arrangement_id ensures that data holders can link notifications about amended consents to the existing authorisation.
from standards-maintenance.
Based on the feedback provided and through internal discussions, we'd like to propose the following options for discussion:
Option 1: Standards Clarification (current proposal)
The intention of this proposal is to clarify what ADRs must do to initiate an authorisation amendment. The current proposal would not result in any new obligations for ADRs, and would not result in a change to standards relating to DHs. This option is considered to have low to no implementation impact. This proposal is as follows:
Consumer Experience → Consent Standards →
Consent: Amendment of Collection Consents and Authorisations (new row in first table)
Data recipients MUST supply the relevant
cdr_arrangement_id
to the data holder when seeking to have a current authorisation amended as per rules 4.18C, 4.20S, and 4.22A.Note: Providing the
cdr_arrangement_id
is necessary to trigger the data holder authorisation flow simplifications outlined in the Amending Authorisation Standards. A failure to supply thecdr_arrangement_id
will result in the full authorisation flow and a disconnected data sharing arrangement history on consumer dashboards.
Option 2: Adjusted ADR and DH standards
This option would result in a change to the existing ADR and DH standards. As per @perlboy's suggestion, this change would remove an existing statement from the amending authorisation standards for DHs; would insert revised wording to the infosec profile to clarify that an ADR must provide a cdr_arrangement_id
; and in the infosec profile would state that a DH must comply with the existing amending authorisation standards where they receive the relevant cdr_arrangement_id
. This option would not be progressing the existing proposal, though would result in changes to the existing infosec profile resulting to ADRs and DHs. While this would not create any new obligations for ADRs or DHs, changes to the infosec profile are expected to have low impacts to DHs, who will need to review the revised obligation wording and placement.
This proposal would appear as follows:
Consumer Experience → Amending Authorisation Standards →
Authorisation: Amending consent
The following Standards apply when requesting to amend a current authorisation:
...
and
Security Profile → Request Object →
Specifying an existing arrangement
Provided a Data Holder supports PAR, they MUST also support the
cdr_arrangement_id
claim provided in the Request Object sent to the PAR endpoint. The Data Recipient Software Product, if requesting to amend a current authorisation under rule 4.22A, MUST provide thecdr_arrangement_id
claim in the Request Object sent to the PAR endpoint. A Data Holder MUST treat the request under the Amending Authorisation Standards if thecdr_arrangement_id
claim is provided.
Option 3: Revision of Original Proposal
Similar to Option 1, Option 3 would limit changes to the ADR side to provide a clarification only, and would not result in a new ADR obligation or changes to standards impacting DHs. The rewording in this option would provide an alternative clarification relating to the notification of a DH of a collection consent being amended, as follows:
Consumer Experience → Consent Standards →
Consent: Amendment of Collection Consents and Authorisations (new row in first table)
When notifying a Data Holder of an amended collection consent as per rules 4.18C or 4.20S, Data Recipients MUST supply the relevant
cdr_arrangement_id
to the Data Holder according to Specifying an existing arrangement.
Providing thecdr_arrangement_id
is necessary to trigger the Data Holder authorisation flow simplifications outlined in the Amending Authorisation Standards. Failure to supply thecdr_arrangement_id
will result in the full authorisation flow and a disconnected data sharing arrangement history on consumer dashboards.
--update 29/05/2024---
Option 4: Combination of Option 2 and Option 3
This option combines approaches from both Option 2 and Option 3. This change would consolidate references to the cdr_arrangement_id
claim value to the request object under InfoSec profile and the proposed new CX Standard to refer to the request object. While this would not create any new obligations for ADRs or DHs, changes to the InfoSec profile are expected to have low impacts to DHs, who will need to review the revised obligation wording and placement.
Consumer Experience → Amending Authorisation Standards →
Authorisation: Amending consent
The following standards apply when a Data Holder invites a CDR consumer to amend a current authorisation as per rule 4.22A and in accordance with Specifying an existing arrangement
...
Consumer Experience → Consent Standards →
Consent: Amendment of Collection Consents and Authorisations (new row in first table)
When notifying a Data Holder of an amended collection consent as per rules 4.18C or 4.20S, Data Recipients MUST supply the relevant CDR Arrangement ID to the Data Holder according to Specifying an existing arrangement. Providing the CDR Arrangement ID is necessary to trigger the Data Holder authorisation flow simplifications outlined in the Amending Authorisation Standards. Failure to supply the CDR Arrangement ID will result in the full authorisation flow and a disconnected data sharing arrangement history on consumer dashboards.
...
and
Security Profile → Request Object →
Specifying an existing arrangement
To facilitate the amending of an existing arrangement, the following statements apply:
- Data Holders MUST support the
cdr_arrangement_id
claim provided in the Request Object.- The Data Recipient Software Product MUST provide the
cdr_arrangement_id
claim in the Request Object if requesting to amend a current authorisation in accordance with Consent: Amendment of Collection Consents and Authorisations.- Data Holders MUST treat the request under the Amending Authorisation Standards if the
cdr_arrangement_id
claim is provided.
Community feedback to these options and any other options that we should consider are welcome.
from standards-maintenance.
Based on community feedback, internal discussions and advice from other CDR agencies, the DSB would like to propose Option 4 as the preferred option. As outlined above, Option 4:
- effectively incorporates community feedbacks received on the issue thus far;
- avoids duplication with the proposed CX standard referring to the Technical standard instead of re-writing it in two places;
- tidies up the specifying existing arrangement requirement by removing redundant statements
- provides separation of Technical and CX requirement; and
- explicitly clarifies ADRs requirement when initiating authorisation amendment
from standards-maintenance.
The proposed change has been staged for review.
from standards-maintenance.
Related Issues (20)
- Update CDS documentation to clarify expected rate value 'sign' (+/-) for each RateType HOT 6
- Update guidance for Banking account rate detail HOT 2
- Update TLS cipher suite requirements to address DHEat Attacks and Raccoon Attack vulnerabilities HOT 3
- AmountString field type impractical for energy tariffs HOT 12
- Set a character limit for resource identifiers
- Clarify selection of Trusted Adviser in the CX Guidelines HOT 9
- Maintenance Iteration 20 Holistic Feedback HOT 7
- Adopt BCP 195 for TLS ciphers HOT 2
- Inconsistent JARM error responses HOT 2
- Weaken JARM Encryption Requirements for ADRs HOT 1
- Supporting HTTP Status 429 passthrough from Secondary Data Holder HOT 2
- Specify units of currency to be used for the AmountString field type HOT 5
- EnergyPlanTariffPeriod - cater for plans with no dailySupplyCharge HOT 5
- Clarify Transaction Security requirements
- Get Metrics V5 error metrics documentation HOT 1
- A status of POSTED should indicate the final update for a transaction
- Addition of LVR in the enumerated values list for constraintType HOT 1
- Guidance in the standards for a posting date/time where no time is stored HOT 9
- Enhancing CDR Adoption: Streamlining Account Selection and Improving Data Transparency HOT 5
- Revise the Availability Requirements NFRs
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from standards-maintenance.