[Openid-specs-ab] Unifying the Front-Channel and Back-Channel Logout Session ID semantics

[Filip]

While implementing Session Management, Back and Front channel logouts i
find myself struggling to find concrete details on the "sid" claim in
general.

Questions i find myself asking

   - if the client's subject_type is public, is it okay to just send my
   internal OP session id?
   - if the client's subject_type is public can i send the same sid to
   every client, afterall the sub claim will be the same for all these clients
   so where's the point in different sid claims
   - if the client's subject_type is pairwise i suppose i SHOULD calculate
   the sid values unique for each client, else instead of matching users by
   sub clients can do so by sid.

My current proposed implementation is to return the same OP session ID as
sid to all public clients and use the same mechanisms for calculating sid
for pairwise client claims as i do for sub.

Kind Regards,
*Filip Skokan*

One of the things blocking us from taking the Front-Channel and
Back-Channel logout specs to Implementer's Draft status is that they
currently use the Session ID ("sid" claim) differently.  The
Front-Channel spec expects "sid" to be globally unique.  The
Back-Channel spec only expects it to be unique in the context of an
IdP - just like "sub" is.
>
> In talking with John and Nat and William at IETF 95, we discussed the possibility of unifying the definitions by changing the Front-Channel usage to match the Back-Channel usage.  In the case when logging out only one session at an RP using the front-channel spec, this would necessitate adding an additional "iss" (issuer) parameter to the logout request, so that it would become:
>               logout_uri?iss=issuer&sid=session
> In the simple case, one could still use only:
>               logout_uri
> without any parameters if it is OK to log out all sessions at the RP.
>
> Are people OK with this change?  It could provide us a way forward to bring both the Front-Channel and Back-Channel specifications to Implementer's Draft status.
>
>                                                           -- Mike
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160804/a5024aa4/attachment.html>