Web payments Face-to-face meeting

Administrivia

David: 3 mailing-lists: public-webpayments-ig: public for the group
... 3 mailing-lists: public-webpayments-comments: public for all, everyone can comment
... member-webpayments-ig: adminstrivia list member only
... we use IRC on #wpay

you can use http://irc.w3.org or a native client

david: chairs are just here to drive the discussions, but the content is up ot the group members
... going over the agenda
... sysaps and nfc.

sysapps very important about how to access device capabilities

Manu: general idea: we see how the first day goes, and then we change in case it needs?

Joerg: I have a demo for after 6 in case you are interested

David: let's see nw if we need to change

Introduction

glen: from verisign, not used to W3C, but with ietf. interested in crypto currency+online identity

let's see overlap with ietf

patrick: fed from chicago. working on payments+identity

interested in interaction with the Web, interoperability is key

dave: from the fed in atlanta.

worked with PCI

interested in the whole area

Virginie: from gemalto

following the web payments activity since the beginning

key for us

interested in the wallet

Dan Sun: from verizon

Bernard: W3C staff in busdev

Mountie: working in korea and south-east asia providing payment

manu: representing few org.: chair of web payments cg, credential cg (identity )

working also for the open payment foundation

Manu: in W3C for quite long time, working on json-ld

excited by the diversity of pple in the room

Manu: hope we will also cover the unbanked and the underbanked

Jean-Yves: working for a consultancy i founded focus on business compliance

formerly with bank on hte regulatory side

Evert: from rabobank, first bank at W3C
... actively developing wallet and nfc payment for the retail sector

interested to see how national standard can fit with internation web standards

thomas: from World Bank (WB), part fo the WB payment team

doing lots of support on banking sector in client countries

also interested in interoperability, access to payment

inclusion is essential for us

I'm new to W3C, first time joining W3C

working with Harish who was in march in paris

Joerg: deutsche telekom, new to payments in W3C since march

involved with AAA authorization, Authentication,etc

interested in identity and also wallet

Dave: w3c staff

with the web since its creation

have been invomlved in launching this work

interested in value-added services around payments

