Re: Multiple Wallets

The issues expressed by some against the proposed working definition are:

1. Some members here don't understand the precise legal terms used by the
top-echelon global standards body on e-commerce law. Which of the terms are
difficult to understand are not specified, so it's impossible to know what
clarify. Perhaps it is clarity itself that is not wanted.

2. The proposal to ground the proposed generic omni-channel definition of
"wallet" upon the precise legal terms of the top-echelon global standards
body on e-commerce law is perceived to be the same as pushing preconceived
ideas based on this or that particular products out there today that call
themselves in name or otherwise, wallets. Perhaps its the domain authority
of the top-echelon global standards body on e-commerce law that is rejected.

3. "We are explicitly trying to avoid defining too rigorously, the wallet's
FUNCTIONS" although the definition in the Charter is clearly functional,
and the FAQ says "the standard will define some minimum required functions
of a wallet (receiving, processing and responding to the standard messages
in the standard flow) to perform payments on the Web".  The proposal is put
forward precisely to express some minimum required functions "so that we
don't restrict the ability of those building systems that can host that
interface, and service those messages from the payee, from innovating in
how they do it".

The word "wallet" appears 30 times in the current charter. The definition
given is: "digital wallet: A wallet is a container for payment instruments
that affords access to them. A digital wallet holds digital payment
instruments."   ...but "payment instruments" is not defined.

The proposed definition provides for two general classes of payment
instrument: "money" and "anything else that might be put into the wallet in
support of payments". Which is to say, the proposed definition provides
that in the superclass of "payment instruments", all of us working in this
space absolutely must design whatever systems we are designing to apply
different sets of constraints to wallet contents that are considered in law
to be "money", than to any other types of wallet contents that are "not
money" but something else.

So let me bring this down to the simplest clarification I'm attempting to
bring foward. The class "PaymentInstruments" includes just two sub-classes:
"Money" and "NotMoney".  To avoid expressing the negative, maybe it could
be "MoneyAssets" and "PaymentRules", but I think I'd stay with "NotMoney".

If this IG cannot bring itself to make that distinction, then I fear it is
setting up users of the eventual specification for a perennial series of
headaches.

The word "wallet" appears 39 times in the FAQ, which states: "The discovery
algorithm and wallet behavior is not standardised only the format of the
request" ... "Is W3C standardizing a wallet? No. ... the standard will
define some minimum required functions of a wallet (receiving, processing
and responding to the standard messages in the standard flow) to perform
payments on the Web. Because the "digital wallet" concept is useful as a
shorthand, but means different things to different audiences, this charter
includes a definition to clarify the intent of this group."

For the W3C to engage in work in the realm of payments is an inherently
interdisciplinary endeavour. The #1 and #2 domains outside of information
technology that provide the logical entities, relationships and constraints
for this work are law and economics, in that order. I come from the #2
domain -- IANAL. But permit me to suggest that if this IG would like more
participation from global payment systems organizations and financial
services companies, then it will take the time to understand and accomodate
certain precise legal terms which the top-echelon working group of lawyers
from around the world provide for use in the domain of e-commerce and
payments.

Or don't.

Joseph Potvin
On behalf of DataKinetics http://www.dkl.com
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983

