- From: Story Henry <henry.story@bblfish.net>
- Date: Wed, 2 Apr 2008 16:52:48 +0200
- To: Toby A Inkster <tai@g5n.co.uk>
- Cc: Semantic Web <semantic-web@w3.org>, foaf-dev Friend of a <foaf-dev@lists.foaf-project.org>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-Id: <61895659-0431-4EE7-99CB-6AF196382555@bblfish.net>
Hi Toby, I thought it would be fun to represent your answer [1] with a Sequence Diagram to make sure I have really understood what you are saying. It is even simpler that the previous sketch.
So let me rephrase your steps: 1. Romeo's User Agent GETs Juliette's public foaf file at <http://juliette.org/ >, that file contains the relation: <> rdfs:seeAlso <https://juliette.org/protected/juliette> . 2. Romeo's UserAgent does a GET on the HTTPS URL with the extra identification header: Agent-Id: http://romeo.name/#romeo All the https handshake stuff goes on as usual. From this Juliette's server extracts the hex id of the SSL key used by Romeo's User Agent. 3. Juliette's Server notices the extra header and GETs the resource at http://romeo.net/ this contains the statements :romeo is wot:identity of [ a wot:X509Key; wot:hex_id "ABC123AB"; wot:pubkeyAddress <http://key.com/romeos.key>; ] . 4. Juliette's Server queries the triples returned in the the representations with the SPARQL query PREFIX wot: <http://xmlns.com/wot/0.1/> SELECT ?hexid WHERE { [] wot:identity <http://romeo.name/#romeo>; wot:hex_id ?hexid . } 5. Since Juliette's user agent trusts the URL "http://romeo.name/ #romeo" - for whatever reason, perhaps her best friend had it in her foaf file - and the SSL session was signed by the client with the public key identified by hex_id "ABC123AB", she knows that the UserAgent has a strong enough trust relation with the person identified by <http://romeo.name/#romeo>, and so she returns the protected information over SSL. Could it really be this simple? Henry [1] http://lists.w3.org/Archives/Public/semantic-web/2008Mar/0207.html On 1 Apr 2008, at 12:40, Toby A Inkster wrote: > > Story Henry wrote: > >> My feeling is that what is needed is to see how this could be made to >> work better with SSL. > > I've already posted a message suggesting an HTTPS-based solution. > > Message-ID: <62649.81.2.120.180.1206622777.squirrel@goddamn.co.uk> > Subject: Re: [foaf-dev] Re: privacy and open data > Date: Thu, 27 Mar 2008 12:59:37 -0000 (UTC) > > Summary: > > 1. Client requests public FOAF > 2. FOAF contains rdf:seeAlso with URI for HTTPS private FOAF > 3. Client requests private FOAF using a client-side SSL cert > 4. Client includes URI of their public FOAF in HTTP "From" header > 5. HTTPS server requests client's public FOAF file and queries it > to find client's certificate serial number > 6. Server checks that FOAF serial number matches the request > cert serial number, thus requesting client really does own > the FOAF file in HTTP From header > 7. Server makes decision on what information client should be > shown, based on client's FOAF, and on client's FOAF URI > 8. Server sends client this information as RDF > > -- > Toby A Inkster BSc (Hons) ARCS > [Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux] > [OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 5 days, 21:52.] > > Cognition 0.1 Alpha 6 > http://tobyinkster.co.uk/blog/2008/03/29/cognition-alpha6/ >
Attachments
- image/png attachment: SequenceDiagram_withSSL.png
- application/pkcs7-signature attachment: smime.p7s
Received on Wednesday, 2 April 2008 14:53:44 UTC