W3C home > Mailing lists > Public > public-webpayments@w3.org > May 2015

Re: [Payments Architecture] A vision statement for the web payments architecture work

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Tue, 26 May 2015 16:31:43 +0200
Message-ID: <CA+eFz_Jj4=3T_Ac5JVcWs5h0-yLea41fcAmUcNmhB7JwRCYQHw@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Antonio Ruiz Martínez <arm@um.es>, Web Payments CG <public-webpayments@w3.org>
How does this change the fact that when sending value over the Web the
analogy with the Web of today and sending of information breaks down? There
is no double-spend problem to overcome in designing a system to send email
over the Internet.

On 26 May 2015 at 16:10, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

>
>
> On 26 May 2015 at 15:50, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
>
>> One must remember that this analogy breaks down when you consider that
>> data can be replicated infinitely and yet we want to send "value" in a way
>> that it can only be sent once and once it has been sent it is held be the
>> receiver.
>>
>
> Data cant be sent infintiely, since storage is finite.  Data can be
> replicated, however, to very large degrees.  This is part of what we call
> the "open world assumption" [1].  Out of this mass of data comes a
> consensus, for it to be useful.  This is either top down through central
> authorities.  Or bottom up, in a self organizing way, which is the design
> philosophy of the web.  We've seen both system work as a hybrid solution on
> the web.
>
> [1] http://en.wikipedia.org/wiki/Open-world_assumption
>
>
>>
>>
>>
>> On 26 May 2015 at 15:32, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 26 May 2015 at 13:03, Adrian Hope-Bailie <adrian@hopebailie.com>
>>> wrote:
>>>
>>>>
>>>>> The second is explicitly calling out the need for the architecture to
>>>>> allow payers and payees to make a transfer of value between one
>>>>> another,
>>>>> even if they don't have a common payment instrument or scheme. i.e. The
>>>>> Web must work like the Web is supposed to and have a mechanism to fill
>>>>> the gaps and comment the two.
>>>>>
>>>>
>>>> With this explanaition I understand your idea. But, from my point of
>>>> view, in the end, this is making a kind of "P2P payment", which we could
>>>> consider as a new payment scheme.
>>>>
>>>> +1 Yes. I wouldn't say it has to be P2P (person to person) it could be
>>>> a business or government or any other entity on either end of the payment
>>>> but the point is we ARE suggesting that there be a new payment scheme,
>>>> called the Web. It will provide the glue between existing schemes so we
>>>> have a truly decentralized system as Melvin suggests.
>>>>
>>>
>>> There's two aspects of the web, one is the glue and one is the core.
>>> Just like UNIX has a kernel and drivers.
>>>
>>> If you consider every HTTP request returns a number of bytes, which are
>>> information.  This is transferring something of value.  Extending the core
>>> of the web to be agnostic to what items of value are transferred.  At the
>>> same time the web acts as a very good glue and can incorporate existing
>>> payments systems on a per need basis, much as webmail incorporated email.
>>>
>>> Different teams will work on different aspects.  The part that intersts
>>> me is stitching payments into the fabric of the web itself (if it isnt
>>> already) and sharing common patterns and experiences.  Probably to start
>>> with the frameworks around existing payments will be the bigger work.  But
>>> to see that in the context of a decentralized web will hopefully allow
>>> incentives to become aligned with value creation, with less friction.
>>>
>>>
>>>>
>>>>
>>>>
>>>> On 26 May 2015 at 11:13, Antonio Ruiz Martínez <arm@um.es> wrote:
>>>>
>>>>> Hi Adrian,
>>>>>
>>>>> First of all, many thanks for you comments and explanations.
>>>>>
>>>>> El 22/05/2015 a las 15:27, Adrian Hope-Bailie escribió:
>>>>>
>>>>>> Hi Antonio,
>>>>>>
>>>>>>     After reading the current version of the document, I have some
>>>>>>     comments and suggestions that I would like to share. I hope they
>>>>>> are
>>>>>>     useful.
>>>>>>
>>>>>>
>>>>>> Thanks for your input
>>>>>>
>>>>>>     - Regarding user experience, I would mention that the payment
>>>>>>     process (initiation, purchase, obtaining a receipt and the
>>>>>>     product/service) should be uniform so that the user can see the
>>>>>>     process is conducted in the same way and, thus, it generates trust
>>>>>>     to the users. I do not know if this is what you want to mean with
>>>>>>     "harmonizing the checkout experience across e-commerce websites."
>>>>>>
>>>>>>
>>>>>> Yes, this is what that sentence is intending to say. Perhaps
>>>>>> "harmonizing the payment experience across all Web applications and
>>>>>> sites."
>>>>>>
>>>>>
>>>>> it sounds ok.
>>>>>
>>>>>
>>>>>>     I would also include that it should facilitate that the user can
>>>>>>     know the payment options available and even the (automatic)
>>>>>>     negotiation of these options.
>>>>>>
>>>>>>
>>>>>> Is this not covered under the bullet: "*Provides payees and payers
>>>>>> unencumbered knowledge and choice in how to undertake payments*"?
>>>>>>
>>>>>
>>>>> May be.
>>>>>
>>>>>
>>>>>>     - I would also incluse some comment on that the way of making the
>>>>>>     encapsulation of (new or existing) payment schemes should be
>>>>>> uniform
>>>>>>     and independent of the type of payment scheme (mobile or not).
>>>>>>
>>>>>>
>>>>>> I think this is implied by the fact that we are "standardizing" this
>>>>>> process.
>>>>>>
>>>>>>     - From my point of view, I do not why know why the document needs
>>>>>>     the bullets "Enables monetization on the spectrum of Web to native
>>>>>>     apps" and "Bridges distributed value networks should part of the
>>>>>>     vision.". From my point of view, these issues are a consequence of
>>>>>>     "Encapsulates existing payment schemes and enables new schemes. "
>>>>>>
>>>>>>
>>>>>> No, the first bullet you mention is explicitly talking about enabling
>>>>>> new business models on the Web due to the reduction in friction and
>>>>>> cost
>>>>>> of payments (monetization). This speaks to things like enabling
>>>>>> pay-per-click/read/watch/listen media consumption or
>>>>>> similar which
>>>>>>
>>>>>
>>>>>
>>>>> This last explanation is clearer since the previous one, in my
>>>>> opinion, do not involve something clear related to the defintion of the
>>>>> payment architecture.
>>>>>
>>>>>  can't be easily done today because the way payments are
>>>>>> processed makes these business models non-viable.
>>>>>>
>>>>>> The second is explicitly calling out the need for the architecture to
>>>>>> allow payers and payees to make a transfer of value between one
>>>>>> another,
>>>>>> even if they don't have a common payment instrument or scheme. i.e.
>>>>>> The
>>>>>> Web must work like the Web is supposed to and have a mechanism to fill
>>>>>> the gaps and comment the two.
>>>>>>
>>>>>
>>>>> With this explanaition I understand your idea. But, from my point of
>>>>> view, in the end, this is making a kind of "P2P payment", which we could
>>>>> consider as a new payment scheme.
>>>>>
>>>>> Best regards,
>>>>> Antonio.
>>>>>
>>>>>
>>>>>>     - As for security and privacy, the sentences that mention
>>>>>> "Supports
>>>>>>     a wide spectrum of security requirements and solutions" or similar
>>>>>>     should be reworded. Why a "wide spectrum"?. I consider that the
>>>>>>     security, privacy and regulatory issues have to be taken into in
>>>>>> the
>>>>>>     development of an e-commerce website or e-payment solution.
>>>>>> However,
>>>>>>     I consider that, e.g., the support of different authentication
>>>>>>     mechanisms is not part of the payment architecture. However, in
>>>>>> the
>>>>>>     processes that are part of the payment process, for example,
>>>>>> getting
>>>>>>     a payment offer, the payment architecture should define the
>>>>>>     mechanisms to protect this information. Then, I consider that in
>>>>>> the
>>>>>>     bullet we could say that security, privacy and regulatory issues
>>>>>>     will be taken into account to design the different process of
>>>>>>     payment architecture that need to be securized.
>>>>>>
>>>>>>
>>>>>> Our intention is to propose an architecture and ultimately define some
>>>>>> standards. When it comes to regulation and security I think our
>>>>>> approach
>>>>>> is to cater for everything we know is out there but not prescribe how
>>>>>> implementations are built. When it comes down to an implementer
>>>>>> deploying a solution in a specific jurisdiction subject to specific
>>>>>> laws
>>>>>> and regulations they should not be restricted by the architecture in
>>>>>> trying to adhere to these. On the other hand the architecture should
>>>>>> describe at what points these issues come into scope and provide
>>>>>> mechanisms to deal with them so that we make the life of the
>>>>>> implementer
>>>>>> easier.
>>>>>>
>>>>>>     Best regards,
>>>>>>     Antonio.
>>>>>>
>>>>>>
>>>>>>
>>>>>>     El 18/05/2015 a las 14:58, Adrian Hope-Bailie escribió:
>>>>>>
>>>>>>         The IG are trying to finalize a short vision statement for the
>>>>>>         work we
>>>>>>         are undertaking, specifically with regards to the architecture
>>>>>>         we will
>>>>>>         be developing, for payments on the Web.
>>>>>>
>>>>>>         The document is intended to express the technical principles
>>>>>> we
>>>>>>         consider
>>>>>>         important in the design of the architecture and I'd
>>>>>> appreciate some
>>>>>>         input on it's content.
>>>>>>
>>>>>>         The document is also intended to be short, less than a page,
>>>>>> and
>>>>>>         as such
>>>>>>         not too detailed. It's purpose is to frame the design and
>>>>>> allow all
>>>>>>         stakeholders to agree up front that we are aligned on our
>>>>>> vision.
>>>>>>
>>>>>>         The audience should be broad, and not necessarily payments or
>>>>>> Web
>>>>>>         technology experts, but since this is related to the design
>>>>>> of a
>>>>>>         technical architecture the content will be technical.
>>>>>>
>>>>>>         Please have a look at the first draft of this document and
>>>>>> send
>>>>>>         me your
>>>>>>         feedback.
>>>>>>
>>>>>>
>>>>>> https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force/Vision
>>>>>>
>>>>>>         Thanks,
>>>>>>         Adrian
>>>>>>
>>>>>>         p.s. Thanks Ian Jacobs for the initial work in getting this
>>>>>> started.
>>>>>>
>>>>>>
>>>>>>     --
>>>>>>     --------------------------------------------------------
>>>>>>     Antonio Ruiz Martínez
>>>>>>     Department of Information and Communications Engineering
>>>>>>     Faculty of Computer Science-University of Murcia
>>>>>>     30100 Murcia - Spain
>>>>>>     http://ants.inf.um.es/~arm/ or http://webs.um.es/arm/
>>>>>>     e-mail: arm@um.es <mailto:arm@um.es> or arm [at] um [dot] es
>>>>>>     --------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> --------------------------------------------------------
>>>>> Antonio Ruiz Martínez
>>>>> Department of Information and Communications Engineering
>>>>> Faculty of Computer Science-University of Murcia
>>>>> 30100 Murcia - Spain
>>>>> http://ants.inf.um.es/~arm/ or http://webs.um.es/arm/
>>>>> e-mail: arm@um.es or arm [at] um [dot] es
>>>>> --------------------------------------------------------
>>>>>
>>>>
>>>>
>>>
>>
>
Received on Tuesday, 26 May 2015 14:32:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:40 UTC