DID Spec - key management - 3 proposals (was: Re: Worldview conflicts on the purpose of DID documents)

On 12/13/2017 11:57 PM, Manu Sporny wrote:
> In the next email I'll try addressing the discussion from the other
> way (bottom up instead of top down). Maybe once we meet in the middle
> we'll figure out a clear path forward.

We have three proposals, as far as I understand it, for doing "key
management" in a DID Document.

Option #1: Keys

This mechanism puts anything that could be considered a "key" into the
"keys" bucket in the document:

Pros:
  * One place to put all keys in the document
  * Enables interop
Cons:
  * Developer may not understand which key is for what purpose and what
    application (non-trivial security vulnerability via bad
    implementation risk)
  * Not broad enough. Are biometrics a key? what about a
    username/password hash? two factor sharded secret? All of these
    could be used for authentication, do they go in the keys field?

{
  "keys": [ ... every key, biometric, etc. goes here ...]
}

Option #2: Authentication Material

Pros:
  * Narrowly focuses on data used for authentication use cases
  * Application of key material is clear and far more difficult to
    mis-implement than Option #1
  * Enables interop
Cons:
  * Requires further discussions on things like encryption keys and
    other use cases.

{
  "authenticationMaterial": [ ... every authentication key here ...]
}

Option #3: DID Method Picks

Pros:
  * UNSTANDARDIZED is a DID method specific term... some may choose
    "keys", others may choose "authenticationMaterial", etc.
Cons:
  * No cross-ledger interoperability for anything key related

{
  "UNSTANDARDIZED": [ ... keys descriptions are standardized ... ]
}

I think that's fundamentally what we're trying to figure out.

The rest, which is a key's purpose and type are things that we agree on
in principle, but not necessarily on the specifics. I think Drummond
would like to combine key type+purpose+application like so (correct me
if I'm wrong, Drummond):

Option #A: Everything in Type

   "type": "VerifiableCredentialsIssuerSigningRsaCryptographicKey"

others think this may be best:

Option #B: Deconstructed Application and Purpose

{
   "type": "RsaCryptographicKey",
   "application": "VerifiableCredentialsIssuer",
   "purpose": "Signing",
   "publicKeyPem": "...................."
}

Option #C: Application via Relation

{
  "issuerMaterial": {
    "type": "RsaCryptographicKey",
    "purpose": "Signing",
     "publicKeyPem": "...................."
  }
}

Hope this helps folks understand the various options under
consideration. Please add/correct if I got something wrong.

-- 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, 14 December 2017 06:15:06 UTC