On Sat, Nov 2, 2013 at 12:13 AM, Jari Arkko <jari.arkko@xxxxxxxxx> 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/