Decision Proposal 035 - Customer Authentication Flow

[JamesMBligh]

This decision proposal relates to the support flows for the requesting and provision of authorisation under the CDR regime between the data consumer, data provider and customer.

It is anticipated that feedback will be closed for this proposal on the 1st of November. While this is a short period for feedback there is a need to accommodate the draft standard release on the 2nd. There will be more time for feedback after this date as the entire standard will be open for feedback at that point. Decision Proposal 035 - Customer Authentication Flow.pdf

[JamesMBligh]

Please Note Leading up to the definition of the first draft of the standards, the security working group decision proposals will be high level only. Due to the sensitivities around sharing security concerns and discussing current implementations in the financial sector the Advisory Committee has requested detailed security design decisions to be formulated via a series of in person meetings. These in person meetings will be co-ordinated using the security working group mailing list. You can sign up to this list at http://eepurl.com/dCNaTn.

The end result of this process will be a working draft proposal that will then be published and opened for transparent public comment, as has been the practice to date for the Data Standards Body.

For this reason this proposal, and others in this series, will focus on high level decisions that shape the overall approach to security under the regime rather than low level technical specifics.

-JB-

[RalphBragg]

Hi,

Given the overwhelming global push towards mobile based authentication, is this the proposal that should consider "App-to-App" or non browser user agents as an authentication mecahnism?

The proposals outlined imply that a web browser is the only user agent available to present an "authentication journey" when actually the clear global trend is for applications to be the user agent for both the Data Receiver and the Data Provider. Like CIBA, in a mobile only world, Option 2 unfortunately would require significant manual user intervention if the User Agent also happens to be the authentication device. The User Experience Team should consider how Option 2 would be received by customers operating on a purely mobile platform.

For clarity, Option 2 works perfectly well when the User Agent is not the same as the authentication device and the ideals stated in it are too be lauded however it would be interesting to see what proportion of the Australian market is mobile only as there is a better redirect (Option 1) alternative for that user segment.

Everyone in this space should be familiar with how app-to-app works, Think, "login with facebook" or "pay with PayPal" where a user is seamless transitioned from a Data Consumer Application to a Data Provider Application (facebook for identity and PayPal for API Payments). The Option 2 that is recommended in this paper describes a user experience that is sub optimal to both.

App to App redirection is 100% standards compliant with OAuth 2.0 and OIDC, 'App-to-App' redirection allows the TPP to redirect a PSU from the TPP application (in a mobile web browser or mobile app) to the ASPSP’s mobile app, installed on the PSU's device, where the TPP is able to transmit details of the request along with PSU preferences (e.g. product type, one-step authentication) and deep link the PSU into the ASPSP app login screen or function. The PSU is then authenticated through their app using the same credentials/methods as normally used when the PSU directly accesses their account using the app (typically biometric).

This does not involve any additional steps (such as being redirected first to a web page to select which ASPSP app to use) and does not require the PSU to provide any PSU identifier or other credentials to the ASPSP if their current ASPSP app does not require this. Where the PSU does not have the ASPSP's mobile app, they should experience a standard redirection flow.

There have been a number of technical and security issues that typically crop up, most of which are now baseless regarding the implementation of App-to-App. These are addressed below.

How the redirect flow works When using a service based on the FAPI API standard for redirection, the PSU will be re-directed twice: From the TPP interface to the ASPSP interface (to authenticate and authorise). The authorisation server URI is specified by each ASPSP in their .well-known endpoint. Back from the ASPSP interface to the TPP interface (to complete any transaction with the TPP). This redirect is specified by the TPP as part of the first redirect.

Implementation of deep links A seamless journey for the PSU, which bypasses the built in browser (e.g. Safari) on their mobile device, can be implemented for any URL, ie BOTH a) for the initial redirect which the TPP sends the PSU to on the ASPSP's servers, AND b) the redirect URL which the ASPSP sends the PSU back to after authentication/authorisation.

Both ASPSPs and TPPs should follow the guidance from Apple and Google below: iOS: https://developer.apple.com/ios/universal-links/ (covers over 99% of all iOS users1, who are on iOS 9 or greater). Android: https://developer.android.com/training/app-links/index.html (covers 65% of all Android users2, who are on Android 6.0 or later). In the event that a PSU does not have the app installed on their device, or if they have an older (or non iOS/Android, e.g. Windows Mobile) operating system, these methods will allow the PSU to be re-directed to a mobile web page. ASPSP Discovery Implications In order to support multiple apps for a given brand (e.g. Brand X Personal App, Brand X Business App), ASPSPs will need to configure multiple 'virtual' .well-known configuration endpoints for each physical authorisation server

