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>