Re: DID Key Management Harmonization Proposal #1

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/

Received on Wednesday, 10 January 2018 19:00:10 UTC