[Openid-specs-ab] Spec call notes 23-Feb-15

Mike Jones Michael.Jones at microsoft.com
Wed Feb 25 18:22:08 UTC 2015


I know that WS-Federation has a back channel logout mechanism.  We should at least understand how what we propose relates to that before inventing something new from whole cloth.

From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Brian Campbell
Sent: Wednesday, February 25, 2015 10:18 AM
To: John Bradley
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Spec call notes 23-Feb-15

For what it's worth, the back-channel stuff we did with logout flipped things around. The clients/RPs we were dealing with are stateless on the server side with respect to individual sessions, which renders a back-channel logout request from OP to RP pretty much useless. We have the OP maintain a lightweight session revocation list and RPs can poll it periodically at their discretion. I'm not suggesting that that model be standardized but just offering a data point on one approach that was taken.
I might humbly suggest that back-channel logout is not something that should be standardized at the SSO protocol layer like Connect. It strikes me as more of the kind of thing that'd be useful as the account level and more of a "shared signals" or deprovisiniong kind of thing.


On Tue, Feb 24, 2015 at 5:18 AM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:
I don’t actualy think we need a signed token in the front channel.

I am talking about using a signed token in the back channel, but that is quite different, as all of the session information needs to be derived from the token as the RP has no session cooke.

In the front channel there are two issues.

1 what account to sign out if there is more than one logged in from the IdP
2 is this from the IdP or a cross site request forgery.

1 could be solved by including the subject or a session identifier.
2 The sid alone should be sufficient to stop a XSRF unless the id_token has leaked.

If you send the sid then you probably don’t need to send the sub. (That is where I thought we were going)

I think trying to OAuth protect  the clients endpoint with a bearer token might be an advanced option, but that would need to be in a query parameter to be sent from a image tag.
Is setting up a way for clients to provision a AS with a AT per subject worth while.   If it is one AT for all subjects then it leaks right away and is no real good to prevent xsrf.

Modifying the authorization request to include a token is possible, but I am not sure how necessary.

John B.

On Feb 24, 2015, at 1:38 AM, Torsten Lodderstedt <torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>> wrote:

I don't understand why you want to invite a new token concept for the logout. First there was a sid. The sid alone is not enough (if the same value is used among RPs in the same session), therefore you need to introduce an audience and a digital signature. This is getting more complex with every iteration.

From a conceptual perspective, the challenge we are facing is the OP wants to send a request to a protected resource (logout endpoint at the RP). Sounds familiar? Yes, because this is classic OAuth with the OP taking the role of the client.

I would therefore suggest to let the RP register the token it wants to get its logout endpoint invoked with. One could also use RFC 6750 mechanisms (or even pop) to carry the token in the actual logout request. The advantage of this design: this token is opaque to the OP. There is no need to specify it. The token design and how to identify the respective session at the RP is at the RP's discretion. It could just be a reference to its session database. It also could be a JWT.

kind regards,
Torsten.
Am 24. Februar 2015 03:45:34 MEZ, schrieb John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>:
My point was not that audience was not needed, but rather that it could be a different audience to differentiate between the login and sign out tokens.
That WAY the sign out tokens would not be accepted as login tokens.   eg the logout_uri rather than the client_id as a posable example.

John B.

On Feb 23, 2015, at 6:32 PM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:

Spec call notes 23-Feb-15


Nat Sakimura

Mike Jones

Brian Campbell

Edmund Jay

John Bradley


Agenda

               Use of Pragma: no-cache in Form Post Response Mode

               Logout

               Certification


Use of Pragma: no-cache in Form Post Response Mode

               Brian believes the only change needed is to remove the "Pragma: no-cache"

               He believes that "Cache-Control: no-store" also performs a "Cache-Control: no-cache"

                              Mike will confirm this

               Then Mike will make the change and update the blog post

               Later in the call, Brian pointed out that we should have normative text about not caching the result

                              He will propose a sentence to add


Logout

               When using the Session ID on the front channel, you're only picking from among those that are live in the browser

               An alternative to putting "sid" and "iss" as query parameters is to them in a JWT

                              But it should not be a legal ID Token, so perhaps shouldn't have a subject

                              John pointed out that we should at least consider whether an audience would be needed

               John will be working on a back channel logout spec also using the Session ID

                              We should try to have these be as close to one another as reasonably possible

                              He's on his way to Barcelona for MWC, so this may not happen for a bit

               People agreed that the differentiation between image and iframe GETs must happen at registration time

               The query parameters still need to be reviewed


Certification

               Roland now has testing up on the Symantec hosts

               A team member of Roland's created an OP self-registration page at https://op.certification.openid.net:60000/

                              When you select dynamic configuration, the answer to the first question is the issuer path (this isn't obvious)

                              Mike will file some bugs on clarifying how the tool works

               People doing testing should migrate over to the official server

               This also means that Roland can now also put up the RP tests

               Breno should be getting back to us within a week or so on how long it will take them to create a conforming implementation

_______________________________________________
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

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.


_______________________________________________
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/20150225/fbb6cbbd/attachment-0001.html>


More information about the Openid-specs-ab mailing list