Re: New Work Item Proposal: Universal Wallet 2020

On the Aries WG call, one of the issues that was raised was the interface
section, and scope that it implied... felt... way too big.

The intention behind it was that without saying something like:

Transfer = Function (Currency, Sender Key, Recipient Key)
Issue = Function (Credential, IssuerKey)

Even if a wallet supports the Data Model, how do you know if it supports
transferring of currency or issuing of credentials?

There was a desire to explain how aspects of the data model related to each
other and to other specs, but there has never been an intention to define
exactly how credentials are issued. You might use the VC HTTP APIs or a
series of DIDComm Messages, or a custom issuing flow... but regardless of
how you actually implement issue credential or transfer currency if you
can't describe the inputs and outputs as things that are wallet contents
that abide by a data model, you can't transfer those things between wallet
vendors and still support transfer or issue... or at least, it's not
obvious to me how you would do that... 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.

Both the did spec and the vc data model have data model and actions such as
"create, resolve, update, deactivate" and "issue, prove, verify"... these
are interfaces which methods must address, but they don't have to support
them all, for example did:key does not support update or deactivate... and
the mechanics of proving an indy credential are different than a JWT.

The hope with the wallet spec was that by defining a common set of
interfaces (some of which are basically just pointers to the vc data model
or did spec), similar choices could be made, and wallet vendors could
decide if they wanted to support "Transfer of Currency" but not "Issue of
Credentials"... but there would be at least one place where a set of common
wallet content and wallet interfaces was defined.

It might be that the way the interface section is written needs to be
majorly overhauled. perhaps it's an informative note, or maybe it's just
untestable vocabulary definitions.

There are a number of areas of the spec, including the representation of
correlation, connections, and the interfaces section which we think need a
substantial amount of work.

OS






On Wed, Jun 24, 2020 at 9:28 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> Extending some previous comments:
>
>    - A reference impl is rarely a gold standard in practice; often it is
>    slower or less scalable than other impls with better staffing. Also, even
>    if it is bug-free it often introduces additional features and/or
>    encumbering dependencies that are not part of the spec itself -- or it
>    omits important features because they would introduce those dependencies,
>    watering down the value prop.
>    - A reference impl creates a second oracle. The spec is supposed to be
>    the oracle for its own intentions.
>    - Code has a different maintenance lifecycle (and different
>    qualifications for contribution) compared to documents. A spec may be
>    perfectly stable after it releases, with no need to re-release for years --
>    but a reference impl might need to be updated on short notice to eliminate
>    a security vuln, for example. All of the features touted for ref impls
>    require that the code and the doc remain perfectly in sync. This is hard to
>    achieve periodically, let alone continuously. (Yes, it can be done. But now
>    spec writers are worried about CI/CD. Are we sure that the people
>    maintaining both types of artifacts will remain equally committed and
>    responsive and productive throughout the lifecycle of the concepts?)
>    - There are major political problems with a "gold standard" impl.
>    Whoever implements that one has undue influence -- or else you have
>    maintenance by committee, which is *really* hard.
>
> Despite these problems, I do see some value in this. But I think it only
> manifests if the scope of the impl is very small. A great example of a
> reference impl is the algorithms that the Unicode consortium published for
> UTF8 encoding and detection. These were not complete implementations of all
> things Unicode-related. They were not big projects that required complex
> maintenance. Rather, they were short (50-ish line) snippets of C code that
> made the abstract descriptions of the algorithms usefully concrete. Because
> they were narrow and crisp samples, there was little risk that they
> contained concept errors (the impact of the sort of unanswered questions
> Christopher is talking about). The consortium only produced such code for
> things where confidence was very high.
>
> Thus, a reference impl of a particular algorithm (say, resolution of
> relative URIs in DID docs) might make sense to me; a reference impl of
> issuance or verification of a VC is *way* too ambitious and politically
> fraught to clear the same bar.
>
>
> On Wed, Jun 24, 2020 at 8:06 PM Christopher Allen <
> ChristopherA@lifewithalacrity.com> wrote:
>
>> I know that I'm interested less in focusing on a reference implementation
>> as the first item for a group to focus on. I don't think we understand the
>> problem well enough for a "universal" wallet architecture.
>>
>> Joe Andrieu and I took a stab at this last year before #RWOT9 in Prague
>> as a topic paper, and feel like we just touched the surface. Take a look at
>> the topic paper:
>> https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/whats-wallet.md
>>
>> In particular, take a look at the diagram:
>> https://github.com/WebOfTrustInfo/rwot9-prague/raw/master/topics-and-advance-readings/media/ExpandedDecentralizedIdentityNetworkComponents.png
>>
>> We also identified in that paper 10+ missing areas that we didn't even
>> begin to break into pieces to put into the picture above. And I also feel
>> it is essential we also look at the issues of currency in wallets, as
>> clearly users expect to put credentials and money in the same wallets
>> (think not just your pocket wallet, but also Apple Wallet and Google
>> Wallet).
>>
>> I personally would like to see the community get together to better name
>> these different parts, or even better, name the connections between the
>> parts. Right now the three major platforms, much less small players like
>> BTCR, don't have any agreement on the naming conventions for the parts,
>> much less ready for a universal architecture.
>>
>> I'd hoped that at either RWOT9 or RWOT10 that we'd make some progress on
>> this, but clearly it will likely be a while before we get have another RWOT
>> to word together F2F, so figuring out how to do it virtually I think would
>> be a useful work item.
>>
>> — Christopher Allen
>>
>>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>