-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decision Proposal 334 - Data Holder Dashboards #334
Comments
DP334 has now been published for consultation. The paper can be found in the original post. This consultation will close on Tuesday 21 November 2023 |
Great Southern Bank welcomes the opportunity to provide feedback on this DP. We support the proposed changes and appreciate the Figma artefact for examples of how and where these standards might be implemented. We also support the FDO of 1 July 2024 for the changes given it's aligned with the rules requirement date. Regards, |
The team have put together a short video introducing Decision Proposal 334 on the Data Standards Body YouTube Channel. |
Westpac welcomes the opportunity to provide feedback on DP334. Part 1 of DP334 (Amending authorisation details) - We suggest as a first iteration “minimum” details required for the "details of each authorisation's amendment" should be an activity log detailing the dates of the consent's amendments and wording directing the customers to the "archived" consents. EG: For full details of the original consent, please refer to the Archive Consents tab. The activity log would be a collapsible section at the bottom of the Consent details page which would give the consumer information about activity that has been performed on this consent. EG: Date(s)/Time consent had been amended, who amended the consent, information to direct the consumer to find the original consent. With the current pipeline of work including DP's and Maintenance Iteration we request a new Obligation date of 1st Nov 2024. Part 2 of DP334(Data recipient handling details) - We support the change and will take guidance from the supplied Figma artifacts to implement this change. |
CBA supports the proposed Consumer Experience standards amendments in DP334, as these enhance transparency for consumers in relation to amending authorisations and data recipient handling details. CBA is also supportive of the 1 July 2024 compliance date to meet these requirements. |
Please find attached Biza feedback regarding DP334. We wish to specifically call out the identification of requirements on Data Recipients in Rule 1.14(3)(i), in effect since December 2020, with precisely the same wording as 1.15(3)(h) for which the DSB appears to only provide a single Guideline (which simply repeats the Rule) and no binding Standards for. |
This consultation is now closed. Thank you to all who responded. |
The Data Standards Chair has now approved this decision. The decision record can be found in the original post. These standards have a future dated obligation of 1 July 2024 to align with the obligation date specified in CDR Rule 1.15(3A) and allow the rules intent to be realised through the standards while reducing compliance ambiguity. The DSB will discuss the queries raised during this consultation with other CDR agencies, and will consider responses and/or CX Guidelines in due course. |
When will the DSB define binding Standards for Recipient Dashboards for the same requirement? This is relevant particularly in the context of integrated dashboards (ie. Holders which are also Recipients) as the CX experience would ideally be uniform. |
Hi @perlboy Thanks for linking ADR and DH dashboards in relation to this issue. The DSB has not planned to develop equivalent standards for ADR dashboards. This is because the introduction of Rule 1.15(3)(h) for DH dashboards creates parity with the existing Rule 1.14(3)(i) for ADR dashboards regarding the details of amendments on consumer dashboards. These rules already require ADR and DH dashboards to be uniform in that the details of amended consents and amended authorisations must be displayed on both, respectively. In relation to Biza's submission, we expect that these rules already require ADRs to display the details of the specified amendments, with the exception of amendments to redundant data handling and business consumer statements (which regardless would not apply to DHs). The standards consulted on in DP334 are in addition to these requirements, and specifically for DHs, due to the difference in technical functionality. This is because, as stated in DP276, authorisations cannot technically be amended, and if the ADR does not supply a cdr_arrangement_id when seeking to amend an authorisation, it is expected that the DH will treat it as a separate and standalone authorisation. The same issue is not expected to exist for amended consents, as ADRs initiate and oversee the invitation to amend a consent, and so have the means to establish this link already. An equivalent example can be found in the rules and standards on amending consents and amending authorisations. The Amending Authorisation Standards link the supply of a cdr_arrangement_id to the notice and amendment invitation requirements specified in Rules 4.18C, 4.20S, and 4.22A. No equivalent standards were proposed for ADRs in relation to consent amendment. We hope that clarifies the rationale but invite further views and/or a change request if we have misunderstood the query or have missed a gap that should be addressed. If so, we would also welcome wording for any such standard(s). |
The question was around Standards not Rules. If the Rules were sufficient it is unclear why the Holder Dashboard Standard needed to be defined in the first place. For clarity these Rules do not prescribe uniformity, they prescribe the same requirement not the same outcome. The Standards are now prescribing on one side and not the other so it is even more confusing on the expectation.
Again, I'm not asking about the Rules but in your answer you've literally highlighted an example of how it isn't possible for both sides to be uniform. This is applicable in the situation of a Dashboard servicing both a Holder and Recipient requirement like for instance a Bank who is a Recipient.
Whether an authorisation can be technically amended is irrelevant in a Rules context. I initially thought this was a 🐰 hole that didn't make sense but rereading what's written I think what @CDR-CX-Stream is implying is that the only amendment to be displayed in Data Holder dashboards is one involving ADR initiated amendments with Does that mean a Holder doesn't have to display modifications to the authorisation other than this specific action? In a legal context (but perhaps not in a nuanced CDR Rules one?), there are quite a few other actions that will result in an authorisation being "amended", like for instance deliberately revoking it, DOMS changes, ineligibility changes, SUI changes and a few others.
Ok but what about amending consents other than disclosure consent? Is the ADR meant to show these changes to? How about the new Business Consumer consent that is exclusively ADR territory?
It doesn't. If anything it seems to highlight a misunderstanding between us around what is an amendment. Is an amendment just the one involving This Standard is making it even more confusing for implementors to try and glean a "vibe" of what is expected which, is what they will have to do, because there is so little prescription to understand what is actually compliant. |
The code changes for this decision are staged for review - ConsumerDataStandardsAustralia/standards-staging@release/1.29.0...dp/334 |
* Create clean version of release 1.29.0 * Added releasenotes file for 1.29.0 * Added redirect_uri * Update CX Guidlines link * Removed amending authz * added RFC7636 to refs * Updated Intro DSB link * Differences in naming of Register endpoints * Added obligation schedule to FDO * Updated desc of minimumValue maximumValue unitOfMeasure * Updated markdown of minimumValue maximumValue unitOfMeasure * Added missing fields for PAID_OUT_AT_MATURITY ROLLED_OVER for maturityInstructions * Updated definition of Number in common field types * Updated descriptions on ErrorMetricsV2 * Modified URL in line with request example * url encoded * Retain Version Delta for Additional Standards Re-added the 1.28.0 Version Delta comments for the Candidate and Draft Standards recently updated and still under consultation in 1.29.0. * Added authorization_signed_response_alg & authorization_encrypted_response_alg as conditional * Resolve link and navigation issues Addresses: ConsumerDataStandardsAustralia/standards-staging#222 * Switch tracking and add Standards category ribbon Addresses: ConsumerDataStandardsAustralia/standards-staging#334, ConsumerDataStandardsAustralia/standards-staging#332 * Corrected minor typos only Addresses typos: ConsumerDataStandardsAustralia/standards-staging#312 * Remove resource name to reduce length + complexity Addresses: ConsumerDataStandardsAustralia/standards-staging#222 * Added end & * Removed FDO Obligation date from Amending authorisation * Created a single link for [PKCE] / [RFC7636] * Standards Maintenance Issue #587: Added new field measureUnit in EnergyBillingDemandTransaction * Adjust heading levels and add navigation classes Addresses: ConsumerDataStandardsAustralia/standards-staging#338 * Identifying superseded versions in obsolete path Addresses: ConsumerDataStandardsAustralia/standards-staging#334 * Business Consumer Provisions Addresses: #333 * Added link to change description * Added link to change description * Standards Maintenance Issue #587: Fixed typos. Re-arranged order of api versions for consistency * Add style to override class for CX submenu items * Added Data Holder Dashboards section Addresses: #334 * Added link to issue * Added issue link to description * Added issue link to description * Updated with data attribute to apply CSS * Updated with data attribute * Added FDO details * Standards Maintenance Issue #613: Changed type of time fields in energy plan data to ExternalRef referring to ISO 8601 Times specification * Standards Maintenance Issue #613: Changed description of affected time fields for clarity. * Standards Maintenance Issue #587: Fixed typos * Standards Maintenance Issue #587: Fixed typo in FDO table * Retaining majority of useful original anchors Addresses: ConsumerDataStandardsAustralia/standards-staging#222 * Display the x-cds-type for array items Addresses: ConsumerDataStandardsAustralia/standards-staging#348 * Show format of request parameter enums correctly Addresses: ConsumerDataStandardsAustralia/standards-staging#349 * Adding release notes and delta comments Update for: ConsumerDataStandardsAustralia/standards-staging#348 * Update to release notes and NBL version delta * Remove last diffs * Moving NBL Draft to Candidate Standards Addresses: #318 * Rebuild * Add FDO diff statement for 587 * Add diff statements and release notes * Add diff and release notes * Add release note reference to CR620 * Add release notes * Add santa hat * Update release date * Fix release notes Update obligation date counts * Corrected typo * Add MI 17 DP to release notes Addresses: #328 * Updated links * Updated dates * Added deprecation dates * Corrected typo * Rebuild * Update change log with DP328 --------- Co-authored-by: Hemang Rathod <hemang.rathod@consumerdatastandards.gov.au> Co-authored-by: kirkycdr <brian.kirkpatrick@consumerdatastandards.gov.au> Co-authored-by: Nils Berge <60594671+nils-work@users.noreply.github.com>
@perlboy this query is being discussed with CDR agencies and a settled response is expected in the new year. |
The decision relating to DP334 has been reflected in v1.29.0 of the published standards, so this issue will now be closed. |
@perlboy apologies for the time taken to respond to this on GitHub. This query has already been responded to elsewhere and is being posted here for completeness and the benefit of others following this thread. We invite any further queries to be raised as a new zendesk ticket here. The crux of this query seems to be: what is an amendment? We have discussed this with CDR agencies and have validated the interpretation upon which these standards were developed. Further details are outlined below. There are existing requirements for ADR and DH dashboards, which include specifying details relating to the status of the consent or authorisation, such as indicating where it has been withdrawn or, for DHs, where SUI or DOMS adjustments have occurred, among other things. These are separate to the requirements for displaying the details of an amendment to a consent or authorisation on a dashboard. As per the rules, an ADR may invite a consumer to amend their existing consent(s) when the conditions set out in 4.12B(3) are met. This could include an amendment to datasets, durations, consent types, or other details requiring consent as outlined in rule 4.11. As per rule 4.11(1), collection consents - which correspond to DH authorisations - can be amended to reflect new datasets and/or a new duration as per rule 4.11(1)(a)(i) and 4.11(1)(b), respectively. If a consumer chooses to amend a collection consent, then rule 4.18C specifies that the ADR must notify the DH, and that the DH must then invite the consumer to amend the corresponding authorisation, which would pertain to the dataset(s) and duration. The authorisation amendment details to be displayed on the DH dashboard would follow accordingly – that is, the dashboard would need to indicate what changes have been made to the dataset and/or duration authorised for sharing. This does not override or displace the need to display other details on the dashboard. As noted in our previous response, the DSB expects that DHs will treat a request as a separate and standalone authorisation where the ADR has not supplied a cdr_arrangement_id. This is on the basis that without this information it will not be possible for the DH to link the request to an existing authorisation. The CX standards establish this link for authorisation amendments where the ADR supplies a cdr_arrangement_id. The standards in DP334 also facilitate this link for the purposes of displaying the corresponding authorisation amendment details on the dashboard, as is now required by the July 2023 rules. |
Tuesday 28 November: Decision Made
The Data Standards Chair has approved this decision.
The decision record can be found below:
Decision 334 - Data Holder Dashboards.pdf
These standards have a future dated obligation of 1 July 2024 to align with the obligation date specified in CDR Rule 1.15(3A) and allow the rules intent to be realised through the standards while reducing compliance ambiguity.
Tuesday 24 October: Decision Proposal Published
Decision Proposal 334 proposes data standards for data holder dashboards in response to the July 2023 CDR Rules.
The decision proposal can be found below:
DP334 - Data Holder Dashboards.pdf
The specific topics covered in this paper are:
This consultation progresses from DP276 to outline which data standards are being proposed as binding. This paper reflects those proposals with minor revisions based on the feedback received.
Community views are now being sought before these standards are proposed to be made binding.
This consultation will close on Tuesday 21 November 2023
The text was updated successfully, but these errors were encountered: