Re: [saag] Liking Linkability

Henry Story <henry.story@bblfish.net> Tue, 23 October 2012 10:15 UTC

Return-Path: <henry.story@bblfish.net>
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 2A00821F8654 for <saag@ietfa.amsl.com>; Tue, 23 Oct 2012 03:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.94
X-Spam-Level:
X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
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 Rhqc9R-RWvnu for <saag@ietfa.amsl.com>; Tue, 23 Oct 2012 03:15:23 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1CD621F8620 for <saag@ietf.org>; Tue, 23 Oct 2012 03:15:22 -0700 (PDT)
Received: by mail-bk0-f44.google.com with SMTP id jc3so1279431bkc.31 for <saag@ietf.org>; Tue, 23 Oct 2012 03:15:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=9eb0rpx8NVtXXONLy3/Wf0wufmOXO9JoqSPMQSik5TU=; b=HPNiqMoWJiNUEwws0evDCaFJvEjk5bE7qmKiePf+KbQVInqxWxVNNE2z1GC1ManxiZ OEhlzz9uR5UlQr7M7JZEzkhqa5XcooNdOkrAMwzBspjVLaTkjOX3VjXzcn8CvmwEx+cd prMxfYQ/g+YtROtv2+6POrnejI2Rlwh9rH31QpbI0FrZ/xJ27Bw3nUcI0a7kL080bOJx FNmlO6YX5XIiUlDnWd+SJsJrSA07g5Y5SQMGnNwEm9xZNQu9w54EAA6jJXYEUlQeO6jU 1oLmzTiR3/XRqSuTEqmxnoOuxXk1l9jppXka2Ebe8IhNToPde0TgmHy4YyyoHend+s6Y V9GA==
Received: by 10.205.135.20 with SMTP id ie20mr3615409bkc.16.1350987321436; Tue, 23 Oct 2012 03:15:21 -0700 (PDT)
Received: from bblfish.home (AAubervilliers-651-1-132-122.w86-198.abo.wanadoo.fr. [86.198.99.122]) by mx.google.com with ESMTPS id ht18sm5277984bkc.14.2012.10.23.03.14.51 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 03:15:17 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_4D66E970-5676-43C8-9B12-0983F407E87A"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <508669C5.90400@webr3.org>
Date: Tue, 23 Oct 2012 12:14:49 +0200
Message-Id: <028CAB40-4F6E-41DD-99C5-E474DF3B7A53@bblfish.net>
References: <CCA5E789.2083A%Josh.Howlett@ja.net> <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> <CABrd9SRNVLbWxifQAQ6iuX4qMeFmZVD6rO_q=L348G1UZzr9tg@mail.gmail.com> <50852726.9030102@openlinksw.com> <CABrd9SQ3KTqHq1hOfbLAU5hfgNyqCPK4u+ToEda+VtQ5S0utwA@mail.gmail.com> <5085360E.3080008@openlinksw.com> <50853CD8.8020005@w3.org> <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net> <508562C2.1060905@w3.org> <F7EA147A-8A49-4627-8AA0-DD811CB9AC49@bblfish.net> <CAG5KPzx673VKqg4=26-cvfeXZrBfK-XbURFj8eYx_mXVkko41A@mail.gmail.co m> <508669C5.90400@webr3.org>
To: nathan@webr3.org
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkU1iFjC1H+bt7j25Hb8PpfrERq3zWZj54IvD7ZIrH5xBpJPTCAziv/2RPAllhjEDxgN4iv
Cc: Halpin Harry <H.halplin@ed.ac.uk>, public-identity@w3.org, saag@ietf.org, "public-privacy@w3.org list" <public-privacy@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: Tue, 23 Oct 2012 10:15:24 -0000

On 23 Oct 2012, at 11:56, Nathan <nathan@webr3.org> wrote:

> Ben Laurie wrote:
>> b) Linkability it not, as you say, inherently bad. The problem occurs
>> when you have (effectively) no choice about linkability.
> 
> .. and when people convey or infer that there is no choice about linkability, when there really is scope to be as unlinkable as one likes within WebID.
> 
> Quite convinced now that the confusion is just differing objectives and opinions, and nothing technical.
> 
> You can have one or more WebIDs to cover any combination of one or more requests to one or more resources. Be as linkable or unlinkable as you like.
> 
> On the other hand, WebID the idea (rather than the technical protocol) has been created within a context where linkability is desired, indeed it's creation was to enable and promote increased linkability - so applying it to situations where unlinkability is desired goes against the grain, or clashes with individual's general mental model of it.
> 
> In it's simplest form, WebID is just a way to establish an identifier for an agent layered on to the usual client cert auth. This allows:
> - WebID to be used anywhere HTTP+TLS can be used
> - Crucially, identifiers to be used that refer to resources anywhere on the web which can be interacted with in order to find out more about the agent identified. Without relying on fixed API features, multiple protocols and layers, out of band knowledge, or limited functionality by using non dereferencable identifiers.
> 
> So if wikileaks want to generate a cert with an identifier only they can view and which is completely unlinkable, for a one time use, they can.

yes, but they had better use some other technology such as TLS-Origin-Bound Certificates
then. http://tools.ietf.org/agenda/81/slides/tls-1.pdf
I am not even sure that is a good idea. Strong username passwords may still be a lot better there, and suggesting strongly the user remember it by heart.

> If a bank wants to issue a series of certs to a client which has some stable identifier in them for the client, they can. If facebook want to issue certs which have identifiers which deref to a machine/human readable version of the users profile, and allow people to use their facebook id on any site, they can. If a single person wants to handle their own identity and profile, they can. If services like AWS want to issue keys to machine agents, they can. And critically, they'd all be interoperable from a technical view, with limits to which identifiers and keys and as to which information is visible and what can be used where added on by ACL and usage restrictions.
> 
> It's quite simple really, client cert auth over TLS is well established, and HTTP(s) URIs allow dereferencing to anything on the web, with the possibility of any features you find anywhere on the web.
> 
> Seems far more logical and simpler than creating a plethora of custom protocols which rely on layer upon layer of techs and protocols in order to try and make non dereferencable identifiers dereferencable, or to try and provide more information about an identified agent via a suite of API extensions that need implemented by all adopters, or to come up with something new which has most of the same negative sides, and requires web scale adoption in order to work everywhere WebID already can.
> 
> Best,
> 
> Nathan

+1 :-)

Social Web Architect
http://bblfish.net/