search

ConsumerDataStandardsAustralia / standards-maintenance

This repository houses the interactions, consultations and work management to support the maintenance of baselined components of the Consumer Data Right API Standards and Information Security profile.
41 stars 9 forks source link

Alternate implementations for one-time consent #300

Closed ghost closed 3 years ago

ghost commented 4 years ago

Background

Regional Australia Bank has elected to use ‘one time consent’ for its online lending CDR workflow. This is to allow applicants who bank with one or more DHs to share a one-off snapshot of up to 2 years of transaction history from each DH without needing to authorise ongoing access to data. The transaction data is then processed to automatically determine and verify historical income and expense information.

Where CDR data is collected on a single occasion, CDR Rule 4.11(1)(b)(i) requires the accredited person to also indicate the period of time during which the CDR data will be used. In Regional Australia Bank’s case, this period is 90 days. This is because, although the bulk of loan applications can submitted in a short space of time, consumers do not always do this, preferring to leave the application open for a period of time. Similarly, although the bank can quickly decision the bulk of loan applications, some might require a more detailed manual assessment, potentially with multiple associated customer interactions over an extended period of time.

To the consumer, one-time collection coupled with a defined period of subsequent use makes sense, and is viewed as a fair value exchange. The alternate of a 90-day collection and use approach is incongruent with a point in time application, “why do you need to have access to my transaction data for 90 days to make a loan decision today?”.

Issues

In practice there are some issues with the one time consent model which is not particularly robust. The current implementation permits an access window of 2-10 minutes during which data can be collected from a DH. Many things can go wrong during this window, potentially meaning data cannot be collected.

Effectively, DRs get one shot at collecting data, and if something goes wrong there is not enough time to resolve and try again; it’s game over. There are many moving parts to a successful transfer of data. The Register, DRs and DHs all have their own systems, platforms and third party arrangements as part of a larger CDR ecosystem, and potentially consent is being given for multiple DHs, all with different performance and system capabilities. So the opportunity for failure during the one attempt is not insignificant.

For the Regional Australia Bank online lending use case, failure to collect all data from a DH within 2 minutes results in a very poor outcome for the consumer. They either have to repeat the consent process (with no guarantee of a different outcome), or manually source and provide the required data. To the consumer, the DR is the one that has ‘failed’ despite the process being outside their control.

It is understood that single collection and time-bound use was created in the Rules to support the type of use case that Regional Australia Bank has implemented. As this does not permit a reliably workable solution in it's current implementation, the relevance of this mode of collection, as it currently stands, is questionable.

Suggested Adjustments

Armed with knowledge obtained through practical experience, two broad approaches to overcoming these limitations are suggested. Option 1 would definitely improve matters and would not appear to require modification of the CDR Rules. Option 2 requires a more fundamental change to both the Rules and Standards and CX Guidelines.

Approach 1 – Carefully redefine ‘one time access’ as a mode of collection that could include multiple access attempts made during a specified, longer time window

Possible suggestions for consideration in order of increasing complexity include:

a. Issuing an access token with a fixed 10 minute expiration window (rather than existing 2 – 10 minutes)

b. Issuing a one-time access token with a fixed 24 hour expiration window

c. Issuing a refresh token with a fixed 24 hour expiration window

All suggestions in Option 1 could be accommodated within the current Rules which specify that data should be ‘collected on a single occasion’. This wording implies that the process needs to have successfully completed. If not, subsequent collection requests might be legitimately made. This could potentially enable DRs to either introduce automated retries or modify the CX to accommodate a ‘try again’ option with a DH if data collection failed due to a technical platform issue or outage.

Approach 2 – Abandon ‘one-time access’ altogether and independently define ‘consent to collect’ and ‘consent to use’ attributes in the Rules

As an example, this would enable an online lending or financial health check use case to request a 24 hour consent to collect, and 90 day consent to use.

This option provides two significant benefits:

