[Openid-specs-ab] Session cleanup via back-channel
Todd W Lainhart
lainhart at us.ibm.com
Thu Mar 13 19:53:14 UTC 2014
> Your example seems to indicate that JavaScript code in pages present in
the browser history doesn’t get to run unless the page is the displayed
page. Is that correct?
I'm also not an expert, but that's my understanding.
> Do you have any sense why this issue also prompted discussions on
non-opaque access tokens and introspection?
I don't. That's something that George/Justin brought up. Went over my
head.
Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart at us.ibm.com
From: Mike Jones <Michael.Jones at microsoft.com>
To: Todd W Lainhart/Lexington/IBM at IBMUS,
Cc: George Fletcher <gffletch at aol.com>, Justin Richer
<jricher at mitre.org>, "openid-specs-ab at lists.openid.net"
<openid-specs-ab at lists.openid.net>,
"openid-specs-ab-bounces at lists.openid.net"
<openid-specs-ab-bounces at lists.openid.net>, Pedro Felix
<pmhsfelix at gmail.com>
Date: 03/13/2014 03:26 PM
Subject: RE: [Openid-specs-ab] Session cleanup via back-channel
Thanks for the concrete example, Todd. That’s useful. Your example seems
to indicate that JavaScript code in pages present in the browser history
doesn’t get to run unless the page is the displayed page. Is that
correct? And is the answer the same for all browsers or is it different
for different browsers? (I’m not an expert in browser implementation
details, so I’m openly asking this, hoping that someone on the thread does
have this expertise.)
Do you have any sense why this issue also prompted discussions on
non-opaque access tokens and introspection?
-- Mike
From: Todd W Lainhart [mailto:lainhart at us.ibm.com]
Sent: Thursday, March 13, 2014 12:12 PM
To: Mike Jones
Cc: George Fletcher; Justin Richer; openid-specs-ab at lists.openid.net;
openid-specs-ab-bounces at lists.openid.net; Pedro Felix
Subject: Re: [Openid-specs-ab] Session cleanup via back-channel
> Am I correct or wrong that this is the same issue?
It is the same issue. My sense at the time it was closed was that folks
on the call didn't want to hold up the specs for this, and so Nat proposed
the extension route, with the observation that the topic had been raised
before. I'm also recalling that maybe the Googlers had something to say
about this.
> is there a reason that RPs can’t learn of the OP-initiated logout via
the JavaScript session state changed notification already in the spec?
I'm not speaking for Pedro, but I'll give you an example (but real)
scenario that prompted #916. Browser is viewing the protected resources
of RP "A" (a session has already been started). Bob clicks a link on the
page which now shows the representation of a protected resource from RP
"B". Bob selects "logout", which directs "B" to the end_session endpoint.
Ideally, "A" would get notified of the session end so that it can drop
resources that it was associating to Bob.
Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainhart at us.ibm.com
From: Mike Jones <Michael.Jones at microsoft.com>
To: George Fletcher <gffletch at aol.com>, Pedro Felix <
pmhsfelix at gmail.com>, Justin Richer <jricher at mitre.org>,
Cc: "openid-specs-ab at lists.openid.net" <
openid-specs-ab at lists.openid.net>
Date: 03/13/2014 02:47 PM
Subject: Re: [Openid-specs-ab] Session cleanup via back-channel
Sent by: openid-specs-ab-bounces at lists.openid.net
Maybe I’m confused, but this issue seems like a duplicate of
https://bitbucket.org/openid/connect/issue/916, which we’d previously
discussed and decided not to fix. Am I correct or wrong that this is the
same issue?
Responding to Pedro’s point “2) The OP propagate this cleanup notification
to the downstream RPs, also via back-channel (a back-channel to
front-channel is not possible)” – is there a reason that RPs can’t learn
of the OP-initiated logout via the JavaScript session state changed
notification already in the spec? I realize that requiring JavaScript
might not be your preferred mechanism, but we’ve also tried not to have
multiple ways to do the same thing, unless there’s a good reason to do so.
I’m open-minded about this, but would like to hear what the arguments for
the additional mechanism are, and if they’re different than those
discussed with issue #916.
I’m also confused about the talk of structured access tokens. How do
structured access tokens relate to logout? And why would we consider
changing access tokens from being opaque to structured? Requiring
specific structure would break many OAuth and OpenID Connect
implementations.
I’m also confused why introspection is being discussed again. We deleted
the Check ID Endpoint, which did introspection on ID Tokens in May 2012 in
response to developer feedback about not wanting to have to support two
ways of doing the same thing. See
https://bitbucket.org/openid/connect/issue/570. Why is this being
discussed again, now that the specs are final?
I guess call me confused today…
-- Mike
From: openid-specs-ab-bounces at lists.openid.net [
mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of George
Fletcher
Sent: Thursday, March 13, 2014 8:19 AM
To: Pedro Felix; Justin Richer
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Session cleanup via back-channel
Hi Pedro,
Sorry for confusing the thread. I was responding to Nat's point about
structured headers. It's not really relevant to the issue you are
addressing. As for requirements for the back-channel call, you can add a
document on the wiki, or file a new issue on the site as an enhancement
for the working group to address and then put in the ticket all the
current requirements. Others can then comment on the ticket and the
working group can track it.
Note, that for this back-channel capability to be relevant to an RP, the
RP must support the concept of "server side" sessions (or maintain a
"black list" of revoked sessions). This doesn't tend to be capabilities
that most RPs support.
Thanks,
George
On 3/13/14 11:12 AM, Pedro Felix wrote:
1) Since I'm rather new in this group, what would be the best way to
continue this discussion? In this email thread? By trying to produce a
requirements doc on the wiki?
Most probably, I will be working on an implementation of this feature in
the near future.
2) Picking up on Justin's reply: an approach would be to also use the
"aud" and the "sub" to identify the session to cleanup. I don't like the
idea of requiring a round-trip to the introspection endpoint in order to
check the token purpose. Makes sense?
Thanks
Pedro
On Thu, Mar 13, 2014 at 2:12 PM, Justin Richer <jricher at mitre.org> wrote:
A number of our apps use this combined approach -- the server sends out a
signed JWT that the client can check the "iss" field and signature, then
(if it cares to do so) the client does introspection with the server at
"iss" to see if the token's still valid and what it's good for.
-- Justin
On 03/13/2014 09:48 AM, George Fletcher wrote:
On the "structured token" side of things I remember having a discussion
about this at IIW (a few back) and I thought someone and written something
up. It was needed in a number of cases that were using the token
introspection endpoint as a way to identifier the authorization server to
send the token to for introspection. I can't find my notes on the
conversation but maybe someone else remembers?
I think conceptually it was as simple as a non-signed JWT containing iss
and token fields. Obviously, the rest of JOSE could be applied for signed
or encrypted tokens.
Thanks,
George
On 3/12/14 9:02 PM, n-sakimura wrote:
Let's just write up requirements on the WG wiki (@bitbucket).
Once we agree on the requirements, it should be straight forward to turn
it into a spec.
On the side note, perhaps it is actually for OAuth WG, but it would be
nice to spec out the structured (access) token. it could be pseudo opaque
as well as long as you can find the authorization server from the token
but we at least need to be able to find out the iss.
Nat
(2014/03/13 3:58), John Bradley wrote:
We have discussed creating a backchannel push method for the IdP to notify
the RP.
So far noting is written up. I have a bad feeling that it might be me
that needs to create the first draft.
John B.
On Mar 12, 2014, at 3:54 PM, Pedro Felix <pmhsfelix at gmail.com> wrote:
Hi,
I've a scenario where a OIDC OP is acting as a bridge between upstream
IdPs using non-OIDC protocols (e.g Shibboleth) and downstream RPs using
OIDC.
In this scenario I have the following requirements
1) The upstream IdP notifies the OP of a session termination via
back-channel
2) The OP propagate this cleanup notification to the downstream RPs,
also via back-channel (a back-channel to front-channel is not possible)
Unfortunately, the OIDC session management spec does not provide any way
to perform this back-channel cleanup, however I remember reading some
meeting notes about this possibility.
Is there anything that can be shared? I would like to align our solution
with what is being developed by this working group.
Thanks
Pedro
_______________________________________________
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/20140313/8fc2b80a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 80944 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140313/8fc2b80a/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 79004 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140313/8fc2b80a/attachment-0001.png>
More information about the Openid-specs-ab
mailing list