W3C home > Mailing lists > Public > public-xg-socialweb@w3.org > January 2010

Re: A comment on Security and Privacy Implications for Contact APIs

From: Story Henry <henry.story@bblfish.net>
Date: Wed, 27 Jan 2010 19:32:21 +0100
Cc: noah_mendelsohn@us.ibm.com, public-device-apis@w3.org, "www-tag@w3.org WG" <www-tag@w3.org>, public-xg-socialweb@w3.org, foaf-protocols@lists.foaf-project.org
Message-Id: <699C5EB0-8688-4811-A9B9-60B23DF93B4F@bblfish.net>
To: Thomas Roessler <tlr@w3.org>

On 27 Jan 2010, at 16:55, Thomas Roessler wrote:
> On 27 Jan 2010, at 16:14, noah_mendelsohn@us.ibm.com wrote:
> 
>> For the above reasons, it seems to me that an appropriate mechanism for 
>> the contacts API will likely involve an ability not just to ask for 
>> permission, but to clarify the subset of the contacts for which access is 
>> being granted.  It may also be necessary to separate access for purposes 
>> of searching vs. access for purposes of display, transmission or 
>> republication.
> 
> It strikes me that an address book in some ways behaves similarly to a file system:
> 
> Just like my file system includes some data that I'm happy to make accessible to some web sites, my address book will include things like a company's hotline.
> 
> And then there is the mobile phone number (or the complete dump of a company's LDAP directory) that, if disclosed, will get me into real trouble.
> 
> This suggests that building the API so it deals with some specific subset (and generally doesn't make decisions about the *entire* address book) is really important.

This is what we are now working on the foaf+ssl mailing list. FOAF+SSL allows us to create global, decentralised, RESTful, standard compliant, patent-less authentication system in 1 connection + 1 cacheable connection.

	http://esw.w3.org/topic/foaf+ssl

We invent nothing new, we just use X509 certificates (possibly self-signed) in a slightly different way than usual, avoiding the problem and complexity of CA signatures.

Once authenticated the address book server will know the user's WebID (the URL for the agent authenticated), and whatever public information is served at that WebId. If that representation points to protected resources the user agent can then fetch that protected resource, which will be returned if his WebID is part of the group of outhorized users.

It is really that simple. We are just putting a few demos together for this. There are apache and perl modules that it can be tried with.

     Henry
Received on Wednesday, 27 January 2010 18:33:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:08 UTC