Just recording the discussion on Sept. 3 that lead to this item.
Nat reported some parties may use SAML because OpenID Connect doesn't have a ratified logout spec
He also said that some enterprise people are inventing home-grown logout spec
Shipping is a feature as well
We still need interop testing on the HTTP-based logout
The back channel logout spec doesn't yet exist
Nat said that some people apparently are using extensions to SCIM for back channel logout
He will try to find references to what those people are doing
Mike expressed that requiring SCIM to do logout seems like unnecessary complexity
For the back channel logout, the OP would send a message to the RP containing the session ID
There could be an ID Token authenticating the sender
Some will want to log out a particular session - others will want to log out all sessions
Back channel logout could be broadly construed - for instance terminating refresh tokens
Nat raised the point about sometimes-connect clients
Nat said that some parties are interested in receiving logout acknowledgements
John said that having some concrete use cases might help
Brian stated that expectations for logout appear to differ dramatically
In theory, PingFederate supports back-channel logout for SAML
But ~90% of integrations don't include the necessary RP support for this
Mobile apps make things even harder
What is the desired behavior for a mobile app?
We can probably say something meaningful for interactive sessions
Mobile applications require the back-channel logout
Things that could be logged out/revoked include:
immediate access and refresh tokens
cascaded token revocations
native app logins
There could be some kind of an ack back to the server for destroyed objects
Callbacks? This could be a scalability issue.
Callbacks probably should be its own spec, if we ever do it
Brian - implementing SAML logout is really hard and all the options only make it harder!