[Openid-specs-fapi] The FAPI Security Model - Under Fire

Tom Jones thomasclinganjones at gmail.com
Fri Mar 2 18:17:43 UTC 2018


Excellent question, I have been working through several possibilities.
Clearly the OpenID client is not be trusted by the user for creating
authorizations, that is the whole point. The idea of forcing all outbound
HTTP through the phone browser helps, but does not appear to be sufficient
for security. If the user has a public client from Amazon, they are
probably safe. If the user has a public client from a debt collection
service they are screwed. It seems that the FCA is abdicating the
responsibility of their own charter in this regard by dumping
responsibility back on the user. I suspect that any bank will determine
that payments initiated by the bill collector are authorized. So there are
two points going forward.

1. Where you can, eg the browser, use the existing strong id - like the EV
cert
2. For apps acting as client determine where the weakness exist and expose
them for correction, Two ways come to mind:
 a. Perform a thorough threat model and analysis and publish it (or give it
to Ross Anderson). Not good for the standard, but there is no choice.
 b. Build an app that shows bad behavior and work with google and apple to
address the issues with the help other public orgs

it should be clear to everyone that OpenID Connect did not give permanent
authorizations to the client. Also the refresh token can be revoked by the
user with the OP (or that should be true.) Perhaps the FAPI spec needs to
involve the OP in every payment initiation after the time out of a
short-lived grant? This should be easy if the OP is the bank. It should
still be possible if the OP is chosen by the user, but a new scope might be
needed.

Notification is an alternate possibility. I have one credit card that i use
for every online transaction. It sends me notification (SMS) of every
charge made against it so i can track what the online site is really doing.
The FAPI spec could mandate that option. CIBA should work here, but i
really need to understand how that might work in practice. Recall the
client is not trustworthy in OpenID, but could be determined to be so by a
trustworthy federation (other than the FCA). Another way to say that is
CIBA in FAPI needs a thorough threat model analysis.

I haven't yet decided on the best approach.  But i will be trying to build
secure apps, perhaps with yolo.

..tom

Peace ..tom

On Fri, Mar 2, 2018 at 7:02 AM, Dave Tonge <dave.tonge at momentumft.co.uk>
wrote:

