delegated authentication

Hi, 

  Andrei Sambra asked a question on dig [1] just now, on how one could do delegated authentication with
WebID. This crosses the lines of webid, authorisation and ACLs, so I am sending it to the rww group
and the webid community groups. 

Andrei has built the most user friendly webid site that I know of for the moment,
( http://my-profile.eu/ ), and is now coming across this problem, because he would like the 
server he built to fetch information for the users on his web site as a service in order to improve 
the User Experience. 

There are a number of ways of doing this, and we discussed this at the Federated Social Web conference in Berlin last year with Mike Jones. I talked to Sebastian Dietzold about this too in Leipzig a month ago. So this problem is a real one many people would like solutions to. (My server is not quite there yet to make use of this, so I'll have to keep a theoretical point of view on this)

So let me summarise the potential ways one can do this, as we discovered them during the conversations in Berlin, Leipzig and on previous occasions on the foaf-protocols mailing list (Btw. Sebastian would like to make this a basis for a paper, and I am sure a few others would be interested too.)

1. The my-profile server adds his own public key to the list of all the foaf profiles of the clients he is working with.
  Pro: no change needed to any existing server
  Cons: because cert:key is an inverse functional property, we would just need servers to do reasoning on 
        public keys to come ( correctly ) to the conclusion that all the users of Andrei's site were just 
        one identical agent.

2. The my-profile server generates a different public key for each user and adds those keys to their profiles. 
  Pro: 
    + no change needed to any existing server
    + no danger of cert:key inverse functional behaviour leading to a logical merging of all   
      users for a site
  Cons: 
    - the site (my-profile.eu) needs to open a new TLS connection for each user it wants to fetch profiles for, which is expensive.
    - the fact that the server is acting on behalf of different users is hidden here

3. The server has each user specify the relation he has to the server with a cert:secretary relation (a secretary being the keeper of secrets) for example, joe's profile (hosted on my-profile perhaps) would just 
have the following relation:

   :joe cert:secretary <http://my-profile.eu/#server> .

  This would require access control agents to understand the cert:secretary relationship. WebID authentication on cert:secretary would work as usual, as <http://my-profile.eu/#server> would log
in with his own webid. Still there remains the problem now of how the server can know that the secretary that just authenticated is acting on behalf of a particular user (joe in this case).

   Here we need the my-profile agent to signal this. We could do this by adding a new HTTP header, call  it "Acting-on-behalf-of", to the request. In the request made by my-profile with its own WebID it would add the following to the header
 
      Acting-on-behalf-of: <http://my-profile.eu/joe#me>

The server being logged into would then see this request and be able to make a decision whether the information made available is accessible to the user joe's secretary.

Come to think of it, it looks like none of these require any changes to the WebID protocol, and that this is all in the domain of access control. 

    I think it would be worth discussing this, and seeing if we can come to a consensus on the relationship, which ontology to put it in, and what the HTTP header should be. There seem to be enough users now who would like to implement it, so we could even test it.

    Henry


[1] http://dig.csail.mit.edu/irc/dig/2012-06-21#T09-00-02

Social Web Architect
http://bblfish.net/

Received on Thursday, 21 June 2012 09:48:16 UTC