Re: delegated authentication

Hello everyone,

First of all, thank you Henry for sending the email.

 From the three suggestions Henry just made, I am personally against the 
first. The problem is that the other servers have no way of knowing the 
real person on behalf of which the request is being made. One may have 
different access policies for two users using the same service (i.e. 
my-profile.eu). Additionally, the server's public key should not really 
belong in a user's profile.

For the second suggestion, one of the cons you described (open a new TLS 
connection) is not really a problem. The server still needs to fetch the 
data from remote hosts, so the process of authentication will probably 
take place during this phase anyway.

I personally prefer the third suggestion, even if it will take some time 
to decide on how we can implement  all the required elements (e.g. 
"cert:secretary"). The reason I like this suggestion is that it makes 
the difference between a real user and a robot when trust decisions have 
to be made, and also because it allows for traceability and eventually 
accountability (which is more important).

I'm still thinking about it from the perspective of privacy and user 
experience, so I think we can at least define a few rules we can follow 
whilst deciding on the best solution. Here are some tentative rules:

1. The identity of the user must be separated from the identity of the 
robot (server).

2. An explicit relation between the user and the robot must be specified.

3. Resulting data must be stored according to the context it belongs to. 
When Anne and Barry request data from Dan, Anne's "view" of Dan's 
profile should only be available to her alone, and it should not be 
merged into the same graph containing Barry's view.

4. Implementing delegated authentication must not be an inconvenience 
for the user. The more transparent it is, the better. (similar to how 
pingback currently is)

Please add more rules if you can think of any.

Andrei

On 06/21/2012 11:47 AM, Henry Story wrote:
> 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 10:53:14 UTC