Decision Proposal 062 - Authorisation Flows

[JamesMBligh]

This issue has been opened to capture, document and obtain feedback on a subset of the Information Security profile for the CDR regime with a view to finalisation and endorsement by the Chair of the Consumer Data Standards body.

This issue is specifically related to the authorisation flow for the regime.

The decision is published below and will be open for feedback until the 17th May: Decision Proposal 062 - Authorisation Flow.pdf

[JamesMBligh]

The decision proposal has now been published for feedback.

-JB-

[Mekaal]

The way this proposal is written it dictates that the authentication happens within the current online channel/s - "Data Holders MUST support the completion of authorisation via the various digital channels they offer that Customers would reasonably expect to use on a regular basis.." Up to this point we had assumed that the requirement was that the authentication and authorisation should happen in an application that looked and felt like the pre-existing digital channels, and in the same manner as the pre-exiting digital channels, but may or may not actually be a part of the pre-existing digital channel/s.

Why has the way the solution is to be delivered been restricted in this manner rather than just being expressed in terms of requirements?

There are potentially (CX) issues in sending the customer into their online banking to consent (consent being an ephemeral activity that is only required as part of a flow launched via the recipient and not to be used otherwise) and there are potentially benefits where many brands/channels exist in seeking a solution outside the various current channels that can be used/reused by all channels.

[WestpacOpenBanking]

We have developed a draft sequence diagram (below) based on our current interpretation of the information security standard.

Based on this interpretation of the standard we have the following remarks and questions:

• Westpac does not recommend omitting the account request object.
• The security of directing the customer to return the original Capture Customer Identifier page [step 22] needs to be reviewed. It will not be uncommon for customers to forget to do this / be interrupted in their process, thereby leaving an unprotected page as the holder of the authorisation code.
• The error recovery scenarios to do with directing the customer to return the original Capture Customer Identifier page [step 22] needs to be reviewed. It will not be uncommon for customers to forget to do this or otherwise be interrupted in their process, thereby leaving the authorisation in an indeterminate state from a Data Holder's perspective and with no way to pick up the authorisation code.
• Replacing step 22 with a HTTP 302 redirect back to the Data Recipient has the following issues:
  • A customer might use a different device to access their known channel.
  • A customer, particularly a business customer, may have multiple consents to approve. It is unclear where the redirect should be to in that case.
• A customer may not expect a redirect from their known channel to a third party.
• It's feasible that multiple once-off consents with the same Data Recipient exist concurrently in a short period of time. For example, a customer might share their transactions to apply for a product, and then if the application is successful they might wish to import a list of payees.
• In the UK, in [ODIC] and [FAPI-RW], redirect_uris, client_ids and the set of scopes allowed by a client_id are all set by the Data Holder during client registration and validated. What are these validated against in the flow below?
• In the UK, Data Holders may advertise additional security scopes beyond the standards through the OIDC Well Known configuration endpoint. Data recipients may also request them. Is this the case in Australia?

Sequence diagram

[JamesMBligh]

Hi @mekaal, the proposal is being expressed in terms of requirement. The requirement is that authentication happens via a channel a customer is familiar with. This has been consistently expressed and has been in direct response to concerns regarding phishing raised by the Banking sector as well as customer advocacy groups.

If the restriction was relaxed to allow for an app that looks like the Bank’s authentication flow but is actually a different app then we are explicitly opening the potential for phishing attacks. That is usually what a phishing attack is. An app that looks like a bank app but isn’t.

-JB-

[JamesMBligh]

In response to @WestpacOpenBanking:

We have developed a draft sequence diagram (below) based on our current interpretation of the information security standard.

Thanks. Nice diagram. Do you mind if I reuse it with amendments as appropriate?

• Westpac does not recommend omitting the account request object.

I'll address this in the thread for proposal 064.

• The security of directing the customer to return the original Capture Customer Identifier page [step 22] needs to be reviewed. It will not be uncommon for customers to forget to do this / be interrupted in their process, thereby leaving an unprotected page as the holder of the authorisation code.

• The error recovery scenarios to do with directing the customer to return the original Capture Customer Identifier page [step 22] needs to be reviewed. It will not be uncommon for customers to forget to do this or otherwise be interrupted in their process, thereby leaving the authorisation in an indeterminate state from a Data Holder's perspective and with no way to pick up the authorisation code.

• Replacing step 22 with a HTTP 302 redirect back to the Data Recipient has the following issues:

  • A customer might use a different device to access their known channel.
  • A customer, particularly a business customer, may have multiple consents to approve. It is unclear where the redirect should be to in that case.

• A customer may not expect a redirect from their known channel to a third party.

Step 22 isn't currently required by the proposal (for all of the reasons stated). There is a specific requirement (below) that requires the recipient to honour a redirect sent from the known channel even if this occurs on a separate device.

