- From: =Drummond Reed <drummond.reed@evernym.com>
- Date: Sun, 10 Dec 2017 18:05:22 -0500
- To: Kim Hamilton Duffy <kim@learningmachine.com>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <CAAjunnbAMw9Q34aEuKFrDNanQwmzyCkejOYViN2Dvx0cHGvrBw@mail.gmail.com>
I have been tied up in NYC the past few days, so I'm just joining this thread. Having read it, let me restate why the DID spec hardening proposal proposes *a very simple flat array of fully-qualified key descriptions*. In fact the dialog between Manu and Kim in this thread is a good illustration of our rationale for taking this approach. Our contention is simply that there is no single RDF ontology—or any single ontology—that can describe all the potential combinations of key algorithms, strengths/lengths, encodings, purposes, and contexts that will may be needed to correctly select the right key in an DID document. Even more so because one of the primary usages of DID documents will be t*o continue to describe the keys associated with a DID over time*—potentially for very long periods of time (years, decades, centuries). So the solution we recommended was to *move 100% of this problem to a key description specification that is identified with a single URI*—and then use this URI (or the JSON-LD context name for it) as the value of the *keys/type* property. To be clear, this means the proposed semantics of key description in a DID document would a very simple graph of relationships as follows: - *id* property (value = DID) <== identifies the subject of the DID document - *keys* property (value = array of key description objects) <== describes that the subject of the DID document *owns/controls this set of keys* - key description object properties - *id* property (value = DID fragment) <== uniquely identifies this key description object within the DID document - *type* property (value = URI or JSON-LD name corresponding to a URI) <== uniquely identifies this key type as defined by the associated key description specification - *value* property (value = encoding of key as defined by key description spec) <== leaf node Let me stress again that the purpose of the URI (or JSON-LD name) that is the value of the *keys/type* property is to identify all the properties of a particular key that are needed to select that key as the right key for a calling application to use in a particular context for a particular purpose. I recognize that this approach to key description does not match the way some other key description schemas or ontologies work (such as Linked Data Signatures). Those schemas or ontologies break out the various aspects/traits/qualities/attributes of key management into separate properties. And that approach is fine for those particular contexts where those forms of key description will be consumed. But I contend what we need in DID documents is a very simple and universal form of key description that can be used across all systems, apps, graph models, and ontologies that need keys. And to make it universal, this simple form "flattens" key description into two properties: 1. The id property to uniquely *identify* the key both in the DID document and globally (because DIDs are globally unique). 2. The type property to uniquely *describe* all properties of the key needed to select it (algorithm, strength/length, encoding, purpose/usage/context, etc.) In summary, this solution has four advantages: 1. *Universality*. There is no key selection problem that cannot be solved using this approach because 100% of the properties or relationships of the key to the DID subject can be expressed using a key description specification that has one unique URI. 2. *Format and ontology independence.* Key description or selection is not (and will never be) dependent on any particular ontology. 3. *Extensibility.* Key descriptions can continue to be infinitely extended and evolved by publishing new key description specifications. 4. *Security.* Since the security properties of a particular key type are precisely defined by the key type URI, a developer only needs to know that key type URI (which is specified in the key description spec) in order to select a key of the right type. Point #4 is ironic because in this discussion it keeps being asserted that additional key description properties are necessary to guide developers to know which key to use so they don't make security mistakes. But at the same time we also keep hearing that many developer do not understand the right combinations of key properties to use. So adding additional key description properties explicitly—within the DID document itself—would appear to *worsen security*. The proposed solution makes it easier for developers to choose the right key by collapsing all relevant facets of key description into a single type property that the developer needs to match. And if the W3C Credentials Community Group (and/or another groups like DIF) publish the set of key description specs that cover the most-commonly-used key types—*combinations that already encapsulate the best practices the community has learned*—then these URIs (or JSON-LD property names) will become very well known and easy to identify in any DID document. One final point: lest any particular camp representing a specific ontology (such as Linked Data Signatures) worry that this solution does not support their format or will not be compatible with extended RDF graphs that include many other properties of a DID, the existence of a key description spec for every key description object in a DID document means that you can unambiguously transform from a simple DID document to a "native" RDF description of that particular key *and back again*. So while the simple DID document format may not be quite as attractive as a native RDF graph version of the same properties, it still works. And it can co-exist with every other graph model and ontology format that needs to consume or represent DID documents. =Drummond On Sun, Dec 10, 2017 at 2:42 PM, Kim Hamilton Duffy <kim@learningmachine.com > wrote: > > Yes, exactly. Chris, myself, DaveL, and MarkM are going to dive into the > capabilities stuff over the next month or two to try to figure out a > minimum set that we may be able to put into the DID spec (or a way of > mapping non-ocap stuff to ocap stuff via the DID data model). > > Excellent. I'm not sure if this will fly with the DID hardening crowd, but > I would prefer if we could revisit the keys discussion after we've made > progress on capabilities. I think this will let us better decide how to > express keys in the context of the DID spec. > > On Sun, Dec 10, 2017 at 11:34 AM Manu Sporny <msporny@digitalbazaar.com> > wrote: > >> On 12/09/2017 11:04 PM, Kim Hamilton Duffy wrote: >> > These same factors may also lead to a different conclusion: that, >> > for at least this iteration of the DID specification, keys remain >> > purposeless, and purpose/application are defined at the method spec >> > level or elsewhere. >> >> We could take that route, but then we're left with a DID specification >> that's only really capable of doing one thing: >> >> Listing services associated with a DID >> >> ... and that's not very exciting. Even worse, it leaves every ledger to >> create their own bespoke implementation. >> >> We wanted to provide capabilities to do authentication (both for log in >> purposes and for issuing purposes), but we can't even do that in a >> standardized way if we don't put it in the DID spec. >> >> Part of the reason we have standards is to make the appropriate >> trade-offs. >> >> We're struggling with at least these immediate questions right now: >> >> 1. How do I cryptographically prove that I am in control of a DID? >> 2. How do I cryptographically verify that a DID issued a particular >> Verifiable Credential? >> 3. How do I discover services associated with a DID? >> >> The rest, such as how a ledger expresses how one can update the DID >> document, has been punted to the linked data capabilities stuff. >> >> > It seems that introducing either purpose (authorization, issuing) or >> > application is treading into capabilities, which we've decided >> > we're not yet ready to include at the DID spec level. >> >> Maybe, but not necessarily. We know that only some ledgers are going to >> support capabilities, so what do the other ledgers going to do? How do >> they express authn or issuing? We can't really avoid this discussion as >> it's pretty critical to making DIDs useful. >> >> > So at minimum, we'd have to ensure we're not carving up the space in >> > ways we'll regret (because they are harder to maintain, compose, >> > etc.) >> >> Yes, exactly. Chris, myself, DaveL, and MarkM are going to dive into the >> capabilities stuff over the next month or two to try to figure out a >> minimum set that we may be able to put into the DID spec (or a way of >> mapping non-ocap stuff to ocap stuff via the DID data model). >> >> > To argue with myself, I agree with your points about confusion to >> > implementors. And perhaps this makes the DID spec pretty useless on >> > its own (without method specs). However, a counter-argument might be >> > that that introducing an incomplete concept of purpose confuses >> > things even more for implementors. >> >> Yep, not saying we shouldn't be very careful here. >> >> ... but to put it another way, no one is going to support or fund a DID >> spec that doesn't do at least authn. >> >> > Perhaps that's too extreme -- should the DID spec, at minimum, allow >> > a way to describe operations on the DID / DID document itself? >> >> That's authorization, not authn/issuing. That's a harder problem to >> address than authn, isn't it? ... and you're in the same quandry... you >> have to specify something that works for both ocap and non-ocap worlds. >> >> In any case, good points, finding the balance isn't going to be easy >> (but that's what standards making is about). I think making more >> progress on the ocap stuff may give us some more insight on the right >> path forward. >> >> -- manu >> >> -- >> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >> Founder/CEO - Digital Bazaar, Inc. >> blog: The State of W3C Web Payments in 2017 >> http://manu.sporny.org/2017/w3c-web-payments/ >> >> -- > Kim Hamilton Duffy > CTO & Principal Architect Learning Machine > Co-chair W3C Credentials Community Group > 400 Main Street Building E19-732, Cambridge, MA 02139 > > kim@learningmachine.com | kimhd@mit.edu > 425-652-0150 <(425)%20652-0150> | LearningMachine.com >
Received on Sunday, 10 December 2017 23:05:56 UTC