- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Wed, 30 Jul 2014 08:12:23 -0400
- To: Manu Sporny <msporny@digitalbazaar.com>, Web Payments CG <public-webpayments@w3.org>
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