Re: [saag] Liking Linkability

Nathan <> Tue, 23 October 2012 09:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44DCD21F8670 for <>; Tue, 23 Oct 2012 02:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MT2gSNS1Pn1E for <>; Tue, 23 Oct 2012 02:56:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 03C3D21F8659 for <>; Tue, 23 Oct 2012 02:56:56 -0700 (PDT)
Received: by with SMTP id dr13so2049344wgb.13 for <>; Tue, 23 Oct 2012 02:56:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=cYXvRS5FCTPUluZohPZseo8EJYPWzs2IF5gjgJ8kPl0=; b=ICbb7vVhaOh2Uxc3UZrbKOrmRG0FvEkXVSnaLwTuJ5lde8qE2o5obF2xa66t3j1BNO giRj3VXbuaSDM1gbI0lP6qMQ+8+SRNu+g4i7Mchh7/aH620eCdE1OXW6aKKihpwCUbls 07kK8JUyHLPdv7hVKH/KSlRSQmeBiY4faZrCMqRNbgx9miht1qewaeVEoSaPb3GoHEpz iUsYMH5jxnfU58wCZr+zb79W98AcanaiGsS7Ox9RVEoQ3q6A1vJTQ+Zi0lo3RNlGqAlY PB0dMTJKSU7iOb3RWTja6o+rhSWLy2fEzsxMlxlgxVdhkGiQ6T8GtwvC+b2P+i+EMSHz fVAQ==
Received: by with SMTP id f20mr6966587weo.181.1350986216071; Tue, 23 Oct 2012 02:56:56 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id cu1sm55511475wib.6.2012. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 02:56:55 -0700 (PDT)
Message-ID: <>
Date: Tue, 23 Oct 2012 10:56:21 +0100
From: Nathan <>
Organization: webr3
User-Agent: Thunderbird (Windows/20100228)
MIME-Version: 1.0
To: Ben Laurie <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> < m>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnrjTjvyNaIPIq2Eexqupe1FGq7C+P1SvjunEhKGv/HzxdpWszdMl3mtC4mKwqNOLX37/BN
X-Mailman-Approved-At: Tue, 23 Oct 2012 14:09:57 -0700
Cc: Halpin Harry <>,,, " list" <>,
Subject: Re: [saag] Liking Linkability
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Oct 2012 09:56:58 -0000

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. 
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.