W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2011

Re: [foaf-protocols] The other side of WebID / four party auth

From: Nathan <nathan@webr3.org>
Date: Thu, 27 Jan 2011 20:14:56 +0000
Message-ID: <4D41D240.7090509@webr3.org>
To: Henry Story <henry.story@bblfish.net>
CC: WebID XG <public-xg-webid@w3.org>
Henry Story wrote:
> [dropping foaf-protocols]
> 
> On 27 Jan 2011, at 03:17, Nathan wrote:
>> This is the four party auth I mentioned earlier in the year,
> 
> So this would be something that should be looked at with ISSUE-4:
> "Detail Authorization "protocol" using WebID"

agree

>>  client: take webid from CS, place in CC-webid foaf file
>>  server: take webid from CC, place in CS-webid foaf file
> 
> If this is an authorisation protocol, don't we need
> a place perhaps for a decision somewhere? Or at
> least a signal to be sent that the client or server is
> seeking to create some relationship with the
> other party? There is a dialog missing in your sketch
> between the two parties.

yup, correct :) it would definately need fleshed out considerably 
more, but I'm also aware that it's essentially a superset of webid, 
and would require considerably more to implement and standardize, 
perhaps it could be used as a counter proposal which one could place 
realistic constraints on to in order to re-produce the webid protocol

> In the "Sketch of a Photo Printing Service" this
> is enabled by placing a relation to an authorization end point
> in the Profile Document.
> 
> http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo
> 
>>  client: check CS-webid foaf file for CC-webid and CS-key
>>  server: check CC-webid foaf file for CS-webid and CC-key
> 
> Here you seem to be checking the identity of the other party
> after having added them to your profile. That seems to be the
> wrong way around.

unsure, the flow is definitely somewhat asynchronous, and these are 
the kind of issues which would need to be fleshed out; one could see 
it as a temporary token, which you remove should you fail to 
invalidate it - essentially it's just replacing a random pair of 
agree'd tokens with the webid uris to make it simpler, the basic 
principle is just "here's a token, if you can place that in your 
profile then I know you /still/ have write permission to it".

O.. just realised, there isn't actually a need to have the public key 
in our profiles, if we can place some token given by the other party 
in our profile, that still proves ownership/authorship to the 
resource.. that follows doesn't it? (although it moves the protocol 
from sync to async as noted above).

>> The above covers all bases, it ensures the user and the server are who 
>> they say they are, still have write permission to their respective 
>> webid resources, ensures HTTP+TLS in all communications, allows ACL 
>> controlled responses from each webid resource to only give the (server 
>> or client) access to the info it's allowed to see. And it would be 
>> webid for the server too, and get rid of the traditional trust chain, 
>> making room for new linked-data web of trust.
>>
>> Essentially, this would replace everything from openid to oauth and 
>> beyond.
>>
>> thoughts? and apologies it took me so long to mention properly on list.
> 
> I would be intersted in your feedback on how you think this 
> improves over the restful photo service.

Likewise, if there's some agreement this would be useful to explore, 
or at least have written up in a bit more detail, then I'll be happy 
to take on an action and draft up a wiki page over the next 10 days so 
we have a reference there.

Best,

Nathan
Received on Thursday, 27 January 2011 20:17:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 27 January 2011 20:17:16 GMT