Re: New Work Item Proposal: Universal Wallet 2020

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
>
>