[foaf-dev] Re: privacy and open data

[Julian Bond]

Story Henry <henry.story at bblfish.net> Wed, 26 Mar 2008 12:36:10
> - A client such as the Beatnik Address Book is not a web client. It is 
>a Semantic Web client. So the User Agent is a consumer of data, not of 
>human readable content. oAuth seems to be designed for reading human 
>consumable web pages. The human reading the site has a few things to 
>read, then gets redirected, then enters his password in his old site, 
>then gets redirected again. As a result his pictures that belonged to 
>one site now appear in another web site, ...
> - I have a feeling that the oAuth protocol is a pairwise protocol.  It 
>seems that every site has to get into a contract with every other  web 
>site they want to do business with for this to work. I don't see  this 
>scaling as it is. Perhaps with semantic help it could.

The use cases for oAuth were principally for mashups. So if I wanted to 
build a system that made use of Twitter data (MyTweet), at the moment 
I'd have to get the user to give me their Twitter Id and Password. Using 
oAuth the user would arrive at MyTweet, I'd redirect the user to Twitter 
where a screen would say "Do you want to allow MyTweet access", It would 
redirect back with a key. From then onwards, MyTweet can use that key to 
access the Twitter API. Most every API that requires authentication and 
uses a bit more than just HTTP AUTH is similar. eg AuthSub, BBAuth, 
Facebook.

So, yes, the initial handshake and key generation involve a web 
redirect. But after that the systems are talking API to API using the 
key and without browser interaction. It doesn't say anything about the 
nature of the APIs or even that they are web APIs. So there's no reason 
why it shouldn't be used where the API is nothing more than a GET to a 
FOAF URL.

I believe the oAuth people are trying to come up with a scheme that 
doesn't involve browsers for the initial handshake and authentication 
but I don't know how far they've got. There's also a move afoot to 
combine oAuth and OpenID. Because at some stage you have to have logged 
into the supplying server and OpenID is of course a good way to do that.

Yes it's pairwise. A User has to confirm that site B can get access to 
Site A. And then do it again for C->A. And if a similar service is run 
at Z, they'll have to confirm B->Z and C->Z Just as with OpenID, there's 
no federation baked in.

-- 
Julian Bond  E&MSN: julian_bond at voidstar.com  M: +44 (0)77 5907 2173
Webmaster:          http://www.ecademy.com/      T: +44 (0)192 0412 433
Personal WebLog:    http://www.voidstar.com/     skype:julian.bond?chat
                       Coupons Cannot Be Combined