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

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

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Tue, 26 May 2015 16:47:42 +0200
Message-ID: <CAKaEYhKbt83kWW0sujgwhFxn27OFDD-ds=bqzXBHkAHdmt+8tg@mail.gmail.com>
To: Adrian Hope-Bailie <adrian@ripple.com>
Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Antonio Ruiz Martínez <arm@um.es>, Web Payments CG <public-webpayments@w3.org>
On 26 May 2015 at 16:29, Adrian Hope-Bailie <adrian@ripple.com> wrote:

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

Information works in a similar way.  If I read an article once I may learn
something, but on reading it again, it may be worth less or nothing to me.
My own behaviour and what I will accept as information vs spam regulates
what gets on my screen.  Double spend can be amelerated.  In highly
connected systems it's tough to tell what form this will take, just as it
was impossible to predict the way search engines, blogs and sharing, would
ameliorate information overload with the web of documents.  Ultimately I
think a web scale trust overlay similar to ripple will be part of this, and
perhaps is an area for standardization in itself.  But to my knoweldge no
one to date innovated in this space.


>
> On Tue, May 26, 2015 at 4:10 PM, 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:48:11 UTC

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