Re: Proposed work item: WebKMS

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