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

Brian Campbell bcampbell at pingidentity.com
Wed Feb 25 18:30:05 UTC 2015


I was unaware of that in WS-Federation. SAML 2.0 has it too.

On Wed, Feb 25, 2015 at 11:22 AM, Mike Jones <Michael.Jones at microsoft.com>
wrote:

>  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> 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> 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
> >:
>
>  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>
> 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
> 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
>
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
>
>
>
> _______________________________________________
> 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/20150225/0a5f1c3b/attachment-0001.html>


More information about the Openid-specs-ab mailing list