Re: DID Hardening: Keys

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
>