<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">An ID Token is a “</span><span lang="EN" style="font-family:"Verdana","sans-serif";color:black">Token that contains Claims about the authentication event</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">”.
That would remain true.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">On the call, I think someone was saying something like “but the ID Token would then not necessarily represent a logged-in user session”.
<i>It never did. </i> It represents that the user <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></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> openid-specs-ab-bounces@lists.openid.net [mailto:openid-specs-ab-bounces@lists.openid.net]
<b>On Behalf Of </b>Torsten Lodderstedt<br>
<b>Sent:</b> Thursday, February 28, 2013 11:01 PM<br>
<b>To:</b> Justin Richer; openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-ab] Returning ID Tokens from Refresh Tokens<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi Justin, <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>
<p class="MsoNormal"><br>
<br>
Justin Richer <<a href="mailto:jricher@mitre.org">jricher@mitre.org</a>> schrieb:<o:p></o:p></p>
<pre style="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><span style="font-family:"Arial","sans-serif""> grant<o:p></o:p></span></pre>
<pre><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><span style="font-family:"Arial","sans-serif""> in a<o:p></o:p></span></pre>
<pre><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="text-align:center"><span style="font-family:"Arial","sans-serif""><hr size="3" width="100%" align="center"></span></pre>
<pre><span style="font-family:"Arial","sans-serif""><br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></span></pre>
</div>
</div>
</body>
</html>