payments for WoT too (paymetns for services

Dan: W3C since 99, working on vxml and related spec

representing aspect

working on web rtc

creator of voicexml

Angel: w3C staff in china

Francis: coming from china, created internet wallet.

we want ot bring our ideas to W3C

jeff: ceo of W3C
... embarassed that we haven't taken up on web payments, vrey glad this group starting. extremly important to W3C mission

Erik: part of accreditrust specialized in web credentials, identity

useful for all sectors

Istvan: from GSMA interested in wallet and web payment

<bgidon> Istvan Lajtos from GSMA

interested to see what value we can bring to the group

Bill: from educational testing service

interested in credentials & identity

been with W3C at the early day

<bgidon> Dan Druta

brian: open payment foundation, developer first W3C meeting

API deszign for retailer

Bill: paypal/ebay

<bgidon> Telenor

Lars Erik: opera

Karen: from ISOC, interested

Dieter: deutsche telekom

Charter review

dezell: We're going to review the charter now, let's see how this charter can help us w/ our mission.

<jeff> Link to charter?

erik: Has everyone had a chance to review the charter yet?

<steph> http://www.w3.org/2014/04/payments/webpayments_charter.html

Some nods, some sheepish downward glances.

<steph> charter uri: http://www.w3.org/2014/04/payments/webpayments_charter.html

erik: We're trying to build a platform that will be applicable to those on the Web. We want to support past payment mechanisms (ACH, Credit Card, etc.)
... We also want to support future payment mechanisms (cryptocurrencies, etc.)

Daniel: What do you mean by "legal" payment mechanisms?
... Was that meant to exclude any payment mechanism in particular?

erik: What's legal in US, doesn't mean it's legal elsewhere or vice versa.
... We aren't going to say what's legal not legal, we want the system to support things that are legal somewhere

Joerg: We want to support gray areas. This is what innovation looks like in the beginning

thomas: What about fiat vs. non-fiat?

thomas: We need to understand what's legal/not legal...

dezell: We were just trying to say "we don't want to support illegal activity".

glen: It's a relevant point, what about Bitcoin? It's illegal in somewhere...

erik: Ecquador made it illegal, but only because they're releasing their own.

dezell: Because this charter has been approved, it is what it is.
... This language is vague, we don't intend to not talk about Bitcoin because Ecuador said it's illegal. In the same point, we can't /just/ talk about Bitcoin.

jeff: The overall scope of the IG charter is broad, and probably doesn't need to be changed at this point. This gives plenty of room to work in it. We'll want to focus down, far much more in there than can be done in the first few months.

erik: It's hard to guess how long this will take.
... New front-end payment initiation systems.
... Other value transfer systems - loyalty, payments, etc. p2p payments.
... Web-mediated business-to-customer, business to business, etc.
... We are here to identify barriers, such as 'card not present'.

thomas: Is there a reason government-to-person payments isn't covered?

dezell: we say 'including', we don't exclude that.

erik: Identify ways to increase stability, make payments work better across web.
... use privacy/protection

dezell: We want to work with Web Crypto WG, etc. wrt. security.

erik: This group does not have solo understanding wrt. Web Crypto, we will work with Web Crypto group.
... Identify role of regulations in payment process... regs have big impact on this work. There's been a lot of talk about putting regulations in the code itself.
... prioritization of the work - self explanatory.
... Review deliverables by other W3C groups that impact our work here.
... Web Crypto, hardware tokens, etc.
... Liason w/ other organizations to get more interoperability.

joerg: Would it be important to talk to companies that could or should use Web Payments? That plays into hand of bizdev in a way.

erik: i can see that web technologies could be different front-ends into backend systems.

joerg: For example, XML has been used for a while, but we reused it in GSMA for some technologies.

dezell: The way the thing blooms, if you've done your REST Web Service correctly, there is a lot of power there... these technologies can be self-defining.
... I personally happen to be a fan of REST - it accepts in either JSON or XML, we can content negotiate.
... There are three bullets in here that are important - "identify missing pieces, missing gaps, identify role of regulations"

erik: Development of technical standards is not in scope for the group.
... We have to consider security/privacy/implications.
... Success criteria - we need participation.
... We're here for you.
... members of the IG will drive work of work items.
... We need constructive feedback on w3C deliverables.
... This is a new process for most of us, we need to ensure interoperability, work with other organizations.
... We need to iron out what we think of the road map, meet regularly.
... Primary deliverable is use cases, requirments, identification of technical specs, gaps.
... We'd ideally specify use cases and requirements and take it to other groups that exist out there.
... We will identify where W3C will need new groups. We want to focus on Web Wallet - that's the good one on there.
... So, work items
... First item is the roadmap - what is the roadmap going to be - identify, identify, identify.
... This is all about interoperability between old and new systems. Enable a level playing field, hard to stress how important that is - no vendor lock in. W3C patent policy is great.
... We want to reduce burden on vendors and payees to support multiple payment providers. Let them pay w/ what they want. Increase user protection.
... increase fraud protection, provide more transparency/choice
... What fees are provided. Identify other services that are relevant, invoices, digital receipts.
... next work item - web payments terminology - make sure we're speaking the same language.
... make sure we're talking about the same thing. Everyone speaking english, nobody understanding each other.

dezell: The transparency aspect - it's a big part of the work, alphabet soup for standards - transparency is not the point of the ISO specs. W3C transparency has a lot to do w/ accessibility.
... One of the core values of W3C is accessibility.
... UX is important.

erik: You want people to innovate, but you want it to be generally accessible.
... wrt. terminology - adopt as much as possible.
... next topic wallet and wallet API
... we're going to be talking about this quite a bit over the next day or two.
... transaction messaging - lots of ISO stuff out there, identify requirements/constraints for merchants.
... requirements for payment service providers - messaging, most of this exists already.

joerg: The word 'token' here might be confusing.
... We may want to avoid that word, or explain what it means per context. .

manu: I think we should stay away from the word "token" or "wallet" right now, could be a permathread.

joerg: We can't stop the use of the words, but we can't monopolize its use. So, better ‘qualify’ them with ‘reference wallet’, ‘hardware security token’, etc.

erfekkes_: We need to specify terms and reference to other terms.

dezell: We should discuss terminology.
... Maybe a Terminological Task Force

laughing in the group

dezell: but seriously, we need a common vocabulary.

thomas: A glossary might develop over time, to have a common set of terms.

erik: we should take into account mobile payments / proximity payments.

miguel: Here from intel - interested from Web Payments, we're in mobile space.

daniel: Before I was Chief Architect of PayPal, now CEO of GRIN.
... Know quite a bit about payments.

erik: Next up - identity, authentication, security
... identify, identify, identify - hot space right now
... ensure secure authentication, FIDO alliance, etc.
... Review existing identification methods and whether they fit in w/ what we're doing here - privacy, security, transaction privacy/security.

daniel: The purpose of FIDO is to generate docs/standardization around this stuff.

erik: identify user protection, data privacy, put the regulations in the code (as a suggestion)
... Access basic user and payment provider information in a way that's easy to synchronize between people. Wallet/SIM chip on telephone - how do you synchronize devices.
... minimize risk - build on top of Web Crypto - don't re-invent the wheel.
... U2F is coming out, various biometric devices - ekg / heartrate - lots of new technology that we can use.
... explore mechanisms for trusted UI - make sure rogue app in browser isn't authorized to make transactions on your behalf.

billGebert: From an education/governmental side, commercial hiring practices, identity is very, very important to us. Our experience at ETS in providing assessments to 200+ countries, and accepting payments, having the right person show up if they're hired/tested. Proficiency is important, that's where we're focused.
... That's what we want to see succeed in this group.

erik: The person taking the GRE, was that really that person taking the GRE.

billGebert: yes workforce, how much money is being wasted because of fraud that occurs. If the wrong person shows up to take the job, or shows up to a university - the cost there is well in the hundreds of millions.

erik: A lot of the problems we're working on here are important to both education and financial technology.
... There are many relevant groups working on this stuff.
... Too early to talk about a timeline for this work. We need short term deliverable focus on this. We don't want open ended tasks.
... Dependencies and liasons - there is a lot more out there that's important.
... participation is important - open to W3C members and invited experts.
... Let's bring those IEs in
... Communication happens over IRC, mailing list, phone calls. Every now and then, face to face meeting.
... Patent disclosures - disclose patents. We have a chance of success at this because of W3C patent policy.

mountie: The charter is trying to cover everything.

erik: There is a lot, we'll have to find things to stay focused on.
... Move what exists into a Web Payment scope.
... There will be new challenges, but most of the stuff exists today.

dezell: We can discuss all this stuff, but we are not the ones that do the technical work.
... We may create use cases, requirements to feed into other work. For example, security - summarize what the requirements are - send them over to WebCrypto group.
... We don't want to lose our way down the security rabbit hole.

mountie: one more comment - wrt. other W3C working groups - this is a convergence of other W3C group work... the group is similar to Web and TV, Web and Automotive... we have to take a different type of approach wrt. what needs to be standardized.
... Web Payments IG is very different from regular W3C groups - it's more high-level.

dezell: That's true - web and tv are parallel... this group is unique at W3C...

erik: There are a lot of different verticals that are going to be interested in this, we need to get involved in those other groups... how does that fit back into Web Payments.
... Get involved in other groups that interest you.

bernard: it's part of the IG to tell which groups should coordinate with whom.
... This is what we're working on - welcome.

dezell: important to show progress in the right areas.
... I hope everyone is thinking about what they want to see come out of the meeting.
... This isn't a spectator sport.

Patrick: Is the payment work looking at the non-human actors in payments - 3D printing, manufacturing, authentication of embedded web agents to facilitate payments.
... It's implied up here, is that another set of use cases?

dezell: That brings up another deep rathole - once you start selling things, and complying w/ regulations - merchant has responsibility - are you automating the sale of illegal goods? or legal goods in illegal ways?
... For example, people of certain ages won't be able to use certain crypto currencies.

joerg: Requirements for some work - depends on where you are, your perspective. I hope that we can say: This is how W3C work complies w/ the charter. Close the loop. Ok to talk about wide scope, but we need to boil it down so we can deliver on what we're going to deliver.

dezell: We need to bring people working on this here - we are good at removing walls.
... Tim Berners-Lee said: secret to standards is to get people that don't get along into the same room in a strange place... they start working toward common goal.
... There is a human factor to this - Bloomberg just joined X9, etc... we can create stuff at W3C and send those to X9 and ISO.

stephane: We have a session where we talk about outreach.
... think about this... who should be here and isn't... we'll talk about that tomorrow.

<steph> bill smith from paypal has left the room

Related Working Groups: Web Crypto

Virginie presents the web crypto WG (see slides )

In last 2 years, we have collected use cases. We have an API which is now quite mature and about to exit Last Call.

We're starting to think about next steps and the potential overlap with web payments, e.g. improved authentication using multi-factor techiques.

We had a workshop recently, see http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/

We have started to look at the potential role of trusted UI. as well as secure elements, etc. The new charter will begin next year.

Just keep in mind that there are groups that could help the Web Payments IG, e.g. Web Security IG, Web Crypto WG, WebAppSec WG. The latter is kicking off work on a credential API.

Questions?

Manu: when is rechartering happening?

Virginie: January 2015

To effect the WebCrypto Charter we need input by then

Manu asks about the credential API.

Virginie: we felt it would be a good fit for the WebAppSec WG which is rechartering at the same time as WebCrypto.

Some discussion about W3C domains. Dave Raggett notes that these are part if the way W3C staff are organized, and it is more important to focus on coordination by group members across groups.

Need to establish good communications across groups. Stephane adds that the Web payment IG charter lists groups or relevance. Having people who are participating in both the Web Payments IG and other groups is a particularly effective way to coordinate.

<virginie> FYI : credential management google proposal here http://mikewest.github.io/credentialmanagement/spec/

Manu: Google is leading work on credential API with support from Mozilla, which is very positive on behalf of browser vendors.

Dan: let's not tie what we're doing to specific browsers

Interoperability is the key.

What kind of credentials?

Manu: primarily relating to authentication to web sites.

<virginie> FYI : discussions related to next steps of web crypto is happening on the Web Security IG http://lists.w3.org/Archives/Public/public-web-security/

David: it is good for us to be engaged and we can discuss this further tomorrow in relation to plans for outreach.

Manu: a good way is to volunteer to perform spec reviews.

Virginie: the Web Security IG are more interested in reviewing specifcations and may not be effective at reviewing use cases.
... first spec from WebCrypto WG is mainly focused on widely deployed crypto algorithms.

Coordination between W3C and IETF on crypto e.g. in relation to HTTP.

Is multi-signature support on their radar? This is important for web payments.

<virginie> FYI : algorithms considered in the web crypto are listed here : https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithm-recommendations

David: one challenge is whether we trust the devices the apps run on?

Answer: you can't trust the devices in general.

Dan: you don't want to confuse encryption with security.

Joerg: is the security good enough for protecting the brand behind the solutions. If Deutsche Bank issues a VISA card in Deutsche Telekom wallet, it’s mainly the three brands, not the security technology which is invisible to the user, that makes them trust and accept a solution.

David: there are a lot of warning flags, so we need to be vigilant.

Related Groups: Web Payments CG (Manu Sporny)

see https://web-payments.org/slides/2014/tpac-wpig-wpcg/

David invites a couple of people who just stepped in to introduce themselves.

<steph> Matt: from walmart

Manu starts with his introduction to the web payments community group and invites questions

<steph> uri slides:https://web-payments.org/slides/2014/tpac-wpig-wpcg/

He explains that community groups are unofficial and exist to incubate work. The web payment CG has 184 registered members.

We're an incubator for ideas we think may have potential and expect to pass ideas to the Interest Group for review. The CG is open to anyone, and our work is open, inclusive and transparent.

The CG is collaborating with a range of other groups. These include technical groups as well as policy, regulatory and legal groups.

Manu mentions the Open Payments Foundation which focuses on open source implementations

He recounts the timelime that has led to the Web Payments IG. Want to encourage good coordination between the CG and IG.

Lists the web platform's current failures: no standards for credentials, payment initiation and digital receipts.

Web Payments CG considers the following to be important: civic - strong identity is central to ownership, democracy, privacy and prosperity

The fact that 2.5 billion adults lack access to financial infrastructure.

The opportunity for the Internet to provide a more agile and vibrant global economy. Why does money transfer take much much longer than sending an email?

Role of phones and increasing penetration of smart phones across the globe.

Some discussion around MPESA for mobile payments.

David: the time for completing payments is related to maintaining control and business models for payment infrastructure.

Competition will drive innovation, e.g. for faster payments.

Daniel Austin: if we can make it profitable for companies to complete payments quickly, that is what will happen.

Experience with Rabobank in the Netherlands. We are trying to encourage card payments over cash payments and looking at the incentives to make that happen.

Moving money internationally involves many parties, and interoperability will stream line this.

Manu introduces the Web Payments CG use cases. We took these from the Paris workshop. They include push payments,subscriptions, digital receipts, pseudo anonymity, wallet portability, account portability, etc.

The design criteria include supporting existing payment instruments, emerging instruments, digital/physical receipts, smart contracts, etc.

David: the IG should review the CG use cases document.

Dan: this shouldn't be considered to be exhaustive
... but is awesome work and will definitely be helpful

Stephane: is this a static finished document, or a living document?

Manu: it is continuing to evolve

We don't have any input into the use cases document from external groups as yet

(cites a list of organizations we would like to hear from)

Dan: it would be interesting to pick all the use cases with validity and pick some for detailed examination

Stephane: as well as selecting use cases, we need to prioritize them, and to ensure that they have sufficient coverage of the challenges we want to address

We have a technology stack (see diagram).

The Web Payment CG considers itself to be in a supporting role to the IG and will continue to experiment with pre-standardization payment technology. Likewise to continue outreach and collection of review input for the IG

Dan: we need to have a clear position when it comes to crypto currencies that we can communicate easily.

Disruptive technologies occur regularly. Things are going to shift in response. We need to keep an open mind and build standards that aren't too attached to current regulation and payment solutions.

Manu: the CG is very happy to take on things that would be impractical for the IG to address without being disrupted.

Some discussion on ensuring the messaging of the relationship between the IG and CG is really clear. We need to avoid mixed messages.

Dan: the W3C name on the CG is confusing.

Stephane: we are aware of this and want to help

Joerg: is there a picture that makes the differences between the various kinds of groups clear?

Stephane: not as far as I am aware, but it is a good idea

Dan Burnett: this is work for the W3C to make the distinction clearer

Manu: there are links on futher background from the slides

The slides are at https://web-payments.org/slides/2014/tpac-wpig-wpcg/

Joerg: I have the feeling that we are touching identity now and identity has many faces. We are missing entitlements as an instrument that avoids the need for tracing all transactions back to the payee.

Related groups: Credentials CG (Manu Sporny)

Slides: http://opencreds.org/presentations/2014/tpac-wpig-ccg/

This spun out of the web payments CG. People felt that work on credentials should be split off to avoid it being tied to closely to payments.

Manu presents the credential CG's definition of the term "credential".

One of the groups participating in the CG is the Badge Alliance, a spin off from Mozilla.

Manu plays a video

The video mentions credentials relating to educational achievements.

Manu: mostly relating to K through 12 age groups

The problem this is addressing is to be able to prove to employers that job applicants have the qualifications they claim to have.

This very much ties to identity. When you take an exam you need to prove your identity.

This requires high stakes credentials. We've been working on addressing this using JSON-LD and digital signatures.

We want to avoid the need for use name and passwords, date of birth and so forth which are subject to fraud.

High stake credentials may be formed from credentials that may or may not be high stakes.

You shouldn't need to distinguish whether these contributory credentials are high stakes.

Dan: these credentials may not be the same as needed for payments, right?
... We need to keep these separate.

Joerg: credible signatures generally speaking involve a cost and a globally recognized signature is likely to cost even more.

Mountie describes the situation in Korea

Manu: this is not a centralized solution. We need to look at what do we need to get people on board, and separately to address the technical issues.

Privacy and tracking are important issues to address.

Some discussion about the relationship to payments, and the role of standards for credentials.

scribe: and the relationship to business models.

Multiple credentials can help to reduce risk.

Open standards would be valuable.

Discussion around tokens and EMV.

David: this group (web payment IG) will need to be proactive and surf on current efforts.

Manu asks for 15 minutes to wrap up after we resume from lunch.

<steph> http://opencreds.org/presentations/2014/tpac-wpig-ccg/

<evert> evert: tests the connection

<evert> scribenick: evert

manu: continues presentation of Credentials CG, starting from Badge Alliance

Menu: Accreditrust

Manu: Educational Testing Service by Bill

Bill: challenge for education space is the credentials from education must be built on low-level credentials for web identity (secure)
... Need to sign credentials. Customer decides which credentials are high stakes. Hiring practices, assessments. Individuals take assessments (such as English) are worldwide
... challenge that ensure that individual who pays for the assessment is the same individual who takes the assessment *giving access to some of the great universities)
... Large business in " selling access to universities" based on the credentials being issued
... how can these credentials be issued, transportable and secure? Cradle to cradle, starting already in primary school and life-long
... what happens somebody passes away, how will the credentials will be deactivated?
... Governmental agents such as immigration need this in their process

