ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (17th of June 2021)
CDR API Stream edited this page Jun 18, 2021
·
5 revisions
When: Weekly every Thursday at 3pm-4.30pm AEST
Location: WebEx, quick dial +61262464433,785383900%23%23
Meeting Details:
Desktop or Mobile Devices
https://csiro.webex.com/csiro/j.php?MTID=m7c39ee9db5e5892ab35cd0bd7bbf94ce
Once connected to your meeting remember to start your audio and video
Please mute when you are not speaking.
Video Conferencing (VC) Rooms
Use the remote control or touch panel and dial the number indicated below:
External VC Room: 785383900@csiro.webex.com
Phones - AUDIO ONLY
- Primary Australia: +61 2 6246 4433
- Quick Dial: +61262464433,785383900%23%23
- Other Global Numbers: https://conferencing.csiro.au/Call-in.php
- Meeting Number/Access Code: 785 383 900
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- Any other business
- 5 min will be allowed for participants to join the call.
The Consumer Data Right Implementation Calls are recorded for note taking purposes. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material shall be provided without the participant's consent. Participants may contact@consumerdatastandards.gov.au should they have any further questions or wish to have any material redacted from the record.
We acknowledge the Traditional Custodians of the various lands on which we work today and the Aboriginal and Torres Strait Islander people participating in this call.
We pay our respects to Elders past, present and emerging, and recognise and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.
| Type | Topic | Update |
|---|---|---|
| Standards | Version 1.10.0 Published | Link to change log here |
| Standards | Version 1.11.0 Draft Board | Link to Version Project Board here |
| Maintenance | 7th Maintenance Iteration underway | Agenda of the backlog session |
| Maintenance | Decision Proposal 178 - Banking Maintenance Iteration 7 | Link to consultation |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| TSY Newsletter | To subscribe to TSY Newsletter | Link here |
| TSY Newsletter | 4th of June 2021 Edition | View in browser here |
| DSB Newsletter | 11th of June 2021 Edition | View in browser here |
| Consultation | Decision Proposal 166 - CX metrics for Data Holders | Link to consultation |
| Consultation | Decision Proposal 180 - Energy Draft Feedback Cycle 3 | Link to consultation |
| Consultation | Decision Proposal 182 - InfoSec Uplift for Write | Link to consultation |
| Consultation | Decision Proposal 186 - Engineering Support | Link to consultation |
| Consultation | Decision Proposal 187 - CX Standards - Disclosure Consents | Link to consultation |
| Consultation | Extending Decision Proposal 166 by 1 week | Link to consultation |
| OAIC | Updated CDR Privacy Safeguard Guidelines |
The Office of the Australian Information Commissioner (OAIC) has published updates to the CDR Privacy Safeguard Guidelines to reflect amendments to the Competition and Consumer Act 2010 and the CDR Rules. The Privacy Safeguard Guidelines outline how the Information Commissioner will interpret and apply the privacy safeguards. The updated guidelines reflect changes to:
|
| Community | Regional Australia Bank - myCDRdata | If people want some background and context https://www.regionalaustraliabank.com.au/the-inside-story/articles/discover-your-data-using-mycdrdata-from-regional-australia-bank If people want to go straight to the application https://mycdrdata.regionalaustraliabank.com.au/ If people want minimal typing https://mycdrdata.com.au/ |
Provides a weekly update on the activities of each of the CDR streams and their workplaces
| Organisation | Stream | Member |
|---|---|---|
| ACCC | CDR Register (Technical) | Ivan Hosgood |
| ACCC | Onboarding | Chantelle Demian |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
None this week.
Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can pre-submit questions to the DSB mailing box.
We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517
| Ticket # | Question | Answer |
|---|---|---|
| 812 Part 1 | As a DH, due to technical limitations that exist within our current core banking application; in some scenarios such as transaction back dating/readjustment or for interest calculations adjustments that may need to occur due to differences in effective date and clearing (posting) date of some transactions on some products/accounts, we could potentially have some historical transactions (transactionId) that are no longer available (however, may have been shared in the past with the ADR). To add further, in these scenarios, these old transactions are effectively replayed/replaced with a modified transaction, but, with a new transactionId. In this problem scenario, is it fine for the DH to respond with a 4xx error when Get Transaction Detail is requested by the ADR, for the old transactionId that does not exist anymore. Is this still considered compliant from a CDR implementation perspective? If yes, which would be a more suitable response - 404 or 422 error response? As a separate question, would this scenario be classified as a data correction by any chance, where we would need to notify the consumer of this amendment to the transaction listing that was shared earlier, in line with Privacy safeguard 11? Guidance on this also would be highly appreciated. Also, do you have an insight of any other CDR participants that are having similar technical limitations/challenges and have reached out with a similar question around Transaction IDs/listing/detail. |
First, yes some banks have similar situations for transaction data. Transaction IDs are unevenly implemented and can change across the lifecycle of various transactions as they move from pending to posted (or equivalent stages for various types of transactions). For this reason the transaction ID has specific language indicating that it does not need to be provided if there are good technical reasons not (as you have outlined in your comments). Changes of this type would not be considered as data correction as the data has changed through the normal lifecycle of the data and not through correction of an error. |
| 812 Part 2 | In this problem scenario, is it fine for the DH to respond with a 4xx error when Get Transaction Detail is requested by the ADR, for the old transactionId that does not exist anymore (noting that this old transactionId has been shared in the past through the Get transaction API). Is this still considered compliant from a CDR implementation perspective? If yes, which would be a more suitable response - 404 or 422 error response? | The correct response would be 422 as the transactionId is valid and has been previously shared but is no longer available. 404 indicates the transactionId was never valid and is unknown. |
| 820 | I wanted to understand how the egress to the outside world is solved by the Data Holders. The default egress policy would be deny all outbound calls (unless we explicitly allow specific ones that we really want to). In the DCR model it becomes a bit tricky. Outbound calls from a DH Solution are the following: 1. ACCC (CDR Register, CDR JWKS). - The end points are absolutely clear. So we can allow outbound traffic for this 2. Digicert CA (for OCSP checks) - The end points are made available by Digicert so not issues here as well 3. ADR (JWKS, cdr arrangement end point ...) - These URLs are not known prior to a DCR request. If we want a DCR call to be successful, then I have the following three choices Allow all outbound traffic - which is not a sensible thing to do. The banks are unlikely to support this approach. Allow a DCR flow to come through and fail - Use the information in DCR (getting the ADR end points and allow egress traffic for that in some automated way) so that a subsequent request from the is successful. ADRs will be unhappy as their first request fails and hoping our automation set up can set things up before the DCR re-try request comes through Have the ADR end points communicated via another mechanism to the Data Holder which is used to get this information. (none of the CDR Registry APIs will provide us with the required information) Interested to see how this has been solved by the other Data Holders. |
The DSB does not give detailed guidance on internal implementation questions. We can, however, say that: Giving an initial error is a non-compliant solution Requiring a separate path for ADR registration is a non-compliant solution Note that this was raised by at least one Data Holder during consultation on the standards and the standards are the result of combining that feedback with other feedback. It is worth noting that the issue you are raising is an inherent issue with the OIDC Dynamic Client Registration protocol which is an international standard tested by the industry. It is also a feature of many other protocols such as internet browsing and the exchange of email. The compensating controls for these implementation models may be more appropriate than the compensating controls normally applied to B2B communication where both end points are often known in advance. |
| 822 | Link: https://cdr-support.zendesk.com/hc/en-us/articles/900003966346-Clarification-of-physicalAddresses-in-CommonPhysicalAddressWithPurpose#comment_360000424775 This appears to violate the standards that say "Must contain at least one address." ? |
We shouldn't let these inconsistencies stand. We've responded on the article and raised a maintenance change request. |
| 825 | Would like to seek guidance on the nbf claim and its validation. As a dataholder we expect that the nbf claim should be provided in any scenario that requires a JWT validation (DCR create/modify (Request and SSA JWT), COnsent Request JWT, Client_assertion JWT (revoke, cdr introspection, /token endpoint) This is not explictly called out in the CDS or the register standards but these requirements are taken from the FAPI profile spec https://openid.net/specs/openid-financial-api-part-2-1_0.html referenced from the standards. Could you confirm our understanding is correct? If we turn on nbf validation, we will reject requests from ADRs that do not include the nbf claim. |
the mandatory requirement of "nbf" was introduced in FAPI 1.0. The CDS currently relies on FAPI WG Draft 06 which does not include this requirement. The "nbf" claim is not currently required by the CDS. A review of differences between Draft 06 and 1.0 Final is currently being undertaken to identify changes like this that will have breaking change impacts. Currently, clients are not required to present the nbf claim however if received, the DH must validate it in accordance to RFC7523 and RFC7519. The additional constraints on validation of the nbf claim introduced in FAPI 1.0 Final don't currently apply but there is a good expectation that on completion of the analysis and consultation on FAPI standards uplift this would be adopted. |
| 834 | Address to be returned in GetAccountDetails API - Requesting clarification on whether it is just the MAIL address that is required, or whether both the REGISTERED and MAIL address should be returned in the GetAccountDetail API response. (Schema ResponseBankingAccountById - BankingAccountDetail - CommonPhysicalAddress - CommonSimpleAddress). In the ResponseCommonCustomerDetail API it is clear that the CommonPhysicalAddressWithPurpose can return more than one address detail, however I can't see that this is clear in the GetAccountDetails API. |
The purpose type isn't specified. The description of the address array notes that the addresses applicable for the account are "to be used for correspondence". If the address is not used for correspondence purposes it is excluded. |
| 835 | Under the traffic thresholds for unattended traffic, there's a threshold mentioning 20 sessions per day, per customer, per data recipient[1]. When applying this threshold, do we have to consider unattended traffic which result in error responses? For example Bad requests due to an invalid account request with a valid access token. And also, as per our understanding traffic with authentication failures should not be considered when applying this policy. Is our understanding correct? [1] https://consumerdatastandardsaustralia.github.io/standards/#traffic-thresholds |
The threshold you quote in your question is "20 sessions per day, per customer, per data recipient". Elsewhere a session is defined as the provision of an access token. Your questions, however, related to the counting of API invocations which are not the same as session. A single session could result in many API invocations, some which success and some which fail. |
| 843 | I think my original question was misunderstood. What I was after is how should data holders treat the following scenario: A customer provides consent today, the consent is given an arrangement ID. 2 years later, when the consent is expired (and no other consent has been added to the arrangement ID) the DR sends a request for a new consent under the same arrangement ID. Should the DH treat it as an 'amendment' and present to the customer the variations between the 2 consents as per the CX standards and then create the new consent under the same arrangement ID. So pretty much the arrangement ID lives for at least 6 years (as per record keeping requirements) from when it was issued or when the last valid consent was added to it? Or should the DH treat it as a totally new consent and give it a new arrangement ID, and not show the differences between the 2 consents in the UI? I could not find anything in the standards related to this scenario. The standards say that if a request for 'amendment' comes a new consent should be created and the old one revoked. However there's nothing mentioned about the case where the original consent is not valid anymore. |
This is an interesting scenario. It is true that the standards are silent on this. This is because, when the arrangement ID was introduced, consent amendment was not actually valid under the rules and we were preparing the ground for a rule change indicated by the rules team. As the rules for amendment were not known the standards could not be definitive on treatment. As the standards are silent we can only give a convention rather than a standards interpretation. Logically, an expired consent is defunct. According to the rules the election for deletion/de-identification has already been invoked. In this context it would not be expected that an expired or revoked consent could be resurrected or amended and this scenario should be treated as a new consent. It should probably not be responded to with error, however, as the consumer must be in the context of establishing consent, otherwise a call would not be made, responding with error would be counter to the desire of the consumer. |
| 846 | We would appreciate it if the Data Standards Body could recommend an approach for including cashback offers (for example an offer to receive an amount of money for opening a new mortgage) in the product reference data. Our suggested approach is to include an offer of this type as a feature with featureType of OTHER. Please confirm that this is the best approach. | This seems a reasonable approach. If you would prefer this to be an explicit feature, it would be worth raising a change request on standards maintenance. |
| 849 | I Was looking for an example of request in the scenario where DH calls the DR /arrangements/revoke. I came across example within section Client Authentication(https://consumerdatastandardsaustralia.github.io/standards/#client-authentication) with below and wanted to make sure I am looking at the right one. Is the below right example for DH calling DR /arrangements/revoke end point? The below example has token&token_type_hint sent as body parameters. But in case of /arrangements/revoke, there will be a single body parameter cdr_arrangement_id, is this correct understanding? Example from (https://consumerdatastandardsaustralia.github.io/standards/#client-authentication). Also attached is the screenshot of the same. Non-Normative Example - Data Holder calls the Data Recipient's revocation end point (note that the “aud” claim is the fully qualified path to the revocation end point because the full path is also the Base URI). POST https://data.recipient.com.au/revocation HTTP/1.1 Host: data.recipient.com.au Content-Type: application/x-www-form-urlencoded Authorization: Bearer eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey … token=45ghiukldjahdnhzdauz&token_type_hint=refresh_token ## Decoded Bearer token JWT { "alg":"PS256", "typ":"JWT", "kid":"67890"}{"iss":"dataholderbrand-123", "sub":"dataholderbrand-123", "aud":"https://data.recipient.com.au/revocation", "iat":1516239022, "exp":1516239322, jti":"dba86502-7cf5-4719-9638-c5339a0ddb06"} |
The normative example you refer takes the form of the token revocation end point. Prior to the introduction of the arrangement revocation end point we were leveraging the OIDC token revocation end point. This is why the URL and the body match the token revocation structure rather than the arrangement revocation structure. There is actually a non-normative example of the arrangement revocation end point in the security end points section: https://consumerdatastandardsaustralia.github.io/standards/#end-points |
| 852 | As per new CDR Standards v1.10.0, new standards in error handling technique has been introduced. Why are the error codes different across the APIs for the same business case? There should be one list of all the applicable error codes and not spread across the APIs. Application wise its not possible to have different error codes (CDR errors in this case) for the same business condition. Eg : Get Transactions has 404 - Unavailable Banking Account and 404 - Invalid Banking Account Get Direct Debits has 422 - Unavailable Banking Account and 422 - Invalid Banking Account |
this has to do with the way the resource is requested. For the bulk APIs that use a POST, the 404 (Not Found) is not the applicable status code because the resource is not presented in the URL. 422 has always been used for the bulk APIs via POST whereby the resource that is being requested cannot be found or returned. The CDR error code is the same in both instances. |
| 853 | BankingInternationalPayee message & legalEntityIdentifier field clarifications I have clarification on what must be provided in following fields of BankingInternationalPayee: 1. beneficiaryDetails -> message: Is this the default Payment Message/Reference entered while payee creation? If not please advice 2. legalEntityIdentifier : ISO 17442-1:2020 specifies LegalEntity ID. Is passing the SWIFT BIC ok? If not please advice. |
In response to your questions: Q: beneficiaryDetails -> message: Is this the default Payment Message/Reference entered while payee creation? If not please advice A: Yes, I believe that is the intent Q: legalEntityIdentifier : ISO 17442-1:2020 specifies LegalEntity ID. Is passing the SWIFT BIC ok? If not please advice. A: No, the Swift BIC should go in beneficiaryBankBIC as stated in the description of that field Note that these fields are optional and designed to capture a beneficiary that may be used for a variety of international payment flows such as NEFT and RTGS. It is therefore not expected that every field will be captured or returned. For instance, if a data holder doesn't capture an ISO 17442 field for international payees then the legalEntityIdentifier would be blank. |
| 854 | The description for the Unavailable Resource, Invalid Banking Account and Unavailable Bank Account for 404 and 422 is the same. Could it be that there's a mistake in the standards and for the 422 errors codes it was meant to apply when the unavailable/invalid resource is provided in the request body? Otherwise what is the difference between the 2 sets of error codes. For example when should the 404 Invalid Banking Account be used and when should the 422 Invalid Banking Account be used? |
This is correct. This was also picked up during internal team review. I have created a fix for this under Standards Maintenance (https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/389) and the fix will be included in the next release. |
| 856 | Looking for some guidance on the consent amendment scenario in a business consumer context and also on the terminology within the standards around customer & consumer. The PAR endpoint standards say "If the cdr_arrangement_id is not related to the consumer being authenticated it MUST be rejected" Could you please clarify who is the consumer here? The nominated representative or the business consumer itself. And, In Issue #153's comments, DSB said this - "The DSB is working with the ACCC to draft a response providing guidance here. CDR Arrangement IDs are bound to the subject, so they are not transferable across different “sub” values." Could you please clarify if we should allow amending the arrangement by the nominated representative who did not create the arrangement in the first place but belongs to the same business consumer? Similarly, for get customer the standards say "Obtain basic information on the customer that has authorised the current session". Could you please clarify who is the customer here? the nominated representative or the business consumer (Organization). I think the expectation here is to provide the organization details even though the customer that has authorized the session is nominated representative. I was referring to the #153 in the Standards github in the specific comment -https://github.com/ConsumerDataStandardsAustralia/standards/issues/153#issuecomment-780184487 |
Currently the statement "If the cdr_arrangement_id is not related to the consumer being authenticated it MUST be rejected" should be understood to mean "If the cdr_arrangement_id is not related to the same subject being authenticated it MUST be rejected". It should be noted that the provision of a subject identifier is up to the data holder in many scenarios and guidance in various articles has been given on this topic. Note that for the standards, a customer is defined as being the customer as interpreted by the data holder. Broad latitude is given to the data holder to interpret the relationship between Customer and Agent Of Customer. This is simple in the retail context as the two entities are always the same. For business customers this is more complicated and data holders have different ways of handling this. In this context the provision of a subject identifier, the relationship between subject and person and the relationship between subject and business is a question for the data holder in their specific context. |
| 862 | Could you please confirm that data sharing rejections for below reasons should not be reported as refusals under rule 9.4(d):
And that below data sharing rejections should be reported as refusals under Rule 9.4(d)
Should requests for below data be responded with an error or empty response field or no response at all? If responded with an error, are they refusals to be reported for rule 9.4(d) purpose?
I have been researching the support portal but was not able to find answers for these specific cases. |
The classification of rejections in your first two lists seem fine to me based on previous statements by the regulator, although I would have considered a timeout as an error rather than a rejection (this still makes it reportable, however). With regards to phasing, a data holder that is not yet obliged to implement a specific end point, or has an exemption, should respond with a 404 rather than an empty payload. These would not be considered refusals. |
Updating the table below - if your question/ ticket has not received a response yet the team continues to work on a response. We do apologise for the delay on some tickets, the teams are doing their best to get to everyone's questions.
To our valued CDR participants, We have undertaken a review of the CDR Support Portal as a channel for providing guidance on CDR Rules. Based on the volume and nature of questions we have received recently, we have decided to move to a model based on publishing guidance to the community, rather than providing individual responses to stakeholder questions. Our goal is to prioritise the provision of guidance that is accessible, transparent and has industry-wide application. We intend to develop this to meet clear community needs, which we will identify and prioritise based on questions and issues raised by stakeholders. We kindly ask for your patience as we work our way through the tickets, feedback and guidance
A work in progress - open for feedback from the community on what you would like to see.
| Organisation | Description | Link |
|---|---|---|
| OAIC | Main landing page for the Office of the Australian Information Commissioner and the Consumer Data Right | Link |
| DSB | CX Artefacts - The CX Guidelines provide optional examples of key requirements and recommendations to help organisations build best practice consent models. CDR Participants should also refer to the CDR Rules, data standards, and privacy guidelines for a complete view of obligations to facilitate compliance. | Link |
| DSB | Consumer Data Standards Main Page - About the DSB team, engaging with our consultations and Events | Link |
| DSB | The Consumer Data Standards - The technical and consumer experience standards for the Consumer Data Right | Link |
| DSB | The Banking Product Comparator - a demonstration of Product Reference Data from Data Holders as part of the Consumer Data Right | Link |
| DSB | GitHub Consultations - all public consultations from the Data Standards Body | Link |
| DSB | Java Artefacts - An Open Source Project comprised of reference implementations of both Data Holders and Data Recipients | Link |
| ACCC & DSB | The Consumer Data Right Support Portal Knowledge base for the Consumer Data Right covering Rules through to Technical articles and questions |
Link |
| ACCC | ACCC Main focus area/ landing page for the Consumer Data Right | Link |
| ACCC | GitHub Consultations - all public consultations from the ACCC Register Team | Link |
| ACCC | CDR Register Design Reference | Link |
| ACCC | Public page for the Consumer Data Right | Link |
| ACCC | Participant Portal page including sign-up and log-in | Link |
| TSY | Consumer Data Right background and historic records from the Treasury | Link |
- Overview
- 2nd of May 2024
- 25th of April 2024 - Cancelled (ANZAC Day)
- 18th of April 2024
- 11th of April 2024
- 4th of April 2024
- March 2024 Agendas
- February 2024 Agendas
- January 2024 Agendas
- 2023 Agendas