- From: Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk>
- Date: Mon, 12 Jul 2010 01:04:53 +0200
- 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, Bruno.
Received on Sunday, 11 July 2010 23:07:53 UTC