- From: Laurent Perez <l.laurent.p@gmail.com>
- Date: Sun, 5 Jan 2014 16:08:17 +0100
- 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. laurent 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 -- http://laurentperez.fr J2EE tips and best practices
Received on Sunday, 5 January 2014 16:52:17 UTC