Security considerations Security considerations are addressed here: https://tools.ietf.org/html/rfc8252. References https://data.apteligent.com/ios/ https://data.apteligent.com/android/

[darkedges]

I am confused by the commentary in option 1 as this is suggesting a bad practise. Why would a 3rd party page collect credential information?

Surely it is the Data Holder authentication page and it ideally should not be within an iframe or a popup window, as that would lead to confusion. Take a look at https://comparethemoose.com/ in a browser and you will see what I mean. Popups can be faked in Firefox and Safari IIRC.

As for option 2 commentary it says the user identifier is not shared with the data consumer. True the internal reference may not be, but the initial identifier is, so not sure what you are trying to suggest there. As for a known channel, surely the Data Holder page redirected to is a known channel for both Option 1 and 2, it is just adding complexity and forcing a data holder to implement something more than they may already have.

I think there may be some confusion with Option 1 and 2 and I am not sure what it is, but it does not smell right.

Option 3 is a good alternative, but depends on some mechanism to notify the consumer they need to perform an action. This is easy to do on/with a mobile device as the data holder can push a request. Desktop devices are a little more complicated as they may not be on the one registered to receive push messages/notifications.

IMHO Option 3 should be a consumer choice on how they want to engage with their Data Holder as a potential hybrid with Option 2. I.e present their external user identifier to the data holder and then presented with the option to do authentication via a method of their choosing.

Option 4 should not collect an Data Holder external identifier, as then they would have a key piece of how to get access to Data Holder services, again another bad practise. It also sounds like options 2 and 1are collecting data within their application.

With Option 5 why would a data holder need to tailor their solution to each ADR? I also don't think the consumer would have distrust in the eco system, as they are using it on a daily basis and continue to use and trust it.

I think we also need to be what what you mean by data provider. Is it the ADR or the DH? I think we should use the nomclemeture defined by the ACCC otherwise we may be talking cross purposes.

