Decision Proposal 183 - Purpose Based Consents

[CDR-API-Stream]

This decision proposal provides introduces the concept of Purpose Based Consents. This is a concept that could be used to address a number of existing issues raised by CDR participants but may also address the anticipated complexity of expansion across many sectors.

This decision proposal does not contain a recommendation. It only introduces the concept of Purpose Based Consents for feedback. No change to the standards will be considered to the standards as a result of this consultation without further consultation being conducted.

The proposal for consultation is attached below: Decision Proposal 183 - Purpose Based Consent.pdf

Feedback is now open for this proposal. Feedback is planned to be closed on Friday 23rd July 2021.

[RobHale-RAB]

This concept of purpose-based CDR scopes seems to be one worthy of further consideration. It would be useful, helpful, and in line with the original intent of enhancing consumer convenience. It also makes optional much of the cognitive load associated with having to review and consider multiple data clusters when providing authorisations. It could enable a more streamlined, simplified consent process for those comfortable to take that path. The comments below are provided to flag areas that might require further thought and consideration, but overall, this is a direction I believe we should explore further and perhaps prove out in a sandpit environment with some willing participant organisations.

1. For certain use cases, such as those where a full financial picture is required, It would help if the scope of a single consent could extend across multiple DHs somehow. This would benefit consumers by removing the repetitive process of selecting multiple DHs and authenticating and authorising data sharing with each. I recognise this is not how consent currently works but perhaps something to strive towards. Today, consumers do not bank with one institution so this problem will compound over time.
2. We will need to work out how to avoid a huge shopping list of potential scopes in the pre-consent flow. At present, 5 data clusters for banks is OK, but once we add other sectors there will be more, and with purpose-based scopes there could be many more, perhaps hundreds. Maybe that’s OK, maybe that just becomes a UX issue. Is there a desirable limit? Should there be a limit? How do we avoid similar scopes with overlapping elements? A definite early use case for consideration would be a Loan Application consent which if expanded showed all the data elements needed.
3. Page 2, Challenges, 2nd bullet talks to aggregation potential. The risk here is that aggregation as part of the scope isn't consistent with ADR expectations. For example, a lender might classify transactions in a unique manner as part of their responsible lending policy. Could we agree on a universal approach? Is it possible to align with industry and regulatory expectations and standardise how this is done? Perhaps here we could again lean on standards such as LIXI which may have already defined such attributes and the required granularity?
4. Standardising aggregation and insights might have negative consequences. It might take away some innovation and differentiation that benefits consumers. It might also remove revenues from insights businesses and slow down endpoint responsiveness for endpoint ingestion from DHs, with consequent damaging of time-critical use cases. Perhaps it would be better for ADRs to absorb this processing time while other details are collected?
5. Page 4, Credit Application Consent - it would be great if we could somehow also resolve the issues associated with one-time nature of this consent that have become apparent since July 2020. Can we consider a definition of one-time to mean successful collection of all data from all DHs for all accounts in support of the agreed scope? That might mean the ADR needs to make multiple attempts to collect the data over an extended period of time. A refined definition might therefore be "sucessfully collect the data, and all of the data, once only".
6. Bullet 3 in this section talks to summarised data. The way we do this today at Regional Australia Bank is to categorise expenses by type and make a determination about which expenses might be considered discretional. That helps identify potential capacity to service a new debt. The theory here is that everyone lives to their income. If the service only returned aggregated amounts, it might not demonstrate capacity or enable it to be considered and validated.
7. This will be contentious but... should we consider a “give me everything” banking scope? While we must honour the data minimisation principle and minimise risk and data sharing, some (informed) consumers may not be worried. Effectively with screen-scraping today already authorise "here you go, have everything" and let the recipient entity determine what is required. Getting “everything” could be really powerful. If tied into an explicit consent then arguably it is still a marked improvement on alternate methods today. Should we let the consumer decide?
8. Page 6 - Identity Confirmation - Another potentially contentious suggestion, but how would we feel about building a KYC or KYB consent? Rather than identifying a person, could an ADR decide they were comfortable to rely upon work already recently undertaken by a bank for instance? The bank could provide a complete package of ID mechanisms used to validate the ID. Maybe this is a chargeable endpoint because the bank incurred cost developing this and the ADR costs are reduced if they are able to rely upon it?

