<div dir="auto">Thank you Vittorio, that’s a great explanation!</div><div dir="auto"><br></div><div dir="auto">I will claim some “blame” for the confusion around refresh_tokens and ‘offline_access’ as at AOL we issued session bound refresh_tokens by default and the only way to get a refresh_token that was not session bound was to request the ‘offline_access’ scope. However, another company in the WG at the time had a different model so I wrote the refresh_token spec language to allow for both :)</div><div dir="auto"><br></div><div dir="auto">Personally, I still think the best practice should be session bound refresh_tokens by default and only issue un-bound refresh_tokens if the ‘offline_access’ scope is requested. Why would the user want to allow the client to access their data when they are not present by default? :-)</div><div dir="auto"><br></div><div dir="auto">However, at this point the implementations are varied as you point out so it may be worth a small specification to allow the client to request a specific behavior. Of course that means that all the authorization servers would need to add support for it to be ubiquitous. It might be nice if there is a way for authorization servers to declare what their default behavior is as well.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">George</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 1, 2022 at 9:48 PM Vittorio Bertocci via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr">I am not sure there's the need to introduce new endpoints and grants for this.<div>The scenario initially identified is the pure SPA, where the app cannot rely on a backend component. The main primitive is an affordance for the app to verify whether there's still an active OP session, eg no other RP participating in the OP session triggered a sign out.</div><div>You can easily obtain that affordance by implementing session bound refresh tokens. If your refresh tokens are session bound, attempts to use them when the session is no more will fail. Simple. Existing endpoints, artifacts, grants.</div><div>If your refresh tokens are meant to be used with a SPA, their lifetime should have an upper bound tied to the session anyway - SPA SDKs implementing the code grant routinely drop from whatever local cache they maintain access and refresh tokens upon their own sign out, hence having refresh tokens surviving that is a security hindrance anyway. In fact, some vendors even require calling their token revocation APIs on logout (which wouldn't be necessary if their refresh and access tokens would automatically be invalidated when the session it originated them terminates).</div><div>One of the challenges of the above (already discussed on this list a while ago) is that although it is a perfectly legitimate behavior for  the authorization server, we have no interoperable way to request it. In fact, the only affordance ever offered to request a refresh token is the famous "offline_access" scope, that does the exact opposite (refresh tokens are now guaranteed to be decoupled from the session) and many providers use that scope as the ONLY way to cause their authorization server to issue refresh tokens, which complicates things. Even ignoring that, basically the behavior of refresh tokens is at complete discretion of the authorization server hence today there's no way to know whether the refresh token as check session trick will work.<br></div><div>At Okta we implemented "online_access", a scope that causes our authorization server to issue refresh tokens that will automatically become invalid when the corresponding OP session is terminated (eg because of a logout). Few years ago we suggested standardizing it, but there was pushback on the account that "offline_access was a mistake hence adding online_access would be doubling down", if I remember correctly. If the browser crisis is making people reconsider, there should still be the draft somewhere :-)</div><div><br></div><div>On the inactivity timeout. One thing that gets lost with using RTs rather than iframe tricks for session renewal is that RTs no longer "touch" the authorization endpoint, hence cannot extend the life of session cookies with sliding expiration settings. This isn't a trivial problem: whether one uses the token endpoint as I described here or a new backend (eg nonbrowser UX) endpoint, allowing a backend operation to affect a front channel session would mix two completely different threat models, and throw away all the protective measures we already have in place on the authorization endpoint (eg anomaly detection based on signal entropy of the front channel). I don't think we can safely get back session extension functionality without first getting some mechanism to prove that calls to the token endpoint are coming from the same user agent that benefited from the initial session setting top level redirects. Sender constraint of some form, perhaps.    </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 30, 2022 at 6:13 PM Jake Feasel via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div>
<p><strong>This message originated outside your organization.</strong></p><br>
  <hr><br>
