Re: Beginner questions on m-commerce spec

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/

Received on Sunday, 5 January 2014 01:30:49 UTC