As the Customer may have used a different device to access the existing digital channel to complete authorisation the use of the redirect URI supplied by the Data Recipient may occur from a different device. The Data Holder and Data Recipient must facilitate this scenario.

The CX team will be testing this flow with customers to assess if there are additional CX issues that need to be addressed.

• It's feasible that multiple once-off consents with the same Data Recipient exist concurrently in a short period of time. For example, a customer might share their transactions to apply for a product, and then if the application is successful they might wish to import a list of payees.

This is an interesting one. I'm not sure anyone has raised this concern before. I don't believe the current proposals would have an issue with this, however.

• In the UK, in [ODIC] and [FAPI-RW], redirect_uris, client_ids and the set of scopes allowed by a client_id are all set by the Data Holder during client registration and validated. What are these validated against in the flow below?

These will still be setup by the recipient during registration. This registration will be with the ACCC Register and the holders will then obtain this information consistently from the register.

• In the UK, Data Holders may advertise additional security scopes beyond the standards through the OIDC Well Known configuration endpoint. Data recipients may also request them. Is this the case in Australia?

This is not precluded by the rules and is specifically encouraged by the extensibility model adopted very early in the process of standards development.

I hope that addresses everything.

-JB-

[WestpacOpenBanking]

We are happy for Data61 to use the diagram as appropriate with amendments. We will email the source used to generate both the diagram above and the diagram below. In the meantime, we have been considering scenarios errors might occur in the proposed flow and have some minimal changes that the community and Data61 may wish to consider. These haven’t been security assessed by us and don’t constitute a recommendation – we still believe that use of a consent resource is the most likely to result in a robust experience for customers, especially where errors occur.

Modified sequence diagram incorporating these minimal changes:

[NationalAustraliaBank]

Hybrid Flow

As part of the initial CDR release, NAB is comfortable overall with the Hybrid Authorisation flow with redirect to known channel. From a security perspective, the hybrid redirect flow allows for active monitoring of fraud that other methods may not cater for today. We understand there are CX/UI implications that may not be sustainable in the foreseeable future such as real-time handling of decoupled authorisation requests from multiple signatories. To ensure the solution provides a desirable and usable customer experience that also balances security requirements, we reiterate that a collaborative workshop is required with the CX / UI and Technical streams along with the industry participants. We expect Data61 to provide a formal, up-to-date detailed sequence diagram flow.

Consent

As previously mentioned on DP#64, NAB strongly opposes the implementation of a solution that consolidates identity management and consent / permission management. In addition to the points previously articulated, there is a risk that the proposed solution exposes unknown security vulnerabilities. NAB supports best practices as seen in the UK implementation, which separates these security and business concerns, and expects that due-diligence Security Assurance activities on the proposed solution are performed.

[Promysys]

Priviti has created an Open Standard Consent API, that we are making available as a proposed standard as part of this process. A Consent API has been called out by us previously as being a necessary step to ensuring a separate Consent framework is adopted across the industry to support Consents for Data Sharing.

With the delay in drafting the standards, there should be plenty opportunity to fully test and adopt a Consent API that support the points raised above and in DP#64 . We feel the decision in DP#68 was closed to soon and further consultation is required or the feedback provided in this thread and others should be considered. There is plenty of opportunity, time and scope to address any UX considerations by all parties seeking to obtain Consumer Consent. The ensuing benefits to the Consumer are paramount and at the core of the intended legislation.

Consent is a crucial element of CDR and Open Banking and as a representative of the Fintech, RegTech , AIIA and startup community we are confident in the benefits Consent can provide to a Consumer. Acknowledging we also have a conflict in participating (as we have invented a Consent API that we would like tested as a standard), however, that’s not our only reason for participating here. As an advocate for the industry and consumer choice, explicit Consent and Consent identifiers are crucial to effect data sharing agreements between organisations and will also help us to participate in current and future global standards, as evidenced through the adoption of GDRP, PSD2, MifIID by overseas and local entities. Consent goes to the heart of CDR and the Open Banking initiative and the valid issues raised in this and other threads, should not be overlooked or left until later. The Consent API has been adopted (after the fact) in the UK and is working well for participating entities. We should be ahead of the world here and have an opportunity (and time) to collaborate and get it right now.

Anything other than a detailed evaluation around the implementation of a Consent API falls short of what we feel those in the industry and our consumers are expecting.

We would like to participate in a testing regime during the standard evaluation period that supports the adoption of a Consent API framework as proposed by NAB, Westpac and others and shared openly by us on Gitlab (PM me for details and access) Cheers, DM

[csirostu]

shared openly by us on Gitlab (PM me for details and access)

