Re: what do DIDs identify?

Thanks Chris,

Your response clarifies and justifies the rationale of a DID beyond that of
the CID.

Putting in my own words:

In addition to the properties of a CID that we discussed, a DID is BOTH ii)
MATHEMATICALLY verifiable AND INDEPENDENTLY verifiable.

When I say INDEPENDENTLY verifiable, I mean independently of the DID
itself. This is achieved by means of a reference/proof originating from
outside the DID , mostly likely from a merkle-proof baked into a block of a
blockchain. Just as the blockchain scheme solved the double-spend problem,
a DID, once registered, solves, what I call the time-travel-problem. With
this property, you cannot pretend the DID came from, or was used during, an
earlier point in time.

Stating this a little bit differently: A digital asset/identifier _cannot_
by itself prove its existence at a particular point-in-time, without an
independent/external reference pointing to it. From this essential
difference of a DID from a CID, (proof of existence at a particular point
in time) we can then build out all those other state change pieces, such as
revocation.

Summing up the case: a DID _is_ essentially different from a CID: a DID,
additionally, has a proof of existence (or state) independent of the DID
itself. This additional property enables you to address the Wright-Satoshi
problem. For me, case has been made why a DID is different/better than a
CID (DID wins the case!)

In closing, I still maintain that the absolute minimalist DID could still
be just an ephemeral/disposable CID, as I described in my earlier email.
But the CID, to become a proper DID, must self-sign a registration
somewhere that likely ends up as part of a merkle proof on a blockchain to
prove it came into existence at a particular point in time. No DDO is
actually required for this minimalist scheme. Upon reflection, this  scheme
would just become another registered DID method.

Tim









On Wed, 23 Jan 2019 at 02:02, Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

>
>
> 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
>
>

-- 
Find me at: http://about.me/tim.bouma