Web Payments Interest Group Teleconference -- 28 Oct 2014

ARTS/NRF UPOS

<m4nu> dezell: There are other efforts - universal Point of Sale

<m4nu> dezell: If you had point of sale devices all of these interfaces would work - WebIDL interfaces... simply bringing it up - almost got richard to present on this, he couldn't make it. Just pointing out there are multiple things on here that feel like a WebApp.

<m4nu> dezell: printer methods UML diagram, print bitmap, print bar code, this has been in production for a long time, we could change this to be a bluetooth printer, etc.

<m4nu> dezell: EPAS - electronic payment applications software - european focus, ISO 20022 - those ISO messages don't make a payment application. If you implement 3 specs, you have a payment application,

<m4nu> dezell: terminal management, retailer application, acquirer protocol - these are the things that we may want to look at.

EMVCo

<m4nu> dezell: it's important for us to talk about this 400lb gorilla in the room - EMVco tokenization spec is at the basis of apple pay (that's the rumor)

<m4nu> dezell: You can download spec, readable - internally they use ISO 8583 - token is built from that stuff... it's binary.

<m4nu> dezell: Ecosystem is token service provider, acquirer, merchant, etc. token requestor is a placeholder - anyone can request a token. The soul of trusting this - refresh early/often.

<m4nu> dezell: If you have an old token, someone steals it, get a new token. Requirements for token service provider - API guidelines - extremely vague - we could define RESTful services to EMVco.

<Karen> Manu: Are you suggesting…it would be neat to get Apple Pay involved

<Karen> …is the EMVCo the mechanism?

<Karen> David: No, I'm just bringing it to our attention

<Karen> …it's more likely to get them moving in our direction if we are not going against them; not advocating, just stating fact

<Karen> Scribenick: Karen

Speaker: Jorg Heuer, Deutsche Telekom

Jorg: I am part of Telekom laboratories

…not productized

…to address an eceosystem which a wallet should perhaps do, we have to have in mind...

…Given chance to occupy two days with what I have to tell

…Like to convey as much as I can

…today so that on second day you can tell me how to best contribute and continue on this topic

…the overview

…I have been using this overview for some time

…consists of people like Google who have been working on wallets

…all costs a lot of money

scribe: Gemalto has made money, but it's hard to do

…One of reasons

…best described if you look at the newest entrant, Apple, with Apple Pay

…So few that have a vertical power to know the user, have access, provide the software and all the backend services

…This is what you have to have if you want to engage with al the partners

…All the others in the end were lacking access to the right part of the value chain

…Also true for DK to some extent; Google has started working on infrastructure

…but they have not yet blasted through the infrastructure as some expected

…Really tough [to do]

…it is an ecosystem

…if all the others are going to be part of something that works in the end, they need to accept their roles

…We have worked on that in our work

…my wallpaper for all the stuff we did, starting in 2006

…NFC, UFC stuff

…our R&D unit worked on it

…In 2007 we came across Info-Cards; identity management solutions

…idea was to turn identities into virtual cards

…my team is actually a team of identity experts

…we did not expect to work on payment

…I will love this topic which is challenging and complex

…Recognized we needed to join these two worlds; identity and payment

…you are showing the entitlement, authorization

…we developed run types, more complex things; aspects of the ecosystem

…Demonstrations by DK were based on technology we had developed

…To show the most important parts

…All the things we had imagined and showed the most important parts

…They came to us with parts from Continental, who had mastered NFC

…show mastery of electronic keys

…We integrated this into our framework

…So we have been working on that until 2013 on basis of an Android native code developed over years

…then looked at how to go further

…and build a wallet with HTML5

…and this is what I want to tell you about

…Story starts with a simple idea about how to structure things

Jorg: Take this info card as the trusted idea

…take credentials; we could build everything around it

…And we were able to create a title engine, a UI and engine worked with metadata

…We had no assumption about how functionality of card was implemented

…We needed to be open

…did not know what sits in the secure element

…but make sure the implementation accesses the secure element

…We know there is a Visa, MC, coupon application

…and we hook them up into our framework

…and have them handle things described in our metadata

….We used HTML5

…wanted to run on every platform

…more or less I have two devices for the demo later on

…Next step

…for us is to define the vision

…what they are doing

…"A tool for users where all types of credentials are stored; with appropriate security; for use in all kinds of personal digital transactions; in a vivid ecosystem - always under the control of the user on his trustable device/service."

…Microsoft started but did not continue

…We wanted to make hardware secure instruments for the end user

…it is already sitting there

…give you maximum control of entitlements, security control, etec.

….make it easy for people to have hundreds of identities

…get a new user card for each new mail box for example

…Since we do have ideas about understanding context for where wallet is used

…we could help and present the few identities that make sense

…We see the development in the identity space where silos are at it again

…we have lots of silos

…Today we see that browsers want to become identity management tools

…I as user have a problem when I want to change my browser; where are all these identities stored?

…possibly be a different tool

…and also take into account when running different devices

…Also, something that relates to next point, we did not to have the silos defined by your mobile operator or bank

…Whatever you do, not be confined o what end user accepts as a wallet

…I tell them your customers are also customers of others

…the wallet needs to be neutral

…That led us to a different model

…with respect to the roles

…We have a bit of a differentiator

…in which we say there is a role for a wallet provider

…someone who runs a wallet service

…could be a service

…you had that in your presentation; could be synchroniized

…Another one might not be open

…All things that are up to the ecosystem if we are talking about global standards

…I really like term Manu put out for a while

…a level playing field for others for innovation

…We could not do everything ourselves

