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

Manu,

A few snippets from your reply to Daniel could be usefully included in the
slide deck you'll be presenting. For example:

__________
The current Web Payments CG and Credentials CG specs:

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)
___________

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.

____________

[This one I've edited with some suggestions...]

It's important to support the current payment instruments that exist today
(eg credit cards, ACH, etc.), and the established value benchmarks (eg WM
Reuters Spot Rate) while also ensuring that a common payment standard takes
other more future-facing solutions into account like blockchains,
sidechains, smart contracts, DAOs, etc., as well as new methods for
algorithmic pricing and benchmarking.

Regards,

Joseph Potvin, M.Phil. MCPM
Doctoral Candidate, Project Management
Université du Québec

Chair, OSI Management Education Working Group

Coordinator, The FLOW Syllabus
http://wiki.opensource.org/bin/Projects/flow-syllabus

The Open Source Initiative

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



On Thu, Oct 23, 2014 at 3:37 PM, Daniel.Buchner <Daniel.Buchner@target.com>
wrote:

> Thank you for the detailed response Manu,
>
> This is exactly what I was hoping for when I asked. As a representative
> for a retailer that is concerned with all current and future payment types
> (as this group is), I was trying to get more clarity around how the group
> envisioned these specs working with emerging payment systems/flows. Per
> Manu's description (and from briefly reviewing them at a highlevel), it
> appears the specs are super set of APIs/flows that make payment systems
> pluggable (even if those systems technically don't require some of the
> included flows to transact value, receipts, etc.)
>
> As Manu knows, blockchain tech interests me personally - it has for years
> now, but I will remain objective and practical in my interactions here (as
> is required, given Target's needs). Thank you for providing me with a
> better sense of where the group is currently at. I will gather more
> specific questions and feedback for the discussions at TPAC next week.
>
> - Daniel
>
>
>
>
>
> ________________________________________
> From: Manu Sporny [msporny@digitalbazaar.com]
> Sent: Thursday, October 23, 2014 10:20 AM
> To: public-webpayments@w3.org
> Subject: 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/
>
>
>


<819-593-5983>