Decision Proposal 135 - November 2020 Consent Obligations: fixes and clarifications

[CDR-API-Stream]

The approved decision record is available here: Decision 135 - November 2020 Consent Obligations.pdf.

---

This decision proposal outlines a recommendation for changes to November 2020 consent obligations including the CDR Arrangement End Point and PAR based on community feedback and clarification of ecosystem transition from single extant consent to concurrent consent.

The consultation draft for this decision proposal is attached below:
Decision Proposal 135 - November 2020 Consent Obligations-v2.pdf

This document has been updated to fix formatting of the recommendations so they can be cross referenced to the noting paper and change history is included in the appendix. No changes have been made to the changes to be made.

Feedback is now open for this proposal. Feedback is planned to be closed on Wednesday 12th August 2020.

---

The original consultation draft for this decision proposal is available below:
Decision Proposal 135 - November 2020 Consent Obligations.pdf

This issue takes into consideration, amongst others, the issues raised here:

• Request For Clarification on CDR Arrangement ID standards-maintenance#254
• DELETE payload requirement for CDR Arrangement Endpoint standards-maintenance#278
• Deferral of PAR obligation date standards-maintenance#246
• Client authentication requirements for PAR standards-maintenance#277

NOTE: This Decision Proposal will not consider removal of solution components or changes to obligation dates. It seeks to correct issues with the standards which are currently in place for November 2020. Whilst some Data Holders may choose to seek extensions to their support of PAR for November 2020 this matter is handled through engagement with ACCC Compliance.

[CDR-API-Stream]

Further to this, a Noting Paper has been developed to assist participants with guidance on ecosystem transition. This is available here: Noting Paper 136 - November 2020 Consent Transition Guidance

[perlboy]

As per Division 8.3—Reviewing, developing and amending data standards and the modification of the standards in affect from August 1, can the DSB please outline whether this change is considered urgent or minor? Could the DSB also provide the link to the proposed draft located on "on the website of the Data Standards Body" (Division 8.3, part 8.9 subsection (2)c).

Finally, as specified in Division 8.3, part 8.9 subsection (2)d please extend the feedback period to the mandatory 28 days from draft publishing on the DSB website:

"invite submissions in relation to the consultation draft from interested members of the public to be made by a specified date that is no earlier than 28 days"

Given the original proposal for the CDR Arrangement Endpoint has no formal draft and feedback (only the precursor to the originally unpublished end-state) and is neither proven nor shown to be functional in external environments it seems unlikely this decision proposal could be considered minor with urgent being of the governments own creation.

[CDR-API-Stream]

Thanks for highlighting this @perlboy. The DSB has been conscious for some time of the date in the rules regarding the development and amendment of standards.

We are currently developing a noting paper, that will initially be tabled with the Advisory Committees for review, outlining our interpretation and alignment with the rules. At this stage we believe our current processes are in alignment with the rules but we will modify our process if we identify any inconsistencies.

In regard to your request to extend the consultation, we will not be doing this. The classification of changes is left to the Data Standards Chair under the rules. There is no explicit definition provided. Your rationale for rating this change as being significant is not one the DSB would be aligned with. We do consider this to be a minor amendment arising from implementation and detailed review of a previous consultation that was conducted over a number of months culminating in the v1.3.0 standard and we will be recommending this classification to the Chair.

[perlboy]

Thanks for highlighting this @perlboy. The DSB has been conscious for some time of the date in the rules regarding the development and amendment of standards.

I could easily dispute this "consciousness" since the change process adopted by the DSB seems to be one of regular reinterpretation when it suits.

We are currently developing a noting paper, that will initially be tabled with the Advisory Committees for review, outlining our interpretation and alignment with the rules. At this stage we believe our current processes are in alignment with the rules but we will modify our process if we identify any inconsistencies.

A noting paper is not enforceable and therefore does not achieve the "Data Standards Body is Accountable" principal outlined, also in a non enforceable noting paper in #50 (comment) which described the "Trial" for standards-maintenance which evolved into the defacto method without a formal decision proposal.

In regard to your request to extend the consultation, we will not be doing this. The classification of changes is left to the Data Standards Chair under the rules. There is no explicit definition provided.

