Re: RDFAuth: an initial sketch

Ok Benjamin,

sorry for taking time to answer to this one. I was having some  
difficulty understanding what
a token server was. Here it is clear that we are very close in our  
understanding of the problem.


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

great!

>   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].

or a pointer to a public key in an asymmetric encryption algorithm  
like PGP.

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

Yes, of course. The interest is to build up on the network effect of  
LinkedData. By having a  URL as a personal Identifier this helps the  
[resource server] find more information on which it can base its  
decision to trust or not the [client app]. It also means that the  
information is available RESTfully, and so could even be edited  
RESTfully by another client app. It all then works very nicely with  
other HTTP standards.

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

ok

>
> 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].

...by GETing information from the user's identifier. (this could of  
course be generalized by relativizing on protocol, but
of course it is easier to stick with http which is well understood)

> 5. The [resource server] validates the [token] via the [token server]

Now I think the only thing I worry about here is whether this means  
you are going to specify how a token server works, and this
seems complicated and full of the same types of authentication  
problems we are trying to solve here.

>
> 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].

yes, using a session token would be very useful to reduce future  
communication costs.
Is this where SSL comes in useful?

[snip]
>
> 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].

It seems to me that we are really very close on how we understand the  
problem. The notion of a token server is what makes me uncomfortable,  
as mentioned before, because it looks like it will be a lot of work to  
specify something like that properly, and because it may not be needed.

Now the anonymous reader of my previous response pointed out to me that

 > Normal HTTPS would only provide you with confidentiality of  
information
 > over the session, and authentication of the server to the client, not
 > the client to the server.  You can use it for mutual authentication  
if
 > you like, using client certificates.  This would probably do  
everything
 > that you're after - mutual authentication, confidentiality, secure
 > sessions, standard protocols.  Not many people use mutual SSL though
 > - don't know how well it works in practice.  Might be worth  
exploring,
 > rather than designing your own public key protocol.

What I think we're after is something like client certificates, but  
discoverable ones
available via URL and linked into the mesh of LinkedData.

Henry

>
>
> Cheers,
> Benji
>
> --
> Benjamin Nowack
> http://bnode.org/
>
>