Should Front-/Backchannel logout flows be tied to a specific session?

[Stein Welberg]

There are a few (security related) scenarios in which the global logout scenario is the preferred one IMO:
- Password change
- OP forcing global logout due to a potential security threat.

Under normal circumstances I do indeed agree with Filip that just clearing the RP sessions that you visited within the particular context (browser) is the expected behaviour.

Cheers,
Stein

> On 19 Dec 2019, at 12:05, Filip Skokan <panva.ip at gmail.com> wrote:
> 
> Personally I don’t believe removing all end user RP sessions is the expected behaviour. For one, front channel logout notification is not likely to do much. 
> 
> I can only see a handful of scenarios where me logging out of a website at work should log me out of all RPs on my phone and home office. 
> 
> Maybe allow your library developers to choose the behaviour they want but the default expected one from my POV is only clearing RP sessions i visited in the session i’m at. 
> 
> Odesláno z iPhonu
> 
>> 19. 12. 2019 v 11:57, Aeneas Rekkas <aeneas at ory.sh>:
>> 
>> Hi Filip,
>> 
>> thank you for the fast response and guidance! I saw that section but I understood it as: We need to keep track of the active RPs session (regardless of the user agent/specific session) to contact them all. Maybe this could be refined with an addition such as:
>> 
>> OPs SHOULD (or MAY) only contact the RPs associated with the user session that is being logged out.
>> 
>> Thank you for clarifying that both options are viable (although one may not scale very well). Are there any other implications this could have?
>> 
>> Best
>> Aeneas
>> 
>>> Am 19.12.2019 um 11:48 schrieb Filip Skokan <panva.ip at gmail.com <mailto:panva.ip at gmail.com>>:
>>> 
>>> Hi Aeneas,
>>> 
>>> The specifications say the OP should keep track of the “visited sites” / RPs so that, when logout notifications go out it knows which ones to contact. 
>>> 
>>> > OPs supporting HTTP-based logout need to keep track of the set of logged-in RPs so that they know what RPs to contact at their logout URIs to cause them to log out. Some OPs track this state using a "visited sites" cookie.
>>> 
>>> But I don’t believe it also forbids contacting all of them, though i believe that doesn’t scale well. 
>>> 
>>> Best,
>>> Filip
>>> 
>>> Odesláno z iPhonu
>>> 
>>>> 19. 12. 2019 v 11:27, Aeneas Rekkas <aeneas at ory.sh <mailto:aeneas at ory.sh>>:
>>>> 
>>>> Hi,
>>>> 
>>>> first of all I hope I ended up in the right list, if not, I’m happy to restate the question in the appropriate one!
>>>> 
>>>> My question is regarding the OpenID Connect Back- and Front-Channel logout (1.0) draft 4 / draft 2. We are currently executing these for all RPs, regardless of the specific device / session of the user. Example: Assuming the user has two distinct, active sessions on two separate end devices, RPs would be notified regardless of the device that was used to perform the OIDC flow in the first place, and that is now used by the user to requesting the logout.
>>>> 
>>>> However, one of our community members asked if that is correct, as he would expect only those RPs to receive the logout request that have their ID Token associated with the specific device session, not globally.
>>>> 
>>>> The spec doesn’t - as far as I can tell - give a clear answer to that. Seeing that RPs may support the `sid` parameter, it could mean that this is up to the RP to decide, not the OP.
>>>> 
>>>> It would be great to get clarification on this topic, and maybe provide concrete guidelines in the official spec!
>>>> 
>>>> I am writing on behalf of the open source, OpenID Certified OpenID Connect Provider ORY Hydra ( https://github.com/ory/hydra <https://github.com/ory/hydra> ).
>>>> 
>>>> Thank you for your time,
>>>> Aeneas
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs at lists.openid.net <mailto:specs at lists.openid.net>
>>>> http://lists.openid.net/mailman/listinfo/openid-specs <http://lists.openid.net/mailman/listinfo/openid-specs>
>> 
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20191231/054e1d81/attachment.html>