This option requires work for DRs, the ACCC and the DSB

Option 1a is probably the easiest to implement but the least effective. Option 1b is also relatively straightforward to implement and would address most access issues. However, although it is the most significant in terms of implementation effort, Option 2 would appear to be the one that needs to be made.

Regional Australia Bank recommends Option 2 as outlined above.

Now is also the time to make this change while the ecosystem is still in a fledgling state with small numbers of participants and relatively minor investment has been made in use case design and development.

cdradr commented 4 years ago

What is stopping RAB from requesting an ongoing consent with 24hr sharing_duration? This would be similar to option 1c with no changes to the standards?

ghost commented 4 years ago

@cdradr We need to be able to use the data for up to 90 days. With the current rules in place tying consent to use with consent to collect, the concept of establishing a 24 hour consent means we can't use that data beyond the 24 hour mark. Hence the proposal for untying the consent to use from the consent to collect. That is, collect for up to 24 hours but use for up to 90 days.

TT-Frollo commented 4 years ago

Good write up Matt. The point first point you make about legitimately being able to complete the one time consent needs to be addressed. This is a concern given the real world problems that can and are occurring obtaining a consent and must be addressed. The Second point about the time to use is also needed and resolution would greatly improve the CDR.

perlboy commented 4 years ago

This requirement, along with the inevitability of further requirements based on use cases, is a perfect example of why a rich description of what and how something has been authorised is essentially mandatory. Replaying a section from OpenID's second response to DP99, from Page 5:

image

If RAR, which btw covers both request and response structures, was the target state for November introducing an additional attribute to the existing payload would be far more trivial versus the process claims modification within a claim security domain.

spikejump commented 4 years ago

@mattp-rab Sound like @cdradr's suggestion of a sharing duration of 24 hours would get you over the technical issues. Then RAB will, like most DRs, need a separation of Collection to Use in the Rules.

There are plenty use-cases that require a "one-time" collection but perpetual use. One of the original CDR notion/use-case is comparison shopping that may lead a consumer to changing banks. When consumer wants to change bank he/she may provide a one-time access to get hold of all payee information to another bank without setting them up again. If the payee information is required to be deleted after one-time consent expires, under the current ruling, then the customer has lost his/her payee data as it is derived CDR data.

Clearly, this is not the intent of CDR nor is the intent of CDR to force customer to consent, say every 12-month, to the original bank for the payee data. It may not even be possible after the consumer leaves the original bank as a customer. The only way to fix this is to separate Collection to Use. And this example shows, even when separated the consent to Use should allow a perpetual use of the data (as well as recurring consent if the use-case requires it).

It's important to realise the CDR data or its derivatives all belong to the customer. The Rules may be trying to protect the customers but it is in fact making it difficult for any participants to offer meaningful products/services for consumers today.

commbankoss commented 4 years ago

Commonwealth Bank is broadly supportive of aligning "single use" consent and other consents by removing "one time" consent and just using short duration consent, to allow ADRs to access the required data with multiple attempts. As per the current standards, we recommend the use of refresh tokens, and strongly oppose the use of long duration access tokens.

CDR-API-Stream commented 4 years ago

Thanks all for the feedback received. This issue was discussed in the maintenance iteration call held on 30/09/2020. There is a Rules consideration to the separation of collection and use consent which the DSB is clarifying with the ACCC. The DSB should be able to post this clarification shortly.

Technical options and CX considerations can be consulted on once this advice is posted.

WestpacOpenBanking commented 4 years ago

Westpac conceptually supports Approach 2. We note that adopting this approach would not necessarily mean that technical support for once-off consent would need to be retired. If the ‘consent to collect’ was sufficiently long then we recommend using the current long-lived consent mechanism (use of a refresh token, not extending the life of access tokens). We strongly oppose the use of long duration access tokens on security grounds.

CDR-API-Stream commented 4 years ago

Hi @mattp-rab / all,