[damircuca]

Hey People

Thanks for brining this issue to attention, this is something I have been pondering for a while and believe is a real flaw in the current implementation. The inability for a ADR to specify what type of accounts they require access to, and further empowering the consumer to select the account has the ability to break every single use case.

Here are some examples where the current implementation breaks use cases:

• Setup a Direct Debit Payment - if a consumer is required to select the account from where they would like to setup a direct debit payment from, it is implied the consumer knows (technically) which accounts support direct debit capability - so nothing would stop them from selecting a term deposit account, mortgage account, saver account etc. from where DD payments can not be applied to.

• Loan Application - the consumer has the option to pick / choose which accounts to share - unbeknown to the ADR what was NOT selected or supplied thus assuming they have the complete financial picture of the customer.

• PFM setup - the customer has the option to pick their mortgage account and unselect all other accounts, the PFM app will most likely be of little value.

In reality, only the ADR (delivering the value) fully understands the use case being implemented, and the type of information they require in order to carry out the use case.

The proposal put forward is one possibility, but the concern I have is that it is focused on Use Cases (purposes) which is something the Data Holder should not have to be concerned about - ultimately the data / services they supply should be use case agnostic - and the focus should be on the data / entities instead. Speaking practically, I can confirm that the number of use cases never ceases and every time we think we have just about seen them all, another would appear.

I think the solution is simple - consumer should NOT have the ability to select the accounts they wish to share. This should be a configuration (part of request) the ADR sends through during the auth flow. The consumer can select it or not.

Providing the consumers the ability to select accounts, implies that they are aware of the code / decisions / logic the ADR has put in place and is well versed with all the intricacies of their app, understand the rules of bank products (which one can you direct debit from etc) and thus has the cognitive ability to select which accounts to share.

[JTRlaw]

I would be interested to understand how removing a consumer's ability to select accounts will ensure each and every consumer data request meets the object of consent in the Rules to be voluntary and express and informed and specific as to purpose?

[RobHale-RAB]

Although I think this comment by JTRlaw https://github.com/ConsumerDataStandardsAustralia/standards/issues/183#issuecomment-873689710 was in response to @damircuca's point, I do have a view on it...

The current consent process under CDR is already very specific and includes a prescribed information flow that ensures the consent is indeed voluntary, express, informed and specific to purpose. The authorisation step (the last bit in the consent flow) is where accounts are selected. Prior to that, the consumer has been informed about the purpose of the consent, selected data clusters and agreed to data being collected for a specific purpose before authenticating with the data holder.

So, although I'm sure it won't be for everyone, letting an accredited data recipient (in a regulated ecosystem with civil penalties for non compliance) access whatever account information is deemed necessary for the stated purpose may not actually be contrary to the objective in the rules - and it could remove a lot of cognitive load for consumers who may not (and may not want to) understand how a credit provider determines their eligibility.

@damircuca's point is not dissimilar to point 7 in my earlier comment - https://github.com/ConsumerDataStandardsAustralia/standards/issues/183#issuecomment-864657552

[JTRlaw]

Thank you robhale-rab for identifying for me where a 'give me everything' fits into the flow.

[SelenaLiuEA]

Hi All,

EnergyAustralia’s feedback is that we have real questions around the benefits of Purpose based consents and have a few initial concerns. Specifically:

• We agree with the comments made by Damir - “In reality, only the ADR (delivering the value) fully understands the use case being implemented, and the type of information they require in order to carry out the use case. The proposal put forward is one possibility, but the concern I have is that it is focused on Use Cases (purposes) which is something the Data Holder should not have to be concerned about - ultimately the data / services they supply should be use case agnostic - and the focus should be on the data / entities instead”

• Purpose based consents would need to establish the specific data required by ADRs for a certain use case. This will be difficult to determine with many ADRs likely to have different views on what data is required for a specific use case. The effect of needing to select the relevant data for a use case, could also have the unintended effect of closing off potential innovation compared to where ADRs were to consider the use case from a “blank slate” and select data the data themselves.  

• Purpose based consent could also make understanding the consent process more difficult for customers. The status quo of consenting to disclosure of specific data sets is a straight forward concept to understand. Limiting consent to this format will help to build consistency for what a customer can expect when engaging with the CDR to provide consent. Introducing Purpose based consents is a more complex concept as a customer will not necessarily know what data disclosure is required for a specific purpose. This needs to be made clear, and introduces another layer of complexity.