Manu: ETS is Educatonial Testing Service

Bill: Also machine to machine connections for processing automated testing of assessments
... 100s of millions of transactions processed by ETS worldwide

Manu: Strong beleif in Credential CG that this technology can also be used for Payments. Express and Verify a credential on-line
... Credentials CG is a same type of organization as the Payments CG, spin off and giving input to the WPIG
... collaboration happening with government organization US, Educations, IGF. Not with Swift, EMV etc right now.

Daniel: missing a number organizations such as Swift and EMVco

Matt: is there an idea about what the ideal state would be like?

Manu: no, that;s not yet defined
... very focused on just storage and transmission of credentials over the web
... need to transmit proof of age or identity document. Care about data probability, Support legacy systems.
... Use cases will be very specific: verifiable claims, storage, transmission, etc
... technology stack is currently "a mess", too complicated still.
... a lot of this stack is similar to that og the Payments CG

Manu The Credentials CG hopes to play a similar role for the WPIG as the Payments CG does

Manu: slides are on http://opencreds.org/presentations/

Mountie: credentials are not always required for every payment transaction

Manu: we want to be able to process pseudo anonymous transactions
... credentials will be required for instance for opening a bank account over the web in the future

Mountie: during Paris workshop, huge number of anonymous payments were discussed. Anonymous payment is very important in a number of cases

