Re: New Work Item Proposal: Universal Wallet 2020

Hello my first message here :P

As an implementer i'm agree with Orie, I would like to see more interface
related information that can be used as a reference (to do TDD for
example). Sometimes it is difficult to understand some specs without this
interface related information. For me a "reference implementation" is the
one implementing all the interfaces.


On Thu, 25 Jun 2020 at 05:25, Orie Steele <orie@transmute.industries> wrote:

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


-- 
Att.
Javi Santos