- From: Amir Herzberg <herzbea@macs.biu.ac.il>
- Date: Wed, 06 Dec 2006 17:17:11 +0200
- To: "Michael(tm) Smith" <mikes@opera.com>, public-wsc-wg@w3.org
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, >
Received on Wednesday, 6 December 2006 15:17:56 UTC