ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 13th of October 2022
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.
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.
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.
By participating in the Consumer Data Right Implementation Call you agree to the Community Guidelines. These guidelines intend to provide a safe and constructive space for members to discuss implementation topics with other participants and members of the ACCC and Data Standards Body.
| Type | Topic | Update |
|---|---|---|
| Standards | Version 1.19.0 Published on 13th of September 2022 | Link to change log here |
| Standards | Version 1.20.0 is being staged | View the branch here |
| Maintenance | Maintenance Iteration 12 | Last met on 14th of September 2022 Agenda for the Final meeting here |
| Maintenance | Decision Proposal 259 - Maintenance Iteration 12 | Changes, meeting notes and updates for the iteration can be found here |
| Maintenance | Maintenance Iteration 13 underway | Met 12th of October 2022 and the agenda for the meet is here |
| Maintenance | Decision Proposal 272 - Maintenance Iteration 13 | Changes, meeting notes and updates for the iteration can be found here |
| TSY Newsletter | To subscribe to TSY Newsletter | Link here |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| TSY Newsletter | 28th of September 2022 | View in browser here |
| DSB Newsletter | 7th of October 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 |
| Noting Paper | Noting Paper 255 - Approach to Telco Sector Standards | Link to consultation |
| Noting Paper | Noting Paper 258 - Independent Information Security Review | Link to consultation |
| Consultation | Decision Proposal 264 - Telco Invoice Payloads Feedback closes: 17th of October 2022 |
Link to consultation |
| Consultation | Decision Proposal 265 - Telco Billing Transactions Payloads Feedback closes: 17th of October 2022 |
Link to consultation |
| Consultation | Decision Proposal 266 - Telco Balance and Usage Payloads Feedback closes: 17th of October 2022 |
Link to consultation |
| Consultation | Decision Proposal 267- CX Standards Telco Data Language Feedback closed: 15th of September 2022 Thanks to those who provided feedback on DP267 by 15th September. With the v5 rules out for consultation, the DSB will leave this issue open for comments while considering existing feedback and developing version 2 of DP267, which is expected to be published for consultation in October. |
Link to consultation |
| Survey | The Data Standards Body invite the CDR Community to provide feedback on the different Engineering Tools and platforms. | Link to survey |
| Survey | 2022 - 2023 CDR Implementation Call | Link to survey |
Provides a weekly update on the activities of each of the CDR streams and their stream of work
| Organisation | Stream | Member |
|---|---|---|
| ACCC | CDR Register | Emma Harvey |
| ACCC | CTS | Andrea Gibney |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking, Infosec | Mark Verstege |
| DSB | Technical Standards - Energy | Hemang Rathod |
| DSB | Technical Standards - Telecommunications | Brian Kirkpatrick |
| DSB | Technical Standards - Register, Engineering | James Bligh |
Playback of survey results:
What do you dislike about the CDR Implementation Call?
DSB: WE will be moving to using Microsoft Teams to host the CDR Implementation Call. Hopefully this will improve the experience of the CDR Implementation Call. This is driven
DSB: attendance will always be a challenge. We do appreciate the time people commit to participating in the Call each week.
DSB: an idea here is to only have Streams with updates on the Call. A pre-written or recorded update is very labour intensive to create and we’re not sure this will have equivalent benefit
DSB: The Consumer Data Right spans multiple sectors. There are often changes, announcements and impacts which are relevant to multi sector participation. The DSB see potential issues with the dissemination of key pieces of information and announcements. Not to mention those who would be required to attend 3 or more Calls per week.
DSB: the ACCC and DSB work closely with the other agencies
DSB: thanks for the feedback, moving forward we have a couple of ideas here: once a quarter walkthrough the DSB Future Plan to familiarise everyone with the content and plans. Post the Maintenance Iteration: play back or present the changes and FDOs to the Call.
DSB: this is a tricky one. We are aware of everyone’s time dedicated to participating in the Call; however, we do not want to stifle nor censor anyone wishing to ask questions. We would encourage everyone to be aware of the audience and exercise their own best judgement. The current approach is to alternate between the Chat questions and those who wish to ask directly on the Call. Introducing a limit on questions would prove problematic to police and enforce week to week. We would ask that overly complex scenario based questions be sent to the CDR Support Portal.
DSB: we think this dovetails in with the ‘Limit the number of questions asked per person’ one of the challenges with the question is often how
DSB: we agree and appreciate this feedback. As an idea we would like to start using a ‘register’ here: https://github.com/ConsumerDataStandardsAustralia/standards/wiki/CDR-Implementation-Call---Questions-on-Notice to capture those questions taken on notice. However, we will need the Community’s assistance here for those questions not in the chat function. We will ask for these to be sent to the CDR Support Portal so we can capture the wording, context and examples accurately.
DSB: See ‘FDO changes as Updates’.
What do you value most about the CDR Implementation Call?
Do you have an idea or suggestion for an addition to the CDR Implementation Call?
DSB: we will do our best to increase the number of presentations.
DSB: very open to conducting these. For now, if you are interested in presenting please reach out to [email protected] and we can work through your topic and time slot.
DSB: we will include a Questions taken on notice register to start capturing these. We do not want to run through these on a weekly basis in the interests of everyone’s time.
DSB: we don’t provide meeting minutes. The task would be onerous, and we would need to increase the time between calls to properly minute the call.
DSB: historically we had pre-submitted questions. This proved problematic due to a backlog from prior weeks, CDR Support Portal and pre-submitted. We dropped this option for now to try and increase capacity. The interim suggestion here is to submit these to the CDR Support Portal.
DSB: agreed. We will see to play back changes coming from the Maintenance Iterations and point out future dated obligations.
DSB: agreed. Feedback from the 12th Maintenance Iteration mirrors this we should playback changes from the Maintenance Iteration.
DSB: we include written up dates in the weekly DSB Newsletter and the ACCC include theirs with the TSY Newsletter.
DSB: this is not something we are exploring right now. The CDR Implementation Call would not scale to be run three or more times a week. There is potential for Q&A to be duplicated, changed, or mistaken between sessions. Further, for those who span cross sector it would require an increased amount of time to engage with the Consumer Data Right: of which there are already a lot of demand for. For now we will hold off making any changes here.
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.
In regards to topics for questions, we ask the participants on the call to consider the Community Guidelines when posing questions to the subject matter experts.
| Ticket # | Question | Answer |
|---|---|---|
| 1683 | If a DH only supports CDR Arrangement JWT method and they don’t provide claims as per Self-Signed JWT Client Authentication specified in v1.17, will this impact anything during the transition period till 15th Nov? Or do they need to go back to form parameter method during this period ? | You can send the JWT to the ADR and this will be compliant with the standards. The inclusion of the cdr_arrangement_id as a form parameter was only included for backwards compatibility. If you are not sending the additional JWT claims for Self-Signed JWT client authentication, this is also ok, but we do recommend that Data Holders include these additional claims as soon as is practical. |
| 1525 | If I rephase my question, does it enable the ACCC Regulatory Guidance Team to provide some guidance to potential ADR applicants? This question has been raised to us on numerous occasions by ADR applicants, and has the potential to increase the number of ADR applicants exponentially. Independent legal advice that has been obtained by potential ADR applicants has been inconsistent, with most advice stating that they should submit an application to the ACCC to see whether it will pass the accreditation process. However ADR applicant’s do not want to incur the cost of a potential application that fundamentally will not pass the accreditation process. **New question ** If an ADR applicant submits an application for accreditation to the ACCC whereby the data flow shows data derived from CDR data is to be provided back to the consumer onscreen (e.g. within a screen in a web application) and the consumer is then required to take an action in the ADR applicant's system (e.g. clicking a next step button) to push that data to another process within the ADR applicant's systems (and if no action is taken by the consumer then the data is deleted), and the ADR applicant has documented in their submission that the data is now deemed customer data and therefore not included in the boundary of their CDR data environment (because they have documented in their CDR data environment boundary that the customer data is no longer considered data derived from CDR data because the customer has processed an action independent of the ADR applicant), would it be possible for this ADR application to be accredited (noting that they would need to demonstrate all the usual ADR application requirements)? |
An application for accreditation will be assessed in accordance with the requirements set out in Part 5 of the CDR Rules. The CDR accreditation guidelines provide further information about how applications are assessed. ADRs may disclose a CDR consumer’s CDR data to the CDR consumer for the purpose of providing existing goods or services in accordance with rule 7.5(1)(c). This includes when the disclosure relates to the good or service requested by the CDR consumer or the disclosure is incidental to the provision of goods or services requested by the CDR consumer. Once CDR data is disclosed to the CDR consumer its status will depend on the consent given and the goods or service being provided. Whether or not it remains part of the CDR data environment after a subsequent action will depend on the facts of each case. Section 56AK of the Competition and Consumer Act 2010 states that an accredited person is an ADR if they hold CDR data (or any CDR data from which it was directly or indirectly derived) that was disclosed to it under the consumer data rules. This means that as long as the data has been disclosed to the ADR under the CDR rules they will continue to be an ADR of the CDR data for as long as they hold it. This is not dependent on where in their system the ADR holds the data or whether the consumer has agreed to the data being held in a different capacity. We note that the objectives of the CDR include enabling consumers to consent to their data being disclosed safely, efficiently and conveniently, including ‘to accredited persons for use subject to privacy safeguards’ (s56AA(a)(ii) of the Act). We consider that ADRs must take into account CDR consumers’ expectations of how their CDR data will be treated once it has been disclosed to an ADR, in light of this objective. In general, data used within the confines of the good or service consented to by the consumer under the CDR remains data subject to the CDR framework ADRs should not attempt to structure their CDR data environments so as to avoid CDR obligations. ADRs must treat CDR data in accordance with Schedule 2 of the CDR Rules and the relevant data standards. The ACCC cannot provide compliance advice specific to an individual scenario and we encourage you to seek independent legal advice if you require further information about your compliance obligations. |
| 1705 | This was the discussion that came up today in the CDR implementation call. I thought it might be easier to post this via email as there are already a couple of tickets on this matter. The below information may be helpful in the analysis. We refer to ticket 1661 per below and have further queries on the response provided Additional question: The response to ticket 1661 highlights when a data holder indicates that they no longer approve CDR data relating to that account being disclosed to that accredited person in response to a consumer data request made by that secondary user, all data sharing should stop for that accredited person on behalf of the secondary user. It further states that this is different to Joint accounts where approvals are managed at each authorisation. The above is not aligned with the secondary user guidance published in Jan 2022 ( link below refer to page 3) : https://www.cdr.gov.au/sites/default/files/2022-03/CDR-Secondary-users-in-the-banking-sector-FAQs-published-28-March-2022.pdf The guidance indicates “ Where an account holder indicates that it no longer approves of a particular data sharing arrangement, sharing must cease under that arrangement” This appears to indicate specific authorisations and not a blanket stop of data sharing with an ADR under other authorisations. Further the Rules don’t state anywhere that the Account Holder can reinstate sharing after they remove their approval as per 4.6(a)(ii) for a particular ADR as the secondary instruction is still valid for other ADR’s. So, if we follow the response to ticket #1661 once the account holder removes their approval as per the below interpretation, the SU will never be able to share data with the DR again ever. As such we are unsure if the response to the ticket #1661 is well rounded from a consumer experience perspective. |
Thank you for your patience while we have reviewed this issue and the guidance provided. We have updated our knowledge article Ceasing secondary user sharing to address questions raised by participants. |
| 1717 | AH - Account holder DR1 - Data Recipient 1 DR2 - Data Recipient 2 SU1 - Secondary user 1 SU2 - Secondary user 2 C1 & C2 - consents authorised by SU1 to DR1 C3 & C4 - consents authorised by SU1 to DR2 C5 & C6 - consents authorised by SU2 to DR1 C7 & C8 - consents authorised by SU2 to DR2 Considering the rules 1.15(5)(b)(i) and 4.6A(a)(ii) [Question 1] As a DH do we need to provide option to the AH to no longer approve CDR Data sharing granted by SU1 to DR1 alone? This would require DH to stop data sharing from C1 & C2 only. [Question 2] OR the above stopping of data sharing is required to be performed at a consent level (e.g. C1)? Awaiting for a quick response as we are in the middle of secondary user implementation for our multiple Data Holder clients. |
Thank you for your patience while we have reviewed this issue and the guidance provided. We have updated our knowledge article Ceasing secondary user sharing to address questions raised by participants and addresses the questions you have raised in your ticket. |
| 1722 | Can I request attention to this, as it may require substantial redesign to our solution? Thanks in advance. I refer to to this article that was recently published: https://cdr-support.zendesk.com/hc/en-us/articles/5465006047375 Our current solution is along this line: Peter(Account owner) Andy(sec user) – created 1 sharing arrangement to ADR X with 3 accounts. • Peter can stop/cease any of the 3 accounts, or all 3 accounts under the 1 sharing arrangement with the ADR. Therefore, our solution allows for rejection to CDR sharing arrangement based on account alone. Whereas I think your article has arrived with this understanding: Peter(Account owner) Andy(sec user) – created 3 separate sharing arrangements to ADR X . • DH needs to provide a function where Peter can indicate that Andy cannot share with ADR X . • Therefore all 3 separate sharing arrangements with ADR X that Andy has shared must now stop. • I’m supposing that also meant that Andy cannot initiate any new sharing arrangement for the accounts (that he's sec user of) with ADR X from then on. • It must not impact Peter's sharing arrangements for the accounts to the same ADR X. And it seems like your article requires it to reject based on ADR to Sec User relation. Per how we understood this rule 4.6A : The data holder must not disclose requested CDR data that relates to a particular account to the person who made the request if the account is shared by a secondary user, and for part (ii) (actual text): "the account holder has indicated, through their consumer dashboard, that they no longer approve CDR data relating to that account being disclosed to that accredited person in response to consumer data requests made by that secondary user; or" as long as we provide the mechanism (i.e. our original solution) for an account owner to reject disclosure of his/her account(s) that are shared by the secondary user in response to THOSE SPECIFIC CDR made, would we not have sufficient covered the requirement set out by the rule? i.e. if Andy made 3 CDR with Peter's accounts, and DH dashboard allows for Peter to reject those shares individually, would it not be sufficient in that sense? OR do ACCC/DSB understanding means that this "rejection based on ADR to Sec User relation" is a mandatory function to provide by the DH? And by providing that functionality, it may be very likely to be a breach of the rule? |
Thank you for your patience while we have reviewed this issue and the guidance provided. We have updated our knowledge article Ceasing secondary user sharing to address questions raised by participants and addresses questions you have raised in your ticket. |
| 1724 | these are 2 follow up questions on https://cdr-support.zendesk.com/hc/en-us/articles/5465006047375 1. Must Data holders allow the account holder to stop sharing for all accredited Data Recipients (irrespective if the Secondary User has active consents with them or not) or only for data recipients with which the SU has at least one active consent 2. Is the stop share for a specific Data Recipient revisable or permanent? |
Thank you for your patience while we have reviewed this issue and the guidance provided. We have updated our knowledge article Ceasing secondary user sharing to address questions raised by participants and addresses questions you have raised in your ticket. |
| 1726 |
https://cdr-support.zendesk.com/hc/en-us/articles/5465006047375 The guidance clarifies the expectation of Data Holders regarding "the account holder has indicated that they no longer approve CDR data relating to that account being disclosed to a particular accredited person" As this clarification changes the previous interpretation of a number of Data Holders, and additional development and deployment will be required to meet this obligation (currently solution allows the account holder to simply stop a secondary users sharing arrangements on a arrangement by arrangement basis, or block the account from being shared in all existing and future arrangements) - we assume that each Data Holder will need to apply for an exemption for not being able to provide this functionality by 1st November. Also, there is no guidance provided on unblocking - i.e.. allowing an account holder to unblock a particular ADR from a secondary user/account block previously setup. Is this type of functionality expected to be available? |
Thank you for your patience while we have reviewed this issue and the guidance provided. We have updated our knowledge article Ceasing secondary user sharing to address questions raised by participants and addresses the questions you have raised in your ticket. |
| 1732 | The recent guidance issued on the Secondary User and withdrawing the authorisation for that consent. The previous concept of account holders managing the authorisations on accounts to be shared have to date been built around the principle that the authorisation management is managed at individual account level within data sharing arrangements and not by entire consent specific to individual ADRs, to support the Joint account included in consents where the other accounts are included and owned solely by the requestor. The recent guidance seems to diverge from that principal and introduces a new concept. Could you help me to understand the rationale behind this. Additionally, wouldn't the ability for an account owner removing the authorisation from a particular consent, meet the obligation to stop the sharing with a specific ADR. | Thank you for your patience while we have reviewed this issue and the guidance provided. We have updated our knowledge article Ceasing secondary user sharing to address questions raised by participants. It provides the policy rationale behind this functionality. We note that this functionality is different to the functionality provided for under the joint account provisions, as the words of the legislative provisions provide for different outcomes. |
| 1734 | Captured from the CDR Implementation Call 15/09/2022: In relation to Secondary Users, main account holder blocking sharing for one ADR. Should the AH be able to block sharing for ADRs for which the SU has active consents, or for any ADR the SU has ever provided a consent or for all the ADRs active in the market, irrespective if the SU has ever provided a consent. When blocking the ADR should we blocking at Software Product level, Brand level or ADR level. |
Thank you for your patience while we have reviewed this issue and the guidance provided. We have updated our knowledge article Ceasing secondary user sharing to address questions raised by participants and addresses the question you have raised in your ticket. |
| 1736 | Captured from CDR Implementation Call 15th of September 2022: As per the article https://cdr-support.zendesk.com/hc/en-us/articles/5465006047375-Ceasing-Secondary-User-Sharing , consider an account holder has stopped a specific secondary user sharing secondary user data with a particular accredited person Q: Can this secondary user add the same account back into the arrangement via consent amendment? |
Thank you for your patience while we have reviewed this issue and the guidance provided. We have updated our knowledge article Ceasing secondary user sharing to address questions raised by participants and addresses the question you have raised in your ticket. |
| 1737 | Thank you for your guidance on secondary users. Upon review we have further queries which we hope you are able to help us resolve. "Rule 1.13(1)(e) requires a data holder to provide a service an account holder can use to make or withdraw a secondary user instruction. This service may be provided online or offline; however, we encourage data holders to provide this service online as rule 1.15(5) requires the data holder to provide an online service to the account holder with a variety of functions related to secondary users once there is a secondary user on an account. In accordance with rule 1.15(7) if the data holder provides a consumer dashboard for the account holder, the online service must be included in the consumer dashboard. The functionality required by rule 1.15(5) includes: • the online service must allow the account holder to stop sharing 'in relation to a particular ADR' in response to requests made by a particular secondary user, in accordance with 4.6A(a)(ii) (rule 1.15(5)(b)(i)) and • the online service must allow for the withdrawal of a secondary user instruction (Rule 1.15(5)(b)(ii)). Rule 4.6A(a)(ii) explains that a data holder must not disclose requested CDR data to the person who made the request, if the request was made on behalf of a secondary user of the account and the account holder has indicated that they no longer approve CDR data relating to that account being disclosed to a particular accredited person in response to consumer data requests made by a particular secondary user." Our point of view: What does “no longer approve CDR data relating to that account being disclosed” mean, for example 1. is the act (by an account holder) of revoking a single authorisation (aka consent, aka sharing arrangement) originally created by a secondary user, deemed implicit instruction to remove all authorisations (for that account, shared with that ADR, created by that secondary user), or 2. is it expected that there is an explicit function, separate to authorisation revocation whereby, for example, an account holder is presented with a list of ADRs with active sharing arrangements created by a specific secondary user, so that they can specifically “disable” the ADR in question, thereby revoking all sharing arrangements for that secondary user, for that account for that ADR, or 3. either? In the event the secondary user has permission to share more than one of the data holder’s account and has created an authorisation consisting of more than one of these account, what effect does 1. or 2. above have on the authorisation, i.e. is the entire authorisation(s) revoked or does the authorisation remain active but only the account in question “paused”? In the case of 1 or 2 above, is the action only relevant for current authorisations or are future authorisations also prohibited. If the latter, is this reversible and how? Further we request guidance on: • Whether statements in relation to ‘a particular ADR’ are meant to be interpreted at an ADR or Software Product level. • How this aspect of the rules interacts with ADRs with different accreditation models, such as the representative model. "The dashboard must allow the account holder to stop a specific secondary user sharing secondary user data with a particular accredited person. If, for example, the specific secondary user has 3 authorisations with a particular accredited person, then the sharing of secondary user data must stop for all 3 authorisations." As above; we would be grateful for UX guidance to help understand the implementation approach required |
Thank you for your patience while we have reviewed this issue and the guidance provided. We have updated our knowledge article Ceasing secondary user sharing to address questions raised by participants and addresses questions you have raised in your ticket. |
| 1745 | Raised on the CDR Implementation Call 29th of September 2022: Where an existing CDR consumer has an open/active account with a data holder, in this example, an ADI, and the consumer has subsequently withdrawn or made inactive, their data sharing arrangement, is the data holder still obligated to action a consumer's data correction request? If we take the same example however, focus only on closed accounts, and subject to Schedule 3 of the CD Rules, Provisions Relating to the Banking Sector, clause 3.2(5) on Closed Accounts, does a data holder still need to action the consumer's request for data correction? Action was for ACCC to take away with (potential( Privacy Safeguard impacts/consultation required. |
The obligations arising from Privacy Safeguard 13 apply to a data holder where a consumer has requested that a data holder correct their CDR data, and the data holder was earlier required or authorised to disclose it under the CDR Rules. The obligations are not limited to open/active accounts, or those with a current authorisation in place. For guidance on steps that a data holder must take in actioning and responding to any PS 13 correction request, see Chapter 13 of the OAIC’s CDR Privacy Safeguard Guidelines. |
| 1730 |
https://cdr-support.zendesk.com/hc/en-us/articles/900001781826-Expected-behaviour-for-scopes-presented-by-an-ADR-to-a-DH The article supports the change with the following justification : As described, the DH would allow the request but accept the client registration with the subset of scopes the DH supports per RFC7591. However, RFC7591 does not state that a subset of scopes should be supported during Dynamic Client Registration. My engineering team will not make this change without support from the standards. Do you know if this decision was supported by standards, and if so, where is that documented? |
the workaround you are implementing for DHs at present seems reasonable whereby the OP supports all scopes the ACCC accredits ADRs for (e.g. banking + energy) so that the DH can continue to allow ADRs to update client registrations. The reason for DHs ignoring unsupported scopes is due the the way the ACCC Register operates. It issues the SSA signed using the ACCC CA cert incorporating all scopes an ADR is accredited for. The way the CDR Rules are expressed it means that once a data recipient is accredited, they are accredited for all sectors and hence all scopes across those sectors: right now that is banking and energy. In future that will include telecommunications etc. To ensure that an ADR can successfully manage their client registration with a DH when they present all scopes (noting that the ADR cannot control what scopes the CDR Register generates for it), the DH needs to facilitate the client registration updates without rejecting the request. |
| 1762 | Is it mandatory to support PKCE for the Hybrid flow? | yes it is because of the upstream FAPI 1.0 Advanced requirements. The profile requires the use of PKCE when using PAR. See FAPI 1.0 Advanced 5.2.2 (18). See: https://openid.net/specs/openid-financial-api-part-2-1_0.html#authorization-server |
| 1763 | Is the nbf claim mandatory for both the client_assertion and the PAR request object? | "nbf" is a required claim in the request object since 16th of September 2022. In other words, the ADR must send the "nbf" in accordance with the FAPI 1.0 (Final) Advanced profile section 5.2.2 (17). "nbf" doesn't really make sense for client authentication in our circumstances because we want the authorisation server to authenticate the client immediately. |
View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
 |