Possibility to revoke sessions when using client storage

[Cantor, Scott]

> Rolling all the keys & killing 40,000+ user's SSO sessions because 1 user got
> phished and the phisher is aware of the long SSO window is very much using
> a nuke to kill a mosquito.

I don't agree that it really has any substantial impact on users, but as long as people who are supporting the project want the feature, it doesn't matter that much what I think about it.
 
> We'd be looking for something that supported nuking the client session and
> not requiring a stateful connection back to the datastore.  Even if it's a simple
> (poll this https://something/nuke.txt file every 5 min) would be good
> enough.

Having the shared datastore in the first place is the issue. We don't believe in adding more persistent data management interfaces to the system and I won't hack up solutions to point problems, it has to fit into the design. That means the StorageService API to get the data. It could mean a StorageService implementation that's read-only and backed by a simple web service call, but by doing it that way, it doesn't preclude people using the existing back-ends and it allows, in those writeable cases, a mgmt interface in the IdP to actually do what this *is*, which is administrative logout.

-- Scott