- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Wed, 26 Mar 2008 08:11:44 -0400
- To: Story Henry <henry.story@bblfish.net>
- Cc: Semantic Web <semantic-web@w3.org>, Julian Bond <julian_bond@voidstar.com>, foaf-dev of a Friend <foaf-dev@lists.foaf-project.org>
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@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@lists.foaf-project.org >> http://lists.foaf-project.org/mailman/listinfo/foaf-dev >
Received on Wednesday, 26 March 2008 12:12:40 UTC