<div dir="ltr"><div>Hi,</div><div dir="ltr"><br></div><div dir="ltr">> For example, the trust chain works differently than what I was used too in X.509. In X.509, the intermediary or trust anchor </div><div dir="ltr">> would issue a certificate binding certain attributes of an entity to the public key of this entity. In federation, the chain starts</div><div dir="ltr">> with a self-signed statement of the entity about itself. The intermediary or trust anchor then seems to vouch for the public key</div><div dir="ltr">> 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</div><div dir="ltr">> completely sure I understood how entity statements, metadata and federation api relate to each other and work together. <br>
><br>> I think an overview describing and motivating the design concepts and principles would be helpful to readers. <br></div><div dir="ltr"><br></div><div>We also made a similar observation when trying to employ this specification.</div><div>Namely it is not intuitive how an intermediate or trust anchor could express metadata information about an entity it vouches for.</div><div><br></div><div>As per 2.1 metadata claim is only possible if iss==sub, meaning only for the self-statement and forbidden for all other cases.</div><div>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:</div><div><br></div><div><span id="gmail-docs-internal-guid-77aff23d-7fff-e138-8b3c-e6a462a84cc6"><p dir="ltr" style="line-height:1.2;border-left:0.5pt solid rgb(0,0,0);border-right:0.5pt solid rgb(0,0,0);border-top:0.5pt solid rgb(0,0,0);margin-top:0pt;margin-bottom:0pt;padding:1pt 4pt 0pt"><span style="font-size:10pt;font-family:"Courier New";color:rgb(0,0,0);font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap;background-color:rgb(255,255,255)"> "metadata_policy": {</span></p><p dir="ltr" style="line-height:1.2;border-left:0.5pt solid rgb(0,0,0);border-right:0.5pt solid rgb(0,0,0);margin-top:0pt;margin-bottom:0pt;padding:0pt 4pt"><span style="color:rgb(0,0,0);font-family:"Courier New";font-size:10pt;white-space:pre-wrap"> "openid_relying_party": {</span><br></p><p dir="ltr" style="line-height:1.2;border-left:0.5pt solid rgb(0,0,0);border-right:0.5pt solid rgb(0,0,0);margin-top:0pt;margin-bottom:0pt;padding:0pt 4pt"><font color="#000000" face="Courier New"><span style="font-size:13.3333px;white-space:pre-wrap">...</span></font></p><p dir="ltr" style="line-height:1.2;border-left:0.5pt solid rgb(0,0,0);border-right:0.5pt solid rgb(0,0,0);margin-top:0pt;margin-bottom:0pt;padding:0pt 4pt"><span style="font-size:10pt;font-family:"Courier New";color:rgb(0,0,0);font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap;background-color:rgb(255,255,255)"> "organization_name": {"value": "NTNU"},</span></p><p style="line-height:1.2;border-left:0.5pt solid rgb(0,0,0);border-right:0.5pt solid rgb(0,0,0);margin-top:0pt;margin-bottom:0pt;padding:0pt 4pt"><span style="font-size:10pt;font-family:"Courier New";color:rgb(0,0,0);font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap;background-color:rgb(255,255,255)"> "trust_level": {"value": 2},</span></p><p dir="ltr" style="line-height:1.2;border-left:0.5pt solid rgb(0,0,0);border-right:0.5pt solid rgb(0,0,0);margin-top:0pt;margin-bottom:0pt;padding:0pt 4pt"><span style="font-size:10pt;font-family:"Courier New";color:rgb(0,0,0);font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap;background-color:rgb(255,255,255)">...</span></p><p dir="ltr" style="line-height:1.2;border-left:0.5pt solid rgb(0,0,0);border-right:0.5pt solid rgb(0,0,0);margin-top:0pt;margin-bottom:0pt;padding:0pt 4pt"><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-size:10pt;font-family:"Courier New";color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap"> }</span><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-size:10pt;font-family:"Courier New";color:rgb(0,0,0);font-weight:700;vertical-align:baseline;white-space:pre-wrap">,</span><br></p><p dir="ltr" style="line-height:1.2;border-left:0.5pt solid rgb(0,0,0);border-right:0.5pt solid rgb(0,0,0);margin-top:0pt;margin-bottom:0pt;padding:0pt 4pt"><span style="color:rgb(0,0,0);font-family:"Courier New";font-size:10pt;white-space:pre-wrap"> },</span><br></p></span><br class="gmail-Apple-interchange-newline"></div><div>This is however semantically not the same as X issuing a statement that Y has a name of "NTNU" and trust level 2.</div><div><br></div><div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Kind Regards,<div>Pawel</div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 30 May 2021 at 18:38, Torsten Lodderstedt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
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. <br>
<br>
— Design Principles and overall architecture<br>
<br>
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. <br>
<br>
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. <br>
<br>
I think an overview describing and motivating the design concepts and principles would be helpful to readers. <br>
<br>
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 ;-). <br>
<br>
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 …). <br>
<br>
— OAuth Entities<br>
<br>
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. <br>
<br>
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? <br>
<br>
What is the envisioned use case for federation and protected resources? Authentication during Token Introspection? <br>
<br>
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. <br>
<br>
best regards,<br>
Torsten. <br>
<br>
> Am 26.05.2021 um 01:27 schrieb Mike Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>:<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> The updated specification is published at:<br>
> • <a href="https://openid.net/specs/openid-connect-federation-1_0-16.html" rel="noreferrer" target="_blank">https://openid.net/specs/openid-connect-federation-1_0-16.html</a><br>
> <br>
> Thanks to Roland Hedberg for the updates!<br>
> <br>
> -- Mike<br>
> <br>
> P.S. This notice was also published at <a href="https://self-issued.info/?p=2175" rel="noreferrer" target="_blank">https://self-issued.info/?p=2175</a> and as @selfissued.<br>
> <br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> <a href="https://www.google.com/url?q=http://lists.openid.net/mailman/listinfo/openid-specs-ab&source=gmail-imap&ust=1622590063000000&usg=AOvVaw2i5PgBKac2neSEmFk88BZd" rel="noreferrer" target="_blank">https://www.google.com/url?q=http://lists.openid.net/mailman/listinfo/openid-specs-ab&source=gmail-imap&ust=1622590063000000&usg=AOvVaw2i5PgBKac2neSEmFk88BZd</a><br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div></div>