[Openid-specs-ab] OpenID Session Management notes

[Nat Sakimura]

I actually was talking about something else. I agree on the need of
non-immediate flow.

I was talking about single sign out of all the sites at once immediately.

=nat via iPhone

On 2011/05/04, at 7:26, Breno de Medeiros <breno at google.com> wrote:

> 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