• The DSB refers to Purposed based consents supporting the data minimisation principle, because Purpose based consents can support collecting only a subset of the data set. While we understand the DSB’s logic, we note that the data minimisation principle would still apply to protect against excessive usage for unnecessary data that is collected. That is, the data minimisation principle also applies to usage of collected data such that an ADR cannot use data beyond what is reasonably needed for the ADR’s service.

• Purpose based consents will increase cost and complexity for Data Holders - not only in responding to data requests but also in the authorisation dashboard requirements. While there would be limited Purpose based consents initially, we expect that this could multiply over time.

• We also question how Purpose based consents will translate in the AP to AP disclosure context and Action Initiation context. With regards to Action Initiation, the complexity for the customer will be in making it clear what different actions are required for a specific purpose, when this will not always be apparent to the customer.

[anzbankau]

Tailoring the data request to a specific purpose can be solved technically through fine grained consents. Fine grained consents will also be needed to address the action initiation framework and hence are already an inevitable part of the CDR roadmap. We propose evolving the standards to accommodate action initiation, in line with global standards (i.e. FAPI2), thereby also accommodating purpose based consents.

Having fine grained consents means that custom data scopes are not required to be implemented by ADHs. ADRs can configure the data required to meet a specific purpose, based on their requirements and adhering to the data minimisation principle. This removes the burden from data holders of having to curate specific data sets, based on the defined purpose - a substantial impost. This also provides the flexibility to ADRs and control to customers, without being constrained by coordinating technical changes with the data holders and associated leads times. Fine grained consents would make the ecosystem simpler and more flexible for ADRs who would be free to create more complex, context-specific purpose based consents.

[RobHale-RAB]

Some good points from @anzbankau and @SelenaLiuEA on the need to consider additional burden imposed on DHs...

One of the challenges with fine-grained consents under the current rules is that bundling of clusters is not permitted in the CX, so consumers still need to select all required data clusters individually. A 'select everything' option is not allowed.

This is counter-intuitive where the use case can only work if everything is selected. We've found consumers find this frustrating - ie "why are you giving me the option to only select some boxes, yet only let me proceed if I select them all?"

Maybe a partial solution here is to permit 'select all' when the ADR has curated a bespoke dataset requirement that comprises numerous fine-grained endpoints?

Important to remember that while there would absolutely be additional DH burden resulting from purpose-based consents , CDR is not intended to help DHs, it's designed to liberate data to benefit Australian consumers, drive innovation and increase competition...

BTW, there are still some options like KYC/B which I think would still make great candidates for purpose-based consents. These could increase efficiency and reduce costs for DHs - for example when onboarding a customer that has switched from another provider. So it works both ways if DHs are willing to become ADRs...

[DimitriSty]

General feedback:

In principle, pre-packaging data sets per requirement seems sensible. Xero agrees the consumer would likely have a smoother and easier to understand consent process. It would help achieve the data minimisation principle and possibly build confidence in the regime. Implementation however would be complicated for data holders.

Xero questions whether the outcomes justify the complexity. The benefits appear to be incremental improvements to benefits likely to be realised under the CDR. We are concerned that this recommendation would be better considered after the regime is operational. A better understanding of the CDR use case and consumer patterns would help inform purpose based consent that is targeted and measures return on investment.

Hypothetical example - Tax return:

The ‘Tax Return’ hypothetical example is a good example to think through purpose based consent. In a business context, most small businesses will have ongoing engagement with advisers. Advisers will assess historical business data for a host of reasons, including advising on strategy and execution and securing finance. Granting a purpose based consent for the purpose of a tax return will be irrelevant for most small businesses, as an adviser will already have access to its data.

However, for a small cohort of sole traders and micro-businesses, this may be a reasonably useful feature. In this case, the investment of the data holder to enable this purpose based consent is very unlikely to be justifiable, for the benefit of a handful of businesses. A better allocation of resources would be in optimising APIs to ensure rich data.

We acknowledge the paper references industry bodies, but Xero would like to reinforce the importance of engaging with these groups. Only through these groups can a satisfactory understanding of use cases be determined to model purpose based consent requirements, and therefore its implementation.

