Web Payments Workshop

<inserted> Agenda

<wseltzer> Date: 24 March, 2014

<wseltzer> Welcomes from Stephane Boyera, Virgine Galindo (Gemalto) and Michel Leger, Ingenico

<Parslow> more glazou https://pbs.twimg.com/media/Bjek-PyIEAAiwzr.jpg:large

Introduction by Jeff Jaffe at W3C

Jeff: The W3C was founded by the inventor of the WWW, Tim Berners-Lee.
... Earlier this month, we celebrated the 25th anniversary of the WWW.
... We have a very simple, mission statement - lead the web to it's full potential.
... We have a pretty good track record of that. We're a member-based organization. We have govts, startups, technology companies, non profits, close to 400 members.
... Large commercial companies. The community that we have are the entire users of the WWW, we're shooting for entire planet.
... For technical standards, we're larger than most technical standards - 70 people spread around the world, we want architectural coherance for the Web.
... Outputs we produce are available to everyone.
... UbiWeb - ubiquitous Web, We work on Web accessibility.
... No one from disabilities should be prevented from using the Web.
... Information and Knowledge focuses on data.
... Each piece of technology gets created in a WG. Most of the work is done by engineers from member organizations, sometimes we have invited experts from outside.
... We work w/ Internet Engineering Task Force, we interface w/ who we need to.
... We have a royalty-free patent policy. When Tim invented the Web, he made it available to the world. If you have an invention that belongs in the core of the Web, and you have a patent, that should be available on a royalty-free basis.
... Some of you may be familiar w/ de-jure standards. We have a fast-path track for DeJure international standards.
... As the Web has become more important, large companies have been joining.
... We also have been trying to get smaller companies in. There is a new track of work - once community decides that something needs to be a Web Standard, we did a good job.
... However, we didn't do well in pre-standardization work.
... So, innovators would get together to do pre-standardization work. So, we created a new track called Community Groups. It made pre-standardization work easier. Sometimes CGs are discussion groups.
... We have around 170 CGs, close to 4,000 engineers working in these groups.
... We are working on the "Open Web Platform", lots of people doing work, but at the end of the day it all has to come together. We use "open web platform" to differentiate the open web from the web of 25 years ago.
... In 25 years, the Web has become much more. Increasingly, the Web is not the end result, it's a platform for other applications to build on top of it.
... The platform for building distributed applications - it's very interactive. It's characterized by Rich Interactive Media. The content was exciting, but it was fairly static. Now web pages are exciting (lots of great fonts, media, images, etc.)
... We're working on HTML5 and CSS3 now, two hallmarks of W3C standardization work.
... The span of devices implementing the Web has been expanding. In last 10 years, we've successfuly moved the Web to the smartphone, it's a design point for the Web.
... Web and automotive is new work we're doing. So is mobile.
... Web technology runs most everywhere,
... Secure Web Platform - it's important that we keep innovating.
... New industries that are affected - mobile, entertainment, gaming, healthcare, digital publishing, all are increasingly getting affected.
... Digital publishing is interesting, we've been publishing for a while now. Mass distribution on a global scale, everyone is an author. Very different from highly selective publishing houses.
... Web lacked quality of publishing for a long time. Font selection, styling, you couldn't do any of that. However, today we're in a situation we know how to achieve all of that technically.
... As publishing was changed after Web, so do other industries.
... With the Web Payments workshop, we're launching what could be a more fundamental transformation. It'll be impactful, now sure how it'll turn out.
... Lots of stuff is bought on the Web :)
... Payments for mobile devices are increasing, searching for new ways of providing payments on the Web.
... If the Open Web Platform has been successful, to be the reference standard for what gets done in those industries, let's explore how the Web affects payments.
... We wouldn't be exploring this if payments were simple.
... For most people, it's bewildering to do payments on the Web (to pay for things).
... To set something up the first time, it's difficult.
... We have cryptocurrencies coming up, it's part of the whole picture. The complexity of the ecosystem is something we're going to be focusing on.
... merchants are a part of the picture. When you want to set yourself up on the Web, you have to figure out how you're going to get payments accessible to your customers.
... With Web Applications, the number of people that are trying to monetize things on the Web is growing exponentially.

<phariramani> With web applications, number of people who are trying to navigate the web has increased substantially

Jeff: I want to do a one-off purchase, it's not easy.
... A regular Amazon user has no problem, but we want a frictionless approach where anyone can buy from anyone in an easy fashion. The user experience should be simple. Not tons of passwords for each site that I frequent.
... High levels of fraud, the overall security of the system - it's not great. We all worry that one day it's going to get worse.

<phariramani> Lack of standardization = Poor and variable user experience across sites and across payment systems

Jeff: Is it really secure enough?
... payments should be easy
... People should be able to pay how they want to. If I have a smartphone, or tablet - I'd like a single "wallet" and do things consistently among devices.
... Transparency is important -transaction fees should be clear.
... How does this get done technically? Unsure, that's why we're having this workshop.
... We're going to figure out where to do standardization. Maybe this happens at W3C, maybe somewhere else.
... What to standardize is a very delicate choice.
... We have the open web platform, having a clean way of getting a request for payments, proof of payments is standardization candidate.
... having a standard interface between browser/wallet is a good standardization candidate.
... Interfacing w/ external payment providers is important.
... Being able to select payment mechanism is important... we need to manage this complexity.
... Users should have greater choices, more choices, more consistency. There is enough automation/verification that merchants should be able to trust customers.
... W3C is a consensus organization, we bring stakeholders together. We bring them together to try and figure out the best way to address some of these issues.
... The Web is a global mechanism, we need things to work across borders. We want an open and level playing field.
... When we start to look at a complex problem, we fail if we try to solve the entire problem at once.
... So, what's the lowest hanging fruit.
... What makes a workshop successful - enter it w/ a spirit of openness.
... There are many things related to technology and payments - we're focused on technology issues and enablement. Standards are a human activity.
... Let's start talking and seeking consensus.

EU Work on Payments: DG Competition

Alexander Gee takes the stage.

<wseltzer> Piggy bank

Alexander: I've been doing payments since 2008.
... We welcome what's being done here. Anything that makes payment on the Web better, we'd welcome anything that would expect the single market from the EU.
... What I'd like to do now is simply go through - explain what we're doing.
... My slides are detailed, so I'll skip through slides relatively quickly.
... Payments in EU - epayments are largely card based. As far as Eu is concerned, payments is 1% of GDP
... It's 25% of bank revenues.
... card transactions have grown from 7.4% to 17.4% - price for accepting card payments is not reflecting scale and increased efficiency.
... DG Competition has focused on interchange fees. This is one of the biggest barriers to competition in payments market.
... We have been embroiled in a legal debate for years. MasterCard has said they'd move interchange fees down 0.2% to 0.3%. They're around 1% right now.
... Visa says they'll match Mastercard's fees.
... Lower fees - markets segmented between national markets.
... We are now continuing w/ cases against MasterCard and Visa - regarding international payments.
... with interchange fees at this level, merchant is indifferent on getting paid w/ cash vs. card. We don't have enough info on what a good comparator is for epayments.
... Direct debits of credit transfers would be good. Offline figures would be good.
... We've carried out a detailed study - 0.2% or 0.3% seems reasonable.
... Normal standardization is pro-competitive, but we've found that major players have banded together to create an exclusionary effect on non-bank epayment mechanisms.
... In Netherlands, more internet-based payments are made than card-based ones.
... Non-bank players were excluded - the way standardization was being done - it was exclusionary.
... We tried to work w/ European Payments Council .
... Interchange fees are a way to pass fees onto customers in a way that they can't see them.
... New entrants to innovation - atms / internet banking, paypal, payfair, monnet, ideal and Mybank, sofort.

<phariramani> Alexander: Paypal is more expensive than card payments

Alexander: From our point of view, Paypal is expensive - more expensive than card payments. It's a closed system. You have to establish a new account w them.

<virginie> payfair : http://www.payfair.eu/

Alexander: Monnet replaced national schemes, but it failed, they were willing to offer 0.2%-0.3%, they wanted to match fees elsehewre in EU (not in France)
... If they didn't do these higher fees, they were taking much more risk.
... Systems in Italy - click directly on bank via credit transfer.
... Recently proposed regulation - we want to create a level playing field - it can't be done by competition enforcement.
... it cannot act very fast - mastercard case took 7 years.

<phariramani> Alexander: competition enforcement cannot act fast//last mover advantage

Alexander: So, we want to create a legal base for non-banks - third party providers.
... So, here's the proposal:
... Promote consumer welfare - reduce excessive fees.
... Increase choice
... Promote competition, efficiences should be passed on to consumers.
... We want to reduce barriers for competition and increase transparency, reduce barriers to entry.
... Reducing interchange fees - Monnet and PayFair - they cannot enter the market because banks are expecting a similar revenue.
... Banks are keen to have more expensive card payments schemes, so we need to work on that.
... the commission proposes - regulate the fees of "Must take" cards - 4 party schemes, consumer visa/mastercard card.
... National schemes are ???
... Immediately cap the fees for cross-border transactions.
... Promote the idea of a single market - 2 years delay on national/domestic transactions.
... More effectively functioning cards market -
... What we can do:

Aleander: Allow merchants to refuse cards, ... (missed)

Alexander: Provide a legal base for 3rd party providers - supervise licensing, make sure their presence in the market is secure - supervised/licensed, identify themselves, limit access to minimum necessary.

scribe missed slide 13

Alexander: No strong confidential data, need strong authentication.

State of play regarding proposal.

Alexander: EU Parliment voted in 20 Feb 2014. MIF caps after 1 year, 7 cent max debit fee
... Caps should also cover commercial cards.
... Cross-border acquiring at rate of acquirer's country.
... Ongoing work on Greek Presidency, undder Italian presidency in Italy.

Eric (from ING): Considering that fees were identified are also being used online - does that mean it's a basis for services like MyBank to consider?

Alexander: No, under competition rules, we have the obligation to say that there is a problem. They can always come forward w/ efficiency arguments. They'll find it difficult to do.
... So, I don't see what efficiency arguments they could bring forward.

Dave_Birch: I don't see what the principle of the regulation is?
... Since the DG Competition has been doing this for a decade - and there is no new competition. I don't get what you're doing?

Alexander: I don't think it's fair to say nothing "new" has happened, there have been new things.

Dave_Birch: you can only use it in the Netherlands

Alexander: There is so much money floating around in this system, banks have not wanted to comply w/ competition law. Mastercard has made no attempt to do anthing other than bare necessary changes.
... Visa has always made changes at very last section. We haven't seen lowering of interchange fees. It takes a very long time to force people to do it.
... Regulatory approach is necessary. If we enforce lower interchange fees, we might be able to do something about it.

Hannes: In Jeff's talk - he said we should have more user choice. Been working on identity - there's an interesting pattern. Little choice w/ identity providers on internet.
... Identity providers layering payment on top. How do we provide more user choice? To prevent us from using 3 payment providers that are going to be US companies.

Alexander: Regulators have a hard time leading the market.

