Re: [saag] Liking Linkability

Ben Laurie <benl@google.com> Mon, 22 October 2012 09:54 UTC

Return-Path: <benl@google.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF0421F89E9 for <saag@ietfa.amsl.com>; Mon, 22 Oct 2012 02:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.677
X-Spam-Level:
X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLZFwIP6Kybt for <saag@ietfa.amsl.com>; Mon, 22 Oct 2012 02:54:37 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 94EB221F843A for <saag@ietf.org>; Mon, 22 Oct 2012 02:54:36 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so1845146wib.13 for <saag@ietf.org>; Mon, 22 Oct 2012 02:54:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=bZwZCovYwvXmyRbzytFvq58uPLSYd0uhY76AAInFs08=; b=DZt2vf3ErEuHuqf1CW3LrOQBlcGRbxwDWoUzV+mQ2qVY8oag68PB8rUXIpyhZtGvSi BVbPXGx1bA54upQTpGI6oe1nQfiX+bqHCzT4y8v3Raj9RR3L9gfsNQ6zNTsF3FMhX32p W7VXk6v9P+mjovlVsSTV9ODpWtowcRVlounQN9796C7sx8ZqsxwlsI+GO2WGS8CfGCXI aZsXVM2hJhnhmfj9cU/F7QDkrc+mvX9VywGJFpT1YhcX8b0QvZ9wW2uvdYisTsje2r2R bKXNu2QbH7LdoxpI40XFKjJYy3NSPsAdIzATZWxQ5fynlrsaX4Px/fVvr4aOC+Z6U0Kp rGwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=bZwZCovYwvXmyRbzytFvq58uPLSYd0uhY76AAInFs08=; b=Rmaqo0xSwaDWMOSLDofhvYgqwJ/PRJpLrlL/VMg/zWq7Bf9iTtP3fNIHqho38pItD3 n98MTKQoD0UlGT4Du9tvBSwn7SIy4tzfoAnkBLvt2g9t9IK0ppdQJzCZ88mDCrogcxhg mlyqdsOSUC++2LZZXUqED8Po2FYKSKyhsyq8DlKPJ35ihyYo1Z2ikQ9axUNE0bSzPG/H r5PY5/Bfvn08IL1mKsMZ2vMbKy25OUEdc7EcR+O16T/nkA3yFxP+mpCTjBN1SKteshDf 7/kWbctso4da5NBjtEVza1FRQP8kwVuNT4Lbeq7il77tFyUQF9arVAmOucXs66fVVDJ/ +ezQ==
MIME-Version: 1.0
Received: by 10.216.136.23 with SMTP id v23mr5191616wei.45.1350899675464; Mon, 22 Oct 2012 02:54:35 -0700 (PDT)
Received: by 10.194.76.170 with HTTP; Mon, 22 Oct 2012 02:54:35 -0700 (PDT)
In-Reply-To: <50851512.9090803@webr3.org>
References: <CCA5E789.2083A%Josh.Howlett@ja.net> <tslzk3jsjv8.fsf@mit.edu> <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <FB9E461D-CA62-4806-9599-054DF24C3FD9@bblfish.net> <CAG5KPzxGz+4MywjP4knfbDr2gyvqUZc1HEBXgtaDfYT+DPg5yg@mail.gmail.com> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <CABrd9SQghpi6_rVQKxYXZDtM5HwvE7Kq7SUw5zi41ZRd3y2h9A@mail.gmail.com> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <CABrd9SQU1uYVaVPedokHxeYkT=759rkPFfimWK1Z8ATzo3yNFA@mail.gmail.com> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com> <50851512.9090803@webr3.org>
Date: Mon, 22 Oct 2012 10:54:35 +0100
Message-ID: <CABrd9SRNVLbWxifQAQ6iuX4qMeFmZVD6rO_q=L348G1UZzr9tg@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: nathan@webr3.org
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlUP3NYZuNh2o/Ag98fHytOhiUgClbsdlX4AoyMAb0rHOyyZ83+A/fU3ZweHL+lqNwtxAZDt2WYecUf6d9S6q9SUu4r+OEn5ZrAVAiMXE7SLZAwDPMupnXcDkbjDhPJVvysSPPieGFbyMAH8B/Zmb8XI/QAZqSL14SGmDyGaoiGtzBSKj+xghlyLaiyqyK0xxqcg4h0
X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700
Cc: "public-philoweb@w3.org" <public-philoweb@w3.org>, "public-identity@w3.org" <public-identity@w3.org>, "saag@ietf.org" <saag@ietf.org>, Melvin Carvalho <melvincarvalho@gmail.com>, "public-privacy@w3.org" <public-privacy@w3.org>, Kingsley Idehen <kidehen@openlinksw.com>, Sam Hartman <hartmans-ietf@mit.edu>, "public-webid@w3.org" <public-webid@w3.org>
Subject: Re: [saag] Liking Linkability
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Oct 2012 09:54:37 -0000

