-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (15th of July 2021)
When: Weekly every Thursday at 3pm-4.30pm AEST
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
- Primary Australia: +61-2-9338-2221
- Quick Dial: +61-2-9338-2221,,1650705270##
- Other Global Numbers: https://treasuryau.webex.com/cmp3300/webcomponents/widget/globalcallin/globalcallin.do?MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&serviceType=MC&serviceType=MC&serviceType=MC&siteurl=treasuryau&siteurl=treasuryau&siteurl=treasuryau&apiname=globalcallin.php&apiname=globalcallin.php&apiname=globalcallin.php&rnd=6124483603&rnd=6124483603&rnd=6124483603&tollFree=0&tollFree=0&tollFree=0&ED=1403111402&ED=1403111402&ED=1403111402&needFilter=false&needFilter=false&needFilter=false&actappname=cmp3300&actappname=cmp3300&actname=/webcomponents/widget/globalcallin/gcnredirector.do&actname=/webcomponents/widget/globalcallin/gcnredirector.do&renewticket=0
- Meeting Number/Access Code: 165 070 5270
- 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 [email protected] 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.11.0 Published | Link to change log here |
Standards | Version 1.11.0+ | Planned for End of July 2021 |
Maintenance | 7th Maintenance Iteration Closed | Retrospective MIRO Board |
Maintenance | 8th Maintenance Iteration Commenced | Invitations to come for the 14th of July 2021 |
Maintenance | Decision Proposal 202 - Banking Maintenance Iteration 8 | Link to consultation |
DSB Newsletter | To subscribe to DSB Newsletter | Link here |
TSY Newsletter | To subscribe to TSY Newsletter | Link here |
TSY Newsletter | 14th of July 2021 | View in browser here |
DSB Newsletter | 9th of July 2021 | View in browser here |
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 183 - Purpose Based Consents | Link to consultation |
Consultation | Decision Proposal 186 - Engineering Support | Link to consultation |
Consultation | Decision Proposal 191 - Retailer to AEMO InfoSec Profile | Link to consultation |
Consultation | Decision Proposal 200 - Action Initiation Framework | Link to consultation |
Consultation | Normative Standards Review (2021) | Link to consultation |
CDR Implementation Call | Today - Noting Paper 200 - Action Initiation Framework walk through | Link to Consultation - Noting Paper 200 |
CDR Implementation Call | Next week - 22nd of July 2021 - Rules V3 Walkthrough with the Treasury Rules team | Presentation and Q&A next week |
Workshop | DSB & TSY 27th of July - Action Initiation | Eventbrite Registration Link |
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 | CTS | Andrea Gibney |
ACCC | Onboarding | Jonathon Ingle |
DSB | CX Standards | Michael Palmyre |
DSB | Technical Standards - Banking | Mark Verstege |
DSB | Technical Standards - Energy & Engineering | Mark Verstege |
Topic: Walkthrough of Noting Paper 200 - Action Initiation Framework
Speaker: Mark Verstege, Michael Palmyre
Link to consultation: Link to Consultation - Noting Paper 200
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 |
---|---|---|
875 | Seeking clarification on the requirement relating to provision of the Secondary User Instruction service. Is the Secondary User Instruction service to be provided as an online service for the Account Holder to manage via their Consumer Dashboard or can the service to create, manage and revoke Secondary User Instructions be maintained by the Data Holder within their core banking system on request from the Account Holder? In the "CDR Rules - Compilation with mark-up against previous version.docx" document under Rule 1.15 (5) the service is referenced as an "online service" while Rule 1.13 (1)(e) drops the reference to "online" and simply requires "a service". |
Please see the below response developed with the ACCC in answer to your query about online access to the secondary user instruction service. Please refer to the current version of the Rules which is available here. Rule 1.13(1)(e) requires a data holder to provide a service to account holders to make or revoke a secondary user instruction. As you note, that service need not be online but we encourage data holders to provide this service online in addition to any offline mediums that may be provided. Rule 1.15(5) requires data holders to provide further functionality through an online service to account holders in relation to secondary users, including the ability to withdraw a secondary user instruction (r 1.15(5)(b)(ii)). We note that allowing the withdrawal of a secondary user instruction through an online service will satisfy the requirement at rule 1.13(1)(e)(ii) (withdrawing a secondary user instruction under rule 1.15(5)(b)(ii) has the same effect as revoking a secondary user instruction under rule 1.13(1)(e)(ii)). If the data holder provides a consumer dashboard to an account holder, rule 1.15(7) requires that the functionality referred to in rule 1.15(5) is included in the account holder’s consumer dashboard. |
907 | In the CDR Standards v.1.11.0 regarding Error Codes, can you please confirm if the majors AND the non-majors are required to implement this by February 2022? | That is correct. |
913 | According to the guidelines in the AU CDR spec, the request object to the Authorization server should be sent with the mandatory scope attribute indicating the scopes requested by the ADR. A combination of following scopes can be used. OIDC Scopes: openid (mandotory), profile (optional) authorisation scopes : bank:accounts.basic:read, ... Please give your clarification on following questions based on the supported combination of values for the scope attribute as constrained by the CDS AU spec. 1. In article, https://cdr-support.zendesk.com/hc/en-us/articles/900002116163?input_string=allowed+scope+combinations+for+the+request+object%27s+scope+attribute+passed+in+the+authorization+request, the following is stated regarding open-id scope, "The only mandatory scope is the openid scope that is required by the OpenID Connect Core normative standard. All other scopes are optional, however, the absence of any scopes is not particularly useful." Based on the above statement, how should the authorization server handles a request object containing only 'open-id' as the scope ? Should that be rejected or accepted by the authorization server? 2. In article, https://cdr-support.zendesk.com/hc/en-us/articles/900003906386? input_string=allowed+scope+combinations+for+the+request+object%27s+scope+attribute+passed+in+the+authorization+request, the following is stated regarding open-id scope, "The current consequence is that the profile scope can only be accepted if it is in association with one of the CDR customer read scopes. That is, the profile scope should be included only where the consumer also consents to the basic customer data cluster" Based on the above statement, is it completely acceptable if the authorization server enforces a validation logic to reject a authorization request having 'profile' scope without one of common:customer.basic:read or common:customer.detail:read in the request object ? |
Question 1: Based on the above statement, how should the authorization server handles a request object containing only 'open-id' as the scope ? Should that be rejected or accepted by the authorization server? Answer 1: It is a valid request and must not be rejected. Note also an ADR may ask for scopes not supported by the DH in which case the DH would authorise only the scopes they support and the authorisation response would provide the subset of scopes. Question 2: Based on the above statement, is it completely acceptable if the authorization server enforces a validation logic to reject a authorization request having 'profile' scope without one of common:customer.basic:read or common:customer.detail:read in the request object ? Answer 2: No. However based on the current guidance, there is a lack of supporting CX data language standards for ADRs to support the 'profile' scope. The compliant approach for the data holder would be to accept this. |
915 | Can DHs reject a request from ADR which does not have any data scopes defined? | If the ADR sends an authorisation request that does not include the openid scope, it must reject the request. If the ADR includes the openid scope and it also includes one or more scopes that are unsupported or unrecognised, the data holder should ignore those extraneous scopes. The FAPI specification (5.2.2) states the data holder shall return an authorisation request with the subset of scopes that were granted. It is conceivable the data holder may authorise a request with only the openid scope and no other valid scopes. That authorisation is of limited practical value but it would allow the client to check the authorisation response and accordingly make a decision if they are insufficient for their value proposition. CDR Support Portal Article |
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
View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.