RE: what do DIDs identify?

Stephen, this is the root of the confusion …you’re using “DID” as a nickname or alias for the “DID Entity” / “DID Object” thing …or whatever we want to call it.

But a DID is a “decentralized identifier”,  the “string” thing.  This ambiguity creates confudsion.

IMHO, these two concepts need to be separable and clear from an everyday terminology perspective.

Best regards,
Michael

From: Stephen Curran <swcurran@cloudcompass.ca>
Sent: January 23, 2019 11:05 AM
To: Michael Herman (Parallelspace) <mwherman@parallelspace.net>
Cc: Tim Bouma <trbouma@gmail.com>; Adrian Gropper <agropper@healthurl.com>; Emmanuel Forche <forchee@hastlabs.com>; Markus Sabadello <markus@danubetech.com>; Daniel Hardman <daniel.hardman@evernym.com>; Joe Andrieu <joe@legreq.com>; Credentials Community Group <public-credentials@w3.org>; Christopher Allen <ChristopherA@lifewithalacrity.com>
Subject: Re: what do DIDs identify?

IMHO This statement is not correct "A DID (a decentralized identifier) doesn’t, by itself, have any of these capabilities and can’t have any of these capabilities."  If it doesn't have the referenced capabilities it's at most a UUID (or a string), not a DID and wouldn't be called a DID. It's unnecessary to add a modifier to the term DID to imply those capabilities.

Stephen Curran
Principal, Cloud Compass Computing, Inc.
P // 250-857-1096<tel:250-857-1096>
W // https://www.cloudcompass.ca

[Twitter]<https://twitter.com/scurranC3I>

On Jan 23 2019, at 7:03 am, Michael Herman (Parallelspace) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>> wrote:
RE: a DID is BOTH ii) MATHEMATICALLY verifiable AND INDEPENDENTLY verifiable.



Tim, this type language is very confusing (confuding<https://hyperonomy.com/2018/12/18/definition-confuding/>) to anyone trying to understand Indy and/or the draft DID spec. This statement is an example of the same terminology issue we talked about before (I think was the original reason for this thread): A DID (a decentralized identifier) doesn’t, by itself, have any of these capabilities and can’t have any of these capabilities.



Only a “DID Entity” or “DID Object” (the entity that results from deserializing a DID Document) can have these capabilities, n’est pas?  How can we fix this terminology? … and our usage of it?



Best regards,

Michael Herman (Toronto/Calgary/Seattle)

Independent Blockchain Developer

Hyperonomy Business Blockchain / Parallelspace Corporation



W: http://hyperonomy.com<http://hyperonomy.com/>

C:  +1 416 524-7702





From: Tim Bouma <trbouma@gmail.com<mailto:trbouma@gmail.com>>
Sent: January 23, 2019 5:51 AM
To: Christopher Allen <ChristopherA@lifewithalacrity.com<mailto:ChristopherA@lifewithalacrity.com>>
Cc: Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>; Emmanuel Forche <forchee@hastlabs.com<mailto:forchee@hastlabs.com>>; Markus Sabadello <markus@danubetech.com<mailto:markus@danubetech.com>>; Daniel Hardman <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>>; Joe Andrieu <joe@legreq.com<mailto:joe@legreq.com>>; Credentials Community Group <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: 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<mailto:ChristopherA@lifewithalacrity.com>> wrote:



On Tue, Jan 22, 2019 at 7:37 PM Tim Bouma <trbouma@gmail.com<mailto: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