Re: Multiple Wallets

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

Received on Monday, 3 August 2015 14:33:14 UTC