Please see the clarification from the ACCC regarding separation of one-time collection and ongoing use of CDR data.

ACCC Rules Guidance

Where ADRs are providing a good or service that requires a one-time collection and ongoing use of the CDR data (as contemplated in rule 4.11(1)(b)(i)), the ADR must:

  • only collect the CDR data that is the subject of the consent once (rule 4.4(1)(c))
  • clearly indicate the specified period of time for use of that data (rule 4.11(1)) which must not exceed 12 months (rule 4.12(1))
  • collect the CDR in accordance with the data standards (rule 4.4(3)(b)).

At this time, ADRs may only have separate time periods for collection and use where the collection is a one-time collection. The ACCC and DSB are aware of legitimate CDR use cases that also require separate time periods for collection and use where there is consent for ongoing data collection (i.e. not one-time collection). The ACCC is currently seeking feedback on rule amendments that, amongst other things, allow for separate consents for collection of CDR data and consents to use CDR data. More information is available on our website, see in particular section 7.4 of the consultation paper. Interested parties have until 29 October 2020 to provide comment on the proposed rule amendments.

Based on this, "Approach 2" that you propose @mattp-rab would be allowed for one-time collection (sometimes referred to as once-off or one-time consent). As mentioned by the ACCC, consultation has commenced on a similar consideration for on-going consent.

Regarding the initial issue, there are a set of considerations still to make from a technical perspective.

CX Guidelines CX Guidelines on the separation of consent to collect and consent to use are under development and will be provided in an upcoming release.

These are being considered alongside the proposed new rules that seek to separate collection and use more broadly, including for ongoing consents and consent/authorisation withdrawal/expiry.

Technical Data Standards Changes Noting that separation of collection and use of CDR data is permitted for one-time collection, and, the intention in future Rules changes is to also permit the separation collection and use for on-going consent, the preferred approach would be to define what is allowable under one-time collection having regards to “Approach 2”.

In this light, Approach 1c is preferable in conjunction with defining what one-time collection is from a technical perspective. Whilst there is an obligation on the ADR to abide by the Rules, it seems reasonable to define a limit on the "sharing duration" where one-time collection is being authorised. This was outlined in the "Approach 1" options by @mattp-rab. If an ADR wishes to ask a consumer for one-time collection consent, it is proposed that this be defined to mean:

One-time collection is defined to be a request to collect data for a period, not greater than 24 hours, where the ADR successfully collects the data only once as required to provide their good or service

  • If the sharing_duration value is less than or equal to 24 hours then one-time collection will be assumed and a Refresh Token and Access Token must be provided
  • If the sharing_duration value is zero or absent then one-time collection will be assumed and only an Access Token (without a Refresh Token) will be provided on successful authorisation.
  • If a Refresh Token is issued for one-time collection the ADR must call the data holder’s revocation endpoint after successful collection of the CDR data.

Regarding each of the proposed options first raised in the CR,

Approach a. Issuing an access token with a fixed 10 minute expiration window (rather than existing 2 – 10 minutes)

This is unlikely to resolve all documented issues - namely where a DH is down for an extended period of time, or network issues cause continual interruption. After expiry of the 10min access token, the ADR still has no further recourse to collect data if they failed to collect it during the 10min window.

Approach b. Issuing a one-time access token with a fixed 24 hour expiration window

This would not be recommended. Changing the functionality and intended behaviour of access tokens would be a workaround fix.

Approach c. Issuing a refresh token with a fixed 24 hour expiration window

This is most in line with the ACCC Rules Guidance and provides a future proof and flexible interpretation of separation of one-time collection and on-going use of CDR data as well as avoiding technical outages or issues.

Approach 2 – Abandon ‘one-time access’ altogether and independently define ‘consent to collect’ and ‘consent to use’ attributes in the Rules

Based on ACCC guidance this is permitted for one-time collection (but not yet for ongoing consent). It would still require one of the Approach 1a-c options with Approach 1c being most suitable.