…Access keys for house, card, hotel doors

…perhaps with loyalty cards; no way for us to cover all of that

…That was hard in our company to say we cannot be the ones to offer all these services, but rather to offer the platform

…We sit on the secure element, or could be a wallet operator

…Many places like SIOS in US, say we need to have one wallet

…One wallet operating

…would make onboarding easier

…So we learned we can achieve much more than we ever expected

…Some people wanted us to implemetn

…We did it in HTML5

S/ISO

scribe: whatever these items are

…that will come from outside

…We recognized that by building this stuff, we had to adopt to every single interface on the OS level; to interact with all the browsers

…see lots of interfaces all different with all different combinations of platforms

…Thought we could share our vision with W3C

…i think the future holds a lot of potential for this kind of things

…In payment, our goal was convergence

…We called it a converged wallet

…We wanted you to have same experience at cash register as the online shop

…We built an NFC based shopping scenario with a PC

…with a plug-in in browser

…and we authenticated

…I would hold my mobile phone against the NFC reader to authenticate

…used it as the trusted instrument

…easier to shop

…this is identical to me paying at the cash registere

…Leads us to the e-commerce field

…Consultancy people approaching us

…asking isn't that what we have been doing for years?

scribe: Good prospect in e-commerce field

…Everything like loyalty, profiling, couponing would be integrated in same approach

…Can show with a small demo how that can be done

…Media is another thing with lots of problems

…in the home nobody knows who is allowed to do what

…To sue content

…that is limited; are you allowed to order something from your smart TV

…lots of personalization you cannot do; have to administer it with every device

…these things could be done simpler

…Also have been approached by DRM people; like music services

…I could have my entitlement with me and use on any device

…Topics of smart cities

…are pretty frightening

…They have started with EU Smart Cities program

…how can we control all the devices around me

…could be good way with my identity and authonomy

…Think we can help the whole thing to become user-centric; the whole idea behind the wallet

…Things flow through this device

…Wallet is also place where I do automation

…Opt-in and opt-out is one problem space

…When you want a confirmation from user

…pop up your wallet; an expression of will; to pick this one part for this transaction

…not opt-in or opt-out; but I picked this card for this transaction

…Also want to avoid storing my payment crednetial

…Id' rather have a world with credentials not stroed outside

…Ideas around centricity

…Lots of arguments; transparency, user control; convenience factor

…reference to Doc @

…He invented VRM (Vendor Relationship Management)

…complementary to customer relationship management

<wseltzer> http://cyber.law.harvard.edu/projectvrm/Main_Page Project VRM

…If you have tokens from vendors

…and you keep them because you think it will be important to get back to that same shop, you might have that same information

…not up to vendor, but you keep data about the transaction on your file

…Every vendor wants to be remembered after years

s/Doc Searls

…Privacy

…use of pseudonyms is eased

…also working with a prof in Frankfurt

…wallet might provide certain modules

…issue these rules

…and be untrackable

…also requires audits

…could be a good thing in the framework

…there is a need

…That is the idea here

…Open ecosystem for all the other players is a bit rough

…Could gain cost efficiencies by using web-based technologies

…We learned that in the mobile industry

…allow connections

…between issuing bank and @

…costs are high

…Germany has a lot of banks

…to be relevant with your wallet you need to have them all on board

…$500K per bank is not a model

…Once you have an agent in secure enviroment

…you could provide everything else

…even based on global platform standards

…Cards could allow that but not in practice today

…Legacy support

…I will show you things with optical systems

…show that these fit together

…technology agnostic makes it fit for innovation

…and fit into processes and things we already have

…Cannot just reinvent payment and expect everyobody to go for it

…and important to provide sercure element serviceces

s/services

…make payment possible

…cut it differently

…we are responsible for secure element; rest is up to others

…So let's look at more practical

…How to fit that into one wallet

…what we did is to create one monolythic application

…had some work done on the device itself

…applications on the same device

…talking to web browser was needed

…to pick your identity in the wallet and convey to a service on the Internet

…something really important

…if you have a merchant that you regularly go io,, they usually have an app

…all these things exist already

…One thing in wallet

…you want to have one place to do your transaction

…coupons in one app, payments in another app, that is not feasible

…If we can be part of that wallet experience that would help us

…Structuring it

…we needed to handle those items in the wallet and make modules available

…Complex picture

…but that contains everything in terms of the big blocks

Manu: one comment on the general diagram

…one of things I was concerned about is use of the term "wallet"

…it means something different to each of us

…looking at this slide, I see a payment ecosystem, not neces a wallet

…Good for outreach, but wallets are composed by a large set of pieces

…each needs its own spec

…In showing people the demo

…do you think there is a misconception about wallet, or do people get it's an ecosystem that is being described

Jorg: this is our software architecture; you seee an ecosystem which is what it is meant to do

…i hate the word wallet because of all the misunderstandings

…This is the wallet in the view of an end user

…Not aspiration of some service to be a wallet provider

…Say this thing is open to call your cards, tickets, coupons you want to collect

…Good to hear you say ecosystem, but it's an architecgture

scribe: If we dare influence people's perception of wallet

David: perhaps we put the bus model and software architectures at different levels

…I have hinted to that in the back end section

…These things would be vertical implementations

…and they would connect to @

…on wallet level we don't need to know so much about it

…the users, browsers pick some elements

…may be a question of communciations channels; optical or NFC, context

Manu: those details we have to figure out

Jorg: Right

…It's a lot

…When I tried to put these slides together for people who were not familiar

…I was concerned they would not understand

…But all these interpretations fit in there

…A simpler one to show

