<div dir="ltr">> It also means that the specification allows the leaf entity to update its metadata without asking all its superiors if it can.<div><div>True and this is fine in many respects when it comes to "technical" metadata, like encryption, capabilities etc.</div><div>I think it's not fitting well when it comes to trust related information, which can be expected to be vetted by the federation in some way.</div><div><br></div></div><div>> Whether that is how it will work in reality is anyones guess. In some contexts it’s absolutely OK in other maybe not.<br></div><div><div>> It’s your choice the specification doesn’t force you to do it in one specific way.</div><div>The issue I see is that by not allowing metadata object in the case of sub != iss it's difficult to express trusted relations other than binary: is part of federation or not.</div><div>It can also be that the trust is not in the scope of Federations spec, or metadata is not the right place to express it.</div><div>From my perspective trust is an important part of any Federation and we should think how the specification can support it the best way.</div><div><br></div><div>> Now if an intermediate feels responsible for it’s subordinates I would expect it to regularly check that the subordinates metadata</div><div>> is within the prescribed boundaries.</div><div>Yes, this is possible, as well as it's possible to express things via metadata_policy.</div><div>None of these approaches is straightforward and IMHO an expression of an intermediate to tell sth about subordinate could be more direct and simple.</div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Kind Regards,<div>Pawel</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 30 Jun 2021 at 10:45, Roland Hedberg <<a href="mailto:roland@catalogix.se">roland@catalogix.se</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"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On 31 May 2021, at 12:01, Pawel Kowalik via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:</div><br><div><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,</div></div></div></blockquote><div><br></div>Correct !</div><div><br><blockquote type="cite"><div><div dir="ltr"><div> like in this example:</div><div><br></div><div><span id="gmail-m_-3517506350151676886gmail-docs-internal-guid-77aff23d-7fff-e138-8b3c-e6a462a84cc6"><div 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";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></div><div 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-family:"Courier New";font-size:10pt;white-space:pre-wrap">    "openid_relying_party": {</span><br></div><div 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 face="Courier New"><span style="font-size:13.3333px;white-space:pre-wrap">...</span></font></div><div 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";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></div><div 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";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></div><div 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";font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap;background-color:rgb(255,255,255)">...</span></div><div 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";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";font-weight:700;vertical-align:baseline;white-space:pre-wrap">,</span><br></div><div 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-family:"Courier New";font-size:10pt;white-space:pre-wrap">  },</span><br></div></span><br></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></div></blockquote><div><br></div>No, it’s not,<br><br></div><div>OK, so the notion was that since a leaf entity not necessarily knows which federations it belongs to, it just publishes</div><div>everything it can do and then it’s up to the opponent to figure out using policies what actually should be used in a</div><div>federation the entity belongs to.</div><div><br></div><div>This means that the intermediate doesn’t vouch for any information the leaf entity is publishing (except for the JWKS)</div><div>it just places boundaries on what of it should be used.</div><div><br></div>It also means that the specification allows the leaf entity to update its metadata without asking all its superiors if it can.<div>Whether that is how it will work in reality is anyones guess. In some contexts it’s absolutely OK in other maybe not.</div><div>It’s your choice the specification doesn’t force you to do it in one specific way.</div><div>Now if an intermediate feels responsible for it’s subordinates I would expect it to regularly check that the subordinates metadata</div><div>is within the prescribed boundaries.</div><div><div><div><br><div>
<div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">— Roland</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Scratch a pessimist and you find often a defender of privilege. -William Beveridge, economist and reformer (5 Mar 1879-1963) </div>
</div>
<br></div></div></div></div></blockquote></div>