Re: sketch of a simple authentication protocol

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 < 
 >, that file contains the relation:

    <> rdfs:seeAlso <> .

2. Romeo's UserAgent does a GET on the HTTPS URL
    with the extra identification header:


    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

    this contains the statements

    :romeo is wot:identity
              of [ a wot:X509Key;
                   wot:hex_id "ABC123AB";
                   wot:pubkeyAddress <>;
                 ] .

4. Juliette's Server queries the triples returned in the the  
    with the SPARQL query

    PREFIX wot: <>
    SELECT ?hexid
    WHERE {
              [] wot:identity <>;
                 wot:hex_id ?hexid .

5. Since Juliette's user agent trusts the URL " 
#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 <>, and so she returns the  
protected information over SSL.

Could it really be this simple?



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: <>
>  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, up 5 days, 21:52.]
>                           Cognition 0.1 Alpha 6

Received on Wednesday, 2 April 2008 14:53:44 UTC