W3C home > Mailing lists > Public > public-webpayments@w3.org > January 2014

Re: Beginner questions on m-commerce spec

From: Laurent Perez <l.laurent.p@gmail.com>
Date: Sun, 5 Jan 2014 16:08:17 +0100
Message-ID: <CACqpeO_Vi78apc=HzGnk7DAcb+65Oqc6EO5LNZ8P9jNMpbYOUw@mail.gmail.com>
To: Web Payments CG <public-webpayments@w3.org>
Thanks for the detailed answers

I don't yet understand where is
https://web-payments.org/specs/source/web-identity/ used. Is it only
used to trust the vendor, or the buyer too ? Is there some UML
State/Sequence diagram available somewhere ? The buying process flow
could be easier to understand with a schema like this.


On Sun, Jan 5, 2014 at 3:13 AM, Joseph Potvin <jpotvin@opman.ca> wrote:
> Laurent, If you consider that a monetary system is a system for tracking
> identified entitlements and obligations, and money is a unit of account to
> implement the tracking. All that needs to happen is for trusted information
> about the entitlements and obligations to be communicated (not "transported"
> exactly).  When that information can be stored reliably by any person, and
> communicated reliably between any two people, peer-to-peer payments are
> feasible.
> Picture the above in a purely oral culture, and it make sense right away: I
> say to you, "I owe you one".  Three weeks later, you get a beer from me. The
> "money" (obligation|entitlement pair) was communicated, not sent, except in
> an intangible cybernetic "message sent" context. But the beer did get
> physically transferred from my fridge to your gulp.
> Joseph Potvin
> On Sat, Jan 4, 2014 at 8:30 PM, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>> On 01/04/2014 10:07 AM, Laurent Perez wrote:
>> > I'm having difficulties understanding the whole picture of the specs
>> > this group is working on, this is really a beginner question.
>> Yeah, it can be sort of difficult to figure out how they all fit
>> together. Have you checked this out yet?
>> https://web-payments.org/intro
>> > What I don't understand is, basically, where does the physical money
>> > come from, and where does it go. As per "where", I mean bank account
>> > or Authority.
>> If you are talking in terms of today, the most probable organizations
>> that would use the standard are credit unions, banks, online payment
>> companies (such as PayPal, Google, etc), and Bitcoin/Ripple/FOREX
>> gateways.
>> If you are talking in terms of 10 years from now, governments could
>> adopt the standard at a nation-wide level, regulation could create new
>> classes of financial organizations that mandate the standard (achieving
>> efficiency) in return for lower barriers to entry (less regulation and
>> surety bonding requirements).
>> Where the "physical money" comes from is largely a matter of the
>> currency being used. USD comes from a very different place than Bitcoin
>> does :)
>> > Reading
>> >
>> > https://web-payments.org/specs/source/web-commerce/#performing-a-purchase
>> > it states "The process consists of re-directing the Web browser to the
>> > buyer's PaySwarm Authority for the purposes of authorizing payment
>> > to the vendor for a particular listing"
>> >
>> > Is my bank credit card form submit page the Authority here, and will
>> > my bank post to the vendor callback once the purchase succeeds ?
>> Yes, in general, you can think of your bank as the Authority. Your bank
>> will post to the vendor callback once the purchase succeeds.
>> > Also I don't understand if the asset is anonymous from the Authority
>> > point of view. I don't want my bank to know what I'm buying in full
>> > details.
>> Right now, no, the asset is not anonymous. You will have to trust your
>> bank with your spending history (just like you do today). As you know,
>> your bank already has a ton of data on you by partnering w/ companies
>> that track your spending across websites via cookies and other tracking
>> mechanisms. You're correct in assuming that this would allow them to
>> collect more accurate data about you w/o having to depend on external
>> parties.
>> People have a number of options when it comes to this issue. The first
>> is to only use a bank that they trust. Perhaps the bank would have a "we
>> don't sell your purchase history" disclaimer in their terms of service?
>> Perhaps that disclaimer would eventually be mandated/regulated by the
>> government? The second is for us to come up with some sort of encryption
>> mechanism that encrypts the asset being purchased so that the bank
>> doesn't know what's being bought.
>> This has two negative ramifications. The first is that it may eventually
>> become illegal to do so (due to how anti-money laundering laws may
>> evolve in the next 10 years). The second is that even though an
>> encryption standard exists, many banks will not do it because there is
>> too much of an economic incentive for them to not do it. You're not
>> going to pay them nearly enough in fees that someone wanting to sell you
>> something is going to pay the banks to get a peek into your spending
>> history. The data would probably be anonymized, but it could still be
>> linked back to you via side-channel attacks like cookies and colluding
>> with merchants.
>> That said, we've played around with the concept of using homomorphic
>> encryption for this purpose but didn't get very far due to the extreme
>> complexity involved in getting such a system to do something useful with
>> the sort of data manipulations that we have to perform when executing a
>> transaction.
>> We've also played around with the concept of having the digital receipt
>> stored at a location of your choosing (such as a personal server) and
>> stating in the spec that the unencrypted receipt should never be stored
>> at the Authority. Unfortunately, this means that either 1) the Authority
>> can't detect double purchases, or 2) the mechanism to detect whether or
>> not you've bought something will have to bounce to your server and then
>> to your Authority in the average case of you having not purchased the
>> item in question. That could lead to a lot of breakage, but if you run
>> your own digital receipt server, you kinda know what you're getting into..
>> There is still an argument that there could be an encrypted digital
>> receipt/asset solution out there that is simple to implement and one
>> which wouldn't cause interoperability issues. We just haven't found one
>> yet. We are very concerned about privacy issues, especially given the
>> recent revelations about the NSA, so this is an area we're very
>> interested in improving. The sad reality is that even if we do come up
>> with a solution, the powers that be might not implement it, it might be
>> too complex to implement, or there would still be other mechanisms at
>> gleaning that data about you anyway (the same ones that are used today).
>> -- manu
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: The Worlds First Web Payments Workshop
>> http://www.w3.org/2013/10/payments/
> --
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> http://www.projectmanagementhotel.com/projects/opman-portfolio
> jpotvin@opman.ca
> Mobile: 819-593-5983
> LinkedIn (Google short URL): http://goo.gl/Ssp56

J2EE tips and best practices
Received on Sunday, 5 January 2014 16:52:17 UTC

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