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

Chris Phillips Chris.Phillips at canarie.ca
Thu Aug 16 17:09:51 UTC 2018


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
    



More information about the Openid-specs-ab mailing list