Re: Beginner questions on m-commerce spec

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