Re: [foaf-dev] Re: privacy and open data

[I sent this response a little while ago, but it seems to have disappeared
into the aether, so I am sending it again. Apologies if your recieve it
twice.]

Karl Dubost wrote:

> My "utopian" FOAF resource, let's say an URI
> http://example.org/foaf.rdf
>
> Mr Smith asking it  would get "name" and "email" Ms Boo (a friend of
mine)  asking   it  would get "my address"
>
> only the relevant part of the file would be accessible depending on the
acls (system with pgp keys?)

Given that HTTPS already includes TLS, it should be feasible to
implement a system based on HTTPS.

In the following examples, I'm going to use a hypothetical WOT 0.2 schema
for RDF. WOT 0.1 defines wot:PubKey to specifically be a
PGP/GPG key, but for WOT 0.2 we'll allow it to be any kind of public key,
and define a wot:pubKeyType to explicitly declare the type of the key. In
lieu of an explicit type being declared, user agents can determine the key
type from HTTP headers, heuristics, etc. We also say that for TLS (X.509)
keys, wot:hex_id is defined to contain the serial number.

The resource <http://example.org/foaf.rdf> is your static public
profile. It might contain your name and a few other details that
you are happy to share with the world. It should contain enough
information for people to be reasonably sure that it's describing
*you* and not some other Karl Dubost.

It also contains:

<http://example.org/foaf.rdf> rdfs:seeAlso <https://example.org/foaf.cgi>;
	wot:hasKey #myKey.
#myKey a wot:PubKey;
	wot:pubkeyAddress <http://example.org/x509.key>;
	wot:pubKeyType "X.509";
	wot:hex_id "ABC123AB".

The first triple there is a link to your "private profile". The rest
describe your public key. These are not strictly necessary for this
example, as you are acting as the provider of information, but should you
wish to consume information, it would be required.

Now a client wishing to request additional information about you will make
an HTTPS request to your private profile. The request will be encrypted
using *their* TLS key. As part of this request they also must include the
URI for *their* public profile -- not quite sure
what is the best way to do this. For now, let's extend the meaning of the
rarely-used "From" HTTP header to allow a URI to be included.

Now the HTTPS server will do its usual HTTPS things and verify that the
client's TLS cert is valid, and the foaf.cgi script (or whatever: this
technique is not limited to the Common Gateway Interface) takes over.

The script looks at the From header in the HTTPS request. If this is
blank, then it's clear that the client isn't respecting our little
cobbled-together protocol. So the script simply returns a carbon
copy of the public profile.

If it's non-blank, then the script fires off a request to the URI
given in the "From" header to retrieve the *client's* public
protocol. In particular, this lists the wot:hex_id of the client's TLS
key. The script checks the wot:hex_id against the serial number of the
certificate used in the HTTPS request. (With Apache CGI, this can be found
in the SSL_CLIENT_M_SERIAL environment variable. This may differ in other
servers.) If they do not match, something foul is afoot, so the script
issues some sort of dire error message.
Perhaps even retaliates by sending wilfully incorrect RDF data back.

If the wot:hex_id matches the serial number, then we can be
reasonably sure (assuming that the client has kept their X.509
private key secure!) that the client really is the person identified by
the resource in the "From" header.

The script can now freely provide additional information about
Karl Dubost to the client, according to the rules that you have
defined. It can grant access to information based on the client's
profile URI itself -- e.g. you may have declared that
<http://example.com/mrs-boo.rdf> is to be allowed access to your
address. Your script also (of course) has access to the client's
public FOAF profile, so you could configure it such that if their
profile reveals a foaf:interest in Cheese, it will reveal that you are
president of the Brunei Cheese Lovers' Association. It packages all this
information up in a neat little RDF/XML wrapper and sends it back to the
client.

So all the technology is in place. All that is needed is a few
extensions to the WOT schema, proper documentation for this pattern, and a
few client and server implementations.

-- 
Toby A Inkster BSc (Hons) ARCS
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Thursday, 27 March 2008 13:00:32 UTC