[Openid-specs-ab] An alternative approach to OpenID Connect Federations

Andreas Åkre Solberg andreas.solberg at uninett.no
Thu Jul 26 14:19:00 UTC 2018


First, I’d like to appologize for not being active on this list (yet). I have some opinions when it comes to the design of OpenID Connect Federations.

I think it is crucial that we build a flexible trust infrastructure that can handle more generic federations of entities sharing data, and not just supporting end-user authentication. Federations for end-user authentication were already solved 10 years ago, and now the use cases that needs to be solved are far more complex.

I’ve tried to draft such a specification for trust between entities, and how OpenID Connection would work on top of that.

https://oauth.no/jwtfederations/

I’d really appreciate feedback on this work. Note that this spec deviates from the current OpenID Connect Federation specification that is up for vote.

Here are some of the major differences:
* it does not rely on client registrations - because that does not scale
* it does rely on asymetric keys - becauce that scales
* it makes use of webfinger for trust and metadata discovery in both directions - discoverying the client the same way that you discover a provider
* it does not rely on embedded JWTs, instead independent JWTs that is fetched from the entity it self. Embedding JWTs comes at a cost of added complexity, and does not really give any thing back.
* it enforces a stable client_id for all clients, which is also enforced to be globally unique, and is reused across federations. This has several benefits.
* it is rather easy to append the federation layer on top of a standard OIDC client / provider implementation. The webfinger resolve component can be deployed  independent from the rest, and the other part can be added as a middleware to the metadata store plugin of existing implementations.
* it does not involve the challenging state management of temporary secrets for each provider that times out and needs to invoke a new registration process each time.
* it does not involve the complexity of performing an updated client registration each time you change configuration/metadata on the client
* it is not limited to OpenID Connect, but can also be used for OAuth federations and other federations of entities sharing userdata orthogonal but interacting with the federation of end-user authentication.


Andreas Åkre Solberg
Senior Technical Architect
UNINETT – https://uninett.no
https://www.linkedin.com/in/andreassolberg/





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180726/0fffb3eb/attachment.html>


More information about the Openid-specs-ab mailing list