…a platform on which all these items sit

…using hardware, software

…or nothing at all

…made available

…all issued

…from your issuers, your services into your wallet

Mountie: We have to think about the

…same-origin policy of the web

…this design was discussed in Web Crypto WG

…problem was…some origins

…need to overcome

…issues with the same-origin policy for secure element

Jorg: I hope so

…you can bet on that, in our company it was not easy to convey notion that secure element could be some secure element

…people were proud of SIM card

…one example was security arm

…customers who need secure elements with certificaitons

Stephane: Question on this

<wseltzer> scribenick: wseltzer

steph: question for tomorrow, where are the points where standards are needed
... vs the places we need flexibility for innovation?

Jorg: [slide: Using t-labs wallet as a straw man, what are the interfaces, protocols, data formats?]
... lots of things in connecting to the back-end
... thought about beefing up the administration interface
... I don't want a backend service that looks entirely different depedning on the client
... I should be able to configure which instruments to sync with which devices
... tell the bank "your customer has a new device, wants to have his card on it" that could be automated
... lots of things out of our scope, coudl be useful in the ecosystem

[slide: references]

Jorg: That's the end of my hour; I hope it's useful for discussion tomorrow
... A wallet isn't everything for payments, but I think it's a piece W3C could contribute

manu: what's next?

Jorg: I want to give the use cases of the wallet, with requirements based on web technology

steph: Are people happy to discuss wallet interfaces, not internals of wallet?

dezell: Let's not take that vote today while we're tired, but wake up tomorrow ready to discuss

dsr: Let's talk use cases and ecosystem, interfaces will follow

Jorg: we created a solution around our ideas, not a product
... I expect there's space for dozens or hundreds of wallets meeting those specs
... I'm not advocating the solution, but user-centric approach to a wallet model

patA: apprach gives a good context to look at the ecosystem

Jorg: Wallet provider shouldn't be capitalizing on information
... this business is based on trust
... let me show you one story

dezell: Let's close the meeting, and people who want to see the demo can see it
... first thing tomorrow, we resume this discussion
... then AC meeting interrupts, and we reconvene to figure out ongoing activities and way forward
... Afternoon is very important

manu: also, identity and credentials CG during AC break

dezell: if you're not in AC meeting, that's a good place to be

[adjourned]

<inserted> scribenick: padler

<trackbot> Date: 28 October 2014

<toml> test

<inserted> topic of the morning - Joerg Heuer - continuation of Wallet discussion/scribenick: padler

<inserted> scribenick: padler

Continuation of Wallet discussion

First presetation/topic of the morning - Joerg Heuer - continuation of Wallet discussion from 10/27

just covering administrivia before getting started..

discussion on where we are publishing minutes/content from meeting...

questions coming from the CG asking for visibility into what was discussed yesterday...

Added information to slide deck on Doc Searles VRM (vendor relationship management) topic

thanks to all for attending demo last night... willing to do another demo today on break..

this part of the topic is more 'freestyle' - looking for input from others on topics/concepts that were discussed last evening

as well as discussing proposal and any use cases..

thanks.. will add...

joerg: recapping key points/from yesterday...
... discussion power of the wallet paradigm to enable horizontal integration across many industries/providers...
... meta-data in the wallet is key to being able to implement many different use-cases

question on what dependencies the wallet concept has to underlying platform.. for example, is the wallet concept dependant on mobile app?

(did not catch speakers name).. .

claudia: question on specific technologies used in implementing the wallet concept..

joerg: talking about the flexibility of the framework to choose distinct technologies based on different scenarios
... showing QR code to show linkages between devices...

browsers display QR code and then leveraging mobile device to do out of band authentication...

joerg: serves as a good example for where these types of modules could "plug-in" to the wallet framework
... black box wallet needs to talk to the browser..

Matt/ joerg: discusssion on where the authentication credential "lives"... wallet implementation is not tied to any one device...

joerg: wallet can live either on device or on in cloud or others..
... many different implementations even for a plastic card..
... use context to be able to decide which implementation "item" to use..

matt: merchant perspective is worried more about details of the issuer of the payment device..
... how do we make this more future looking... than just looking at how this works in today's context..

pat/matt/joerg: discussion on merchant preferences for how to route transactions...

matt/pat/joerg: how does the merchant context work? joerg: discussion on how debit schemes may work for POS terminal providers..

matt/joerg: discussion on POS terminals and standards...

dave m: how many issuing banks in Germany?

joerg: there are many

Dave E: discussion on full stack providing too much detail..

TIMEOUT... potential gas leak in building..

padler: back from Gas Leak - everyone is safe

dave e: sharing context about ad-hoc discussions on break and asking to refocus the group on use-cases - is there a way to talk about the API's and interfaces used in the concepts being discussed?

Erik: take concept of the wallet and decompose it into specific components and line them up against use cases... figure out what are the key pieces...

dave: we have till around 10:35 to discuss and then need to decide what is next before Advisory Committee breakout...

joerg: showing slide on core aspects of "wallet"

<manu> padler: if you take that picture - it's very consumer focused.

<manu> padler: I thnk your idea about the portable framework makes a lot of sense

thanks for covering the notes!

<manu> padler: this seems like it's all the same sort of stuff... can be applied in a variety of scenarios

<manu> scribenick: manu

joerg: The whole thing could be fit to the situation well...

<padler> dave e: need a design that does not hit on any specific hardware...

david: The API that we show can't be dependent on specific hardware.

<scribe> scribenick: padler

that'd be great!

<manu> scribenick: manu

