Re: RDFAuth: an initial sketch

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