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 <[email protected]> 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 <[email protected]>: >> >> 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 <[email protected] >>> <mailto:[email protected]>>: >>> >>> 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 <[email protected] <mailto:[email protected]>>: >>>> >>>> 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 >>>> [email protected] <mailto:[email protected]> >>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>> <http://lists.openid.net/mailman/listinfo/openid-specs> >> > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
