<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br>On 30. aug.2011, at 17:09, Nat Sakimura wrote:<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">and MUST NOT return id_token unless it<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is in the user in-presence (browser) session. Otherwise, the user may<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">be being impersonated by the application.<br></blockquote></blockquote></blockquote><div><br></div><div>The user is not present in the back-channel token request call, where the id token is returned in the authorization code flow.</div><div>The user is neither present in the back-channel refresh token call, where an id_token is returned in exchange for refresh_token. The refresh_token is likely to have a much longer duration than the session.</div><div><br></div><div>Section 3.1 Session (draft-03):</div><div><i><font class="Apple-style-span" color="#b9171a"><span class="Apple-tab-span" style="white-space:pre"> </span>In either case, an ID Token will also be returned along with the access token when submitting a refresh token to the token access endpoint if the initial authorization request included id_token in the response_typeparameter. </font></i></div><div><br></div><br><blockquote type="cite">Yes. OAuth Client, to be precise.<br><br>Important distinction between Access Token and ID Token are as follows:<br></blockquote><div><br></div><div>I completely agree that the ID Token and Access Token have different properties, and it is the current spec that treats the two as the same. My proposal would be to use the access token to obtain the ID Token, something that would make the different properties of these two tokens easier to understand, more clear and not break with existing (OAuth) libraries.<br></div><br><blockquote type="cite">1) Access Token cannot expand the scope while ID Token may potentially<br>have the power to do so.<br>2) Access Token can be long lived, but ID Token is valid only within<br>the session.<br>3) Access Token can be presented to a third party OAuth resource while<br>ID Token is not.<br>4) In the code flow, access_token is not exposed to the browser, while<br>ID Token potentially is.<br></blockquote><div><br></div><div>Where in the code flow can the ID token potentially be exposed in the browser? Are you thinking of the refresh session endpoint?</div><div><br></div><blockquote type="cite">Therefore, in general, you cannot issue an access token to a scope<br>'id_token'. If you do, the OAuth resource that the access token was<br>used against may be able to obtain 'id_token' to create the session<br>and impersonate the user at the Client.<br></blockquote><div><br></div><div>OK; let us confirm that we agree on the following:</div><div><br></div><div>* Returning an ID Token and issuing an ID Token are two different things.</div><div>* An ID Token is always (and only) issued when the user is sent via the authorization endpoint; and the 'iat' timestamp will always be associated with that point in time.</div><div>* In the implicit flow (current spec) the issued ID Token is returned immediately together with the token.</div><div>* In the authorization code (current spec) the issued ID Token is returned in response for the code - the ID Token is not issued at this point, instead the ID Token issued at the authoriation time, is cached at the OP and returned to the RP for the first time.</div><div><br></div><div>What I am suggesting is that a OAuth protected endpoint, that requires an openid-idtoken access token for authorization; will return the ID Token issued earlier. </div><div>* The ID Token is already audience restricted to the specific client, which means that if the openid-idtoken scoped access token by some means are obtained by a foreign Oauth client, it cannot be used to get anything else than a copy of the old ID Token issued and restricted to the first client.</div><div>* The client may not use the openid-idtoken access token to issue any 'new session', and obviously not impersonating the user by any means.</div><div><br></div><div>The OAuth protected endpoint that returns an ID Token JWT or a ID Token unpacked JSON when authorized with the openid-idtoken scoped access token, would be used in the normal flow, but I think that it may also make the currently speced 'check session' endpoint superfluous.</div><div><br></div><div>Refreshing an openid-idtoken scoped access token will not extend any session; instead extend the period where you are able to retreive the cached version of the id token by this endpoint. I dont think it makes sense to extend the validity of this access token to anything longer than the validity of the session. </div><div><br></div><div>In the case of a multi-scoped token is used (for simplicity), asking this endpoint for a ID Token long after is has expired would be as simple getting an error that the session does not longer exists (or similar).</div><div><br></div><div>I have a couple of things two say about the refresh token service, so I'm firing off a separate email on that topic.</div><div><br></div><div>I included your other email here:</div><div><blockquote type="cite">P.S. Having summed up the history -- I am actually OK with using<br>access token to obtain id_token if the first access token is suitably<br>constrained in such a way that it can only be used against the<br>userinfo endpoint. This is equivalent in constraining the 'scope' such<br>that it MUST NOT include anything but the Connect scopes. Returning<br>id_token together with access_token then is just an optional<br>optimization for the latency. I think this approach is cleaner.<br>Downside is obvious: more optional portion means more interoperability<br>issues though.</blockquote><br></div><div>The client will ALWAYS ask for all the scopes it ever needs; in the request. Then I would suggest it is up to the provider whether to issue multi-scoped tokens or not.</div><div>If there is any good reasons why the client may indicate its preferences to that, it may be included as part of the metadata, or as a parameter in the authorization request.</div><div>Implementation of scope handling on the client side, being able to handle the fact that it receives a subset of the requested scopes, should not be rocket science, as this is very Core OAuth operations.</div><div>I would say by including multiple scopes in the Lite spec; we are already expecting that the client handles scopes properly anyway. AFAIK in the current Lite spec there is nothing that denies the provider from first issuing a long-lived access token scoped 'openid email', and then client is expected to use the refresh token to request a new access token (which might have a different validity period) for 'openid profile'.</div><div>We also need to take into consideration that OpenID Connect is used in combination with non-connect scopes, making sure that clients can deal with scopes in the first places, will increase the chances of interoperability with other protocols.</div><div>In example: if openid is requested together with some non-openid connect scopes, the provider may choose to return only the non-openid scopes in the first request to the access token endpoint; the client MUST then be able to request additional scopes to continue with the openid connect flow.</div><div>To increase interoperability, we should describe scopes in more detail in the spec, regardless of whether we decide to use a id_token access token; to deal with the cases mentioned above.</div><div><br></div><div><br></div><div>Andreas</div></body></html>