Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

Tom Herbert <> Wed, 04 October 2017 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC9381326F6 for <>; Wed, 4 Oct 2017 09:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2riHRNz79ylO for <>; Wed, 4 Oct 2017 09:17:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1EE15126D0C for <>; Wed, 4 Oct 2017 09:17:40 -0700 (PDT)
Received: by with SMTP id r64so11738416qkc.1 for <>; Wed, 04 Oct 2017 09:17:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JCoFWHe6tWZtmgqtr6OIHam0XGxpdFgFeDvhbxYqI7s=; b=c9BCyT6RQLZIH/YIFeFNhIO2fA+sqDcvkMW5+9uv9FILqY/cXoWRLx5pIn1ptWLyRo weq6vvI6FJTHwklRtY7M1sUiP32NvGBep0lGRj9TvA9bOohXIHNaXJQnnmgtT09F8o1R GcP79+YsWMe4tmSNHg7qY6lqE6rgN1BxmnnxwOhyqNnMSvANFf8dyo7izwJs37xj8iXu /Gqln7bH/3SQ81xaRxjym02fhLQvrtqFlo0yWAbTmehISaM8jrxeQzd4bI41IxmOQqge tPrQF8O6HnOkUYuiUZnX4FShA4/ZXVImDpP8kUeGFJ5vjakrmF00Imm//82JU+/V/se/ 8W5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JCoFWHe6tWZtmgqtr6OIHam0XGxpdFgFeDvhbxYqI7s=; b=ulT4H5zmdLYyaQHOVqa9pQd/XnLDWZpBJ78FPcRwKjIS7mH/aUk8v3Bk3x5IvRB3CH XYclVfnD/FdvSzh0F28jY/zLOiCVaUSE33EROkcSawVbNoMkGkDM/VOiMkDhjx84gIVX rxeB+DuVRKVnn/xExXSUwCNn/tsa/YIUR7jhpvJTveFjzTeqRFy84X/zabknhpO6RZaD x7tX2iaqcQq0S/7PY1SYr2QT33q9SFO/nqSEYM0ZYh7rXb2Er4a+N1aAJjkXBOoxThch Xe/E9mEhg5G/flxkGeuSAgKpg3whLyZbg2UpmSNbVKZB6kUrlZLpkof/7tzXbCooS81P 6aFw==
X-Gm-Message-State: AMCzsaXmIcsw9VmIYt58k4OTVNYZR9Ghz568VoE9zDuXI2eag8Y+ftZv ARpBOuEW2JHpN3QwTrl47L8gAcHFb3ZQwOTSNkmpqnVC
X-Google-Smtp-Source: AOwi7QA3NMQVB7dgmH2TaC+ZNKkWvUzyj7+4dWPx+CN23HU4KRlz59xBb2l6zr3rjDrQMBYh3z8QHfslYwtlg9+foPc=
X-Received: by with SMTP id i125mr24464257qkc.17.1507133859037; Wed, 04 Oct 2017 09:17:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 4 Oct 2017 09:17:38 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Tom Herbert <>
Date: Wed, 4 Oct 2017 09:17:38 -0700
Message-ID: <>
To: Phillip Hallam-Baker <>
Cc: Stephen Farrell <>,, IETF-Discussion <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Oct 2017 16:17:43 -0000

On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker
<> wrote:
> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell <>
> wrote:
>> As currently described, I oppose creation of this working
>> group on the basis that it enables and seemingly encourages
>> embedding identifiers for humans as addresses. Doing so
>> would have significant privacy downsides, would enable
>> new methods for censorship and discrimination, and could
>> be very hard to mitigate should one wish to help protect
>> people's privacy, as I think is current IETF policy.
>> If the work precluded the use of any identifiers that
>> strongly map to humans then I'd be ok with it being done
>> as it'd then only be a waste of resources. But I don't
>> know how that could be enforced so I think it'd be better
>> to just not do this work at all.
>> S.
> +1
> I know how to restrict the work to 'meaningless' identifiers, require that
> the identifiers be the output of a cryptographic algorithm.
> Now strictly speaking, this only limits scope to identifiers that are
> indexical as opposed to rendering them meaningless but I think that was the
> sense of it.
> Nöth proposed a trichotemy of identifiers as follows
> * Identity, the signifier is the signified (e.g. data: URI)
> * Indexical, the signifier is related to the signified by a systematic
> relationship, (e.g. ni URIs, SHA256Data), PGP fingerprints etc.)
> * Names,  the signifier is the related to the signified by a purely
> conventional relationship, (e.g. to its owner)
> There is a big difference between attempting to manage indexical signifiers
> and names. Especially when the people trying to do so refuse to read any of
> the literature on semiotics.
> Names are problematic because the only way that a conventional relationship
> can be implemented is through some sort of registration infrastructure and
> we already have one of those and the industry that manages it has a
> marketcap in the tens of billions.
> Identifiers do lead to tractable solutions. But, this proposal looks a bit
> unfocused for IRTF consideration, an IETF WG? Really?
Identifiers are equivalent to addresses in that they indicate a node
in the network for the purposes of end to end communications. The only
difference between identifiers and addresses is that identifiers are
not topological. Virtual addresses in network virtualization are also
identifiers. So the security properties are the same when considering
privacy. For instance, if applications use temporary addresses for
privacy, it would have equivalent properties using temporary
identifiers. In fact from the application POV this would be
transparent. It could get a pool of apparently random addresses to
choose from as source of communication, it shouldn't know or even care
if the addresses are identifiers.

Identity is a completely separate concept from identifiers. Is not
required in any of the identifier/locator protocols and AFAIK none of
them even mention the term. There is no association of an identity of
user behind and identifier any more than there is an association of
identity behind IP address. The fact that the words "identifier" and
"identity" share a common prefix is an unfortunate happenstance :-).