[PratibhaOrigin]

Thanks for providing us the opportunity to comment on this topic.

The concept of purpose-based consent (including the scenarios outlined) may be a value-added functionality for consumers. From a security perspective, it means we don’t share more data than what is needed for a specific purpose. This is a good thing. But the capability to allow purpose-based consent will be costly and technically more challenging will likely also increase the delivery timeline as well– especially for the Data Holders who are the source for the data and are responsible for managing the authorisation process for the release of the data.

Some issues that need to be considered: • If the purpose-based consent is voluntary - additional registers and checks will be needed on both ADR and Data Holder side to determine if a requested participant in the CDR has this capability or not. This will be added implementation cost. • Due to the partial sharing nature, extra governance and reporting would need to be defined for the Data Holders and ADRs. • Energy retailers are not the only Data Holders in the energy sector. It is being proposed that AEMO be defined as a secondary Data Holder where certain data is obtained from AEMO (i.e., NMI standing data, DER and meter date). Purpose based consent will be even more complicated as retailers need to confirm if the partial data is requested from AEMO (i.e., impacting those APIs) or after receiving data from AEMO, only partial data from AEMO is being shared. This is not a preferred option. Hence, the impacts to AEMO APIs and implementation need serious consideration. • Requiring consent for the release of partial data sets raises complexities as 1) to whether the consumer has the knowledge to understand what they are consenting too and 2) the reasons for why and how the partial data sets will be used. Consent needs to be clear and partial consent adds a layer of complexities. If the DSB continue to explore purpose-based consent, there should be high level scoping that has its own CX language but is mapped to a series of existing scopes and no new APIs (i.e., whether there is an option for consumers to further select data subsets within a data cluster).

Regarding the granular authorisation, in the context of a specific purpose, it could provide valuable control to the allowing for more granular consent to be provided by the consumer and in previous consultations and papers for energy sector, we have requested to second level consent for sensitive data like concession and hardship information which are currently part of account API which can be viewed as a granular authorisation.

Further, we are keen to understand current use cases from banking where requests from customers to share the data partially and how many times a partial data request was made by consumer (do they have any data?). OR how many times a consumer declined or decided not to proceed with a CDR request as the partial data sharing for a specific purpose was not available. This data will be helpful in cost benefit analysis.

[AusBanking2]

The proposed solution put forward in DP-183 refers to a principle of ‘Purpose-based consent’. Purpose Based Consents are a way to encode all of the required dimensions and granularity for a specific use case. Unfortunately, this specificity leads to a consequent loss in flexibility. DP-183 highlights read-only use cases which are not currently covered; however, the same principles and requirements are even stronger to enable read-write access.

Taking the example of the Tax Return, DP-183 specifies a number of dimensions that would be sufficient for a Consumer to consent, and for a Bank to identify and return that data as a one-time request. This is the equivalent of creating a specific printed consent form.

However, that same Consumer would need a new Purpose Based Consent to be defined in order to repeat the request for the following year, and every year after. To extend the analogy, ‘Tax Return 2021’ would require a new form which is different from ‘Tax Return 2020’, and may have different items on it that a Consumer would need to be aware of. There is a risk that trying to centralise all possible use cases restricts potential innovation by participants, and in fact reduces the levels of visibility and control that consumers have over their data.

The alternative, multi-dimensional fine-grained consent is more similar to providing a mechanism to select appropriate options for printing out a consent form, which provides full control and visibility to both Consumer and CDR participant. Consumers experience with fine-grained consent can be more easily managed within CX guidelines. The main point is that without adopting fine-grained consent within a dynamic structure, the underlying technology will not support wider and evolving use cases, including payments.

The proposal which is purpose-based consents may simplify the consumer experience, but it will require new purpose definitions for EACH purpose and will not allow innovative expansion of use-cases.

The current approach being suggested by Decision Proposal 183 implies the DSB is will represent every possible combination and dimension of access into static scope representations. The ABA seeks clarity on this interpretation.

The ABA recommends instead that the DSB consider adopting RAR as a generic mechanism for enabling multi-dimensional fine-grained consent to be requested and instead focus efforts onto the standardization of the dimensions of data access that the CDR wishes to enable within an Australian RAR envelope.

