[foaf-dev] Re: privacy and open data
Alan Ruttenberg
alanruttenberg at gmail.com
Wed Mar 26 12:11:44 GMT 2008
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.
http://www.handle.net/rfc/rfc3652.pdf
-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 <bnowack at semsol.com> 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
>
> http://beppa.com/#company
>
> 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] http://blogs.sun.com/bblfish/entry/hyperdata_and_folktologies
> [2] http://blogs.sun.com/bblfish/entry/a_foaf_file_for_sun
>
>
>
>> Henry
>>
>>
>>> --
>>> 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
>> _______________________________________________
>> foaf-dev mailing list
>> foaf-dev at lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>
More information about the foaf-dev
mailing list