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

Steffen Klemer klemer at dfn.de
Fri Aug 17 09:22:31 UTC 2018

Perhaps to abstract and explain this a bit more:

In the bank scenario we have a federation with many SP but one IdP and
after you registered the OpenID-Connect RP, the app, the only thing you
can do is log in at that one IdP and then use the bank's API -- do your
financial stuff. Even if you mess with the app, only user's of that
bank may log in and the bank knows *who* uses the API and whom to blame
-- you had to log in with them.

The multi-IdP federation as we have them in the edu world have another
level of trust besides the end users. Every entity, IdPs, SPs, have to
trust each other (or this is what we like them to do ;) ). An IdP only
wants to release attributes/claims to SP that are approved by the
federation. A federation operator somehow 'checks' this SP before
allowing it into the federation. This usually happens by 'checking' and
trusting the administrator or administrative entity of the SP. You
might also check the SP itself but then you have to make sure that it
wasn't changed between the check and the time of it accessing the

In the app world this would mean you have to make sure that the app
code wasn't changed and/or the operating system doesn't change the
behaviour of the app. This could only be possible with completely
locked, non-root'able smartphones which we don't have at the moment.
Otherwise this would lead to a situation where everybody could just
register his RP in the federation. And the whole idea of the trusted
3rd party in the federation would be meaningless.

You could now construct a scenario where a user first has to log in
somewhere and with these credentials register the app as an RP in the
federation but 1st of all you get the same problems only one step
before and 2nd we usually don't see the users as part of the
federation. The universities, institutes etc. are part of it. We have
contracts with them forcing them to fulfill minimum standards but not
with their users.

The way we see to get out of this is: Build your app, give it a
login-page that shows the login-website of a server that belongs to
your app and is part of the federation; login there; have the server
hand the necessary claims, tokens, whatever to the app. That way only
the server has to be part of the federation.

Does this clarify things?


Am Do, 16.08.2018 um 17:09 schrieb Chris Phillips
<Chris.Phillips at canarie.ca>:

> I like the analogy Mike J however the example is an IdP of one -- the
> bank or in other words a bi-lateral trust of one. 
> A multi-lateral federation context is different. It's more like a
> neutral app that can be signed into by any number of Idps -- maybe
> thousands of possible originations but within THAT circle of trust
> and then do things.
> When the bank writes the app, I'm sure they bake in things for their
> interests, thus forcing copies of the same app over and over again
> because it's bilaterally trusting things and the only delivery
> container/security context is 'the app' because it's configured for
> the bank it was built for.
> It's not like I can download a 'transfer money app' and then sign
> into any of my banks with it and perform the same function as if I
> were within the same security context -- can I?
> C
> On 2018-08-16, 11:26 AM, "Openid-specs-ab on behalf of Mike Jones
> via Openid-specs-ab" <openid-specs-ab-bounces at lists.openid.net on
> behalf of openid-specs-ab at lists.openid.net> wrote:
>     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 

DFN-Verein             Steffen Klemer
Alexanderplatz 1       +49 30 884299 307
10178 Berlin           klemer at dfn.de

Fax: 030 88 42 99 370
-------------- 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/20180817/689a437e/attachment.p7s>

More information about the Openid-specs-ab mailing list