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

Manu, thanks, I think this summary will help us in the DID Spec Closure
call today (that starts in 10 mins - see the reminder message Susan posted
to the list).

A few comments inline.

On Thu, Dec 14, 2017 at 1:14 AM, Manu Sporny <msporny@digitalbazaar.com>
wrote:

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

On that point I think we have a high level of disagreement among the crypto
folks in the group; I've heard just the opposite from advocates of this
approach. I suggest this is one area we can focus discussion.


>   * 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?
>

This is a second area where I think the worldview conflicts are the source
of disagreement, and where I think we would benefit from discussing it from
that angle.


>
> {
>   "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.
>

>From the agent worldview, the "con" is bigger than this—it is confusion
about use of a DID doc for key management if keys are "all over the place"
and understanding what key goes where requires understanding the RDF graph
model.


>
> {
>   "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 ... ]
> }
>

Uggh. On today's call I'd like to see if we have consensus right away to
cross this option off the list.


>
> 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):
>

Correct.


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

I think it does. I would invite anyone on the list who has strong feelings
about these options but is not able to attend today's call (that starts in
10 mins) to please weigh in here on the list so we can hear your voice.

Thanks,

=Drummond


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