Re: VOTE: Revised Payment Initiation / Wallet Web Payments Workshop Use Cases

Joseph,

I unfortunately can't make the call today but here is my take on this.
Version 1 of the spec should cater for explicit data provided between the
payer and payee and in later versions introduce calculated data and rules
for calculation.

Version 1
As the payer I get presented with a number of payment options from the
payee (in the form of a machine readable document - probably JSON-LD).
I select the option I prefer and make the payment.
If the payee offers payment in different currencies or requires different
amounts to be paid based on the channel then they must all be listed.
i.e. In your example my options may be:
Channel: PayPal
 - Prices [EUR 30, CND 48.03]

As the payer I know I am providing a payment instrument that will be
charged in CDN so I know that I will only find out what the conversion rate
is when the transaction completes if I choose the EUR price.
This at least gives us what is available today.

Version 2
Introduce calculation rules.
Each payment channel now offers payment options including rules about how
conversions will be done.
Channels can provide multiple sources of conversion rates and the payer
picks the one they want used.
Ultimately this may evolve into smart contracts that could specify a date
to make the conversion etc etc

My options may now be:
Channel:PayPal
- Prices [EUR 30, CND 48.03]
- Supported currency conversion indexes: [http://paypal.com/indices/EURIndex
or http://anotherplace.com/EUR]

This is all very simplified but I hope it illustrates the theory.
The way this will be expressed and calculated requires some pretty serious
thought and a whole swathe of new use cases.
Hence, I'm inclined to put it out to a later version.

Adrian



On 30 July 2014 14:12, Joseph Potvin <jpotvin@opman.ca> wrote:

> Manu, Thanks, I'll be on today's call. In summary, here are five
> points I request that the group consider:
>
> 1. To its credit, Paypal already implements this use case. For the
> screenshots of the Paypal process that I presented in Paris, please
> see: http://www.w3.org/2013/10/payments/slides/session4_potvin.pdf   I
> suggest that a W3C spec for this use case can be both simpler and
> fully generic (i.e. not limited to just the two choices that the
> payment intermediary determines to present).
>
> 2. The global market is moving in the direction I'm describing. For
> one example, here's an announcement just this week about a bitcoin
> derivative anchored to a primary commodity benchmark: http://uro.io/
> [1]
>
> 3. There exists no "true exchange rate". It's just an algorithm
> maintained by a private self-interested consortium, and is subject to
> manipulation:
>
> http://www.theguardian.com/business/2014/jul/21/foreign-exchange-trading-criminal-investigation-serious-fraud-office
>
> 4. A decision to defer this use case is a de facto decision to have
> V1.0 of the W3C spec accommodate payments intermediaries restricting
> payees and payers to a benchmark that is known to be manipulated, and
> also to accommodate arbitrary skimming from every transaction. In a
> market, choice of benchmark is the prerogative of the parties to the
> contract to determine, not the payments intermediaries. Of course
> payments intermediaries do have every right to be fully compensated
> for their services, but a W3C standard ought not to conflate the
> intermediary's fee-for-service (a micro-economic concept) with the
> monetary value-in-exchange benchmark (a macro-economic concept).
> Defaulting those two together subverts the objective of transparency
> and fairness in web payments.
>
> 5. If there has been industry push-back against this use-case, it may
> have been behind closed doors and not in the open discussion fora. As
> far as I can tell we've seen no reasons presented against it, but this
> might be because this level of transparency is more controversial than
> might be comfortable in open discussion. So, IF the concern is that
> including this use case would de-rail the entire schedule for v1.0 of
> the spec, I propose that deferral be explicitly attached to a process
> towards open deliberation and resolution, linked to a schedule.
>
> - - -
>
> [1] Background: I've not been involved in http://uro.io/ but I am busy
> helping various teams to operationalize fundamentally different
> value-in-exchange benchmarks, including commodity-based ones. If
> you're interested in the commodity-based concept generally, here's a
> short overview that I co-authored back in 2009:
>
> http://www.theglobeandmail.com/globe-investor/investment-ideas/commodities-as-a-global-currency/article1346127/
>   Since 2009 in discussions with people in banking and monetary
> systems-design, we've realized the practicality of de-coupling
> unit-of-account from value-in-exchange benchmark. If you've ever been
> in a country that had a so-called "black market" offering exchange
> rates different than the banks, that's what de-coupling looks like.
> I'll be happy to elaborate on legally sound vs legally problematic
> ways to approach this.  My interventions with the W3C CG on this topic
> benefit from discussions in other venues about how to approach this
> use case well-within bounds existing statute and case law.
>
>
> --
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca
> Mobile: 819-593-5983
>
> On Tue, Jul 29, 2014 at 11:19 PM, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
> > On 07/22/2014 08:50 AM, Joseph Potvin wrote:
> >> RE: Use Case: A merchant advertises different details, such as price,
> >> for an offer of sale based on potential payment processor choice.
> >>
> >> I wish to ask if the "value-in-exchange benchmarking" issue I
> >> presented about in Paris is intended to be incorporated in this use
> >> case, or is benchmarking elsewhere and I haven't noticed?
> >
> > The value-in-exchange benchmarking issue was deemed to be out of scope
> > for the first iteration (and is something that could be implemented by
> > payment processors w/o it being mandated via a specification). We don't
> > know if it's a good technical design to mandate it in the specification
> > because we can't really police it via technology. It's a policy
> > decision, not a technological one.
> >
> > I've added the use case you mentioned back into the list for further
> > discussion:
> >
> >> Use Case: Payee and payers negotiate secure price in an open market.
> >>  They are free to choose all three essential attributes of the
> >> numeric quantity expressing a price (e.g. 10.99), namely: a
> >> unit-of-account (e.g. $ £ € ¥ etc.); a medium-of-exchange (e.g.
> >> debit card, credit card, web payment etc.); and, a value-in-exchange
> >> benchmark (e.g. WM Reuters Spot Exchange; Purchasing Power Parity;
> >> Commodity Index; etc.)
> >
> > It's already agreed that we will support listing the unit-of-account,
> > and medium-of-exchange. I guess we could also support value-in-exchange
> > by providing an index URL along w/ the price of the good... so the way
> > one /could/ list items for sale is:
> >
> > "payee": [{
> >     "id": "http://example.com/articles/1#offer-payee",
> >     "type": "Payee",
> >     "currency": "USD",
> > *** "priceBenchmark": "https://reduters.com/spot-exchange-rates",
> >     "destination": "https://payswarm.example.com/i/bob/accounts/primary
> ",
> >     "rate": "0.05",
> >     "rateType": "FlatAmount",
> >     "comment": "Payment for PaySwarm in Practice by Digital Bazaar."
> >   }],
> >
> > We'll discuss in more detail on tomorrows call.
> >
> > Who sets the value-in-exchange benchmark? The payer or the payee?
> >
> > -- manu
> >
> > --
> > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> > Founder/CEO - Digital Bazaar, Inc.
> > blog: The Marathonic Dawn of Web Payments
> > http://manu.sporny.org/2014/dawn-of-web-payments/
> >
>
>