Jeff says that instead of us using HTTPS for everything, he'd "rather see a better, more secure identity protocol than ye olde HTTP cookies".
The thing is.. it already exists and has done since 1997 , see:
http://en.wikipedia.org/wiki/Digest_access_authentication
There is a more fundamental reason to hate cookies and avoid using them in your application:
Cookies are crap because they are used to create shared state over a protocol that is deliberately stateless, and session hijacking is just one example of the problems that causes.
They were a hack designed to overcome the historical limitations of browsers as a client; browsers sucked at managing and presenting their client-side state to users, so cookies were created as a way to offload that responsibility to the server which would maintain the shared state and render that should-be-client-side state into the web pages. This approach to application design is not scalable and is horribly inefficient. You can't cache pages that vary by the client accessing them. This led to applications requiring things like ESI just to stay performant (I'm looking at you, Magento).
Fortunately, with 'HTML5 & co.' browsers are now developing more sophisticated features which are eliminating the need for shared state altogether.
Back to the point then, I suppose.. Auth is, as far as I can tell, relatively well covered by HTTP Digest but for three things:
- No control over the login box gives designers a heart attack
- There's no way to logout other than closing the browser (which people don't do all that much anymore)
- A feasible subset of Digest features should be identified to keep things simple and help interop
Hopefully that will lead to "a better online identity solution than creaky old HTTP cookies" and, in the process, help us to move away from cookies entirely.
p.s: WebID looks interesting, too.
