[Openid-specs-ab] Session cleanup via back-channel
George Fletcher
gffletch at aol.com
Thu Mar 13 15:19:23 UTC 2014
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140313/6000b62d/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/6000b62d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XeC
Type: image/png
Size: 79004 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140313/6000b62d/attachment-0001.png>
More information about the Openid-specs-ab
mailing list