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