Sorry, but point of order here. "Shared Openly" and then "PM me for .. access". We welcome all of the valuable feedback you and others have provided but these two statements are contradictory. Can you provide a link to where I can find a swagger spec? Open is not open if it's an invite only party.

[Promysys]

shared openly by us on Gitlab (PM me for details and access)

Sorry, but point of order here. "Shared Openly" and then "PM me for .. access". We welcome all of the valuable feedback you and others have provided but these two statements are contradictory. Can you provide a link to where I can find a swagger spec? Open is not open if it's an invite only party.

It's a fair point you raise and I'm glad you did. There are 31million users on Github so forgive me I wasn't intentionally misleading but by 'Open' I didn't mean that we would feel comfortable sharing the API and IP with the whole world. We would happily share it with you and those involved in this program. If you PM me for access I will give you a link to login to review the swagger files. If we get a project kicked off we can open the kimono to an offline closed working group to tear into with a view to developing the new Australian Consent standard. We think there is an opportunity to create new standards from this exercise (in fact we think that's the whole point) and we think we've got something that will help in relation to creating a Consent framework. We also think there is value in what we have created so don't want public access until all the standards bodies in different regions have done their own due diligence and established their own standards.

We're not a bank and don't have those kind of resources. If you're interested have a look at how Barclays have done it Barclays Consent API or via the UK sandbox here

[jh-a]

On a point of information, there's no such thing as a Barclays consent standard. Barclays adopted the OB consent standard which was developed in a completely open and unrestricted manner, with many open meetings and cycles of feedback. The most up to date version is at https://openbanking.atlassian.net/wiki/spaces/DZ/pages/1077805332/Account+Access+Consents+v3.1.2

The idea of an 'Australian' technical standard where there are elements which have no jurisdictional bearing is difficult to understand. Where possible, global standards should be able to converge - FAPI and SWIFT being two key examples.

In any event an open process will have the greatest likelihood of collaborative efforts which result in a high quality output. Finally, APIs which are to be offered and consumed by a wide audience shouldn't be considered IP or hidden. The examples in market which are consumed at scale (Stripe, Paypal, eBay etc) are completely open and have supporting (and freely accessible test facilities.

[jh-a]

The 'UK Sandbox' is available at https://backstage.forgerock.com/knowledge/openbanking/home/g82455974

[Promysys]

On a point of information, there's no such thing as a Barclays consent standard. Barclays adopted the OB consent standard which was developed in a completely open and unrestricted manner, with many open meetings and cycles of feedback. The most up to date version is at https://openbanking.atlassian.net/wiki/spaces/DZ/pages/1077805332/Account+Access+Consents+v3.1.2

The idea of an 'Australian' technical standard where there are elements which have no jurisdictional bearing is difficult to understand. Where possible, global standards should be able to converge - FAPI and SWIFT being two key examples.

In any event an open process will have the greatest likelihood of collaborative efforts which result in a high quality output. Finally, APIs which are to be offered and consumed by a wide audience shouldn't be considered IP or hidden. The examples in market which are consumed at scale (Stripe, Paypal, eBay etc) are completely open and have supporting (and freely accessible test facilities.

ok this is going wrong.. this isn't about Priviti (we're not a bank, ebay or Stripe) use our Consent API or not or another one I'm not bothered. The point we (and others) were trying to make was that there needs to be a Consent API and there currently isn't one and we feel that's a mistake.

[JamesMBligh]

I really appreciate your input @DermotMcCann on this topic. Specialists in areas impacting the standards are usually strong and effective voices during consultation. All comments on this topic are very welcome.

As the topic of the consent API is a recurring theme in feedback it is probably a good idea for reasoning behind the current position to be outlined.

1. The DSB agrees that a consent API has value. Assuming the CDR is successful in its goals (which is an end I am personally committed to), the regime will extend across industries and hopefully become a basis for voluntary extension. As the regime grows in sophistication a mechanism for allowing more fine grained control of consent that can also be used in other channels such as B2B batch would be very useful.

2. The standards for consent are nascent. There are a number available as proposals or drafts and there are commercial standards being proposed. Along with the Priviti standard there is the Kantara initiative draft, a draft proposal with the OIDF and the one in use in the UK. There are also standards by other organisations focused on issues arising from the GDPR and, I’m sure, a few others. All of these have similarities and differences.

3. With the exception of an extended sharing duration there is no current need arising from the legislation, rules or designation instrument that requires a consent API. There is no current need for consent update (we define consent as immutable), no multi-party scenarios, no cross-channel scenarios, no data cluster level durations and no requirement for fine grain permissioning.

4. The CDR has adopted a series of principles for API design that we have been attempting to adhere to and also using when attempting to reach a compromise solution.

