Re: what do DIDs identify?

We definitely have problems with the rigor in the document. For a bit of
grace, please note that this is not yet even standards-track. What we
are working through are the earliest stages of a draft document that
attempts to capture the work of dozens of people over a period of years.
It is an input into the DID working group charter process. It'll be
useful to push through as many of these types of issues as possible.
Pull requests will be considered.
To be clear, the DID is NOT an alias or nickname for anything. It is
an acronym of Decentralized Identifier, which is a URL (and a URI).
That URL is a string and it has an ABNF in the spec. Personally, I
think the ABNF is incorrect--it's odd to me that a DID-Reference is
not a DID. That isn't how URLs are treated, so its odd that we would
structure it that way.
However, the DID specification has no notion of--nor, IMO, any need for--
a DID Entity or DID Object. The specification defines how a DID URL
encodes specific information. That URL can be used to do a bunch of
things. Some pieces of software will deserialize that DID into an
internal representation--which Michael calls a DID Entity. That
deserialized representation is not part of the spec, just like that
deserialization of a URL is not part of the spec. At most, those
representations are functions of the library used to use the DID to do
work and will absolutely vary dependent on the language and design
choices of the implementers.
It is correct to say that a DID does not, on its own, *do* anything
other than provide the information needed to resolve the DID to a DID
Document, just as a URL doesn't *do* anything except provide the
information needed to resolve the resource it refers to.
When someone says "a DID is BOTH ii) MATHEMATICALLY verifiable AND
INDEPENDENTLY verifiable." It is not a statement that the text string of
the DID self verifies. It says that the DID provides the information to
be verified mathematically--using math specified in the DID method--and
procedurally (independent of the math)--using a process defined by the
DID's method.
Tom, have you seen the ABNF of the DID? It exists, although, thanks to
Michael's review, its clear that it needs some help, at a minimum in the
prose description of it, perhaps in the definition itself if we want it
to be more like a URL and less like a weird new thing.
-j

On Wed, Jan 23, 2019, at 11:18 AM, Tom Jones wrote:
> 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____


>> Twitter____


>> 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[1]) 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[2]____


>>> __ __


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



--
Joe Andrieu, PMP
joe@legreq.comLEGENDARY REQUIREMENTS
+1(805)705-8651Do what matters.
http://legreq.com[3]


Links:

  1. https://hyperonomy.com/2018/12/18/definition-confuding/
  2. http://hyperonomy.com/
  3. http://www.legendaryrequirements.com