- From: Steven Rowat <steven_rowat@sunshine.net>
- Date: Wed, 23 Jan 2019 12:15:12 -0800
- To: Joe Andrieu <joe@legreq.com>, public-credentials@w3.org
Dear Joe and all, Would it be correct, as an attempt at a simplified (ie, non-technical) explanation, to say: A DID is an encrypted label to be applied to something; this label is a string which can be printed out physically. A DID Document is a collection of text statements conveying attributes about, or leading to, the 'something' that is being labelled by the DID string; this collection of statements can be printed out physically. ? Steven Rowat On 2019-01-23 11:45 am, Joe Andrieu wrote: > 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 <mailto: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 >> <mailto:swcurran@cloudcompass.ca>> >> *Sent:* January 23, 2019 11:05 AM >> *To:* Michael Herman (Parallelspace) <mwherman@parallelspace.net >> <mailto:mwherman@parallelspace.net>> >> *Cc:* Tim Bouma <trbouma@gmail.com <mailto:trbouma@gmail.com>>; >> 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>>; Christopher Allen >> <ChristopherA@lifewithalacrity.com >> <mailto: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 <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 >> <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.com <mailto:joe@legreq.com> > LEGENDARY REQUIREMENTS > +1(805)705-8651 > Do what matters. http://legreq.com <http://www.legendaryrequirements.com> > >
Received on Wednesday, 23 January 2019 20:15:40 UTC