[Openid-specs-fapi] FAPI meeting request - Mobile app access (Francis)

John Bradley ve7jtb at ve7jtb.com
Mon Jul 27 16:32:34 UTC 2020


FYI

At least on iOS 13/14 to use FIDO2/WebAuthn native apps  need to use the
AppAuth pattern.  

At some point in the future there may be a native API but at this point
doing FAPI/AppAuth is the only way to use apples WebAuthn implimentation.

John B.

On 7/27/2020 11:02 AM, Joseph Heenan via Openid-specs-fapi wrote:
>
>
>> On 27 Jul 2020, at 15:02, Anders Rundgren via Openid-specs-fapi
>> <openid-specs-fapi at lists.openid.net
>> <mailto:openid-specs-fapi at lists.openid.net>> wrote:
>>
>> Hello Francis,
>>
>> Can we take this slowly to not create unnecessary friction or hardships?
>>
>> I am claiming that:
>> - On-line banking applications usually call bank-servers directly.
>
> That’s incorrect; they almost always have a backend that talks to the
> underlying bank server.
>
>> - Such applications use some kind of API that in the end presumably
>> does quite similar things as Open Banking APIs.
>
> That varies a lot between banks. Some do not use anything you would
> think of as an API (for example, some bank mobile app backends
> generate significant amounts of html).
>
>> - Such applications are neither TPPs nor regulated.
>
> That’s incorrect; such applications are definitely regulated and banks
> have had to make changes to their apps due to PSD2, for example
> requiring SCA in places they didn’t before.
>
>> - Such applications use authentication solutions that the bank
>> consider sufficient.
>
> And, very very importantly, the bank is able to validate the identity
> of the calling application, because it is the bank’s own mobile app,
> and the app has (somehow) also proved to the bank server which PSU it
> is associated with.
>
>> - FIDO is currently held as the state-of-the-art for user authentication.
>> - FIDO is not a PKI solution.
>>
>> If any of the above is wrong, feel free to correct me.
>>
>> What I'm proposing is that it might be useful if such applications
>> could reuse the core of Open Banking APIs. This obviously needs
>> another "input channel" since the security model is entirely different.
>
> I’m aware of at least one bank where the mobile app is an oauth client
> that uses FAPI to obtain such an access token - albeit there are still
> some differences.
>
>>
>> Since on-line banking as well as mobile wallets are not standardized,
>> I'm only proposing a standardized mechanism [1] for connecting
>> trusted bank-local applications to Open Banking APIs.  BTW, a trusted
>> bank-local application may very well support a PSD2 compliant service.
>>
>> You claim that the Berlin Group cannot introduce this due to
>> regulatory requirements.
>> Since the Berlin Group is a member-driven organization shouldn't this
>> be up to the members to decide?
>>
>> OBIE is different because they got substantial government funding.
>
> OBIE’s protocol supports what I think you’re talking about with
> ‘direct mode':
>
> https://github.com/OpenBankingUK/read-write-api-docs-pub/blob/master/profiles/read-write-data-api-profile.md#consent-re-authentication-through-tpp
>
> (Which you’ll note just uses an existing standard, RFC7523, combined
> with the relevant FAPI requirements like send constrained access tokens.)
>
> But note that I’m not currently aware of any banks that have yet
> chosen to enter such an agreement with TPPs, as they’re not legally
> required to, and implying that no TPP has yet proposed something to
> the bank that is financially attractive for the bank. And (as already
> noted re: eIDAS etc), such APIs can’t really be used directly from
> third party mobile apps, due to the requirement to identify both the
> app/organisation and the user - i.e. the third party mobile app must
> have a bank end that verifies the call came from the third party’s
> app, as there’s really no way to have the bank validating a third
> parties app - or at least not a standardised way (the state of art on
> iOS generally involves a lot of what can be viewed as security through
> obscurity, which won’t be put into a published standard for hopefully
> obvious reasons).
>
> Thanks
>
> Joseph
>
>
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200727/56fd81a1/attachment-0001.html>


More information about the Openid-specs-fapi mailing list