Re: ACTION-11 SSO & Federated Identity

Thomas Roessler wrote:
> This is a pretty typical pattern for the "big" content providers --
> e.g., Yahoo and Google both do it.
>
> Basically, authentication state is mapped into a cookie with a
> limited lifetime, which can then be verified easily.  When the user
> tries to do actions deemed "dangerous", then they are asked to
> re-authenticate, and get a new cookie, or are moved into a constant
> TLS mode.
>
> One of the perceived benefits of this approach is that the servers
> that provide the individual services can operate on a lower trust
> level -- after all, they neither know the service's TLS certificate,
> nor do they touch "real" client credentials.
>   
I agree, but I think this motivation is flawed. The sites could use a 
cookie (as they do) but pass it to the less-trusted services over an 
SSL/TLS connection (so it'll also be an SSL/TLS-protected cookie). Of 
course the less-trusted service can have a different domain and 
certificate (public / private key pair).

Of course, this still requires the less-trusted site to run SSL/TLS, and 
many site designers are concerned about the performance implications 
(although I also don't quite agree here, esp. using TLS tickets...)

Best, Amir Herzberg.
> Cheers,
>