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

Roland Hedberg roland at catalogix.se
Sat Sep 4 06:22:39 UTC 2021


To answer Torsten’s email I’ve added some text in the specification on design principles/architecture.
I’ve also added a section to appendix 1 on what it takes to set up a federation.
There is also a line explicitly mentioning the possibility of a OAuth2 federation.

All this is in the GitHub master:

https://github.com/rohe/oidcfederation <https://github.com/rohe/oidcfederation>


> On 30 May 2021, at 18:38, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> 
> Hi,
> 
> 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,
> Torsten. 
> 
>> 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:
>>https://openid.net/specs/openid-connect-federation-1_0-16.html
>> 
>> 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
> 

— Roland

The higher up you go, the more mistakes you are allowed. Right at the top, if you make enough of them, it's considered to be your style. 
-Fred Astaire, dancer, actor, singer, musician, and choreographer (10 May 1899-1987)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210904/51db62ad/attachment.html>


More information about the Openid-specs-ab mailing list