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

Mon Aug 20 20:35:54 UTC 2018

Minor comment:
I think the line in the "Entity statements, metadata and trust" section,
that says:

    "The *issued entity identifier* MUST be included as the |iss| claim."

should be modified to instead say:

    "The*issuer entity's entity identifier* MUST be included as the |iss| claim."

because, as written, I don't think the term "issued entity identifier" is semantically
meaningful.

   Thanks,
   Rich

On 8/17/2018 5:22 AM, Steffen Klemer via Openid-specs-ab wrote:
> 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
> federation.
>
> 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?
>
> Steffen
>
> 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
>>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20180820/66e44375/attachment.html>