Re: [security-services] Protocol extension for role change

[Rainer Hoerbe <rainer@hoerbe.at>]

> Am 09.11.2016 um 02:13 schrieb Cantor, Scott <cantor.2@osu.edu>:
> 
>> BTW, this use case is actually implemented this way in our legacy SSO system.
> 
> If it uses a shared cookie, I can see how. If not, I don't. SLO isn't practical now, if it ever was, so given your requirements, I don't know how to meet them practically.

The legacy protocol has IDPs working as reverse proxies, so it is easy to implement

> 
> It's not really so much whether this is specifiable, obviously it is, it's just not implementable.

I fail to see the show stopper. IFIAK the main problem areas with front channel SLO are UX (the user understanding the scope of federated apps), logout status reporting and unreachable SPs (unless using iFrames/Javascript), and application session handling. These do not apply in this use case. What am I missing?

> 
> I would probably argue for some other approach involving some kind of polling for the role. Perhaps the software could detect a lag in activity and when the user comes back "re-certify" the status using an API. Seems like a good OAuth use case.

That could turn out to be a protocol change for scores of applications.

- Rainer