Re: Update: Five Attributes of Payment

On 09/09/2014 07:02 AM, Joseph Potvin wrote:
>> _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.

I don't think it can be external, can it? I mean, if all we have to do
is put a URL in there and ignore what's at the end of it, that's simple
to do. However, I don't think you're going to get what you want as a
result of doing that. It moves the problem from one that a machine can
solve automatically to one that requires human intervention.

Let me try and provide an example:

{
  "amount": "5.00",
  "currency": "USD",
  "priceBenchmark":
    "https://example.org/benchmarks/usd?start=2014-09-17T03:24:14Z"
}

Effectively, the above says "the value of $5 USD according to the
benchmark listed in 'priceBenchmark' on 2014-09-17 at 3:23:14am Zulu time.

So, that's how I would expect we would express a price in a smart
contract that's pegged to a non-standard benchmark. Doing that in a
human-readable way is simple, I agree.

However, I thought what you also wanted to do (which is the more
interesting thing, I think) is to also define a protocol as to how you
use that "priceBenchmark" URL to transform the amount shown above into
the value at any arbitrary future date (as long as the price benchmark
continues to exist). If we do that, then all prices can be automatically
price benchmarked. It would allow software agents to automatically
determine what the current value is by querying the price benchmark URL.

For example, getting the price a year later:

https://example.org/benchmarks/usd?amount=5.00&start=2014-09-17T03:24:14Z&end=2015-09-17T03:24:14Z

Could return something like this (a year later):

{
  "amount": "5.15",
  "currency": "USD",
  "priceBenchmark":
    "https://example.org/benchmarks/usd?start=2015-09-17T03:24:14Z"
}

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

+1, I agree with you, which is why I assumed that the only logical
argument is to make it a part of the standard. :)

What we could do, instead, is to not support time-deferred payments in
version 1, and then put them in 2 years later in version 2.

Another alternative is to not define the protocol and just say "there
exists a URL with a price benchmark of some sort", but that proposal
seems a bit toothless. At worst, you'd have all sorts of formats pop up
at the end of the URL.

Another alternative is to draft the protocol, but not take it on the
standards track until we have more experience w/ what people would
expect at the end of price benchmark URLs (which might be the best option).

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

No, I think you've clearly communicated that.

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

It's simple if we're just talking about a URL. It's not simple if we're
talking about a corresponding protocol for querying the benchmark in
near-real-time.

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

Hopefully what I've said above helps clarify. The complicated bit isn't
putting the URL in there, it's the protocol and what clients MUST and
MUST NOT do as a result of the priceBenchmark value.

For example, if the URL exists, then you could construe that as a
contractual term "a payment processor MUST honor this price according to
this price benchmark". Is it legal for a payment processor to ignore the
price benchmark if it's not available? Is it legal to cache the price
benchmark for an hour at a time? Is it legal for a payment processor to
ignore the price benchmark if they want to and use one of their own? We
have to figure out the answer to all of these questions, get consensus
on it, and create the technology around it.

If we do that, will Web developers or the financial industry implement
it, or will they find it too complicated? I hope you can see that this
isn't as simple as just mentioning a URL and claiming victory.

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

Payment preferences are outside of the scope of the specs we're talking
about, which is good, because it'll be up to the payment processor to
determine how to do this in the way that best serves their customers. I
agree that this part isn't that complicated to do.

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

No, I imagine that it would be fairly simple to implement once the
protocol is hammered out. The protocol being hammered out will take time
and expertise that we do not have in version 1.

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

I /think/ Ripple has solved this problem. The exchange rate on Ripple is
a result of the open orders on the network and isn't tied to any FX
index, IIRC.

For the Web Payments stuff, version 1 may not support price benchmarking
unless someone steps forward and proposes a solid protocol and spec for
how this should work. I can't speak for any other company, but if
someone solves the problem in an elegant way, writes the spec, gets
consensus, and stands up a test suite, Digital Bazaar would most likely
be among the first to implement the feature.

> On what grounds would a W3C spec block payees and payers from 
> benchmarking their payment arrangements against something other than
>  a known corruptable index?

On the grounds that we (the Web Payments community) don't currently have
the resources to implement a proper solution. It happens all the time.
We've all known for years that payments on the Web has been broken, but
it's only recently that we've been able to get around to trying to fix
the problem.

> Because the payment solutions providers haven't implemented this 
> yet?

No, I don't think that's the issue. The issue is priorities, time, and
money.

Don't let this discourage you, it's just my opinion, and I want to see
this feature in the Web Payments work. I personally don't have the
funding to make it happen in version 1.

Most of the spec development for the Web Payments work has come about
because Digital Bazaar took it upon itself to dump lots and lots of
money and time into designing and creating the technology, writing the
specs, doing implementations, creating test suites, and then releasing
it under a royalty and patent-free license. We can only work on so many
things at the same time given the resources that we have. If someone
threw $50K at the problem, I imagine that it could be solved quickly and
completely.

-- 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 Thursday, 18 September 2014 01:32:27 UTC