For further detail, we refer readers to the ABA’s submission on DP 182 – InfoSec Uplift for Write (to be published 23-July).

[commbankoss]

Commonwealth Bank has reviewed the proposal and has the following feedback:

• Most of the current and future use cases can be solved using fine-grained consents. While Purpose-based consents may help a portion of use cases on the data recipient side, it will significantly complicate both Data Recipient’s and Data Holder’s implementations. Fine-grained consents (commonly achieved using Rich Authorization Requests) give the added benefit of enabling data requests to be limited to certain time periods and also specific data sets, which in turn leads to the ability to provide customers more control over their data sharing through more explicit and concise data sharing.
• Purpose-based consents would be detrimental to user understanding and related control of data sharing, as bundling data sets makes it difficult for consumers to understand which data sets are shared. In contrast, fine-grained consents enable the desired functionality without requiring increased CX complexity. For example, an ADR may create a template to request data of the last financial year, tell the user plainly they are collecting all their financial data of the last financial year, and avoids the requirement for customers to tick boxes and change parameters. Fine-grained consent doesn’t necessarily mean complex CX for users. There is still space to innovate and simplify user experience.
• Centralized management of purpose bundles will further reduce innovation for data recipients. From a governance perspective, it will be difficult to anticipate and manage the various use cases in the pipeline whereas fine-grained consent gives the ultimate flexibility to data recipients to support both known and unknown use cases.
• Purpose based consents would require custom changes to bank’s security infrastructure. Purpose-based consents further complicate the consent model from an individual dataset model to a hybrid model, where some scopes enable access to a single API resource and others to bundles. There is also a concern that a growing number of purpose-based consents/scopes would result in an increase of custom-built API infrastructures, ultimately defeating the purpose of the modular resource API approach currently used.

As a result of the above points, Commonwealth Bank, both as Data Holder and Data Recipient, is opposed to purpose-based consents, and recommends the DSB focus on the development of fine-grained consent which will be required as the target state to enable the future CDR.

[WestpacOpenBanking]

Westpac recognises the challenges highlighted in the Decision Proposal and fully supports the objective of uplifting the standards to better support use cases and the principle of data minimisation without compromising customer experience or control; however, Westpac does not support the Purpose Based Consents proposal as described in the decision paper (the “scopes-based” approach), but instead recommends that the Rich Authorisation Request (RAR) model, as discussed in Decision Proposal 182, be introduced as a priority.

While we believe that the RAR standard is likely to fully meet the objectives of data minimisation and desired efficiencies, we acknowledge that Purpose Based Consents may bring further uplifts in a mature ecosystem, and recommend any development of the concept be postponed until the ecosystem has evolved, to allow a better assessment of broader consumer usage and frictions that may be remediated without compromise of the principles of transparency.

We are concerned that the proposed Purpose Based Consents approach:

• Will create a new standards-making burden at a time of growing complexity with the introduction of Action Initiation and v3 of the Rules;
• Will constrain innovation by prescribing in the standards which data elements could be used for which purposes;
• Increase the cost of participation through deviation from vendor product support for international standards – this is in opposition to comments made in DP182 which expressed a desire to be better aligned with international standards;
• Be constrained by limitations of data aggregation algorithms covered by the CDR;
• Introduce aggregated constructs consumers may understand less than the current set of Accounts, Transactions, Balances etc.
• Is unlikely to extend to support the functionally required by "write", as it is unsuitable for conveying, and subsequently querying the status of a specific payment authorisation (i.e. to pay a specified amount in a specified currency from a specified account to a specified account).
• Holds considerable risk and uncertainty in outcomes, as issues such as optionality, discovery, complexity and subsequent time and effort to implement may result in underwhelming outcomes that come at the expense of the implementation of foundational standards such as Rich Authorisation Requests.

We also have the following ancillary remarks on the paper:

