ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 17th of March 2022 - ConsumerDataStandardsAustralia/standards GitHub Wiki

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEDT Location: WebEx, quick dial +61-2-9338-2221,,1650705270##

Meeting Details:

Desktop or Mobile Devices https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f 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: [email protected]

Phones - AUDIO ONLY

Agenda

  1. Introductions
  2. Actions
  3. CDR Stream updates
  4. Presentation
  5. Q&A
  6. Any other business

Introductions

  • 5 min will be allowed for participants to join the call.

Recording

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 [email protected] should they have any further questions or wish to have any material redacted from the record.

Acknowledgement of Country

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.

Updates

Type Topic Update
Standards Version 1.16.0 Published Link to change log here
Maintenance DSB Maintenance Iteration 10: Agenda & Meeting Notes on 16th of March 2022 Link to the agenda and minutes
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 4th of March 2022 View in browser here
DSB Newsletter 11th of March 2022 View in browser here
Consultation Normative Standards Review (2021) No Close Date Link to consultation
Consultation Decision Proposal 229 - CDR Participant Representation Placeholder: no close date Link to consultation
Consultation Decision Proposal 240 - ADR Metrics Feedback closes 15th of April 2022 Link to consultation
Design Paper Design Paper: Consumer Data Right Rules and Standards for the Telecommunications Sector Link to DSB GitHub Link to Treasury page
CX Guidelines 14th of March 2022 Update NEW Open source design assets and prototypes for Consent Management (Data recipient): Collection and use NEW Open source design assets and prototypes for Consent Management (Data recipient): Disclosure consents. Updated CX Checklist (on website) related to CX standards for Collection and Use, and Disclosure Consents Updated page titles and hierarchy for Consent Management Link to the CX Guidelines
CX Guidelines 16th of March 2022 Update New Open source design assets and prototypes for Consent Management (Data recipient): Withdrawal. Updated CX Checklist Link to the CX Guidelines
Knowledge Video 19: CDS CX Standards and Guidelines - with Michael Palmyre (11/03/2022) Link to video
Knowledge Video 20: Technical aspects of the Consumer Data Standards - with James Bligh (17/03/2022) Link to video
Knowledge Video Playlist for Telecommunications Workshop (February 2022) Link to Playlist
Action Update Joint Account Guidance article with clearer indication of new/ updated advice. Completed.

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their stream of work

Organisation Stream Member
DSB CX Standards Michael Palmyre
DSB Technical Standards - Register Ivan Hosgood
DSB Technical Standards - Energy Hemang Rathod
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Engineering James Bligh

Presentation

None.

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.

We are using Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #747194

Answer provided

The following table will be updated after the meeting.