erik: Let's say that I have a loyalty card - that may not have any sort of integration w/ wallet.
... This might be some UI information that's output that becomes part of the wallet.
... If I could break down what a wallet is - it's a general purpose container for an item.
... The loyalty card, the bitcoin wallet, etc.

<padler> manu: here's the concerns about the wallet... experiences with wallet is that it means many things to many people...

<Zakim> manu, you wanted to talk about "What is a wallet?" question.

<padler> can hold many things..

<padler> manu: it's too broad... need to pick something that's more narrrow in scope...

<padler> manu: need to focus on the 3 key features that will make us successful in our first iteration..

<padler> manu: don't want' to rush it.. but we need to get the right focus quickly...

joerg: we want the user to be in control of the technology
... The field is very wide - very wide field of applications
... Focusing on wallet would ease the way we approach this.
... This is something, from an implementation point of view, we can show today.
... This could help us to deliver something that people can use

claudia: Going back to charter for the group - what are thewe're trying to solve
... I thought we were trying to focus on key problems - what are the use cases
... Then go to - what do we need to focus on.
... This seemed like a bit cart before the horse

david: We knew this was a deep dive - brings to the surface opinions and way to think about things.
... If we only talked about abstract use cases - we wouldn't hear about certain t hings.
... The end result we could come to is that we should have a task force looking at this issue.
... We may want to divide and conquer this huge task.

mountie: comment about the wallet - if we tried to implement this as a standard, we have to make secure element as base - wallet API should be a connection.
... Maybe we can add FIDO or U2F for authentication
... W/o the secure element - hardware based, strong storage - the wallet can be locked into browsers that cause different types of use experience.

joerg: as a MNO, I don't have an objection, but we should propose choices.
... We need to take into account - costs for SE element usage may not be appropriate.
... Low value things - crypto in memory, etc. I think SE needs to be a part of it,
... I would propose it as a use case to work on. Why not talk about convergent payment.

erik: Let's look at this from a business point of view.

joerg: Aware of taking this from implementation perspective.
... reasoning behind this, we need to discuss here.

virginie: I wanted to react to secure element - happy w/ what you said - there is a fragmentation of SE solutions.
... We have to be abstract about it.

mountie: There are many other groups touching SE

joerg: We've been talking about MasterPass - onlinen card present mechanism.
... That could be one of the cornerstones to think about, we could easily integrate.
... Make use of virtual mastercard, same card that you use on register w/ NFC.

<tom> manu, let me know if i should take over

<scribe> scribenick: tom

stephane: strong focus on user side of thins, lower focus on merchant side, interoperability, etc

<manu> stephane: We have a huge focus on user side - less focus on merchant side. I want to be sure - hear from people on the other side - merchant side.

stephane: what do people think about importance of other things

joerg showing slide 23 again

ticketing a very complex issue, could hardly be integrated into the model

joerg: would like to stay out of the complex processes around e.g. ticketing

stephane: easier to focus only on payment aspects for a start
... being agnostic of business level as far as possible

matt: merchant id is needed for certain use cases

<Zakim> manu, you wanted to talk about business requrements

correct: gray not matt

manu: what is the key business need we try to meet?
... user experience on the web is completely different on the web, depending on the payment instrument used
... once customer hits "pay button" only the user preferred payment instrument should be shown
... merchant should ideally not have to implement all payment instruments individually
... key app would simplify it for both sides of the paymens market: customer and retailer

gray: credentialing is key

manu: push based payment, not a pull based payment

gray: then credentialing becomes consumer problem

manu: push based payments first

joerg: probably we have to think about a payment user agent

manu: requirement on the technology
... merchant can express which type of payments he can accept

joerg summarizes: push payment (merchant), select applicable instrument (consumer), receipt

david: part of the business discussion

manu: describes push vs pull payment
... push - consumer initiates the payment
... pull - merchant initiates the payment

matt: requests further explanation

manu: key thing - reducing pain of making a payment over the web
... could theoretically also applied for in-store payment
... negotiation between merchant and user if different payment instruments are in the wallet

payment instrument = pi

claudia: in the current environment merchants try to register customers
... often combined with customers' payment information
... if i can pre-register my preference with a retailer, payment process is very easy
... difficult if i would like to shop in different shops

matt: this is what amazon, paypal et al try to solve

manu: two sides - merchant and consumer

joerg: pre-reg of customers should be avoided
... intermediation by third parties should/could be avoided

<glenwiley> i'd like to be one the queu as well

joerg: data breach issues could be solved, if merchants do not have sensitive data
... wallet could 'learn' customer preferences over time
... that
... that would be the idea

gray: untokenized payment data on the network, issue
... tokenization could solve a lot of problems and increase security

stephane: push payment, multiple aspects
... trust and security are key
... user experience can be standardized for push payments
... 3dsecure has problematic user experience

andy: mechanism empowers user
... merchants get a minimum set of data, no possibility to necessarily trace the consumer
... privacy aspect is compelling

pat: differentiation between shopping as private person and shopping for organization would be possible

brian: becomes a negotiated business value exchange, works for variety of problems

gray: age verification another possibility

<Zakim> ShaneM, you wanted to speak for the smaller vendor

<Zakim> dezell, you wanted to say it's not just "on the web"

glen: article of the fbi of hundred of million of compromised accounts over the past year
... update of all details at different merchants is very painful for customer

shane: the huge retailers are important, but small merchants would not necessarily want to loose their brand by using amazon payment
... the same holds true for mc and visa

david: captured a few things
... would like to refocus discussion a bit
... business discussion should be held in this group
... higher level discussion needed, to capture main points
... task force is substructure of an interest group
... ig does not create standards
... wg writes standards
... if there were a tf to discuss the framework of apis, possible user experience and that people can innovate insied