• We believe that consent purpose should be used only to further refine data scopes, not expand them, and that both the purpose and the data scopes should be publicly available to enable consumer transparency.
• Credit Application Consent example: Different credit providers have different policies with regards to how they treat certain types of transactions and different rules on how they attribute transactions on joint accounts. The summarisation would require the use of proprietary information derived by the ADR and therefore not covered by the CDR.
• Limited Online Contact Details example: It's unlikely that this will be a valuable scenario as there is limited, isolated value for a customer to complete a CDR flow over typing or autocompleting four fields, a common feature of most operating systems and browsers.
• Identity Confirmation example: Identity verification, even at lower levels, should be the purview of the Digital Identity initiative and not the CDR. Attempting to add it to CDR without fully considering the risk model and policy implications and coexistence with other initiatives underway is not advised.

Responses to the questions asked in the paper:

Would Purpose Based Consents be a valuable tool for the CDR regime for specific scenarios?

We strongly support both the principles of fully informed consent and of data minimisation and we don’t believe that Purpose Based Consents, as described in this document, is the right solution to the identified challenges. As stated above, we believe that this proposal:

• Creates an unequal playing field favouring the status quo rather than innovation.
• Makes innovation difficult, even within the defined purposes, because having even one extra field added to a defined purpose will likely lead to a lengthy lobbying and standards making process.
• Will increase the cost of oversight to the regulator to ensure initial and ongoing accreditation for the purpose is consistent with the consumer experience of the ADRs accredited software product.
• Will introduce aggregated constructs consumers will understand less than the current set of Accounts, Transactions, Balances etc.
• Overloading the common usage of scopes, with is what is essentially a purpose-based policy scope over underlying data scopes: increases the risk of security incidents and increases the cost of entry into the ecosystem by requiring customisation to security products to comply.

What purposes would be worth considering for application of the concept of Purpose Based Consents?

We do not recommend the application of the proposed model for Purpose Based Consent for reasons previously stated.

Would voluntary, or optional, scopes of this type be of value where the standards defined a series of Purpose Based Consents but data holders would not be required to implement them all?

If the opportunity for purpose based consents lies within the most common and valuable scenarios, it is unclear how the value would be realised if they were not made mandatory.

Should purpose-based consents be explicitly governed so they can only be used for defined use cases with set terms?

Purpose Based Consents as proposed must be governed to remove the risk of consumer confusion, and an outcome that is less transparent than explicit consent to the underlying data scopes.

Should data recipients register for, or be accredited for, specific purposes that allows consumers to look up these registrations in a central purpose register or marketplace?

ADRs could be accredited for any purpose based consents as part of their software product registration, in addition to the specific data scopes that their software product requires to fulfil that purpose.

Would there be value in exploring the concept of a simplified form of this concept where a high-level scope has its own CX language but is mapped to a series of existing scopes and no new APIs are created?

No. Scopes should be used to convey API permissions, not CX language. Extending standard making to CX language for specific purposes will constrain innovation and struggle to keep up with new consumer devices and technologies people will interact with now and in the future.

Should the introduction of rich authorisation be considered alongside the concept of purpose based consent and, if so, what types of more granular consent should be considered?

As noted above we recommend that Rich Authorisation Requests should be implemented instead of, not in conjunction with Purpose Based Consents using scopes as described in this document. Rich authorisation requests allow the benefits of Purpose Based Consents to be achieved without introducing a new standards-making burden, constraining innovation, or further deviating from international standards.

[NationalAustraliaBank]

NAB does not support the introduction of purpose-based consents at this time.

Purpose-based consents would require a catalogue of data sets to be defined and maintained for each specific use case. This introduces a range of technical and operational complexities into the ecosystem. For example, how would agreement be reached on what data is required for a specific use case? How would proliferation of purpose-based consents be prevented? Participants would have to introduce complexity in their solutions to maintain these custom data sets and co-ordinate the roll-out of these changes. Customers would be exposed to a different customer experience between use cases that leverage purpose-based consents and regular consents. If the purpose-based consents were voluntary for DHs, ADRs would have to build solutions to determine whether a DH supports this capability or not and as a result, customers would be exposed to differing customer experiences depending on whether their DH supports purpose-based consents.

