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

[George Fletcher]

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
>>
>
>

-- 
George Fletcher <http://connect.me/gffletch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140313/2b5e03da/attachment.html>
-------------- 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/2b5e03da/attachment.png>