Re: future of identifiers

[Phillip Hallam-Baker <[e-mail]>]

On Sat, Nov 2, 2013 at 12:13 AM, Jari Arkko <[e-mail]> 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. Amazon.com) 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.

-- 
Website: http://hallambaker.com/