<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>Anyone can join a WG call.   </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>To actively participate and post on the list you need to sign the IPR non assert for the WG.</p><p class=MsoNormal>You can do it electronically from this page. </p><p class=MsoNormal><a href="https://openid.net/intellectual-property/">https://openid.net/intellectual-property/</a></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Andreas raises some good points.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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><o:p> </o:p></p><p class=MsoNormal>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><o:p> </o:p></p><p class=MsoNormal>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><o:p> </o:p></p><p class=MsoNormal>I did do a OAuth spec for stateless client_id a long time ago.</p><p class=MsoNormal>It didn’t get much interest at the time.</p><p class=MsoNormal><a href="https://datatracker.ietf.org/doc/draft-bradley-oauth-stateless-client-id/">https://datatracker.ietf.org/doc/draft-bradley-oauth-stateless-client-id/</a></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We should discuss the advantages and disadvantages of the approaches on the call.</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>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:openid-specs-ab@lists.openid.net">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">openid-specs-ab@lists.openid.net</a><br><b>Cc: </b><a href="mailto:leifj@mnt.se">Leif Johansson</a><br><b>Subject: </b>Re: [Openid-specs-ab] OpenID Connect Federation Design</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On 2018-08-02 08:58, Andreas Åkre Solberg via Openid-specs-ab wrote:</p><p class=MsoNormal>> I wrote a new article trying to explain and compare two alternative</p><p class=MsoNormal>> designs for trust chains for OpenID Connect Federations:</p><p class=MsoNormal>> </p><p class=MsoNormal>> https://oauth.no/trust/</p><p class=MsoNormal>> </p><p class=MsoNormal>> I would really appreciate others comments on this. I hope there is room</p><p class=MsoNormal>> for *discussions* on these fundamental design choices, regardless of the</p><p class=MsoNormal>> /implementer’s draft/ status of the currently proposed specification.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I would like to have a discussion about this proposal. I am however</p><p class=MsoNormal>unfamiliar with the processes that govern the OIDF.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>        Cheers Leif</p><p class=MsoNormal>_______________________________________________</p><p class=MsoNormal>Openid-specs-ab mailing list</p><p class=MsoNormal>Openid-specs-ab@lists.openid.net</p><p class=MsoNormal>http://lists.openid.net/mailman/listinfo/openid-specs-ab</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>