On Mon, Aug 3, 2015 at 10:32 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> It's important to not take a narrow view of the discussion thus-far or
> respond to cherry-picked comments.
>
> @Joseph: I would suggest that you received little buy in for your proposal
> because those definitions are overly complicated and highly-abstract and,
> to be honest, almost impossible to understand. I did respond to you at some
> point asking for further clarity on what you meant but that was the end of
> that thread. Like Jorg I am viewing all of this through the lens of a
> potential working group participant and specifically a developer who would
> have to implement something either as a wallet vendor, browser vendor
> payent processor or other stakeholder.
>
> We should not colour this discussion with preconceived ideas of what a
> wallet is, based on the variety of products out there today that call
> themselves in name or otherwise, wallets.
>
> The wallet, as defined by the group in the charter and FAQ, is a service
> that is the initial entry point for messages from the payee usually passed
> via the user-agent.
>
> The wallet may be a container for payment instruments. It may simply be a
> selection service that is able to discover many other wallet services that
> are all able to process the same message. It may also be a service acting
> on behalf of a depository or be a depository itself.
>
> The point is, we are explicitly trying to avoid defining too rigorously,
> the wallet's FUNCTIONS. Rather we are focusing on the INTERFACE into the
> wallet service so that we don't restrict the ability of those building
> systems that can host that interface, and service those messages from the
> payee, from innovating in how they do it.
>
> Let's understand the requirements a little better as context for how we
> got here:
>
>    1. We are going to get a request from a payee to initiate the payment
>    process and this request should contain all of the ways that the payee is
>    prepared to accept this payment (as well as some other details of the
>    payment).
>    2. There is a requirement for this request to be directed somewhere.
>    If the request is directed at a browser API then the browser must either
>    handle it or proxy it to some service capable of processing the message.
>    For this to work we need a SINGLE service that will take in this message
>    and return a response.
>    3. The service that receives this message must itself, OR through
>    integration with one or more other services, perform some discovery of the
>    payment instruments available from the payer and then, through
>    user-mediation, business rules or a combination of these select a single
>    payment instrument that the payer is going to use to pay and return the
>    details of this back to the payee.
>    4. If the payment instrument selected is from a "pull" scheme then the
>    payee takes the details it received in the response and processes the
>    payment, probably through some payment provider with which it has a
>    relationship for processing payment for that particular scheme. Following
>    this, it sends a 2nd message to the payer to notify them that the payment
>    is complete and will likely get some form of ACK back from the payer to
>    complete the typical request/response flow.
>    5. If the payment instrument selected is from a "push" scheme then the
>    payee sends a 2nd message to the payer requesting them to process the
>    payment. This message ends up at the same service that received the
>    original message from the payee. At this point (from a standardisation
>    perspective) it is not important what happens next. What is important is
>    that the payment is processed and a response comes back to the payee to
>    prove this. The format of this proof is also outside the scope of the
>    standard as it will be scheme dependent.
>    6. As a developer of any componenet that is involved in this flow I
>    need a standardised flow and I need certain fields in the messages I send
>    and receive to be standardised but unless I am doing the payment processing
>    or discovery or executing some other business logic it's fine if the rest
>    of the message is opaque to me.
>
> What is important to note here is that once the standardised messages have
> been passed "out of the Web context" the behaviour of any services or
> compomenets is outside the scope of our standard. There are any number of
> ways that the system beyond the browser API could be architected:
>
>    - The wallet service could be built into the browser OR browsers may
>    define a mechanism for third parties to integrate wallet services.
>    - All payment instruments may be simply data (such as card numbers,
>    Bitcoin keys etc) that are held in some secure storage and used as required
>    to process payments (that would require the wallet service to have business
>    logic on how to process payments for every payment scheme for which it will
>    hold payment instruments) OR the wallet may define a standard interface for
>    payment instruments so that they are more than purely data but can actually
>    execute payment processing logic too.
>    - The scheme specific data that is passed back and forth between payee
>    and payer using the standard messages and flow we define will be opaque to
>    the standard. This makes the standard simple and allows new schemes to
>    emerge easily into the ecosystem.
>    - When the wallet responds with a payment instrument to use that
>    instrument may be one that was registered with the wallet (eg: you add a
>    card to your Google Wallet and Google Wallet returns the actual card
>    instrument as the payment method) or it may be one that is built into the
>    wallet,perhaps even representing the wallet itself. (eg: you add a card to
>    your Google Wallet and Google Wallet returns a "Google Wallet" instrument
>    as the payment method)
>    - Payment schemes are free to define additional hooks or call-outs to
>    other services that are not defined in the standard and the implementer of
>    support of that scheme (wallet vendor, payment scheme adminstrator etc)
>    must simply find a way for those call-outs or hooks to fit into the
>    standardised flow. Let me expand on this a little with some examples:
>       - A card based scheme (typical pull scheme) may decide that it
>       would like payee's to submit an encrypted card number (encrypted with the
>       scheme operator's public key) to the payment processor to process a
>       payment. For this to work the wallet will need to submit this in the
>       response to the payee (see 3 above). Therefor either the wallet (if the
>       business logic sits there) or the payment instrument (if the logic sits
>       there) must prepare this data to send in the response. i.e. It knows which
>       key to use, how to encrypt the data (format, algo etc) and where to put
>       this in the response.
>       - A card based scheme (typical pull scheme) may decide that it
>       would like payee's to submit a one-time-use token instead of a card number
>       to the payment processor to process a payment. For this to work the wallet
>       will need to submit this in the response to the payee (see 3 above).
>       Therefor either the wallet (if the business logic sits there) or the
>       payment instrument (if the logic sits there) must be capable of getting or
>       generating this token either through some call-out to a token provision
>       service or using some hardware based token generation.
>       - A push based scheme like Bitcoin may be supported by a wallet
>       service which holds the user's private key or has secure credentials to
>       access an online Bitcoin wallet. When it comes time for the wallet to
>       process the payment (see 5 above) it sends the payment to the payee's
>       Bitcoin wallet either by submitting the transaction directly to the Bitcoin
>       network or the online Bitcoin wallet API. The nature of Bitcoin means the
>       scheme may define that the "proof" is unneccesary as a transaction
>       reference is sufficient to send back to the payee who can verify the
>       payment themselves by querying the Bitcoin ledger directly.
>
> My understanding of the charter is that all of the above is true. If any
> IG members disagree I'd be interested to hear your comments.
>
> On 3 August 2015 at 14:27, <Joerg.Heuer@telekom.de> wrote:
>
>> Hello Joseph,
>>
>>
>>
>> If that’s what was intended anyway, I’m happy with it. Perhaps I’m too
>> implementation-oriented to find my way through generic sentences like those
>> you referred to. ;-)
>>
>>
>>
>> Ciao,
>>
>>                 Jörg
>>
>>
>>
>> *From:* Joseph Potvin [mailto:jpotvin@opman.ca]
>> *Sent:* Montag, 3. August 2015 13:41
>>
>> *To:* Web Payments IG
>> *Subject:* Re: Multiple Wallets
>>
>>
>>
>> RE: "being a depository and a repository - in our eyes is the capability
>> to process requests for certain types of transactions and delegate them to
>> the respective services as the user choses (or has them pre-configured)"
>>
>>
>> Joerg,
>>
>> That is precisely what is intended by including the word "algorithm" in
>> "a 'repository' for persistent storage of enduring integral artifacts (e.g.
>> payment method *algorithms*, receipts, coupons, credentials, etc.)".
>>
>> Perhaps it could be more explicitly worded, or if necessary elaborated.
>>
>> Basically, to relate this proposed working definition of an e-wallet to a
>> physical wallet:
>>
>> * It is a "depository" for the temporary storage of information in the
>> form of authorized scalar units of money (as either tokens and/or scalar
>> values in a registry)
>> =
>>
>> * It's where I put my money
>>
>>
>>
>> ...and also:
>>
>>
>> * It is a "repository" for persistent storage of enduring integral
>> artifacts (e.g. payment method algorithms, receipts, coupons, credentials,
>> etc.)
>> =
>>
>> * It's where put my credit cards, debit cards, driver's license, transit
>> pass, café card, etc.
>>
>>
>>
>> Does this address what you have in mind?
>>
>>
>>
>> Joseph Potvin
>> On behalf of DataKinetics http://www.dkl.com
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>>
>>
>>
>> On Mon, Aug 3, 2015 at 5:49 AM, <Joerg.Heuer@telekom.de> wrote:
>>
>> Hello all,
>>
>> Another aspect - besides being a depository and a repository - in our
>> eyes is the capability to process requests for certain types of
>> transactions and delegate them to the respective services as the user
>> choses (or has them pre-configured).
>>
>> We need to be aware of the fact that, while several approaches we see
>> today claim to be 'wallets', their inventors have no fundament to make
>> their product as 'neutral' wrt/ payment instruments as my leather wallet
>> is, because there are no such neutral transaction protocols available
>> (yet). It is the lack of what we aim to accomplish, that blurs the word
>> 'wallet' and the semantics associated.
>>
>> I think that our work represents a good example for a wallet that governs
>> the overall transaction but leaves the implementation for a specific
>> instrument open. However, we can do so because we have an R&D prototype not
>> a product. Every product meant to succeed in the market and eventually earn
>> money, will have to do proprietary stuff and tie things together.
>>
>> I believe it's our job, to do the respective disentanglement and come up
>> with specifications that are needed to allow 'Wallets' according to our
>> definition to come into life.
>>
>> Cheers,
>>         Jörg
>>
>> -----Original Message-----
>> From: Joseph Potvin [mailto:jpotvin@opman.ca]
>> Sent: Samstag, 1. August 2015 13:47
>> To: Web Payments IG
>> Subject: Re: Multiple Wallets
>>
>> RE: "I think it's clear that nobody is talking about the same thing here
>> :)  I think the term "wallet" and "payment instrument" will only make sense
>> in the context of a particular concrete proposal."
>>
>> Given the prominence of the "wallet" concept in the Charter, and given
>> the IG's decision that the Charter will not include work towards
>> standardization of an electronic wallet specification, and yet given the
>> absence of any working definiition of electronic wallet in this or any
>> other reference document, this topic promises to be an inevitable source of
>> lasting debate.
>>
>> In work underway at DataKinetics on a free/libre/open source module to
>> enhance any e-invoice, we required a sufficiently generic and yet
>> semantically specific working definition of any e-wallet so that the
>> requirements for information exchanged between the two could be specified.
>> I suggest the same is required for the other side of the e-wallet, which is
>> any e-payment system.
>>
>> A week ago I offered the following suggestion. I hope it will be okay to
>> repeat myself, as I didn't see any replies on its substance...
>>
>> ***
>> 1. On the topic of wallets:
>>
>> SUGGESTION: There was considerable discussion on this list about whether
>> or not the term "wallet" was helpful or confusing. It appears there's a
>> preference to keep it. Let me therefore suggest the following concise
>> functional definition summarizing our approach at
>> DataKinetics:
>>
>> An e-wallet has two general functions:
>> * It is a "depository" for the temporary storage of information in the
>> form of authorized scalar units of money (as either tokens and/or scalar
>> values in a registry)
>> * It is a "repository" for persistent storage of enduring integral
>> artifacts (e.g. payment method algorithms, receipts, coupons, credentials,
>> etc.)
>>
>> ***
>>
>> In the above, we are attempting to align with the WG IV (e-Commerce) of
>> the United Nations Commission on International Trade Law (UNCITRAL). This
>> top-level global legal standards body distinguishes two systems for the
>> management of electronic transferable records (their most generic term):
>> “registry-based” and “token-based”. A registry contains information about
>> the electronic transferable records including “the identification of a sole
>> owner of the record and of the rights incorporated in that record at any
>> time”. In contrast, a token is an original and unique record, with which a
>> transfer of rights is accomplished through transfer of control over the
>> record itself. A token-based system for electronic payments is similar in
>> its basic procedures to a paper-based payments system.
>> (UNCITRAL, 2012, p. 7) A registry-based payments system implements
>> control via the management of verifiable unique identities; a token-based
>> payments system implements control via the management of verifiable unique
>> tokens.
>>
>> Source: UNCITRAL. (2012). Legal issues relating to the use of electronic
>> transferable records (Version dated 17 August 2012). United Nations
>> Commission on International Trade Law (UNCITRAL), Working Group IV
>> (Electronic Commerce). Forty-sixth Session, Vienna, 29
>> October-2 November 2012. United Nations General Assembly
>> (A/CN.9/WG.IV/WP.118). Retrieved from
>> https://www.uncitral.org/pdf/english/workinggroups/wg_4/WG4-WP_118_e.pdf
>>
>>
>>
>> Joseph Potvin
>> On behalf of DataKinetics http://www.dkl.com Operations Manager |
>> Gestionnaire des opérations The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>>
>> On Fri, Jul 31, 2015 at 11:07 PM, Brett Wilson <brettw@google.com> wrote:
>> >
>> > On Fri, Jul 31, 2015 at 6:56 PM, Mountie Lee <mountie@paygate.net>
>> wrote:
>> >>
>> >> is anybody share the latest link of glossary for wallet, payment
>> scheme, payment instrument?
>> >>
>> >> in the user's view of payment instrument, for example, credit card is
>> >> one of payment instrument.
>> >> google wallet(or apple pay) is the container of payment
>> >> instruments(credit card and/or more)
>> >>
>> >> I thought that the container is the wallet.
>> >>
>> >> to process credit card payment, users may choose google wallet(or
>> apple pay..) when merchant accept it.
>> >
>> >
>> > OK, I think it's clear that nobody is talking about the same thing
>> > here :)
>> >
>> > I think the term "wallet" and "payment instrument" will only make sense
>> in the context of a particular concrete proposal. Right now things are too
>> ambiguous for any consensus. I am going to stop worrying about this.
>> >
>> > Brett
>>
>>
>>
>
>