- From: Daniel.Buchner <Daniel.Buchner@target.com>
- Date: Thu, 23 Oct 2014 19:37:29 +0000
- To: Manu Sporny <msporny@digitalbazaar.com>, "public-webpayments@w3.org" <public-webpayments@w3.org>
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/
Received on Thursday, 23 October 2014 19:38:00 UTC