Eliminate use of public clients

[Tom Jones]

It should be self-evident that any API allowing money to be diverted should not be allowed from a public client

[Joseph Heenan]

Can you explain why/how a typical mobile banking app is more secure than a public client please?

There was already some discussion about this here: https://bitbucket.org/openid/fapi/issues/74/write-spec-should-only-support

[Tom Jones]

First of all that is a good question, but it is out of scope for open I'd.

As an implementor I will attest that if I own both ends of the connection I have lots of resources to assure security that are not available when I must adapt to some one else`s code.

[Joseph Heenan]

I'm not sure if we're getting off topic now, but it is an interesting conversation.

The team at teller ( https://teller.io ) have reverse engineered the APIs used by the mobile apps of all UK banks to the point that they obtain long lasting tokens for users and can initiate payments from their own servers. Perhaps all the UK banks have failed to implement what you have in mind.

Anecdotally, at least one [non-CMA9] UK bank's mobile app uses neither any kind of token binding mechanism nor any white box crypto etc and minimally protects the access/refresh token (or equivalent).

Here's another UK banks API (they're not using OpenBanking): https://developer.starlingbank.com/docs They are happy allowing mobile apps to use the API and are using plain oauth2.

We don't mandate public clients, and explaining the best practice if you want to allow public clients seems sane to me - and OAuth 2.0 Token Binding and the other security improvements you get from FAPI seem to me to be a step beyond what a lot of people seem to be using in similar use cases currently.

[Tom Jones]

first of all if the user gives up their creds to access their bank account, there is a huge ux problem that the banks should fix, even tho it might not be fully in their interests to do so.

The easiest way to get banks interested in security is to severely limit the liability of consumers. I heartily recommend it.

Since the web site owns both end of the connex, it is much easier to respond to any attacker that occurs.

Secret obfuscation in a native app is poor security, but it is way better than javascript. it would be interesting to determine if there is a means to leverage more of the secret storage components in the phone, the way that the Google Authenticator does (perhaps they have an api?)

public clients written in javascript running inside the browser have very limited resources available to them and little means to fix the problem.

We see both android and apple moving to provide addition secure storage options, especially android since it became mandatory access control (MAC) enabled. The end of this track will be when open yolo is enabled and secure storage is easier, for any app, not just open yolo.

[Nat Sakimura]

So, getting back to the issue itself, FAPI allows a "public client" in the sense that it is a client that cannot keep the client_secret value securely, i.e., a client that does not perform per instance registration.

However, they are mandated to use OAuth Token Binding. EKM is per device and is much more secure than the confidential client's client_secret. During the protocol, it has to "register" the EKM as Token Binding ID to the server. So, it is now a registered client with a much stronger cryptographic key than a typical web client. IMHO, it should be allowed to make payments etc.

[Tom Jones]

Sorry to sound skeptical, but I would need more details before I could accept the idea that could be secure. Where can I find them?

The issue is that if the device cannot keep a client secret, why should we expect that it can keep a private key secret.

[Dave Tonge]

This is quite an in-depth overview of token binding https://medium.facilelogin.com/oauth-2-0-token-binding-e84cbb2e60

[Tom Jones]

I understand all that stuff. What's missing is how the client is trusted to represent the user intent.

How would I understand that a client loaded on my phone is ok to take full responsibility for all the money in my bank account?

The solutions that I can think about are all related to the registration ceremony of installation of the client on the user device. Without those the client imho is not trustworthy.

thx ..Tom (mobile)

[Joseph Heenan]

I'm not sure if we're over thinking this. The same issue of client trust applies to website/confidential client. (And EV cert not really a solution to that, as even if it's not a stolen cert it's near to impossible for a user to establish a clear relationship between a company name and the entity they think they're talking to.)

I'm not convinced the trust issue is one that can be solved with technology, or at least not technology at the openid connect level. Reviews on the App Store are a pretty good indication. Users are generally happy to give up quite a bit of personal data to apps that fit a need.

As you rightly say, a good model is to put the liability onto the API providers, as they are the ones with the necessary data to detect any kind of large scale fraud. The model adopted in the UK (and EU) where the bank is liable for losses unless the user is a bad actor seems to be a good one, though some of the details are still a bit unknown.

[Tom Jones]

wow, what do you know about ev certs that i do not? https://en.wikipedia.org/wiki/Extended_Validation_Certificate afaik these provide good binding from the web site to a physical business of know provenance. Please tell me why you think that is not the case?

You should reread the statement by the FCA. The bank will reimburse the user for "unauthorized payments". And who determines if the payment was authorized? Well i believe it is the bank unless i miss my guess.

Peace ..tom

[Joseph Heenan]

Hi Tom,

It's probably better if I put the EV discussion onto #135.

And who determines if the payment was authorized? Well i believe it is the bank unless i miss my guess.

It's initially the bank, but if the bank gets it wrong the user can take their case to the financial ombudsman. See http://www.financial-ombudsman.org.uk/publications/ombudsman-news/116/116-disputed-transactions.html for some [old, pre PSD2] background on how the financial ombudsman decides. Decisions of the financial ombudsman are essentially binding on the bank. Banks that consistently get it wrong can expect attention from the FCA I believe.

[Tom Jones]

that's a great link - thanks for that

[Tom Jones]

the use of public clients by a web entity for connection with a user was not anticipated by me. I do believe that public clients are not always appropriate, but will need to find some other way to proscribe them.

[Tom Jones]

will reissue if i can articulate the specific area where they are proscribed