- From: Benjamin Nowack <bnowack@semsol.com>
- Date: Fri, 28 Mar 2008 12:20:07 +0100
- To: Story Henry <henry.story@bblfish.net>
- Cc: foaf-dev of a Friend <foaf-dev@lists.foaf-project.org>, Semantic Web <semantic-web@w3.org>
Hi, using PGP is interesting, and as I wrote, there should be a way to transparently combine it with RDFAuth. The protocol itself, however, does not rely on it. Neither the [client app] nor the [resource server] require PGP. I wouldn't be able to use RDFAuth on the platforms I'm going to deploy my apps to (shared, hosted LAMP servers) if PGP was a prerequisite. Best, Benji -- Benjamin Nowack http://bnode.org/ On 28.03.2008 10:15:22, Story Henry wrote: >Hi Benjamin, > > >On 27 Mar 2008, at 17:44, Benjamin Nowack wrote: >> >> >> Hi, just some clarifications: >> RDFAuth doesn't use public/private key encryption, but simple >> token servers. Thanks to RDF, eRDFa, MFs, and GRDDL, it also >> doesn't need AX, sREG, or anything like that for data exchange >> and discovery. > >Well RDFAuth is not finalised yet, as far as I understand. The >proposal I am putting forward here does rely on public/private key >encryption, at least at the first stage. I suppose this can be >combined with a token that can then be passed at a later stage when >the initial identification of the client is clear. > >The advantage of this proposal is that it does not need a token >server. It is much more RESTful in this respect, since there is no >need for a dynamic web service. Placing a file on the web is all that >is needed. Furthermore the private key can remain on the client >machine, so there is no need for passwords to travel over the >internet, increasing security still further. Finally since there is no >need for a token server, the OpenId Identity Provider, there is no >centralised point of control which can be used to track your behavior. >True, everyone can use their OpenId server of choice, and even set up >their own, but currently most people are going to be using one of the >big openid providers listed http://openid.net/get/ . >With the RESTful publication of a PGP key, anywhere you wish, even if >the large players wished to publish your key, they could not >distinguish a simple GET of your public key, from one that may be used >to authenticate you at one site. > >Here is the diagram again, this time with the public and protected >resources a little more clearly distinguished. In the previous diagram >I assumed that Juliette's public foaf representation and her protected >were different representations of the same resource. I am not sure if >in HTTP protocol one can do this, and also it caused confusion because >people were wondering how the whole thing would get going, especially >in stage 5 below. Distinguishing this makes it clearer. Public foaf >files would have a link to public keys, and as much other information >as the author wanted to make public. > > > > > >Now if you find encryption and decryption in 3 and 8 to be too >difficult to implement with some of the commonly used tools, that is >easy to fix. Just create an web service to do this for you. But there >is clearly no need to add this to the specification. > > > >> Long-term-ish, this mechanism should be partly replaced by whatever >> oAuth offers WRT server-side token generation, but the main >> motivation right now is to build something very easy that works >> for basic use cases and which can then be extended once we have >> prototypes. >> >> >> So, the idea is more or less: >> >> Prerequisites: >> The [user] of the [client app] maintains a public RDF profile >> that contains a [personal identifier] (foaf:homepage, foaf:openid, >> a personal URI, xfn:me, whatever) and an rdfauth:tokenServer >> triple pointing at the personal [token server]. The identifier >> is ideally a personal URI directly related to the profile to >> simplify "follow your nose" discovery, maybe we should make that >> mandatory to simplify things, not sure. >> >> Scenario A >> >> 1. The [client app] knows/assumes that there is private info >> available at the [resource server] >> 2. The [client app] creates a [token] at the [user]'s [token >> server] (identical to openID, the "how" is not part of the spec) >> 3. The [client app] requests a resource from the [resource server], >> via standard HTTP, plus an "Authorization" header that contains >> the [token], and the [user]'s [personal identifier] >> 4. The [resource server] detects the "Authorization" header, >> extracts the [token] and the [personal identifier] and tries to >> identify the [user]'s [token server]. >> 5. The [resource server] validates the [token] via the [token server] >> 6. Based on the available data (named/trusted graphs, a list of >> trusted token serves, etc.) and app logic, the [resource server] >> decides whether it accepts/trusts the [personal identifier] and >> which information to serve to the [client app]. It may additionally >> create and send a [session token] which might be used for later >> requests. When or how this session token expires is up to the >> [resource server]. >> >> >> Scenario B >> >> 1. The [client app] does not know/assume upfront that there is private >> information available at the [resource server] >> 2. The [client app] requests a resource from the [resource server], >> via standard HTTP >> 3. The [resource server] serves whatever it decides to serve to >> unauthorized clients. This can for example be a partial RDF or >> HTML file. Together with the (possibly "200 OK") response, a >> "WWW-Authenticate" header is sent. >> 4. The [client app] detects the "WWW-Authenticate" header and decides >> whether it'll try to authenticate to retrieve more information. >> 5.-9. = step 2.-6. in Scenarion A >> >> >> Scenario C >> >> 1. The [client app] has a [session token] from an earlier request >> 2. The [client app] requests a resource from the [resource server], >> via standard HTTP, plus an "Authorization" header that contains >> the [session token] >> 3. The [resource server] detects the "Authorization" header and >> extracts the [session token]. >> 4. The [resource server] validates the [session token] and detects >> the associated [personal identifier] >> 5. = step 6. in Scenario A >> >> >> Now, the sent [token] could indeed contain a portion that is generated >> using PGP-encrypted information. In that case the personal [token >> server] >> could be a PGP verifier. This would be transparent to the [resource >> server] >> and the RDFAuth protocol, though. The token will have a certain >> structure >> to make sure that it can only be used for one [user] and one [resource >> server]. >> >> >> Cheers, >> Benji >> >> -- >> Benjamin Nowack >> http://bnode.org/ >> >> >
Received on Friday, 28 March 2008 11:21:01 UTC