[Openid-specs-ab] OpenID Connect Federation updated in preparation for third Implementer’s Draft review

Torsten Lodderstedt torsten at lodderstedt.net
Sun May 30 16:38:33 UTC 2021


here is my review feedback. This is the result of my first full review, I only reviewed the authentication part of this draft in the past. Bear with me if I ask questions or share observations that were already discussed before. 

— Design Principles and overall architecture

The draft seems to be based on a lot of experience and a sounding foundation. For me as a first time reader, the concepts and design principles were not that obvious on first read. 

For example, the trust chain works differently than what I was used too in X.509. In X.509, the intermediary or trust anchor would issue a certificate binding certain attributes of an entity to the public key of this entity. In federation, the chain starts with a self-signed statement of the entity about itself. The intermediary or trust anchor then seems to vouch for the public key of the entity the respective federation policy is about? That’s not fully clear to me, perhaps I’m the only one.  Moreover, I’m not completely sure I understood how entity statements, metadata and federation api relate to each other and work together.  

I think an overview describing and motivating the design concepts and principles would be helpful to readers. 

I would also appreciate an explanation why the federation draft design is better suited for the envisioned use cases than X.509 certificates. Deployments need to be convinced to invest into a pretty new solution with a lot of runtime overhead (latency and availability implications!) while X.509 is used for the same/similar (?) applications in the wild. I’m pretty sure there a good arguments ;-). 

The example in A.1 proved very useful to grasp the concepts, I think it would benefit from an explanation of what it takes to setup a federation (how needs to setup which endpoints, what statements need to be requested using what data …). 

— OAuth Entities

I like the fact this draft also considers OAuth entities because I think most identity federations are or will (also) turn into OAuth-based federations for delegated authorization simply because web SSO is complemented by APIs. Our scheme already is in this stage. 

In such a situation, an OAuth AS is most likely also an OpenID Connect OP. Same holds for clients, which also can be RPs. How would that be captured? 

What is the envisioned use case for federation and protected resources? Authentication during Token Introspection? 

Also, the document mostly refers to OpenID Connect discovery and dynamic client registration. How is the federation draft supposed to work with the OAuth counterparts? OAuth Server Metadata (RFC 8414) is mention but OAuth Dynamic Client Registration (RFC 7591) is mentioned in 3.4 only but not in 9.2.1. 

best regards,

> Am 26.05.2021 um 01:27 schrieb Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net>:
> The OpenID Connect Federation specification has been updated to add Security Considerations text.  As discussed in the recent OpenID Connect working group calls, we are currently reviewing the specification in preparation for it becoming the third and possibly last Implementer’s Draft.
> Working group members (and others!) are encouraged to provide feedback on the draft soon before we start the foundation-wide review.  We will probably decide next week to progress the draft to foundation-wide review.  In particular, there’s been interest recently in both Entity Statements and Automatic Registration among those working on Self-Issued OpenID Provider extensions.  Reviews of those features would be particularly welcome.
> The updated specification is published at:
> Thanks to Roland Hedberg for the updates!
>                                                        -- Mike
> P.S.  This notice was also published at https://self-issued.info/?p=2175 and as @selfissued.
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://www.google.com/url?q=http://lists.openid.net/mailman/listinfo/openid-specs-ab&source=gmail-imap&ust=1622590063000000&usg=AOvVaw2i5PgBKac2neSEmFk88BZd

More information about the Openid-specs-ab mailing list