W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: sketch of a simple authentication protocol

From: Pipian <pipian@pipian.com>
Date: Wed, 2 Apr 2008 13:54:41 -0400
Cc: Story Henry <henry.story@bblfish.net>, Toby A Inkster <tai@g5n.co.uk>, 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: <4AAF2434-EF5B-4FEC-BE16-E20C49167764@pipian.com>
To: "Chris Richard" <chris.richard@gmail.com>

On Apr 2, 2008, at 1:21 PM, Chris Richard wrote:

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

Absolutely.  This is more or less the key element of the access  
control proposal Jim Hendler and I have made in the TAMI project[1].   
The project focuses a bit more on the accountability/access aspect,  
the idea that a server may wish to authenticate against another server  
(e.g. a server may require proof that you are a fireman to access  
building blueprints, and in order to do so, your identity is checked  
against those approved by the local fire department, etc.)

I've attached a couple of the architecture images we've been working  
with that elucidate the 'webby' nature of this authentication scheme  
(not too dissimilar to those put forth already, though a couple are  
outdated).  I've actually got a mockup of our proposal up already  
protecting the page http://www.pipian.com/rdf/tami/t42_contacts.html,  
but it's using our originally proposed OpenID authentication method,  
which I can elaborate on if you'd like.

Ian Jacobi
Received on Wednesday, 2 April 2008 17:56:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:46 GMT