[Openid-specs-ab] OpenID Session Management notes

[Breno de Medeiros]

On Wed, May 4, 2011 at 04:49, Nat Sakimura <sakimura at gmail.com> 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.

I disagree. There was concern about requiring consent, which I think
can be addressed by a non-immediate version.

You are confusing a separate issue that was raised about traditional
approaches to single sign-out that require the server to keep state
about all RPs the user has signed in to and do a 'signout push flow'
at the IDP. This is not what we're proposing, but essentially 'pull'
at the RP.


> 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,

The feature is not hard to provide.

> 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
>



-- 
--Breno