Daniel: Not convinced that the credentials (and classes thereof) are the same for these cases. Privacy can be different: an address is not required when buying a candy bar. There will be N levels of credentials for different use cases
... we need to think of of more refined way handling credentials

David: we need to talk this further. As a point of order, we need to proceed to the next topic

NFC, SysApps, Trust & Permission

Dave Raggett presenting (slides)

David: we are moving to the buying side of the conversation now

Dave: SysApps, NFC and their relevance to wallets and payment solutions
... Also trust and permissions are in scope here
... Wallets and payment solutions could be implemented as web applications (stress on could)
... standards allowing this required. Locally installed on a device, remotely hosted in the cloud or a hybrid of these
... user registers wallet with browser,
... user registers payment solution with wallet
... synchronization across devices is for the implementors to address
... System Applications WG drafted 2 years ago
... two models: packaged apps installed from app store and hosted apps run from the web server
... Phase 1 focus on executions & security model plus small number of APIs (in progress)
... proposals for App Manifest (JSON), App lifecylcle and App URI (Last Call WD)
... App lifecycle has an eventing model based upon Service Worker now
... Challenges for dealing with trust & permissions in an interoperable way
... Lifecycle can have several states (micro lifecycle events)
... the Service Worker can be launched from several events, including system events
... other phase 1 work items: Task scheduler, Contacts, Messaging, Telephony and TCP & UDP sockets

