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

Sat Sep 4 06:25:39 UTC 2021

Hi Pawel,

That a superior can not issue statements about a subordinates claims are by design.
Entities can only make statements about themselves.

Having superiors only being able to issue policies allows the subordinate to evolve its functionality 
within the bounds set by the superior.

> On 31 May 2021, at 12:01, Pawel Kowalik via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> Hi,
> 
> > 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. 
> 
> We also made a similar observation when trying to employ this specification.
> Namely it is not intuitive how an intermediate or trust anchor could express metadata information about an entity it vouches for.
> 
> As per 2.1 metadata claim is only possible if iss==sub, meaning only for the self-statement and forbidden for all other cases.
> The only way an intermediate X may say something about a leaf Y is through metadata_policy by enforcing a value, like in this example:
> 
>  "metadata_policy": {
>     "openid_relying_party": {
> ...
>       "organization_name": {"value": "NTNU"},
>       "trust_level": {"value": 2},
> ...
>     },
>   },
> 
> This is however semantically not the same as X issuing a statement that Y has a name of "NTNU" and trust level 2.
> 
> Kind Regards,
> Pawel
> 
> 
> On Sun, 30 May 2021 at 18:38, Torsten Lodderstedt via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.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 <mailto: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 <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 <https://self-issued.info/?p=2175> and as @selfissued.
> >  
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net <mailto: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 <https://www.google.com/url?q=http://lists.openid.net/mailman/listinfo/openid-specs-ab&source=gmail-imap&ust=1622590063000000&usg=AOvVaw2i5PgBKac2neSEmFk88BZd>
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

“The first principel is that you must not fool yourself — and you are the easiest person to fool” 
— Richard Feynman

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