<dka> Some side discussion going on here kicked off my my comment on http 402 status code and also link rel=payment (see http://relpayment.com) : https://twitter.com/torgo/status/448016153869574145

Alexander: Danish market - banks operating through banking association - NETSID - ID system used by danish banks - used for online gaming.
... Way of verifying that people are over 18.
... This is the only recognized system - banks have used this power to kick out new entrants. This is a difficult area for regulators to get involved in.

Chaals: Two questions - in 3rd party providers - they're not allowed to store confidential data? What kind and why? Isn't there a risk that if you silo off EU as a limited income space, won't they just jack up the prices for the rest of the world? Isn't that what they do?

Alexander: Second question first, this is an argument that we often hear from the banks / card schemes. What we see is that we're moving away from hidden fees to fees people can see.
... System of transparent pricing - see what happened in US - Durbin amendment - banks said that they want to increase card payment fees, found that they couldn't do it - people didn't want it.
... Banks would like to say - we want to raise fees - they will be constrained by market opportunities. If they could raise them, they'd have already done it.

Chaals: There is a difference between transparency and caps on pricing.

Alexander: In this case, we're capping the part that customers can't see

Chaals: TPP's and why they can't hold data?

Alexander: The concern is that payment providers can hold your data and get back into your bank account.
... That should not be possible, there should be a transactional business model. You leave no trace w/ the TPP.
... Minimize risks - they need to keep basic info on transaction.

Format of Sessions

Stephane: We're trying to keep presentations short - less than 1 hour. Chaals w/ be moderator for this session

Overview of Current and Future Payment Ecosystems

Stan: Hello, I work for Hub Culture - one of the first social networks. We operate a digital currency, It's been moving into financial markets
... I want to talk about the idea of reserves, social contract, and identity.
... These are core to payments. The size of where we see digital currency - by 2017 2.5 billion unbanked coming online - low incomes, not profitable to find banking solutions for them.
... 2018 bots doing around $1T in transactions - humans now playing day to day in transaction.
... 2020 - 50 billion connected devices
... Social connections are important, virtual currency allows us to create/maintain accounts relative to connections.
... A few things in Ven that are valuable - Ven is 100% asset backed - wide variety of currencies - it's stable... 50% less volatile than other currencies.
... It's global, it's secure - you don't use credit card / banking system to move it around. zero transaction cost.
... We introduced "carbon" into asset - so actual money backing currency builds in natural protection for nature. This is our answer to "social contract" concept.

<bryan> usecase: autobots that execute financial operations on behalf of users

Stan: Even though Ven isn't fiat - it is a ledger of value and recorder of value.
... These currencies can have positive benefit to society.
... We think we'll do $1B in transactions this year - it's traded in the global markets.
... Social network that runs Ven is an open source set of APIs. Apps on core platform are moving towards open source so that others can innovate/build around it.

Stan shows Hubs that show Ven.

Stan: We're working w/ partners - authorities that can issue/redeem Ven.
... We're working on identity - HubID - KYC and AML solution for digital currency on the Internet - can be used by anyone.

<bryan> kyc? aml?

KYC == Know Your Customer

AML == Anti-Money Laundering

<phariramani> AML = Anti Money Laundering

Stan: We're creating open source crypto vaults that are issuing identity to individual uses on the Web. You own this ID - self sovereignty on the Web.
... We don't sell the data that's connected to underlying users - we work off of a transaction model. Data is safe and not being looked at.
... In return for this, we can give you a unique profile/badge - more data you put into that vault, it generates an "aura" on the Web. They only have to look at your HubID to know how authenticated you are.

<bryan> usecase: personal vault can host information/assets and issue ids useful for various things (e.g. payments?)

Stan: Size of your network, bank number - you own this stuff yourself. No one can access this data w/o your knowledge.
... In this way, you have much more information, much more granular control.

<virginie> HubID : http://developers.hubculture.com/info/hubid

Loud ringing drives Stan off of the stage.

<bryan> usecase: managed access to personal identity/attributes as economically valuable assets in a payment system

Ken Isaacson from US Federal Reserve takes the stage.

Ken: I lead Future Payment team - national US Fed effort. Improves the payment system in the US.
... Fed has multiple responsibilities - provide financial services to depository institutions - that's where this intiative is being led.
... Supervisors - we don't represent the monetary policy or regulatory side.
... One of the things we do is every 5 years, we update our strategic direction - essence of refresh is to improve safety-speed-efficiency of the system, from end to end.
... Renewed focus on speed - make payments faster.
... End-to-end - Fed has focused more on inter-bank - now we're focused on end users.
... We put out a public consultation to have the Fed put some ideas out there on the problem in the US - what we can improve - desired outcomes.

<wseltzer> Fed's Payment System Improvement Public Consultation Paper

Ken: Desired outcomes - strategic industry engagement, ubiquitous real-time payment capability, improved efficiency, cross-border payment improvements, enhanced payments safety and security.
... Multiple work streams feeding into the Fed - three other work streams.
... Fed's retail payment study - important to figure out where we are.
... Data of 2012 released publicly in 2013 - 122B total

ACH == Automated Clearing House (bank-based payments)

Ken: Breakdown - less checks, about the same ACH, more credit card, much more debit card, pre-paid card...
... Highest areas of growth are Debit Cards / Prepaid.
... Public consultation paper - asked anyone to give input on how we could improve.
... 200 responses - bottom line - agreed on gaps/opportunities that US Fed put out there.
... Fed should become more active, non-banks want to get involved, desire for faster payments, unfairness in risk management.
... End-user research - 1,200 consumers - resuls are here
... 69%-75% prefer instant or one-hour payment systems.

Chaals: Next speaker is Evgeny from Yandex.

Evgeny: Yandex Money is the payment system provider for Yandex - huge search engine/shopping company in Russia.
... This is a payment service provider perspective. We need a standard?

<mauro> s/Yvgeny/Evgeny/

Evgeny: We want to decrease the friction for user payment, we want to improve security, the standard could help both of these things.
... We want to provide interoperability - let's talk about markup.
... One parameter, lots of parameters - markup can help user. Browser - start email app.

<bryan> usecase: invoke payment service via uri scheme

<inserted> [

<bryan> sounds like the earlier vision for web intents, in which "pay" was one of the actions I recommended be on the roadmap

Evgeny: We want to have a standard like mailto: but in the payments area. We want to help someone that wants to pay via this link markup - payto:mybankcom/payto.xml?item=BigBook&sum=10$account=28394728&someotherparams=foo
... Who can process the payment?
... The benefits is this is just a simple link
... Stuff like this is the sort of stuff we can expect from a standard.
... Once you click the link, the payment process begins.

<chaals> usecase: simple URI system => simple payment markup that developers get right

Evgeny: Once we initiate the transaction, we need to know where the money comes from.

<bryan> ernesto, really a solution, but hard to distinguish from use case at this point

<chaals> usecase: allow selection of payment processor

Evgeny: The source of money can be different, changed during the payment process, this can be complicated infrastructure for banks/payment processors.
... We also need to be concerned about the confirmation mechanism (how does buy er say they hve money, seller has the goods)

<bryan> usecase: switching payment method in the middle of transactions

Joerg: Would you be able to incorporate user loyalty cards / coupons in your solution?

Evgeny: We don't wan to restrict for loyalty cards - maybe not for first version.

Ricardo: This is more a suggestion of an intent-based payment mechanism? Was this a proposal?

Evgeny: This is an idea, it's supposed to make it easier.

Chaals next up is Harish.

<bryan> re invoking payment via a URI, is a well-known resource essentially equivalent to a uri scheme in this case / for this purpose? that's something to be considered at qa technical level I guess

Harish: I'm from the world bank, payment system deliveries group. Let's focus on public policy perspectives - safety and efficiency is a goal.

<chaals> usecase: allow loyalty cards, coupons, etc as a payment mechanism

Harish: We care about affordability - 2.5B who don't have access to payment services can't afford costs.
... We want access - goal should be to expand access.
... Moving to electronic is not necessarily an objective - there are costs there - things like excessive use of credit cards may not be ideal.
... There have been studies done on what a good electronic payment mechanisms can do for a country... Brazil did a study that showed that they could save a almost 0.7% of GDP, huge savings.
... Cost of cash is about $70B to businesses - that's in US.
... Government payments - small amount of cash distribution to families in Brazil could be reduced by 80% if moved to electronic.
... cost of international remittances is ba - 11% of transaction cost - we want to move to 5% by 2018. From the slide, there's a significant gap

<bryan> usecase: national incentives for using web-based payments due to beneficial effects upon economy

Harish: Moving towards electronic payments - wide disparity
... Number of cashless transactions (missed slide 6)
... Here are the factors that matter: infrastructure is bad, competition and cost is bad, government and corporate payments are not being addressed, risk management mechanisms are not adequate.
... This is a chart that shows percentage of populatio that has access to payment network (slide 8)
... 2010 - we looked at diff payment instruments being used.
... Top payment instrument by volume.

<bryan> usecase: access to payment systems by non-traditional channels, where barriers exist for traditional channels

Harish: check usage is substantial in low-income countries. Direct debit are lower in those countries as well.
... This shows that traditional electronic payment instruments are also not being used for payment needs in those countries
... Here are a few trends - technology and new payment needs are key drivers for innovation.
... There is a greater involvement from non-banks in retail payments - these are not banks.
... Pre-paid products are also on the rise - lots of different types of emoney - this is at an early stange.
... Business model, card payments - greater usage of authentiation mechanisms - biometric, 2 factor, etc.
... Broad shift toward near-realtime in traditional payment systems - examples in Mexico, India, etc.
... The objective - universal financial access by 2020.
... Access could be possible by 2020.

Chaals: Olivier is next from Worldline.

Olivier: Where do you draw the line between Web Payment and non-Web payment? We've talked about cash and non-cash payment mechanisms. What is current, what is past? It's not clear.
... Basics of payment is a buyer and a seller. Let's say buyer has a smartphone and seller has a POS (Point of Sale)
... Let's say they want to do an EMV payment.

<bryan> emv = https://www.emvco.com/

Olivier: So, EMV offline payment is done - POS terminal won't go online to query about issuer/account - this is an account present transaction

<bryan> EMV = Europay Mastercard Visa

Olivier: What does this have to do w/ Web Payment? It's not even online, it's offline.

<bryan> usecase: secure element based offline payment

Olivier: These are secure elements, the cloud is involved - let's go one step further.

<phariramani> Actually he is talking about non secure element based payment where payment credentials are in the cloud

Olivier: On the POS terminal, there was no PIN input - that was done on the buyer's side.
... There is an app on the tablet for the seller. Let's go one step further, let's get rid of the tablet - let's say everything happens in the web browser of the buyer - wallet app.
... So, there is a SE in the browser on their mobile phone - the idea was to give you some thoughts about where we draw the line.
... In both cases, we're doing EMV card not present transaction. So, cloud -> phone -> cloud?

<Zakim> Olivier, you wanted to give his presentation

Olivier: EMV is well suited - but where are we going.

XYZ: Do card schemes agree w/ this card not present mechanism?

Olivier: They said they'll support this architecture - they're going to publish a SE transaction spec soon.
... Offline EMV authentication - this has been around for 10 years - nobody uses it - what's the barrier?
... It's been adopted by some banks during the pilot, not on the wide scale - total cost of ownership is too expensive.

Dave_Birch: Costs are pushed onto merchant - surely these are cheaper if that weren't the case?

<bryan_> CAP = Chip_Authentication_Program http://en.wikipedia.org/wiki/Chip_Authentication_Program

Olivier: There are many reasons this solution hasn't been adopted widely.

Joerg: I don' think big difference is offline - we don't expect everhything to be online, always.

Olivier: Technically, EMV is "offline", but you need to be "online" to perform it.

<bryan_> usecase: browser-mediated offline transactions

Chaals next up is Erik Anderson from Bloomberg.

Erik: I'd like to talk a bit about remittances - $1.1B live below $1.25/day
... There are a lot of people in different parts of the world that don't have access to financial networks/services.

<Axel_Nennker> e.g. Mastercard does not care (much) about the channel how their applet is reached. Can be over the web.

Erik: Remittances are growing - $400B today - these are people trying to send money back to their family. How are you going to get $20 to your mom in Brazil when it costs $30 for the wire transfer?

<bryan_> usecase: sending money to family internationally via low-cost methods

Erik: The countries where you need the money the worst are the most expensive to send it to.
... South Africa -> Malawi - 23% to send the money - people provind gthe services get that money.

Erik shows complex slide showing how money flows.

This is just for US -> Mexico.

Erik: Every one of these steps, someone takes a percentage of this money.
... Let's just go from the person -> US Feds -> Person.
... We should also look at Cryptocurrencies.
... Out of all 7 stages that your money goes through, each one of these people makes money.
... Saving 5% per year is 15B extra to those familities.
... Many places in Africa have bypassed traditional telephone lines, they have mobile phones - computers in their pocket.
... FinCEN needs to come up w/ creative solutions to handle currencies.

<Zakim> Erik, you wanted to give his presentation

Erik: Everyone that sends value must be licensed - etc - high cost of compliance. They have thousands of compliance officers to meet regulator.
... Anonymity is Evil (stay with me)

<bryan_> wow talk about your value judgements!

Erik: We should put the regulations in the protocols.
... Underground economy that people are trying to send this stuff to - these folks live on $1.25/day

<chaals> usecase: enable financial regulation (e.g. reporting above a certain value) to be implemented directly in payment protocols

Erik: System D - people were classified into standard money users - kid selling koolaid and someone else running drugs categorized into same area.

<bryan_> usecase: zero-trust transactions

Dave_Birch: Anyone read FATF recommendations? Those recommendations say to target higher value transactions.

<virginie> reference to FAFT http://tomorrowstransactions.com/2011/06/the-fatf-report-on-new-payment-methods-has-very-sensible-conclusions/

Dave_Birch: So, we should reduce these costs - any oppotunities to remove these?

Erik: What gets reported when - $10K in the US, China - it's probably $100. We need to put financial regulations into the code - don't focus on compliance officers.
... Put the regulatory call-outs in the technology - that's a use case.
... So, let governments know what they need to know while keeping out of their business.

Joseph: Put code is law - is that Lawrence Lessig's work?

Erik: Yes, that idea has been floated around the cryptocurrency world - so yeah.

Chaals thanks panelists.

<bryan_> Code is law -> http://codev2.cc/

Dave_Birch: Banks thought that things were fine, everyone else didn't.
... How is the US Fed going to weight those comments? In the EU, the government had to step in and mandate it.

Ken: our perspective is an end-to-end perspective. So, we have our high-level objectives. If there's something in the public interest, we want to support that.
... Many people said that the only way this is going to happen is to do a mandate - that may be where we're headed.
... So, regulators are watching, but we're operating w/in the constraints of the law.

WendySeltzer: Anonymous != Evil - we should think about customer/end-user interests. We should look at which attributes of identity are necessary where; users' interests may differ from regulators'. Focus on when we need to do it.

Erik: Depending on what government you need to go into will shape the regulation.

<bryan_> usecase: leveraging variable degrees of identity/anonymity per requirements of the payment transaction

Hannes: Does this new system need to work w/ legacy infrastructure - payment systems in Africa don't necessarily. These countries may catch up - they jump an entire generation of technology.
... I'm not quite sure I get the message.

Erik: We want a bridge - we can't replace everything in a day - Ripple will talk about it during panel 3.

<Zakim> dka, you wanted to ask how transferwire is addressing the international remittence problem?

Dan: I want to get back to International Remittances - it's an area that we ran into a lot of trouble when integrating into BlueVia - if you want an end user to pay from Brazil to Estonia - then that's a huge issue.
... There are startups coming into the space that are doing better...

Erik: The problem w/ startups is that they're not top-down. Lots of financial institutions, govt. needs to be involved. W3C standards are a better solution. There are a lot of big players in this room that are going to be a part of it.
... Then again, startups are paving their way too - while others are taking a passive stance.

Harish: Broadly, what we're seeing is Visa/mastercard for international payments - aside from SWIFT, there is no such infrastructure. Earthport does some of this, so does Western Union.
... US Federal Reserve - international payment framework.

Hannes: Role of standards may be different here - you can always add more roles as people do - we may want to start fairly simplistic w/ very few standards.
... Maybe we don't need so much standardization.

<chaals> organisation to track new transfer systems

Stan: DAT Authority is important - reguator industry organization - related to cutting edge technologies - crypto, digital, digital asset transfer systems - Washington later this month. Look at it.
... That could be a good link to what's happening here.

Ricardo: It's nice to think that standards are going to solve that stuff - but W3C can standardize protocols, it's the financial operators that need to implement this stuff.
... At BlueVia, we were thinking of doing these transfers w/in ourselves. But when we do that, law comes into play - if Visa/Mastercard have effectively a monopoly, how can business entities play the role of money transmitter?
... If you have a facebook coupon, and transfer to facebook in spain - no banks, no western union, now multiply that by several million transactions.

Adrian: Adrian from SWIFT - payment, 20022 - a lot of what you're trying to do is already done by SWIFT in some cases.
... We could start w/ ISO standards and see where that takes us.

Joerg: My assumption is that people want to know the money is there - US Fed - need more info (missed)

Ken: How fast you received the money is not as important as convenience. When asked all other things equal, most everyone said "Yes".
... Consumers - speed of debiting is more important than crediting. With corporations - they care more about getting the money faster.
... But that's not always the most important factor.

Harish: What's the expectation of the consumer. P2P transfer - they expect it to be near real-time. For a business, they want confirmation of payment.

<bryan_> usecase: realtime purchases involving prerequisite reception of funds from international sources (e.g. family)

Chaals: Fast transactions - remittances Australia -> Spain - market case of buying something.
... Different use case - I want to mix the sources of payment, don't have anything big enough to cover. Nearly all of that money should get to who I'm trying to pay. How easy/hard is that today - is it important?

<bryan_> usecase: mixed sources of payment for a single transaction, using multiple payments with minimal transaction overhead

Joerg: I'm wondering if we're misled about the topics - Credit Cards are great, I can choose to pay much later.
... People taking money out is a good thing.

<bryan_> usecase: selection of payment method based upon desired payment delay

Joerg: There is innovation there, we need to encourage that - we shouldn't say one way or another. We need a wide variety of things around payment.

Evgeny: Let's talk about small payments - payments should "look" fast. It should seem fast, even if the money moves more slowly. Backend speed doesn't need to increase, front-end speed should only be necessary.

XYZ: We did some studies (somewhere) - You can't compete against credit card - test groups, active online buyers - speedy debiting was an advantage. Overspending on credit card was a bad thing wrt. customer thoughts.

Alexander: Single transaction would be nice, efficiencies to be driven there.

<jungkees> Alexander Gee

<chaals> s/yyt/Alexander/

Connie: On the merchant side - different point that we've heard - merchants need feedback - many retailers have business cycle where they're taking in revenues on weekend. They'll use credit/debit - but they have huge swings in liquidity - big credit facilities to help offset these swings.
... So big input on Thu-Sun, but they don't get money until Tues.

Emil: Are the merchants willing to pay for earlier servie.

Connie: 1/3rd of consumers say faster payments would be okay if it costs more.

<bryan_> usecase: option to get faster payment

Connie: 75% of businesses said they'd like that.

Ken: it varies by use case - sometimes ome of the antiquated systems - ACH - doesn't have any of those features.
... So, you need to look at each use case to determine if there is a gap or not.

Chaals: So, people want a wide variety of options, but asking people what they want doesn't mean that they'll tell you what they need.
... What are people already spending their money on in an array of services.

Jeff: Jeff, W3C - we've heard a number of different comments on what people would like to see. Some done by companies, some by regulators, innovators.
... What's the role for Web standards - what do panelists want to see in web standards.

Olivier: The trend is to mix payment, shopping experience, first payment provider - Alipay - escrow type of payment - it's cultural. In China, people don't trust seller. Every culture has its own way of making payments.
... We need to create a basic mechanism that enables all of these use cases happen. We shouldn't focus on commerce use case.

<bryan> usecase: selection of payment service based upon ability to handle escrow for untrusted merchants

Olivier: If we try to support all shopping use cases, it won't work.

Harish: From a data standards perspective - I think payment systems community is working on it. There are existing standards.
... The intent to pay and how to pay is a good area to focus.
... The interactions between new payment mechanisms - how do you exchange new payment info.

IngenicoXYZ: Payment is about trust, security, convenience - Web technology should focus on bringing trust/convenience.
... People need to be comfortable w/ payment online. Complexity of payment online - fragmentation of market.
... We want technologies to ease integration of payment w/ nice user experience.

<dka> +1 to focus on trust / convenience

IngenicoXYZ: Web technology is right technology.

<mauro> sIngenicoXYZ/IngenicoXYZ/g

IngenicoXYZ: Payments/business integration - payment is separate from everything else business related.
... We want payment to be integrated w/ business application.

Evgeny: The important thing that a standard can bring to us is a good user experience.
... Why do they want my phone number to any service that asks for it?
... The security mechanics - everyone should be able to implement it.

Joseph: These standards need to be explicit about rights/responsibilities - what rights do they have? How can one impose stuff on other merchants.
... Many merchants complain that many things are imposed on them by credit card companies.

Ken: In Australia - they mapped out payments use cases - then made a determination on whether it should be in cooperative space. One potential approach could be to do that. Where is the boundary between cooperative/competitive.

Stan: On the Internet, the things that we now have, like blogs - are along side the media players - we have this whole forest of new things that have appeared. 2005-2015 is happening in finance.
... it's important that we take an open approach to standards.

Louise: Louise Bennet, BCS - follow up on rights/responsibilities. It's vital from business/consumer perspective - where is the liability. Some of the panel were talking about regulators, when is the regulator going to impose of something on the standard. At what point is a regulator going to say that KYC is required?
... Do we know what the regulator is going to impose?

<bryan> usecase: rights & responsibilities of a transaction being associated with the context of the transaction, and conveyed to parties in the transaction

Erik: KYC is going to be hard to give up - it's going to have to happen - they're going to have to happen. I built a lot of the systems that people in this room works, but before I start building something, I need to know the standards before I do that, though.
... One person in XRP, another in Bitcoin, how are they going to interchange? Without those standards, we can't build anything on top of them.

Ernesto: I see this as where we draw the line wrt. what we can standardize.
... I'm interested in payments, not necessarily in cryptocurrencies. This is very much aligned w/ Yandex - This is like supporting existing technologies for money - more convenient.

Dave_Birch: Anonymity is Evil - so I'm going to agree on that - US printed $22B in non small bills.
... Number of US currency in circulation is very large. If you kick down the door of a mexican drug dealer, you don't find Bitcoin, you find USD.

<bryan> anonymity is evil = cash is evil? both are suspect concepts IMO, and their equation is suspect squared

Chaals: I think we need to be aware of the case where I order sushi to my house - it works on a very high-trust system. I fill in a form, sends a form to someone 2km from my house, they bring it to my door, and then they expect me to hand over some cash.
... Building systems that ignore that would be bad. Let's not restrict things people are doing. I'd like standards that take a layered approach, there are some basic things we do, and there are some basic things we need (like security) that should be in there from the beginning.
... The bottom layer of the standards need to be solid. We want future standards to bild on top of the base layer. We don'tn want to prevent further standardization. We want competition/innovation to give us more.

Bryan: This might be cash being an aspect of anonymity - we're trying to collect use cases.

<dsr> Bryan: is zero-trust transactions on the table?

Ricardo: 20% of electronic transactions in Brazil are done by a printed system - you pay in a bank/shop - 20% of digital transactions are anonymous.

<dsr> Chaals: yes it is definitely on the table.

Joerg: It's always possible to grant anonymity - we should have that.

Chaals: Building regulation into code - we should think about whether we want to deanonymize all transactions immediately - we will create a digital underground mechanism.

<bryan> trying to clarify the sentiment here, it seemed that people are equating anonymity with zero trust, which perhaqps is not necessary, but the role of identity/anonymity of zero-trust transactions is a key question, if that type of transaction is to be on the table as a use case (which I think it should, at least from the perspective of some participants in a transaction, if not all)

Chaals: Who is tracking my transaction? Can I influence that?
... An identity at global scale is a big identity scheme to roll out.

<Sergio_Aquero> US printed $27 billion in non-$100 bills, lowest since 1981

Hannes: When some of you use privacy - and it appears there is a black/white - that's a bad characterization. We need to figure out which player sees what in the transaction.

<Sergio_Aquero> So the US is printing record amounts of $100 bills, which are used primarily for criminal purposes

<bryan> personally I like $100 bills...

<Sergio_Aquero> ergo the US is in favour of anonymity for criminal transactions but not for legitimate transactions - seems a crazy policy to me

Stan: A couple of quick points - founding ethos of Web - anyone can contribute. With payments in particular, with identity - it has to be in a careful way so that founding principles can be held in place. We could accidentally put us on the road to totalitarianism, there needs to be constant churn in power structures. We don't want to lock in power structures that are detrimental.

<bryan> though getting change for them is sometimes problematic

Stan: There is much more at stake than just a payment transactions, we need need to preserve human freedom on the Web.

<bryan> usecase: take the change for your $100 bill through a web payment

Olivier: Anonymity is meaning less and less - there is room for anonymity. No system has made it through, but we can't wipe it off of the Agenda.

<wseltzer> [for more on anonymity, see Financial Crypto, PETS Symposium]

<evan_schwartz> Session 2 — Toward an Ideal Web Payment Experience

<evan_schwartz> I'll be scribing for this session but unlike Manu I don't know everyone's names. To all on IRC, any help with figuring out who's talking would be much appreciated

<evan_schwartz> will do

Toward an Ideal Web Payments Experience

<wseltzer> speaking, Natasha Rooney

<inserted> scribenick: evan_schwartz

Natasha: in this session, 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

Manu Sporny: "Cat herding 101", everyone has a different idea of what to standardize

Manu: W3C creates standards through consensus, "ideal" payments experience is subjective and there are many, we can only realistically standardize parts of the experience
... don't want to beat innovation out in the process
... 3 main inputs to standardization: position papers, input from Web Payments Community Group, attendees of this workshop
... 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%)

<mhepp> usecase: verify identity or assess trust of partners in a transaction

Manu: didn't think identity was going to be such a common issue but it was the #1 issue cited amongst the papers

<mhepp> usecase: initiate / request payment

<mhepp> usecase: issue, transmit, validate proof-of-purchase

<mhepp> usecase: find and compare payment options for transaction

Manu: 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
... Web Payments CG - 146 members -- not an official group at the W3C, existed for ~3 years, creating space where open payment technologies can incubate
... currently working on 14 technologies that can be applied to payment problems
... machine-readable products and offers, initiating transactions, digital receipts, identity, web security upgrades

<mhepp> usecase: digital receipts

Manu: (types of tech being worked on)
... workshop attendee input: looking to determine problems, constraints, use cases, goals, and actions for the W3C
... 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

Kumar McMillan: for the past several years mozilla has been building mobile OS called Firefox OS

Kumar: looked at HTML5 and available APIs, tried to create APIs that did not already exist
... wanted to have commerce as part of the mobile operating system, for developers to sell apps

<mhepp> usecase: selling apps in mobile scenarios

Kumar: navigator.mozPay is not on the standards track
... talk will focus on what can be standardized based on mozilla's experience
... web payments work today
... 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
... there are some problems
... credit card numbers are insecure, mobile billing is broken in some major ways, new customer info, no standard for asset ownership

<mhepp> usecase:: Prove asset ownership

Kumar: credit card numbers are totally insecured, Target got hacked and I had to cancel my card, get a new one, and update all of the accounts
... why are we giving people credit cards when all they want to do is make a specific payment
... payment tokens for merchants: merchants could give token that requests specific amount of money and token expires

<mhepp> usecase: temporary payment tokens for mechants

Kumar: payment processor needs to move money from customer's account to merchant account -- merchant doesn't care how payment is executed

<mhepp> s/temporaty/temporary

Kumar: PayPal hosted flow works with tokens, mozPay JSON web token works the same way, as well as Stripe and Square
... merchant never receives credit card number

<mhepp> usecase: mobile billing

Kumar: 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
... don't know how to fix this, operators need to step up and fix this
... at mozilla, introduced silent SMS API, they'd like to extract that from mozPay -- still just a better hack
... Apple's facetime has published how they do silent SMS

<mhepp> usecase: registering new / as a new customer

Kumar: 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
... 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
... 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
... 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
... digital receipts could be standardized to help payments
... payments work well, it's important to focus on things that are real problems
... also important to think about what are the payment primitives? the basic, low-level building blocks like the token idea

Yaromin from Dynorg (?): 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: whitelist of payment providers may end up being deprecated, need low-level building blocks for accessible APIs

MartinHepp: how is the idea of digital receipts related to the work on schema.org? -- could be applied to JSON-LD representation

Kumar: no plan right now to align this with JSON-LD but he thinks it's a better idea than Mozilla's free-form JSON

Stephane Boyera: mozPay seems like an interesting abstraction across other payment provider APIs

Kumar: 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: 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
... 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
... there are issues with the current security aspect, chromeless webapps or native applications, how can you determine if you're in a secure application
... certificate model of web security is broken because people don't pay attention to it, people click through even on old certificates
... innovations in payment UI like using camera to recognize credit card, but then there's a privacy issue
... loyalty cards have interesting developments
... mobile ticketing is also part of payments
... 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

<mhepp> usecase: loyalty cards

Bryan: people should look at the push API he's working on with Telefonica
... payment is personal, enabling user choice in everything regarded to payment is a key aspect of the UI
... W3C doesn't have to address entire industry but it should look at key use cases and requirements
... UI for web on moblie is very diverse, all of contexts should be supported. Don't want a fragmented web UX
... 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
... 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: 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: 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

David 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: digitally signed invoice can act as the receipts
... 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> +1 to Dave Birch point on TEE optimism

Kumar: maybe the token doesn't need the W3C but I want to see sites stop using credit card numbers

<bshambaugh> Hello Web Payments Workshop!

Kumar: 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: people should look at global platform for TEE, this is a problem that's been around since feature phones
... it's a general problem of the web that things can pop up and take over the screen

<virginie> note : light explanation of Trusted Execution Environment technology there : http://poulpita.com/2014/02/18/trusted-execution-environment-do-you-have-yours/

Ricardo: 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: many position papers separate UI and intent to pay, questioning whether UI should be standardized. What do people want from standards?

<stanstalnaker> hello world

Kumar: 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

<ernesto> usecase: 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.

Manu: agrees completely. 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 m[CUT]

Bryan: management of that type of data is the essence of evil, solution needs to be more scalable

Daniel: 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

* cues

Bryan: trusted consent is a general problem of the web

<bshambaugh> If I may ask, how's linked data, Ethereum?

Prakash: murkiness in terms of the standard for payment tokens, what does the Fed and European Commission think of the standards?

<virginie> note : some trusted user interface like work is discussed in WebAppSec see : http://www.w3.org/TR/wsc-ui/

can't hear unmiced commentors

Jeremy King: the standard that Mastercard and Visa have just related is taking tokenization from the issuer perspective and using token to iinitiate transaction

Jeremy: from PCI standards there is tokenization from the acquirer's side
... everyone's talking about tokenization from different ends of the spectrum

<mhepp> usecase: Tokenization

<BryanS> Not sure how the tokenization spec relates to the UX, maybe this can be clarified

Giri: re: mozilla telefonica paper -- why aren't client technologies for geolocation good enough? How will third party payment providers being included?

<virginie> note emvco tokenization framework : https://www.emvco.com/specifications.aspx?id=263

<chaals> (see above for an example :) )