</div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div>While this concern is important, if we follow it through completely it kills the entire auth code grant for the same reasons. Looking at it from the browser point-of-view, the auth code grant is just some redirection across domains involving the transmission of an opaque "code" generated by the OP back to the RP, followed by an additional call from the RP to the OP passing it back; who is to say that this code isn't used for tracking users across sites?</div><div><br></div><div>"The browser people don’t seem to care about that at the moment." - There is a good reason why the privacy-conscious should not be opposed to this general technique (both the auth code and the proposed session check grants). Both grants can only work in a third-party cookie blocking environment if the browser is redirected through the OP at the top-level (i.e. as a first party interaction). I believe this is the critical point that shifts the usage from "nefarious" to "legitimate". </div><div><br></div><div>Put another way - if a privacy-abusing marketing company wanted to try to copy this pattern for their own nefarious purposes, they would have to require every page they advertise on to have a top-level redirect for all visitors through their own domain and back again (passing the requisite tracking id back in the URL). I feel like this extremely obtrusive pattern would not be acceptable for most pages that just want to show ads - it's only acceptable in the case of authentication because the site and the user have very tangible benefits from the interruption in flow associated with logging in.</div><div><br></div><div>I think we are on safe ground here, in terms of what patterns are likely to be shut down in the future. As such I would like to continue with this "session_check" grant proposal.</div><div><br></div><div>Thanks</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 10, 2022 at 3:25 AM Mischa Salle via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On Tue, Aug 09, 2022 at 06:39:27PM +0000, Nicole Roy via Openid-specs-ab wrote:<br>
> 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.<br>
<br>
probably would have the same problems with "nonce" and "state" then?<br>
Plus makes one wonder whether these three could not have been a single<br>
parameter?<br>
<br>
Mischa<br>
<br>
> > On Aug 2, 2022, at 4:30 PM, Jake Feasel via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br>
> > <br>
> > 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.<br>
> > <br>
> > 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" rel="noreferrer" target="_blank">https://docs.google.com/presentation/d/1uU3KvK6ayTpjB2OEmrSqQnUdJDPSdfxxetJrks1czvI/edit#slide=id.g11aa5093f19_0_63</a> <<a href="https://docs.google.com/presentation/d/1uU3KvK6ayTpjB2OEmrSqQnUdJDPSdfxxetJrks1czvI/edit#slide=id.g11aa5093f19_0_63" rel="noreferrer" target="_blank">https://docs.google.com/presentation/d/1uU3KvK6ayTpjB2OEmrSqQnUdJDPSdfxxetJrks1czvI/edit#slide=id.g11aa5093f19_0_63</a>><br>
> > <br>
> <br>
> [snip]<br>
> <br>
> > 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):<br>
> > <br>
> >   POST /token HTTP/1.1<br>
> >   Host: <a href="https://urldefense.com/v3/__http://server.example.com__;!!PwKahg!-sNCnmvAkBWaB80MnJiytMhdTvP9mHClc2CeSSyiYIOENf4mecfQl_wKoHP_uR0dlBcwvqmjJb3Bahnn0_uXULQ7mR5vWQ$" rel="noreferrer" target="_blank">server.example.com</a> <<a href="https://urldefense.com/v3/__http://server.example.com/__;!!PwKahg!-sNCnmvAkBWaB80MnJiytMhdTvP9mHClc2CeSSyiYIOENf4mecfQl_wKoHP_uR0dlBcwvqmjJb3Bahnn0_uXULSFUiVTrA$" rel="noreferrer" target="_blank">http://server.example.com/</a>><br>
> >   Content-Type: application/x-www-form-urlencoded<br>
> >   Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW<br>
> > <br>
> >   grant_type=session_check&sid=1234xyz<br>
> > <br>
> > 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).<br>
> > <br>
> <br>
> [snip]<br>
> <br>
<br>
<br>
<br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
> <a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!PwKahg!-sNCnmvAkBWaB80MnJiytMhdTvP9mHClc2CeSSyiYIOENf4mecfQl_wKoHP_uR0dlBcwvqmjJb3Bahnn0_uXULRsA0bY8A$" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
<br>
-- <br>
Nikhef                      Room  1.14<br>
<a href="https://www.google.com/maps/search/Science+Park+110?entry=gmail&source=g">Science Park 110</a>            Tel.  +31-6-4681 2202<br>
1098 XG Amsterdam           Fax   +31-20-592 5155<br>
The Netherlands             Email <a href="mailto:msalle@nikhef.nl" target="_blank">msalle@nikhef.nl</a><br>
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!PwKahg!-sNCnmvAkBWaB80MnJiytMhdTvP9mHClc2CeSSyiYIOENf4mecfQl_wKoHP_uR0dlBcwvqmjJb3Bahnn0_uXULRsA0bY8A$" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><table border="0" cellspacing="0" cellpadding="0" style="font-family:"Times New Roman""><tbody style="font-family:"Times New Roman""><tr style="font-family:"Times New Roman""><td valign="center" style="font-family:"Times New Roman""><a href="https://urldefense.com/v3/__https://www.forgerock.com/__;!!PwKahg!-sNCnmvAkBWaB80MnJiytMhdTvP9mHClc2CeSSyiYIOENf4mecfQl_wKoHP_uR0dlBcwvqmjJb3Bahnn0_uXULQN6gZ7BA$" target="_blank" style="font-family:"Times New Roman""><img src="https://www.forgerock.com/img/2019_forgerock_email_logo_retina.png" width="185" height="70" border="0" alt="ForgeRock" style="font-family: "Times New Roman";"></a></td><td valign="top" align="left" bgcolor="#ffffff" style="font-family:arial,helvetica,verdana,sans-serif;font-size:12px;line-height:19.8px;color:rgb(47,52,56)"><span style="font-family:arial,helvetica,verdana,sans-serif;color:rgb(3,43,117)"><strong style="font-family:arial,helvetica,verdana,sans-serif">Jake Feasel</strong></span><br>Sr. Product Manager, IDM |  ForgeRock<br><span style="display:inline-block;font-family:arial,helvetica,verdana,sans-serif"><span style="font-family:arial,helvetica,verdana,sans-serif;color:rgb(249,103,0)"><strong style="font-family:arial,helvetica,verdana,sans-serif">e</strong></span> <a href="mailto:firstname.lastname@forgerock.com" style="font-family:arial,helvetica,verdana,sans-serif;color:rgb(47,52,56)" target="_blank">jake.feasel@forgerock.com</a></span><br><span style="font-family:arial,helvetica,verdana,sans-serif;color:rgb(249,103,0)"><strong style="font-family:arial,helvetica,verdana,sans-serif">twitter</strong></span> jakefeasel  |  <span style="display:inline-block;font-family:arial,helvetica,verdana,sans-serif"><span style="font-family:arial,helvetica,verdana,sans-serif;color:rgb(249,103,0)"><strong style="font-family:arial,helvetica,verdana,sans-serif">web</strong></span> <a href="https://urldefense.com/v3/__https://www.forgerock.com/__;!!PwKahg!-sNCnmvAkBWaB80MnJiytMhdTvP9mHClc2CeSSyiYIOENf4mecfQl_wKoHP_uR0dlBcwvqmjJb3Bahnn0_uXULQN6gZ7BA$" style="font-family:arial,helvetica,verdana,sans-serif;color:rgb(47,52,56)" target="_blank">www.forgerock.com</a></span></td></tr></tbody></table></div></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
</blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!KNhV09KjpGIf4zBMZ81UEPN1vsB1cVe2Mq1iRklt_igayER49LEfFyfQYxOwHBw1pE4su9AQWQ9HgnxILT5mdUGbYIXUHFHKjuF-WF0$" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!KNhV09KjpGIf4zBMZ81UEPN1vsB1cVe2Mq1iRklt_igayER49LEfFyfQYxOwHBw1pE4su9AQWQ9HgnxILT5mdUGbYIXUHFHKjuF-WF0$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.openid.net/mailman/listinfo/openid-specs-ab__;!!FrPt2g6CO4Wadw!KNhV09KjpGIf4zBMZ81UEPN1vsB1cVe2Mq1iRklt_igayER49LEfFyfQYxOwHBw1pE4su9AQWQ9HgnxILT5mdUGbYIXUHFHKjuF-WF0$</a>  <br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="font-family:optimist,Arial,Helvetica,sans-serif;color:rgb(28,43,57);font-size:16px;float:left;width:102px;padding-top:4px;padding-right:6px;display:inline-block;vertical-align:top;height:100px"><img src="https://d2p9w4ui8rp50l.cloudfront.net/m/778c2ded498644ec/original/capital-one-logo-emailsig.png" alt="Capital One" width="80" style="vertical-align:middle;border-style:none;width:80px;height:28px;max-width:80px;display:block;color:rgb(1,61,91);font-size:14px;font-weight:600;font-family:Optimist"></div><div style="font-family:Optimist,"Helvetica Neue",Helvetica,Arial,sans-serif;color:rgb(28,43,57);font-size:16px;float:left;width:500px;min-width:500px;display:contents"><p style="font-size:14px;line-height:1.5em;font-weight:600;color:rgb(1,61,91);margin:0px!important">George Fletcher (he/him)</p><p style="margin:0px 0px 16px;font-size:12px;line-height:16px;color:rgb(1,61,91);white-space:nowrap">Executive Distinguished Engineer • Identity Architect<br><img src="https://d2p9w4ui8rp50l.cloudfront.net/m/1465f66c3ad833b4/original/locationpin-emailsig.png" alt="address" style="vertical-align:middle;border-style:none;width:8px;margin-right:3px"><span style="font-family:optimist,Arial,Helvetica,sans-serif;line-height:1.4"><span>8020 Towers Crescent Drive, Vienna, VA 22128</span><br><img src="https://d2p9w4ui8rp50l.cloudfront.net/m/0517871018033b5e/original/mobilephone-emailsig.png" alt="mobile" style="vertical-align:middle;border-style:none;width:5px;height:9px;margin-right:6px"><span>616-498-8240</span><br><br><span style="line-height:1.4">assistant: </span><img src="https://d2vppzocvtms05.cloudfront.net/media/24B3C89B-18F1-45C0-951FA826F175026F/6D4F56A7-CA22-4255-8A435780C72278FA/webimage-D978F7E8-C634-4B49-9843C19E38F5C471.png" alt="email" height="7" style="vertical-align:middle;border-style:none;width:10px;margin-left:5px;margin-right:2px"><span style="line-height:1.4"> <a href="mailto:sharon.anderson@capitalone.com" target="_blank">sharon.anderson@capitalone.com</a></span></span></p></div></div></div>

<HR><table border="0" cellspacing="0" cellpadding="0" width="100%" height="30"><BR>
<tr><BR>
<font color="#404040">The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.</font></td><BR>
</tr><BR>
</table><BR>