Re: [decentralization] Movable type V3 and Authentication
- Wes Felter <wesley@...> wrote:
>Sure, everything should be decentralized. :-) But the usability isThere's some middle ground here with federated single signon. If there
>better with a centralized service, because all you have to do is click
>on a link. In a decentralized version you'd have to tell each site
>where your server is at.
were competing authentication services using a common standard, then you
could just choose from a drop down list of services that the current
website knew about and accepted.
The next layer down would be most easily solved by having the remote
service and service type as part of the ID. eg
"Jabber:julian_bond@...". That's not much harder than julian_bond
and assuming Typekey.com
I'm not really sure that a 3 field form for signin is that hard either.
ID, password, signin endpoint URL would be easy to use, especially if
the browser remembered the values for you. These second and third
options shift the burden of proof towards post-audit from ante-trust but
I don't think that's any bad thing except in commercial transactions
where there's money involved.
The piece missing in all this is a simple, easy to use protocol for
sites to participate as either as a service provider or identity
provider or both. The Liberty/PingId project is probably the closest we
have to a standard but I still find it excessively complicated to
implement. I just can't see the typical LAMP based site making it
happen. There is a Java and Dotnet implementation but it's not friendly
to enthusiasts as opposed to funded professionals. (I hate the terms but
I think you get the difference).
The Drupal system is a good starting point but nobody pretends that it's
even remotely secure. That's not actually a problem in the real world
and it works fine where security is not the issue.
The other related problem is populating the local user record and
avoiding retyping the same 30 fields on every new site you sign up to.
There's some work being done on trying to use your FOAF file for this.
At the moment there's not a very good match between FOAF and the sort of
data required. Another place where some standardization could really
There's an opportunity here for SixApart to create some de-facto open
standards for all this. I just don't expect them to do it. No blame;
Julian Bond Email&MSM: julian.bond at voidstar.com
Personal WebLog: http://www.voidstar.com/
M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433