On 22 October 2012 10:42, Nathan <nathan@webr3.org> wrote:
> Kingsley Idehen wrote:
>>
>> On 10/21/12 3:52 PM, Nathan wrote:
>>>
>>> Kingsley Idehen wrote:
>>>>
>>>> On 10/21/12 6:22 AM, Nathan wrote:
>>>>>
>>>>> Ben Laurie wrote:
>>>>>>
>>>>>> I'm getting quite tired of this: the point is, you cannot achieve
>>>>>> unlinkability with WebID except by using a different WebIDs. You made
>>>>>> the claim that ACLs on resources achieve unlinkability. This is
>>>>>> incorrect.
>>>>>
>>>>>
>>>>> You're 100% correct here Ben, and I'm unsure why it's so hard to
>>>>> convey!?
>>>>>
>>>>> If you use the same identifier for more than one request, subsequent
>>>>> requests can be associated with the first request. An identifier here is any
>>>>> identifying, stable, information - key parts and URIs.
>>>>>
>>>>> If the issue is only unlinkability across sites, then you just have a
>>>>> keypair+uri per site. Or better, key-pair only, and that's associated with
>>>>> an identifier for the agent behind the interface.
>>>>>
>>>>> You're correct that ACLs won't cut it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Nathan,
>>>>
>>>> What is the subject of unlinkability ?
>>>>
>>>> I am sure you know that Henry and I are fundamentally referring to
>>>> nebulous real-world entities such as "You" and "I". A composite key of:
>>>> machine name, user agent name, and a document referrer links != said
>>>> neboulus entity. Even further away in today world of multiple form factor
>>>> devices that interact with the Internet and Web.
>>>>
>>>> There is no precise mechanism for electronically nailing down nebulous
>>>> entity "You" and "I". We aren't of the Internet or Web, so you can apprehend
>>>> us in person. At best you can speculate that we are the subjects of tokens
>>>> comprised of composite keys.
>>>>
>>>> Unlinkability is subject to context fluidity and temporality once you
>>>> add neboulus congnitive entites (not of the Web or Internet) to the
>>>> equation. I believe you know this anyway :-)
>>>
>>>
>>> We cannot say that a URI refers to "you" or "I" in one breathe, and say
>>> it doesn't (or may not) in another.
>>
>>
>> You raise a good point, Now let me clarify, I don't believe (unless in
>> utter error) that I've ever claimed that a URI definitively refers to "You",
>> "Me", or "I". Of course, I cannot claim to have not made the careless
>> utterances such as "Your Personal URI" , for instance.
>>
>> A URI that serves as a WebID has always been a denotation mechanism for a
>> composite key comprised of:
>>
>> 1. private key
>> 2. public key
>> 3. URI that resolves to a profile document that describes a subject via an
>> entity relationship graph.
>>
>> The subject of an X.509 certificate is a nebulous entity. This entity is
>> associated with attribute and value pairs that comprise the profile graph
>> imprinted in said certificate. The semantics of an X.509 certificate don't
>> change the nature of the certificates subject.
>>
>>>
>>> There is a use case which provides a technical requirement here, one
>>> which is simply to not use identifiable information between requests to
>>> different origin servers, and sometimes more granular, not using the same
>>> identifiable information between requests to the same server.
>>>
>>> WebID, just like any auth protocol can be used, it just means using it on
>>> a one time basis, or only for a particular origin.
>>
>>
>> WebID is a part of the picture, not the picture in its entirety. I've
>> pretty much tried to encourage others to be careful about conveying the
>> misconception that WebID (solely) resolves the issues at hand. It is just a
>> critical piece of the puzzle, that's it.
>>
>> You don't need to have a single WebID. Such a thing fails the most mundane
>> alter ego test re. 'Clarke Kent' and 'Superman' or 'Peter Parker' and
>> 'Spiderman'.
>>
>> Privacy is about the aforementioned personas not being comprised, under
>> any circumstances. The fact that DC world entities 'Clark Kent' and
>> 'Superman' used the same Web browser shouldn't comprise the alter ego
>> relationship between these personas.
>>
>> Unlinkability is about the alter ego paradox.
>>
>>>
>>> Personally I feel there are still questions here with WebID, as currently
>>> people use usernames/emails and passwords almost everywhere, and they can
>>> pick different usernames/emails/passwords on every site/origin. Suppose
>>> WebID was to gain 100% adoption overnight, we'd suddenly be in a position
>>> where everybody usually used the same identifier (rather than usernames and
>>> email addresses) and the same key (rather than multiple passwords) - because
>>> we've never been in a world like that, we don't know the consequences yet.
>>
>>
>> See my comments above. Such a system is dead on arrival re. privacy. There
>> have to be multiple WebIDs and the exploitation of logic when dealing with
>> data access policies, and all of this has to occur within specific
>> interaction contexts. For instance, if I want only you to see a document, I
>> could knock up the require security tokens and send them to you via a
>> PKCS#12 file. You open the file then go GET the document in question. Being
>> super paranoid, I would more than likely speak to you via phone about the
>> username and password combo for opening up the PKCS#12 file.
>>>
>>>
>>> Thus, when security and identity experts suggest that we need to handle
>>> unlinkability, or consider that we may often need per origin WebIDs (or even
>>> have that as the default mode), then we may be wise to say "okay", go away
>>> and find our options, then report them back for consideration and review.
>>>
>>> It by no means limits WebID, rather it just makes it applicable to a
>>> broader range of use cases.
>>
>>
>> We need others (note: expert is utterly subjective to me) interested in
>> these matters to be constructive rather than dismissive. I chime in most of
>> the time because I see Henry going to immense pains to explain matters only
>> to be summarily dismissed in manners that I find cognitively dissonant.
>>
>> A basic RDBMS product doesn't depend on single attribute/field primary
>> keys, why would such thinking even apply to the complex matter of privacy.
>> When I use the term composite, I am pretty much referring the the same
>> concept well understood in the RDBMS world. You can have a 'super key'
>> comprised of elements that are of themselves unique identifiers.
>>
>> I don't believe in a single WebID neither does Henry. We just believe that
>> Web-scale verifiable identity is a critical part of the required
>> infrastructure. We also believe that a de-referencable URI (e.g., an HTTP
>> URI) is a very powerful vehicle for this endeavor, even more so when
>> combined with structured data and first-order logic.
>>
>> I only know of one way to deal with context fluidity at the software
>> level, and that's via logic integrated into data which produces self
>> describing data objects .
>
>
> I agree on all counts and feel/think the same,

So do I, more or less (except the last sentence, which I don't think I
really understand, and if I do, seems too sweeping), which surprises
me.

> so I think I'll need to go
> and re-read this thread and see where the confusion is.

Possibly something to do with the fact that of all of Kingley's posts
so far this is the only one I haven't found either incomprehensible or
wrong.

Where we came in was me pointing out that if you disconnect your
identities by using multiple WebIDs, then you have a UI problem, and
since then the aim seems to have been to persuade us that multiple
WebIDs are not needed.

>
> Best, Nathan