[Openid-specs-ab] Comments on Solberg JWT Federation
Michael.Jones at microsoft.com
Thu Aug 16 15:26:37 UTC 2018
Thanks for writing, Steffen. For what it's worth, mobile applications were one of the design points for OpenID Connect. Connect is widely used for authenticating mobile applications, both on Android and iOS (often using the AppAuth libraries supported by this working group).
At least as a thought experiment, it would seem to me that since banks are somehow able to trust their mobile applications sufficiently to let their customers perform financial transactions with them, that surely we should be able to trust some mobile applications sufficiently to let them participate in federations.
I'd encourage people who are experts in using Connect with mobile applications to also weigh in on how to enable them in federations.
From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Steffen Klemer via Openid-specs-ab
Sent: Monday, August 6, 2018 1:54 AM
To: openid-specs-ab at lists.openid.net
Cc: Steffen Klemer <klemer at dfn.de>
Subject: Re: [Openid-specs-ab] Comments on Solberg JWT Federation
> I think that trends and new requirements would make it interesting to
> discuss the ability for SPAs and native apps to establish their own
> credentials (self generated key pairs). This will result in separate
> client_ids for each deployent, while the redirect_uris would be
> shared. How we build the federated infrastructure have consequences
> for how easy it would be to build and how smooth this will run.
I was thinking about the native app-scenario in a federation in some length and couldn't find a way to extend the trust into the mobile app; no matter which technology one assumes. The inherent problem I see is the non-trustworthyness of the administrator of the devices. You don't know her and even if you know her (by some out-of-band mechanism of the app distribution) you can't know that she doesn't tamper with your code or executes it in a tampered environment. You can't trust that they do what they tell they do. The point of federations as I understand them is that by some mechanism you trust the entities. This can never be said about apps.
To put it differently: I'd say it's not worth to consider the app-client scenario for the federation specs.
Every time I discussed this with people we ended in a scenario that somehow has an classical web server as the federation entity/SP/RP that acts as some kind of proxy for the app to get it trustworthy/secure from the point of view of the federation. For example by handing it oauth-tokens after federation login to access the secured content. It's very hard (for me) to imagine a real-world app that needs some federation awareness that does not use this knowledge to access other web services (e.g. via oauth) but only locally stored data. (so the federation is used a bit like a software-license server)
DFN-Verein Steffen Klemer
Alexanderplatz 1 +49 30 884299 307
10178 Berlin klemer at dfn.de
Fax: 030 88 42 99 370
More information about the Openid-specs-ab