- From: Benjamin Nowack <bnowack@semsol.com>
- Date: Fri, 28 Mar 2008 13:43:32 +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>
Hmm, ok, but wouldn't users also have to upload a private key to my server? And my app would have to send the private key to the encryption service, which I guess isn't too cool either. Benji On 28.03.2008 12:32:28, Story Henry wrote: >Well as I mention it would be easy to create a PGP encryption >decryption web service. That should be very easy to set up. What is >the problem? > >Henry > >On 28 Mar 2008, at 12:20, Benjamin Nowack wrote: >> >> 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 12:44:16 UTC