Re: DID Key Management Harmonization Proposal #1

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.

Some questions for Manu:

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

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

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

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

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

Questions for Sam Smith:

What is your general thought about the proposal? Is it a step in the right
direction? Does it roughly address your concerns?

Best,
Christian



On Wed, Jan 10, 2018 at 2:00 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> Hey Markus, some thoughts on your thoughts:
>
> On 01/09/2018 08:33 AM, Markus Sabadello wrote:
> > Myself, I like this proposal, I'm coming from the "extensibility" /
> > "graph-model" rather than the "minimalist" worldview.
>
> Yay :)
>
> > At the same time, this doesn't seem to preclude minimalist DID
> > documents, and the spec could have appropriate recommendations on
> > privacy and correlation.
>
> Yes, that was a design goal to enable both minimalist DID documents that
> only want to talk about keys and nothing else, all the way up to the
> larger ecosystem that ledgers like Veres One want to provide via a DID
> Document.
>
> > I've also thought for a while that purpose/application should be
> > kept separate from the technical properties of the keys.
>
> I'm starting to warm to that viewpoint as well. The abuse that it
> potentially opens up is people using keys w/o knowing the purpose of the
> keys. More traditional developers may do this because that's all they've
> ever know.
>
> However, the specification and libraries should be very clear that you
> shouldn't use a key unless you have derived it's purpose by going down a
> particular branch of a tree-based model or a particular relationship in
> a graph-based model. We could even create tests that fail when keys NOT
> in the authentication field are used for authentication and ensure that
> DID authentication libraries ensure that they pass the entire test suite
> in order to be listed on our page of "conformant libraries".
>
> > I do feel a bit uneasy every time the JSON tree model vs. RDF graph
> > model tension comes up (not just in this community). But I guess as
> > Manu writes, techniques like JSON-LD Framing can help avoid problems
> > and make it work in both worlds.
>
> Yes, it's more lifting on the JSON-LD side of things, but that seems
> like where the heavy lifting always happens since pure JSON developers
> don't want to be bothered. In any case, the JSON-LD libraries can bury
> these details and just expose clean APIs for both JSON and JSON-LD
> developers alike.
>
> > I agree with Drummond it was interesting to note that the
> > "authentication" branch is not modeled as a service endpoint (or a
> > service without service endpoint). I could see how this makes sense,
> > since not every interaction, data sharing, messaging flow, etc.
> > necessarily has to involve a discoverable service endpoint.
>
> Yes, and that's the primary reason it ended up in "authentication"
> instead of as a service. Authentication is kind of a meta-protocol,
> where you're operating on messages instead of at the protocol layer.
>
> One could argue that that's what makes encryption different. Encryption
> tends to be more protocol oriented - you need to provide an endpoint
> and a protocol that will do key negotiation whereas with authentication,
> all that information is the same for everyone authenticating via the
> same key material.
>
> > And I can see how purposes/applications like "authentication" or
> > "encryption" could be thought of as applying to the DID owner in
> > general, rather than applying to a specific service. I guess the
> > question then is, do we still need to be able to connect service
> > definitions to specific keys and/or purposes/applications, as it is
> > in the DID Spec Hardening Proposal V3
> > <
> https://docs.google.com/document/d/1je9Bnhe-1tLgP1bfCSUjvbQ_qllwCz042aGncWX7Uio/
> >?
>
> I think we still need this ability as certain services will only accept
> certain types of keys. To put it another way, the authentication field
> lists authentication suites. I'd expect the same for encryption and
> services. That key material needs to be applied in a certain way for the
> protocol to work and that's what the suites are about.
>
> > Regarding encryption, maybe one aspect here is that in some cases
> > (e.g. RSA) a DID's keys can be used directly for
> > encryption/decryption. In other cases (e.g. Curve25519) a DID's keys
> > are used to agree on a shared key which is then used for
> > encryption/decryption. Mike Lodder or other crypto experts should
> > clarify, but I suspect this difference may have to be reflected
> > semantically in the DID document.
>
> We certainly need to differentiate between signing keys and encryption
> keys as you don't want to use one key for both purposes (that's a
> security vulnerability). That's one of the reasons we have the
> "authentication" and "encryption" purposes broken out (and we should
> have extra language in there that states that one must throw an error to
> use a key that is associated w/ both purposes).
>
> -- 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/
>
>