The method that the DSB uses to classify changes has been requested many many times with either no answer or a suitably obfuscated answer that provides no further clarity.

Additionally, specifically with regard to this proposal, the DSB posted a clarification that explicitly stated:

No further changes to the standards which specify November compliance obligations will be considered unless requested changes are expressly marked as Urgent Change Requests and have the full support of all impacted Data Holders and ADRs during the consultation process.

Is this statement now invalidated?

Your rationale for rating this change as being significant is not one the DSB would be aligned with.

I didn't provide a rationale, I asked if it was urgent or minor and stated it seemed unlikely on the basis the changes relate to an unproven and unvalidated implementation with direct impacts on the information security profile of the ecosystem. While the Chair may have essentially dictator rights to define whatever he/she likes the rules also state a number of references to secure coding practices required of Recipients.

I'd be interested to hear how the DSB understands Data Recipients will comply with Part 2—Minimum information security controls, Part 2.2, Section 4:

Changes to the accredited data recipient’s systems (including its CDR data environment) are designed and developed consistent with industry accepted secure coding practices, and are appropriately tested prior to release into the production environment."

Within an environment which has no validated implementation worldwide.

We do consider this to be a minor amendment arising from implementation and detailed review of a previous consultation that was conducted over a number of months culminating in the v1.3.0 standard and we will be recommending this classification to the Chair.

For the clarity of those who just arrived and without the rose coloured glasses government representatives wish to see things through, this is a reference to DP #99 whereby the "CDR Arrangement Endpoint" was finalised in a decision proposal, post consultation and in the face of opposition from no less than 5 participants in the ecosystem. While there was some in principal support from one participant, the API in it's final state and it's name as "CDR Arrangement Endpoint" were introduced at the end and no further response was possible because collaboration was closed.

@CDR-API-Stream, as you've apparently decided this is minor and therefore consultation isn't required, why ask for feedback to it in the first place? There is already a precedent of declarations without consultations and the rules don't require you to.

Essentially, this leads me to ask, what's the point of bothering to provide feedback, beyond giving some glazed over impression of consultation?

[CDR-API-Stream]

Minor fixes document has been updated to correct formatting of the recommendations so they can be cross referenced to the noting paper and change history is included in the appendix. No changes have been made to the changes to be made.

[commbankoss]

Commonwealth Bank has the following points in response to this decision proposal:

1) Draft Standards for Review
In order to remove any assumptions and provide maximum delivery surety, Commonwealth Bank would like to review the resulting draft standards that integrate PAR/Arrangement API introduction. It is very difficult to overlay the current standards, verbal commentary, and multiple decision proposals in order to gain a complete view of the net impact of the current proposals is i.e. it is hard to know precisely which pieces of the current standards will be replaced by these decision proposals and which pieces will remain.

2) Proposed alternative migration approach
Commonwealth Bank believes that the transition from revocation API to arrangement API as it currently stands could be simplified. The principle will be to deal with existing consents using the July standard APIs and new consents using the Nov standards APIs. To this end we propose the following from November:

• All new consents issued have a cdr_arrangement_id associated and returned to the ADR;
• DHs keep token revocation endpoint untouched until all previous consents are expired or replaced (up to a year after cdr_arrangement_id introduction). This will ensure that all existing consents can be revoked using this API;
• DHs don’t modify existing consents (i.e. don’t allocate cdr_arrangement_id);
• In order to revoke consent, existing ADRs must use CDR Arrangement Revocation API for consents that have an arrangement ID, or the existing revocation endpoint if the consent does not have an arrangement id; and
• New ADRs must only use the CDR Arrangement Revocation API for revoking consent.

Pros:

• Minimize complexity of migration for both ADR and DH;
• Minimal implementation on DH side - no need to code logic to allocate cdr_arrangement_ids for existing consents and associated edge conditions;
• No cdr_arrangement_id hydration for ADRs; and
• No impact for ADRs entering ecosystem after November 1.

Cons:

• Data Holders need to keep existing token revocation API alive ‘as is’ for longer period; and
• Data recipients need conditional logic for handling revocation of consent (until all old consents are replaced or expired).

