| Kendra Wiki is thinking along similar lines. There's a thread on the decentralization mailing list following it. More thoughts:- Ignore the actual protocol for a moment. Site alpha.com validates with Site bravo.com. Site Alpha knows that UserID="foo" + Password="bar" + URL="bravo.com/sea/" = True. The remaining security question is the reputation or authenticity of the web service at bravo.com/sea/ This is the added value that centralized single sign-on systems claim to provide. I guess my argument is that there are very large numbers of situations where that last layer of authentication is not needed. So if it's not needed, stop trying to solve that problem and come up with the simplest solution that is "good enough" to answer the layer below. The real security question is whether the end user is comfortable giving ID+Password+URL to alpha.com. Arguably, alpha.com is building a database of these triples in the knowledge that they *might* be useful elsewhere.[2] In terms of protocol, I'm probably getting it wrong and ignoring prior art. I'm sure there are challenge-response approaches where the password never goes down the wire (SPA? APOP?). And if necessary the whole authentication transaction can be hidden with TLS[1]. In terms of UI, the user would need to provide ID;Password;URL;Protocol Where protocol is one of SEA, Drupal, Blogger, Delphi Forums, Manila, Yahoo, Jabber and LDAP[2]. And URL may be part of ID for some protocols. [1]Such a shame that there's a commercial lock on TLS certificates. [2]Several of these take advantage of an existing API that includes password. I suspect that a bit of screen scraping and cURL could extend this to Passport, AOL, and quite a few others. Clearly, ID+Password+Passport is worth quite a bit more than ID+Password+Manila but also has much more potential for abuse. Jeffrey Kay wrote: >The basic idea behind authentication are that you have to trust the >authenticating authority. If you can't then the system fails. Back in the real world, there's a reductio ad absurdam problem with this. Most "Authorities" (eg Passport) are only really warranting that this ID is associated with an email address which appeared to once have a human reading it. Even eCommerce SSL certificates only really warrant that a domain had a fax number associated with it at one time. So let's try a use-case. I got it into my head that the Deanspace software could be used by the Liberal-Democrats in the UK. While doing the research, I signed up at geeks4dean.com and told them to validate against jbond:drupal.login:voidstar.co m/xmlrpc.php. When the password I gave them validated, they picked up my foaf file and thumbnail and auto-created a profile for me. There's an audit trail and if necessary someone could look at voidstar.com and find content going back a few years. They could check the pgp signature on the foaf file. The domain has some history. Email addresses that include @voidstar.com appear all over the web. There's a CV up there. So clearly voidstar.com is a pretty good authenticating authority for jbond. Now I go to expats4dean.co.uk and tell it to validate on jbond:drupal.login:geeks4dean.com/xmlrpc.php They create their own profile based on the one at geeks4dean.com which originally came from voidstar.com. When I start posting extreme libertarian anarcho-capitalist tracts on expats4dean.co.uk and they decide to ban me, they can post all over their site, geeks4dean.com, this mailing list, bloggercon and anywhere else they choose that the entity that calls itself jbond and lives at voidstar.com is not to be trusted. ISTM that this has proved at least as effective as the big centralized authenticating authorities. And we didn't have to involve them at all. I feel sure that I'm re-inventing wheels here. And I've no doubt that I'm glossing over deep problems. But I refuse to accept that this problem needs either some BigCo in the middle, or incredibly complicated web services that are all spec and no implementation. |
[ << Simple External Authentication or Single Sign-on for the rest of us ] [ VoIP testing >> ]
[ 25-Sep-03 10:15am ]
