
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi !<div class=""><br class=""></div><div class="">Thanks Torsten for your comments. I’ll start the answer with the design criteria we had:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">- So far we’ve seen a small number of federation models. One-to-many (Google's 1 OP, many RPs or Amazon's 1 RP and many OPs) and small to fairly large multi lateral federations like EduGAIN (~4400 OPs and 3300 RPs). All of them based on centralised static registration. In order to allow multi lateral federations to grow in size we think that it’s necessary to move to decentralised dynamic registration (imaging if SIOP takes off). </div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">- One-to-many OIDC federations normally uses dynamic provider info discovery but not dynamic client registration. </div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Which is not that surprising since classic OIDC client registration in essence is a leap of faith. There is no way you as an OP can </div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">verify that the client metadata is correct. We would like to make client registration more robust and allow OPs to verify</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">the correctness of the client metadata.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">- Federation policies will change over time (like moving from SHA1 to SHA256) we would like to support that and to have built-in</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">support for policies to change dynamically. Also, having decentralised entity registration we need a way to enforce federation policies.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">- OIDC and OAuth2 both have defined APIs for provider info discovery and client registration the federation specification should </div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">work equally well for both.</div><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">- The messages pushed around in this specification should not depend on TLS for their protection. </div><div class=""><br class=""></div><div class="">- We should when possible use functionally already present in OIDC libraries (like key handling, signed JWT verifications, JWKS, ..)</div><div class=""><br class=""></div><div class="">- We should only touch the initial OIDC RP<->OP communication phases (provider info discovery and client registration).</div><div class="">Now, this changed during the work of the specification so there now is one use case where we touch the authorization request.</div><div class=""><br class=""></div><div class="">- An entity (OP or RP) should be able to belong to more the one federation.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 30 May 2021, at 18:38, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" class="">torsten@lodderstedt.net</a>> wrote:</div><div class=""><div class=""><br class="">I think an overview describing and motivating the design concepts and principles would be helpful to readers. <br class=""><br class="">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 class=""></div></div></blockquote></div><br class=""><div class="">

<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;">— Roland</div><div style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;"><br class=""></div><div style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;">Were it left to me to decide whether we should have a government without newspapers, or newspapers without a government, I should not hesitate a moment to prefer the latter. -Thomas Jefferson, third US president, architect, and author (1743-1826) </div></div>

</div>

<br class=""></div></body></html>