[Openid-specs-ab] Session ID semantics aligned across OpenID Connect front-channel and back-channel logout specs

Wed Aug 24 22:43:24 UTC 2016

Further, if a new id token is issued after iat of the logout SET, than that token represents a new session (assuming there is no other way to distinguish). 

The use case I am thinking of is where a user is logged out and immediately logs back in due to a password or account reset or other reason. 

I can see some RPs getting confused and getting into a race condition. 

Phil

> On Aug 24, 2016, at 3:37 PM, Phil Hunt (IDM) via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> The issue I raised was how long does a relying party need to keep track of the logout in case a token is re-presented that erroneously causes a new session when it should be rejected as logged out.
> 
> MUST'nt the logout event be valid for as long as an outstanding token is valid? 
> 
> Phil
> 
>> On Aug 24, 2016, at 3:18 PM, John Bradley via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>> 
>> There are two discussions going on in the thread.
>> 
>> One is the meaning of exp in for the logout message.   It would be if you receive this message after this time then don’t process it.  
>> That is more important if you don’t include sid as you don’t want a delayed message blowing away a new session.  
>> 
>> With sid you may wan to always process the logout as any new one would have a new sid. 
>> 
>> The other one that crept in was what is the meaning of exp in the id_token.
>> 
>> That is relatively clear that it is the lifetime of the id_token being initially accepted by the client for establishing a session. 
>> The question is if we need an errata someplace to clarify foe some people who are reading exp to be the lifetime of the users session before the client must should go back and validate that the user still has a session at the IdP.    I think someone also mentioned an interpretation of it being the lifetime of the users session at the IdP.
>> 
>> That sort of clarification for the id_token could be a errata, that might be useful as different interpretations will lead to interoperability or security issues.
>> 
>> John B.
>> 
>>> On Aug 24, 2016, at 6:29 PM, Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>>> 
>>> The text would go in the logout specs for two reasons:
>>> 1.  They pertain to the lifetime of the logout request
>>> 2.  We can’t make normative changes to Core
>>>  
>>>                                                        -- Mike
>>>  
>>> From: Brian Campbell [mailto:bcampbell at pingidentity.com] 
>>> Sent: Wednesday, August 24, 2016 2:21 PM
>>> To: Mike Jones <Michael.Jones at microsoft.com>
>>> Cc: Thomas Broyer <t.broyer at ltgt.net>; Phil Hunt (IDM) <phil.hunt at oracle.com>; openid-specs-ab at lists.openid.net
>>> Subject: Re: [Openid-specs-ab] Session ID semantics aligned across OpenID Connect front-channel and back-channel logout specs
>>>  
>>> Where would such text go? Core errata? Or?
>>>  
>>> On Wed, Aug 24, 2016 at 11:53 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>>> Suggested text capturing these points would be great.
>>>  
>>> From: Brian Campbell
>>> Sent: Wednesday, August 24, 2016 12:39 PM
>>> To: Thomas Broyer
>>> Cc: Mike Jones; Phil Hunt (IDM); openid-specs-ab at lists.openid.net
>>> 
>>> Subject: Re: [Openid-specs-ab] Session ID semantics aligned across OpenID Connect front-channel and back-channel logout specs
>>>  
>>> I would say yes, Thomas, but I think the answer will depend on who you ask and when.
>>> 
>>> Typically, in my own experience anyway, the SSO token (like the id token) has a relatively short expiration time and is consumed and validated by the client/RP once and then that client sets up its own session or security context with its own lifetime. 
>>> 
>>> But I think some have used or want to use the id token directly as the session token at the client/RP. And doing so might then rely on the exp in the id token as the session expiration, which presumably would want a larger window. 
>>> 
>>> I don't think the spec(s) explicitly require one approach or the other. And, as such, I don't think any of the logout stuff can assume one or the other.
>>>  
>>>  
>>> 
>>>  
>>> On Wed, Aug 24, 2016 at 10:19 AM, Thomas Broyer via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>>> Aren't ID Tokens supposed to have a short expiration time? (I asked twice already over the last 2 years and never got an answer, maybe this time?)
>>>  
>>> On Wed, Aug 24, 2016 at 6:05 PM Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>>> I found your original logic to be sound.  The ID Token could be reused with id_token_hint until it expires. Communicating the matching expiration time in the logout made sense to me – particularly in the no Session ID case, as John points out.
>>>  
>>> – Mike
>>>  
>>> From: Phil Hunt (IDM)
>>> Sent: Wednesday, August 24, 2016 11:45 AM
>>> To: Phil Hunt (IDM)
>>> Cc: Mike Jones; openid-specs-ab at lists.openid.net
>>> 
>>> Subject: Re: [Openid-specs-ab] Session ID semantics aligned across OpenID Connect front-channel and back-channel logout specs
>>> Scratch that. Was thinking oauth resource and tokens. 
>>>  
>>> Not sure the same would exist here. 
>>> 
>>> Phil
>>> 
>>> On Aug 24, 2016, at 8:17 AM, Phil Hunt (IDM) via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>>> 
>>> It may be useful to include the original session expiry time or make the exp match the original id token. If the service isn't tracking state of sessions it needs to know for how much longer an id token might show up in order to keep its revocation list managed over time. 
>>> 
>>> Phil
>>> 
>>> On Aug 24, 2016, at 5:58 AM, Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>>> 
>>> Good catch, Filip.  I’d replaced “exp” (expiration time) with “iat” (issued at) to align it with the ID Events spec https://tools.ietf.org/html/draft-hunt-idevent-token-03.  But I’d also wanted to ask the working group – do we want to retain an explicit expiration time in the logout token?
>>>  
>>>                                                        -- Mike
>>>  
>>> From: Filip [mailto:panva.ip at gmail.com] 
>>> Sent: Wednesday, August 24, 2016 1:24 AM
>>> To: Mike Jones <Michael.Jones at microsoft.com>
>>> Cc: openid-specs-ab at lists.openid.net
>>> Subject: Re: [Openid-specs-ab] Session ID semantics aligned across OpenID Connect front-channel and back-channel logout specs
>>>  
>>> Hello,
>>>  
>>> reviewing the changes i noticed in Section 2.4 of Backchannel draft 03 the 'exp' claim got removed from Logout Token claims, however section 4 still recomends OPs to use short expiration times for their Logout Tokens. It is not clear enough if 'exp' should be present or not.
>>> 
>>> Best Regards,
>>> Filip Skokan
>>>  
>>> On Wed, Aug 24, 2016 at 3:44 AM, Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>>> Session ID definitions in the OpenID Connect front-channel and back-channel logout specs have been aligned so that the Session ID definition is now the same in both specs.  The Session ID is scoped to the Issuer in both specs now (whereas it was previously global in scope in the front-channel spec).  This means that the issuer value now needs to be supplied whenever the Session ID is.  This doesn’t change the simple (no-parameter) front-channel logout messages.  The back-channel specification is now also aligned with the ID Event Token specification.
>>>  
>>> The new specification versions are:
>>> ·       http://openid.net/specs/openid-connect-frontchannel-1_0-01.html
>>> 
>>> ·       http://openid.net/specs/openid-connect-backchannel-1_0-03.html
>>> 
>>>  
>>>                                                        -- Mike
>>>  
>>> P.S.  This notice was also posted at http://self-issued.info/?p=1599 and as @selfissued.
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> 
>>>  
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> 
>>>  
>>>  
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160824/863adc79/attachment.html>