Re: DID Hardening: Keys

> 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 | LearningMachine.com