W3C home > Mailing lists > Public > public-credentials@w3.org > December 2017

Re: DID Hardening: Keys

From: Samuel Smith <sam@prosapien.com>
Date: Mon, 11 Dec 2017 08:38:33 -0700
Cc: W3C Credentials CG <public-credentials@w3.org>
Message-Id: <D8E16541-48C8-4A45-AE30-DD80791825FC@prosapien.com>
To: Manu Sporny <msporny@digitalbazaar.com>
I suggest a third alternative.

We treat the DDO as a graph not a tree. This means that we can eat our cake and have it too.

I think on of the source of the problems is that we are confusing MUST with MAY and SHOULD requirements.
If there is consensus that there is one and only one way to do something then its a MUST or if its and essential requirement.
But if there is more than one good way or if it is application specific then its likely better to be a SHOULD


The key material can show up in keys to enable key discovery for version management (an essential security feature)  
The key material has a tightly coupled tuple in a string of key type =  (cryptographic suite, cryptographic operation, version)
The cryptographic suite implies a cryptgraphic strength

The purpose of the key is in another branch of the ddo doc (making it a graph not a tree)
The leaf of this brach is a did fragment ref (so we only add one extra string to the size of the ddo but we free ourselves of the 
arbitrary constraint of tryinf to find the one tree ontology for key purpose.

Now we use SHOULD to define how best to "Purpose" keys for different applications such as authentication, (which is almost always applications specific)


> On 10 Dec 2017, at 12:32 , 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/
> 


Samuel M. Smith Ph.D.   Founder
smith.sam@prosapien.com 
ProSapien LLC
242 East 600 North, Lindon Utah 84042-1662 USA
Office 1.801.768-2769
Mobile 1.801.592.8230
Skype: samuelmsmith
http://www.prosapien.com/ 

NOTICE: This electronic mail message, together with any attachments contains information
that may be copyrighted, confidential, proprietary, and/or legally privileged of and/or by 
ProSapien LLC. This  electronic mail message is intended solely for the use of
the individual or entity originally named as the intended recipient. If you are not the intended
recipient, and have received this message in error, please return immediately this message











Received on Thursday, 14 December 2017 01:34:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:17 UTC