A post on the AD++ blog mentions a new web authentication project called SORUA (Simple Online Remote User Authentication). It's a variation on the auth by url approach, with a username returned during the server to server challenge verification.
xxx (remove) Identity systems are multiplying. Some are web-based (TypeKey) and some are system-oriented (Kerberos).
Various identity systems
Still haven't seen one site that uses Liberty
This shows how big of a problem authentication still is. Search for a solution, but only variants of each other, re-using the same concepts.
Challenge: writing an "sso code" (in the spirit of geek code), that would encode the characteristics of an SSO as a short code string: id=URL,(scenario=browser,authentication=(method=redir+check_sign(nonce),challenge=nonce,response=sign(nonce)))
Too many systems
As more identity solutions appear each one loses some value. Here are some reasons why:
Idea: what is more secure? 3 services, using 3 passwords (chances they are the same). 3 services using 1 password. Or 3 services using 2 password (account + payment).
The main risk with SSO is that the one cred or the one auth system gets compromised. Same problem as compromising a principal on a local system. The solution is to create security boundaries, that make sense and that protect various authorities a user may hold. Similar to capability-based security approach.
VISA is doing something like this, where VISA also has a password that you need to use before the online transaction goes through.
There is an approach that I found missing in most of these solutions, that would combine convenience and security, by grouping the scenarios into "clearance" levels.
What we need is a few solutions that fit the various scenarios well. Here's the online scenarios that I could think of: browsing, blog commenting, shopping, email and publishing, online service management (phone, ISP, ...), buying and banking.
If we clustered these by requirements (convenience vs. security), we could minimize the number of identity solutions and sort them by security level. The most convenient and relatively less secure one could be used for browsing and blog commenting, while the most painful and secure one would be reserved for buying and banking.
We would separate and isolate the various "clearance" levels (as in the military). This is what many users already try to do, in a way, by having one simple password for many low security sites, and more secure password for more important sites.
But some of these scenarios can be combined in a single activity or website: for example when you both shop (fill your shopping cart) and buy at Amazon. But most of the time (when you just shop) you don't actually need the authority to use your credit card stored in your account.
This also relates to the bad design of credit card security.
The solution that most sites apply is they force the user to enter their password interactively (within a short time window) to enter the more "secure" part of the site. But that really doesn't help if your password was stolen (say from another website where you used the same password...).
Here's the corrected Amazon scenario:
Amazon should not have your credit card information; you would browse and add stuff to your shopping cart using a "low" security account. But when the time comes to check-out, you would be sent to your bank to issue a one-time token for Amazon to complete the transaction. Your bank would first check your "low" security credentials (should be silent, since you're already logged in) and would then ask you to use your more secure credentials (maybe a smartcard or other PKI) before letting you do the operation.
The "level-1" security is not too high (maybe a simple password with a persistent cookie) and is exposed to many sites.
The "level-2" credentials act as an extra layer of security, and they only get exposed to a limited number of websites (like your bank).
This helps mitigate the common problems with SSO
Orthogonal of many implementation choices: webSSO, client-side certs,...
Resetting a low security password may be done using an email, but higher ones possibly could require you to go to your bank. (Schneier on password resets: http://www.computerworld.com/securitytopics/security/story/0,,99628,00.html )
The question is how many layers of security are needed. I think 3 or 4 would be a reasonable trade-off.
Federation (who controls the credentials?)
Multiple accounts
Interop/migration
Cross-site anonymity (no shared/global ID)
Profile sharing/consent
Marketing http://www.glenbrook.com/opinions/shared-authentication.html
Payment Views :: Verified by Visa is in big trouble if techies like Wes Felter don't get it
http://www.paymentviews.com/blog/_archives/2004/11/9/178115.html
Links:
Martin's thoughts on identity.
Gleenbrock on Federation and liability
http://www.glenbrook.com/opinions/federated-liability.html
The 100 Hour Board Tackles Single Sign-On
http://www.windley.com/2004/10/05.html#a1450
O'Reilly is going to publish a book on digital identity
E-commerce Single Sign-On Not Dead Yet
http://slashdot.org/article.pl?sid=04/11/30/042202
Single-Sign on Insanity
http://www.oreillynet.com/pub/wlg/5998
Doc Searls on Identity and namespace fragementation
http://www.linuxjournal.com/article/7888
via Udell http://weblog.infoworld.com/udell/2004/12/07.html#a1128
Why yet another sso?
http://www.bingme.com/2005/02/simple-online-remote-user.html
Same problem with segmented IM systems and fragmented/concurrent tag systems