[Openid-specs-ab] OpenID Session Management notes

Wed May 4 14:21:14 UTC 2011

Speed seems to now be the priority.

Encrypted is nice, but not essential for the ID token.  

The short term solution for those concerned about it is to not use the ID token for session management.

Encryption should be a future extension.  
Having a way to ask for it would be as far as I would go at this point.

There are three things that need to be expressible in the request from a Gov point of view:
1 Identifier type
2 Authentication context
3 Time of last interactive login.

I don't know if a single numeric value is sufficient.

For those that don't know x.eaa is the ITU-T/ISO spec similar to the US SP-800-63.

For the sake of size lets propose:
nidt :  Name ID Type 
		Value Numeric 
		Optional
		Global=0   (Default)
		PPID=1
		session=2

eaa:  Entity Authentication Assurance
		Optional
		Default undefined if not specified
		Type Numeric 
		Value= Authentication context mapped to the 4 reference levels.

lt:  Time since last interactive login.
		Optional
		Type Numeric
		Seconds elapsed since last interactive login.

We could compress that into a single element   nidt:eaa:lt

I would however do this as a v1 extension rather than have it in the main spec.

We can discuss today.

John B.

On 2011-05-04, at 4:49 AM, Nat Sakimura wrote:

> Let us not try to achieve "single log out" in this round. 
> The voice of the floor I felt was that it is a hard problem to fix. 
> As long as we have an extension point so that we can add feature later, 
> we can do so at a later date. So, we may want to include the 
> version of the ID Token in the token itself, such as "ver"=1. 
> 
> At this point, we should concentrate on finishing the spec quickly, 
> rather than adding features that seems to be hard to resolve. 
> 
> For indicating the authentication level, 
> does it suffice to include something like "eaa"=2 in the token? 
> 
> Anything more elaborate should probably go to another extension 
> variable in the authorization response so that we do not blow up the ID token 
> as George suggested on Monday (at the Summit.) 
> We do not have much space limit for this especially for "code" grant variant of the Bindings. 
> Please suggest a name for this variable. 
> (One idea is to use "openid" for this variable and use "id_token" for the ID Token.)
> 
> I am bit concerned about the assertion disclosure 
> and assertion reuse by the session management feature. 
> 
> We seemed to have agreed that we need to add an entropy (ent) to 
> the ID token so that the combination of iat and ent acts as a nonce 
> to prevent the assertion reuse. 
> 
> To prevent the assertion disclosure, 
> we may want to leave an option of encrypting the ID token. 
> It is just the matter of adding a sentence so we may want to include 
> it in this round. We have a way to indicate if it is encrypted or not 
> because we are using JWT, so we are good to go. 
> 
> =nat
> 
> 
> On Wed, May 4, 2011 at 4:41 PM, Breno de Medeiros <breno at google.com> wrote:
> I would notice that there was some concern about the RP-initiated
> sign-out flow. Maybe the spec needs to be refined on that regard.
> Possibly have an immediate vs. non-immediate versions of sign-out (in
> case the IDP wants to obtain user consent or confirmation for logout).
> 
> On Tue, May 3, 2011 at 17:19, Mike Jones <Michael.Jones at microsoft.com> wrote:
> > Session:  OpenID Session Management
> >
> > Organizers:  Breno de Medeiros, John Bradley
> >
> > When:  May 3, 2011, 2:00 (Session 3), Room E
> >
> > Note Taker:  Mike Jones
> >
> >
> >
> > Breno introduced the id_token and went through session establishment
> > procedure.
> >
> > Id_token:
> >
> >                Is a JWT
> >
> >                Identifies provider
> >
> >                Identifies user
> >
> >                Contains an audience restriction
> >
> >                Has limited duration
> >
> > In the AB/C spec, the id_token is called “openid”.  It is the identity
> > assertion for OpenID AB/C.
> >
> >
> >
> > Breno raised the question about whether the JWT should contain an
> > authorization context.
> >
> > George Fletcher questioned of whether having an authorization context is a
> > good use of space.
> >
> > John Bradley stated that we don’t want to add every feature of SAML tokens
> > to JWTs.
> >
> >
> >
> > We discussed that we could define extensions to convey information about the
> > user’s login state.
> >
> > George raised the question of whether the PAPE information should be in the
> > token.
> >
> >
> >
> > We discussed using the equivalent of a “checkid_immediate that doesn’t give
> > you an access token” to extend the current session or revive an expired
> > session.  In either case, the authentication quality may have changed, so
> > the id_token may need to contain the PAPE state.
> >
> >
> >
> > If the user signs out at the provider, within a few minutes the user should
> > be signed out at the RPs.
> >
> >
> >
> > Session management is different for the user agent flow.
> >
> > Our security considerations will work to prevent leaking id_tokens.
> >
> >
> 
> 
> 
> --
> --Breno
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110504/7f91cbee/attachment.html>