Re: DID Hardening: Keys

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

Received on Sunday, 10 December 2017 19:32:38 UTC