Re: delegated authentication

On 21 Jun 2012, at 15:53, Andrei Sambra wrote:

> 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.

I understand you to be saying above that you are thinking of the secretary robot
connecting to some server  (say on IBM.com),  and then make a request on that resource 
but somehow adding a ?id=webid to the url it was going to request? How would it know
that that resource understood the same thing that you thought you meant when adding 
?id=webid to the resource? There may not even be a resource there. (those are 2 different
URLs)

That does not seem very RESTful. It would require 2 requests on the resource:
one where you get the version without the ?id=webid fields, and it returns some information 
telling you how you can GET a version for the secretary namely in your case by
adding a ?id=webid field (perhaps it returns a semantically annotated form). 


If you are thinking of logging in to ibm.com each time, this could work for a human agent using a login form, but would be tedious (they'd have to remember the URL). I  think we are really developing something for robots here.

Also it would require a logout form too, so that the robot could first login
as the secretary of one person, logout, then login again as the secretary of 
another person... For larger services this would not be very helpful, especially
those using tools like SPDY that asynchronously send messages.

If we stick to robots then things should be simpler. For humans things could then
be adjusted with plugins for user agents. I think the immediate use case for you
and others is server doing requests. For them changing http headers are not problematic.



> 
> 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
> 

Social Web Architect
http://bblfish.net/

Received on Friday, 22 June 2012 09:33:09 UTC