[Openid-specs-ab] Session ID semantics aligned across OpenID Connect front-channel and back-channel logout specs
Justin Richer
jricher at mit.edu
Sun Aug 28 21:14:00 UTC 2016
+1 to this. Many systems I've deployed will parse and validate the ID
token then throw it out, using local session management from that point
forward.
-- Justin
On 8/24/2016 12:38 PM, Brian Campbell via Openid-specs-ab wrote:
> 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
> <mailto: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
> <mailto: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) <mailto:phil.hunt at oracle.com>
> *Sent: *Wednesday, August 24, 2016 11:45 AM
> *To: *Phil Hunt (IDM) <mailto:phil.hunt at oracle.com>
> *Cc: *Mike Jones <mailto:Michael.Jones at microsoft.com>;
> openid-specs-ab at lists.openid.net
> <mailto: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
> <mailto: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
>> <mailto: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
>>> <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
>>> <mailto:Michael.Jones at microsoft.com>>
>>> *Cc:* openid-specs-ab at lists.openid.net
>>> <mailto: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
>>> <mailto: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-frontchannel-1_0-01.html>
>>>
>>> ·http://openid.net/specs/openid-connect-backchannel-1_0-03.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
>>> <http://self-issued.info/?p=1599> and as @selfissued
>>> <https://twitter.com/selfissued>.
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> <mailto:Openid-specs-ab at lists.openid.net>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> <mailto:Openid-specs-ab at lists.openid.net>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> <mailto:Openid-specs-ab at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> <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/20160828/57736fb9/attachment.html>
More information about the Openid-specs-ab
mailing list