ghost commented 4 years ago

Thanks @CDR-API-Stream. Can I summarise this proposed change as being a change to the standards to define a one-time consent as being a request where the sharing_duration is between 0 and 86400 seconds (i.e. up to 24 hours)?

Would such a definitional change result in any implementation change needed for DH's? Perhaps around classification of a one-time consent for the presentation of one-time consents in their consumer dashboards?

Obviously, for a DR the change becomes more significant as the DR will now need to consider consent to collect revocation and related functions and standards if they request a sharing_duration > 0.

If my interpretation is about right, then I'm OK with the proposed adjustment.

NationalAustraliaBank commented 4 years ago

Due to security concerns, NAB strongly opposes the use of long duration access tokens (option 1b). NAB also opposes the extension of the access token from 2-10 minutes to a fixed 10 minute period as we don’t believe this will resolve the issue (option 1a).

NAB suggests a technical standard change to support how ‘one-time access’ consents are implemented. Rather than use the current access token approach, a short-lived refresh token (up to 24 hours) would be used. This will allow ADR’s a (up to) 24 hour window to collect data for a one-time access consent. At the same time continuing to meet the current ‘one-time access’ rule where data is ‘collected on a single occasion and used over a specified period of time’.

CDR-API-Stream commented 4 years ago

Hi @mattp-rab, that is correct. The proposal wouldn't preclude ADRs requesting the DH issue one-time consent where sharing_duration = 0 and only an access token is issued.

The proposal would support ADRs with a clear definition of one-time collection representing an agreed maximum sharing duration of 24 hours where they require a refresh token.

This wouldn't require a change for DHs because refresh token issuance is already supported where sharing_duration > 0. From this perspective, it isn't envisaged that a future dated obligation is required. It would be at the discretion of the ADR whether they make use of this change and when.

The DSB would welcome input from ADRs and DHs whether any other participants foresee future dated obligation requirements.

CDR-API-Stream commented 4 years ago

Thanks @NationalAustraliaBank for input on options 1a and 1b.

Regarding the technical standards changes are you proposing anything further to what has been proposed above? One-time collection would be treated as more of a conceptual state for consent with a time-bounded definition. Refresh tokens would inherently be short lived because the refresh token cannot have an expiry beyond the time remaining on the sharing arrangement. In this case, the second condition of the following statement Refresh Token expiration MAY be any length of time greater than 28 days but MUST NOT exceed the end of the duration of sharing consented to by the Consumer. would apply.

ghost commented 4 years ago

@CDR-API-Stream, the implications of DHs (and DRs) becomes one of UX where different copy is applied for once-off consents compared to other types. E.g.

Data holders SHOULD show the status of the consent, which may refer to it being 'active', 'withdrawn', 'expired', or relating to a 'once-off’ instance of sharing.

Consumer dashboards will need to be adjusted to cater for the new definition of a 'once-off' arrangement so that the correct copy can be presented to the consumers.

This is no argument against the proposal. But participants will need to be aware of this implication.

NationalAustraliaBank commented 4 years ago

@CDR-API-Stream, the proposed change to the standards that we are referring to in our post above refers to the addition of the following points into the Standards:

CDR-API-Stream commented 4 years ago

Hi @NationalAustraliaBank, the change being proposed to support one-time collection is to allow one-time collection to be supported by issuance of both Refresh Token and Access Token where the sharing_duration <= 24 hrs.

It would not disallow a sharing_duration = 0 and only an Access Token be issued (no Refresh Token). As the current statement in the standards implies, if the sharing_duration is absent, this is taken to mean the sharing_duration = 0. If the sharing_duration = 0 this is taken to mean once off access without issuance of a Refresh Token because there is no way to use a refresh token.

spikejump commented 4 years ago

