- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 10 Jan 2018 13:59:43 -0500
- To: public-credentials@w3.org
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