[Openid-specs-ab] Session cleanup via back-channel
George Fletcher
gffletch at aol.com
Thu Mar 13 20:08:53 UTC 2014
Hi Mike,
Sorry for causing the confusion. In Nat's email he addressed two
different (and unrelated topics).
1. Requirements for the IdP-to-RP session logout notification
2. Need for some guidance around structured tokens
These are two orthogonal topics. I addressed the second item in this
thread (rather than starting a new one) and that I think is what caused
the confusion.
Thanks,
George
On 3/13/14 2:46 PM, Mike Jones wrote:
>
> 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
> <mailto: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> <mailto: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
> <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
>
> --
> George Fletcher <http://connect.me/gffletch>
>
>
>
> _______________________________________________
>
> 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
>
> --
> George Fletcher <http://connect.me/gffletch>
>
--
George Fletcher <http://connect.me/gffletch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140313/fda28fd8/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/fda28fd8/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/fda28fd8/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XeC
Type: image/png
Size: 80944 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140313/fda28fd8/attachment-0002.png>
More information about the Openid-specs-ab
mailing list