Re: decentralized wallets and payment processors

On Sat, May 2, 2015 at 6:13 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
 wrote:

> I like the definition of a wallet as being the virtual version of the
> physical thing. A place to store instruments that can be used to complete a
> payment, which if you think about it are normally just credentials of some
> form.


I like that definition too. I see wallets as aggregators of identity and
payment credentials. In the context of the Web, I think of wallets as
aggregators of URLs that represent [identity and payment] credentials, just
like Bitcoin wallets are aggregators or collections of private keys.


On Sat, May 2, 2015 at 6:02 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
 wrote:

> I acknowledge that a lot of what is discussed and standardised at the W3C
> revolves around browsers, but these are not the only Web clients. In fact
> in most cases mobile Apps are also HTTP clients using technology such as
> REST (or similar) to communicate with the services they rely on.


 Exactly, we need to keep in mind that browsers are not the only web
clients. Web payments doesn't mean "payments from a browser" but "payments
through web technologies". Furthermore, given the fact that we can do
pretty much anything from the browser through CORS-enabled APIs, we
shouldn't worry about NPAPI deprecation or browser adoption in general, nor
talk specifically about browsers but web-based payment agents (i.e.
HTTP-based).


On Sat, May 2, 2015 at 6:02 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
 wrote:
>
> User access to their payment agent will only occasionally be through a
> browser, it could easily be that the service that is acting as the payment
> agent is sitting on a web server or is an App on a mobile device.. What I
> believe we have consensus over is that the communications between these
> agents will use Web technologies (existing or possibly new) which have been
> standardized at the W3C.


Absolutely. No matter where a payment agent sits, if it uses HTTP(S)(/2)
[verbs] to exchange OAuth 2.0 tokens with a [REST] API and send [JWS]
messages to URLs that represent payment credentials, for example, it is a
web payments agent.

On Sat, May 2, 2015 at 7:28 AM, Joseph Potvin <jpotvin@opman.ca> wrote:

> PNC provides the following "about" summary when you click on features &
> fees for their "Virtual Wallet" (and type in a random ZIP code).
>
> https://www.pnc.com/en/personal-banking/banking/checking/virtual-wallet.html
>
> In their terminology, a wallet can contain several accounts, that's to say
> it's an account with "folders":
>
> *Virtual Wallet is comprised of 3 accounts working together:*
> *Your Spend account is a non-interest-bearing checking account*
> *Your Reserve account is an interest-bearing c**hecking account used for
> short term savings goals*
> *Your Growth account is a savings account which earns interest and can be
> used for longer term savings goals *
>
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca
> Mobile: 819-593-5983
>
> On Sat, May 2, 2015 at 8:00 AM, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On 2 May 2015 at 13:13, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
>>
>>> Wallets vs Accounts
>>>
>>> I have come across very different definitions of a "wallet" both in this
>>> group and amongst payments industry practitioners for some time. There
>>> seems to be two camps. One sees the wallet as an account, simply a store of
>>> value and the other as a virtual wallet that stores all the things one
>>> normally stores in a physical wallet such as payment cards (ways to pay),
>>> loyalty cards (ways to identity you as a member of some group), electronic
>>> "cash" (which compares closely to the former definition).
>>>
>>> I see no value in the first definition, this is simply an account.
>>>
>>> To add, I think that a wallet shouldn't have too much built in "logic"
>>> or "business rules" or it is no longer a wallet. My wallet in my pocket
>>> doesn't execute payments autonomously.
>>>
>>> I like the definition of a wallet as being the virtual version of the
>>> physical thing. A place to store instruments that can be used to complete a
>>> payment, which if you think about it are normally just credentials of some
>>> form.
>>>
>>> I also like the concept of a payment agent which the IG have started to
>>> define in their architecture document. This is a service that acts as a
>>> broker between an entity, it's wallet and/or accounts and other payment
>>> agents. Under this model the wallet is a component of (or is interfaced to
>>> by) the payment agent.
>>>
>>
>> I had this exact issue during implementing, and had to change things
>> around.
>>
>> My goal for a wallet is to make it lightweight.
>>
>> So there seems to be two ways:
>>
>> 1. User -> balance
>>
>> 2. User -> account -> balance
>>
>> Where accounts are useful is that they can sub divide balances per
>> currency.  (1) cant easily do this unless you use currency as a type.  I
>> got round this by having the default currency set to "bits".
>>
>> The advantage of (1) is simplicity leading to adoption.
>>
>> The advantage of (2) more fine grained control.
>>
>> Wallets are containers of one or more of these ledger entries, and
>> provide a path to pay, deposit and withdraw.
>>
>> My current strategy is to go with (1) to start with, and if there's
>> scalability issues (a nice problem to have) transition to (2)
>>
>>
>>>
>>> Thoughts?
>>>
>>> Adrian
>>>
>>> On 1 May 2015 at 19:19, Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 1 May 2015 at 19:04, Melvin Carvalho <melvincarvalho@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 1 May 2015 at 18:42, David Nicol <davidnicol@gmail.com> wrote:
>>>>>
>>>>>> Conversely, is a digital wallet (or does a digital wallet imply) a
>>>>>> bank account?
>>>>>>
>>>>>
>>>>> Banks tend to perform a number of mandatory services, of which a
>>>>> wallet function is just one.  For example, withdrawal counters, direct
>>>>> debit, standing orders, phone banking, reversing fraudulent payments,
>>>>> investments, and many more.  The downside is that customers pay for these
>>>>> services in the form of interest (either lower interest for savers, or
>>>>> higher interest for borrowers), occasional defaults and bail outs.
>>>>>
>>>>> So I would say, a wallet is a small tool in banking services, it's not
>>>>> the same as a bank account, imho.  But using the web as an existing
>>>>> infrastructure can hopefully spur new innovation, and make existing systems
>>>>> more efficient
>>>>>
>>>>>>
>>>>>>
>>>>>> The matter will only be resolved by consensus on definition of terms,
>>>>>> after a discussion in which the overlap is recognized and explored,
>>>>>> and there is at least one clarifying
>>>>>>
>>>>>> https://en.wikipedia.org/wiki/Venn_diagram
>>>>>>
>>>>>
>>>>> Yes, exactly.  Every term will have overlaps with others, and they
>>>>> could be debated for a long time.  Our primary goal is to get the
>>>>> definitions good enough, and quickly enough, so that software systems can
>>>>> be built.
>>>>>
>>>>> Although interesting, and it's great to hear from legal experts, this
>>>>> is not primarily a legal forum.
>>>>>
>>>>
>>>> Just wanted to clarify this a bit more.
>>>>
>>>> David says there's a venn diagram for overlapping terms.  So, spec
>>>> designers will mean one thing by one term, legal experts will mean another
>>>> thing, and general every day use of language will mean yet another.
>>>>
>>>> The process we come to consensus in software standards (at least at the
>>>> w3c) is through ontologies, and learning through building software.  While
>>>> it's really interesting to hear a cross section of views in the venn
>>>> diagram, my hope in starting this thread was to focus on the software and
>>>> ontology part.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> is produced.
>>>>>>
>>>>>>
>>>>>>
>>>>>> >> Is a bank account a type of digital wallet?
>>>>>> >
>>>>>> >
>>>>>> > A bank account is not a digital wallet
>>>>>>
>>>>>> --
>>>>>> Case law is made by litigants questioning Judges' decisions.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
>
> <819-593-5983>
>