Re: what do DIDs identify?

I generally agree with Michael on this point that terms are not used with
precision in any of the work products of the CCG and a look at the way
"good" standards are structured would help. but a DID is a URI (or URL).
The only other piece necessary is a rigorous exposition of the scheme. If
one exists, i have not found it.
Peace ..tom


On Wed, Jan 23, 2019 at 10:27 AM Michael Herman (Parallelspace) <
mwherman@parallelspace.net> wrote:

> 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
>
> W // https://www.cloudcompass.ca
>
> [image: Twitter] <https://twitter.com/scurranC3I>
>
> On Jan 23 2019, at 7:03 am, Michael Herman (Parallelspace) <
> 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
>
>
>
> C:  +1 416 524-7702
>
>
>
>
>
>
>
>
>
>
>
> *From:* Tim Bouma <trbouma@gmail.com>
>
> *Sent:* January 23, 2019 5:51 AM
>
> *To:* Christopher Allen <ChristopherA@lifewithalacrity.com>
>
> *Cc:* 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>
>
> *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> 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
>
>