Re: DID Key Management Harmonization Proposal #1

On 01/10/2018 05:02 PM, Steven Rowat wrote:
> This seemed logical and interesting.

I have some fairly strong reservations about the proposal as it falls
into the same "Bag of X" standardization anti-pattern that I mentioned
previously. Please also see the response to Christian as better
alternatives are outlined there.

> Then when thinking about it I envisioned a use case for a local 
> problem that I'd already been thinking about. Then I realized I 
> didn't really understand how the 'DID Method' part of this would 
> work, including Sam's suggestion.

A DID Method is a way of providing the functionality needed by the DID
Specification. For example, the "Bitcoin BTCR DID Method" is a
specification that defines how the basic DID operations for Create,
Read, Update, Deactivate work by using the Bitcoin ledger as the
technical foundation.

> Am I correct in the following beliefs:
> 
> 1. Each person in this system -- all 10 donors and all 50 
> single-parent recipients -- would have their own DID Document that 
> defines their identity for ledger purposes. So there would be 60 
> separate DID Documents.

Yes, correct.

> 2. If an appropriate ledger is written for the system to work (ie, to
> handle banking information and government credentials), it will 
> require its own DID Method in order to interact with the DID 
> Documents.

Yup.

> 3. Sam's suggestion implies that each DID Document will be modified 
> to contain DID Method files in a folder at root level.

Hmm, kinda, but not really.

Each DID Document would be modified to contain one DID Method-specific
property at the root level. For example:

{
  ... this is the DID Document
  "xyzDidMethod": {
    ... all DID Method-specific properties go here
  }
}

Where "xyzDidMethod" would be something like "uport" or "sov" or any
other DID Method name, where the registry for valid DID Method names is
here:

https://htmlpreview.github.io/?https://github.com/w3c-ccg/did-spec/blob/a72068fb963c6d57f89ce44656e735de7304b730/did-methods.html

The problem here is that pure JSON developers may start using terms like
"issuer" and "credential" and "type" in ways that conflict with the
basic data model and that would immediately create incompatability
across the entire ecosystem of DID Methods.

That's why I propose that we prefix all DID Method-specific properties
w/ the DID method. So, "uportIssuer" instead of "issuer". Terminology
conflicts lead to very nasty security vulnerabilities.

> 4. Will this placing of the DID Method files *only* happen on the fly
> during transactions? Or will the DID Documents be modified in 
> advance, and the DID Method files will sit permanently inside the
> DID Document?

There is no such thing as a DID Method file. There are only DID
Documents and what they contain. These changes will not be "on the fly
during transactions", but rather the data will sit permanently in the
DID Document.

> 5. In either case, does the need for the DID Method files inside the 
> DID Document  imply that a person's DID Document will need permanent 
> changes for all the other ledgers it might encounter on the Internet,
> such as Evernym, Sovrin, Bitcoin, and eventually hundreds of others?

DID Documents are not portable between ledgers at present. There are
parts of DID Documents that are processable using generalized libraries
(that's one of the primary goals we're trying to accomplish).

So, if you want to authenticate using information in a DID Document,
there are common ways to do it across multiple ledgers.

> 6. If so, does each of those have its own folder at the root level of
> the DID Document, or (in Sam's suggestion at least) are all of the
> placed as child folders inside the DID Method folder (the one Sam 
> says is not standardized)?

Every time you create a field that is not a part of a standard you
create an interoperability problem for the ledger. That is, it's a
feature that your ledger (and only your ledger) supports. While there
are good reasons to do that, it also means that you are creating an
interoperability burden for everyone else who will then need to
standardize the feature later on if it catches on. At that point all the
code that has to be rewritten to understand the old way of doing things
and the new standardized way of doing things, which means added
complexity and opportunity for bugs to surface.

The better approach is to try and standardize /something/ first, and if
you fail, only then do a DID Method specific extension. Unfortunately,
many developers have a tendency to just forge ahead, get lots of
adoption, and then standardize whatever shakes out. There are merits and
drawbacks to that approach.

-- 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/

Received on Thursday, 11 January 2018 14:49:54 UTC