I know there is a requirement to remove the barrier of entry for ADR interactions with consumers, but I am not sure what the solution is. I like the process of User Managed Access (https://en.m.wikipedia.org/wiki/User-Managed_Access) as I can go to one place to control access to my data, but I can also see how it does not fit in with what most ADR want. It is a consumer choice to give access to data and overall leads to a less risky proposition for consumers, as they can do it within an eco-system they already know, their Data Holder application. Controversial? Yes it is. Going to happen? Not yet.

Regards Nicholas Irving

[davidgtonge]

The reason that Option 2 seems to be favoured is because of supposedly increased risk of phishing attacks if consumers get used to Option 1. I would argue that this is an ineffective time-limited solution to the problem of phishing. The full solution is the use of phishing-resistant credentials, e.g. FIDO / web authentication. Furthermore because Option 2 is impossible to deliver in a standards based way, there are actually increased security risks around it. I am happy to give examples of some of issues we have seen with implementations of flows similar to Option 2.

As @RalphBragg mentions, option 1 allows app to app flows. These have excellent usability and security characteristics and the standard should aim to support such flows.

Option 3 is a useful optional addition to the standard that can support cross-device interaction. CIBA has been tidied up a lot and will shortly receive a full FAPI profile. The latest draft of the core spec is here: https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fmobile%2Fraw%2Ftip%2Fdraft-mobile-client-initiated-backchannel-authentication.xml%3Fat%3Ddefault

It is important to note that Option 1 actually gives the Data Provider more context information than any of the other flows. Such information can be fed into fraud engines to help protect users.

Dave Tonge CTO Moneyhub Co-Chair FAPI WG, OIDF Co-Editor CIBA Profile, MODRNA WG, OIDF

[jh-a]

To add to the comments already voiced by @RalphBragg

Option 1 - I don't recognise the UX described as resulting from the OAuth flow. The likely experience is that the interface presented by the Data Provider will be a mobile application, and that this will not involve the submission of static, knowledge based factors of authentication. Additionally the reverse redirect of the customer authentication journey will include an authorisation code which is then exchanged from an access token at the token endpoint.

Given these clarifications, the commentary around risk to customers is entirely dependent on the factors of authentication used. There are many solutions using possession and knowledge based factors which do not involved the same risks of phishing / inception of credentials, and yet are still OAuth2 compliant. Supporting option 1 cannot therefore be seen as endorsing a more regressive type of customer authentication (knowledge) which is seen less and less frequently in market.

Option 2 - many of the comments in relation to point 1 above stand. It is also not clear what is referred to as 'the user identifier', as this could be any number of elements, or something entirely proprietary to the context. It is also unclear how a data provider would enforce observation of a device, particularly if the expectation is that the device not be mobile.

Options 3/4 - with both models, there is no need for the customer identifier to be static or related to the customer. It can be dynamic and opaque (i.e. a dynamic QR code), and linked to an individual data request. In many respects this is preferable as it can be scanned using an app, removing the need for the customer to type in an alpha numeric identifier.

[winter-ibt]

As @davidgtonge mentioned, the biggest issue with the design as it currently stands for consumer authentication is the reliance on phishable credentials. FIDO/WebAuthN mitigates the security issues while improving usability and consumer confidence. SMS OTP are not sufficient to protect user data even in read only modes.

[LenNatBEN]

Agree with above posts that the option selected should not exclude Native App OAUTH flow. If Option 2 can be reworked to ensure that is the case then it seems feasible - however will be keen for the UX Workshops happening currently to provide a view.

[johndugganoz]

Data transfer isn’t a low risk transaction.

The transfer of my data from a data provider to a data consumer is a high risk transaction because any vulnerabilities in this process can facilitate my identity being taken over at the data consumer service and beyond.

The data provider should also maintain a signed proof of the transaction that would be available to me if I require it to counter identity takeover.

Given phishing and other concerns, passwords and the SMS OTP mechanism are not appropriate for a high risk transaction. These are primary vulnerabilities that fraudsters leverage for identity takeover so they are particularly inappropriate to the data sharing use care. They also don’t facilitate a signed proof in the industry accepted PKI context.

The right thing to do here is move beyond passwords and SMS OTP. Don’t let the current use of these dictate a poor UX and lower security scheme for Open Banking

John Duggan SVP Daon

[commbankoss]

CBA’s primary concern in this discussion is ensuring we re-enforce safe consumer behavior in an inherently risky environment which is exposed to a broad range of potentially fraudulent activities such as phishing and smishing attacks.

In an average month, CBA works with authorities to take down 100+ sites that attempt to imitate our Netbank login page and online banking portal. It is nearly impossible for an average consumer to differentiate these sites from the authentic bank homepage, especially once the URL is masked by an IFrame, WebView, or other method or obfuscation.

To help protect our customers from these attacks today, we recommend they always key in the known URL of their banking site to ensure it is genuine prior to providing any credentials and putting sensitive information at risk. CBA feel that a decoupled customer authentication is the best approach to re-enforce this behavior and help to protect consumers against these attacks.

CBA is open to continue to work with the industry on maturing best practice around cybercrime defense and will contribute to this topic further via the closed security working groups.

[mperryau]

I believe there is a major piece missing in this proposal as it stands: Two-Factor (or Multi-Factor) Authentication. MFA can help mitigate risks associated with Option 1. As Ralph mentioned, this is a desired authentication flow as it is supported by standards, and I support Option 1 with the additional of MFA.

Option 2, as I understand it from the description, does not seem to fully address the issues with Option 1, as both sets of screens could potentially be impersonated by an attacker.

CIBA is an emerging specification that should also be considered. That specification should be available for implementation shortly and is within the timeframe for the initial CDR go-live.

I also want to back up John's comments on MFA and read-only APIs.

MFA should not be optional in any CDR regime. And where possible, OTP via SMS should be offered as an authentication method of last resort, based on the recommendation of standards bodies like NIST.

Mark Perry Ping Identity

[anzbankau]

Proposed option 2 as it reads suggests redirect to browser type user-agent which could include browser on mobile e.g. Safari as only interim landing page on redirect from Data Consumer’s app or mobile client. ANZ position with this is that we do not want to preclude redirect to native mobile client by directly landing on Data Provider’s mobile app. This could mean that where a device used to establish consent is also the one which have Data providers mobile app present, redirect is performed directly to mobile app without necessarily introducing another point of friction in between for customer to enter their known identifier with Data provider. Where Data provider app is not present then a redirect can be to webpage on mobile or desktop browser from Data provider which can present subsequent options and authenticators available to customer to complete process. ANZ believes that this refinement to option 2 offers most flexibility to service scenarios where consent initiation in data consumer channel and authentication/authorization on data provider channel all happen on same mobile device balancing need of security, customer experience and industry standards. This also provides ability to support true decoupled approach where customer as an example can be informed to complete consent authentication and authorization on channel which could potentially be on different device well known to them. Benefits as stated in option 2 such as non-disclosure of customer identifier in Data Consumer channel, ability for Data Consumer to observe devices will still be present.

[da-banking]

Summary

• Data61 should mandate OpenID Connect and FAPI RW.
• Data61 should leave the authentication mechanisms to the discretion of banks.
• This is a modified version of Option 1, with the specifics of a user identified and password omitted.

Rationale Security is an arms race, between the holders of sensitive information and attackers. Banks have many layers of security controls in place, and must retain the right to unilaterally adapt their security posture to any emerging threats. Different channels represent a different level of threat to data holders, and security should be relative to that threat.

There is a good argument that a consistent authentication experience across all of a bank's services conditions the user to expect that experience, and reduces the scope for phishing attacks. Banks will want to control this. We do not think Data61 should prescribe the bank's authentication controls (username, password, channel OTP etc), and that banks should have complete discretion in this regard.

Data61 should mandate OpenID Connect and FAPI RW. This regime remains extremely flexible in what the bank does to authenticate the user, while at the same time providing a consistent interaction between the data consumer and all of the banks. This will give banks the most flexibility to address new threats while providing the best user experience. Option 1 and Option 2, and bank-specific variations in between (involving MFA, risk analysis, etc) can all be accommodated within that, without any impact on data consumers.

Options 3 and 4 refer to a draft flow that is not well supported among tool providers for data consumers or data providers. We think both are unsuitable. In addition, option 4 complicates the user experience. A data consumer would have to explain to a user that they need to open their [Bank Name] app, and follow proprietary steps x, y, and z, to obtain a one-time passcode, that could then be entered into the data consumer interface. The steps to achieve this could be different for each bank, and within each bank they would be different for users that use a banking app versus users that use internet banking, versus users that use business banking. This is untenable.

We believe that security of users' personal information is the highest concern, and that banks require discretion to protect against emerging threats. The potential for banks to abuse this discretion in an anti-competitive manner should be a matter for the ACCC to adjudicate.

[WestpacOpenBanking]

Westpac recommends Option 4 because it is the most secure. We accept Option 2 if the user experience of option 4 is not deemed suitable from a user experience viewpoint. This is on the assumption that ‘direct’ in the description of Option 2 does not mean redirect, but instead that the user is directed to go to their online channel via text or some other means. We also assume that the exact method of capturing authorisation at that point would be up to the data holder until the completed authorisation is sent to the data recipient.

As a general comment, we don’t believe that user experience and authentication flow should be considered in isolation. There are many examples where user experience impacts with or is aligned with the best choice from a security perspective. In particular, the proposal should have considered the differences between app, webview and browser contexts. For example, the redirect options proposed do not give specific consideration to app-to-app, browser-to-browser and app-to-webview redirect scenarios. Multi-factor or biometric authentication are also not discussed when considering each flow.

[RalphBragg]

@WestpacOpenBanking I agree in principle with your last comment, the failure to consider the security user experience as well as the user agents involved makes "picking one" very difficult. I would like to point out that CIBA option 3, supports option 4. The authors did not realise this when they published the paper. Was there a reason why option 4 (less standardized CIBA) was chosen over 3?

CIBA requires a "login_hint_token" that provides "a user identifier known to the Data Provider". This could be a one time password / code that option 4 talks about. Based on the text of paper, Option 4 offers nothing further than Option from a functional POV, just proposes less standardization.

This sentence is incorrect and misrepresents the standard which is a bit unfortunate: The data consumer is required to know the customer’s identifier which is considered sensitive information by many financial institutions

For example a CIBA Token could be

{ type: staticid, value: RalphBankUsername }

or it could be a dynamic value generated on a users mobile phone. { type: generated. value: 1234567897234 }

[NationalAustraliaBank]

NAB has provided detailed feedback directly to Data 61 on this topic, which will be shared with the security working group. However in summary:

• Option 1 - Redirect [not recommended]
• Option 2 - Redirect with known channel authentication [Plausible]
• Option 3 - CIBA [Plausible]
• Option 4 - Entirely Decoupled [Plausible but complex for consumers]
• Option 5 - Data Provider Discretion [not recommended]

[JamesMBligh]

Thanks for the feedback everyone. We will synthesising this for an initial hypothesis for the draft standards and will then work with the security working group in working sessions to work through the issues and clarify the position for implementation.

-JB-

[JamesMBligh]

The finalised decision for this topic has been endorsed. Please refer to the attached document. Decision 035 - Customer Authentication Flow.pdf

-JB-