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

The other side of WebID / four party auth

From: Nathan <nathan@webr3.org>
Date: Thu, 27 Jan 2011 02:17:17 +0000
Message-ID: <4D40D5AD.8030702@webr3.org>
To: WebID XG <public-xg-webid@w3.org>
CC: foaf-protocols <foaf-protocols@lists.foaf-project.org>
 From a mail a moment ago to Peter on foaf-protocols:

Essentially, the protocol is a case of:

  this is my key pair (present certificate, let TLS confirm it's valid)
  this is my webid
  protocol = deference webid, check if "owned" key is found, if so 
assert that user has authority over the resource identified by the 
webid-minus-frag, and thus webid is a valid name for them


However, I'm positively more interested in getting a list of ways in 
which the dereferencing process can be abused / hacked / man in the 
middled, as that's the biggest grey area in all of this at the minute.

On that note, we should really be giving ourselves https:// scheme 
webids to prevent the man in the middles, and force TLS across the 
wire there too, which would give far more scope for the protocol to 
become an OAuth replacement, since one could repeat the flow with our 
storage agents to only allow trusted servers access to our 
information, and to log + identify everybody accessing it, but that's 
a different topic.

This is the four party auth I mentioned earlier in the year, 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
  client: take webid from CS, place in CC-webid foaf file
  server: take webid from CC, place in CS-webid foaf file
  client: check CS-webid foaf file for CC-webid and CS-key
  server: check CC-webid foaf file for CS-webid and CC-key

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 

thoughts? and apologies it took me so long to mention properly on list.


Received on Thursday, 27 January 2011 02:18:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:40 UTC