David: This is really what is talked about. JS engine running in the browser to launch events, not requiring to be a guru to use these.
... think about EMV offline transactions serviced by a Service Worker

Dave: scripting in HTML processed by Web Workers (not in the thread)
... Sysapps phase 2: Bluetooth API, Browser API, Calendar API, Deveice Capa API, Idle API, Media Storage API, Network IF API, Secure Elements API, System Settings API

David: If you have a development group developing an API it is good to look what APIs are developed here. Giving much better alignment going forward

Dave: Secure Elements API intended to enable web apps to invoke code hosted by tamper resistant modules
... Draft spec by Gemalto http://opoto.github.io/secure-element/
... use cases Authentication, digital signature, payment, credential provisioning

Joerg: Processing in laptops with TPM differs quite a bit from UICC processing. Is that included? (not clear now)
... the API should be generic enough

Dave: Via NFC to secure element on another device.
... the slides are linked on the meeting agenda

https://www.w3.org/Payments/IG/wiki/images/b/b4/27-dsr-payments.pdf

Dave: discusses diagram in slides, user device running web application runtime with secure element. API is abstraction layer over the APDU exchange.
... slide number is 9/22

Joerg: usually you should have only one agent addressing the SE. Lot of discussion here

Dave: Application in JS communicating with the Secure Element

Joerg: you need some rulings on how to access the SE, such as known secrets. More complex when application also plays a role, depending on the status of the applet.
... is the hash of the app correct to access the SIM card? (e.g.)

Dave: Bluetooth API - lots of innovations such as Paypal and Apple beacons

Daniel: security linked strong to Bluetooth Low Energy

Dave: Bluetooth Community Group http://www.w3.org/community/web-bluetooth/
... using BLE to broadcast URIs to nearby phones. Google promoting "Physical Web"

Daniel: a Discovery mechanism of some sort will be needed

