W3C home > Mailing lists > Public > public-credentials@w3.org > June 2020

Re: Wallet Portability (was: Re: New Work Item Proposal: Universal Wallet 2020)

From: Orie Steele <orie@transmute.industries>
Date: Thu, 25 Jun 2020 08:50:09 -0500
Message-ID: <CAN8C-_+XKed4PT3JbiR8WmgOgONZ-pN1S8-He2+q-ABQT86nMA@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
We have a demo of synching data using the universal wallet and encrypted
data vaults. And I agree that it generally solves the data portability
problem. However, functionality wise we are also not seeing a loss, since
we are copying data between 2 instances of the same sample implementation.
If we were to replicate to a new wallet vendor, 2 things would happen.
Certain data model objects might not be rendered (unsupported data model)
or certain interfaces might not be supported (unsupported interface). As
long as the data moves, that's one part of the problem solved. But I think
it's also desirable to be able to alert the user that wallet content or
interfaces that worked previously may not be available in the current
vendor. To borrow from the IoT sphere, web things exposed IoT device
characteristics and capabilities under a common vocabulary, so you discover
easily if temperature or humidity sensors were available. Similarly, our
initial desire was to work towards knowing if ERC-20 tokens are supported
or not.

This is especially important when we consider wallets that support 3
credential formats and 10 currency / token types... Before you even move,
you might want to check that you can transfer funds after you move... With
encrypted data vaults... The good news is that you can always fix this by
just copying the raw contents to a wallet vendor that does support that


On Thu, Jun 25, 2020, 8:35 AM Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 6/24/20 11:23 PM, Orie Steele wrote:
> > maybe there is a better way to get wallet portability and
> > interoperability that does not involve defining the data model for
> > wallet contents and a set of interfaces that a wallet vendor might
> > support that are linked to the data model.
> There is a better way... copying Encrypted Data Vaults.
> If wallet software has to understand everything stored in a wallet to
> transfer the contents of the wallet from one provider to another, we've
> lost.
> Here's an analogy:
> A hard drive manufacturer DOES NOT need to understand how to interpret
> music lists, pictures, documents, grocery lists, and videos in order to
> copy those things from one hard drive to another one.
> Similarly, an operating system doesn't have to understand the objects
> it's storing -- they are just blobs of binary data and the most minimal
> of metadata to operate on those blobs of data.
> The only thing we have to do to ensure Wallet portability is make sure
> all of the data in one wallet can be copied to another one... and that's
> the purpose of Encrypted Data Vaults - to provide that interface and
> basic data model.
> Everything else is layered on top, in application layers -- which is
> what I thought Universal Wallet 2020 was doing. It seems to be an
> application layer specification, not a portability layer specification.
> Am I missing something there?
> -- 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 Thursday, 25 June 2020 13:50:36 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 25 June 2020 13:50:37 UTC