> How would EV certs helps with apps though?
>
> On 2 March 2018 at 14:46, Tom Jones via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net> wrote:
>
>> That's not what really bothers me. It is the inability of the entities in
>> this transaction to step up and accept responsibility that sends the wrong
>> message.
>>
>> I propose that fapi require EV certs for every consumer facing web site.
>>
>> thx ..Tom (mobile)
>>
>> On Mar 2, 2018 4:08 AM, "Joseph Heenan" <joseph at authlete.com> wrote:
>>
>> Hi Tom,
>>
>> Under the OpenBanking model, the TPP MUST be registered with the FCA,
>> which includes a lot of checking, requires liability insurance and
>> documented processes for dealing with security/data loss/etc, and as I
>> understand it there are additional checks with the org tries to enrol onto
>> the OpenBanking directory. Aside from issues like stolen certificates, when
>> a TPP sends you to a bank to login, the bank will display the TPP name and
>> there is a good certainty (I'd say more than an EV certificate) that the
>> organisation name you see in the bank's portal is the one getting access to
>> your data.
>>
>> The transitional arrangements are an issue (and only a temporary one),
>> but importantly transitional participants cannot access the OpenBanking
>> APIs. They can only operate under screen scraping or other models that were
>> possible pre-OpenBanking. To use a transitional service, you will be
>> required to give your banking credentials to the TPP (not to your bank) so
>> there is a clear difference. I believe many or most of the companies that
>> could operate under transitional arrangements have applied for
>> registration/authorisation so they can access OB APIs, though there are one
>> or two notable exceptions.
>>
>> The situation with fraud and TPPs operating under the transitional
>> arrangements are unclear. I have heard of legal opinions that go in both
>> directions as to whether the bank is liable or not and I doubt it will
>> become clear unless/until the FCA or a court issue a binding decision, if
>> significant fraud happens prior to the transitional arrangement ceasing at
>> the end of next year.
>>
>> Cheers,
>>
>> Joseph
>>
>>
>> On 2 Mar 2018, at 03:31, Tom Jones <thomasclinganjones at gmail.com> wrote:
>>
>> here is the quoted detail from the UK FCA https://www.fca.org.uk/con
>> sumers/account-information-and-payment-initiation-services
>>
>> you will note that neither the UK govt (FCA) nor the framework itself
>> take any responsibility for even assuring that services are who they say
>> they are, which a EV cert does do.
>> That means that an approval of the FCA has less assurance than an EV cert.
>> Now tell me how many bank customers are expected to read these
>> stipulations on this site?
>> Who can provide these services?
>>
>> From January 2018, companies that are authorised or registered by the
>> Financial Conduct Authority, or another European regulator, can provide AIS
>> or PIS.
>>
>> The FCA and other European Regulators will add AIS and PIS providers to
>> the registers they keep of all authorised businesses. These registers are
>> publically available. You can access the FCA’s register
>> <https://register.fca.org.uk/> to search for a business or contact our consumer
>> helpline <https://www.fca.org.uk/contact>.
>>
>> You should be aware that companies that have been providing these
>> services since before 12 January 2016 do not need to be authorised by the
>> FCA until the end of 2019, so may not appear on the FCA’s register until a
>> later date.
>>
>> *Before you use one of these services be alert, and make sure you are
>> confident that any organisations you share your information with are who
>> they say they are. You should make sure that you understand the service and
>> that you are happy with who will be providing it to you.*
>>
>>
>> Peace ..tom
>>
>> On Mon, Feb 26, 2018 at 7:50 AM, Tom Jones <thomasclinganjones at gmail.com>
>> wrote:
>>
>>> The gotcha is the determination of what was unauthorized. I recall that
>>> during the ATM wars a policeman lost his job solely because he had the
>>> temerity to claim that an ATM withdrawal was unauthorized. He turned out to
>>> have been correct.
>>>
>>> ..Tom's phone
>>>
>>> On Feb 26, 2018, at 8:33 AM, Joseph Heenan via Openid-specs-fapi <
>>> openid-specs-fapi at lists.openid.net> wrote:
>>>
>>> Hi Tom,
>>>
>>> Under the UK OpenBanking model, the bank is required to make immediate
>>> refunds for any unauthorised transactions (and if a TPP was involved and
>>> negligent, the bank can then try to reclaim that money from the TPP). The
>>> only exception is if the bank suspects fraud or negligence by the user. I
>>> believe that setup comes from the EU wide PSD2 requirements (but others
>>> know that area better than I do).
>>>
>>> How this actually works in practice remains to be seen, as this has only
>>> been in place for about 6 weeks.
>>>
>>> Joseph
>>>
>>>
>>> On 26 Feb 2018, at 15:02, Tom Jones via Openid-specs-fapi <
>>> openid-specs-fapi at lists.openid.net> wrote:
>>>
>>> the user does not authorize to Zelle. It is just a transport protocol.
>>> It can either send or request a payment. All the rest is on the user's
>>> account using the web browser or the bank app. Theoretically the user could
>>> pre-authorize payment requests, but my banks do not do that. Unlike the ACH
>>> where pre-auth is common, but not automated.
>>>
>>> The fraud problem is that there are 6 parties to such a transaction
>>> (consumer, merchant, PISP, bank, UK gov't, attacker). The only party that
>>> does not understand the system is the consumer, who is the only one that
>>> bears risk of loss in the UK model. Every other party loses no money no
>>> matter what happens. This has been tried before in the UK when then ATMs
>>> were introduced. It did not go well for the consumer.
>>> http://www.cl.cam.ac.uk/~rja14/banksec.html Trust is an illusion.
>>>
>>>
>>> Peace ..tom
>>>
>>> On Sun, Feb 25, 2018 at 11:01 PM, Anders Rundgren <
>>> anders.rundgren.net at gmail.com> wrote:
>>>
>>>> On 2018-02-25 16:11, Tom Jones wrote:
>>>>
>>>>> As near as I can tell Zelle is under user control and ok.
>>>>>
>>>>
>>>> I'm sure Zelle is just fine, my "techie" question is if the bank gets
>>>> anything tangible from the user's authorization to Zelle.
>>>>
>>>>
>>>> The truly evil organization will be the PISP if it is allowed to
>>>>> operate on the users’ behalf with contracts of adhesion.
>>>>>
>>>>
>>>> Well, this appears to be the master plan in the UK.  FAPI/OAuth is
>>>> essentially morphing into an enrollment system for *persistent* business
>>>> relations between three parties.
>>>>
>>>> This is not common knowledge and may turn out as a source of
>>>> non-interoperability (at the policy level).
>>>>
>>>> Other side effects include something the traditional PSPs didn't have
>>>> to bother with: Authentication of end users.
>>>>
>>>>
>>>> Fraud will basically be be legalized.
>>>>>
>>>>
>>>> The technical capability to perform fraud is more or less a part of
>>>> most TTPs, be it a CA or a PSP. Trust in services is a combination of
>>>> regulations, reputation, marketing, and time.
>>>>
>>>>
>>>>
>>>> The one limiting factor, at least so far as xborder flows go, is
>>>>> government control of “hot money”. There are good articles just now on the
>>>>> linkage between kleptocrats and hot money in the Journal of democracy. I
>>>>> thoroughly recommend them to any thoughtful discussion of this threat. I
>>>>> suspect that the last thing governments want is friction free money flows.
>>>>>
>>>>> ..Tom's phone
>>>>>
>>>>> On Feb 25, 2018, at 12:07 AM, Anders Rundgren via Openid-specs-fapi <
>>>>>> openid-specs-fapi at lists.openid.net> wrote:
>>>>>>
>>>>>> On 2018-02-25 03:44, n-sakimura via Openid-specs-fapi wrote:
>>>>>>> Could you guys please elaborate a little more?
>>>>>>>
>>>>>>
>>>>>> Note: If this list is exclusively intended for discussing pure
>>>>>> technical issues with the specification rather than the environment where
>>>>>> it is supposed to used, this message has landed in the wrong forum.
>>>>>>
>>>>>>
>>>>>> As far as I understand the decoupled authentication model is indeed
>>>>>> used by US TTPs like "Venmo" and "Zelle".
>>>>>>
>>>>>> However, all these systems are proprietary and secret so I'm just
>>>>>> guessing here.
>>>>>>
>>>>>> Going back to the UK and EU, the idea is that independent payment
>>>>>> providers compete with fees, core features, and user interfaces.  This can
>>>>>> only be realized if each of them run a network of their own [1] including
>>>>>> authentication of customers.
>>>>>>
>>>>>> This has major implications beyond security.  In theory this concept
>>>>>> will foster innovation and competition. In practice it will probably rather
>>>>>> lead to fragmentation [2] and after an expected shakeout [3], reduce the
>>>>>> number of national players to one or two which is essentially the opposite
>>>>>> to the (good) intention.
>>>>>>
>>>>>> The Scandinavian banks separated their Open Banking and Mobile
>>>>>> Payment efforts with exceptionally good results (adoption rate) for the
>>>>>> latter.
>>>>>>
>>>>>> Cheers,
>>>>>> Anders
>>>>>>
>>>>>> 1] "Pass-through" services like PISPs offer limited power and
>>>>>> flexibility
>>>>>> 2] All "Apps" behave differently making consumers and merchants
>>>>>> unhappy
>>>>>> 3] The current consolidation among payment providers shows that
>>>>>> volume is everything
>>>>>>
>>>>>> Nat Sakimura
>>>>>>> このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご
>>>>>>> 連絡のうえ、このメールを削除してくださいますようお願い申し上げます。
>>>>>>> PLEASE READ:This e-mail is confidential and intended for the named
>>>>>>> recipient only. If you are not an intended recipient, please notify the
>>>>>>> sender and delete this e-mail.
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------------------------------------
>>>>>>> ------------------------------
>>>>>>> *From:* Openid-specs-fapi <openid-specs-fapi-bounces at lis
>>>>>>> ts.openid.net> on behalf of Tom Jones via Openid-specs-fapi <
>>>>>>> openid-specs-fapi at lists.openid.net>
>>>>>>> *Sent:* Sunday, February 25, 2018 4:24:06 AM
>>>>>>> *To:* Financial API Working Group List
>>>>>>> *Cc:* Tom Jones
>>>>>>> *Subject:* Re: [Openid-specs-fapi] The FAPI Security Model - Under
>>>>>>> Fire
>>>>>>> yeah, that fits the UK business model.
>>>>>>> It wont fly in the US however.
>>>>>>> Peace ..tom
>>>>>>> On Thu, Feb 22, 2018 at 11:53 PM, Anders Rundgren via
>>>>>>> Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:
>>>>>>> openid-specs-fapi at lists.openid.net>> wrote:
>>>>>>>     Hi FAPIers,
>>>>>>>     As a curious person I have always wondered how Open
>>>>>>> Banking/PISP/SCA would combine with Amazon's famous one-click checkout.
>>>>>>>     Various LinkedIn and Slack conversations have revealed the
>>>>>>> (ugly?) truth.
>>>>>>>     The intention (at least in the UK), is giving OAuth tokens
>>>>>>> "eternal life" and rather letting PISPs (Amazon is expected to be a one),
>>>>>>> deal with payer authorization.  This faithfully emulates the "card-on-file"
>>>>>>> system that powers most US based super providers.
>>>>>>>     Cheers,
>>>>>>>     Anders
>>>>>>>     _______________________________________________
>>>>>>>     Openid-specs-fapi mailing list
>>>>>>>     Openid-specs-fapi at lists.openid.net <mailto:
>>>>>>> Openid-specs-fapi at lists.openid.net>
>>>>>>>     http://lists.openid.net/mailman/listinfo/openid-specs-fapi <
>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi>
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-fapi mailing list
>>>>>>> Openid-specs-fapi at lists.openid.net
>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Openid-specs-fapi mailing list
>>>>>> Openid-specs-fapi at lists.openid.net
>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> Openid-specs-fapi mailing list
>>> Openid-specs-fapi at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-fapi mailing list
>>> Openid-specs-fapi at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>
>>
>
>
> --
> Dave Tonge
> CTO
> [image: Moneyhub Enterprise]
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
> 10 Temple Back, Bristol, BS1 6FL
> <https://maps.google.com/?q=10+Temple+Back,+Bristol,+BS1+6FL&entry=gmail&source=g>
> t: +44 (0)117 280 5120 <+44%20117%20280%205120>
>
> Moneyhub Enterprise is a trading style of Momentum Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Momentum Financial Technology is entered on the
> Financial Services Register (FRN 561538) at fca.org.uk/register. Momentum
> Financial Technology is registered in England & Wales, company registration
> number 06909772 © . Momentum Financial Technology Limited 2016. DISCLAIMER:
> This email (including any attachments) is subject to copyright, and the
> information in it is confidential. Use of this email or of any information
> in it other than by the addressee is unauthorised and unlawful. Whilst
> reasonable efforts are made to ensure that any attachments are virus-free,
> it is the recipient's sole responsibility to scan all attachments for
> viruses. All calls and emails to and from this company may be monitored and
> recorded for legitimate purposes relating to this company's business. Any
> opinions expressed in this email (or in any attachments) are those of the
> author and do not necessarily represent the opinions of Momentum Financial
> Technology Limited or of any other group company.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180302/f3c9df47/attachment-0001.html>


More information about the Openid-specs-fapi mailing list