<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 reply to for the list is set to poster rather than list.   That is the way most of our lists are set up.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I guess that I have been trained over time to do reply all to get it to go to the list, and just don’t think about it any more.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Some of the lists are set to reply to list.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If people prefer to have replay as well as reply all go to the list I can change it.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I hope that explains it.</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:ve7jtb@ve7jtb.com">John Bradley</a><br><b>Sent: </b>Friday, July 20, 2018 1:17 PM<br><b>To: </b><a href="mailto:nroy@internet2.edu">Nick Roy</a><br><b>Cc: </b><a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net Ab</a><br><b>Subject: </b>RE: [Openid-specs-ab] Please Either ABSTAIN or OBJECT fromtheFederation Spec Vote</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Yes, that seems to be the case.   Strange.  I will have a look at the list settings, and see what has changed.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John<o:p></o:p></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<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From: </b><a href="mailto:openid-specs-ab@lists.openid.net">Nick Roy via Openid-specs-ab</a><br><b>Sent: </b>Friday, July 20, 2018 11:19 AM<br><b>To: </b><a href="mailto:phil.hunt@oracle.com">Phil Hunt</a><br><b>Cc: </b><a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br><b>Subject: </b>Re: [Openid-specs-ab] Please Either ABSTAIN or OBJECT from theFederation Spec Vote<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>As shown by both my and Phil's accidental replies off-list, there also<o:p></o:p></p><p class=MsoNormal>seems to be a list configuration issue which sets the reply-to address<o:p></o:p></p><p class=MsoNormal>as the address of the poster, rather than the address of the list.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Nick<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On 7/20/18 9:17 AM, Phil Hunt wrote:<o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>> Phil<o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>>> On Jul 20, 2018, at 8:16 AM, Phil Hunt <phil.hunt@oracle.com> wrote:<o:p></o:p></p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> I agree with Nick. The correct process (as i sort of understand it) and discussion was followed. <o:p></o:p></p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> That said I have complained many times because of issues like this that the WG processes are not published and wg consensus is almost never called. <o:p></o:p></p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> There is too much rush to implementation without a last call. <o:p></o:p></p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> This is a serious problem the board must resolve.  <o:p></o:p></p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>> Phil<o:p></o:p></p><p class=MsoNormal>>><o:p> </o:p></p><p class=MsoNormal>>>> On Jul 20, 2018, at 7:34 AM, Nick Roy via Openid-specs-ab <openid-specs-ab@lists.openid.net> wrote:<o:p></o:p></p><p class=MsoNormal>>>><o:p> </o:p></p><p class=MsoNormal>>>> This time to the list...<o:p></o:p></p><p class=MsoNormal>>>><o:p> </o:p></p><p class=MsoNormal>>>>> On Jul 20, 2018, at 8:30 AM, Nick Roy <nroy@internet2.edu> wrote:<o:p></o:p></p><p class=MsoNormal>>>>><o:p> </o:p></p><p class=MsoNormal>>>>> Mike, I personally provided feedback to Roland which he incorporated<o:p></o:p></p><p class=MsoNormal>>>>> into an updated draft over a year ago. The spec has been available in<o:p></o:p></p><p class=MsoNormal>>>>> draft form in github for something like two years.<o:p></o:p></p><p class=MsoNormal>>>>><o:p> </o:p></p><p class=MsoNormal>>>>> Nick<o:p></o:p></p><p class=MsoNormal>>>>><o:p> </o:p></p><p class=MsoNormal>>>>> On 7/20/18 8:16 AM, Mike Schwartz via Openid-specs-ab wrote:<o:p></o:p></p><p class=MsoNormal>>>>>>> And there's nothing that prevents that, just like there is nothing that<o:p></o:p></p><p class=MsoNormal>>>>>>> prevented me from working on HEART if I wanted to.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Nick<o:p></o:p></p><p class=MsoNormal>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>> Actually, you're wrong. And I'm pretty active in the OpenID Connect <o:p></o:p></p><p class=MsoNormal>>>>>> community... I don't think anyone would say otherwise.<o:p></o:p></p><p class=MsoNormal>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>> None of the design decisions on this spec were put to any kind of vote. <o:p></o:p></p><p class=MsoNormal>>>>>> And as I pointed out previously, discussion was limited. It was a take <o:p></o:p></p><p class=MsoNormal>>>>>> it or leave it design. Being presented at a conference is not the same <o:p></o:p></p><p class=MsoNormal>>>>>> as getting a say in the process.<o:p></o:p></p><p class=MsoNormal>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>> It was a closed process, where Jones/Hedburg might or might take your <o:p></o:p></p><p class=MsoNormal>>>>>> suggestions, depending on their whim. It has the veneer of openness, but <o:p></o:p></p><p class=MsoNormal>>>>>> it's not actually open. It's a one party vote, take it or leave it.<o:p></o:p></p><p class=MsoNormal>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>> I can't start a spec and call it the "Connect AB Alternate Federation <o:p></o:p></p><p class=MsoNormal>>>>>> Spec" and have it published here https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_connect_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=jglkfzh43veJDEsRH8sokGmpsmrh2afbdzoPw7Z-XH0&e=   So this <o:p></o:p></p><p class=MsoNormal>>>>>> spec was given VERY special treatment, placement and promotion.<o:p></o:p></p><p class=MsoNormal>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>> Let's not call this an open process when it's not.<o:p></o:p></p><p class=MsoNormal>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>> - Mike<o:p></o:p></p><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>>>>>> ------------------------<o:p></o:p></p><p class=MsoNormal>>>>>> Michael Schwartz<o:p></o:p></p><p class=MsoNormal>>>>>> Gluu<o:p></o:p></p><p class=MsoNormal>>>>>> Founder / CEO<o:p></o:p></p><p class=MsoNormal>>>>>> mike@gluu.org<o:p></o:p></p><p class=MsoNormal>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_nynymike_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=hpgFrnPt9eP5DCbWWSkhzDGGgkCLxqsYB5OxNoFp674&e=<o:p></o:p></p><p class=MsoNormal>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> On 2018-07-20 06:17, openid-specs-ab-request@lists.openid.net wrote:<o:p></o:p></p><p class=MsoNormal>>>>>>> Send Openid-specs-ab mailing list submissions to<o:p></o:p></p><p class=MsoNormal>>>>>>>  openid-specs-ab@lists.openid.net<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> To subscribe or unsubscribe via the World Wide Web, visit<o:p></o:p></p><p class=MsoNormal>>>>>>>  https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=<o:p></o:p></p><p class=MsoNormal>>>>>>> or, via email, send a message with subject or body 'help' to<o:p></o:p></p><p class=MsoNormal>>>>>>>  openid-specs-ab-request@lists.openid.net<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> You can reach the person managing the list at<o:p></o:p></p><p class=MsoNormal>>>>>>>  openid-specs-ab-owner@lists.openid.net<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> When replying, please edit your Subject line so it is more specific<o:p></o:p></p><p class=MsoNormal>>>>>>> than "Re: Contents of Openid-specs-ab digest..."<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Today's Topics:<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> 1. Re: Please Either ABSTAIN or OBJECT from the Federation Spec<o:p></o:p></p><p class=MsoNormal>>>>>>>    Vote (Nick Roy)<o:p></o:p></p><p class=MsoNormal>>>>>>> 2. Issue #1032: rp-initiated logout - proposal for client_id<o:p></o:p></p><p class=MsoNormal>>>>>>>    parameter (openid/connect) (Filip Skokan)<o:p></o:p></p><p class=MsoNormal>>>>>>> 3. Re: Issue #1032: rp-initiated logout - proposal for client_id<o:p></o:p></p><p class=MsoNormal>>>>>>>    parameter (openid/connect) (Vladimir Dzhuvinov)<o:p></o:p></p><p class=MsoNormal>>>>>>> 4. Re: Issue #1032: rp-initiated logout - proposal for client_id<o:p></o:p></p><p class=MsoNormal>>>>>>>    parameter (openid/connect) (Filip Skokan)<o:p></o:p></p><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>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Message: 1<o:p></o:p></p><p class=MsoNormal>>>>>>> Date: Thu, 19 Jul 2018 18:05:45 +0000<o:p></o:p></p><p class=MsoNormal>>>>>>> From: Nick Roy <nroy@internet2.edu><o:p></o:p></p><p class=MsoNormal>>>>>>> To: "openid-specs-ab@lists.openid.net"<o:p></o:p></p><p class=MsoNormal>>>>>>>  <openid-specs-ab@lists.openid.net><o:p></o:p></p><p class=MsoNormal>>>>>>> Subject: Re: [Openid-specs-ab] Please Either ABSTAIN or OBJECT from<o:p></o:p></p><p class=MsoNormal>>>>>>>  the Federation Spec Vote<o:p></o:p></p><p class=MsoNormal>>>>>>> Message-ID:<o:p></o:p></p><p class=MsoNormal>>>>>>>  <CY4PR08MB35449C06D30AE97F5188DDFA83520@CY4PR08MB3544.namprd08.prod.outlook.com><o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Content-Type: text/plain; charset="us-ascii"<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> And there's nothing that prevents that, just like there is nothing that<o:p></o:p></p><p class=MsoNormal>>>>>>> prevented me from working on HEART if I wanted to.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Nick<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> On 7/19/18 10:43 AM, Mike Schwartz via Openid-specs-ab wrote:<o:p></o:p></p><p class=MsoNormal>>>>>>>> Nick,<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> I thought you had a good idea to move federation to its own WG.<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> So of course, I'm all for OpenID federations. And I'm also really<o:p></o:p></p><p class=MsoNormal>>>>>>>> interested in this proposed design. And I appreciate the work done by<o:p></o:p></p><p class=MsoNormal>>>>>>>> the current editors. It might be the best way. But I was never given a<o:p></o:p></p><p class=MsoNormal>>>>>>>> choice of A or B. I was just given a choice to approve A.<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> I think the community should get a say in this design of this spec.<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> - Mike<o:p></o:p></p><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>>>>>>>>> it sounds like you aren't interested in working in an R&E working<o:p></o:p></p><p class=MsoNormal>>>>>>>>> group.<o:p></o:p></p><p class=MsoNormal>>>>>>>>> My understanding is that this WG will pursue R&E use cases for this<o:p></o:p></p><p class=MsoNormal>>>>>>>>> profile. Since R&E is one of the largest users of multilateral SAML<o:p></o:p></p><p class=MsoNormal>>>>>>>>> federation, I think exploring use of the OIDC Federation work in that<o:p></o:p></p><p class=MsoNormal>>>>>>>>> space is a great next step.<o:p></o:p></p><p class=MsoNormal>>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>>> Nick<o:p></o:p></p><p class=MsoNormal>>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> _______________________________________________<o:p></o:p></p><p class=MsoNormal>>>>>>>> Openid-specs-ab mailing list<o:p></o:p></p><p class=MsoNormal>>>>>>>> Openid-specs-ab@lists.openid.net<o:p></o:p></p><p class=MsoNormal>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=<o:p></o:p></p><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>>>>>>> ------------------------------<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Message: 2<o:p></o:p></p><p class=MsoNormal>>>>>>> Date: Fri, 20 Jul 2018 08:10:50 +0000 (UTC)<o:p></o:p></p><p class=MsoNormal>>>>>>> From: "Filip Skokan" <issues-reply@bitbucket.org><o:p></o:p></p><p class=MsoNormal>>>>>>> To: openid-specs-ab@lists.openid.net<o:p></o:p></p><p class=MsoNormal>>>>>>> Subject: [Openid-specs-ab] Issue #1032: rp-initiated logout - proposal<o:p></o:p></p><p class=MsoNormal>>>>>>>  for client_id parameter (openid/connect)<o:p></o:p></p><p class=MsoNormal>>>>>>> Message-ID:<o:p></o:p></p><p class=MsoNormal>>>>>>>  <20180720081050.39616.17365@celery-worker-105.ash1.bb-inf.net><o:p></o:p></p><p class=MsoNormal>>>>>>> Content-Type: text/plain; charset="utf-8"<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> New issue 1032: rp-initiated logout - proposal for client_id parameter<o:p></o:p></p><p class=MsoNormal>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dproposal-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP71dmPh3bNGNK7k5w&e=<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Filip Skokan:<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> I'd like to request that a parameter (optional or required?) client_id<o:p></o:p></p><p class=MsoNormal>>>>>>> is defined for rp-initiated logout request.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> rationale:<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Currently the id_token_hint is the only way of identifying the client<o:p></o:p></p><p class=MsoNormal>>>>>>> that's making the request. In scenarios where a client does not yet<o:p></o:p></p><p class=MsoNormal>>>>>>> have an id_token but makes a request to authenticate which fails (e.g.<o:p></o:p></p><p class=MsoNormal>>>>>>> due to being requested with essential sub claim through claims) the<o:p></o:p></p><p class=MsoNormal>>>>>>> next step will be to trigger an rp initiated logout with a registered<o:p></o:p></p><p class=MsoNormal>>>>>>> post_logout_redirect_uri but without an id_token_hint. This can be<o:p></o:p></p><p class=MsoNormal>>>>>>> problematic for OP deployments with a high number of clients as it is<o:p></o:p></p><p class=MsoNormal>>>>>>> not efficient or sometimes even not possible to iterate over all of<o:p></o:p></p><p class=MsoNormal>>>>>>> them to see if this post_logout_redirect_uri is whitelisted or not.<o:p></o:p></p><p class=MsoNormal>>>>>>> Hence the client_id parameter to make this lookup possible and<o:p></o:p></p><p class=MsoNormal>>>>>>> efficient.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Further processing may be defined such as if both client_id and<o:p></o:p></p><p class=MsoNormal>>>>>>> id_token_hint are provided the audience of the id_token_hint must<o:p></o:p></p><p class=MsoNormal>>>>>>> include the client_id etc.<o:p></o:p></p><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>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> ------------------------------<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Message: 3<o:p></o:p></p><p class=MsoNormal>>>>>>> Date: Fri, 20 Jul 2018 14:01:29 +0300<o:p></o:p></p><p class=MsoNormal>>>>>>> From: Vladimir Dzhuvinov <vladimir@connect2id.com><o:p></o:p></p><p class=MsoNormal>>>>>>> To: openid-specs-ab@lists.openid.net<o:p></o:p></p><p class=MsoNormal>>>>>>> Subject: Re: [Openid-specs-ab] Issue #1032: rp-initiated logout -<o:p></o:p></p><p class=MsoNormal>>>>>>>  proposal for client_id parameter (openid/connect)<o:p></o:p></p><p class=MsoNormal>>>>>>> Message-ID: <14898981-27c9-8a85-91c8-77c93a931278@connect2id.com><o:p></o:p></p><p class=MsoNormal>>>>>>> Content-Type: text/plain; charset="utf-8"<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Hi Filip,<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> My concern is that relying on the client_id opens up post logout<o:p></o:p></p><p class=MsoNormal>>>>>>> redirection to potential misuse.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> IMO the OP shouldn't be picking any redirections if cannot be sure, to <o:p></o:p></p><p class=MsoNormal>>>>>>> a<o:p></o:p></p><p class=MsoNormal>>>>>>> satisfactory degree, that it's the legitimate RP making the call.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> The ID token isn't really a substitute for proper RP authentication, <o:p></o:p></p><p class=MsoNormal>>>>>>> but<o:p></o:p></p><p class=MsoNormal>>>>>>> it's some way towards that.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> A JWS request might help here, but it's probably too much to ask from <o:p></o:p></p><p class=MsoNormal>>>>>>> RPs.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Vladimir<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 20/07/18 11:10, Filip Skokan via Openid-specs-ab wrote:<o:p></o:p></p><p class=MsoNormal>>>>>>>> New issue 1032: rp-initiated logout - proposal for client_id parameter<o:p></o:p></p><p class=MsoNormal>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dproposal-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP71dmPh3bNGNK7k5w&e=<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> Filip Skokan:<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> I'd like to request that a parameter (optional or required?) client_id <o:p></o:p></p><p class=MsoNormal>>>>>>>> is defined for rp-initiated logout request.<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> rationale:<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> Currently the id_token_hint is the only way of identifying the client <o:p></o:p></p><p class=MsoNormal>>>>>>>> that's making the request. In scenarios where a client does not yet <o:p></o:p></p><p class=MsoNormal>>>>>>>> have an id_token but makes a request to authenticate which fails (e.g. <o:p></o:p></p><p class=MsoNormal>>>>>>>> due to being requested with essential sub claim through claims) the <o:p></o:p></p><p class=MsoNormal>>>>>>>> next step will be to trigger an rp initiated logout with a registered <o:p></o:p></p><p class=MsoNormal>>>>>>>> post_logout_redirect_uri but without an id_token_hint. This can be <o:p></o:p></p><p class=MsoNormal>>>>>>>> problematic for OP deployments with a high number of clients as it is <o:p></o:p></p><p class=MsoNormal>>>>>>>> not efficient or sometimes even not possible to iterate over all of <o:p></o:p></p><p class=MsoNormal>>>>>>>> them to see if this post_logout_redirect_uri is whitelisted or not. <o:p></o:p></p><p class=MsoNormal>>>>>>>> Hence the client_id parameter to make this lookup possible and <o:p></o:p></p><p class=MsoNormal>>>>>>>> efficient.<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> Further processing may be defined such as if both client_id and <o:p></o:p></p><p class=MsoNormal>>>>>>>> id_token_hint are provided the audience of the id_token_hint must <o:p></o:p></p><p class=MsoNormal>>>>>>>> include the client_id etc.<o:p></o:p></p><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>>>>>>> -------------- next part --------------<o:p></o:p></p><p class=MsoNormal>>>>>>> A non-text attachment was scrubbed...<o:p></o:p></p><p class=MsoNormal>>>>>>> Name: smime.p7s<o:p></o:p></p><p class=MsoNormal>>>>>>> Type: application/pkcs7-signature<o:p></o:p></p><p class=MsoNormal>>>>>>> Size: 4002 bytes<o:p></o:p></p><p class=MsoNormal>>>>>>> Desc: S/MIME Cryptographic Signature<o:p></o:p></p><p class=MsoNormal>>>>>>> URL:<o:p></o:p></p><p class=MsoNormal>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dab_attachments_20180720_00f40e94_attachment-2D0001.p7s&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=eTHo7f8tNiakUT3d8PkF8AQgSq44lpjr4_2Y7S8skp4&e=><o:p></o:p></p><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>>>>>>> Message: 4<o:p></o:p></p><p class=MsoNormal>>>>>>> Date: Fri, 20 Jul 2018 13:16:52 +0200<o:p></o:p></p><p class=MsoNormal>>>>>>> From: Filip Skokan <panva.ip@gmail.com><o:p></o:p></p><p class=MsoNormal>>>>>>> To: Vladimir Dzhuvinov <vladimir@connect2id.com><o:p></o:p></p><p class=MsoNormal>>>>>>> Cc: "openid-specs-ab@lists.openid.net Ab"<o:p></o:p></p><p class=MsoNormal>>>>>>>  <openid-specs-ab@lists.openid.net><o:p></o:p></p><p class=MsoNormal>>>>>>> Subject: Re: [Openid-specs-ab] Issue #1032: rp-initiated logout -<o:p></o:p></p><p class=MsoNormal>>>>>>>  proposal for client_id parameter (openid/connect)<o:p></o:p></p><p class=MsoNormal>>>>>>> Message-ID:<o:p></o:p></p><p class=MsoNormal>>>>>>>  <CALAqi_8w2uvCd9R39YQpL-QxT7srCTvgpQvqkGXnrfo80owEFw@mail.gmail.com><o:p></o:p></p><p class=MsoNormal>>>>>>> Content-Type: text/plain; charset="utf-8"<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Hello Vladimir,<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> The OP is advised to render a prompt for the end-user in those cases <o:p></o:p></p><p class=MsoNormal>>>>>>> where<o:p></o:p></p><p class=MsoNormal>>>>>>> post_logout_redirect_uri is not provided. And there's no mention of<o:p></o:p></p><p class=MsoNormal>>>>>>> ignoring the post_logout_redirect_uri param if id_token_hint is <o:p></o:p></p><p class=MsoNormal>>>>>>> missing.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Currently:<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> post_logout_redirect_uri<o:p></o:p></p><p class=MsoNormal>>>>>>>> OPTIONAL. URL to which the RP is requesting that the End-User's User <o:p></o:p></p><p class=MsoNormal>>>>>>>> Agent<o:p></o:p></p><p class=MsoNormal>>>>>>>> be redirected after a logout has been performed. The value MUST have <o:p></o:p></p><p class=MsoNormal>>>>>>>> been<o:p></o:p></p><p class=MsoNormal>>>>>>>> previously registered with the OP, either using the<o:p></o:p></p><p class=MsoNormal>>>>>>>> post_logout_redirect_uris Registration parameter or via another <o:p></o:p></p><p class=MsoNormal>>>>>>>> mechanism.<o:p></o:p></p><p class=MsoNormal>>>>>>>> If supplied, the OP SHOULD honor this request following the logout.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> No mention of ignoring the value if id_token_hint is not provided.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> and under security considerations, the advise to prompt.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> The id_token_hint parameter to a logout request can be used to <o:p></o:p></p><p class=MsoNormal>>>>>>> determine<o:p></o:p></p><p class=MsoNormal>>>>>>>> which RP initiated the logout request. Logout requests without a valid<o:p></o:p></p><p class=MsoNormal>>>>>>>> id_token_hint value are a potential means of denial of service; <o:p></o:p></p><p class=MsoNormal>>>>>>>> therefore,<o:p></o:p></p><p class=MsoNormal>>>>>>>> OPs may want to require explicit user confirmation before acting upon <o:p></o:p></p><p class=MsoNormal>>>>>>>> them.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Supplying a client_id does not change a potential extra OP policy that<o:p></o:p></p><p class=MsoNormal>>>>>>> id_token_hint must be provided if it choses to do so, it simply makes<o:p></o:p></p><p class=MsoNormal>>>>>>> post_logout_redirect_uri lookup possible in cases where loading all <o:p></o:p></p><p class=MsoNormal>>>>>>> uris or<o:p></o:p></p><p class=MsoNormal>>>>>>> clients into memory is not possible/is inefficient or can't query for <o:p></o:p></p><p class=MsoNormal>>>>>>> all<o:p></o:p></p><p class=MsoNormal>>>>>>> valid uris for the same reasons.<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> Best,<o:p></o:p></p><p class=MsoNormal>>>>>>> *Filip*<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 Fri, Jul 20, 2018 at 1:01 PM Vladimir Dzhuvinov via Openid-specs-ab <o:p></o:p></p><p class=MsoNormal>>>>>>> <<o:p></o:p></p><p class=MsoNormal>>>>>>> openid-specs-ab@lists.openid.net> wrote:<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> Hi Filip,<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> My concern is that relying on the client_id opens up post logout<o:p></o:p></p><p class=MsoNormal>>>>>>>> redirection to potential misuse.<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> IMO the OP shouldn't be picking any redirections if cannot be sure, to <o:p></o:p></p><p class=MsoNormal>>>>>>>> a<o:p></o:p></p><p class=MsoNormal>>>>>>>> satisfactory degree, that it's the legitimate RP making the call.<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> The ID token isn't really a substitute for proper RP authentication, <o:p></o:p></p><p class=MsoNormal>>>>>>>> but<o:p></o:p></p><p class=MsoNormal>>>>>>>> it's some way towards that.<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> A JWS request might help here, but it's probably too much to ask from <o:p></o:p></p><p class=MsoNormal>>>>>>>> RPs.<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> Vladimir<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 20/07/18 11:10, Filip Skokan via Openid-specs-ab wrote:<o:p></o:p></p><p class=MsoNormal>>>>>>>>> New issue 1032: rp-initiated logout - proposal for client_id parameter<o:p></o:p></p><p class=MsoNormal>>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dproposal-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP71dmPh3bNGNK7k5w&e=<o:p></o:p></p><p class=MsoNormal>>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>>> Filip Skokan:<o:p></o:p></p><p class=MsoNormal>>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>>> I'd like to request that a parameter (optional or required?) client_id<o:p></o:p></p><p class=MsoNormal>>>>>>>> is defined for rp-initiated logout request.<o:p></o:p></p><p class=MsoNormal>>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>>> rationale:<o:p></o:p></p><p class=MsoNormal>>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>>> Currently the id_token_hint is the only way of identifying the client<o:p></o:p></p><p class=MsoNormal>>>>>>>> that's making the request. In scenarios where a client does not yet <o:p></o:p></p><p class=MsoNormal>>>>>>>> have an<o:p></o:p></p><p class=MsoNormal>>>>>>>> id_token but makes a request to authenticate which fails (e.g. due to <o:p></o:p></p><p class=MsoNormal>>>>>>>> being<o:p></o:p></p><p class=MsoNormal>>>>>>>> requested with essential sub claim through claims) the next step will <o:p></o:p></p><p class=MsoNormal>>>>>>>> be to<o:p></o:p></p><p class=MsoNormal>>>>>>>> trigger an rp initiated logout with a registered <o:p></o:p></p><p class=MsoNormal>>>>>>>> post_logout_redirect_uri<o:p></o:p></p><p class=MsoNormal>>>>>>>> but without an id_token_hint. This can be problematic for OP <o:p></o:p></p><p class=MsoNormal>>>>>>>> deployments<o:p></o:p></p><p class=MsoNormal>>>>>>>> with a high number of clients as it is not efficient or sometimes even <o:p></o:p></p><p class=MsoNormal>>>>>>>> not<o:p></o:p></p><p class=MsoNormal>>>>>>>> possible to iterate over all of them to see if this<o:p></o:p></p><p class=MsoNormal>>>>>>>> post_logout_redirect_uri is whitelisted or not. Hence the client_id<o:p></o:p></p><p class=MsoNormal>>>>>>>> parameter to make this lookup possible and efficient.<o:p></o:p></p><p class=MsoNormal>>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>>>> Further processing may be defined such as if both client_id and<o:p></o:p></p><p class=MsoNormal>>>>>>>> id_token_hint are provided the audience of the id_token_hint must <o:p></o:p></p><p class=MsoNormal>>>>>>>> include<o:p></o:p></p><p class=MsoNormal>>>>>>>> the client_id etc.<o:p></o:p></p><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>>>>>>>> _______________________________________________<o:p></o:p></p><p class=MsoNormal>>>>>>>> Openid-specs-ab mailing list<o:p></o:p></p><p class=MsoNormal>>>>>>>> Openid-specs-ab@lists.openid.net<o:p></o:p></p><p class=MsoNormal>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=<o:p></o:p></p><p class=MsoNormal>>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> -------------- next part --------------<o:p></o:p></p><p class=MsoNormal>>>>>>> An HTML attachment was scrubbed...<o:p></o:p></p><p class=MsoNormal>>>>>>> URL:<o:p></o:p></p><p class=MsoNormal>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dab_attachments_20180720_43cba25d_attachment.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=KmCCQjnkztIL-CzFEhohJrsvdGwCZtWRDGDfwFTOOTs&e=><o:p></o:p></p><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>>>>>>> Subject: Digest Footer<o:p></o:p></p><p class=MsoNormal>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> _______________________________________________<o:p></o:p></p><p class=MsoNormal>>>>>>> Openid-specs-ab mailing list<o:p></o:p></p><p class=MsoNormal>>>>>>> Openid-specs-ab@lists.openid.net<o:p></o:p></p><p class=MsoNormal>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=<o:p></o:p></p><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>>>>>>><o:p> </o:p></p><p class=MsoNormal>>>>>>> End of Openid-specs-ab Digest, Vol 390, Issue 9<o:p></o:p></p><p class=MsoNormal>>>>>>> ***********************************************<o:p></o:p></p><p class=MsoNormal>>>>>> _______________________________________________<o:p></o:p></p><p class=MsoNormal>>>>>> Openid-specs-ab mailing list<o:p></o:p></p><p class=MsoNormal>>>>>> Openid-specs-ab@lists.openid.net<o:p></o:p></p><p class=MsoNormal>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=<o:p></o:p></p><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>>>> Openid-specs-ab mailing list<o:p></o:p></p><p class=MsoNormal>>>> Openid-specs-ab@lists.openid.net<o:p></o:p></p><p class=MsoNormal>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=<o:p></o:p></p><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>Openid-specs-ab mailing list<o:p></o:p></p><p class=MsoNormal>Openid-specs-ab@lists.openid.net<o:p></o:p></p><p class=MsoNormal>http://lists.openid.net/mailman/listinfo/openid-specs-ab<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>