Dave: Discovery will prove to be quite challenging
... strong relevance for payments.
... NFC working group: tap based interaction (very short range)
... growth now to really take off? Significant announcement of Apple
... Google android, Windows Phone API, Firefox OS, Tizen - all different APIs
... Basic functionality: NDEF small formatted messages such as strings, URLs. Sending and receiving NDEF messages between peers
... Handover mechanisms for bluetooth and wifi pairing
... card emulation is NOT yet supported, could be in a future specification
... see secure element API for APDU access
... Possible use cases (see slide 12/22)
... for NFC to have a common standard we have to develop the use case. Will the Payment area drive this?
... code example slide 14/22 (Promise design pattern)
... NFC is common in hardware now,how to move from proprietary to open API standards?

Manu: general NFC use cases, FIDO alliance 2 factor authentication device - could not figure out how to piece the parts together
... what specs required, where to look? What does a " useful package" consist of?
... what needs to be completed at W3C to enable this to happen?

Dave: Hardware tokens is restarted in the Web Crypto group

David: we need to figure out how to make things secure, interface the Secure Element

Mountie: comment, Web Crypto WG is different for key ownership philosophy. Is the user having ownership? Contradictions exist today

Dave: some stories around provisioning

Joerg: when an SE is shipped, you need to keep track of it. The manufacturer does not have the customer relation.
... end user may have to have the power, but someone has to manage this in the back end

David: Thinks that this IG has a clear role to decide how to manage loading keys. Strategies need to be put in place.

Joerg: what is needed to make a wallet workable? Providing e.g. Mastercard and Visa functionality needs backend support, others might have other ways.

Dave: this is good stuff for further discussions on the use cases
... Trust and permissions
... Apps need to be trusted before they can be given access to use certain capabilities such as payments and raw socket access
... common approaches include asking user consent when app is installed (android) or first used (iOS)
... Browse may silently grant permission to platform apps
... native platforms handle this in a proprietory wa (iOS, Android, Windows Phone)
... Hybrid platforms - Apcha Cordova/Phonegap
... Open Web Platform HTML5

Web OS platforms extending the Open Web Platform proprietary: Mozilla Firefox, Tizen etc

Daniel Burnett: depending on connection being secure or not, some trust aspects can be stored

Dave: resource integrity, application accesses local libraries
... http://www.w3.org/2014/07/permissions/
... SysApps meeting sharing experiences on native platforms, web platforms and research studies
... Discussed ideas for extending the Open Web Platform
... Need shared standards for Open Web Platform, building on precedents with exiting APIs
... Browser vendors looking for heuristics monitoring how apps work, detecting misbehaving apps
... increasing role for endorsements by trusted 3rd parties as a way for users to delegate trust decisions
... avoid to ask the user upfront a long list of approving all kind of things
... general agreement on launching a Community Group on Trust and Permisisons
... Questions?

Manu: trust level to be obtained,?

Dave: Granularity depends. When asking the user, a small set of questions must be asked. When delegated, it can be more fine grained
... prevent lots of annoying questions to the users, there is lots of interest for the delegation model

Daniel: Web RTC model - browser must confirm that the user has given permission - but does not say how. May be a license agreement in some cases.
... different browser vendors have implemented this in different ways

David: Web browser is itself also just an application. When controlling other applications there can be issues.

Dave: Suspicious behavior of apps may be determined also by others, such as a responsible adult monitoring.
... important where the trusted software is running

Daniel: the generic term for the browser is the " user agent". What we need to trust is not the browser, but the specific JavaScript
... this JavaScript can be monitored on its behaviour

Erik: having deployed enterprise solutions, learned that sometimes a rogue install of a script by the user can interfere with otherwise secure distribution of signed JS

ISO 20022

erik: This is a basic introduction to ISO20022, it's a big data dictionary, highlight some particular items of interest.
... This is a recipe for making financial industry standards.
... FIs exchange massive amounts of information - sender/receiver need to agree on structured format... syntax and semantics.

page 14 of ISO20022 for dummies

erik: There isn't one standard out there, there are many.
... You can map XML to SWIFT like so - syntax is the format - the way the message is structured.
... so think of text-based, vs. XML-based, vs. JSON-based format
... Widely used existing standards in FI space... lots from ISO / SWIFT / etc.
... For example, if you want to exchange an address - it must contain these components
... ISO20022 is a consistent message standard across business/industry. Business components and elements - started high, went low. Messages are aligned for business processes.
... page 23 - syntax - ISO20022 is focused on separate layers - two different layers... third layer is physical syntax.
... focus is on reusability
... FI identification - that data structure looks identical
... What makes ISO so great? logical messages can be mapped to business definitions. Technical definitions map to businesses.
... Linking messages back to business processes, money transfer, security exchange, etc.

ISO 8583

Slides: https://www.w3.org/Payments/IG/wiki/images/6/69/W3C_Web_Payments_-_Topics.pdf

dezell: I think we want to reuse what we can to enhance the experience on the Web... people sending money and people receiving money are important.

dezell: First bone of contention is 8583 is what is in use in most US banks.

dezell: They dont' want to give it up - it's a bit format, invented for a 1200 baud modem.

dezell: This isn't like XML, not human readable... based on business processes.. doesn't have reusable components. older, smaller message format.

dezell: Showing slide 2, authorization message, financial messages, file actions, reversal and chargebacks, reconsiliation, administrative, fee collection, etc.

dezell: If you think about payment protocols, they do these things, they're going to have admiistrative components.

ISO 12812