erik: keep high level business requirements discussion going
... 1. business, 2. business cases, and finally go into technical details

mountie: not focus only on the client side of the wallet, but also on the server side

<manu> mountie: We tried to generate digital receipts on the client side and failed, we should consider how these digital receipts are signed.

pat: agrees with erik to focus on the top level business casses first

<manu> mountie: Perhaps the payment processor or the cloud device should digitally sign the receipt.

pat: contextual framework (location, time, legal jurisdiction) have impact on the technical side too

dan: newer forms of payment
... things like bitcoins, blockchains, etc

pat: you still need wallet providers
... key abstraction point, how to specify the context
... protocols comes in here

dan: agrees

manu: tf might be premature
... helps getting everyone on the same page
... better to have some conf calls first

steph: agrees with manu
... we have to be sure that we do not put everything into the wallet
... push payment is not necessarily a wallet discussion
... wallet tf soon, but not put everything into the wallet tf
... wallet can help to bring user into the (complex) payment process

correct steph <> joerg

steph: david thanks for lively discussion

david: thanks for lively discussion.
... reconvene at 3pm and continue discussion

<siddharthb> HI - can you add Siddharth Bajaj (Opera) to the attendee list for 27th

<siddharthb> I am attending remotely this morning and will try and attend in person this afternoon

<steph> sure Siddarthb

<ShaneM> ScribeNick: ShaneM

Payment Agent (formally Wallet)

David: Reintroduced topics: Payment Agent (formally Wallet)
... two types. Traditional model and the idea of "push payment". If we can capture what we think are the pros and cons of each; where the weak spots are in traditional and in push we will have a better understand and might help us decide how to proceed.
... alternately, continue the discussion from before and attempt to call out more use cases.
... some use cases are from web browsers. some happen only on a phone.

manu: there were already some use cases from the web payment cg. we could at least look at the titles.

dezell: any objections? timebox it. 15 minutes.

stefb: we should probably identify some sources of other documents.

dezell: Claudia should get the titles from 12 8 12

