- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 30 Mar 2014 20:49:46 -0400
- To: Web Payments <public-webpayments@w3.org>
Thanks to Evan Schwartz and Charles McCathie Nevile for scribing "Session 2: Toward an Ideal Web Payments Experience" of the Web Payments Workshop. The minutes are now available: https://web-payments.org/minutes/2014-03-24-s2/ Note: These are minutes for an official W3C Workshop event that have been cleaned up and reformatted by the Web Payments CG. The Web Payments CG and the W3C are two different organizations, and it is the W3C that put on this event. These minutes may be handed over to the W3C to become the official minutes for the event, but that has not happened yet (and may not happen at all). Readers should understand that there is a difference between officially sanctioned W3C work, and the work done by this community (which is not officially sanctioned by W3C's membership). ---------------------------------------------------------------- Web Payments Workshop - Session 2 Minutes for 2014-03-24 Agenda: http://www.w3.org/2013/10/payments/agenda.html Topics: 1. Toward an Ideal Web Payments Experience 2. The Inputs to the Payments Standardization Process 3. Lessons Learned from the Mozilla Marketplace 4. General Discussion on the Ideal Payment Experiences Chair: Daniel Appelquist Scribe: Evan Schwartz and Charles McCathie Nevile Present: Daniel Appelquist, Evan Schwartz, Natasha Rooney, Manu Sporny, Kumar McMillan, Martin Hepp, Stéphane Boyera, Bryan Sullivan, Ernesto Jimenez, Dave Birch, David Ezell, Virginie Galindo, Ricardo Varela, Prakash Hariramani, Jeremy King, Giridhar Mandyam, Hannes Tschofenig, Jeff Jaffe, Erik Anderson, Charles McCathie Nevile, Jörg Heuer, Wendy Seltzer, Stan Stalnaker, Ori Eisen, Tobie Langel, Mountie Lee, Dave Raggett, and 78 others for a total of 103+ people Evan Schwartz is scribing. Topic: Toward an Ideal Web Payments Experience Natasha Rooney: In this session, we're going to look at use cases for web payments, analyzing issues and questions associated. By the end we should have some guidelines on how to move forward with these issues Topic: The Inputs to the Payments Standardization Process Slides for this presentation are here - https://web-payments.org/slides/2014/web-payments-workshop/ Manu Sporny: "Cat Herding 101", everyone has a different idea of what to standardize Manu Sporny: W3C creates standards through consensus, "ideal" payments experience is subjective and there are many, we can only realistically standardize parts of the experience Manu Sporny: Don't want to beat innovation out in the process Manu Sporny: 3 Main inputs to standardization: position papers, input from Web Payments Community Group, attendees of this workshop Manu Sporny: Survey of papers, common themes: no verified identity / trust mechanism (72%), outdated security tech (50%), no payment request standard (38%), no proof of purchase standard (38%) USE CASE: Verify identity or assess trust of partners in a transaction. Manu Sporny: Didn't think identity was going to be such a common issue but it was the #1 issue cited amongst the papers USE CASE: Initiate / request payment. USE CASE: Issue, transmit, validate proof-of-purchase / digital receipt. USE CASE: Find and compare payment options for transaction. Manu Sporny: Other themes: bad payment provider competition and lock-in (38%), expensive for vendors to integrate with payment providers (31%), mobile payments are fragmented (31%), payment provider lock-in (28%), poor rate of extensibility Manu Sporny: Web Payments CG - 146 members -- not an official group at the W3C, existed for ~3 years, creating space where open payment technologies can incubate Manu Sporny: Currently working on 14 technologies that can be applied to payment problems, these are designed to be taken W3C standards track if we get consensus on them. Almost all of them apply to the problems raised by the attendees of this workshop. Very much aligned in "what's wrong, and how to fix it". Manu Sporny: Machine-readable products and offers, initiating transactions, digital receipts, identity, web security upgrades USE CASE: Create a common digital receipt format. Manu Sporny: (Types of tech being worked on) Manu Sporny: Workshop attendee input: looking to determine problems, constraints, use cases, goals, and actions for the W3C Manu Sporny: If you are interested in following up with this work, please join the Web Payments CG, it's not official but there will be a lot of post-workshop work and that's where most of this work is happening now: https://web-payments.org/join Topic: Lessons Learned from the Mozilla Marketplace Slides for thsi presentation are here: http://kumar303.github.io/w3c-payments Kumar McMillan: For the past several years Mozilla has been building mobile OS called Firefox OS Kumar McMillan: Looked at HTML5 and available APIs, tried to create APIs that did not already exist Kumar McMillan: Wanted to have commerce as part of the mobile operating system, for developers to sell apps USE CASE: App Stores - selling apps in mobile scenarios. Kumar McMillan: Navigator.mozPay() is not on the standards track Kumar McMillan: Talk will focus on what can be standardized based on mozilla's experience Kumar McMillan: Web payments work today Kumar McMillan: When presented with a choice between credit card and paypal, I'll almost always choose paypal. This works on the web, we have secure HTTP. There's also Stripe and Square in the US. Lots of startups disrupting the space Kumar McMillan: There are some problems Kumar McMillan: Credit card numbers are insecure, mobile billing is broken in some major ways, new customer info, no standard for asset ownership USE CASE: Prove ownership over a particular asset (proof of purchase / ownership). Kumar McMillan: Credit card numbers are totally insecure. Target got hacked and I had to cancel my card, get a new one, and update all of the accounts Kumar McMillan: Why are we giving people credit cards when all they want to do is make a specific payment Kumar McMillan: Payment tokens for merchants: merchants could give token that requests specific amount of money and token expires USE CASE: Temporary payment tokens for merchants. If token is stolen, thief does not get access to financial account. Kumar McMillan: Payment processor needs to move money from customer's account to merchant account -- merchant doesn't care how payment is executed Kumar McMillan: PayPal hosted flow works with tokens, mozPay JSON web token works the same way, as well as Stripe and Square Kumar McMillan: Merchant never receives credit card number USE CASE: Billing through mobile operator (mobile billing) without hacks to HTTP. Kumar McMillan: Mobile billing is broken, it's a nice way to pay and works on the web, but there is HTTP header injection, every operator is different, and there are SMS hacks Kumar McMillan: Don't know how to fix this, operators need to step up and fix this Kumar McMillan: At mozilla, introduced silent SMS API, they'd like to extract that from mozPay -- still just a better hack Kumar McMillan: Apple's facetime has published how they do silent SMS USE CASE: Make it simple to register as a new customer (get rid of the registration step, if possible, or make it transparent). Kumar McMillan: Becoming a new customer is hard, you have to fill in home address, billing address, credit card number, and you need to do it all over again for each payment provider Kumar McMillan: Request Autocomplete was developed by Google, shipping in Chrome, web page can request and autocompletion by the device and the info will be stored securely on the device Kumar McMillan: Standard web identity could be one solution but it's pretty ambitious, there are strongholds around identity so it might be harder to use that Kumar McMillan: How do you prove you own an item? FirefoxOS is trying to embrace fragmentation, they want firefox marketplace to sell app but other marketplaces can also sell that app -- to make this work they made a digital receipt format that is portable, decentralized, and verifiable Kumar McMillan: Digital receipts could be standardized to help payments Kumar McMillan: Payments work well, it's important to focus on things that are real problems Kumar McMillan: Also important to think about what are the payment primitives? the basic, low-level building blocks like the token idea Topic: General Discussion on the Ideal Payment Experiences Denis: looking at the spec for web payments provider, it asks providers to be in a whitelist, what does it take to get in there? Kumar McMillan: Whitelist of payment providers may end up being deprecated, need low-level building blocks for accessible APIs Martin Hepp: How is the idea of digital receipts related to the work on schema.org? -- could be applied to JSON-LD representation Kumar McMillan: No plan right now to align this with JSON-LD but it's a better idea than Mozilla's free-form JSON Stéphane Boyera: MozPay seems like an interesting abstraction across other payment provider APIs Kumar McMillan: It's an abstraction but anyone could make an abstraction, all the building blocks are on there on the web with HTML forms that have a submit button. I don't think we need to standardize an end-to-end flow, only focus on things that are missing like tokens. Stripe has its own abstraction Daniel Appelquist: Working at Telefonica I agree with what Kumar said, but I don't agree that SMS is a hack Daniel Appelquist: Using SMS is becoming pretty well cemented as mechanism for verification -- silent SMS may be useful in some cases but in others it might make the customer feel more secure Daniel Appelquist: Is there really an ideal payment experience? Micropayments have long been needed. HTTP status code 402 was intended to support micro-payments. There were people in the mid-1990s trying to implement micropayments but there is plenty of room for innovation, shouldn't just focus on an ideal scenario. Need to focus on security and convenience Daniel Appelquist: There are issues with the current security aspect, chromeless webapps or native applications, how can you determine if you're in a secure application Daniel Appelquist: Certificate model of web security is broken because people don't pay attention to it, people click through even on old certificates Daniel Appelquist: Innovations in payment UI like using camera to recognize credit card, but then there's a privacy issue Daniel Appelquist: Loyalty cards have interesting developments Daniel Appelquist: Mobile ticketing is also part of payments Daniel Appelquist: Not currently convinced that we need payments as part of the core architecture of the web. we should incrementally strengthen existing work Bryan Sullivan: ATT has operated as payment broker since 2002, APIs have improved over the years, also mobile wallet in the US. There isn't an ideal experience USE CASE: Application of loyalty cards to purchases. Bryan Sullivan: People should look at the push API he's working on with Telefonica Bryan Sullivan: Payment is personal, enabling user choice in everything regarded to payment is a key aspect of the UI Bryan Sullivan: W3C doesn't have to address entire industry but it should look at key use cases and requirements Bryan Sullivan: UI for web on moblie is very diverse, all of contexts should be supported. Don't want a fragmented web UX Bryan Sullivan: UX is going to be driven by how consistently the APIs are implemented, not so much about the UI -- you can set expectations but mandating a particular UX leads to narrowing scope of problem too much Bryan Sullivan: Transfer of funds as an exercise is a really good place to start but we need to think of payments as an aspect of transaction processing in general, need to be able to exchange all types of value Ernesto Jimenez: Used to work for Telefonica and Mozilla, background on what mozPay offered them -- it was good because everything is web-based, needed a way to verify trusted UI for entering details, the only problem was that there wasn't an option to open it up to every type of payment provider Kumar McMillan: In mozPay there's a trusted UI, but it is still spoofable. That's not a payment-specific problem, it's a problem for all mobile. There's no way to trust that a site is connected to the right URL, all of mobile needs that Dave Birch: If you assume payment token is the invoice signed by the provider, that's completely feasible. The client is going to pass the token to the payment service provider so they need to manage providers. They'll also resolve certificate chains David Ezell: Digitally signed invoice can act as the receipts David Ezell: If we assume most of this is going to move onto mobile, Trusted Execution Environments might add some optimism even if it's not ideal right now Virginie Galindo: +1 To Dave Birch point on TEE optimism Kumar McMillan: Maybe the token doesn't need the W3C but I want to see sites stop using credit card numbers Kumar McMillan: With the receipts there's also the ownership part, like a cookie that lives on device so you could give it back to the website Bryan Sullivan: People should look at global platform for TEE, this is a problem that's been around since feature phones Bryan Sullivan: It's a general problem of the web that things can pop up and take over the screen Virginie Galindo: Note : light explanation of Trusted Execution Environment technology there : http://poulpita.com/2014/02/18/trusted-execution-environment-do-you-have-yours/ Ricardo Varela: The moment we start getting into trusted elements, we're getting into manufacturers and browsers, etc. we'll need to decide if we want to involve those. Payments are not just a form, the actual payment is done later. The open question is whether payments should be a more integral part of the web. Similar to geolocation where you say I want your location, a merchant could say I want $10 Natasha Rooney: Many position papers separate UI and intent to pay, questioning whether UI should be standardized. What do people want from standards? Kumar McMillan: Dangerous to standardize things that don't need to be standardized -- UI is easy to build on existing web technology. Risky to introduce APIs that are not useful. A 402 response is not as useful as a 301 redirect that redirects to a page saying you haven't purchased this option Manu Sporny: I agree completely. It's dangerous to say this is exactly how payments look on the web, it's more about the intent to pay. Whitelists and digital receipts have been raised a number of times but if we say there will be a whitelist on payment provider signatures we'll continue having the same ecosystem we see today, no innovation. We could potentially put in the same infrastructure that was put in for the Certificate Authorities, we want a more flexible solution. Whitelists mean that we anoint winners and losers of a particular service, that's bad when it comes to payment, worse than what we have to Certificate Authorities today. Just say "No!" to whitelists. USE CASE: When doing a payment, need a way to assure the customer he is his payment service provider and is not subject to phising. Specially problematic in mobile when browser chrome is not available. Bryan Sullivan: Management of that type of data is the essence of evil, solution needs to be more scalable Daniel Appelquist: We shouldn't describe things as "evil". On mobile, most apps are being used in a chromeless way, there is a disparity because there isn't the same kinds of visual cues. Bryan Sullivan: Trusted consent is a general problem of the web Prakash Hariramani: Murkiness in terms of the standard for payment tokens, what does the Fed and European Commission think of the standards? Virginie Galindo: Note : some trusted user interface like work is discussed in WebAppSec see : http://www.w3.org/TR/wsc-ui/ Jeremy King: The standard that Mastercard and Visa have just related is taking tokenization from the issuer perspective and using token to initiate transaction Jeremy King: From PCI standards there is tokenization from the acquirer's side Jeremy King: Everyone's talking about tokenization from different ends of the spectrum, so we need to get our terminology straight. USE CASE: Tokenization mechanism that protects the buyer and merchant from theft of credentials. Bryan Sullivan: Not sure how the tokenization spec relates to the UX, maybe this can be clarified Giridhar Mandyam: Re: mozilla telefonica paper -- why aren't client technologies for geolocation good enough? How will third party payment providers being included? Virginie Galindo: Note emvco tokenization framework : https://www.emvco.com/specifications.aspx?id=263 Kumar McMillan: We're not sure, that's why there's a whitelist right now. There are really sensitive APIs, there are privacy reasons why we don't want to allow access to that Natasha Rooney: Want to pull conversation away from mozPay because they're not going to spec it Jeremy King: Re comments about SMS, not long ago there was a laptop and mobile phone, but now they've merged into one so SMS is ineffective 2FA +Q Hannes Tschofenig: There's always a reluctance to standardize UI but the standardization is gone on mobile, as well as the certificate validation. Is there any possibility to improve the mobile experience? No one wants someone to dictate UI but it's not a good state now Bryan Sullivan: Re SMS use in stolen phones, the solution there is faster response for locking phones. And anyway in most cases the thief will pull the SIM first thing, which prevents the SMS from being an attack vector. Kumar McMillan: Any time you're talking to any website on mobile phone, need better mechanism than a lock icon for non-crypto users to know they're talking to the right site Parslow says - there is not only stolen phones but a lot of stolen OTP are due to cloned SIM issued by the operators Daniel Appelquist: Security is a payments issue. per PHB, HTTPS was designed for payments, i.e., to make consumers feel confident enough to make payments online. Bryan Sullivan: Re earlier point on location, I agree it should be entirely adequate (GeoLoc API) for payment purposes. Newer tech and networks e.g. LTE will also support indoor location soon. Jeff Jaffe: Both Kumar and Manu have made strong points about not standardizing UI, but if we're talking about an ideal UX for payments, we have to get people to trust us with their dollars or Euros, it's different than browsing the web for information Kumar McMillan: There's a lot of innovation on the current web with UI. Amazon payments are incredibly fast, Stripe has made it super easy to pay. We'd hold people back Manu Sporny: I'm hearing people say that they want to standardize a UI, but does anyone even have an idea of what the ideal UI would be? I've never heard a solid proposal over the last several years that ended up gaining any sort of consensus (and there have been a few by big companies). Natasha Rooney: Too many stakeholders Stéphane Boyera: I believe we are mixing ideal functional interface vs ideal design Bryan Sullivan: Shouldn't focus too much on UI Erik Anderson: UI will always be branded by the organization. They will want their own particular theme. Standardizing the UI will never go anywhere. Chaals wanted to ask what the relation is between digital receipts and EME, and to offer the counter-example of EV certificates and standardisation of UI Bryan Sullivan: The problem is that solutions that focus on UI get reduced to a solvable surface, in the case of tracking protection for example limited to web browsers, and leaving all other web contexts off the table. Charles McCathie Nevile: When we created extended validation certificate system, one of the things we did at W3C was standardization of UI to show that you were on an extended validated system. There's not a full spec but there are some clear guidelines to help users be sure they know what they're getting. You do have to dictate something about the UI to pass a clear message across different UIs, need to pass minimal viable set. Perhaps we should talk to the group that has done the most with digital receipts... the EME folks have been dealing with this stuff for a long time, we should talk to them. Bryan Sullivan: UI can come from many places... Web servers are the most flexible source of UI, and OAuth servers have the same advantage of being able to dynamically pull in content/info to present to the user, and don't impact browser code bases (another limiting factor). Charles McCathie Nevile: Might be way to standardize receipts Natasha Rooney: Who thinks it's a good idea to start looking into UI elements of payments? Some people think it's a good idea, a few think it's an awful idea Natasha Rooney: Good case to start looking at it Virginie Galindo: Note : UI with security merits may be worth looking at Jörg Heuer: Need to differentiate between UI and user iteraction patters, need to get into user interaction patters which blend into technical transaction interactions Charles McCathie Nevile: [Having a digital receipt that is transferable doesn't solve all of EME, but one part of what they want to do is determine whether you have the right to use the content] Bryan Sullivan: To address offline use cases, we also have service workers and other new tech that can serve the same goals e.g. local OAuth servers that can on the back end integrate with TEE Trusted Applications or Secure Elements, which can provide a truly trusted UI capability for the web. Daniel Appelquist: +1 To thinking about interaction (not interface). Bryan Sullivan: Would web components provide a means to create secure interactive elements? Natasha Rooney: Bryan, just what I was going to say! Jeff Jaffe: [+1 The distinction between interaction and interface is a helpful distinction] Daniel Appelquist: Interaction is the more accurate term than interface Charles McCathie Nevile: [... I.e. a digital receipt. And having a decentralised receipt instead of your prof-of-ownership being provided as a service by a particular provider would, for example, reduce the problem of your key expiring with the company that made it] Bryan Sullivan: What would be the role of web components? they could provide secure interactive elements Natasha Rooney: B2B payments haven't come up yet Ricardo Varela: Bryan, I don't think so: web components at its basic form are just glorified client-side template engines, they don't solve anything we couldn't do already (of course they have benefits like reusability but they don't add new "use cases") Bryan Sullivan: Whole range of relationships beyond B2C, in order to really reach scale, need to look at end-to-end interaction and see all of the players. Need means of exchange between providers and a market USE CASE: Payments / digital receipts should be applicable to Encrypted Media Extension authorization to show content. Ernesto Jimenez: 2 Tracks for UI, browser or OS UI and there's also UI for payment flow from payment processor. need way to show customer in mobile and desktop that they're in a trusted environment. shouldn't standardize how that looks but should provide means for browsers to show it's in a trusted environment Ernesto Jimenez: Different aspects of this could be standardized separately as layers Bryan Sullivan: Businesses and enterprise user use cases are just as important as consumer use cases. For example, the parties involved in enterprise use cases might aggregate or authorize payments on behalf of the enterprise, thus represent a B2B use case. Charles McCathie Nevile is scribing. Manu Sporny: Don't think anyone is arguing against a layered approach Daniel Appelquist: Agreed Stephane wanted to talk about merchant ideal experience - adding easily psps without changing a line Stéphane Boyera: We talk a lot about users. I feel we need a holistic approach. Think of the merchant UI. What merchants want is to support more payment providers without changing the website for each one... that has a huge impact. Kumar McMillan: Would be nice, don't see it happening. People woudn't follow a standard for an API. ... the incentives are not there. Open source is a good answer ... that would get traction. Chaals thinks a standard is a far better tool than an Open Library... David Ezell: +1 To chaals Stéphane Boyera: There is an abstraction that can be done like mozpay, routing the user through the payment layer generically seems a clever way to provide benefits to merchants and customers. Bryan Sullivan: Isn't the interface between a virtual wallet and payment providers valuable to standardize? ... think that could be a good goal, allowing innovation where it makes sense and a generic approach where it is required. Manu Sporny: Big problem for merchants- if there is an open mechanism, the merchant still needs to get the money. ... They want to accept all payment, but don't want to make individual deals with each processor. Not sure we touched on that. Bryan Sullivan: The merchants don't need to know or use the API between the wallet and payment provider, just the web API that provides access to the wallet. Stéphane Boyera: Think that would solve the issue. It isn't just an account today, it is also writing a whole backend. Manu Sporny: So where do they open the account? Without an open standard, it matters where you open the account - that's a big problem. Natasha Rooney: Wallets might be able to handle that, giving a bundle of accounts. ... people innovating around there can cause issues. Wendy Seltzer wants to discuss privacy. Wendy Seltzer: Wanted to re-emphasise Dan's quote about HTTPS - giving customers confidence to make payments on the web. ... shared interest is giving the customer confidence in transactions. ... and we have interest in making that confidence justified. Erik Anderson: Merchants dont want to be exposed to all of the underlying payment sources or technologies. They want it to be more simple. Stan Stalnaker: Deep thought - what would an http:// protocol look like as a means of annotating a potential payment marker? Wendy Seltzer: Some attention to the UX is needed. We need some workto standardise and help people see they don't need to be an expert in choosing providers to do business, don't need to do a lot of research before knowing if payment will work on the web. ... we want this to happen, where can we do the work? Charles McCathie Nevile: Stan, you mean like: payto: ? David Ezell: Merchants want choice, but not necessarily infinite choice. Having ANY choice would be a huge improvement over status quo. Hannes Tschofenig: Raises an interesting question for W3C. On the one hand you create building blocks, and let industry innovate, but how do you ensure that these are sound for security, which is the sum of, not just individual block properties. ... relates to whitelisting/certification. ... When people meet the right criteria they get the User Experience. I see layers in standardisation - some blocks at W3C, but some maybe somewhere else (dunno where) ... to provide a block that people get which is trustable. There are examples in other sectors, like FIDO or Bluetooth. Bryan Sullivan: I agree that trusted UI is an important thing to be considered but in general, not just for payments. And we should keep a broader focus when we consider this, remembering that much of the Web's UI exists outside the user agent, at least in how the presentation layer is crafted. Natasha Rooney: Has happened in eg WebRTC too. Ori Eisen: Suggest we keep the UI and visual to the end. Computers are great in shell before they had UIs. Let's fix the core issue and then worry about how to signal what we are trying to solve. ... Think there are plenty of things W3C can and should do. BUT there is no standardisation of fighting viruses. The bad guys are too agile to make standards of how we fight them. Bryan Sullivan: APIs are the analogy of the shell Wendy Seltzer: [Cough Kerckhoffs's Principle, that a cryptosystem should be secure even if all is disclosed but the key; transparency can aid security cough] Ori Eisen: Any standard we make will be so slow that bad guys have a roadmap in advance. ... need to figure what should and what shouldn't be standardised. ... who takes responsibility for paymetn security if it goes bad. How do people who take responsibility for lost money fit into the standardisation. ... Don't forget there is an adversary watching us. Daniel Appelquist: My perspective is this workshop is looking to feed a process in W3C, but the thinking we are doing can have a big influence too. ... documented record of the meeting might produce outcomes which are work items but not for W3C. Tobie wanted to comment on non-normative UI/UX work. Tobie Langel: Following up on UX. The reason not to standardise is 1: IPconcerns, 2: don't block innovation. Which are important points. However, there would be value in some non-normative documents on the topics. Jeff Jaffe: [Jeff supports Tobie's point. We often call that "Best Practices".] Erik Anderson: All the merchant cares about is getting the money into their bank. What is their experience going to be? Manu Sporny: We are focusing on customer experience and especially security issue for them, not "does their payment provider match the merchant"? ... When merchants accept Visa and MasterCard both them and the customer doesn't care who people bank with. Unless we're building on existing powers, you have to have a standard where the merchant and customer can have different bank accounts, otherwise we can't compete with what we already have. Daniel Appelquist: Agree. E.g. Stripe's value-add is simplifying life for the merchant. ... Yandex proposal has some issues but the thinking behind it to make it easy for merchants to integrate payment is something we really need to understand how to do, and to get right as an output. Kumar McMillan: Why do we need to standardise? Merchant can already accept bitcoin. Charles McCathie Nevile: There are some governments who take a dim view of merchants doing that (accepting Bitcoin). Stéphane Boyera: -1 To what Kumar said. Bryan Sullivan: Downside is fragmentation inhibits growth. Developers always complain about the lack of standard APIs. The developer experience is horrible and they don't have bandwidthto track the fragmented world. ... standardising at least a digital receipt might help as a minimum. Manu Sporny: What we want is "any merchant can integrate any currency, so long as the value ends up at what they asked for". Ideal is that when a vendor implements a cart, the mechanism is the same across currencies and national boundaries. They just want a receipt for the amount they asked for. Stéphane Boyera: +1 To what Manu just said. Daniel Appelquist: Sometimes the vendor needs more info than the credit, e.g. for regulatory requirements (reporting, etc) Mountie Lee: Re certificates, a strength is that it is not yet fully standardised. Problem of transport medium. Web is on the application layer. ... certificate has ??? ... 2nd point, payment can be connected to the merchant or delivery or ID service providers. Have to think about integrating the process from initiating, getting the receipt... ... 3rd We can use recommendation systems to determine trust. ... we can rent the idea from bitcoins and use users instead of whitelisting, exchange w/o trust. Daniel Appelquist: So learn from cryptocurrency and bring ideas into mainstream payment? Bryan Sullivan: The third idea seems to call for vendor reputation integration into the UX for payment. Mountie Lee: No, we get votes from users. Accumulating votes can use the bitcoin transaction history mechanism to increase trust. Manu Sporny: So, you're saying that the trust of the merchant based on other transactions. More people work with them, the more you an trust them. Mountie Lee: Also user experience reports. No trust until you get "xyz" accumulated experiences Charles McCathie Nevile: The problem with that is how do new entrants get on board? Manu Sporny: Yep, that is a problem - no clear solution to that right now. Perhaps they get on board just like every other merchant does on the Web today, although that's less than ideal. Gives enormous power to the Amazon, Walmart, and Tescos of the world. USE CASE: Merchant and User reputation system accessible to the payments mechanism. Bryan Sullivan: Reputation is integral. If we could integrate verifiiable reputation recommendation it would be valuable Wendy Seltzer: I hear "two-sided market". Dave Raggett: Bryan, reputation is important for all the parties, not just merchants USE CASE: Reputation based selection of providers in a payment transaction, or info about merchants to help the user choose whether to complete the transaction. Ricardo Varela: Payments with cards are optimised for merchants. I ahve no idea what I get charged when I make an international purchase. ... The same will happen here. Merchants already whitelist payment providers - won't accept some card because of various factors. ... question is who does whitelisting. ... in B2B, a merchant cannot ust receive money out of everywhere, they have to justify the income. Parslow says - now in France you can be charged for exchange rate between EUR and EUR... Jörg Heuer: Important to understand that the security things are about risk management, since 100% security is an illusion. We need to keep that in mind and associate risk with the right players. ... in many cases the system holds the user free of liabilities - this is a service of the payment provider. ... if they can make the browser secure easily, they can make things cheaper. We're not looking for *a* security mechanism but a framework that supports many. We want to give users and merchants a choice. ... I go to a shop and they say what they accept. I want to see that on the web, and then choose the instrument of those I want. two places where choices can be matched, which is a protocol thing that we can work on. Natasha Rooney: Seemed from position papers that stronger solutions were the simple things. Is a simple solution the right thing to do? What would it be? Kumar McMillan: Think we need to focus on the small pieces, not an end-to-end solution. Everyone has different incentives. So they won't adopt a standard that doesn't match their incentive. ... If we focus on e.g. receipts, someone finds that useful but will want to e.g. maintain their own control over identity provision. So think we can only focus on the primitives. Manu Sporny: Largely agree. Important to know where we are going. Would expect work to happen in phases. Primitives first, then maybe higher-level concepts. Can we give anyone the ability to crowdfund up to X value? Not in generation 1, but with the right primitives in place it might be possible to handle that in a future iteration. ... A big standardization initiative will result in failure, we need to start with small blocks. Bryan Sullivan: Keep it simple. Don't make a thin abstraction layer covering a mess of javascript that covers all the horrors. ... finding the sweet spot is complex (we're going through that with PushAPI) Hannes Tschofenig: It was interesting that all panel members argued for **simple** solution Hannes Tschofenig: (Nobody every argues for complex solution and for standards that are hard to understand. How boring is that?) Hannes Tschofenig: Even consultants argue for simple solutions. They just add that the search for simple solutions is still ongoing and requires lots of work USE CASE: Whitelisting of parties - users, merchants, payment providers without scalability / anti-compete issues. Natasha Rooney: Wrapping: Trust and security is a big topic. ... we focused on trust and trustworthy UI. Lot of attention paid to digital receipts and tokens. Whitelisting has scalability issues but we want to look at what they really are. ... flow from the merchant perspective is important - we are all users, but not all merchants. ... for standards, keep things simple and/or standardise in modules. ... We dabbled in stakeholders, and wallets (there is a session on that tomorrow) ... I'm eating your break, but while there, think of the primitives to standardise around and tweet with #w3cpayment hashtag End of session 2. -- 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 Monday, 31 March 2014 00:50:21 UTC