Re: sketch of a simple authentication protocol

I really like this.

Is it too soon to bring up the case of multiple "semantically-enabled" web
servers whereby a server can make a request to a server on behalf of another
user? Suppose a user GETs a web page or a SPARQL protocol query from a
semantically-enabled server. In order to service that request, the server
makes secure requests to several other semantic servers for protected
resources necessary to build the requested view. The server-to-server
requests can use same authentication process described (steps 2-4 above,
note that many servers already have SSL certificates which is an added
bonus).

However, access to a resource should only be allowed if both the user and
the requesting server are trusted by the owner of the resource. You can
imagine this can be extended to a chain of "on-behalf-of" requests. Would
supporting this be as simple as using a stack of agent-id values? Servers
making a new on-behalf-of request would simply prepend their id to the list
from the incoming request and servers would be required to confirm that all
identities in the list are trusted or granted appropriate permissions (as
you noted previously, this part is external to the protocol).

While each server would *authorise all parties indicated in the agent-id
list*, for a chain of on-behalf-of requests this would require the server
that actually serves a particular protected resource to *authenticate only
the requesting party*. It would implicitly trust that each previous server
in the chain had taken proper steps to authenticate their requesting party.

What do you think?


Chris Richard

On Wed, Apr 2, 2008 at 10:52 AM, Story Henry <henry.story@bblfish.net>
wrote:

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