<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="">Hello Jake!<div class=""><br class=""></div><div class="">I attempted to define something similar to this a while back,</div><div class=""><a href="https://bitbucket.org/openid/connect/raw/293dca14cd1352bbb101d15bcac4a6f3825a4b15/distributed-token-validity-api.txt" class="">https://bitbucket.org/openid/connect/raw/293dca14cd1352bbb101d15bcac4a6f3825a4b15/distributed-token-validity-api.txt</a></div><div class=""><br class=""></div><div class="">The motivation was to:</div><div class="">1. Create an API which could easily be proxied/cached such that an RP could run their own infrastructure for checking validity (for scaling/reliability/latency reasons)</div><div class="">2. Investigate ways other than reactive HTTP proxying to synchronize this data, such as using a distributed ledger (described in a separate proposal in the same repo).</div><div class=""><br class=""></div><div class="">In retrospect, #2 was a step too far - I also was planning an investigation of using secevent-based signalling, but dropped this due to low interest.</div><div class=""><br class=""></div><div class="">I did a presentation on this on the last IIW; I got the impression that the slow death of third party cookies had increased interest in this sort of approach, but I personally don’t have time to lead that effort at the moment.<br class=""><div><br class=""></div><div>-DW</div><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 18, 2021, at 9:13 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=""><div dir="ltr" class="">Based on my searching of the mailing-list archives, it appears to me that there is a wide-spread acknowledgement of the problem that third-party cookie restrictions impose on the current OIDC Session Management draft spec. In short - using hidden iframes with prompt=none to check the session status at the OP is not viable when browsers are restricting the OP session cookie.<div class=""><br class="">I have a proposal for how to address this limitation:<br class=""><br class=""></div><div class="">The front-channel logout and back-channel logout drafts both define the "sid" claim. There is some discussion of it here, too: <a href="https://bitbucket.org/openid/connect/issues/1031/sid-id-token-claim-definition-and-when-to" class="">https://bitbucket.org/openid/connect/issues/1031/sid-id-token-claim-definition-and-when-to</a></div><div class=""><br class="">My understanding from reading these specs is that both have the assumption that the "sid" claim is first given to the RP in the id_token as part of initial authentication. I would like to build upon that assumption and suggest that this claim could be used as the basis for a new grant - "session_check" or some such. It could be another call to the token endpoint, secured in much the same way as the original auth code grant (verifying client_id, redirect_uri, etc...). Rather than the code, it would pass the "sid" value. In response, if the session identified by the sid is still current in the OP the RP would get back a new id_token with updated claims (exp, acr, auth_time, etc...). It would be reasonable to assume that if the session in the OP has an idle timeout, this call from the RP would reset that timeout.</div><div class=""><br class="">I don't see any obvious reason why such a grant would not work well for any RP that is currently capable of performing an authorization code grant - including single page apps without a back-end component (relying on CORS). This has the advantage of avoiding all iframe and cookie limitations, while building upon existing patterns such as the "sid" claim.</div><div class=""><br class="">What do you think? Is this a viable approach?<br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><table border="0" cellspacing="0" cellpadding="0" style="font-family:"Times New Roman"" class=""><tbody class=""><tr class=""><td valign="center" class=""><a href="https://www.forgerock.com/" target="_blank" class=""><img src="https://www.forgerock.com/img/2019_forgerock_email_logo_retina.png" width="185" height="70" border="0" alt="ForgeRock" class=""></a></td><td valign="top" align="left" bgcolor="#ffffff" style="font-family:arial,helvetica,verdana,sans-serif;font-size:12px;color:rgb(47,52,56);line-height:19.8px" class=""><span style="color:rgb(3,43,117)" class=""><strong class="">Jake Feasel</strong></span><br class="">Principal Engineer | ForgeRock<br class=""><span style="color:rgb(249,103,0)" class=""><strong class="">t</strong></span> (907) 229-1865 | <span style="display:inline-block" class=""><span style="color:rgb(249,103,0)" class=""><strong class="">e</strong></span> <a href="mailto:firstname.lastname@forgerock.com" style="color:rgb(47,52,56)" target="_blank" class="">jake.feasel@forgerock.com</a></span><br class=""><span style="color:rgb(249,103,0)" class=""><strong class="">twitter</strong></span> jakefeasel | <span style="display:inline-block" class=""><span style="color:rgb(249,103,0)" class=""><strong class="">web</strong></span> <a href="https://www.forgerock.com/" style="color:rgb(47,52,56)" target="_blank" class="">www.forgerock.com</a></span></td></tr></tbody></table></div></div></div></div>
<br class="">
<span style="color:rgb(23,43,77);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;background-color:rgb(255,255,255)" class=""><font size="1" class="">ForgeRock values your <a href="https://www.forgerock.com/your-privacy" target="_blank" class="">Privacy</a></font></span>_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></blockquote></div><br class=""></div></body></html>