3) Proposed amendment to draft proposal
In the event that point 2 is not accepted, Commonwealth Bank recommend that ADHs support the existing revocation endpoint until Feb in order to give ADRs sufficient time to hydrate arrangement id’s for existing consents.

4) Strategic Roadmap
Commonwealth Bank requests the collaborative development of a strategic roadmap for consent management for the CDR. Without sufficient forward thinking, we are concerned the current changes will be tactical, and that there may be another set of significant changes to consent management required in the future. This would result in further regret spend for all participants, complicated transition periods and resultant high technical risk.

Data61 also indicated further alignment with FAPI 2. We would like to understand the full impact on consent design and the roadmap.

5) Notice for future changes to consent
Decision proposals indicate that further consent changes are expected in February 2021 and after.

Commonwealth Bank requests a 6-month notice for any “ecosystem breaking” changes after standards are finalised and transition period is agreed on.

6) cdr_arrangement_id represents a single consent
Commonwealth Bank would like to clarify that until consent renewal is supported: If a cdr_arrangement_id is supplied in the pushed authorization request then the cdr_arrangement_id returned upon successful completion of the authorization must be different than the one supplied in the request.

7) Feature discovery
Commonwealth Bank requests a clear dedicated discovery mechanism for all features. This will help avoid the introduction of unnecessary complexity and confusion for feature consumers.

E.g.: currently support for concurrent consent is inferred by the presence of cdr_arrangement_id in certain payloads. Additionally, error codes (404 or 422) are being used to discover which Data recipients’ revocation endpoints to use.

