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

[Steffen Klemer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7249 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180806/8076442e/attachment.p7s>