[foaf-dev] Re: RDFAuth: an initial sketch
Story Henry
henry.story at bblfish.net
Mon Mar 31 16:54:55 BST 2008
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/
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2429 bytes
Desc: not available
Url : http://lists.usefulinc.com/pipermail/foaf-dev/attachments/20080331/95d1b4aa/smime.bin
More information about the foaf-dev
mailing list