@CDR-API-Stream Is there a need to call out one-time consent given where this is headed? Essentially a one-time consent as it is headed is just a consent with a sharing duration of 24-hours right? Is it necessary to give a 24-hour sharing duration a one-time consent name? Given the upcoming Rules amendment recommendation (assuming it gets adopted) of separation of consent to collect and consent to use this does not seem to be an issue?

ghost commented 4 years ago

Hey @spikejump to me the difference comes about when communicating to the consumer. It is good to be able to provide confident messaging that their information is to be/was collected just the once as a snapshot in time. This is both in the consent flow and in the dashboards. Without the construct of a one-time consent, this isn't possible to do cleanly or consistently.

spikejump commented 4 years ago

@mattp-rab Understand the intent and how it helps on the messaging for consumers. On the flip side, there can be use cases where ADRs ask for a 24-hour sharing duration but fetches data multiple times in the 24 hours (assuming there's value to do so). In which case it is actually misleading for the consumers to label the consent as one-time.

ghost commented 4 years ago

@spikejump you're right that it does introduce that potential. The potential is larger if the proposed rules v2 is adopted around the separation of consents. Is it realistic that such a strict use-case might exist for sub-24 hour multiple collection but longer usage? And would the theorised deficit outweigh the benefit to one-time consent models? I would think making the proposed change is the right choice of the lesser of two evils there.

If anyone is looking to introduce a sub 24 hour consent duration once rules v2 is introduced and this proposed definition of a one-time consent interferes with their plans, then now is the time to speak up!

TT-Frollo commented 4 years ago

There is always the potential for doing something miss-leading. There are many use cases (particularly lending) for a one-time consent and so it does need to be a clear and distinct consent.. At Frollo we would consider a 24 hour consent if the issues raised by @mattp-rab https://github.com/mattp-rab were not addressed. Our preference is for the one time consent. Hopefully as an ecosystem we can give clarity to consumers on the purpose and benefits of one-time consents and therefore ensure trust is established in the many use cases for one-time consent. It does not interfere with a periodic consent even if for 24 hours.

On Thu, 29 Oct 2020 at 13:40, Matt Peterson notifications@github.com wrote:

@spikejump https://github.com/spikejump you're right that it does introduce that potential. The potential is larger if the proposed rules v2 is adopted around the separation of consents. Is it realistic that such a strict use-case might exist for sub-24 hour multiple collection but longer usage? And would the theorised deficit outweigh the benefit to one-time consent models? I would think making the proposed change is the right choice of the lesser of two evils there.

If anyone is looking to introduce a sub 24 hour consent duration once rules v2 is introduced and this proposed definition of a one-time consent interferes with their plans, then now is the time to speak up!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/300#issuecomment-718322479, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN6HRHGWUHMO3J45QA3I5VLSNDIYJANCNFSM4QBNN6SQ .

--

Tony Thrassis

CIO

Vote for Frollo as Fintech organisation of the year (Finnies) http://bit.ly/votefrollo

m: +61 437 016 763

w: frollo.com.au

e: tony@frollo.us

a: L33/100 Walker St, N Sydney NSW 2060

This message contains privileged and confidential information for use by the intended recipient only. If you are not the intended recipient of this message, you must not disseminate, copy or use it in any manner. If you have received this message in error, please advise the sender by reply e-mail. Please ensure all e-mail attachments are scanned for viruses prior to opening or using.

spikejump commented 4 years ago

Strictly speaking a sharing duration of 12-month, 3-month, 24-hours, etc are all one-time consent as long as the ADR does not request for renewal. The intent for the advocated one-time consent is really to tell customers the collection of their data is one-time only.

I do agree the correct & consistent messaging to customers is required and of benefit to customers to trust the ecosystem. However, to enforce a customer facing messaging on to how technology is used behind the scenes just does not seem appropriate.

CDR-API-Stream commented 3 years ago

The outcome of this issue has been approved by the Data Standards Chair for inclusion in v1.7.0. A change to the data standards was recommended.

This issue will be closed accordingly.