- From: Andrei Sambra <andrei@fcns.eu>
- Date: Thu, 21 Jun 2012 15:53:32 +0200
- To: public-webid <public-webid@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. Andrei
Received on Thursday, 21 June 2012 13:54:03 UTC