<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>The idea of being able to separate the registration service from the authentication service predates software statements.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We sort of dropped it in favor of using a software statement to dynamically register.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>However in open banking and other federation type deployments we do see a desire to centrally manage clientID.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I mentioned it because we can consider these other approaches, it may turn out that software statements give us more flexibility in negotiating capabilities.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For central registration you can encode the info in the client_id or dereference it, or possibly use a hybrid approach of including the id and a reference in a signed JWT to use as the client ID to reduce size and allow updating.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>To keep Leif happy I would also sign the data pointed to by the refrence and not rely completely on TLS<span style='font-family:"Segoe UI Emoji",sans-serif'>😊</span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John B.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal> </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:sakimura@gmail.com">Nat Sakimura</a><br><b>Sent: </b>Friday, August 3, 2018 2:12 AM<br><b>To: </b><a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net Ab</a><br><b>Cc: </b><a href="mailto:ve7jtb@ve7jtb.com">John Bradley</a><br><b>Subject: </b>Re: [Openid-specs-ab] OpenID Connect Federation Design</p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><a href="https://datatracker.ietf.org/doc/draft-bradley-oauth-stateless-client-id/" target="_blank">https://datatracker.ietf.org/doc/draft-bradley-oauth-stateless-client-id/</a> may now get some more traction, do not you think? > John</p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Fri, Aug 3, 2018 at 7:09 AM John Bradley via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:</p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Anyone can join a WG call.   </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>To actively participate and post on the list you need to sign the IPR non assert for the WG.</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>You can do it electronically from this page. </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a href="https://openid.net/intellectual-property/" target="_blank">https://openid.net/intellectual-property/</a></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Andreas raises some good points.</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The main reason for keeping the client registration step is that is required to support the legacy of symmetric OAuth credentials. </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>If we acknowledge that symmetric credential authentication is a bad thing that potentially allows us to move in this proposed direction.</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The only other reason for keeping per client registration would be to negotiate specific capabilities with each AS.  I know SAML has gotten by without that, and I suspect that it is not a bad tradeoff when dealing with a federation, but it is something to keep in mind.</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I did do a OAuth spec for stateless client_id a long time ago.</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>It didn’t get much interest at the time.</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a href="https://datatracker.ietf.org/doc/draft-bradley-oauth-stateless-client-id/" target="_blank">https://datatracker.ietf.org/doc/draft-bradley-oauth-stateless-client-id/</a></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>We should discuss the advantages and disadvantages of the approaches on the call.</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>John B.</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986" target="_blank">Mail</a> for Windows 10</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From: </b><a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">Leif Johansson via Openid-specs-ab</a><br><b>Sent: </b>Thursday, August 2, 2018 12:30 PM<br><b>To: </b><a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br><b>Cc: </b><a href="mailto:leifj@mnt.se" target="_blank">Leif Johansson</a><br><b>Subject: </b>Re: [Openid-specs-ab] OpenID Connect Federation Design</p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On 2018-08-02 08:58, Andreas Åkre Solberg via Openid-specs-ab wrote:</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> I wrote a new article trying to explain and compare two alternative</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> designs for trust chains for OpenID Connect Federations:</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> <a href="https://oauth.no/trust/" target="_blank">https://oauth.no/trust/</a></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> I would really appreciate others comments on this. I hope there is room</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> for *discussions* on these fundamental design choices, regardless of the</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> /implementer’s draft/ status of the currently proposed specification.</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I would like to have a discussion about this proposal. I am however</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>unfamiliar with the processes that govern the OIDF.</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>        Cheers Leif</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>_______________________________________________</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Openid-specs-ab mailing list</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p></div></div><p class=MsoNormal>_______________________________________________<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" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></p></blockquote></div><p class=MsoNormal><br clear=all></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- </p><div><p class=MsoNormal>Nat Sakimura (=nat)</p></div><p class=MsoNormal>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>