[Openid-specs-ab] Session cleanup via back-channel

[Pedro Felix]

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><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
>
>
>
>
> --
> [image: George Fletcher] <http://connect.me/gffletch>
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://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/f3814a27/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/f3814a27/attachment.png>