Re: DID Hardening: Keys

Sam, thanks for articulating this so clearly. I recall this is the
suggestion you made at the end of the last DID Spec Closure meeting, and in
fact it matches a core pattern in XDI designed for exactly that purpose
(referencing the same ultimate graph node via multiple ontologies).

So I'm open to it, and it does provide an example of how to bridge the two
worldviews we've been discussing.

Talk to you on the call tomorrow.

=Drummond

On Mon, Dec 11, 2017 at 10:38 AM, Samuel Smith <sam@prosapien.com> wrote:

> 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
> <https://maps.google.com/?q=242+East+600+North,+Lindon+Utah+84042&entry=gmail&source=g>-1662
> USA
> Office 1.801.768-2769 <(801)%20768-2769>
> Mobile 1.801.592.8230 <(801)%20592-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
>
>
>
>
>
>
>
>
>
>
>