<stefb> ACTION: Claudia to investigate use-cases document from iso 12812 [recorded in http://www.w3.org/2014/10/28-wpay-minutes.html#action01]

<trackbot> Error finding 'Claudia'. You can review and register nicknames at <http://www.w3.org/Payments/IG/track/users>.

<manu> Web Payments CG use cases: https://web-payments.org/specs/source/use-cases/

(group reviewed WCG use case titles - manu presented)

"purchase request"

dezell: is purchase request from the point of view of a consumer?

manu: think of it as an invoice. merchant generates an invoice and sends it to the consumers payment processor

6.2 payment link

manu: like a 'payto:' scheme URL

6.3 payment processor choice

manu: consumer should be able to pick whatever payment processor they want. any given processor might be able to handle many payment methods (paypal, bitcoin, Amex).

dezell: how does a payment processor integrate with the concept of a payment agent?

manu: a payment processor is like a bank or a paypal. its some service someone is providing that implements the specifications we are talking about.
... could be a combined payment gateway and also a credit issuer

Claudia: any organization that supported the specifications could be considered a payment processor?

manu: yes.

Claudia: Today a merchant selects a processor. The user rarely has this.

manu: yes. but in push based payments it almost becomes meaningful.

Claudia: But it might matter to a merchant in that some processors would cost more than others.

manu: yes but the merchant can limit the types of payments and even the processors that they will work with when they push the invoice?

joe_h: this feels like dangerous wording.

What about "payment scheme"?

6.4 Parametric Offers

manu: machine readable offer for a time limited sale of an item.
... designed to help search engines find offers of sale.

dezell: is the 'parametric' in this limited to the way the payment can be made?

manu: your payment agent knows. The merchant says "here are the payment methods that I accept and the discounts I will offer for each"

matt: but how do I know what offers to make?

ShaneM: You make all the offers all the time.

patrick: Is there a similar intelligent agent on the merchant side?

dezell: I feel like this is a topic for future discussion.

Claudia: Yeah, this is a big deal.

Gray: I think that this is a worthwhile.

6.8 Choosing the Attributes of Price

dezell: the index that is used for currency exchange is sort of up to the bank

joe_h: some banks and cards might tell you about their fees and rates, and some do not.

dezell: it would be okay as an IG to say "your bank should be telling you this. If they are not then you might want to find a new bank."

Matt: But the settlement of a transaction doesn't happen statically

patrick: Ripple sort of does this today

Claudia: Ripple is not used today. We should be realistic.

manu: the other place this becomes interesting is if we want to do parametric offers.... a bakery might have a contract with the local grocery stores. I will tie my prices to certain indexes.

Gray: (lots of information about how indexes and settlement work). If there are things that will really help effect payment, the merchant could tell us.
... you are obligated to present multiple currencies in offers in Europe.

6.9 App-Store Purchases

manu: whatever payment mechanism we create should work everywhere - even a captive app-store

6.10 In-App Purchases

manu: in a game should work the same way, even with an in-app payment. It needs to work WITHIN the game.

6.11 Payment Tokenization

if someone breaks into a merchant and steals the tokens, then no harm should come to the consumer.

Is this a design requirement?

6.12 Registration-less purchases

You should not have to create an account in order to purchase something. When you buy something it should just work. You should not have to retype all your information.

manu: there is something called 'request auto-complete' that can fill in forms. but that mechanism keeps your data in the browser (and maybe elsewhere).

Claudia: We don't want to have all that information stored in the browser?

Can we use the secure element to store that sort of information?

manu: yes. But what if you don't have it or there isn't a way to do it?
... this is more like what is the best way to do a registration-less purchase?

joe_h: What about purchasing a song? Amazon sends me a song and they get my $0.99.

But they may need to know where you are for copyright issues.

<manu> ShaneM: Speaking for small merchants - it's good data, even if we have preferences.

<manu> ShaneM: confirmation/transaction ID to say payment was made is good.

joe_h: even smaller merchants want the purchase more than they want your data.

DRaggett: Are there use cases where you need to provide a credential to back up some requirement (like you live in a specific place)?

manu: there is a use case in the credentials group to help with this.

DRaggett: But what if they need actual proof?

manu: a credential is a digitally signed piece of information. So consider a government issued credential that certifies your age and address.
... An additional usecase: escrow and cancellation? They are not on the list. They should be. It comes up at the UN a lot.

Claudia: Returns and credits are a mess on the network right now. should that be a separate use case?

manu: yes!

6.15 Non-interactive purchases

manu: example of a micro-payment model with some sort of upper limit.

Should there be a way for things to purchase things on your behalf?

manu: yes. IoT. Your fridge should be able to order groceries on your behalf.

Meta-question: Are we trying to capture all the use cases in the world?

manu: I don't know what the IG is trying to do. The CG did not try to do that.

dezell: We are reviewing the CG work. We will put them on the Wiki, but we need to add to them. We will also point to the X9 use cases. And we will have our own.
... We might need to capture business processes to back up the use cases. Some standards have done this already so there is a basis for the work.

possible some use cases will violate patents or processes. Those might belong to non-W3C members. We will need to be careful of that.

The requirements we have reviewed so far do not address consumer to consumer, government, nor business to business requirements. We might need to address those.

manu: these requirements came out of the web payments workshop in March. once the CG looked at it we saw that the one use case about app-store got split into other requirements.

The in-app purchases are something that are too big for this group to address.

dezell: I imagine once this gets into the wiki we will start marking the as basic use cases, things that are too difficult, etc. Can be edited of course.

joe_h: How would these requirements map into the user payment agent concepts? There should be a way to associate these requirements with the work that has been done.

dezell: It seems like you are volunteering, Joe!
... end up with a wiki that has business processes, linked to use cases, catregorized as things we need to do right now vs things in the future or never. also link them with the work that has been done with payment agents and how the requirements can be supported by that technology.

stefb: where are all of the business processes and requirements coming from?

dezell: I am preparing to filter them based upon this discussion as I build the Wiki.

draggett: Need areas where we find gaps and look for people to fill them.

patrick: What about taking an approach like looking at requirements for government-initiated payments, consumer-initiated, business-initiated?

Payor and Payee are typical categories. but there are classes of payor and payee.

dezell: to we attempt to encompass all the actors?
... what does 12812 emcompass?

Claudia: P2P and P2B where B is both business and government.

Actors are individuals, business, or government. Regulator is a subset of business or government.

<manu> scribenick: manu

thomas: This is a simple metric - this graph on screen.
... it shows the cross-cutting of B2B, P2P, B2P, P2B, etc.

???: Should we consider AML / KYC

ShaneM: Are we talking about money transfer? Transfer of money from one person to another.

???: I just want to send my money to someone.

thomas: That's a person-to-person payment, moneygram.

???: We need to pay attention to money laundering.

claudia: When you go up to choice of payment processor - that's when the payee decides, we assume laws/regs apply - we don't need to create something here. All laws apply.

???: That could be provided by another area.

pat: interesting that this works w/ the model provided.

<ShaneM> scribenick: ShaneM

6.16 Payment Agent Database Portability

manu: you should be able to easily migrate your data from one provider to another. all your receipts, credentials, etc.
... there is a technical solution that is already 80% done

joe_h: what about the legal implications of transferring a credit card number etc? You need to have the provisions, but in many cases there will be the start of a process.

manu: we wanted it to me almost automatic. Compare this to porting a cell phone number from one provider to another.
... red flag. It must be hard to protect the information.

joe_h: it is a process issue. and there may be costs associated. And it is not just technical. There are liabilities - or potential liabilities.
... I don't think it should be in version 1.
... in principle you need to be able to change your service.

eric: you might not be migrating a 'card'. you might be using an instance of a 'card' on a secure element. and if you want to migrate to another you get another instance of a 'card'.

joe_h: it would depend on the technology in use. you need to be able to work with existing payment terminals.

dezell: apple pay's concept seems to be that a token service provider can reprovision your payment agent. This requirement seems to be about decentralizing the token service provider.

6.17 real-time regulatory reporting

manu: ensure there are hooks in case regulators have rules. high level concept. design requirement?

dezell: this sounds like some existing regulations where people are required to record every transaction so they can expose them to regulators on demand

Gray: The IRS is looking for 1099 information on settlement accounts.

Dan: Is this related to credit bureau stuff?

manu: We were not thinking of that at the time. It might be an important area though.

???: can we remove this requirement?

eric: Actually there are lot of regulatory bodies that are asking for this.

???: It seems too burdensome

eric: Maybe it could be batched instead of real-time

6.18 Digital Receipts

manu: if we are doing push payments, then we need proof that you paid. It is something the payment processor gives you so that you can hand it over to the merchant to prove you paid.

joe_h: there are at least 3 different uses. 1) transparency. 2) the merchant wants the transaction list in a form that is acceptable. 3) legal support for liability.
... legally binding receipt will be hard to implement.

David: It seems that some of these things are design criteria vs. actual use cases.

