Re: sketch of a simple authentication protocol

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