<html xmlns:v="urn:schemas-microsoft-com:vml" 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=us-ascii">
<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:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#002060;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">Thanks for the review, Jim. Your comments all seem correct to me. I’ll plan to incorporate them in the next draft.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Openid-specs-ab [mailto:openid-specs-ab-bounces@lists.openid.net]
<b>On Behalf Of </b>Jim des Rivieres<br>
<b>Sent:</b> Monday, March 16, 2015 8:34 AM<br>
<b>To:</b> openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-ab] First full HTML-based logout spec published<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Here are some comments on draft 00 of OpenID Connect HTTP-Based Logout 1.0.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">re: 2. Relying Party Logout Functionality</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> Upon receiving the GET, the RP clears state associated with the logged-in session, including any cookies, and then returns an image and a HTTP 200 status code.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">The RP's response also needs anti-caching headers (Cache-Control: no-store, Pragma: no-cache) to prevent the user agent from caching the response. Otherwise caching of one logout response could interfere
with future logouts.</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> If the RP supports OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration], it uses this metadata value to register the logout URL:</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Regardless of whether the RP supports OpenID.Registration, the RP's registration with the OP needs to include the logout URL, logout_use_iframe and logout_session_required settings (when OP supports
latter). This makes it awkward to frame this section entirely in terms of OpenID.Registration. Since a parameter is passed to the logout URL, it might be clearer to call it the RP's Logout endpoint (cf. OAuth2 Redirection endpoint). Like other OAuth2/OIDC
endpoint URIs, the spec should spell out the restrictions on the endpoint URI; e.g., "The Logout endpoint URI MUST be an absolute URI as defined by [RFC3986] Section 4.3. The Logout endpoint URI MAY include an "application/x-www-form-urlencoded" formatted
(per [RFC 6749] Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters. The Logout endpoint URI MUST NOT include a fragment component."</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">re: 3. OpenID Provider Logout Functionality</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> sid (Session ID) OPTIONAL. String identifier for a Session - a pairing of an OP to a User Agent or device for a logged-in End-User.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Shouldn't the Session ID bind in the RP as well? If an OP were to use the same sid value across multiple RPs, it would be easy enough for a naughty RP to cause another RP2 to logout, with no way
for RP2 to defend itself.</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Regards,</span> <br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Jim</span><o:p></o:p></p>
</div>
</body>
</html>