Re: Multiple Wallets

Hi Joseph,

Since it's unclear if the passive-aggressive tone of your email is
intentional or not I'll do you the courtesy of responding anyway.

The charter and FAQ you are analyzing are for a working group with a very
specific scope of work that it is a subset of the greater scope of work
payments that the IG is interested in. Specifically, the WG is aiming at
standardizing some interfaces between Web applications and user-agents for
exchange of messages that may be used to complete a payment in a more
efficient manner than is done today. That is all.

In doing this it is impossible to proceed without considering the actors
immediately connected to the Web application (such as payment processors)
and user agent (such as wallet services) and their requirements in
completing a payment over the Web so that the interface that is in scope
can accommodate these.

To be clear, this group is lazer focused on payments and the minimal set of
messages and data that must be exchanged to complete a payment. eCommerce
is a far wider domain and the WG has explicitly chosen to limit it's scope
to not include everything in that domain.


On 3 August 2015 at 18:03, Joseph Potvin <jpotvin@opman.ca> wrote:

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

I think Manu has answered this appropriately. The definitons you give are
legalese that are from a legal standards body and are not useful (in my
opinion) in the charter of a WG that is working on Web standards the
primary audience of which will be developers.


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

Why do you consider a definition from "the top-echelon global standards
body on e-commerce law" more useful than one defined, refined and captured
by the group who will need to refer to the definition in completing their
work? UNICTRAL are a valuable resource for the IG but I would argue have
very little overlap with the WG.


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

I don't see the issue. We will define the minimum required functions of the
service we are calling a wallet. i.e. Enough to be able to accommodate the
interface we will define. We will not rigorously define the wallet's
functions. i.e. We will not define exactly what functionality the wallet
will have (only the minimum required) so that we leave room for
functionality that wallet service implementors can dream up to innovate in
this area.


>
> 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 phrase payment instrument is linked to the definition in the use cases:
http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#dfn-payment-instrument


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

I disagree. The definition of payment instrument is quite abstract and
allows for a scheme to define it however they like as long as it can
fulfill the functions that will be implicit in the standard. While the
standard does not yet exist it appears these will be things like:
identifiable (have a way of differentiating one instrument from another),
serialisable (able to pass an instance or reference to an instance in the
messages).

Beyond that the scheme will define any additional behavior that is required
to use a payment instrument to process a payment. The payment processor and
wallet service will need to be able to execute that scheme defined logic in
order to claim support for that scheme.


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

Correct. Which is why the scope of this WG is intentionally focused as it
is on a very specific set of interactions that, if standardised, will
remove a roadblock to more efficient online payment systems and development
of new and better payment schemes and instruments specifically target at
use on the Web.

This WG is not concerning itself with identity, commerce, invoicing,
receipts, proof of payment or any other of the many issues that are part of
"the realm of payments". The WG is concerning itself with a more efficient
exchange of data between payer and payee to facilitate further advancements
in all of these areas in time.


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

Thanks, but for the purposes of this WG I don't think we will. I appreciate
the sentiment but as I have said in many round-about ways thus far you are
confusing the work of the WG with the wider scope of the IG and therefor a
lot of the criticisms you are leveling at the charter and FAQ are simply
misplaced.

Adrian



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