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

[Mike Jones]

Also great points. Suggested text also solicited to capture these thoughts.

From: Phil Hunt (IDM) via Openid-specs-ab<mailto:openid-specs-ab at lists.openid.net>
Sent: Wednesday, August 24, 2016 12:58 PM
To: John Bradley<mailto:ve7jtb at ve7jtb.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

1. Re session: when we start talking session from op we are causing confusion. Is it the op session?

My worry is that if the relying party executes the logout and clears its own session it still needs to track the id token in case the id token reappears since while the token might be valid is revoked. Otherwise it might treat as a new login session.

Likewise if a logout is followed immediately by a new login, we have to make sure the login is accepted.

Phil

On Aug 24, 2016, at 9:42 AM, John Bradley via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:

Correct,  That is something that we might want to clarify.

Some people are interpreting the exp as the life time of the token and others are taking it as the lifetime of the session.

The spec states that for validating the id_token "The current time MUST be before the time represented by the exp Claim (possibly allowing for some small leeway to account for clock skew).”

As a result the server may receive expired id_tokens as hints (The id_token is always going to be invalid as the audience is wrong that is why it is just a hint)

I think we did talk at one time about having a session duration like SAML, but didn’t as it is almost never honoured by SAML SP.

John B.
On Aug 24, 2016, at 1:22 PM, Brian Campbell via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:


I think we need to be careful with some of these assumptions. The exp on the ID Token doesn't correlate to the timeouts or expiration of the session the client establishes from the ID Token.  And there's no normative requirements about the exp in an id_token_hint.

On Wed, Aug 24, 2016 at 9:49 AM, 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.  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-backchannel-1_0-03.html


                                                       -- Mike

P.S.  This notice was also posted at 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

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

_______________________________________________
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


_______________________________________________
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

_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160824/8dfb8f8e/attachment.html>