8) ADR Hosting of APIs
Commonwealth Bank continues to advocate for the position that ADRs should not need to host APIs, apart from jwks (ConsumerDataStandardsAustralia/standards-maintenance#247).

This position would have significantly reduced transition complexity for cdr_arrangement_id and PAR (along with other benefits outlined in the GitHub issue above).

[WestpacOpenBanking]

Westpac is supportive of the proposed changes. However, as we have already commenced build, it is important that they are finalised as soon as practicable.

In addition to the items discussed, the data standards body may wish to consider retaining the existing behaviour of the token revocation endpoint which revokes the consents associated with a token for a period of time before depreciating it in favour of pure token revocation. This is because there is a possible second race condition not currently identified in the standard where a consumer may attempt to revoke consent with a data recipient before that data recipient has obtained a cdr_arrangement_id might occur. Although in principle the cdr_arrangement_id is discoverable as per noting paper 136 sequence table item 3, this relies on all data recipients having built this functionality prior to any data holder release of items 2 and 4 in that sequence table.

In regard to the CDR Arrangement Revocation End Point we note that the sentence “For Data Holders, Data Recipients must be authenticated when they call this end point using a valid Access Token as specified in section 10.3 of [OAUTH2]" has been omitted from the definition whereas it was present for the CDR Arrangement Management End Point Definition. We note that client authentication still appears to be required in the endpoint table. Was the omission intentional? It is not clear whether the expectation is that a signed client assertion is to be placed directly into the authorization header, or whether the expectation is that an access token is used. It would make sense for the Data Recipient to present the access token to validate the identity of the user for whom the arrangement is being revoked.

[mannharleen]

Feedback from Origin Energy on DP-135

• Origin supports the use of concurrent consent, however we believe that implementation using arrangement-ids brings additional overheads (cost & complexity), both for DHs and ADRs

• We propose the use of having separate consents for endpoints/scopes based on sensitivity of data e.g. high, medium and low

• We also believe that having more number of consents (via arrangements) increases the chances of ADR and DH going out of sync, eventually leading to bad customer experience

• Finally, the default value for the refresh_token = 1 year i.e. for retaining the consent is a very long period. This may not be warranted to ADR use cases in the Energy industry. We propose to limit the refresh_token expiry to a shorted period based on the ADR use-case

[anzbankau]

ANZ agrees with @commbankoss and @WestpacOpenBanking in regards to keeping the existing behaviour of the token revocation endpoint for a transitionary period of time.

This means that ADRs can call either the new CDR Arrangement Management end point or existing revocation end point and have the same outcome expected. This will help enable the possible mixed implementations that will be in place until February 2021.

[CDR-API-Stream]

Thank you to everyone who's put forward views and proposals. Consultation on this decision proposal has been closed and feedback will be considered.

[CDR-API-Stream]

Consultation has been reopened temporarily by request

[NationalAustraliaBank]

1. NAB would like to suggest that Data Holders leave the existing Revocation endpoint (by AT/RT) in place post November (e.g. until February). This would allow 2 mechanisms for consent revocation (i.e. by Arrangement ID and by Refresh Token) and maintain the ADRs ability to revoke consents if the following scenarios occur:
   • The ADR hasn’t deployed the functionality to revoke by cdr_arrangement_id.
   • The ADR aren’t able to obtain cdr_arrangement_id for all their in-flight consents before 1 November.

2. With regards to the cdr_arrangement_id supplied to the PAR endpoint:
   • if the cdr_arrangement_id is not related to the client software product of this request, how should DH respond in this scenario? eg. invalid cdr_arrangement_id / 422 response?
   • if the cdr_arrangement_id is provided but it is expired, how should the DH respond in that scenario? eg. invalid cdr_arrangement_id/ 422 response?
   To ensure consistency across the DH’s implementations, NAB requests a full definition of all the scenarios where cdr_arrangement_id is considered invalid.

3. NAB would like to point out that it t has been difficult to assess the impact of this decision proposal’s net effect to the standards. To assist with this, NAB would like to request a draft of the ‘end state’ (inclusive of the updated standards) after the proposed changes relating to this Decision Proposal are applied. Some examples of ambiguity :

• the current standards (Revocation endpoint) define requirements for Data Holders and Data Recipient implementations. Decision Proposal 135 only refers to Data Recipient implementations. How do we interpret that? Ie if something isn’t mentioned in the decision proposal, does it mean it’s not changing?
• similarly, Question 1 of Github # 254 seeks confirmation around whether the standards will be updated around the cdr_arrangement_id claim in the ID Token. There is no mention of this in this Decision Proposal. How do we interpret this? Eg. Can we assume standards will be updated to remove per bullet # 2 in the following link: https://consumerdatastandardsaustralia.github.io/standards/#identifiers-and-subject-types?

4. Page 5 - Payload Conventions link on page 5 doesn’t open

5. Page 5 – Typo: 204 No Consent -> No Content

[CDR-API-Stream]

The consultation is now being closed again

[CDR-API-Stream]

Consultation has been reopened temporarily by request

[spikejump]

Perhaps our Question 5 posted on #136 should be posted here.

We are supportive of @commbankoss comment above for all the points raised with further consideration of point 6.

For point 6, Intuit would like to further analyse @commbankoss suggestion. Conceptually, supplying an existing cdr_arrangement_id implies one wants to do something with that specific arrangement and this is typically renew/extend existing consent. However, as pointed out by @CDR-API-Stream in this thread re-authorisation is not supported for November 2020. We question the value of supplying a cdr_arrangement_id for November given the case.

Supplying cdr_arrangement_id should be reserved for the use case of renew/extend existing consent and not be muddled with creating a new consent arrangement that may have got nothing to do with the previous other than allowing implicit revoke of previous consent.

We suggest

1. a clear definition for Nov 2020 on what happens when a cdr_arrangement_id is supplied in an authorisation call in conjunction with CX experience guideline specified. Without it there can be no consistent behaviour from DHs.

2. a more thorough discussion on how to support re-authorisation/renew/extend an existing consent for post November 2020.
   One of UK Open Banking consideration on this topic can be found here.

[CDR-API-Stream]

The consultation is now being closed again

[CDR-API-Stream]

The Data Standards Chair has approved Decision 135 constituting the changes to address November 2020 consent feedback. The decision record is available here: Decision 135 - November 2020 Consent Obligations.pdf

[CDR-API-Stream]

Hi @commbankoss thank you for providing feedback.

1. Draft Standards for Review
   In order to remove any assumptions and provide maximum delivery surety, Commonwealth Bank would like to review the resulting draft standards that integrate PAR/Arrangement API introduction. It is very difficult to overlay the current standards, verbal commentary, and multiple decision proposals in order to gain a complete view of the net impact of the current proposals is i.e. it is hard to know precisely which pieces of the current standards will be replaced by these decision proposals and which pieces will remain.

Thank you for the suggestion. The DSB will consider this for future decision proposals and standards changes.

2. Proposed alternative migration approach
3. Proposed amendment to draft proposal
   In the event that point 2 is not accepted, Commonwealth Bank recommend that ADHs support the existing revocation endpoint until Feb in order to give ADRs sufficient time to hydrate arrangement id’s for existing consents.

The second option has been adopted. This was broadly supported by data holders and data recipients.

• All new consents issued have a cdr_arrangement_id associated and returned to the ADR;

This proposal is not accepted. It is important to retrospectively include the cdr_arrangement_id for existing consents established prior to November. This ensures that re-authorisation of active consents along with changes to rules regarding separation of collection and use can be consistently applied to consents created prior to November as well as post-November. The first option proposed would mean existing consents cannot be renewed or amended were the Rules are changed to permit this.

• DHs keep token revocation endpoint untouched until all previous consents are expired or replaced (up to a year after cdr_arrangement_id introduction). This will ensure that all existing consents can be revoked using this API;

This change was accepted based on community feedback in the context of the transition to provide sufficient time for ADRs to obtain the cdr_arrangement_id for all active consents.

• DHs don’t modify existing consents (i.e. don’t allocate cdr_arrangement_id);

This change is not supported. See above.

• In order to revoke consent, existing ADRs must use CDR Arrangement Revocation API for consents that have an arrangement ID, or the existing revocation endpoint if the consent does not have an arrangement id; and

This is the current position with the expectation that from 1st of November all consents are presented with an arrangement ID and all ADRs actively update their consents with an arrangement ID

• New ADRs must only use the CDR Arrangement Revocation API for revoking consent.

This is expected to be the case however this is contingent on when the ADR goes live. Assuming that an ADR goes live after November this would hold true. To avoid impact to ADRs based on when DHs will deploy November obligations, technical discovery mechanisms were used to decouple capability discovery from obligation requirements. ADRs should use the discoverability mechanisms to determine the individual DH supportability. The standards already state that the ADR must use the CDR Arrangement Revocation API if it is available.

4. Strategic Roadmap
   Commonwealth Bank requests the collaborative development of a strategic roadmap for consent management for the CDR. Without sufficient forward thinking, we are concerned the current changes will be tactical, and that there may be another set of significant changes to consent management required in the future. This would result in further regret spend for all participants, complicated transition periods and resultant high technical risk.

Data61 also indicated further alignment with FAPI 2. We would like to understand the full impact on consent design and the roadmap.

The DSB will be consulting on the work plan and transition approach for technical changes to accomodate a longer term target state. Workshops addressing the consumer experience for amending consent are planned for September.

5. Notice for future changes to consent
   Decision proposals indicate that further consent changes are expected in February 2021 and after.

Commonwealth Bank requests a 6-month notice for any “ecosystem breaking” changes after standards are finalised and transition period is agreed on.

Thank you this input is appreciated. With Maintenance Iteration 4 (#134), care has been given to provide future planning and implementation time in regards to changes.

6. cdr_arrangement_id represents a single consent
   Commonwealth Bank would like to clarify that until consent renewal is supported: If a cdr_arrangement_id is supplied in the pushed authorization request then the cdr_arrangement_id returned upon successful completion of the authorization must be different than the one supplied in the request.

This is not accepted. The cdr_arrangement_id should be continued across consent authorisations where the ADR provides the cdr_arrangement_id via the PAR request object as a logical continuation.

7. Feature discovery
   Commonwealth Bank requests a clear dedicated discovery mechanism for all features. This will help avoid the introduction of unnecessary complexity and confusion for feature consumers.

E.g.: currently support for concurrent consent is inferred by the presence of cdr_arrangement_id in certain payloads. Additionally, error codes (404 or 422) are being used to discover which Data recipients’ revocation endpoints to use.

This suggestion is reasonable and the DSB will consult on a solution in future maintenance iterations. It is worth noting that this is the pattern the DSB has started to establish.

8. ADR Hosting of APIs
   Commonwealth Bank continues to advocate for the position that ADRs should not need to host APIs, apart from jwks (ADR Revocation Endpoint standards-maintenance#247).

This position would have significantly reduced transition complexity for cdr_arrangement_id and PAR (along with other benefits outlined in the GitHub issue above).

Whilst this has been raised in other maintenance issues and change requests, the current approach stands based on meeting the CDR Rules and privacy safeguard requirements.

[CDR-API-Stream]

Hi @WestpacOpenBanking thank you for providing feedback.

In addition to the items discussed, the data standards body may wish to consider retaining the existing behaviour of the token revocation endpoint which revokes the consents associated with a token for a period of time before depreciating it in favour of pure token revocation. This is because there is a possible second race condition not currently identified in the standard where a consumer may attempt to revoke consent with a data recipient before that data recipient has obtained a cdr_arrangement_id might occur. Although in principle the cdr_arrangement_id is discoverable as per noting paper 136 sequence table item 3, this relies on all data recipients having built this functionality prior to any data holder release of items 2 and 4 in that sequence table.

This change has been adopted and it is noted it was broadly supported.

In regard to the CDR Arrangement Revocation End Point we note that the sentence “For Data Holders, Data Recipients must be authenticated when they call this end point using a valid Access Token as specified in section 10.3 of [OAUTH2]" has been omitted from the definition whereas it was present for the CDR Arrangement Management End Point Definition. We note that client authentication still appears to be required in the endpoint table. Was the omission intentional? It is not clear whether the expectation is that a signed client assertion is to be placed directly into the authorization header, or whether the expectation is that an access token is used. It would make sense for the Data Recipient to present the access token to validate the identity of the user for whom the arrangement is being revoked.

Data recipients would follow the requirements in the Client Authentication section of the data standards.

[CDR-API-Stream]

Hi @mannharleen thank you for providing feedback.

• Origin supports the use of concurrent consent, however we believe that implementation using arrangement-ids brings additional overheads (cost & complexity), both for DHs and ADRs

Arrangement ID is a minor change that should not introduce complexity. It is required to support re-authorisation and amending consent.

• We propose the use of having separate consents for endpoints/scopes based on sensitivity of data e.g. high, medium and low

This change is not supported. Whilst this is the model in the UK it does not align with the pattern established in the CDR and is not part of the problem to solve for this decision proposal.

• We also believe that having more number of consents (via arrangements) increases the chances of ADR and DH going out of sync, eventually leading to bad customer experience

This is part of the CDR Rules and the data standards are being brought in line.

• Finally, the default value for the refresh_token = 1 year i.e. for retaining the consent is a very long period. This may not be warranted to ADR use cases in the Energy industry. We propose to limit the refresh_token expiry to a shorted period based on the ADR use-case

Refresh token duration is within the control of the DH. Consent duration is defined by the sharing_duration established as part of authorisation between the ADR and DH. The expiry time of the refresh token is not a determinant of the duration of consent.

[CDR-API-Stream]

Hi @anzbankau thank you for providing feedback.

ANZ agrees with @commbankoss and @WestpacOpenBanking in regards to keeping the existing behaviour of the token revocation endpoint for a transitionary period of time.

Thank you. This change has been adopted.

[CDR-API-Stream]

Hi @NationalAustraliaBank thank you for providing feedback.

NAB would like to suggest that Data Holders leave the existing Revocation endpoint (by AT/RT) in place post November (e.g. until February). This would allow 2 mechanisms for consent revocation (i.e. by Arrangement ID and by Refresh Token) and maintain the ADRs ability to revoke consents if the following scenarios occur:

Thank you. This change has been adopted and it is noted it was broadly supported.

With regards to the cdr_arrangement_id supplied to the PAR endpoint:

• if the cdr_arrangement_id is not related to the client software product of this request, how should DH respond in this scenario? eg. invalid cdr_arrangement_id / 422 response?

In this instance it would be an oAuth error response invalid_request https://tools.ietf.org/html/rfc6749#section-4.2.2

• if the cdr_arrangement_id is provided but it is expired, how should the DH respond in that scenario? eg. invalid cdr_arrangement_id/ 422 response?

In this instance it would be an oAuth error response invalid_request https://tools.ietf.org/html/rfc6749#section-4.2.2

NAB would like to point out that it t has been difficult to assess the impact of this decision proposal’s net effect to the standards. To assist with this, NAB would like to request a draft of the ‘end state’ (inclusive of the updated standards) after the proposed changes relating to this Decision Proposal are applied.

Thank you for the suggestion. The DSB will consider this for future decision proposals and standards changes.

Page 5 - Payload Conventions link on page 5 doesn’t open
Page 5 – Typo: 204 No Consent -> No Content

Thank you. These have been corrected.

[CDR-API-Stream]

Hi @spikejump thank you for providing feedback.

We are supportive of @commbankoss comment above for all the points raised with further consideration of point 6.

This is not accepted. Please refer to response to @commbankoss's feedback above.

For point 6, Intuit would like to further analyse @commbankoss suggestion. Conceptually, supplying an existing cdr_arrangement_id implies one wants to do something with that specific arrangement and this is typically renew/extend existing consent. However, as pointed out by @CDR-API-Stream in this thread re-authorisation is not supported for November 2020. We question the value of supplying a cdr_arrangement_id for November given the case.

For Nov it will provide an indication to the DH to revoke the existing consent and establish a new consent. As the Rules are anticipated to allow re-authorisaition and amending consent in future, the cdr_arrangement_id will take on further importance.

Supplying cdr_arrangement_id should be reserved for the use case of renew/extend existing consent and not be muddled with creating a new consent arrangement that may have got nothing to do with the previous other than allowing implicit revoke of previous consent.

If the new consent has nothing to do with the current one, an ADR should establish a separate consent and explicitly revoke the current consent if required.

We suggest a clear definition for Nov 2020 on what happens when a cdr_arrangement_id is supplied in an authorisation call in conjunction with CX experience guideline specified. Without it there can be no consistent behaviour from DHs.

Could you please elaborate on the issue you see here?

a more thorough discussion on how to support re-authorisation/renew/extend an existing consent for post November 2020.

Thanks for this feedback. This has been answered under point 4 of feedback from @commbankoss

[spikejump]

@CDR-API-Stream Thanks for the response above.
We are unaware of any clear guidance or Rules on what DHs will present back to the users when a cdr_arrangement_id is supplied back to the DH. It is assumed the DHs will present the same CX experience as they do today. In which case, there may be a few situations that happen.

1. [Happy Path] The customer supplies the correct bank side "customer ID" that was used to authorise the consent previously and the customer selects same accounts as previously. Consent is effectively renewed/extended. Then ADR can continue to service the customer as before. In the UK, this renew/extent scenario, has a very simple CX where customers simply confirms the existing consent without re-selecting accounts etc.
2. [Unhappy Path] The customer supplies the correct bank side "customer ID" that was used to authorise the consent previously but now selects completely different accounts than previously. (Why? We don't have the answer but we've seen this many times.) The ADR now may not be able to service the customer as before. For example, ADR needs to delete CDR data because the previously consented accounts are no longer selected. Customer is now unhappy because his/her data is now lost when he/she did not intend for it to happen.
3. [Unhappy Path] The customer supplies a different bank side "customer ID" than what was used to authorise the consent previously. The outcome is similar to above as all accounts will be completely different than previously. (And yes this happens in real life unfortunately.)

The unhappy path above can be avoided if careful consideration is specified via CX and spec.

While reading the above @CDR-API-Stream responses, we have one more query on the response to @NationalAustraliaBank. IN there, a couple of the answers mentioned

In this instance it would be an oAuth error response invalid_request https://tools.ietf.org/html/rfc6749#section-4.2.2

Can @CDR-API-Stream clarify the HTTP response code that is meant to be returned in such a case? Presumably 400 is appropriate and there are no other 4xx possibilities?

[CDR-API-Stream]

Hi @spikejump,

Can @CDR-API-Stream clarify the HTTP response code that is meant to be returned in such a case? Presumably 400 is appropriate and there are no other 4xx possibilities?

RFC6749 specifies 400 (Bad Request) would apply for error response invalid_request:

5.2. Error Response

The authorization server responds with an HTTP 400 (Bad Request)
status code (unless specified otherwise)