<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://5238/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">One thing we need to be clear on with tokens issued from the token endpoint no matter the grant type is that they represent the authentication event used to get the token (refresh/assertion/id_token) that is being used to request the id_token.<div><br></div><div>This is NOT a back channel way to see if a user is still logged in.</div><div><br></div><div>The main reason someone would do this based on a refresh token is to get a id_token with a different audience or perhaps different claims (I think Google refers to this as side scoping if I recall correctly).</div><div><br></div><div>I understand that some people think doing this as part of refresh adds to possible confusion by the client. Remember that it is the client that is requesting this in the first place and if it dosen't understand the semantics of a id_token based on a refresh grant type it will just ignore the extra parameter in the response.</div><div><br></div><div>The other approach where we create a new grant_type that takes a id_token, perhaps refresh token and maybe a request_object is a larger undertaking. It was pam that pointed out if you go down that road there will be lots of people trying to pile on features. This should be a separate extension if people want it.</div><div><br></div><div>For the refresh grant type allowing the AS to cache the info about the id_token that was originally issued with that refresh token and return it again when the refresh token is used should not be precluded.</div><div>I do agree that we do probably need some rules around the question of "iat" , "exp" , "azp" , "acr" and "aud" changing if that is allowed. There is a question if this is part of the messages or core spec or a separate profile of the refresh grant.</div><div><br></div><div>John B.</div><div><div><div>On 2013-03-01, at 12:53 AM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Responding to Justin, I don’t see the ability to return an ID Token from the Token Endpoint for grant types other than just “authorization_code” as being a break from what an ID Token standard for at all – let alone it being dangerous. Here’s why…<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">An ID Token is a “</span><span lang="EN" style="font-family: Verdana, sans-serif; ">Token that contains Claims about the authentication event</span><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">”. That would remain true.<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">On the call, I think someone was saying something like “but the ID Token would then not necessarily represent a logged-in user session”. <span class="Apple-converted-space"> </span><i>It never did.<span class="Apple-converted-space"> </span></i> It represents that the user<span class="Apple-converted-space"> </span><i>had logged in</i>. If you want to know whether the user is still logged in, make a “prompt”:”none” request using the ID Token as the “id_token_hint” parameter value, and find out. Or use Session Management, which will result in you knowing that the interactive user session was terminated within a small delta of time after it happened. None of that changes.<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">What does change is that it’s no longer prohibited to return an ID Token from the Token Endpoint for grant_types other than “authorization_code”. For instance, that might let some deployers use the “client_credentials” grant_type, which was previously prohibited.<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">I don’t see any practical downside to this change, whereas I do see upsides in the additional flexibility that it gives us.<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> -- Mike<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">P.S. Pam used to have reservations about this change, but once she realized this afternoon that an ID Token never did represent a logged-in user session, she dropped her reservations. I hope that you and Brian will do likewise, having thought about it some more, Justin.<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(181, 196, 223); padding: 3pt 0in 0in; "><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "><span class="Apple-converted-space"> </span><a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [mailto:openid-<a href="mailto:specs-ab-bounces@lists.openid.net">specs-ab-bounces@lists.openid.net</a>]<span class="Apple-converted-space"> </span><b>On Behalf Of</b>Torsten Lodderstedt<br><b>Sent:</b><span class="Apple-converted-space"> </span>Thursday, February 28, 2013 11:01 PM<br><b>To:</b><span class="Apple-converted-space"> </span>Justin Richer; <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br><b>Subject:</b><span class="Apple-converted-space"> </span>Re: [Openid-specs-ab] Returning ID Tokens from Refresh Tokens<o:p></o:p></span></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">Hi Justin,<span class="Apple-converted-space"> </span><br><br>I don't see the difference between both approaches. The AS should be able to link the refresh token to authentication instant and session as well. So before issuing another id token it can perfom some checks. Moreover, the new id token should contain the original authentication instant and method. Thus a client may decide whether a fresh authentication is required.<br><br>regards,<br>Torsten.<o:p></o:p></p><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br>Justin Richer <<a href="mailto:jricher@mitre.org" style="color: purple; text-decoration: underline; ">jricher@mitre.org</a>> schrieb:<o:p></o:p></div><pre style="margin: 0in 0in 0.0001pt; font-size: 10pt; font-family: 'Courier New'; white-space: pre-wrap; word-wrap: break-word; "><span style="font-family: Arial, sans-serif; ">Issues #787 was recently filed, asking to open up the restrictions <br>around when to return id tokens from the token endpoint. Currently, this <br>is restricted to the authorization_code grant type and no others, but it <br>has been proposed that this is too restrictive and that there are use <br>cases to allow returning of id tokens from assertions and refresh tokens.<br><br>However, Brian and I both think that the return from a refresh token is <br>a potentially dangerous break from previous notions of what the id token <br>represents. To me at least, the id token always represented a handle on <br>the user's session that contained a directly accessible pack of <br>information about the current user. The refresh token, on the other <br>hand, is a long-term delegation that in many cases never expires. I <br>could therefore get a "fresh" id token from a <o:p></o:p></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 10pt; font-family: 'Courier New'; "><span style="font-family: Arial, sans-serif; "> grant<o:p></o:p></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 10pt; font-family: 'Courier New'; "><span style="font-family: Arial, sans-serif; ">that happened months <br>ago, and that doesn't seem right to me. It could be very dangerous for <br>an app to pretend that a user is still logged in and authorized by their <br>IdP by perpetually refreshing the id token in the back channel like <br>this. Yes, an app can already do this by setting some kind of local <br>cookie that never expires or any number of other things, but is this a <br>pattern we want to tacitly encourage? I would argue that if you can <br>refresh an id token like this, it becomes even less distinct from the <br>existing access token.<br><br>As such, I believe that if you want to extend the session, you should do <br>so in a way that directly uses the existing session key. What I proposed <br>a few months ago, and what we've implemented here, is a method that uses <br>the ID token itself as an JWT Bearer Assertion in a call to the token <br>endpoint. The AS can then make the decision if the id token is being <br>presented <o:p></o:p></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 10pt; font-family: 'Courier New'; "><span style="font-family: Arial, sans-serif; "> in a<o:p></o:p></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 10pt; font-family: 'Courier New'; "><span style="font-family: Arial, sans-serif; ">context that it makes sense to extend. And in this case, <br>you're trading one ID token for another, and not getting a *new* one <br>through the back channel.<br><br>It was suggested on the call this morning that we relax the language in <br>the spec to say that an ID token MAY come back from any grant, but that <br>we have something in the security considerations dictating the possible <br>pitfalls. So it's those pitfalls that I'd like to discuss here -- are <br>there horrible things that could really happen here, or am I simply <br>jumping at shadows?<br><br>-- Justin<o:p></o:p></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 10pt; font-family: 'Courier New'; text-align: center; "><span style="font-family: Arial, sans-serif; "><hr size="3" width="100%" align="center"></span></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 10pt; font-family: 'Courier New'; "><span style="font-family: Arial, sans-serif; "><br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" style="color: purple; text-decoration: underline; ">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" style="color: purple; text-decoration: underline; ">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></span></pre></div></div>_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab</div></blockquote></div><br></div></body></html>