- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Wed, 30 Jul 2014 09:51:36 -0400
- To: Adrian Hope-Bailie <adrian@hopebailie.com>, Web Payments CG <public-webpayments@w3.org>
Adrian, RE: "The way this will be expressed and calculated requires some pretty serious thought"... :-) Yup. I'm currently up to my knees it, writing my doctoral disseration at UQuebec entitled "Free/Libre/Open World Market Payment: A Model of Potential Arrangements and Emergent Effects". We'll be modeling this with MASON Lagom regiO http://www.alde.es/encuentros/anteriores/xveea/trabajos/p/pdf/96.pdf RE: Version 1 Scope: Explicit data provided between the payer and payee Version 2+ Scope: Introduce calculated data and rules for calculation. That seems like a coherent way to organize the process, but I wonder if the structure you describe is what you fully intend? The WM Reuters Spot Exchange Rate is a calculated item. Do you mean that Version 1 should not include any reference to an exchange rate? RE: Your illustration of Version 2 as: Channel:PayPal - Prices [EUR 30, CND 48.03] - Supported currency conversion indexes: [http://paypal.com/indices/EURIndex or http://anotherplace.com/EUR] There are two contexts in which to handle value-in-exchange benchmarking: via currency-conversion, and via contract terms. By handling it in currency conversion as you illustrate, this limits the issue to multi-currency transactions, and places it legally under capital controls law. Handling it as algorithmic pricing in contracts, it also includes time-deferred payment use cases (eg payment installments) and keeps it legally under contract law. It seems to me this would be both more useful to business, and less complicated legally. -- Joseph Potvin Operations Manager | Gestionnaire des opérations The Opman Company | La compagnie Opman jpotvin@opman.ca Mobile: 819-593-5983 On Wed, Jul 30, 2014 at 8:53 AM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote: > 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/ >> > >> >
Received on Wednesday, 30 July 2014 13:52:23 UTC