Taking these points into account, if we adopt a consent API now we will be pinning ourselves to a specific position just before a relevant open standard is likely to emerge without any functional requirement to do so. The position in the current proposal does not exclude the addition of a consent API in the future when a standard has emerged with commensurate vendor support and/or a specific need presents itself. This position is compliant with the following design principles:

• Principle 1: APIs are secure: a new CDR specific consent API would not be standards aligned and would therefore be untested in other circumstances

• Principle 2: APIs use open standards: there isn’t an open standard yet but there will likely be one soon. It is preferable if we adopt an appropriate open standard than to be pre-emptier

• Principle 6: APIs are implementation agnostic: implementations considerations are important they are short term. Something as significant as consent, which will be a long term decision across multiple industries, should not be too driven by the first implemenations

• Principle 7: APIs are simple: at the last Advisory Committee meeting one of the members specifically called out the need for simplicity over complexity in design decisions. Part of the implication of this principle is to not exceed the functional requirements of the moment (which is the intent of the MVP concept). In this case this a consent API is not the simplest path.

In summary, the current position is: a consent API is a good idea but should be considered in a future iteration of the standards, not version 1.

I hope that helps clarify the position somewhat. As always, feedback is welcome.

-JB-

[Mekaal]

James, the text reads "Data Holders MUST apply a timeout of five minutes for the completion of the volitionary action by the customer of authenticating in an existing channel." Can you please clarify what is the start of the five minutes - is it the customer authenticating a session in an existing channel, or other (eg receipt of the original request, capture of the username)?

[JamesMBligh]

Hi @Mekaal, I wasn't specific because this could depend on variations arising the CX guidelines but an initial expectation is that the five minutes is initiated once the customer enters their ID in the redirected page and would be fulfilled once the same customers completes authentication in a known channel. Is this the clarification you are looking for?

-JB-

[Mekaal]

That’s good - thanks

[anzbankau]

• Use of Known channel by means of volitionary action from redirected page still doesn’t prevent Phishing. Effective treatment against it is customer education which admittingly can be relatively easier with consistency. Even with proposed approach Phishing can occur by directing customer to Data Holder’s look alike page to collect identifier and prompt for explicit action to be redirected to another Phishing page to harvest credentials.

• Discretion on how and where to authenticate should be left to Data Holder to decide as long as it doesn’t risk unauthorised access to Data Holders existing channels. Use of Authenticators like One Time Use credential delivered via trusted known channel to the customer provides effective control. Further restriction of access using those for consent creation takes away motivation for Phishing attacks.

• ANZ believes authenticators like OTP delivered to customer's mobile on file or registered Mobile App which can be entered on redirected Data Holders page can provide balance not giving anything more than identifier as in proposal. Customers in this variation are not required to leave their current user agent or device to complete process and be redirected to Data Recipient from Bank’s known channel abruptly.

• Education piece here still offers consistency where customers are encouraged to not enter their passwords outside known channels (e.g. Internet Banking or Mobile) inline with industry education.

• We appreciate experience as a whole be taken into consideration for wider adoption and that standards can avoid being prohibitive to implement authentication of any type on redirect page. In case where this is not acceptable we strongly encourage CIBA be brought back to standards.

[JamesMBligh]

Thanks for all of the feedback. By request this issue will be kept open for further consultation until mid week.

[commbankoss]

CBA continues to recommend the use of de-coupled (non-redirect) authorisation approach rather than “redirect with known channel” (redirect) approach. We believe the redirect approach significantly increases the phishing risk to consumers by creating new opportunities for highly adaptive cyber criminals to create new phishing scams. In addition, we believe the redirect approach will contribute to a less secure ecosystem as consumers will become conditioned to trusting URLs to which they are redirected by a third party. While it is impossible to fully guarantee consumer safety online, Commonwealth Bank believes that the decoupled approach is significantly more secure for consumers than the redirect approach.

Furthermore the Decision Proposal states that “Data Holders MUST support the capture of the Customer’s username via the redirected page. We understand this username to be the same identifier the Customer would normally use for other digital channels provided by the Data Holder.” CBA strongly opposes the use of unique banking identifiers by consumers for any purpose other than accessing online banking services to protect against future phishing attacks.

CBA believes that a decoupled approach will not lead to a significant compromise on CX. Rather the proposed redirect model may actually increase the risk of consumer ‘drop out’, since there are more steps involved.

We welcome further discussion with all parties to identify the most secure solution for consumers.

[JamesMBligh]

Thanks for the feedback. This is all very useful and will be reviewed internally with a view to determining a path forward. I'll be closing down feedback on this thread. Any additional feedback or points of clarification can be posted on the current open thread for feedback (#67)

[JamesMBligh]

Please find attached the final decision covering this issue Decision 061-066,068 - Information Security Profile.pdf