<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Speed seems to now be the priority.<div><br></div><div>Encrypted is nice, but not essential for the ID token. </div><div><br></div><div>The short term solution for those concerned about it is to not use the ID token for session management.</div><div><br></div><div>Encryption should be a future extension. </div><div>Having a way to ask for it would be as far as I would go at this point.</div><div><br></div><div>There are three things that need to be expressible in the request from a Gov point of view:</div><div>1 Identifier type</div><div>2 Authentication context</div><div>3 Time of last interactive login.</div><div><br></div><div>I don't know if a single numeric value is sufficient.</div><div><br></div><div>For those that don't know x.eaa is the ITU-T/ISO spec similar to the US SP-800-63.</div><div><br></div><div>For the sake of size lets propose:</div><div>nidt : Name ID Type </div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Value Numeric </div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Optional</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Global=0 (Default)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>PPID=1</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>session=2</div><div><br></div><div>eaa: Entity Authentication Assurance</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Optional</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Default undefined if not specified</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Type Numeric </div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Value= Authentication context mapped to the 4 reference levels.</div><div><br></div><div>lt: Time since last interactive login.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Optional</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Type Numeric</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Seconds elapsed since last interactive login.</div><div><br></div><div>We could compress that into a single element nidt:eaa:lt</div><div><br></div><div>I would however do this as a v1 extension rather than have it in the main spec.</div><div><br></div><div>We can discuss today.</div><div><br></div><div>John B.</div><div><br></div><div><br></div><div><br></div><div><div><div>On 2011-05-04, at 4:49 AM, Nat Sakimura wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Let us not try to achieve "single log out" in this round. <div>The voice of the floor I felt was that it is a hard problem to fix. <br><div>As long as we have an extension point so that we can add feature later, </div>
<div>we can do so at a later date. So, we may want to include the </div><div>version of the ID Token in the token itself, such as "ver"=1. </div><div><br></div><div>At this point, we should concentrate on finishing the spec quickly, </div>
<div>rather than adding features that seems to be hard to resolve. </div><div><br></div><div><div>For indicating the authentication level, </div><div>does it suffice to include something like "eaa"=2 in the token? </div>
<div><br></div><div>Anything more elaborate should probably go to another extension </div><div>variable in the authorization response so that we do not blow up the ID token </div><div>as George suggested on Monday (at the Summit.) </div>
<div>We do not have much space limit for this especially for "code" grant variant of the Bindings. </div></div><div>Please suggest a name for this variable. </div><div>(One idea is to use "openid" for this variable and use "id_token" for the ID Token.)</div>
<div><br></div><div>I am bit concerned about the assertion disclosure </div><div>and assertion reuse by the session management feature. </div><div><br></div><div>We seemed to have agreed that we need to add an entropy (ent) to </div>
<div>the ID token so that the combination of iat and ent acts as a nonce </div><div>to prevent the assertion reuse. </div><div><br></div><div>To prevent the assertion disclosure, </div><div>we may want to leave an option of encrypting the ID token. </div>
<div>It is just the matter of adding a sentence so we may want to include </div><div>it in this round. We have a way to indicate if it is encrypted or not </div><div>because we are using JWT, so we are good to go. </div><div>
<br></div><div>=nat</div><div><br></div><div><br><div class="gmail_quote">On Wed, May 4, 2011 at 4:41 PM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I would notice that there was some concern about the RP-initiated<br>
sign-out flow. Maybe the spec needs to be refined on that regard.<br>
Possibly have an immediate vs. non-immediate versions of sign-out (in<br>
case the IDP wants to obtain user consent or confirmation for logout).<br>
<div><div></div><div class="h5"><br>
On Tue, May 3, 2011 at 17:19, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:<br>
> Session: OpenID Session Management<br>
><br>
> Organizers: Breno de Medeiros, John Bradley<br>
><br>
> When: May 3, 2011, 2:00 (Session 3), Room E<br>
><br>
> Note Taker: Mike Jones<br>
><br>
><br>
><br>
> Breno introduced the id_token and went through session establishment<br>
> procedure.<br>
><br>
> Id_token:<br>
><br>
> Is a JWT<br>
><br>
> Identifies provider<br>
><br>
> Identifies user<br>
><br>
> Contains an audience restriction<br>
><br>
> Has limited duration<br>
><br>
> In the AB/C spec, the id_token is called “openid”. It is the identity<br>
> assertion for OpenID AB/C.<br>
><br>
><br>
><br>
> Breno raised the question about whether the JWT should contain an<br>
> authorization context.<br>
><br>
> George Fletcher questioned of whether having an authorization context is a<br>
> good use of space.<br>
><br>
> John Bradley stated that we don’t want to add every feature of SAML tokens<br>
> to JWTs.<br>
><br>
><br>
><br>
> We discussed that we could define extensions to convey information about the<br>
> user’s login state.<br>
><br>
> George raised the question of whether the PAPE information should be in the<br>
> token.<br>
><br>
><br>
><br>
> We discussed using the equivalent of a “checkid_immediate that doesn’t give<br>
> you an access token” to extend the current session or revive an expired<br>
> session. In either case, the authentication quality may have changed, so<br>
> the id_token may need to contain the PAPE state.<br>
><br>
><br>
><br>
> If the user signs out at the provider, within a few minutes the user should<br>
> be signed out at the RPs.<br>
><br>
><br>
><br>
> Session management is different for the user agent flow.<br>
><br>
> Our security considerations will work to prevent leaking id_tokens.<br>
><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<font color="#888888">--Breno<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div></div>
</blockquote></div><br></div></body></html>