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

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

Received on Wednesday, 30 July 2014 12:13:11 UTC