[Openid-specs-ab] OpenID Session Management notes

[Nat Sakimura]

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/e4ed02f0/attachment.html>