- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 23 Nov 2019 19:16:47 -0500
- To: Oliver Terbu <oliver.terbu@consensys.net>
- Cc: W3C Credentials CG <public-credentials@w3.org>
On 11/23/19 11:51 AM, Oliver Terbu wrote: > How would the WebKMS work relate to the Cloud Signature Consortium? > Seems like there is a lot of overlap! Thanks for the links, Oliver. Yes, at a basic level I think there is some overlap, but those are only at the surface. Some of the differences in WebKMS are: * WebKMS is a facade on existing KMS systems... think AWS CloudHSM, Azure Dedicated HSM, Google CloudHSM... and is intended to also wrap WebAuthn on the client-side. Ideally, you use one API to access cloud-based and local-based HSM signing. Orie (impressively) deduced this from the specification, which is still a bit vague on this particular concept. * The goal isn't to try to convince these cloud providers to support the API, which has been attempted and has failed multiple times across the OpenStack, AWS, Azure, Google, Digital Ocean stacks. Rather, it's to enable the rest of us to implement drivers that can be dropped into libraries to make use of the cloud-based services that are already provided, CSC RSP included. * Since WebKMS is a facade on server-side *and* client-side KMS systems, it also needs to be protocol agnostic and focuses on a local library API *and* an HTTP API. CSC RSP assumes server-only, which doesn't really help Web developers trying to do something similar client-side. * WebKMS is designed to be authorization agnostic, whereas, as Orie mentioned, CSC is tied to OAuth2 and password-based authentication. That is, bearer tokens and passwords, which is a questionable authorization mechanism for a hardware-based system. WebKMS is going to focus on Signature-based authentication (with a focus on ZCAPs), but will be agnostic. In some cases, it expects a front-end system to do authz. We will almost certainly not support password-based invocation of signatures as CSC RSP does. * WebKMS is not user-focused but rather keystore focused, when multiple people or organizations need to "share" access to a particular keystore (but not actually share the key or authorization details). This means safe multi-signature capabilities without the need to exfiltrate keys (which doesn't seem to be supported by CSC RSP). It also means support for delegation of authority to use a key for a specific purpose (ZCAP-based delegation). Those are just the ones I can remember off of the top of my head that make WebKMS different from CSC RSP (based on an admittedly 6+ month out of date understanding of CSC RSP). I do agree that we should make absolutely sure that all of these points still hold before pushing forward on WebKMS. -- 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 Sunday, 24 November 2019 00:16:54 UTC