W3C home > Mailing lists > Public > www-archive@w3.org > July 2010

Re: [foaf-protocols] Standardising the foaf+ssl protocol to launch the Social Web

From: Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk>
Date: Mon, 12 Jul 2010 01:04:53 +0200
Message-ID: <4C3A4E15.6070006@manchester.ac.uk>
To: Henry Story <henry.story@gmail.com>
CC: Harry Halpin <hhalpin@w3.org>, Tim Berners-Lee <timbl@w3.org>, Jeffrey Jaff <jeff@w3.org>, foaf-protocols@lists.foaf-project.org, Ian Jacobs <ij@w3.org>, Ivan Herman <ivan@w3.org>, www-archive <www-archive@w3.org>, Thomas Roessler <tlr@w3.org>
Hi Henry,

On 11/07/2010 23:47, Henry Story wrote:
> On 10 Jul 2010, at 18:34, Harry Halpin wrote:
>>> Great discussion folks!
>>> I think this thread should give the w3 folks we are CCing here a good idea
>>> of the passion, quality of work, depth of discussion and breadth of the foaf+ssl
>>> community, which includes hackers from every programming language, researchers
>>> from every continent, security as well as linked data specialists, and more.
>>> Perhaps we should leave them a bit of time to digest the details of this thread,
>>> so they can then let us know how we should proceed.
>> Digesting. Overall, great to follow, +1 to Bruno's points re security.
> You mean the one where he suggests that the WebId protocol is not more secure
> than OpenId? Why do you think this is true? I think it is clearly wrong, in
> fact obviously wrong for a number of reasons of which the simplest is
> just the relative complexity of the two protocols.

I think you've missed my point. The complexity of the protocol isn't 
really at stake here. Regarding security, what matters is the weakest 
link in the chain: it's the same for OpenID and FOAF+SSL/WebID (without 
building a cryptographic web of trust).
In both cases, whoever controls the hosting of the WebID controls the 
way the physical user may be challenged to prove their identity.

For more important services such as banking, I don't want anyone who's 
not me or my bank to be able to impersonate me, or effectively change my 
password (or public key in our case). I don't want to have to wonder 
whether my hosting company is sufficiently honest or offers sufficient 
protections against hacking on their server for this sort of services.

It's a matter of risk assessment. If someone was to tamper with your CV 
on your website, you'd be upset, but you would certainly manage to limit 
the damage. If someone tampered with your FOAF document and if your bank 
allowed connections into your account simply on the basis of what the 
document dereferenced from your WebID contained, you'd be more worried.

OpenID and WebID, by making the URL and its dereferencing as the primary 
pillar of trust, is fine for a large number of use-cases (most social 
networking frameworks, blogs, ...), but when the legal and financial 
consequences have higher stakes, you'd want a higher level of assurance. 
As it stands, WebID by simple dereferencing, without a cryptographic web 
of trust offers the very same level of assurance as OpenID.
Building a network of reputation (which is what you call "web of trust") 
by linking WebIDs as friends of other WebIDs is pointless if you can't 
make sure that the physical person gaining access WebID is indeed who 
they are. That's something that a (cryptographic) web of trust (a la 
PGP) can help with (I'm not saying it's perfect).

The real security enhancement of FOAF+SSL should come from the fact we 
have the cryptographic instruments (the keys) and that we *could* go 
further than effectively just checking who controls the hosting of a 
WebID. There is the potential, but this isn't something we do yet.

In addition, you seem to assume that certificates reduce the complexity. 
Sure, there are fewer steps in the protocol, but there's also a security 
issue in how users perceive and make use of the technology. 
Unfortunately, most people consider that client certificate increase the 
complexity. As such, if they're badly understood, client certificates 
could be badly taken care of by their users, which could in fact make 
things worse.

Best wishes,

Received on Sunday, 11 July 2010 23:07:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:43:41 UTC