[Openid-specs-fapi] Public Client Support

Joseph Heenan joseph at authlete.com
Thu Jan 3 05:06:04 UTC 2019

I think even if we remove it we should maintain a public client section that says something along the lines of:

"There do not currently appear to be any techniques that make public clients sufficiently secure to be considered Financial-grade for write operations.

Wherever possible, it is recommended to use dynamically registered confidential clients instead of public clients. Where the use of public clients is unavoidable, the recommendations in FAPI-R should be followed."

Possibly a recommendation to use token bound refresh tokens and access tokens should be included? (Though I’m not sure that today this is really a realistic recommendation given the lack of support for token binding in many popular technology stacks.)
Certainly I think we can mention https://tools.ietf.org/html/draft-ietf-oauth-mtls-12#section-4.3 "4.3.  Certificate Bound Access Tokens Without Client Authentication”. Device attestations may be worth a mention.

I think the first-party app case is interesting and I’d love to hear any insights around how first party banking apps (and for that matter, first party TPP apps that show banking data and/or allow the initiation of payments) work currently. I’m pretty certain the overwhelming majority do not use oauth and/or do not follow the native apps bcp. Without knowing what techniques the average app uses, it’s not clear to me what the level of acceptable security for a mobile banking app is today. The recent experience of moving to a new iPhone suggested to me that a non-negligible percentage do not use techniques like private keys tied to the device's Secure Enclave, which was a surprise.


> On 3 Jan 2019, at 00:26, Dave Tonge via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> Dear FAPI WG
> We very briefly discussed the issue of Public Client support on the call today and I said I'd email the list.
> We have two issues open:
> https://bitbucket.org/openid/fapi/issues/158/fapi-part-2-request-object-for-public <https://bitbucket.org/openid/fapi/issues/158/fapi-part-2-request-object-for-public>
> https://bitbucket.org/openid/fapi/issues/170/remove-public-client-support <https://bitbucket.org/openid/fapi/issues/170/remove-public-client-support>
> From my perspective the key argument to remove support for public clients is:
> It is harder to implement secure public clients, the spec would be simpler if we just removed support.
> The key argument to include support is:
> The FAPI specs are not just for use in PSD2 style APIs where a confidential client is required. Rather the specs are intended to also support first party clients, for example a bank or TPP implementing its own app. People will implement such apps using public clients so we should provide guidance on how to do it securely.
> It would be good to get feedback from the list on this. 
> Thanks
> -- 
> Dave Tonge
> _______________________________________________
> 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/20190103/141423c1/attachment.html>

More information about the Openid-specs-fapi mailing list