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

I'd counsel using a different model for comprehending that sequence.
 
Its final state is what is known as peer trust, having bilaterally exchanged keys and names. You can think of it as each peer is cross-certifying the other's key/name binding. Nathan happens to use the model of webid names, foaf cards for storing keys, web servers limiting write access to foaf card graphs, and complete ssl handshakes for signing. Others have used DNs, directory entries, ACLs on write privileges in directory entries, and signed (cross-)certificate minting.
 
In "peer trust", every entity is a CA, and any one entity can re-sign credentials already issued (and probably once signed) by third party CAs. 
 
The scheme really only works when "peering", as it requires a reciprocal process - in which I follow you, you follow me.
 
The larger commercial CAs have long recognized peer trust scheme as a business threat, and generally have terms and conditions that prohibit their subscriber with "issued certs/keys" from repurposing those public keys in this manner. 
 
In 1994 when 1 million client certs were issued as an experiment to navigator 3 and IE3 users, the logic was: I do all the work to introduce you to each other, and you then dump me and just trust each other thereafter? There was no web-centric business model to recover the initial costs and define a continuing value. Thus the practice was prohibited when using public keys already under management.
 
Now, what I succesfully argued, to promote certs in the web generally, was that the world of self-signed certs should be countenanced. And, duely, peering protocols could come into their own. Thus, the whoel web infrastructure supprots self-signed certs just as well as it does issued certs.
 
Should one fashion self-signed certs using keys NOT managed by a third and now peer (as above), the CA business plans had no problem with this, viewing it as a marketing tool to teach the world about the management value theybrought, as peering relation get harder to managed as they scale (viz PGP). 
 
This is where we now back to, 16 years later, with the webid protocol work : peer trust.
 
Once there is peer trust, then one worrired about rights to print documents, where rights are bound to entities or channels speaking-for the entity under classical Lampson reasoning about authentication.

 
> From: henry.story@bblfish.net
> Date: Thu, 27 Jan 2011 19:56:32 +0100
> CC: public-xg-webid@w3.org
> To: nathan@webr3.org
> Subject: Re: [foaf-protocols] The other side of WebID / four party auth
> 
> [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"
> 
> > but never 
> > mentioned in detail, roughly the protocol would be:
> > 
> > client: this is my cert (key pair w/ webid) - CC
> > server: this is my cert (key pair w/ webid) - CS
> 
> Though actually this is done in one https connection,
> and it happens the other way around: with the
> server first proposing it's certificate, asking the 
> client for its cert, which the client can then choose to
> send.
> 
> > 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.
> 
> 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.
> 
> > 
> > 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.
> 
> Henry
> 
> > 
> > Best,
> > 
> > Nathan
> > _______________________________________________
> > foaf-protocols mailing list
> > foaf-protocols@lists.foaf-project.org
> > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> 
> Social Web Architect
> http://bblfish.net/
> 
>