Re: WebKMS and Serialization

There are two levels of interoperable data we ought to think about: what
does plaintext serialized data look like, and what does
encrypted/compressed serialized data look like.

Plaintext wallet data in codebases that use Hyperledger Indy (libindy.so)
is MessagePacked and consists of records that are very simple: name (a
string identifier), type (a short token; can't remember if it's an int or a
few chars), value (BLOB or MEMO-type field, IIRC), value_key (crypto key).
I can't remember if value_key is preserved on export or thrown away to be
rebuilt on import. Encrypted wallet data in codebases that use Hyperledger
Indy uses a streaming cipher (ChaCha20-Poly1305-IETF, IIRC); see these
design docs
<https://github.com/hyperledger/indy-sdk/tree/master/docs/design/009-wallet-export-import>.
I've added a couple EV people to the thread who know more than I do about
it. We felt that streaming was important, as some enterprise wallets might
contain millions of keys, even though the wallets on mobile apps are far
smaller. Theoretically this results in a standard, portable package where
the data could be reimported anywhere; however, we've found a couple
caveats as some impls add a compression packaging that others lack. This
approach has certain virtues, but is not without drawbacks, too.

I think people in Indy's or Aries's orbit would be happy to tweak our
approach, or share it, to find common ground. Making this data portable is
an important proof-point for self-sovereignty; we don't want vendor wallet
data lock-in.

On Mon, Jan 6, 2020 at 10:57 AM Orie Steele <orie@transmute.industries>
wrote:

> Happy New Year!
>
> We've updated our did:key demo to point to the did:key method spec, and
> work with our test web wallet serialization format we use in did:github and
> did:elem.
>
> https://did-key.web.app/ (Open Source)
>
> We're working towards an encrypted data vaults demo that works with
> did:key, did:github and did:elem.
>
> One of the challenges we are facing along the way is getting keys and meta
> data from our existing "wallet" system into the software needed to connect
> to an encrypted data vault, which is used by
> https://github.com/digitalbazaar/edv-client
>
> Because much of the crypto we use (secp256k1 and ed25519) don't have built
> in browser support, we are forced to use extractable keys, and in browser
> crypto suites such as lib sodium.
>
> This causes us to often need to import key material and meta data into a
> browser or client app, for demo purposes... we created this test javascript
> / json (wallet/keystore) serialization library to help do this:
>
> https://github.com/transmute-industries/did-wallet
>
> Increasingly we're finding ourselves storing DID meta data in these wallet
> files in order to work with demos for encrypted data vaults / ZCaps...
>
> In other words, our portability system for keys is starting to overlap a
> bit with WebKMS... https://digitalbazaar.github.io/webkms/
>
> We don't want to be going our own way here, we want our portability
> solution to be WebKMS compliant, and from what I understand, it would not
> be that hard to get there.
>
> What we need is a standard way of describing a set of keys (including
> private keys), and a set of metadata about those keys in a way that can be
> serialized to a string and encrypted... (this is what our existing
> did-wallet does, it's not fancy).
>
> My question to this group is: *What is the standard for serializing a
> collection of key material and metadata that best integrates with web kms,
> if there is not one, how might we go about defining such a thing?*
>
> I will note that JWKS is a solution to this problem, but it's not obvious
> that adding metadata fields to a JWK would be how the community would want
> to solve this issue... and I think the metadata would need some type /
> semantic information such as JSON-LD or JSON Schema to be useful.
>
> Regards,
>
> OS
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
> ᐧ
>

Received on Monday, 6 January 2020 18:47:13 UTC