W3C home > Mailing lists > Public > public-rww@w3.org > June 2012

Re: delegated authentication

From: Andrei Sambra <andrei@fcns.eu>
Date: Thu, 21 Jun 2012 15:52:54 +0200
Message-ID: <4FE32736.9010400@fcns.eu>
To: public-rww@w3.org
On 06/21/2012 03:27 PM, Kingsley Idehen wrote:
> On 6/21/12 5:47 AM, Henry Story wrote:
>> 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.
> You mean: how http://my-profile.eu (and others) delegate WebID
> verification to 3rd party services? If that's the question then Andrei
> and look at:
> 1. http://id.myopenlink.net/ods/webid_verify.vsp -- WebID verification
> service
> 2. http://ods.openlinksw.com/wiki/ODS/ODSWebIDIdP -- usage guide (a bit
> verbose) .

That's exactly what my current test version does. It takes an optional 
IdP uri (for delegated authentication), and the certificate of the 
person in whose name the server is making the request. However, this 
means that each user will have to share his/her certificate with the 
server (problem).

Now, what Henry said in 3) is to create a trust relation between the 
user and the robot performing the request (server A). I've been thinking 
about this and I think it's quite easy to implement, even without a 
dedicated HTTP header option, by passing the identity of the real user 
as a GET parameter (http://example.com/foaf.rdf?id=<.../andrei/card#me> 
during the robot's authentication process.

Then the server of the requested resource (server B) can check if the 
graph found at <.../andrei/card#me> contains a <webid:robot> or 
<webid:secretary> resource pointing to the robot's WebID (which he used 
to authenticate in the first place). If it does find this resource, it 
means that Andrei explicitly trusts the robot to fetch data in his behalf.

The beauty of it is that server B will not necessarily give access to 
the robot, even though it's acting on behalf of a trusted user.

Received on Thursday, 21 June 2012 13:53:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:10:28 UTC