Subject: Distributed comment/post authorisation proposal

From: "Angus Turnbull" <[email-masked]>
Date: Wed, 18 Aug 2004 14:23:02 +1200

Greetings all,

Since this email is rather lengthy, I'll begin with a brief synopsis. I think the ATOM API is a good place to implement an idea I've been considering for a while: distributed blog comment/post authorisation.

Basically, all existing post authorisation API schemes assume that a poster has an account with a username and password on the server hosting the blog. However, it would be possible to add functionality to host an authorisation server as a CGI script on your own domain (or a provider of your choice) that would allow you to post comments/articles on other blogs, authenticated as yourself, without giving personal information to the blog owner. Think of Microsoft Passport done via an open-standard API for blogging.

If this is (a) interesting, (b) possible and (c) novel, I've outlined my ideas below. Also, thanks to Anne van Kesteren for taking an initial glance at it and suggesting that it be posted here!

Regards,

Angus Turnbull
http://www.twinhelix.com

--------

Currently, a page that accepts user content has a <LINK> tag in the header for autodiscovery of Atom services. As such, it should be simple to implement an authorisation scheme like this involving two fictional users:

1) Andy visits Bob's blog at www.bob.com, and intends to leave a comment. Andy does not have an account on Bob's blog, nor does he wish to sign up for an account on Bob's server, as he does not trust Bob with his password(s). However, Andy dislikes people impersonating him online, and wishes to use some kind of authentication mechanism so Bob's readers know it's Andy that is posting.

2) Andy has a CGI script installed on his server (or a trusted hosting provider) implementing this authentication system. He loads the script in his browser, configures it with a password, and drags a bookmarklet like this onto his browser toolbar:

javascript:window.open('http://www.andy.com/atom-auth.cgi?page='+location.href);void(0);

3) Andy visits Bob's blog to leave a comment, and clicks the bookmarklet. Non-JavaScript capable useragents would have to manually open up the correct CGI script via their bookmarks, and cut/paste Bob's blog URI into a form field there. (Ideas for better accessibility are welcome; perhaps a feature of the post-comment fields on the target blog...?)

4) Andy's server either remembers him via a cookie, or he logs in normally, or by some other form of authorisation.

5) Andy fills in his comment and hits "Post" on his own server.

(Alternatively, steps 3-5 could be performed by Andy's Atom client software submitting his post to his own server using the existing Atom API authorisation scheme, but with the eventual destination URI specified as Bob's blog. That would be a simple implementation issue; the client would generate a "reply to this post" button/link after compliant posts it had syndicated).

6) The interesting part begins. Andy's webserver acts as an Atom client and contacts Bob's Atom server, submitting an HTTP POST similar to an existing Atom authentication request, containing its own URI alongside the standard <author>, <content> and nonce+date, but no hash. Andy's server retains this information.

7) Bob's server receives an incoming request from an unknown IP address. It retrieves and stores the post data, and closes the HTTP connection.

8) Bob's server opens a new HTTP connection to the URI contained in the POST, which is the CGI script on Andy's server. It calculates a hash consisting of: SHA1(nonce+date+comment content), and posts the hash and Andy's <author> details back to the Andy's server using a defined Atom API. Note that "comment content" would be specified as having all newlines as "\n" characters, to ensure hash consistency.

9) Andy's server receives an incoming request, and checks that the supplied hash matches its own record of Andy's user details and nonce+date+comment. It returns a success/failure code to Bob's server using a defined format. This is to foil man-in-the-middle attacks.

