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