<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>From a security point of view sending did in a JWT would be best, however the size of a asymmetrically signed JWT is not insignificant when multiplied by the RP to be logged out. The biggest problem with this logout method is that tend to close the page after logging out.</div><div><br></div><div>The larger the message the less likely they all will work. </div><div><br></div><div>Perhaps someone can produce some performance comparisons to help us make a decision. </div><div><br></div><div>John B. <br><br>Sent from my iPhone</div><div><br>On Feb 21, 2015, at 9:52 AM, Thomas Broyer <<a href="mailto:t.broyer@gmail.com">t.broyer@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Could you please add "Security Considerations" section?<div><br></div><div>IMO, "sid" should be required, and <span style="font-size:13.1999998092651px">RPs MUST validate the "sid" claim and not only rely on the sent credentials (generally a cookie or set of cookies). Failing to do that leaves the door open to CSRF logging out users from third-party RPs (possibly a competitor). Sure the impact is "limited", in the sense those RPs could probably log the user in transparently the next time they come in (that depends on the OP though, possibly some user configuration at the OP; or the RP if they use the 'prompt' parameter), but it's still a threat (the attacker could log you out every few minutes, and you' likely never blame them, but rather the victim RP).</span></div><div><span style="font-size:13.1999998092651px"><br></span></div><div>Also, quite obviously the "sid" claim should be kept as private as possible (see my previous mails in this thread); but as it's returned in the id_token and that one is sent as id_token_hint to authorization_endpoints and end_session_endpoints, or even right to the redirect_uri… Or maybe the OP SHOULD "revoke" the "sid" in this case (and issue a new one to the redirect_uri when received at the authorization_endpoint). But there's still a "risk" if the RP doesn't use HTTPS (redirection to the OP with the id_token_hint could be easily intercepted; or to the RP when using an id_token response_type)<div>It should also be "sufficiently unique" as to not be discoverable (or subject to brute force; see CSRF attack scenario above).</div><div><br></div><div>IMO, the logout_uri should receive some crypto material (signature or encryption) he can verify to validate that the caller is the OP, and that <span style="font-size:13.1999998092651px">parameter should have a short validity timeframe and/or include some sort of "nonce" to prevent replay attacks. It could just be a JWT (JWS/JWE) including the "sid" you propose as a claim, along with "iat", "exp", and/or a "jti".</span></div><div><span style="font-size:13.1999998092651px">If this has been rejected for any reason, please make it public somewhere (and ideally even add it in an appendix). Explaining the "why" is almost as important as describing the "how" of the settled-on solution in any spec (why that thing is a MUST, or a SHOULD, why has this been designed that way and not another, etc.)</span></div><div><span style="font-size:13.1999998092651px"><br></span></div><div><div class="gmail_quote">On Sat Feb 21 2015 at 01:38:02 Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">A third iteration of the proposed OpenID Connect spec on logout using HTTP GET is attached. (It’s now a two-pager.) This incorporates the results of the useful discussion on Thursday’s call. Keep those cards and letters coming!<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Changes were:<u></u><u></u></p>
<p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u>Replaced the optional <span style="font-family:"Courier New"">
id_token</span> parameter with an optional <span style="font-family:"Courier New"">
sid</span> (Session ID) parameter.<u></u><u></u></p>
<p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u>Enabled the use of iframes with nested images or iframes to achieve downstream logouts.<u></u><u></u></p></div></div><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> -- Mike<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</div></div>
______________________________<u></u>_________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.<u></u>net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/<u></u>mailman/listinfo/openid-specs-<u></u>ab</a><br>
</blockquote></div></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Openid-specs-ab mailing list</span><br><span><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></span><br><span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br></div></blockquote></body></html>