- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 7 Dec 2020 17:01:24 -0500
- To: Gabe Cohen <gabe.cohen@workday.com>, "daniel.hardman@evernym.com" <daniel.hardman@evernym.com>
- Cc: "public-credentials@w3.org" <public-credentials@w3.org>
On 12/3/20 12:26 AM, Daniel Hardman wrote: > Most of us who were building web tech in the 90s started out with > the detailed, careful alignment offered by SOAP, WSDL, and XML > namespaces. The paradigm with this approach is much like the > worldview you're advocating, Manu. No, that is a straw man, is not what I believe, and is the opposite of what is being advocated. JSON-LD was an attempt to combat the very thing you're arguing against (warning, strong language and strong opinions): http://manu.sporny.org/2014/json-ld-origins-2/ ... or to put in different terms -- we're on the same side of history! :P On 12/3/20 1:40 PM, Gabe Cohen wrote: > The “my way or the highway” sentiment is really quite detrimental to > progress here. Given your and Daniels reaction, let me take a step back and apologize for communicating that -- it's certainly not what I was trying to communicate. Gabe, I'm trying to learn from you and Daniel. I want to understand under what circumstances you think that JCS is appropriate to use for a Verifiable Credential. I have an idea of what is appropriate from my point of view, but have no concept of what you or Daniel think is appropriate. All I have to go on is what you've written in the email, which is not prescriptive... and when you're not prescriptive, it can be very dangerous from a security perspective. > The advice is not “dangerous.” I give more agency to software > engineers and their teams to do research and come to a well-reasoned > conclusion. Not all enlightened VC engineers will reach the same > conclusions. You're giving "software engineers" far more time than they actually have to think about these sorts of things. Many have a crushing workload, no time to even participate in forums such as these, are not trained in security-relted issues, and barely any time to read the documentation beyond something giving them the green light before they move on to the next thing in their queue. This doesn't make them stupid... it makes them short on time and resources (aren't we all). The best thing you can hand a software engineer in that situation is a library that won't ever blow their foot off, or at least a set of instructions on how to use the tools you're giving them properly. We must strive to give developers systems that are safe to use by default. I challenge the notion that JCS is such a system, but would be thrilled to be proven wrong, and I'm looking to you to do that through some well-crafted responses. > We need to have a clear enumeration of viable options with clear > tradeoffs. Great, we agree! Under what specific circumstances do you think JCS is a good choice when it comes to signing Verifiable Credentials? I certainly have what I think is an acceptable answer to this, but didn't want to influence your answer in case you take the discussion in a different direction. Your answer could be the "clear enumeration of viable options with clear tradeoffs". We have done work in this area before and made an attempt at this here a few years ago: https://www.w3.org/TR/vc-imp-guide/#proof-formats https://www.w3.org/TR/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs I'm looking to you and Daniel to either write the section on JCS (or get us started) with at least the same level of time, care, and attention to the topic. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. blog: Veres One Decentralized Identifier Blockchain Launches https://tinyurl.com/veres-one-launches
Received on Monday, 7 December 2020 22:01:42 UTC