- From: Michael Herman (Parallelspace) <mwherman@parallelspace.net>
- Date: Wed, 23 Jan 2019 20:31:43 +0000
- To: Joe Andrieu <joe@legreq.com>, "public-credentials@w3.org" <public-credentials@w3.org>
- Message-ID: <MWHPR13MB1277E13BBEE6841483F7324DC3990@MWHPR13MB1277.namprd13.prod.outlook.com>
I suggest we need to take more of a top-down approach to this discussion – otherwise I think we’ll end up going in circles discussing the nitty-gritty of the details. To support this goal, I’ve created the following issues in the https://github.com/w3c-ccg/did-spec/issues/ repo: 1. https://github.com/w3c-ccg/did-spec/issues/157 Draft DID spec purpose and target audience 2. https://github.com/w3c-ccg/did-spec/issues/158 Normative, Informative (and in-scope) and just plain out of scope? 3. https://github.com/w3c-ccg/did-spec/issues/151 Missing Decentralized Identifiers Data Model 4. https://github.com/w3c-ccg/did-spec/issues/155 URIs, URLs, and URNs section of draft DID spec Questions * What is the best way to discuss these initial issues? * Do others think these initial issues are important and should be prioritized? * Do people need to see specific PRs first or can the discussion be issues driven? 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: Joe Andrieu <joe@legreq.com> Sent: January 23, 2019 12:45 PM To: public-credentials@w3.org Subject: 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<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 [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 -- 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:32:10 UTC