- From: Henry Story <henry.story@bblfish.net>
- Date: Mon, 8 Oct 2012 11:53:20 +0200
- To: Ben Laurie <benl@google.com>
- Cc: Melvin Carvalho <melvincarvalho@gmail.com>, "public-webid@w3.org" <public-webid@w3.org>
- Message-Id: <16F4FEF4-81FA-42F9-8F98-6034D26A291C@bblfish.net>
On 8 Oct 2012, at 11:36, Ben Laurie <benl@google.com> wrote: > On 6 October 2012 08:48, Melvin Carvalho <melvincarvalho@gmail.com> wrote: >> WebID is actually 2 specs. >> >> 1. The first part is authentication via your public key which is a IFP of >> your identity. In certain circumstances (ie caching, just like >> ~/.ssh/authorized_keys ) you can be done here and it operates like SSH. >> >> (1) I think solves the unlinkability problem > > How? Clearly the public key makes all authentications that use it linkable. +1 yes. It' is only unlinkable in the bizarre sense (which may in fact be nonsense) in which for Harry Halpin BrowserId has some unlinkable properties that WebID lacks. In any case the linkability issue is one which requires one to decide who the attacker is according to the definition [1] • If the attacker is the site you are logging into, and you want to communicate with that site unlinkably - as a wikileaks leaker would want to do to cover his tracks - then using WebID, BrowserId or other such systems is really not the right technology. That is pretty self evident. • On the other hand if you want to avoid a centralised network, be able to create long term relationships across organisations - and the site you are communicating with is not an attacker - then WebID is the right solution. The linkability properties of WebID becomes a positive without the negative of the unlinkability. Perhaps that is how we can summarise the linkability properties of WebID? Henry [1] http://tools.ietf.org/html/draft-iab-privacy-terminology-01#section-4 Social Web Architect http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 8 October 2012 09:53:52 UTC