Ticket # Question Answer
883 Test Scenario: Ensure Client Assertion Data In Token Request I observed this in a CTS test execution where the subject claim does not match the iss claim "iss": "dcr-29b54862-ba42-3262-8e22-af157d05f02c", "sub": "dcr-29b54862-ba42-3262-8e22-af157d05f02c_0f967bd4-b03b-4663-bba0-af6444cd4565", We return a HttpStatusCode": 401, with the error_description: Invalid client or client credentials., error":"invalid_client" CTS expects a BadRequest (400) Actual Error message from CTS is as follows: Verify bad request token response wrong sub Token request: Unauthorized received, BadRequest expected. My interpretation of the spec is this: (From the Error Response section of OAuth2.0 RFC) invalid_client - Client authentication failed. The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. This is not a invalid_request scenario as the required claims data is present (request is complete except for sub and iss claims are not the same. They are expected to be the client_id of the bearer) References: https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication https://datatracker.ietf.org/doc/html/rfc6749 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bearer#page-5) Appreciate what the team thinks is the expected HTTP status code for this scenario. Data Standards Body response: This is an area where the standards (both CDR Standards and normative standards) are not definitive. The CDR Standards defer to the normative standard and the normative standards use MAY. As a result the DSB would consider both a 400 (representing a bad request or invalid client) and a 401 (as per OAuth 2) as a valid response. The key point for compliance is that an error is required as the iss and sub claims should match. The implementation in areas that are not definitive is at the discretion of the data holder. ACCC Response: The CTS team is working on a fix to support 401 as a valid error response code. We will provide an update when this fix has been deployed in CTS.
1326 part 1 1) If a CDR Consumer’s Internet Login to access their account is blocked temporarily and they can’t access any of their accounts online, should we treat that as a refusal (i.e. Rule 4.7(c )) or should we treat this as an ineligible (Sch 3 Part 2 – 2.1 Meaning of eligible banking sector) CDR Consumer ? 2) If the CDR Consumer from question 1 is treated as ineligible (temporary), should we proceed to delete all of their current consents (i.e. rule 4.26(1)(c ) while their access is temporarily blocked ? We’d also like to clarify that although a CDR Consumer’s Internet banking may be temporarily blocked, they can still transact on their accounts. For example the following activities can still be performed : Withdraw money from an ATM Existing Direct Debit arrangements Existing Schedule Payments arrangements. This is because the accounts themselves are not blocked, only their access into Internet Banking to view/take action on those accounts. We (ACCC) have recently updated our knowledge article on ‘Blocked or suspended accounts’. This knowledge article provides information relevant to your enquiry.
1326 part 2 Thank you for your response. Unfortunately the response did not address the question about whether or not we need to delete any active consent if the CDR Consumer becomes ineligible after the consent was created. Below is a scenario : On 1/3/22, John created a consent with Frollo to share this customer data. The duration of the consent is 12 months. On 15/3/22, John reported suspicious activities to his accounts and requested the bank to lock his Internet Banking access while further investigation is underway. He is now not able to access his accounts online. On 18/3/22, the Bank informed John there's no issues and re-enabled his Internet Banking access. He now has access to his accounts online. Question : On 15/3, when John has no access to his accounts online, that makes him ineligible (Rule : Sch 3 (2.1)(1). Should the consent created on 1/3/22 be deleted ? As set out in the relevant knowledge article, our view is that a blocked or suspended account will not cause a CDR consumer to be ineligible in relation to a data holder. This means that authorisations do not expire, and disclosures that had stopped under rules 3.5 and 4.7 may continue once the account is no longer blocked or suspended.
1326 part 3 The main question is how does rule 4.26(1)(c) have an impact on a Consumer who is made ineligible temporarily ? Do we need to delete their active consent if they are temporarily ineligible. Someone can be ineligible a) permanently (left the bank) or b) temporarily (e.g. looses access to the account online - Schedule 3 Part 2.1(1) Note : we are clear about the refusal rule in regards to Blocked or Suspended accounts but we are unclear about rule 4.26(1)(c) Details of rule as follows: 4.26 Duration of authorisation to disclose CDR data (1) An authorisation to disclose particular CDR data to an accredited person expires at the earliest of the following: (a) if the authorisation was withdrawn in accordance with paragraph 4.25(1)(b)―the earlier of the following: (i) when the data holder gave effect to the withdrawal; (ii) 2 business days after the data holder received the communication; (b) if the authorisation was withdrawn in accordance with paragraph 4.25(1)(a)―when the authorisation was withdrawn; (c) if the CDR consumer ceases to be eligible in relation to the data holder; As previously advised, our view is that a blocked or suspended account will not cause a CDR consumer to be ineligible in relation to a data holder (i.e. the consumer would not cease to be eligible for the purposes of rule 4.26(1)(c)). We encourage you to seek independent advice if you require further information about the application of the rules to your specific scenario. It is the responsibility of CDR participants to determine how they will comply with the CDR Rules.
1357 We are reviewing our product names and hoping to get clarification on whether our product names need to correspond exactly to the names published on our product disclosures? We are faced with character restrictions on our solution and will need to use abbreviations or reword our product disclosures. Would this be compliant? Note the content of specific product name fields are at the discretion of the data holder. Please refer to this knowledge article which provides information relevant to your enquiry.
1387 Taken on notice from 04/03/2022 from CDR Implementation Call On last week's call someone raised an interesting question about whether there was any policy intent behind the rule change to eligibility for the banking sector, e.g an account is "set up in such a way that it can be accessed online" versus "is able to access the account online". Have Treasury provided any response to this query, if not, when can a response be expected? Treasury has confirmed that the amendment to the wording of the eligibility criteria for the banking sector resulted from some ‘housekeeping’ amendments undertaken as part of the v4 rule amendments (to move common elements of eligibility for the banking and energy sectors into new rule 1.10B, while sector specific elements remained in the sector schedules). Treasury acknowledges the amendment has resulted in inconsistent language, but has confirmed that the policy intent was for the eligibility requirements for the banking sector to remain unchanged. That is, consistent with the CDR support portal guidance, the policy view is that CDR consumers in the banking sector must have an online account set up to be eligible.
1404 Follow-up to a question answered on 10th of March 2022. If a joint account has a mode of operation that is not either to operate, is this situation referred to as co-approval? ‘In that context… any joint accounts that have a mode of operation that is not either to operate, if we are not going to do co-approval, then we would not even include those accounts as able to be shared’ ? Information about the different disclosure options that may be applied for joint accounts under the CDR Rules is available in our revised Joint Accounts Implementation Guidance. Please note that the disclosure option that applies to a joint account may differ from existing authorities on the joint account. That is, if there is a ‘2 to sign’ authority for payments made from a joint account, that would not automatically transfer to a ‘co-approval’ option when sharing is automatically switched on for CDR. The requirement to facilitate data sharing under the CDR will apply regardless of existing authorities on the joint account, despite any decision not to offer the co-approval disclosure option for CDR data sharing. From 1 July 2022 the following will apply for all eligible joint accounts, regardless of existing authorities (unrelated to CDR data sharing) on those accounts: - if a disclosure option has never previously applied to a joint account, the pre-approval disclosure option will apply - if the pre-approval or co-approval applies to a joint account, the same disclosure option will apply - if a disclosure option previously applied to the joint account but was removed so that no CDR could be disclosed from the account, the non-disclosure option will apply from 1 July 2022.
1116 For Disclosure options, these are provided service by Data holder. 1. I believe there's no requirement for DH to notify ADRs for disclosure option changes right? (therefore, they should only know about it if they attempt to obtain data?) 2. If there's a request for new CDR data and the disclosure option is set to non-disclosure, the DH will just refuse to ask for an authorisation per 4.7(1)? 3. if point 2 is correct, that means DH will not need to track that as a refusal count? https://cdr-support.zendesk.com/hc/en-us/articles/900001914223-Reporting-for-refusals-to-disclose-CDR-data 4. If there's a change to the disclosure options after there's already active authorisation shared by one of the Joint AH, what is expected behaviour from the DH? Since setting non-disclosure option does not revoke any authorisation given, and Rule 4A.10(6) indicate that the DH must refuse to disclose the requested CDR data, so in terms of information to the ADR when they request the data again, do the DH just omit the account information back to the ADR (i.e. send them blank fields) ? or do DH need to send an error code to them instead? 5. For scenario mention in point 4, do DH track that as a refusal count? Q1: I believe there's no requirement for DH to notify ADRs for disclosure option changes right? (therefore, they should only know about it if they attempt to obtain data?) **A: **That’s right. Please refer to sections 5.23 and 5.24 of our joint account guidance Q2: If there's a request for new CDR data and the disclosure option is set to non-disclosure, the DH will just refuse to ask for an authorisation per 4.7(1)? A: Assuming that this refers to the establishment of a new consent then yes. Q3: if point 2 is correct, that means DH will not need to track that as a refusal count? https://cdr-support.zendesk.com/hc/en-us/articles/900001914223-Reporting-for-refusals-to-disclose-CDR-data A: Assuming that this refers to the establishment of a new consent then no, this would not be a refusal. Q4. If there's a change to the disclosure options after there's already active authorisation shared by one of the Joint AH, what is expected behaviour from the DH? Since setting non-disclosure option does not revoke any authorisation given, and Rule 4A.10(6) indicate that the DH must refuse to disclose the requested CDR data, so in terms of information to the ADR when they request the data again, do the DH just omit the account information back to the ADR (i.e. send them blank fields) ? or do DH need to send an error code to them instead? A: If an account is requested that is no longer authorised to be provided (due to a change in a disclosure status for instance) then the technical standards have specific error codes for this scenario (usually a 404 if the ID is provided as a path parameter and 422 if passed in a request payload) Q4a: If Joint AH sets Disclosure option to Non-Disclosure, would the Joint Account be disassociated from all existing authorisations given? i.e. Only account will be removed from those authorisations? But other consent authorisations will remains is that right? A: Yes. Q4b: Supposed if Joint AH arranged and set disclosure option back to Pre-approval, new CDR requests (along with approval/authorisation of the request) will be needed in order to share the Joint account again, is this interpretation correct? A: No. Please refer to scenario 7 of our joint account guidance. Q5. For scenario mention in point 4, do DH track that as a refusal count? A: In the scenario that a 404 or 422 is provided as per the technical standards this would be counted as a refusal.
1356 We're concerned at the lack of detail which might indicate full / partial ownership of both income and listed expenses contained in an account. We are trying to establish whether a particular account is an Individual Account (Sole ownership), Joint Account (Joint Ownership) or Third-party Account however GetAccounts API [https://consumerdatastandardsaustralia.github.io/standards/?examples#get-accounts] only provides following information "accountId": "string", "creationDate": "string", "displayName": "string", "nickname": "string", "openStatus": "CLOSED", "isOwned": true, "maskedNumber": "string", "productCategory": "BUSINESS_LOANS", "productName": "string" AND isOwned flag only Filters accounts based on whether they are owned by the authorised customer. True for owned accounts, false for unowned accounts and absent for all accounts, Does not indicate sole ownership. Is there another attribute that we could use to establish joint or sole ownership of accounts? Something in the lines of ownershipType with values as SOLEOWNER, JOINTOWNER, THIRDPARTY? There is no field in the Get Accounts payloads that indicate the ownership type. There is no current plan to provide this data through the existing resource APIs. If you see it as an important feature I'd encourage you to raise a change request.
1358 Wanted to understand the performance requirements that is applicable to arrangement revocation end point hosted at DR side. The CDR link https://consumerdatastandardsaustralia.github.io/standards/#performance-requirements does mentions 1000ms for revocation end point, but looks like this is specified for the data holder. Specifically the "nominated threshold" in the link is preceded by statements "In light of these considerations, the performance requirement for Data Holders is: 95% of calls per hour responded to within a nominated threshold The nominated threshold for each end point will be according to the following table:" which makes it look like being applicable to data holders. Hence wanted to clarify if the same would apply for data recipient as well? There are no performance NFRs imposed on ADRs. There is however relief for data holders in the situation where an ADR is providing a poor or unreliable service. In this situation the DH is required to take reasonable measures to notify the ADR of the consent withdrawal at the ADR's CDR arrangement revocation endpoint. Clearly there is a motivation for ADRs to provide a high quality service otherwise it impacts their customers.
1364 Currently the CDR Standards define that participants must support, at a minimum, the following ID Token algorithms: - For id_token_encrypted_response_alg: RSA-OAEP; RSA-OAEP-256 - For id_token_encrypted_response_enc: A256GCM; A128CBC-HS256 Is it the ADR or the DH responsible for supporting these encryption algorithms? Previous guidance on the selection of ID Token algorithms (Github Issue #97) defines that data holders may only support at least one of these algorithms and that the onus is on ADRs to support the many ID Token algorithms listed in the standards. Is this the current expectation? Can the CDR Standards or Github Issue please be updated to clarify the current position on this. Reference: Github Issue #97: https://github.com/ConsumerDataStandardsAustralia/register/issues/97 CDR Standards: https://consumerdatastandardsaustralia.github.io/standards/#client-registration The FAPI and associated Open ID Connect standards do not dictate which id token algorithms are supported. There is a wide variety of algorithms available and the more algorithms present in the CDR, the larger the implementation effort required by ADRs to ensure sufficient coverage. The CDS introduces the requirement to support a minimum set of algorithms. This reduces complexity and gives ADRs confidence that new data holders entering the ecosystem can be integrated with, minimising the number of platform upgrades required to support additional algorithms. Data holders are expected to support a minimum of one algorithm for each claim, data recipients are expected to support as many ID tokens as listed in the standards. The transition of requirements from the CDR Register design to the CDS does not articulate these requirements. I have raised the following change request to address this: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/491
1371 In relation to the changes introduced by Decision Proposal 216 2 questions: 1. How will the Data Recipients be notified of the claims that the Data Holder supports? Assuming a DH is not supporting optional claims 2. What data cluster language should a customer see in the authorisation if the DR requests both the profile scope and the customer.basic/customer.detailed scopes. Are the DHs expected to duplicate the name information? It would be a strange and confusing customer experience if we present to the customer: you are agreeing to share the following data: - Full name and title - Contact details - - Name and occupation - Contact details. It pretty much duplicates the name and contact details. Is it acceptable to merge the data clusters shown to the end user when appropriate? Eg in the case above only show: - Name, title and occupation - Contact details ** Question 1.** How will the Data Recipients be notified of the claims that the Data Holder supports? Assuming a DH is not supporting optional claims Response The claims the DH supports are advertised via their OpenID Discovery Document using the "claims_supported" parameter. This is documented in the OpenID Provider Configuration endpoint. Here's a non-normative example: "claims_supported": ["name", "given_name", "family_name", "acr", "auth_time", "sub", "refresh_token_expires_at", "sharing_expires_at"] Question 2: What data cluster language should a customer see in the authorisation if the DR requests both the profile scope and the customer.basic/customer.detailed scopes. Are the DHs expected to duplicate the name information? Response: This knowledge article articulates the below expectations for DHs where customer.basic/detailed scopes are requested : If the ADR ONLY asks for the basic scope (for either customer or accounts), the expectation is for the DH to only display the data language for the basic cluster. If the ADR ONLY asks for the detailed scope (for either customer or accounts), the expectation is for the DH to display the merged language. This is because detailed scopes include basic scope data. If the ADR asks for BOTH basic and detailed scopes (for either customer or accounts), the expectation is for the DH to display the merged language. Following the above expectations: If the ADR asks for the profile scope and the customer.basic scope, the expectation is for the DH to display: - Full name and title - Contact details - Name and occupation If the ADR asks for the profile scope and the customer.detailed scope, the expectation is for the DH to display: - Full name and title - Contact details - Name, occupation, contact details The standards require the specified language to be used and do not allow language for profile and customer scope requests to be merged. We will monitor the implementation of these standards and can reassess if consumer comprehension issues are identified.
1400 We have come across this confusion about whether we need to enable id permanence for the offsetAccountIds field in the Get Account Detail response. Currently, it's under the loan section in the response [1], "loan": { .. .. "offsetAccountIds": [ "string" ], .. .. }, As stated in the related question [2], it's mentioned that (accountId, transactionId, scheduledPayementId, and payeeId) are all subject to the ID permanence rules. So our confusion is that this string array of offsetAccountIds is also subjected to the ID permanence rules [1] https://consumerdatastandardsaustralia.github.io/standards/#tocSbankingloanaccountv2 [2] https://cdr-support.zendesk.com/hc/en-us/articles/360003943895-ID-Permanence-fields Each element in the offsetAccountIds field is intended to be normal accountId that can be used to access account details or transactions endpoints for instance. As such, it is explicit that these IDs have ID Permanence applied. Also, note the callout in the field description that only accountIds for accounts available under the current consent should be included.
1401 In the CDS specification we cannot find any indication to validate this x-fapi-auth-date as not a future date. The header reference is as follows [1], [1] - https://consumerdatastandardsaustralia.github.io/standards/#http-headers x-fapi-auth-date - The time when the customer last logged in to the Data Recipient Software Product as described in [FAPI-R-Draft]. Required for all resource calls (customer present and unattended). Not required for unauthenticated calls. That's because there can be two scenarios, 1. The date entered as x-fapi-auth-date can be in between actual customer last logged in time to the Data Recipient Software Product and the Current Time API call is taking place. 2. The date entered as x-fapi-auth-date can be ahead of Current Time API call is taking place. Since we are not maintaining actual customer last logged in time (Since its related ADR Software Product) as DH, first scenario cannot be validated properly. But in definition its a future date compared to the last logged time. Therefore, is it OK to only validate second scenario mentioned? here is no constraint in the upstream FAPI standards that preclude an "x-fapi-auth-date" in the future. Accounting for differences in clock time between client and server it is reasonable that an x-fapi-auth-date knowingly in the future should be treated with suspicion. Given there is no current constraint that precludes future dates it would not be acceptable to reject the request. Instead it would be at the DH's discretion whether they ignore this value. This would be a good change request for you to raise in regards to the scenario you've described so the ambiguity can be cleared up.
1409 For the DCR APIs, Register DAta recipient oAuth Client: https://consumerdatastandardsaustralia.github.io/standards/#register-data-recipient-oauth-client Should the "jwks_uri" in the Response payload be a URI pointing to Treasury, instead of "mock company"? The sequence of API working when making using of the JWT is: 1) Base64 decoding 2) use the "jwks_uri" in the decoded JWT to obtain JWT Public Key from Treasury / actual CDR server 3) verify JWT Signature using Public key The question refers to the "jwks_uri" in step (2) above. This seem to be verified by an existing question: https://cdr-support.zendesk.com/hc/en-au/articles/4411981337999-JSON-Web-Token-usage-for-Client-Authentication-and-Dynamic-Client-Registration And Process flow of from v1.5.0 of the Registration Flow: https://consumerdatastandardsaustralia.github.io/register/#registration-flows The registration response returns all the fields the data holder maintains against the registration. The jwks_uri field is documented in the Client Registration section of the Consumer Data Standards. I've extracted the jwks_uri description from the documentation. jwks_uri Required URL string referencing the client's JSON Web Key (JWK) Set [RFC7517] document, which contains the client's public keys This field belongs to the client, it is hosted by the data recipient, NOT the CDR Register. The CDS requires data recipients to host their own JWKS endpoint. Please refer to the Security Endpoints section of the standards. JWKS endpoints hosted by the CDR Register are used for SSA signature verification and outbound authentication when the CDR Register calls Data Holder Admin endpoints.

Useful Links

View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.