manu: they could be badly categorized.

dezell: we will ferret out the differences between use cases and design criteria

Gray: missing requirement: pre-authorization, post-pay

<manu> ShaneM: You describe a digital receipt as holding metadata from vendor/home depot. You also said payment receipt came from the payment agent.

<manu> dezell: We have various models in the payment area - pin-based, ..., semi-integrated - higher level than integrated - pay $23 dollars. Tells device every product that is sold.

<manu> dezell: if cc network uses that information, we're crossed the line into semi-integrated land.

<manu> dezell: in my mind, I've been keeping everything in "fully-integrated" mode... It doesn't know about anything except for payment

<manu> dezell: Suddenly the system knows about everything that goes into the transaction. In my mind, there is a definite line in there - we need to figure out how to do this.

<manu> gray: It's a slippery slope - SNAP and WIC... public assistance is difficult.

<manu> dezell: Do we include public assistance.

<manu> shaneM: My digital wallet includes my snap benefits wallet - when I go to Target, everything that can be paid by SNAP goes to my snap card, the rest of it goes to debit.

<manu> dezell: This is correct - there is also a certain absurdity to it.

<manu> joerg: I was showing use of protocol covered by GSMA... loyalty card and coupons - all of this is tranferred in one go.

<manu> joerg: Functionality of payment processor and card is over one channel. We are aware of that, we have talked w/ several manufacturers - the receipts better be constructed by a different instance.

<manu> joerg: brainstorming/concepts led to - we need to get some kind of key/URL back to wallet... we can pull information from some source. If it comes over NFC id' be very surprised.

<manu> joerg: Maybe you just need wifi access to get receipt - totally different thing. it converges in this payment. Very likely to not be solved using same means as other payment activities.

<manu> dave: When I pay via hotel, I get two pieces of paper - receipt of purchase, and invoice.

<manu> evert: Do we have that in the standard - line items in payment method, should we then further refine roles - we don't have payee, we have whole chain of services needed to complete payment. It blows up our scope.

<manu> matt: There is a huge fight over data right now, given Google's entry into the market with Google Wallet.

<manu> matt: If you require me to send SKU level information, I'm not going to do it - I'm not going to share it w/ a third party... I'm not going to do it.

<manu> matt: I'm not going to share the fact that it's a hammer back...

<manu> matt: If you have certain transactions - red hammer, in Google Wallet app, google shopping express has ability to, in that transaction, get 5% off from Target.

<scribe> scribenick: ShaneM

dezell: it is important that we capture this. the meta data about the purchase should be able to NOT be sent to the payment agent.
... there is always a risk that it could be poached in some way. And that would be very very bad.

AndyF: push style payments might need to be done using reference information about the transaction.

<manu> ShaneM: Isn't that how it works now?

<manu> ShaneM: When I go to Walmart and buy something - when I use my Amex number, that reference number is on the receipt.

AndyF: does existing equipment support this when the payment request is sent to a payment system now?

<manu> ShaneM: I'm not worried about that, that should continue to work in the model we've been talking about all day.

gray: the consumer expects an itemized receipt. cant file an expense report about it.
... we don't need to send that information to the payor. it isn't important to the payor. I don't know how to firewall that.
... payors do not get that information today.
... the reference number is the identifier everyone can use

Matt: why can't the merchant just issue the digital receipt?

dezell: no reason they cannot. the concern about the poaching is a real issue.

gray: this is a privacy issue around payments in general. only on a need to know basis are transaction details exposed.

pat: why not encrypt the data using the merchant's key?
... there are lots of ways to do this to wrapping the information up.

<wseltzer> +1 to encrypted tunnels

pat: it could route through the payment processor's network. but it is encrypted so I don't lose it.

<Erik> q

joe_h: 3 things: we built a demo a while ago. there were ways of dealing with these concerns.

<wseltzer> Gray: Preauth folios

joe_h: there is a german service that sends you an email receipt once you have done shopping. some chains have subscribed to this service.
... one reason is to capture your email.
... gaining some traction in Germany.
... if there is a digital transaction consumers will expect a digital receipt.

The receipt can be decoupled from the payment from a technical point of view. But from the consumer's perspective a receipt is part of the transaction.

dezell: We have not discussed on-line vs off-line payments.
... in an EMV card there is a chip. The chip can be updated by the card issuer.

Claudia: there is a section on Mobile Remote Credit Transfer. This is essentially a "push" payment.
... there may be detail in it that will be helpful when doing the Wiki

section 6.2.2

<dan> is there a link to the document being displayed?

draggett: for dispute resolution, what are the requirements?

Claudia: there are sections in the document about what should happen when things go wrong?

dezell: How can the W3C get access to this kind of document to use as reference?

Claudia: Set up a call with Steve Stevens (executive director of X9).