We believe that multi-dimensional fine-grained consents (which can also be used to address the requirements of action initiation framework as described in our response to Github # 182) provides for the purpose-based consent capability in a technically and operationally simpler and more flexible, standardised way. Under this model, ADRs will be able to formulate any combination of data sets required to meet their specific use cases.

[gurchan-AGL]

Thanks for the opportunity to contribute.

Further to the points already outlined by @anzbankau, @SelenaLiuEA and @DimitriSty. Its unclear how “Purpose Based Consents” would operate/scale if the customer job-to-be-done had a cross industry scope (i.e. including banking, energy and telco) such as moving home.

Introducing “Purpose Based Consents” may be premature based upon the current adoption and limited real world use cases operationalised within CDR today. AGL believe deferring this would be prudent to allow for further customer validation (i.e. need) and whether the implied complexity it introduces would offset the believed benefit.

[biza-io]

Biza.io believes that this discussion is intrinsically linked to the discussions contained within DP182, NP200 and DP191 as well as more broadly related to the current Treasury Consultations on Rules V3. On this basis we intend to respond to all of these items with linked papers.

As a consequence of the volume of considerations between these items we request the closure time for submissions be extended to 30 July 2021.

[CDR-API-Stream]

Thanks all for the extensive feedback. The request for an extension is noted, however, as also noted there are other avenues for related feedback and we have a large forward plan for consultation. As a result this consultation will not be extended.

We will work through the feedback and provide comment this week.

[biza-io]

In this case we request this thread be left open so that a response can be provided in the next 24-48 hours.

[CDR-API-Stream]

48 hours will be no problem

[ShaneDoolanAdatree]

Adatree does not support the introduction of purpose based consents at this time.

In our opinion, the problems that purpose based consents appears to be attempting to solve occur because of the coarse-grained authorization that exists within the infosec profile today, and also by customer experience guidelines that go against existing industry consumer facing patterns that consumers are familiar with.

We feel if the DSB wishes to better facilitate the data minimisation principle then this can be achieved through the introduction of fine-grained authorization.

We feel if the DSB wishes to reduce the cognitive load on consumers during the consent process then this can better be achieved by a review of the CX standards. Forcing ADRs to insist that consumers check data clusters that contain information that is irrelevant to the use case the ADR is trying to facilitate destroys trust in the ADR solution - "why are you asking for access to information X when it's unrelated?" Also, forcing the consumer the check every individual data cluster as if to initial clauses in a contract is not in line with the majority of consent based processes that consumers are currently familiar with.

A consent implementation built on top of fine-grained authorization where consumers are given the opportunity to check a merged data cluster containing the information required for the ADR use case would better facilitate the data minimisation principle and reduce consumer cognitive load by providing a more familiar experience.

We also do not feel it is in the regime's best interests to further burden ADHs with additional APIs when the current simple API set and infosec profile implementations of the majority of data holders is currently quite poor. If consistency across simple APIs among ADHs is difficult at the moment then consistency across actual use case implementations will be almost impossible, or it will require ADRs to police consistency to sustain their business models which is what's happening today with the current API set.

The regime is best focused on enforcing consistent infosec profile implementations in line with international standards and consistent data sets across data holders. Use cases are better left to the market than mandated by the CDS. If individual data holders wish to make use case based APIs available to ADRs we would welcome it but through ADH extensions that they can monetise rather than CDS mandated solutions. We feel providing ADHs with monetisation opportunities can help ensure implementation quality, otherwise ADRs will get more of the same low quality which the regime cannot afford if it wishes to succeed.

[biza-io]

Please find attached the Biza.io Response to Decision Proposal 183: Purpose Based Consents: DP183 - Purpose Based Consents.pdf

In addition to responding to the questions and evaluating the hypothesis we restate the following recommendations:

1. We support the construct of Purpose Based Consents
2. We do not support the use of scopes with complex business rules as proposed
3. We strongly recommend the DSB seek to adopt RAR as an underlying standard which will enable the delivery of Purpose Based Consents

[CDR-API-Stream]

Thanks all for the feedback. We will be closing this consultation and respond with our summary of, and response to, the feedback.

[CDR-API-Stream]

The feedback for this consultation has been internally reviewed and discussed.

As a result of this consultation a decision has been submitted to the Chair that will be published once it has been reviewed, amended and accepted. If it is approved or rejected by the Chair this thread will be updated.

The decision does not incorporate any change to the standards. It contains strategic statements only and includes definitions, to help clarify future consultations, and some constraining statements about how the concept of purpose based concepts will (or will not) be considered in the future.

[CDR-API-Stream]

Attached is the final decision document approved by the Chair: Decision 183 - Purpose Based Consents.pdf