Re: Legacy systems vs blockchains - what is the spec impact?

On 10/23/2014 12:40 AM, Daniel.Buchner wrote:
> Hello Web Pay-ers,

Hey Daniel, I don't know if you remember, but we spoke about 8+ months
ago about the Web Payments stuff when you were at Mozilla. I'm very glad
to see that you've joined the Web Payments CG and are engaging the group. :)

Also, congratulations on getting Target to join the W3C:

http://target.github.io/standards/target-joins-w3c/

For those that are are not in the US/AU/CA, Target is one of the top 10
retailers in the world and Daniel was behind getting the first major
retailer in W3C history to join.

> My first question for the group after last reviewing these specs
> over a year ago:

One thing to keep in mind is that the specs are lagging the
implementations by many months. Just keep that in mind while we go
through the discussion. In the future, refer to the specs you're
concerned about and we can tell you whether or not they reflect current
thinking.

> How much are they crafted around traditional payment systems vs new
> tech like blockchains?

They're designed to be payment instrument agnostic. They should work
just as well for traditional payment instruments as they do for
blockchain-based payment instruments. If they don't, we've failed at
designing something that's going to scale into the future.

> More specifically, if for a moment you imagine a world where
> payments happened /primarily /over a shared blockchain, would
> significant portions of these specs be irrelevant without the
> encumbrance of legacy payment systems?

The short answer is, no. Most blockchains fit into the "back-end
clearing" technology box. They don't fit neatly into that box, but
blockchains are usually not considered front-end technologies like a
detailed machine-readable offer of sale, mobile phone interface for
puchasing a product, or a digital receipt proving that a particular
purchase is valid.

The current Web Payments CG and Credentials CG specs have more to do
with the following:

1. Expression of digitally verifiable claims via credentials (like
   proof-of-age, government ID cards, corporate ID cards, proof-
   of-skillset, etc.)
2. Expression of Offers of sale on the Web
3. Payment initiation on the Web
4. Digital receipts (confirming payment across multiple payment
   instruments)

It is true that you could probably get rid of most of #3 and #4 if you
were using a single blockchain, like the Bitcoin blockchain, but that's
not the world we live in today (nor will it be the one we live in in the
future).

Even if one predicts that the only payment instruments in the future
will be blockchain-based, there will almost certainly be more than one
type of them with different mechanisms to verify when a transaction is
valid. For example, with one chain one might assume 6 verifications,
another might need 30. So, you end up needing #3 and #4 again even in a
world that only uses blockchains for payment instruments.

The realization that this community has come to over the 4+ years that
it's been operating is that there will never be only one way of doing
payments, and so, the specifications that we're building shouldn't
assume that.

In addition, it's important to support the current payment instruments
that exist today, such as fiat-based payments, credit cards, ACH, etc.,
while also ensuring that the payment standard takes other more
future-facing technologies into account like blockchains, sidechains,
smart contracts, DAOs, etc.

Hope that helps clarify the difference a bit. You may find the following
document useful for a quick overview of the technologies involved:

https://web-payments.org/specs/source/roadmap/

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: High-Stakes Credentials and Web Login
http://manu.sporny.org/2014/identity-credentials/

Received on Thursday, 23 October 2014 17:21:14 UTC