[Openid-specs-ab] backchannel logout: events

[Phil Hunt]

I agree, the spec needs some more work. In part because it started around the same time we started talking about events and agreed to come to a common format.

What the Logout Event should be saying is the OP has cancelled a session etc.  You’ll note that the OP does not know what the Client’s session is. The client, attempts to map the information in the Logout Event (e.g. map the OP’s session and subject to a local session and subject) and can then decide, based on local policy, on appropriate local action (e.g. cancel the local session).

The event format means the Client is free to map the command based on its policy. For example, some scenarios may not require or desire a single-sign-out.  BUT, it may be useful to know that the OP has logged the user out as future UX interactions may be affected.

Other missing functionality. I would like to see Logout events be initiated from the Client.  There are scenarios where it is useful for the OP to know a user has been logged out of a specific audience which might be part of a larger SSO domain.  Policy can dictate whether localized logout is allowed vs domain with logout — which then OP could then choose to relay by issuing its own Logout event to all the other ID tokens and audience web sites associated with the user.

Phil

Oracle Corporation, Identity Cloud Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>











> On Mar 16, 2017, at 4:48 AM, Axel Nennker via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> Hi,
>  
> Regarding https://openid.net/specs/openid-connect-backchannel-1_0.html <https://openid.net/specs/openid-connect-backchannel-1_0.html>
>  
> I am wondering what the reason behind events is:
> events
> REQUIRED. Claim whose value is a JSON object containing the member namehttp://schemas.openid.net/event/backchannel-logout <http://schemas.openid.net/event/backchannel-logout>. This declares that the JWT is a Logout Token. The corresponding member value MUST be a JSON object and SHOULD be the empty JSON object {}.
>  
> The reason, I think, to have “events” is to make the logout JWT compatible to SET: https://tools.ietf.org/html/draft-ietf-secevent-token-01 <https://tools.ietf.org/html/draft-ietf-secevent-token-01>
> But SET states: “Security Events are not commands issued between parties”
> While openid-connect-backchannel-1_0.html JWT is a command.
>  
> If we want SET compatibility wouldn’t it make more sense to have a SET compatible response to the logout command?
>  
> Why is SET compatibility important? Is it important enough to justify this really strange type specifier?
> "events": {
>      "http://schemas.openid.net/event/backchannel-logout <http://schemas.openid.net/event/backchannel-logout>": {}
>      }
>  
> Kind regards
> Axel
>  
>  
>  
>  
>  
>  
>  
> DEUTSCHE TELEKOM AG
> T-Labs (Research & Innovation)
> Dipl.-Inform. Axel Nennker
> Winterfeldtstr. 21, 10781 Berlin
> +491702275312 (Mobile)
> E-Mail: axel.nennker at telekom.de <mailto:axel.nennker at telekom.de>
>  
> _______________________________________________
> 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 <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/20170316/629158e3/attachment.html>