Re: future of identifiers

Phillip Hallam-Baker <> Sat, 02 November 2013 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D9D021E80CF for <>; Sat, 2 Nov 2013 09:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.456
X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QS-2F7aT9NNE for <>; Sat, 2 Nov 2013 09:17:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22a]) by (Postfix) with ESMTP id DC89B11E816F for <>; Sat, 2 Nov 2013 09:17:48 -0700 (PDT)
Received: by with SMTP id ea20so4316783lab.1 for <>; Sat, 02 Nov 2013 09:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ee07kMJUl0y3pvuIA9DKIHq77fpCu9L/ynIr6V6bCJs=; b=o6k8IIPiu47JKDwfKoZUm9pXoyfd7BtPjr0azLPeh9XXDcFkPUcEdttHnp5Mnd+Mhs uYc50vqE1iDnlDVFmDo4bWq4r4VPZxx80TIX3HGKJDdUzeM54mKqEhdWD3N+UEKk52mt QzS37PMyZtS1rgm7TeCFF79y7GN8mkP4Euh21ImBIBRaPqBFtl4wVdqDGsx5RHQ07xh8 JX0vEH12fkvXZnIMPt0tBVFy14fgVXUICYoTNh8KmuBerejkTAXN+z7WhdR7dL/BUtk9 bzy09qZDF2lvq9X2QSM8GIukn1Y50lgjvwtSunfROHJ4mKnyZdRCxx9vJXha2IBCMjTJ f8Wg==
MIME-Version: 1.0
X-Received: by with SMTP id h6mr5349225lah.12.1383409057643; Sat, 02 Nov 2013 09:17:37 -0700 (PDT)
Received: by with HTTP; Sat, 2 Nov 2013 09:17:37 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Sat, 02 Nov 2013 12:17:37 -0400
Message-ID: <>
Subject: Re: future of identifiers
From: Phillip Hallam-Baker <>
To: Jari Arkko <>
Content-Type: multipart/alternative; boundary="089e01493d5675c26b04ea3405d4"
Cc: " Discussion" <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 02 Nov 2013 16:17:50 -0000

On Sat, Nov 2, 2013 at 12:13 AM, Jari Arkko <> wrote:

> > it might be a good thing if we were to first identify what needs to be
> identified.
> > ...
> > But seriously, I'd suggest we start from first principles before
> thinking about solutions here. What needs to be identified, and what
> characteristics does it have?
> Agreed, of course. This is a key part of the future I wanted to
> understand. (But not to forget possible evolution of current identifiers or
> their characteristics.)

Everything needs to be identified but the use of the identifier is what
gives it semantics.

Take the following

A) A static document
B) A document that is created dynamically
C) A can of beans
D) A public signature verification key

All can be referred to by a URI form but there are different ways that they
can be referred to. We can refer to a static document by specifying a means
by which it may be retrieved (a URL) or we could specify a digest of the
document which would identify the document uniquely and but not permit
resolution. And of course we can specify the static document by a raw data
string of the document itself.

So these are the basic modalities of data:

1) Raw: The data Itself
2) Descriptor: A description of the data
3) Locator: A description of how the data may be obtained.

[For those into semiotics this is essentially Noth's trichotemy]

A locator can return the data itself or another identifier. So there are
turtles all the way down.

A dynamic document can only be referenced by how to retrieve it or by a
property that it is asserted only the dynamic document will have. For
example, that it will be signed with a particular public key.

A can of beans is interesting in that we can specify the Platonic ideal can
of beans of which this specific can is an example (i.e. the UPC code) or we
can identify one particular can. Which one you want to do depends on the
purpose. If you are buying Heinz Beans imported from the UK in Boston then
the Universal Platonic Code is all you need. If on the other hand you are
tracking down the 6,000 cans of beans recently stollen or a public health
inspector tracking down possibly tainted beans then you care about the
identifier of the specific tin. RFID codes are used to identify specific
tins and that has proved so useful that the RF part of RFID is now an
anachronism, there are RFID barcodes...

[The same is also true of documents but it is not very useful to have an
identifier for 'all PDF documents', instead we consider this to be a
property that a document may have rather than a document]

A can of beans cannot be located by the identifier alone. But if you add
context (e.g. then you can turn the description into a locator.
We can play the same trick with data. The ni identifier scheme does exactly
that, taking a digest of a document and adding in location context to turn
the descriptor into a locator.

[Here there is a picture with a triangle (hey he filched the recycling
logo!) at the corners are Raw -> [Digest] -> Descriptor -> [Context] ->
Locator -> [Protocol] -> Raw

Public signature keys can be identified in the same way as static
documents: by value, by location or by digest. But what makes them very
different is that they are a document that can be used to create
descriptions of other documents.

So for example, imagine that we all establish a personal master key. We
might then use the personal master key to endorse additional temporary keys
for our personal use from time to time.

If I have a digest of someone's personal master key and some location
context, I can obtain a current use key

There is however a subtle issue with public keys, endorsements only flow in
one direction. If A signs B and I trust A then I can make deductions about
B. But if I trust B and not A, the endorsement tells me nothing.