<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">My concern would be that a browser employing “Intelligent Tracking Prevention” would see the POST of the SID as tracking and prevent it. Of course, doing so breaks all sorts of other things, but the browser people don’t seem to care about that at the moment.<div class=""><br class=""></div><div class="">Nicole Roy</div><div class="">Internet2/InCommon<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 2, 2022, at 4:30 PM, Jake Feasel via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class="">This topic has been raised before, but based on the traffic from this list it seems to not be going anywhere. I would like to revive it.<div class=""><br class=""></div><div class="">I had a quick talk at Identiverse this year covering the OIDC Session Management draft spec, in particular my take on the upcoming "Cookiepocalypse" and how it will render the current draft completely obsolete. You can see my slides here: <a href="https://docs.google.com/presentation/d/1uU3KvK6ayTpjB2OEmrSqQnUdJDPSdfxxetJrks1czvI/edit#slide=id.g11aa5093f19_0_63" class="">https://docs.google.com/presentation/d/1uU3KvK6ayTpjB2OEmrSqQnUdJDPSdfxxetJrks1czvI/edit#slide=id.g11aa5093f19_0_63</a></div><div class=""></div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div>[snip]</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">The OP will include the "sid" claim (as defined in the Front and Back-channel logout drafts) as a claim in the id_token used in an auth_code grant. This "sid" value will be included in a POST request to the "token" endpoint on the OP on a periodic basis (likely prompted from user activity within the RP). It would like something like so (note the absence of a cookie in this request):</div><div class=""><br class=""></div><div class=""> POST /token HTTP/1.1<br class=""> Host: <a href="http://server.example.com/" class="">server.example.com</a><br class=""> Content-Type: application/x-www-form-urlencoded<br class=""> Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW<br class=""><br class=""> grant_type=session_check&sid=1234xyz</div><div class=""><br class=""></div><div class="">The response code from this could be a 401 if the sid is not associated with a valid OP session, or 200 if it is. The response body in the case of a 200 could include a new id_token with updated session claims (to provide better context for when the session expires or if other important details about the session change).</div><div class=""><br class=""></div></div></div></blockquote><br class=""></div><div>[snip]</div><br class=""></div></body></html>