Slides: https://www.w3.org/Payments/IG/wiki/images/6/69/W3C_Web_Payments_-_Topics.pdf

dezell: New mobile financial services - web financial services - huge amount of momentum behind this work. More or less trying to do some of the same things we want to do. It shouldn't be bad/demotivating. We could dust around the edges and reuse it.

dezell: Just last week, they decided to make this an international standard - if you say you're going to do it, you have to do it, or you're fined.

dezell: There are 5 details here - introduces a concept of a mobile financial service provider.

dezell: They can be banks, mnos, etc. Intent is to reuse ISO - the issue is TC68 dropped the ball on 8583 is out of sync. Let's assume it'll happen.

dezell: What the US recommended - the committee did all of it. They asked secure elements to be changed to "cloud" processing of sensitive data.

dezell: We can reuse most of this technology. If you focus on SE, you are driving a solution like NFC - we don't want to do that, we want to be more open/general.

Joerg: The intention is good and understood - one is that it works offline, the other is it works online, but allows instant reassessment of the risk. Different functionalty - you can assess risk in realtime. They have very different powers in there.

Claudia: We dont' want to limit it to one approach, that was the problem w/ the existing standard.

dezell: You don't want to refactor often. Lots of back and forth between david, claudia, joerg - discussing the reason behind the move to more abstract terminology.

dezell: Parts - general, security and data protection, financial app management, mobile payments to persons/businesses.

dezell: Since this has the force of an international standard - lots of SHALLs - doesn't specify what mechanism to use.

dezell: This is strange to W3C - we're much more nuts and bolts, we don't make policy recommendations in general, but we need to learn to swim in this world.

dezell: Consumer rights - important - putting this sort of stuff in the spec is something we may need to put in the technical specs.

dezell: You have to provide all those rails in your spec.

dezell: Consumer rights are the important bit

dezell: PIN entry - for people that care about this sort of thing - Gemalto is the king of this world - has everything to do w/ access to the secure element.

dezell: You can never enter it on a random device - only into devices rated in a certain way. How to make that accessible w/in the Web. The idea of a PIN, it's something sacrosanct to us.

X9

Slides: https://www.w3.org/Payments/IG/wiki/images/0/03/102014_Draft_W3C_Presentation_Swendseid_10_27_2014.pptx

Claudia: Intro slide on Fed, you can read it on your own

Claudia: There are various X* organizations, they're all accredited by ANSI - we have to follow processes, we're audited, etc. There are ways that X* organinzations follow consensus/voting.

Claudia: There is an explicit and open voting process - there is a process that has to be maintained/updated.

Claudia: When ANSI accredits a standards body, they accredit them for a certain area - X9 is for the US Financial industry

Claudia: We focus on today and where we're going into the future - we own the US vote into ISO for TC68, whcih is the counter-part to X9

Claudia: US adoption of ISO standards - we work with ISO. In general, if we want to start a new standards effort in X9, we'll just start as an ISO work item. If it's clear that it only has domestic relevance, for example check images, mobile standards - if we can't get international adoption, we might then revert to a domestic standard

Claudia: Within X9, we have management committees, we have technical subcommittees - four - payments, corporate, securities, data security.

Claudia: Payments is where you find check cards, mirror groups for ISo12812

Claudia: Corporate payments, mostly US - but there is an effort to take X12 for electronic data interchange - don't know if this is true of W3C, often a standard is written w/o implementation document. List of 700 codes that large retailers/suppliers.

Claudia: No information about which codes about different things - no interoperability - if walmart uses code for "bad hanger", and Macy's uses a different one - there is a problem.

Claudia: We need companion guides or implementations.

Claudia: We have quite a few standards in data security - you may want to look at X9.112 - security here is more robust - tokenization may be relevant - cloud security may be relevant. Involves US work.

Matt: Is anyone usin the tokenization mechanism yet?

Claudia: Part one .. part two ? (scirbe missed)

Claudia: When that comes out, large retailers are interested - we'd be targetting education for those groups - NACS is involved in that work. US, ANSI, etc. sync up in this way - overarching body - ANSI / ISO.

Claudia: There are lots of TCs in ISO - we are secretariat TC68 - McKenna chairs TC68

Claudia: Data and info sec group relates to subcommittee 2 - mapping global SCs to US X* groups

Claudia: Just giving some of the organizational feel - membership is structured differently - 4 levels of membership - A-level... fees are flat vs. based on revenues - one WG may join at WG level... vs. joining at consensus body level. We do a lot of MOUs w/ other standards orgs,

Claudia: X9 would be very interested in collaborating in any way.

Erik: How do you see the work of this group working w/ the X9 group - do individual companies work w/ them... or can W3C collaborate directly with them?

Claudia: I'll give you an example - we setup orgs w/ ??? organization - they setup a workgroup to develop extended remittance standard. In US we can carry large amount of data for remittance data... US has multiples of 1000s, other countries have maybe 200 characters.

Claudia: Since we manage TC68, we have lots of ISO capabiltiy - we wrote a MOU on their behalf.

Claudia: That worked well...

Claudia: On a separate slide - pain points between financial institutions and corporates - subject matter expertise between subject matter experts - join at WG level... 1,200/year - provide input into standard in that way.

Claudia: What collaboration might work best? I can setup a call - we issue joint standards, lots of different standards out there.

Karen: How do other countires around the world interact w/ ISO/ANSI.

