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

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"


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



Received on Thursday, 27 January 2011 20:17:15 UTC