<scribe> ACTION: dezell to have Claudia set up a call with Steve Stevens about X9 document access. [recorded in http://www.w3.org/2014/10/28-wpay-minutes.html#action02]

<trackbot> Error finding 'dezell'. You can review and register nicknames at <http://www.w3.org/Payments/IG/track/users>.

dezell: we would treat it like a member confidential document if we needed to.

david: I think there is a difference between a "payment" and a "transaction". Not sure where the group is.

dezell: the intent of getting the use cases up is to indicate what is in scope or not

erik: more on receipts. bitpays and other technologies out there. rootkeys and derived keys. encrypting the receipts using your root key or your derived keys. you can then get your transactions for all of time.
... very secure. and will be accessible forever. if a given receipt is compromised it only compromises the one derived key.

matt: pull payments are a near-real time confirmation of good funds. what is the expectation for push payments?

manu: the same

dezell: some aspects might take a little longer, but other aspects will take less time.

Matt: do the brands have any ways to do "push" payments now?

Claudia: fedwire is push. ach supports both. debit and credit are only pull right now.

Matt: so are we expecting the whole industry to change?

Claudia: The spec should be agnostic.

???: some other places have push already.

Matt: pull payments take longer.
... who is going to write the rules for how settlement works. charge backs, etc?

Claudia: if only push payments work on this specification then the current card players won't work.

Matt: how long will this take to set up? What infrastructure is in place now?

Claudia: Not clear. New organization needed. New rules. You could use eChecks in the us. Clears same day.

Matt: There is authorization in card space in the US today.

manu: if the backend clearing network can't clear in real time, but some payment processor will guarantee availability after authorization.

Gray: Some intermediary will do this.
... also push payments are a more safe transaction.

claudia: if you say that it has to be push with guaranteed funds, won't that be more secure and cheaper.

<Erik> Gray: Push payments are 4x less likely to be fraud

????: user centric but our terminology is confusing. "push" is confusing.

manu: it is defined based upon what the merchant does.

matt: if we decide that push payments are in scope, based upon what is available in the US today, it is going to change priorities and timelines.

erik: some things will get done in parallel as we get task forces set up.

matt: moving push to the top of the list is going to make stuff challenging.

AndyF: there are different rules in europe vs. the us. someone needs to do the analysis to figure out what is feasible. It could take a month or more.

Wendy: From the W3C perspective what we need to be looking at is the web interface interface layer. Influencing what the industry does with push vs. pull payments is not going to be accomplished exclusively within the W3C.

dezell: We need to set up the wiki - dezell, erik, stephan volunteered.
... set up the use cases, business processes, matrix of actors, on-line or off-line,
... manu volunteered as well.
... is it worthwhile to have a taskforce to consider the payment agent?

manu: let's prioritize - what are the options?

dezell: some options: Payment Agent, Payment Type Negotiation?

manu: push vs. pull as a task force?
... payment agent seems like it encapsulates 80% of what we talked about already.
... so would we talk about push vs pull on the weekly calls?

dezell: yes.

pat: different actor relationships will change the discussion a lot.

Claudia: given that p2b has been the focus of the discussions to date, is that not the highest priority?
... there needs to be a consistent framework.

dezell: So I hear that P2B is the first thing to focus upon.

manu: credentialing / identity might need to be a future task force

dezell: payment agent task force: Stefan, manu, jorge

Administrativia

dezell: f2f - how often?

manu: fewer is better.

draggett: less but longer?

(some consensus that longer is better if there are less meetings)

stefb: we have a small subset of the companies who said they would participate here today. so we need to have a next one sooner than later.

dezell: not much time left in the year. so are you thinking in january / february?

stefb: end of feb meeting in Barcelona. Maybe something around then?

Claudia: Where are most of the members from?

stefb: Well, there needs to be balance for the participants and a sponsor.

<scribe> ACTION: dezell to set a page on the wiki with some sites that are in conjunction with other conferences and then try to pick a next location / date. [recorded in http://www.w3.org/2014/10/28-wpay-minutes.html#action03]

<trackbot> Created ACTION-1 - Set a page on the wiki with some sites that are in conjunction with other conferences and then try to pick a next location / date. [on David Ezell - due 2014-11-05].

dezell: straw poll. how many like two meetings a year; no more than 3; more than 3?

<stefb> ACTION: dezell to check for face-to-face place/time [recorded in http://www.w3.org/2014/10/28-wpay-minutes.html#action04]

<trackbot> Created ACTION-2 - Check for face-to-face place/time [on David Ezell - due 2014-11-05].

dezell: weekly meetings? or every two weeks?
... if it is every week, 1 hour vs 1.5 hours ?
... or every two weeks?
... time of day? Erik suggested at the chair's breakfast doing a poll of the group.

<Karen_> +1 taking Asian times into consideration

stefb: possible of alternating times so that it is easier some weeks.

dezell: do 9 AM eastern one week, and 9 PM eastern next week?
... let's try it for now
... what day? I prefer Friday
... next teleconference is Friday, 7 November at 9 AM eastern.

<manu> +1

<scribe> ACTION: Stefan to set up conference bridge [recorded in http://www.w3.org/2014/10/28-wpay-minutes.html#action05]

<trackbot> Error finding 'Stefan'. You can review and register nicknames at <http://www.w3.org/Payments/IG/track/users>.

<stefb> ACTION: stephane to setup conference bridge [recorded in http://www.w3.org/2014/10/28-wpay-minutes.html#action06]

<trackbot> Error finding 'stephane'. You can review and register nicknames at <http://www.w3.org/Payments/IG/track/users>.

<stefb> ACTION: boyera to setup conference bridge [recorded in http://www.w3.org/2014/10/28-wpay-minutes.html#action07]

<trackbot> Created ACTION-3 - Setup conference bridge [on Stéphane Boyera - due 2014-11-05].

<stefb> ACTION: boyera to send consolidated minutes [recorded in http://www.w3.org/2014/10/28-wpay-minutes.html#action08]

<trackbot> Created ACTION-4 - Send consolidated minutes [on Stéphane Boyera - due 2014-11-05].

- DRAFT -

Web Payments Interest Group Teleconference

28 Oct 2014

Attendees

Contents

ARTS/NRF UPOS

EMVCo

Continuation of Wallet discussion

Payment Agent (formally Wallet)

Administrativia

Summary of Action Items

Scribe.perl diagnostic output