Claudia: In germany for example, there are german represenative, japanese reps, etc.

Claudia: The country elects their reps - every board meeeting for X9 has TC68 meeting - who will be our reps for SC4, who for mobile effort? Then we send a delegation, every country has the same thing.

Claudia: That's how they come into ISO, typically.

Matt: Are we trying to get X9 join this group? If Web Payments WG of some sort comes up w/ the spec, do we have X9 co-sponsor it?

Claudia: So, mobile financial services standard, for example - you may be able to adopt it wholesale. What I do, do a gap analysis - figure out what's alreaady good, what can we reuse?

Claudia: For example, taking existing X12 standard, X9 owns IP, X12 owns IP - then we come to an agreement - we're better off using eaach others work.

Claudia: Maybe this group sits down w/ other group and you do a gap analysis - which standards do you want to reuse - refer to other standard, lots of ways we can get that to work.

dezell: W3C has submitter status w/ ISO - we can actually make this an ISO standard if done successfully.

Matt: Yes, joint support - maybe get FED on record.

Claudia: There is a place for proprietary standards, we don't hate them, but in general we tend to prefer open consensus standards work, more democratic, more voices at the table, etc.

Claudia: We would be happy to say things along those lines, on public record - anything I can help to broker that, happy to help.

Mountie: What about ITU-T? Similar approach to X9

Claudia: How would you see that working?

Mountie: ITU-T is trying to keep current technologies - aim is similar to X9, is there any touch points/considerations wrt. ITU-T standards in the US?

dezell: Please bring that back up in the outreach session.

Claudia: ISO and X9 aren't the only standards bodies that your effort might want to build on.

Daniel: They have Internet of Things (ITU-T) standards... so we want to pay attention to that.

ARTS/NRF UPOS

Slides: https://www.w3.org/Payments/IG/wiki/images/6/69/W3C_Web_Payments_-_Topics.pdf

dezell: There are other efforts - universal Point of Sale

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.

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.

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,

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

EMVCo

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)

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

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.

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.

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

Manu …is the EMVCo the mechanism?

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

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

Wallet discussion - day 1

Speaker: Jorg Heuer, Deutsche Telekom

Slides: https://www.w3.org/Payments/IG/wiki/images/a/a5/141027_T-Labs_Wallet_TPAC_1_1.pdf

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 for those who provide wallet service

…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, hardware and all the backend services

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

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

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

…but they have not yet blasted through the ecosystem 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, UICC (SIM card with Secure Element) 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 DT 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 for cars

…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

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

…do not know what sits in the secure element

…but make sure the implementation accesses the secure element properly

…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 with InfoCard

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

…it is already sitting there

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

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

…get a new user card for each new mail box for example or any other account at a service

…Since we do have ideas about the 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 it needs to 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

…a wallet operator, someone who runs a wallet service

…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 MNOs now, say we need to have one wallet

…One joint wallet operation

…would make onboarding easier

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

…We did it in HTML5

scribe: centering our development around virtual cards, tickets, and coupons

…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 and hardware capabilities

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

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

…can be pretty frightening if there’s computers all around you

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

…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 if done somewhere in the cloud

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

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

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

…reference to Doc Searls

…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

…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

…between issuing bank and operator

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

…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 everybody to go for it

…and important to provide secure element 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 monolithic 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 to, 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 necessary a wallet

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

…each needs its own spec and business logics

…In showing people the demo we can make it easier to understand and discuss

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

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

…i came to hate the word wallet because of all the misunderstandings

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

…Not an aspiration of some service to be a wallet provider for just their brand and partners

…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 architecture for now, needs to turn into an ecosystem

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 pick some elements, the context allows the wallet to narrow down choice to what makes sense

…may be a question of communications 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

Joerg: I hope so

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

…people were proud of SIM card

…one example was security arm who’d provide SD cardswith an SE

…good for customers who need secure elements with special certifications

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 from the client. we already have a client with an HTML5 web interface
... 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, could 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]

Day 2 - 28 Oct 2014

Continuation of Wallet discussion

David Ezell: First presentation/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 Searls 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 functions even in one implementations - even for a plastic card..
... use context to be able to decide which function of an "item" to use.. [example: Lufthansa Miles & More Master Card. Collects points, can do MC’s PayWave, could as well open door to lounge or let you pay with miles or points…]

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

Essentially: the user gets to pick his/ her payment instrument every time again. Avoid pre-configurations not remembered, merchants storing data they shouldn’t/ needn’t, stale data, update problems for users changing cards and banks

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

High level of flexibility allows for many technologies and logics to be applied

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

patrick: 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 payment 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, yet enabling it through the framework. Need to be ‘agnostic’ and open.

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

Gray: merchant id is needed for certain use cases

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

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 (desired by banks too, otherwise see above for reasoning on update and transparency problems)

<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
... specific modules can help with location information, identifying contexts, etc.
... 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

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]

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

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

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.

mountie: can we remove this requirement?

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

mountie: 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 levels of uses. 1) transparency for the user. 2) the merchant wants the transaction list in a form that is acceptable for e.g. refunds, repair, etc. 3) legal support for liability.
... legally binding receipt will be harder to implement. But we can start with the easiest.

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 the entire receipt comes over NFC i would be very surprised. [too high data volume]

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

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]

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.

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

dezell: 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]

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]

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

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

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