Re: Update: Five Attributes of Payment

RE: "The ability to attach the payment to a URI for any benchmark of choice
needs to be part of the W3C spec."

Here's how this is addressed in an essential reference for international
trade: the "UNIDROIT Principles of International Commercial Contracts"
http://www.unidroit.org/english/principles/contracts/principles2010/integralversionprinciples2010-e.pdf

Page 158:  "Determination of price by reference to external factors: In
some situations the price is to be fixed by reference to external factors,
typically a published index, or quotations on a commodity exchange."

-- 
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983

On Tue, Sep 9, 2014 at 7:02 AM, Joseph Potvin <jpotvin@opman.ca> wrote:

> Some follow-up replies interline, identified with [JRP]:
>
> On Mon, Sep 8, 2014 at 8:47 PM, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> On 08/31/2014 01:36 PM, Melvin Carvalho wrote:
>> > Joseph Potvin wrote: Further discussion and research on this topic
>> > (including research in economics and law towards my doctoral
>> > dissertation at U Quebec), as well as consideration of various ideas
>> > raised on these lists, has led me to include five attributes.
>> >
>> > Thanks for sharing.  I'll give my understanding of the answers to
>> > your questions, but it's just my opinions ...
>>
>> More opinions, some facts follow:
>>
>> > 1.
>> >
>> > _S__cal__ar __quantity_ (e.g. 10.99; 0.0001099—/Can the parties
>> > //specify////micro payments //to //their//chosen//number of decimal
>> > places//?/)
>> >
>> > Yes.  xsd decimal is arbitrary precision
>>
>> All of the technologies that have a serious amount of consideration in
>> the Web Payments work support arbitrary precision in the expression of
>> the scalar quantity.
>>
>
> [JRP]: Agreed, that's part of what makes this work interesting.
>
>>
>> You should note that some technologies like Bitcoin aren't arbitrary
>> position, precision is at 8 decimal places right now, but can be
>> extended based on the consensus of the network (most of Bitcoin's limits
>> can be raised using this approach).
>>
>
> [JRP]: Of course.
>
>>
>> > /Can //contracting //parties //to //implement //algorithmic pricing
>> > //to their chosen specifications//? /;
>>
>> I don't quite understand this question. If you're asking "can an
>> algorithmic pricing algorithm operate assuming arbitrary scalar quantity
>> values?", the answer is "yes, assuming that the currency supports
>> arbitrary scalar values".
>
>
> [JRP]: And assuming the payments system does not make this terribly
> diffiicult to operationalize.
>
>
>
>> Most currencies don't support arbitrary scalar
>> values. For example, USD is really only good to a few decimal places,
>> having 100 doesn't really buy you much. Bitcoin is a bit better wrt. how
>> many decimal places you have available to you, but its still not
>> "arbitrary precision" in practice today.
>>
>
> [JRP]: What I'm saying is the specification of parameters for the scalar
> values is something for the parties to a contract to determine, not the
> architects of the monetary system. What this means, however, is that the
> architects of the monetary system ought to build "use choice" of parameters
> into the architecture. Hard-coding to 2 decimal places is like hard-coding
> browsers to 25 colors.
>
>
>> You should clarify the second question you're asking because it's vague.
>>
>
> [JRP]: Will do.
>
>>
>> > _U__nit-of-account_ (e.g. $ £ € ¥ etc. Are contracting parties free
>> > to //price and pay in//their //unit //s////of choice?
>> >
>> > Yes currency is anyURI or a 3 letter ISO code.
>>
>> They're free to price it in units of their choice.
>
>
> [JRP]:  Normally. But that might not always be the case in parrticular
> applications (de facto), or in partciular jusdictions (de jure).
>
>
>> They may not be free
>> to pay in their unit of choice (depending on if the payee accepts the
>> units directly).
>
>
> [JRP]: Payee ultimately trumps payer in choice of unit, that's clear.  If
> payee lists 4 currencies as acceptabe, then the payer has a choice amongst
> those 4.
>
>
>> Third parties (such as the payment processor) could be
>> used to broker the conversion.
>>
>
> [JRP]: Yes, I always recommend to de-construct that process though. It's
> not a single step, and not a single 3rd party. It includes the requirement
> for a benchmark. Who determines the choice of benchmark? Who designs it?
> Who supplies that service?
>
>
>>
>> > //Can the unit//of payment//be //one that is self-defined//by the
>> > contracting parties, and/or //can it be from a non-traditional
>> > provider//?//)/;
>>
>> The Web Payments technologies certainly can allow the unit to be
>> self-defined or non-traditional (aka a private currency).
>
>
> [JRP]:  Some do. In all of this, I'm saying that all these capabilities
> ought to show up somehow in the spec. Otherwise, parties to contacts can
> find their legitimate market freedoms restricted by "standard-compliant"
> web payents servcies providers who are contraining market freedom.
>
>
>> Keep in mind
>> that this may be heavily restricted by federal law or international law.
>
> The technology gives the issuer the option, but leaves the legality of
>> the instrument up to the issuer.
>>
>
> [JRP]: Exactly. This is to be determined by jurisdictional authorities,
> not by W3C or by payment service providers. It might be useful for generic
> web payments specs however to pro-actively accommodate jurisdiction-based
> restrictions -- not to impose them, but rather to standardize and ensure
> some elegance to how jurisdications implement such restrictions, so that
> all the helpful notices to end-users show up in expected ways. This is not
> to say that I'm a fan of restrictions, but rather that since countries do
> have legal authority to impose restrictions, let's at least make it
> structured rather than ad hoc.
>
>
>>
>> > _V__alue-in-exchange benchmark_ (e.g. WM Reuters Spot Exchange
>> > Index; Purchasing Power Parity Index; Commodity Index; Earth Reserve
>> > Index, etc.—/Can//contracting parties benchmark //the scalar quantity
>> > of //payment to //any//market factors they deem to be relevant //to
>> > the //duration//and //object//of the contract//?/);
>> >
>> > If someone can create a URI out if it then sure.  Indexes are not
>> > always 100% accurate tho.
>>
>> Yes, but the question remains: is this a part of the standard or
>> something that's added on after the fact.
>
>
> [JRP]: The ability to attach the payment to a URI for any benchmark of
> choice needs to be part of the W3C spec. What's out at those URI is
> external to the W3C spec.
>
> Joseph has been arguing that
>
>> it should be a part of the standard.
>
>
> [JRP]:  No, I'm simply observing that it's logically inevitable. You can't
> logically have time-deferred payments without the ability to cite a
> benchmark. You can't logically have 2-currency or multi-currency markets
> withouth the ability to cite a benchmark. The impression that these are
> possible without a benchmark is an impression that comes from taking "the
> exchange rate" for granted, as if it's something other than just a
> benchmark from an algorithm.
>
>
>> Digital Bazaar, while agreeing that
>> this work is important, is concerned that there isn't enough engineering
>> work behind it to solve this problem along with all of the other
>> problems that need to be solved. It suffers from a lack of engineering
>> backing and implementations.
>>
>
> [JRP]:  Somehow I'm failing to communicate that the WM Reuters Spot
> Exchange Rate is just a benchmark maintained by a group of companies. And
> somehow, I guess due to how I'm expressing this, it seems like a
> complicated engineering feat to let payees and payers de-couple from the WM
> Reuters Spot Exchange Rate, and benchmark their inter-currency transactions
> instead to the World Price Index
> http://www.worldeconomics.com/WorldPriceIndex/WPI.efp   Or, to some other
> index they prefer.  To me this seems exceedingly simple.
>
> Manu, can you explain what's complicated about accommodating payees and
> payers to associate their inter-currency payment to the WPI instead of the
> WM-Reuters index?
> And if they can chose the WPI, what's complincate about letting them set
> up their payments preferences to other index they might prefer, availble
> via a URI?
>
> When you way "lack of engineering", do you mean that this sort of choice
> is complicated in Digital Bazaar's software in particular, so that it needs
> to be re-engineered? Do users of Digital Bazaar's payments solution, or
> RippleLabs's solution, have no escape from
> http://www.bloomberg.com/news/2014-08-13/banks-said-to-get-enforcement-letters-in-fx-rigging-probe.html
> ??
>
> On what grounds would a W3C spec block payees and payers from benchmarking
> their payment arrangements against something other than a known corruptable
> index? Because the payment solutions providers haven't implemented this
> yet?
>
>
>> > _Transaction__depositories_ (eg physical wallet; digital wallet;
>> > digital bank account, etc.—/Do contracting parties have the ability
>> > to decide //upon and control //the origin and destination nodes for
>> > their payments?/); and,
>> >
>> > Source and origin are again anyURI so it can be anything.
>>
>> I believe the answer to this question is "yes", as Melvin said. I'm a
>> bit concerned that the question is a bit vague. What does it mean to be
>> a "node"? Is that a bank account? A reference to a bank account? Does
>> the node contain the actual "true" amount in the account (such as a
>> cryptocurrency value), or a reference to an account value (such as a
>> bank account value)?
>>
>
> [JRP]:  I dunno. Needs thinking.
>
>>
>> > _M__edium-of-exchange_(e.g. debit card, credit card, giro, cash,
>> > etc.—/Are media-of-exchange options documented effectively to enable
>> > informed user choice?
>>
>> "Documentation" is up to the merchant and the payment processor, no
>> standard can enforce that things be properly documented. The
>> specifications that we have right now do allow for the media-of-exchange
>> options to be offered to the customer and merchant. I don't think we can
>> safely say that they "effectively enable informed user choice" - that's
>> a user experience/interface issue (and the spec probably shouldn't
>> mandate things like that).
>>
>
> [JRP]: The certainly can be minimum equivalent neutral documentation req's
> -- like ingredients labelling in food, and effects documentation that has
> to be provided with prescription meds.
>
>
>>
>> > Do contracting parties have //practical //access to choice //amongst
>> > //medi//a//-of-exchange?/)"
>>
>> Hard to say until the system is deployed. If a merchant only offers
>> payments via credit card, then no. If a merchant offers at least 3-5
>> different options, then we could say "yes".... but what does "practical
>> access to choice" mean? What number of media-of-exchange options does
>> one have to offer to meet the "practical access to choice" bar?
>>
>
> [JRP]: Of course -- for the merchant. The point here is whether the
> payments system accommodates payee and payer choices. Currently here in N
> Am we generally can't pay with our smart phones the way they can in Kenya.
>
>
>> -- 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/
>>
>
>
>
> --
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca
> Mobile: 819-593-5983
>