Re: RDFAuth: an initial sketch

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/
>
>