Re: DID Key Management Harmonization Proposal #1

On 01/10/2018 04:28 PM, Christian Lundkvist wrote:
> Having had some time to dig into this proposal, I think it’s a great
>  step towards reaching consensus on the DID spec! I think it allows 
> for simple DID docs as well as more extensible ones. I also like the 
> idea that the publicKeys specifically only talk about the 
> cryptographic properties of the keys themselves and their purpose is 
> delegated to other sections.

Great, thanks for the review, Christian! :)

Responses to your questions/thoughts below...

> * For public key authentication in the “authentication” list, do you
>  always see this referencing keys in the “publicKeys” list (as in the
>  example)? Would you ever have a key in the “authentication” list
> but not in the “publicKeys” list?

At present, I think the Veres One ledger would prefer to not use the
publicKeys array and instead list keys completely in the
"authentication" property. The downside there is that Veres One may be
forced into a situation where one has to repeat key information OR use
key references where it won't be clear where to find the complete key
information. That said, we'd provide easy API calls that would allow you
to just do doc.getKey(keyId) and get a fully formed key from the JSON-LD
data. That's the approach we would have preferred that the group take,
but there were a number of -1s to the proposal when it was made, which
makes this the backup proposal.

Note that just because we are planning to do this doesn't mean that
others can't use authentication (with key references to publicKeys). The
proposed algorithm compensates for both approaches while staying unified
across all DID ledgers.

> * Would we have a separate master document where the keys/ciphers are
> defined (like RsaSigningKey2017 in the example)? (This was a central
> point in Drummonds original proposal)

Yes, there would be/are separate specs for keys/suites.

Note that this is not specific to DID specs and is not a new proposal,
but is rather more or less how the Linked Data Signatures stuff has
worked since 2013. For example, here's a link to the 2017 RSA Signature
Suite:

https://w3c-dvcg.github.io/lds-rsa2017/

The bit that is new is encoding the cryptographic purpose for the key in
the key type (e.g. RsaSigningKey2017). We can choose to embed that in
the signature suites, or have a separate key suite document... but
that's an editorial decision for later down the road.

> * “Authentication types“ would also need its own document where the 
> various authentication types are defined? I would imagine that a lot 
> of them would be very similar (i.e. RsaKeyBasedAuthentication2017 
> would only be different from NistP256EcdsaKeyBasedAuthentication2017 
> in the type of key used)

Yes, that's true and we'd have to figure out the best way to define
those sorts of things. In many cases, a simple one page spec would
suffice. That's what the key types registry work item is about:

https://htmlpreview.github.io/?https://github.com/w3c-ccg/did-spec/blob/4eafb19e5c66b9d54e31d88460b89bdc00a07d80/ld-keys.html

> * What are “credentials” in the DID doc? Are these lists of specific
>  credentials or more “credentials” as an “application/purpose” - i.e.
>  these are keys used to sign verifiable claims?

The "credentials" property is a placeholder for where one would put
public verifiable credentials about the entity represented by the DID.
For example, if I wanted to assert that a particular DID has an open
source package with more than 1 million downloads a month, I'd place the
verifiable credential in that property.

You raise a good point about where we should place keys used for doing
things like signing contracts or issuing verifiable credentials. I'd
expect we'd use something like "issuing" or "credentialIssuing" for the
application/purpose... and maybe we should have a deeper discussion on
whether or not "credential" is the best name to use... that's what we're
currently using in the Verifiable Claims WG. I've raised an issue to
discuss based on the point you make above:

https://github.com/w3c/vc-data-model/issues/103

> * What are your thoughts on Sam’s idea of using the method name as a 
> way of name spacing part of the DID document to be used for method 
> specific data?

I think it falls into the "Bag of Keys" anti-pattern. We might as well
call is "methodData", where "method" is replaced by "uportData". The
problem here is that we'd then have /two/ ways of extending the data
model (which is more complexity for no real added benefit vs. just
adding a term to a JSON-LD Context and using JSON-LD to extend).

If push comes to shove, I'd rather we use the prefix approach I
suggested earlier, so `uport<PROPERTY>` would be the pattern. If you
wanted to define a new type of Foo that would be specific to uport, it
would be uportFoo. JSON-LD processors would do one of two things:

1. Process it w/o conflict if uportFoo was included in a uPort JSON-LD
   Context (this would be the best of both worlds), or
2. Drop it on the floor if there was no JSON-LD Context specified.

Both approaches would lead to no conflict and avoid the worst of the
"Bag of X" anti-pattern.

-- 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:28:54 UTC