[Openid-specs-ab] Comments on Solberg JWT Federation

Jeff LOMBARDO jeff.lombardo at gmail.com
Thu Aug 16 15:40:54 UTC 2018


A small comment, hoping not to be out of bounds cause I still try to catch
up with the overload of information, some native App will have a role to
play in the Federation when interacting as local hosted OP in the SIIdP
scenario.

As support and preservation of OIDC Core was mentioned, we should not
overlook this part too.

JF

Le jeu. 16 août 2018, à 11 h 26, Mike Jones via Openid-specs-ab <
openid-specs-ab at lists.openid.net> a écrit :

> 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.
>
>                                 Best wishes,
>                                 -- Mike
>
> -----Original Message-----
> 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
>
> Hey,
>
> about this:
>
> > 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)
>
> Steffen
> --
> DFN-Verein             Steffen Klemer
> Alexanderplatz 1       +49 30 884299 307
> 10178 Berlin           klemer at dfn.de
>
>
> Fax: 030 88 42 99 370
> http://www.dfn.de
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180816/53736055/attachment-0001.html>


More information about the Openid-specs-ab mailing list