Giter VIP home page Giter VIP logo

Comments (8)

perlboy avatar perlboy commented on August 26, 2024

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.

CDR-CX-Stream avatar CDR-CX-Stream commented on August 26, 2024

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.

perlboy avatar perlboy commented on August 26, 2024

@CDR-CX-Stream ,

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:

  1. In Amending Authorisation Standards
  2. In Data Holder Dashboards
  3. In Specifying an existing arrangement
  4. 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:

  1. 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:"
  2. 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.

joshuanicholson avatar joshuanicholson commented on August 26, 2024

As an ADR, we had always intended on passing the arrangement id

from standards-maintenance.

ACCC-CDR avatar ACCC-CDR commented on August 26, 2024

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.

CDR-CX-Stream avatar CDR-CX-Stream commented on August 26, 2024

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 the cdr_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 the cdr_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 the cdr_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 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.

--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.

CDR-CX-Stream avatar CDR-CX-Stream commented on August 26, 2024

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.

CDR-API-Stream avatar CDR-API-Stream commented on August 26, 2024

The proposed change has been staged for review.

from standards-maintenance.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.