[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.


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

-------------- 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