Kumar: 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: 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

Hans: 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

<BryanS> 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: 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> there is not only stolen phones but a lot of stolen OTP are due to cloned SIM issued by the operators

Daniel: security is a payments issue. per PHB, HTTPS was designed for payments, i.e., to make consumers feel confident enough to make payments online.

<BryanS> 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: 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: does anyone even have an idea of what the ideal UI would be?

Natasha: too many stakeholders

<Ori_Eisen> sorry, new to this format ;-)

<steph> i believe we are mixing ideal functional interface vs ideal design

Manu: never heard an idea that would work for everyone

Bryan: 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.

<Zakim> chaals, you 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

<BryanS> 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.

<steph> +1 to Dan

<Ori_Eisen> thanks!

Chaals: 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. This wouldn't be restricted[CUT]

<jaromil> evan_schwartz: s/Yaromin from Dynorg/Jaromil from Dyne.org/

thank you

<BryanS> 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).

Chaals: might be way to standardize receipts

Natasha: 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: good case to start looking at it

<virginie> Note : UI with security merits may be worth looking at

Jorg: need to differentiate between UI and user iteraction patters, need to get into user interaction patters which blend into technical transaction interactions

<chaals> [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]

scribe is getting very tired of typing :(

<BryanS> 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.

<dka> +1 to thinking about interaction (not interface).

<steph> +1 too

<BryanS> Would web components provide a means to create secure interactive elements?

<schuki> BryanS: I was going to say!

<jeff> [+1 the distinction between interaction and interface is a helpful distinction]

Daniel: interaction is the more accurate term than interface

<chaals> [… 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: what would be the role of web components? they could provide secure interactive elements

Natasha: B2B payments haven't come up yet

<phobeo> 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: 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

<Zakim> ernesto, you wanted to comment on UI specification

<mhepp> usecase: encrypted media extensions

Ernesto: 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
... different aspects of this could be standardized separately as layers

<BryanS> 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.

<chaals> scribe: chaals

<evan_schwartz> thank you so much

Manu: Don't think anyone is arguing against a layered approach

DKA: Agreed

<Zakim> steph, you wanted to talk about merchant ideal experience: adding easily psps without changing a line

Steph: 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: 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

[chaals thinks a standard is a far better tool than an Open Library]

… that would get traction.

<dezell> +1 to chaals

Steph: 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.

<BryanS> 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: 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.

<BryanS> 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.

Steph: Think that would solve the issue. It isn't just an account today, it is also writing a whole backend.

Manu: So where to they open the account?

Natasha: Wallets might be able to handle that, giving a bundle of accounts.

… people innovating around there can cause issues.

<Zakim> wseltzer, you wanted to discuss privacy

Wendy: 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.

<Erik_Anderson> They want it more simple

<stanstalnaker> d:) deep thought - what would an httpp:// protocol look like as a means of annotating a potential payment marker

… some attention to the UX is needed. We need some workto standardise and help people see they don't need to be an expret in choosing providers to do business, don't need to do a lot of research before knowing if payment will work on the web.

[chaals to stan: payto:… ?]

… we want this to happen, where can we do the work?

<dezell> Merchants want choice, but not necessarily infinite choice. Having ANY choice would be a huge improvement over status quo.

Hannes: 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 propoerties.

… relates to white-listing/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.

<BryanS> 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: has happened in eg WebRTC too.

<Erik_Anderson> +1 core

<schuki> virginie: Ori_Eisen

Ori: 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.

<virginie> .me thanks schuki, helps preparing my security session

… 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.

<BryanS> APIs are the analogy of the shell

<wseltzer> [Kerckhoffs's Principle, that a cryptosystem should be secure even if all is disclosed but the key; transparency can aid security]

… 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.

DKA: 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.

<schuki> acl tobie__

<Zakim> tobie__, you wanted to comment on non-normative UI/UX work

tobie: 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> [Jeff supports Tobie's point. We often call that "Best Practices".]

Erik: All the merchant cares about is getting the money into their bank. What is their experience going to be?

Manu: we ar focusing on customer experience and especially security issue for them, not "does their payment provider match the merchant"?

… Visa and MC don'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.

DKA: 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: Why do we need to standardise? Merchant can accept bitcoin.

[there are some governments who take a dim view of merchants doing that]

<steph> -1 to Kumar

Bryan: 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: Any merchant can integrate any currency, so long as the value ends up at "X". Ideal is that when a vendor implements a cart, the mechanism is the same across currencies. They just want a receipt for the amount they asked for.

<steph> +1 to manu

DKA: Sometimes the vendor needs more info than the credit, e.g. for regulatory requirements (reporting, etc)

Mountie: 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

DKA: So learn from cryptocurrency and bring ideas into mainstream payment?

<BryanS> The third idea seems to call for vendor reputation integration into the UX for payment.

Mountie: No, we get votes from users. Accumulating votes can use the bitcoin transaction history mechanism to increase trust.

Manu: Trust of merchant based on other transactions. More people work with them, the more you an trust them.

Mountie: Also user experience reports. No trust until you get "xyz" accumulated experiences

[chaals: problem with that is how new entrants get on board]

<Erik_Anderson> usecase: Merchant and User reputation

Bryan: reputation is integral. If we could integrate verifiiable reputation recommendation it would be valuable

<wseltzer> [I hear "two-sided market"]

<dsr> Bryan: reputation is important for all the parties, not just merchants

Ricardo: payments with cards are optimised for merchants. I ahve no idea what I get charged when I make an international purchase.

<BryanS> Usecase: reputation based selection of providers in a payment transaction, or info about merchants to help the user choose whether to complete the transaction

… 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> now in France you can be charged for exchange rate between EUR and EUR …

<Parslow> I'm sure this existe also elwere chaals

Jorg: 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.

… f 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: Seemed from position papers that stronger solutions were the simple things. Is a simplesolution the right thing to do? What would it be?

Kumar: 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: 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.

… best approach to failure is to try and make this a big standards initiative, we need to start on small blocks.

DKA: +1

Bryan: 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)

Natasha: 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.

<Hannes> It was interesting that all panel members argue for **simple** solution

<mhepp> usecase: whitelisting of parties - users, merchants, payment providers

… flow from the merchant perspective is important - we are all users, but not all merchants.

<Hannes> (Nobody every argues for complex solution and for standards that are hard to understand. How boring is that?)

… for standards, keep things simple and/or standardise in modules.

… We dabbled in stakeholders, and wallets (there is a session on that tomorrow)

<Hannes> Even consultants argue for simple solutions. They just add that the search for simple solutions is still ongoing and requires lots of work

… I'm eating your break, but while there, think of the primitives to standardise around and tweet with #w3cpayment tag

<wseltzer> [break]

<dsr> scribenick: dsr

<scribe> scribe: dsr

Session 3 — Back End: Banks, Regulation, and Future Clearing

<phariramani> Day 1: 16:00 Session 3 — Back End: Banks, Regulation, and Future Clearing starting

Stephane introduces the session moderator Erik Anderson

<phariramani> Erik Anderson: Session focused on banking, back end and regulation

Erik: this session will be more about the backend and the banking side.

(introduces Jean Claude Barbezange, Worldline)

JC: slide on legacy web payment mode

<phariramani> Jean: Front end: web form: declarative data: E.g. PAN, CVV

<phariramani> PAN = Personal Account Number

<phariramani> CVV = security code at back of card

<phariramani> secure mechanisms: 3dS, tokenization, dynamic CVX

JC: front end with a web form, declarative data, e.g. card info. Security with 3DSecure, and more recently tokenization.

<phariramani> Dynamic CVX provides better secuirty

<phariramani> Slide 3: Legacy Web Payment -> Back end

JC: also dynamic CVS for improved security. Also convenience for user, e.g. form auto completion and one click purchases.

<phariramani> Banking card: universal, fee for payee, some level guarantees

<phariramani> In some countries like Germany, credit transfer is used for nilling, home banking..

<phariramani> Ideal is used in Netherlands

<phariramani> Direct debit is used for regular recurring payments

<phariramani> Slide 4: Legacy web payment mode

<scribe> scribe: phariramani

depends on cultural user behavior per country/usage/trusted level

different rules for some functions: transaction collection, clearing/settlement, cancellation/refund, dispute, risk management, fraud detection

If token is used for txn lifecycle management then toke needs to be preserved for long period

Backed protocol is moving to ISO 20002

Slide 5: New web payment mode (crypto currencies)

Crypto tools: hash, asymmetric signatures, mathematical functions like pairing

currency virtualization: dynamic change currency

autonomous cryptogram contains all the data for the transaction as bank notes or coin.

Interest in reducing cross border transaction costs

in some cases can keep anonymous information on user

Slide 6: New web payment mode

Front end: P2P: Based on open source software wallet

Front end: Also based on new internet technologies like IP (TCP/UDOP), IP Address

Slide 7: New Web Payment mode: Back end

Real time with instant balance

distributed functions for txn validation

Slide 8: Conclusion

For both ecosystems, trust and security are mandatory

PSPs also have to develop authentication, risk analysis and fraud detection

Some standardization on web browser could be helpful like fingerprinting, secure inputs, API to secure client device resources

and privacy requirement on vendor

Erik: W3C is encapsulation layer beyond a low level protocol; need to consider legacy systems while considering standards
... introducing World Bank/Harish Natarajan

Harish: Build on topics introduced from this morning

Key findings from WB global payments survey...

Innovative = anything not based on traditional bank accounts

11% of innovative product transactions accounted for more than 5% of electronic payments volume

69% of innovative product transactions were growing

Slide 4: Findings & policy implications ..

Right hand corner of pie chart -> innovations could serve affordability & accessibility of payment services

Slide 5: interoperability

Interoperability generally associated with card products

Interoperability fosters competition and consumer convenience

Several levels of interoperability. Infrastructure, system wide & cross system

E.g. card level interoperability -> POS terminal in US can support cards issued by any bank as long as card adheres to standards

E.g. system wide interoperability -> Visa system

Cross system interoperability not as easily achieved

However cross membership across systems (Visa / MasterCard) could achieve cross system interoperability

Money transfer example: In some geographies money transfer operators like Western Union, Money Gram etc. prohibit sharing of agents; restricts interoperability

Slide 7: Infrastructure and access interoperability//use of clearing & settlement

More than 50% of innovative products settled in books of issuer and only around 24% with central bank

Slide 9: Legal and Regulatory Considerations

<bryan> AML/CFT = Anti-Money Laundering/Combating the Financing of Terrorism (AML/CFT)

4 main issues-> safety of customer funds; typical bank has deposit insurance however this may not apply for a non bank institution

<bryan> link: http://www.imf.org/external/np/leg/amlcft/eng/

Heightened AML/CTF risks: The way non bank accounts are setup created higher AML/CTF risks but can be addressed thru velocity limits, txn sizes

Weaker authentication could lead to higher fraud risks. E.g. SMS used by some for operator billing

Consumer protection: when a customer signs up for credit/debit card there are very clear requirements however that is not the case with many prepaid products so customer may not be aware of what they are getting into

<bryan> how to know if a customer really knows what they are getting into? $64K question

Need to ensure competitive market conditions: Avoid regulatory arbitrage. Banks subject to higher constraints but non banks may have more relaxed requirements

Oversight arrangements: Typically supervision is the term used; oversight looks at impacts to system as a whole and typically function of central bank. Non banks typically fall outside of this central bank purview

Conclusion: Innovative payment mechanisms expand access, efficiency but form a regulatory perspective they need to be seen as an integral part of the national payment system of the country

<bryan> usecase: payment process includes user informed consent requirements about "what they are getting into"

Dave Birch: 2 of the most successful schemes (MPESA and SMART Philippines) do not involve banks. Is that a coincidence?

Harish: They adopted a model that banks typically do not use (agent model) and a consumer pays model
... MPESA cash withdrawal transactions have a transaction fee of about on an average 1% but many banks are not allowed to charge users for withdrawing cash form their own account

Erik: Introducing Evan from Ripple

<chaals> [chaals wonders how much of the reason MPESA/Smart didn't come from banks is due to banks thinking "payment already works…"]

Evan: Ripple = global, open source decentralized payment network that connects other payment networks

Evan: Talk about how Ripple can make payments faster, easier and cheaper for everyone

Ripple = Global decentralized open source network

Ripple Labs = company dedicated to supporting Ripple's development

Next slide (no slide numbers unfortunately) : Ripple payments are . . .

Ripple payments are fast, free, in any currency, global and secure. Can be done in any currency, gold or any stored value

Slide: Payments technologies are not interoperable ..

payment technologies do not work together because inter network transfers are slow and expensive. Very difficult to move money cross border

Slide: Web payments need decentralized clearing and settlement

There will never be buy in for a centralized clearinghouse

Slide: Ripple connects payments technologies

Ripple takes 2-5 seconds to settle and is essentially free

Slide: Ripple connects payment networks (slide with Paypal, Bank of America logo)
... Ripple has 4 broad categories of users

Basic user example is someone trying to send a payment

Merchant, market makers and gateways are the other 3 users

Slide: Send from any currency to any currency ..

Network takes care of all the exchange and this is seamless for the end user

Slide: Receive only the currency you want

<bryan> usecase: send money to any currency type

This is great for merchants because they can accept only the currencies they desire. No currency risk with Ripple

Slide: Market makers facilitate exchange

<bryan> usecase: receive money in a desired type

Market maker facilitates exchange. E.g. someone buying USD and selling Euros. Transparent to user since market maker handles this

Slide: Market makers compete on a distributed exchange

1st open decentralized currency exchange

User does not have to worry about FX

<bryan> usecase: market makers acting as transfer agent

Slide: Financial institutions act as entry/exit points on Ripple

These could be Paypal, mpesa, etc

As long as the institutions are connected to the Ripple network this is transparent to the user.

Slide: Deal only with institutions you trust

No individual integrations required; you sign up with only one service you trust

Unlike other systems where both sender/receiver to have say signed up with Visa/MC this is more interoperable

Slide: Connected without needing any prior business arrangements

Picture of 2 Ripple gateways and market makers are between them

<bryan> usecase: transfer money through gateway providers of financial networks

Market makers compete to offer the best exchange between these gateways

Does not require FIs/merchants to have individual negotiations

<bryan> usecase: knowing through which financial network your transaction will be delivered (you might care?)

Slide: Summary

Ripple connects other payment technologies, fast easy to integrate ..

Erik introducing Max (CoinAPex)

Max: Introducing Bitcoin incubator

Mac: Interesting to talk about standardization in context of decentralized community like bitcoin

Please do take over scribing :-)

Thanks dsr

<dsr> scribe: dsr

What's interesting is that there are lot of solutions in the bitcoin world which can move quickly, but are not necessarily what the regulators will want to see.

We're seeing a split in the bitcoin community with some who want to create an identity layer on top of bitcoin and others who want to avoid any kind of centralization.

<bryan> the "interesting interplay" and knowing this is a concern (or may be) is one rationale for the use case of knowing how your money is being transfered (what if an international network used bitcoin internally?)

What US banks and regulators will be able to do is still in progress and it will be interesting to see how it plays out.

Connie Theien (US Federal Reserve), I want to take us back to legacy system and the feedback we got from stakeholders.

We've identified about 11 major kinds of use cases

scribe: We've document the requirements and are looking at the gaps from what is doable now.
... We want to understand where we should be focusing our efforts -- shoring up the existing systems or supporting new kinds of systems.

We would like to make payment systems more accessible. We look at ACH as an efficient system, but we want to make it more open.

We've seen interest from some sources for a means to initiate cheque based payments electronically.

<bryan> usecase: Electronically originated checks

We're also looking at the unique needs of businesses, and their specific requirements as compared to B2C.

<bryan> usecase: knowing what info will be required to supplement a transaction

On the international side, we're looking at an ACH service that is fairly fast relative to other international payment solutions. Today this reaches 35 countries and we are looking to expand this further.

<bryan> X9 = http://x9.org/

ISO 20022 ...

<bryan> NACHA = https://www.nacha.org/

We're interested in enabling improved security, information sharing and fraud detection.

This is what we're hearing from our qualitative assessment of our consultation.

<phariramani> ISO 20022 = http://www.iso20022.org

<bryan> usecase: knowing that data minimization principles are followed by systems in a payment chain

Erik: I would like to open the floor to questions.

Manu Sporny: an observation, it is great that all of the panelists have been focusing on their individual areas.

scribe: I am seeing that there is a very large divide between what is said in public and what people will say privately.

For example in respect to bitcoin and risk of legal litigation

scribe: As far as I can see, banks don't have a motivation to switch to truly decentralized clearing solutions. Very little cross pollination with the bitcoin communities.
... It is great to see representatives from both communities sitting down together here.

Max: you are going to see caution at least from a high level. Things are happening, maybe not at the pace bitcoin folks want, but progress nonetheless.

If states start seeing tax dollars from bitcoin transactions, this will ease things forward.

Connie: I do see the dialog starting with people keen to reach out and talk. I think there is interest in learning and understanding where the future of payment systems might evolve.
... Much of our focus and effort is on how we can improve.

Jaromil: I would like to second Manu, it is readlly good to discuss the potential changes.
... games are now bigger than movies, and kids are trading their WoW goods.
... we are talking too much about fraud and not enough at the opportunities for supporting new markets.

Erik: not significant traffic as now on these alternative networks for governments to worry too much.

<cyberphone> is fixing the broken Card Not Present system in scope?

Stan: Our experience with governments has been surprisingly open. It is difficult for small startups to fly and meet people.
... We need to see greater effort on non-incumbent organizations to reach out and make their case on behalf of their communities.

Anonymity is a real concern in some areas of the world.

scribe: we need to avoid setting up conflict.

<bryan> in an environment which a variety of decentralized / "innovative" systems may be used by money transfer networks, how important is it for users to know which types of networks may be involved, and to set preferences or express consent for their money to be transferred via such networks?

Bryan: in the environment, how important is it for standards and metadata about transactions, e.g. to enable people to know whether a given solution is more likely to be subject to scrutiny.

Evan: as long as the payment solutions are trusted and secure, that's probably sufficient.

David Birch: as a consumer I am protected against fraud on credit cards. This is different from regulating money. Can you be a little clearer about consumer protection vs regulatory requirements

<jaromil> ECB paper I've mentioned https://www.ecb.europa.eu/pub/pdf/other/virtualcurrencyschemes201210en.pdf

Harish: a customer may not know, but the bank will. There needs to be a framework governing how exceptions are handled.

<bryan> the notion of trustworthiness and the current user transparency to how their money is transferred point to an issue of (a) who is asserting the trustworthiness (regulators?), and (2) the fact that users can currently rely upon a safe/reliable transfer system i.e. they have never had to worry about such things, so far.

Evan: on Ripple, all transactions are irreversible, so there is no mechanism for charge back.
... Ripple is much more like a debit system than a credit system, payments only proceed if you account has the necessary funds.

Harish: it is more about when a service needs to be refunded, e.g. on cancelling a flight.

Evan: you could have an escrow service that only transfers the funds when the service is delivered.
... The merchant would have a rock solid guarantee of receiving the funds.

Erik: we've seen stories of people paying with bitcoin on ebay and never getting a refund on non-delivery of the product. Escrow is important.

Evan: Ripple would allow card issuers to reduce their fees and it is likely that market pressure would force that.

??: will crypto currencies become important for wallet to wallet transactions?

Gray Taylor, NACS: VISA and MasterCard are profit driven. Merchants are tee'd up to go, but are concerned about volatility.

scribe: smaller payments are subject to a different risk model

<bryan> way long ago, I used Tradenable to sell a high-value guitar to a buyer in the UK, with international shipping required - a complex sale. the role of the escrow company was an essential one. speed of transaction or the lowest fees are often (if not always, to me) secondary to trust in the transaction.

Manu: I've just heard something really scary. Evan: you've just explained why MasterCard and VISA are unlikely to adopt Ripple.

<stanstalnaker> Manu - don’t forget that 50% of the interchange fee goes to the banks, so they are in the same boat as Visa/Mastercard

Manu: We're talking about standardization process that could drive fees down, and this may deter adption, unless it is forced by governments.

Max: if enough merchants switch, the market will force a transition to reduced fees. This is likely to happen in an incremental and initially small way.

If the banks become more comfortable and regulators give a nod, we can expect to see change.

<bryan> I think enabling payments on the web through APIs is orthogonal to the desire to reduce fees which I would think in user's minds is secondary to trust in the payment provider/system

Evan: I expect an inevitable decline in fees as the market evolves.

<steph> +1 to bryan

<bryan> in summary we don't have to solve the international transfer problems to enable payments on the web

Ricardo: the only thing that is likely to be regulated is the entry point to the system.

Bailey: regulation of virtual currency to virtual currency will happen when the volume is sufficiently high to take notice.

<Zakim> chaals, you wanted to say there is a market for visa/mc apart from interchange, and there are plenty of people living in wildly fluctuating currencies

Chaals: We've heard about exorbitant fees especially in less regulated markets

<bryan> and a lot of people are paying 300% for payday loans... web payments enabling similar loans could operate a much more efficient/low-cost system for the masses of people that currently depend upon payday loan services

Chaals: bitcoins might be attractive simply on the grounds of transaction cost and relative stability. Credit cards on the other hand are attractive because they offer credit.

Evan: some of those fees are due to unnecessary issues and we may be able to get rid of them.

Max: once we see a stable future's market for bitcoin, this should address volatility concerns.

David Birch: are there any ideas for merchant run payment systems?

Max: ...

Joerg: as long as the issuing banks are receiving the interchange fees, they are motivated to continue this.

<phariramani> sorry i typed too quickly

Max: if there is no intermediary then bitcoin transfers incur no fees.

Giri: can standardization realistically address the problem of bad debts for merchants of apps?

<gmandyam> Re: bad debt. Many of the speakers have focused on consumer protections, but not so much on merchant protection. There are many well-known methods where operator-direct billing can be exploited by end users to obtain electronic goods (e.g. apps). Merchants either bear the cost through worse rev-shares or eating the costs. Can standardization realistically address this problem (e.g. standardized receipts)? Will they ever achieve adoption worldwide?

Evan: I don't know how standards could dictate terms.

<gmandyam> Regardng my question , I didn't expect standards could address business terms. I was asking whether standardization (e.g. standardized receipts) could be used to address bad debt.

<wseltzer> [wseltzer notes that W3C can make recommendations, at the behest of its members' consensus]

Phobeo: if visa and mastercard removed their fees, what other reasons would merchants have for using Ripple?

Evan: we're more likely to see competition across a wide range of payment solutions. We want to see standards that make it easier for users to have a free choice.

Stan: metadata could be one answer given the opportunities for the Ripple ledger.

Evan: metadata could be attached to any transaction and made public or subject to some form of access control.
... we've been thinking of SWIFT style clearing

<bryan> "intelligent data" (or metadata) sounds to me like a double-edged sword, especially one that comes with access control / privacy implications

Max: the sky could be the limit for what could be built on top of the bitcoin technologies, but on the other hand it could be nothing (Laughter)

<bryan> +1 to avoiding all discussion of fees in a standards context

XX: Visa and MasterCard aren't here, so let's not refer to unjustified claims about fees

Evan: I was only referring to what we heard earlier.

<stanstalnaker> re fees and Visa/MC my comment on bank take - that information is public from MC

<bryan> ... except that disclosure of such fees might be useful metadata for a payment transaction, something that might drive user choice

Harish: there is a question of whose metadata is involved in transactions, there is a privacy issue here.

Evan: we're very interested in digital receipts and where these are stored.

Erik: let me close up the session! This is the first time I've seen all of these players in the room, but it is disappointing that MC and Visa aren't.

Stephane makes some closing announcements.

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/20th/25th/
Succeeded: s/hi everybody//
Succeeded: s/hi all//
Succeeded: s/?//
Succeeded: s/hehe, ok//
Succeeded: s/chaals: why? is that for auto note taking?//
Succeeded: s/glazou: close to the number of prrson in the amphi//
Succeeded: s/ invetor/inventor/
Succeeded: s/we need link for current presentation of Jeffe//
Succeeded: s/abe/able/
Succeeded: s/tomanaage/to manage/
Succeeded: s/ theinventor/ the inventor/
Succeeded: i/Date/-> http://www.w3.org/2013/10/payments/agenda Agenda
Succeeded: s/Introduction from Worldline/EU Work on Payments: DG Competition/
Succeeded: s/aqurers/acquirer's/
Succeeded: s/Considerign/Considering/
Succeeded: s/obligatin/obligation/
Succeeded: s/you can't use it in the netherlands/ you can only use it in the Netherlands/
Succeeded: s/takl/talk/
Succeeded: s/Any guidance on use case capturing for the minutes? otherwise i'll just preface notes in irc with "usecase: "//
Succeeded: s/soverignty/sovereignty/
Succeeded: s/safety-speed/safety-speed-efficiency/
Succeeded: s/Yvgeny/Evgeny/
Succeeded: s/Yvgeny/Evgeny/
Succeeded: s/Yvgeny/Evgeny/g
FAILED: s/Yvgeny/Evgeny/
Succeeded: s/benfits/benefits/
Succeeded: s/i welcome though ideas on what the higher-level use case(s) for this might be//
Succeeded: i/sounds like/[
Succeeded: s/tto/to/
Succeeded: s/tthink/think/
Succeeded: s/African/Africa/
Succeeded: s/==/!=/
Succeeded: s/look of ways of aggregating ways - maybe diaggregatingn/look at which attributes of identity are necessary where; users' interests may differ from regulators'. Focus on /
Succeeded: s/they're not/while others are/
Succeeded: s/Bryan/Stan/
Succeeded: s/why can't business entities play/how can business entities play/
FAILED: s/yyt/Alexander/
Succeeded: s/those requirements/those features/
Succeeded: s/YYT/Alexander/
Succeeded: s/AngelicoXYZ/IngenicoXYZ/g
Succeeded: s/determinination/determination/
Succeeded: s/20% of electronic transactions/20% of electronic transactions in Brazil/
Succeeded: s/role identity/role of identity/g
Succeeded: s/strutures/structures/
Succeeded: s/temporaty/temporary/
FAILED: s/temporaty/temporary/
Succeeded: s/:loyalty/: loyalty/
Succeeded: s/@@/MartinHepp/
Succeeded: s/queues/cues/
Succeeded: s/Geary/Giri/g
Succeeded: s/+q//
Succeeded: s/HTTPS was designed for payments/per PHB, HTTPS was designed for payments, i.e., to make consumers feel confident enough to make payments online./
Succeeded: s/Hi, I would like to make a comment//
Succeeded: i/Natasha: in this session/scribenick: evan_schwartz
Succeeded: s/Wendy, do I type just "q+" or like you did "q+ Ori_Eisen"? so I know//
Succeeded: s/cough Kerkhoffs/Kerckhoffs's Principle, that a cryptosystem should be secure even if all is disclosed but the key; transparency can aid security/
Succeeded: s/initiative/initiative, we need to start on small blocks/
Succeeded: s/Thats sounds good. Thanks Dave/ /
Succeeded: s/Ok chaals. Good idea//
Succeeded: s/mesa/MPESA/
Succeeded: s/mesa transactions/MPESA transactions/
Succeeded: s/mesa/mpesa/
Succeeded: s/W/We've identified about 11 major kinds of use cases/
Succeeded: s/Jeromie/Jaromil/
Succeeded: s/there is now mechanism/there is no mechanism/
Succeeded: s/YY/Gray Taylor, NACS/
Succeeded: s/ZZ/Ricardo/
Succeeded: s/??/Bailey/
Succeeded: s/of cost/of transaction cost and relative stability/
Succeeded: s/q +//
Found Scribe: m4nu
Inferring ScribeNick: m4nu
Found ScribeNick: evan_schwartz
Found Scribe: chaals
Inferring ScribeNick: chaals
Found ScribeNick: dsr
Found Scribe: dsr
Inferring ScribeNick: dsr
Found Scribe: phariramani
Inferring ScribeNick: phariramani
Found Scribe: dsr
Inferring ScribeNick: dsr
Scribes: m4nu, chaals, dsr, phariramani
ScribeNicks: m4nu, evan_schwartz, chaals, dsr, phariramani
Present: chaals Manu StephB Wonsuk Jungkee Mauro EvgenyVinogradov prakash VirginieG JeffJaffe WendySeltzer thisNatasha BryanSullivan JorgHeuer MarieClaire darobin tobie DaveBirch Bryan_Sullivan HannesTchofenig KenIsaacson OlivierMaas StanStalnaker HarishNatarajan ErikAnderson JeremyKing LarsErik davidEzell mhepp
Found Date: 24 Mar 2014
Guessing minutes URL: http://www.w3.org/2014/03/24-w3cpayment-minutes.html
People with action items: