W3C home > Mailing lists > Public > public-webid@w3.org > October 2012

Re: [saag] Liking Linkability

From: David Chadwick <d.w.chadwick@kent.ac.uk>
Date: Thu, 18 Oct 2012 20:18:41 +0100
Message-ID: <50805611.2000904@kent.ac.uk>
To: Ben Laurie <benl@google.com>
CC: Henry Story <henry.story@bblfish.net>, "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>, "public-identity@w3.org" <public-identity@w3.org>, "public-philoweb@w3.org" <public-philoweb@w3.org>, "saag@ietf.org" <saag@ietf.org>, "public-webid@w3.org" <public-webid@w3.org>, "public-privacy@w3.org" <public-privacy@w3.org>
Hi Ben

I disagree. It depends upon your risk assessment. Your stand is like 
saying TLS should be the substrate, not http. There are two alternative 
viewpoints. You can either start with the lowest security/privacy and 
add to it, or make the highest security/privacy the default and then 
take from it. So you should not necessarily mandate that U-Prove/Idemix 
are the default tokens, but rather only require them if your risk 
assessment says privacy protection is essential



On 18/10/2012 16:34, Ben Laurie wrote:
> On 9 October 2012 14:19, Henry Story <henry.story@bblfish.net> wrote:
>> Still in my conversations I have found that many people in security spaces
>> just don't seem to be  able to put the issues in context, and can get sidetracked
>> into not wanting any linkability at all. Not sure how to fix that.
> You persist in missing the point, which is why you can't fix it. The
> point is that we want unlinkability to be possible. Protocols that do
> not permit it or make it difficult are problematic. I have certainly
> never said that you should always be unlinked, that would be stupid
> (in fact, I once wrote a paper about how unpleasant it would be).
> As I once wrote, anonymity should be the substrate. Once you have
> that, you can the build on it to be linked when you choose to be, and
> not linked when you choose not to be. If it is not the substrate, then
> you do not have this choice.
Received on Thursday, 18 October 2012 19:19:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:37 UTC