<div dir="ltr">I can confirm that Session Management 1.0 suffers the same fate, OPs relying on a cookie presence aren't able to calculate the same session state, always resulting in "changed" state.<div><br></div><div>With 3rd party cookies disabled</div><div>OP frames loaded from RP origin - OP cookies are not available</div><div>RP frames loaded from OP origin - RP cookies are not avaialble (d'oh).</div><div><br></div><div><div>In addition, the RP must not block it's front_channel_logout_uri from being iframed. That means either not using X-Frame-Options header at all for the page, or using `X-Frame-Options: ALLOW-FROM <a href="https://op.example.com/`">https://op.example.com/`</a> to whitelist OP origins that are able to execute the frontchannel logout. OP and RP should agree on what the OP logout origin will be in this case. Whitelisting the origins is recommended if `iss` & `sid` is not being used by the RP to prevent unintended or potentially exploitable logouts.</div><div><br></div><div>There are additional restrictions for P3P enabled User-Agents where non P3P declaring pages won't have their cookies sent to the server when iframed. These Agents are, as far as i am aware all IE versions on non-Windows 10 systems.</div><div><br></div><div>But since P3P is no longer supported (<a href="https://msdn.microsoft.com/en-us/library/mt146424(v=vs.85).aspx">https://msdn.microsoft.com/en-us/library/mt146424(v=vs.85).aspx</a>) i think there's no harm in abusing the spec's definition and completely bypass it by sending an invalid P3P header value from the server when it detects a relevant IE version in the user agent. (This obviously applies to Session Management 1.0 as well, since the OP frame won't be able to access the cookies it needs to calculate the matching session state, reporting either error or session changed).</div><div><br></div><div>I can think of ways to have session management implementation rely on localStorage, making that one work, however, can't figure out a workaround for changing RP states via an iframe or any other frontend element means.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">Best,<br><b>Filip Skokan</b></div></div>
<br><div class="gmail_quote">On Mon, Aug 29, 2016 at 10:09 PM, Prateek Mishra via Openid-specs-ab <span dir="ltr"><<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Agreed, Torsten, we would like to see a solution to the problem as well.<div><br></div><div>I believe that the “OpenID Session Management 1.0” specification suffers from the same problem, </div><div>but I have personally not worked with this specification.</div><div><br></div><div>Mike - could we please add this issue to the next AB call agenda?</div><div><br></div><div>Thanks,</div><div>prateek</div><div><div class="gmail-h5"><div><br><div><blockquote type="cite"><div>On Aug 29, 2016, at 8:48 AM, <a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a> wrote:</div><br class="gmail-m_-1718426063717454442Apple-interchange-newline"><div><p dir="ltr">Hi Pratek,</p><p dir="ltr">we are facing the same problem. Describing it in the spec is definitely the minimum. Better would be to come up with a viable solution.</p><p dir="ltr">best regards,<br>
Torsten. </p><p dir="ltr">Sent by <a href="http://www.mail-wise.com/installation/2" target="_blank">MailWise</a> – See your emails as clean, short chats.</p>
<br><br>-------- Ursprüngliche Nachricht --------<br>Von: Prateek Mishra via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.<wbr>net</a>><br>Gesendet: Friday, August 26, 2016 02:56 AM<br>An: <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.<wbr>net</a><br>Betreff: [Openid-specs-ab] Third-Party Cookies and Front Channel Logout<br><br><font face="Verdana">The OIDC Front Channel Logout draft specification uses<span style="background-color:rgb(255,255,255)"> HTTP GETs to RP URLs that clear login state.</span></font><div><span style="background-color:rgb(255,255,255)"><font face="Verdana"><br></font></span></div><div><a href="http://openid.net/specs/openid-connect-frontchannel-1_0.html" target="_blank"><font face="Verdana">http://openid.net/specs/<wbr>openid-connect-frontchannel-1_<wbr>0.html</font></a></div><div><font face="Verdana"><br></font></div><div><font face="Verdana">This typically takes the form of an OP loading a page with <tt style="color:rgb(0,51,102);background-color:rgb(255,255,255)"><iframe src="frontchannel_logout_uri”></tt><span style="background-color:rgb(255,255,255)"><wbr> or <img src=“</span>front_channel_logout_uri”<wbr>></font></div><div><font face="Verdana"><br></font></div><div><font face="Verdana">However, modern browsers allow users to “block third party cookies” and this setting means that the logout at the RP will fail (unable to remove previously</font></div><div><font face="Verdana">established RP cookie). Our implementation and test teams have found this to be a really confusing situation for end-users.</font></div><div><font face="Verdana"><br></font></div><div><font face="Verdana">Have implementors had any success with alternatives or work-arounds? At a minimum we should capture this behavior in the draft specification.</font></div><div><font face="Verdana"><br></font></div><div><font face="Verdana">Thanks,</font></div><div><font face="Verdana">prateek</font></div><div><font face="verdana, charcoal, helvetica, arial, sans-serif" size="2"><br></font></div><div><font face="verdana, charcoal, helvetica, arial, sans-serif" size="2"><br></font></div></div></blockquote></div><br></div></div></div></div><br>______________________________<wbr>_________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.<wbr>net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>ab</a><br>
<br></blockquote></div><br></div></div></div>