10) Bob's weblog, assuming step 9 returned successfully, displays Andy's post and username, and the authentication URL used (http://www.andy.com/atom-auth.cgi), so visitors know it's really Andy that has commented.

This could probably be simplified or corrected a little, and perhaps more run of it over the existing Atom API, but the extensions required would be pretty trivial. The advantages of this system:

* Anyone could set up an authorisation server of their own, never have to sign up at hundreds of different weblog service providers, and yet be reliably authenticated as themselves.
* Bob cannot use Andy's account details to post as Andy on other weblogs, something that is possible under the current "create-an-account everywhere" paradigm with a less-than-honest webmaster and poster who duplicates passwords.
* It would be easy for anyone to start up a trusted authorisation service and give away accounts, with easy setup procedures, so this could catch on with non-technical users who don't really know what a CGI script or Atom client is.
* You could extend a remote authorisation mechanism with all sorts of cool syndication-based hacks.

Disadvantages:

* Six Apart and Blogger already have their own authentication systems and are unlikely to want to give up their sweet proprietary lock-in goodness, but it's not a perfect world.
* It would be vulnerable to people signing up for similar-looking domains like www.4ndy.com and setting up authentication servers on them; I can't think of a workaround there.
* Untrustworthy sites could simply post "You all suck, this comment is by So-and-so and authorised at his/her correct URL". There's nothing really to stop that either, unless Andy's CGI software retains and publishes a list of sites to which he's contributed; that's just an implementation issue.

If you've read this far, what do you think? Is it workable and/or desirable? Should we work on nailing together some kind of proposal for the ATOM Wiki? I don't mind if anyone takes this idea and runs with it, by the way.

Cheers - Angus.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 18 Aug 2004 23:17:01 +0200

On Wed, 18 Aug 2004 14:23:02 +1200, Angus Turnbull <[email-masked]>  
wrote:

> However, it would be possible to add functionality to host an
> authorisation server as a CGI script on your own domain (or a provider  
> of your choice) that would allow you to post comments/articles on other  
> blogs, authenticated as yourself, without giving personal information to  
> the blog owner. Think of Microsoft Passport done via an open-standard  
> API for blogging.

I would assume that the Liberty Alliance Project[1] is what you want. What  
I want too, for that matter.

It is a great idea that opens up for a much more (user-) friendly web. It  
also makes it a lot simpler to know who you can trust, since it creates so  
called «trusted networks» or «circles of trust» within a group of people  
that trusts each other.

Let's say that you trust Mark Pilgrim, and thus have his public key in  
your whitelist. Sam Ruby also trusts Mark Pilgrim, so he's in his  
whitelist as well. If Tim Bray trusts Sam and you, but have never heard of  
Mark, Mark would still have high credibility since two of Tim's trusted  
friends trust him.

However, if I, who aren't trusted by anyone, tries to write to Tim's blog,  
my posts will be appended to a queue, since Tim has no idea about my  
credibility. Whenever I prove myself worthy of his trust, my comments will  
go directly out to the blog.

I've thought about this idea for quite a while, and I think Atom is the  
perfect technology to test such a technology out with.

____
[1] <url: http://www.projectliberty.org/>

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: "Angus Turnbull" <[email-masked]>
Date: Thu, 19 Aug 2004 13:35:05 +1200

Asbjørn Ulsberg wrote:
> I would assume that the Liberty Alliance Project[1] is what you want.
> What I want too, for that matter.
>
> It is a great idea that opens up for a much more (user-) friendly
> web. It also makes it a lot simpler to know who you can trust, since
> it creates so called «trusted networks» or «circles of trust» within
> a group of people that trusts each other.
> 
> whitelist as well. If Tim Bray trusts Sam and you, but have never
> heard of Mark, Mark would still have high credibility since two of
> Tim's trusted friends trust him.
> 
> However, if I, who aren't trusted by anyone, tries to write to Tim's
> blog, my posts will be appended to a queue, since Tim has no idea
> about my credibility. Whenever I prove myself worthy of his trust, my
> comments will go directly out to the blog.
> 
> I've thought about this idea for quite a while, and I think Atom is
> the perfect technology to test such a technology out with.
> 
> ____

Indeed, I'm aware of the Liberty Alliance. This is a simpler protocol
change native to the ATOM API that doesn't rely on a distributed network
of trust, something I feel would be really, really contentious to
implement given the existing RDF vs. XML Schema flamewars on this list!

It seems my initial post has virtually sunk without a trace. Is it
considered unworkable? Personally, I think it could be a "killer app" of
ATOM syndication, as to be honest, end-users don't really notice or care
whether their aggregator is using RSS 0.9x, 1.0, 2.0, ATOM or whatever,
just as long as it works. Basically, being able to post an authenticated
comment from within your aggregator of choice on any compliant blog would
be a really distinguishing feature.

Putting in some smart server-to-server authorisation protocols could well
lead to a distributed trust/FOAF type network regardless, as a natural
evolution of the protocol.

Anyway, I'm out of here for now. I just wanted to float the idea and see
what happened. Hopefully one or other kind of distributed authorisation
eventually makes it into the ATOM proposal. Good luck if you do want to
push a FOAF approach!

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 25 Aug 2004 22:10:50 +0200

On Thu, 19 Aug 2004 13:35:05 +1200, Angus Turnbull <[email-masked]>  
wrote:

> Indeed, I'm aware of the Liberty Alliance.

Okay.

> This [...] is a simpler protocol change native to the ATOM API that
> doesn't rely on a distributed network of trust, something I feel would
> be really, really contentious to implement given the existing RDF vs.
> XML Schema flamewars on this list!

Then I'm not sure if I've understood your proposal fully. My thoughts on  
using the Liberty Alliance's work, is that we don't have to re-invent the  
wheel. Everything's already there, and being deployed in large  
corporations like AOL.

Having exactly one, and no more, authentication mechanism for all web  
based services, would make everything much easier for users. The Liberty  
Alliance Project might be that mechanism. Your proposal, afaik, can't.

> considered unworkable?

I'm not sure everyone understands it well enough. Write more about it. Use  
the wiki if you will.

> Personally, I think it could be a "killer app" of ATOM syndication, as
> to be honest, end-users don't really notice or care whether their
> aggregator is using RSS 0.9x, 1.0, 2.0, ATOM or whatever, just as long as
> it works.

True. They don't care what authentication mechanism is used either, as  
long as it works. And as LAP is existing, working and being used, it's a  
good chance they'll some day have an LPA identity they can use to  
authenticate on a blog.

> Basically, being able to post an authenticated comment from within your
> aggregator of choice on any compliant blog would be a really
> distinguishing feature.

Indeed.

> evolution of the protocol.

LAP does this already. Why re-invent?

> eventually makes it into the ATOM proposal.

It will probably be an extension nonetheless, so it's no rush to get it  
into the 1.0 release of the protocol. But it would be interesting to start  
looking at the different possibilities that are out there, and I think LAP  
solves a lot of problems if it's just implemented in enough applications.

> Good luck if you do want to push a FOAF approach!

I know too little about FOAF to do that, sorry.