Re: [foaf-dev] Re: privacy and open data

On 26 Mar 2008, at 13:11, Alan Ruttenberg wrote:
> The Handle system has a specification for encryption. My feeling is  
> that if you want to build something that will scale and last you  
> should do this carefully and properly secure. I'm not a security  
> expert, but this is a job for one of those.

Thanks for the pointer. This looks way too complicated for what I am  
looking for. Or rather it does not seem to build well on what most  
people know. (The web standards are in   quite complex too but they  
are well known)

I don't think there is a need for identifiers. We have some that are  
well understood, globally used, widely deployed and known as URIs.  
http URIs are the most widely used and are excellent identifiers for  
documents as well as things, as the Semantic Web has taught us.

Also the security level I am looking for at present is at the level of  
openid or better.

I think my suggestion is as good as openid or better. It is better at  
least as far as privacy goes, as it does not require a authentication  
service. The openid authentication services is usually hosted by some  
service provide (Yahoo, Microsoft, ...) which can use this role to  
gather information on what services people are using on the internet.  
True one can start one's own service, but this is not usually accepted.

It is probably more secure, just because it is simpler: it requires  
just a foaf file, and a public key located at a URL. The simpler  
something is, the less likely it can break.


> -Alan
> On Mar 26, 2008, at 7:36 AM, Story Henry wrote:
>> On 25 Mar 2008, at 19:04, Story Henry wrote:
>>> On 25 Mar 2008, at 18:59, Julian Bond wrote:
>>>> Benjamin Nowack <> Tue, 25 Mar 2008 15:51:08
>>>>> That's as simple and close to existing mechanisms as I could get  
>>>>> it.
>>>>> Unlike OpenID and oAuth, there is no need for redirects, so  
>>>>> RDFAuth works
>>>>> for non-browser agents, which was my main requirement.
>>>> I feel like I'm missing something here. oAuth was built  
>>>> specifically to enable non-browser agents and non-UI applications  
>>>> to have good authentication. And it feels like you're re- 
>>>> inventing oAuth. And I'm not sure why.
>>> Well I may be reinventing it because its obvious. Which would be  
>>> good :-)
>>> Let me check it out, since it comes up again and again.
>> Ok, so I read the initial incomplete getting-started documentation  
>> on oAuth, and quickly perused the spec. There are parts that are  
>> interesting and may be useful, and also I may have missed some  
>> important bits. My initial feeling is that oAuth could be a lot  
>> better if it made use of Linked Data [1].
>> Just from reading the getting started documentation I had the  
>> following reservations:
>> - I am not looking for one time authorisation to access resources,  
>> which is what oAuth provides.
>> - 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.
>> What I am looking for is even simpler than oAuth at the first  
>> level. I want simply the server to be able to decide what  
>> representation to return to a user. The user is initially (usually)  
>> not identified. So the resource should know how to return a default  
>> representation, and let the client know that more information is  
>> available. If the user identifies himself then more information is  
>> made available. What the server decides to make available or not is  
>> not of interest here. Presumably the server has a notion of groups  
>> and a notion of information that can be made available to members  
>> of these groups.
>> Since the best way to identify a user is with a URI, a la foaf, we  
>> should use a URI identifier. Note, this need not be a person. It  
>> could also be a foaf:Agent. In order to help make sure that the  
>> user is who he says he is, he encrypts a string (eg. the uri of the  
>> requested resource appended with a nonce) with a pgp private key  
>> that is available from his identifier. (use of linked data)
>> I don't think one can do simpler than that.
>> Now on top of that I can imagine a service like oAuth being built.   
>> So let us give the Beppa eco friendly printing site a foaf file
>> which could be encoded in rdfa in the html of the front page. [2]
>> then what is needed would be a way for beppa to ask to be added to  
>> a group which gives short term access to resources belonging to  
>> another agent (why not identify him via his foaf id?). This seems  
>> to be all that oAuth is doing. Once that is settled, we are back to  
>> our very simple use case described above. Beppa could then ask for  
>> the resources by identifying itself as beppa, and the server could  
>> then return the correct representations. So it seems one could  
>> build one on top of the other.
>> So from what I have read at present I think at first what is needed  
>> is just the very simple protocol a la RDFAuth that was mentioned  
>> previously. More complex services can be built on to of that.
>> Does that sounds right? Have I missed something important?
>> 	Henry
>> [1]
>> [2]
>>> Henry
>>>> -- 
>>>> Julian Bond  E&MSN: julian_bond at  M: +44 (0)77  
>>>> 5907 2173
>>>> Webmaster:      T: +44 (0)192  
>>>> 0412 433
>>>> Personal WebLog:
>>> _______________________________________________
>>> foaf-dev mailing list

Received on Wednesday, 26 March 2008 12:37:08 UTC