- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 20 Jan 2020 15:18:52 -0500
- To: daniel.hardman@evernym.com
- Cc: W3C Credentials CG <public-credentials@w3.org>
On 1/20/20 2:56 PM, Daniel Hardman wrote: > I don't think this work is relevant to the DIDComm binding for HTTP. > DIDComm is transport-independent; its security can't depend on > mechanisms that are unique to one transport. Yes, but DIDComm *can* use features of a particular transport that enhances security, right? For example, given two bindings for DIDComm, an HTTP one where there is no security (no use of TLS) and HTTPS where there is security (use of TLS), my expectation is that people would view the HTTPS one that uses TLS as more secure because there are two layers of security there (the DIDComm layer and the TLS layer). Since TLS is easy enough to use these days, it doesn't cost you much for that higher level of security. The argument for why DIDComm might want to use HTTP Signatures is the same. Security is about layering... you never just depend on one security mechanism, like DIDComm, to protect you, mainly because stuff like this happens way more often than we'd like: https://threatpost.com/exploit-fully-breaks-sha-1/151697/ My expectation is that if we were to use DIDComm, we'd want this as an option (especially because it provides an alternative to using TLS and the CA system to the DID ecosystem). Perhaps I'm missing something that makes this not possible using DIDComm? -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) Founder/CEO - Digital Bazaar, Inc. blog: Veres One Decentralized Identifier Blockchain Launches https://tinyurl.com/veres-one-launches
Received on Monday, 20 January 2020 20:18:57 UTC