Re: what do DIDs identify?

On Tue, Jan 22, 2019 at 7:37 PM Tim Bouma <trbouma@gmail.com> wrote:

> Reflecting on the essence of a DID
>
> Please see this paper titled: A practicable approach towards secure
> key-based routing (2008) - I got this reference from an IPFS paper (Juan
> Benet)
>
> https://drive.google.com/open?id=1EXrWYhsK1awHQLibKs21oByklGRfDX18
>
> …
>
> Anyway, some thoughts for consideration,
>

Way back when, when I was architecting what would become DIDs with Drummond
at OASIS, the original version was very much a cryptographic identifier,
which we called a CID. However, we became really concerned about various
effects of compromise of the private key material.

Knowing when a CID was created (i.e. time-stamping it) turned out to be
useful, and being able to have a subsequent timestamp revoke it was as
well.  This was very easy on bitcoin (thus the origin of BTCR method,
though that was really inspired of my revoke-SSL project which uses Bitcoin
as an alternative way to revoke SSL/TLS/SSH certificates
https://github.com/ChristopherA/revocable-self-signed-tls-certificates-hack
-- revocation actually came first!). The CID there was the private key, and
publishing a signed transaction with it was the revocation.

These prototypes ultimately led to my push toward non-cryptographic UUIDs
that could be linked to hard cryptographic keys, but the problem with a
UUID is that someone could see your UUID and claim that they had it first.
For instance this happened when Craig Wright made some false claims that
his PGP keys demonstrated that he was Satoshi. Having timestamps on UUIDs
solved this problem, and along with a linked key and ordering, could still
do revocation.

Thus ability to do revocation became a critical part of the DID
architecture that emerged. Once you have time-stamping & ordering of UUIDs
and ability to link to at least one key, you can do revocation. Once you
can do revocation, rotation became possible.

The simplest blockchain, bitcoin, allowed for 40 bytes of data, which led
to using it for a short URL or IPFS hash to allow more keys to be listed
(other blockchains could do more). That lead to the DID document, which
allows even more capabilities.

At this point I'm really reluctant to go back to bare CIDs and call them
DIDs. The ability to have a time-stamp and thus order, revoke, and update
doesn't absolutely require a blockchain (you could probably do it with
another immutable replicated database or something like Certificate
Transparency-like architecture) makes me reluctant to call a CID anything
but a degenerate form of DID, and possibly should be strong discouraged if
not disallowed in the standard.

-- Christopher Allen