Web Payments IG F2F, Utrecht

2-4 February 2015

We would like to acknowledge support from the European Commission through funding for the Seventh Framework Programme (FP7/2013-2015) under grant agreement n°611327 – HTML5Apps.

This was the second face to face for the Web Payments Interest Group. We were hosted by Rabobank.

Minutes

Agenda

Day 1 (Monday – Start 10:00 Local Time)

Day’s Topics – IG Review, Use Case and Glossary Discussions

Morning 1

• Administrivia
  • Welcome, Introductions, and W3M Announcements
  • Appointment of Scribe
  • Review and approval of
  • Review and approval of Santa Clara Face To Face Minutes
  • Review and Bashing of Agenda

• Getting up to speed
  • Introduction to the Payments IG, Highlights of the Charter, and progress to date (30 minutes).
  • Quick overview of other work going on in this space (30 minutes)
    • ISO20022
    • ISO12812
    • X9.119 Pt 2
    • Web Crypto, NFC
    • Credentials
      • Use Cases
      • Credentials JSON-LD Context/Vocabulary
      • Roadmap

• Discussion: Capturing Key Principles and Desired Outcomes – What do successful Web Payments Look Like?
  • A fast and significant adoption of the technology (>100M+ in the first two years).
  • Level playing field (aka fair competition) for merchants, payment providers, customers, software vendors, and payment networks.
  • A great reduction in “stolen card” transaction fraud.
  • A great reduction in the amount of custom software that a merchant must write to integrate with new payment products.
  • Removal of the need for a merchant to hold on to sensitive customer data.
  • Greatly reduced payment provider switching costs for customers and merchants.

Lunch

Afternoon 1

• Appointment of Scribe

• Refining the Glossary

Web Payments Glossary

• Introducing the Use Cases

Work of the TF so far, including categorization work

At the end of this section the goal is to have at least a handful of the “big rocks” that we are trying to improve as we go through specific use cases.

• • Approaching the Use Cases
    • Solidify our understanding, through the use case discussion, of the building blocks required to create a useful payment experience.
    • Identify missing blocks and gaps.
  • Use Cases TF Page
  • Use Cases Editors Draft
• Introduction of the “Payment Steps” proposal (link TBA)
  • Offer of Sale
  • Establish Credentials / Payment Initiation / Request / Invoice Generation
  • Value-added services / Coupons / Loyalty / etc.
  • Jurisdictional and Regulatory Controls
  • Delivery of Proof-of-Hold / Proof-of-Funds/ Proof-of-Purchase / Digital Receipt
  • Payment Clearing
  • Refunds / Reversals
• Focus
  • Focus on data being passed, rather than who it goes to.

• Deeper dive on the Use Cases

Use the building blocks discovered in conjunction with use cases document to walk through early use cases deliverables to do proof of concept on building block needs/goals/gaps.

Break

Afternoon 2

• Deeper dive on the Use Cases (continued)

Break

Afternoon 3

• Applying Scenarios and Building Blocks

this section will take the use case scenarios and key building block principles in conjunction with the logical models to determine if we have the right level of abstraction in the building blocks and if there are any additional building blocks or details that should be added/edited.

• Short introduction of the work of UETP (30 minutes).
• Recap/overview of Day 2

Team Dinner/Outing

Indonesisch Restaurant Borobudur

Veemarktplein 42 (facing the Jaarbeurs)

19.30

set menu: rice table (mixed dishes)

Day 2 (Tuesday – Start 9:00 Local Time)

Day’s Topics – discuss the User Payment Agent, begin to formulate the outline of the Roadmap

Morning 1

• Appointment of Scribe
• Overview of day
• Agenda rebash
• Review of Logical Web Payments Models (Payment Agent Architecture Concepts)

Include roundtable discussion/white boarding session on other web payments concepts or enhancements to existing concepts

Break

Morning 2

• Continue discussion of User Payment Agent and Logical Web Payments Models

Lunch

Afternoon 1

• Appointment of Scribe
• Finish discussion of User Payment Agent

Break

Afternoon 2

• Revisit Scenarios and Building Blocks, informed now by Use Cases and Payment Agent discussions
• Begin discussion of the Roadmap Outline

Work in this section to begin to build an outline for the roadmap and identify needed information to complete the roadmap.

Break

Afternoon 3

• Finish Discussion of the Roadmap Outline
• Recap/overview of Day 3

Team Dinner

Day 3 (Wednesday – Start 9:00 Local Time)

Day’s Topics – finish discussion of the Roadmap document outline, brainstorm about membership, review emerging ideas, define next steps

Morning 1

• Appointment of Scribe
• Overview of day
• Agenda rebash
• Roundtable discussion on new marketplace happenings that might influence/impact our work.

[E.g. new product launches/announcements/credentials, etc.]

Break

Morning 2

• Membership brainstorm
  • Talent/Recruitment
    • Looking at the where we would like to go with the release plan,
    • Identify prioritized list of needed expertise/experience that will be required to ensure goals are met.

Lunch

Afternoon 1

• Appointment of Scribe
• Membership Brainstorm continued
  • Industry engagement and promotion – engage the broader workgroup in determining forums and places to build awareness of the W3C Payments work and any support needed from the team

Break

Afternoon 2

• Refine Go-Forward Plans
  • Use Case FPWD publication
  • Payment Agent publication
  • Other required task forces or recommendations for WGs to W3M
• Looking Forward: Wrap up, Action Items, etc.
• AOB

Adjourn (17:00)

Minutes

2 February

3 February

Welcome

<wseltzer> Erik: Today’s main topics will be payment agent and to start on roadmap

<wseltzer> … idea of discussing payment agent is to give us a lens for viewing the use cases

<wseltzer> … not yet an actual architecture

<wseltzer> … it’s up to you to tell us when we’re wrong

<wseltzer> scribenick: wseltzer

David: [recap of yesterday]
… We reviewed some outside resources — not all
… reviewed use cases. Necessary but challenging
… Today, we want to talk about straw architecture
… speaking as a WG member, I’ve never thought we’d replace X9 or ISO 20022
… but think about way technologies fit together with the Open Web Platform
… other W3C values, universal accessibility
… We’re the steering committee

<scribe> Agenda: https://www.w3.org/Payments/IG/wiki/2014-02-02_Meeting_Page#Day_2_.28Tuesday_-_Start_9:00_Local_Time.29

David: We’ll see Joerg’s demo, then talk about user payment agent
… Afternoon, we’ll look to use cases+architecture => roadmap

<AndersR> Related to payment agent. W3C WebCrypto.Next went belly-up yesterday

David: IG publication of FPWD will help show the rest of the world what we’re starting
… Roadmap give us a starting point

<Zakim> m4nu, you wanted to recommend we look at payment phases from the agenda yesterday

m4nu: Can we talk about phases of payment process?

Joerg: I planned to run through the wiki page briefly
… first, a quick demo
… then go into phase model, to connect with use cases

David: Time-boxed discussion of payment phases

Payment Phases

https://www.w3.org/Payments/IG/wiki/2014-02-02_Meeting_Page#Afternoon_1

m4nu: breaking down into the steps that any software needs to complete for a transaction
… group could add/remove decide we don’t want to deal with some
… 1. Offer of sale
… 2. payment initiation. e.g. customer on-site finds something they want to buy. invoice-generation
… 3. jurisdictional and regulatory controls. fuzzy area
… pre-purchase, e.g. regulatory reporting for authorization

4. proof of funds

scribe: Delivery of Proof-of-Hold / Proof-of-Funds/ Proof-of-Purchase / Digital Receipt
… this is out of the hands of the customer and merchant
… 5. payment clearing
… 6. refunds/reversals

david: that’s not really a step, but an aspect

m4nu: what does the group do for each of these stages?
… maybe nothing, maybe something

jheuer: Important aspects of the process. Not all are steps, but some are framing.
… offer of sale may be a thicket. for Payments, we might want to start with payment initiation.
… shopping experience may be out of scope, unnecessary for “payments” work
… so I’d start with payment initiation, take out jurisdication, possibly talk about credentials, then delivery of digital receipt
… not sure we need to go deeply into processing now / as w3c

CyrilV: we may need more detail
… describe the actors participating in these steps
… notifications

<steph> +1 to detail the payment processes

CyrilV: for me, it’s a 3D description, but after we describe the process, we can apply it to many kinds of payment

Chaals: take offer of sale off the critical path

<evanschwartz> +1

<mario_de_armas> +1 remove offer of sale from the critical path

<evanschwartz> +2 actually

dezell: we probably need a subsuming activity, “web commerce,” but offer is probably not part of “web payments”
… appears in the use cases
… second, this seems to be missing the value-add

evert: I’m mapping this onto the diagram

<Zakim> stefb, you wanted to ask for a dedicate slot on push-based payment

steph: should we have a deeper discussion of push-based payments?

dezell: I’ll put that on the parking lot list

Laurent_: +1 to start with payment initiation
… re 3 or 4-corner model, focus on the delivery of proof of payment
… so here, we should be careful to support both models
… so focus on payment initiation, delivery of proof

<Zakim> evert, you wanted to say VAS is not yet covered

evert: +1 to add step on value-added services

<Zakim> NickTR, you wanted to ask if q+ establishing the id/credentials of the parties is a precursor or part of this process

NickTR: establishing the id/credentials of the parties is a precursor or part of this process?

jheuer: payment agent I’m going to show offers one posibility, but doesn’t require specific position of the identification

NickTR: proofs may differ depending on identification
… “from check-out to check-in”

m4nu: put it in payment initiation

<dezell> ack mario*

[wseltzer says credentialing should include possibility of un-identified use]

mario_de_armas: you might provide credentials one time, then not have to repeat

<Ian> [IJ considers that “one time credential provision” is an optimization of “provide credentials before payment”]

mario_de_armas: instead of talking about txn flowing across consumer to network to merchant, talk about the data that’s flowing

<jheuer> Proposal: layer the steps: One for the whole transaction, and an optional recurring presentment and processing of individual process steps and credentials

mario_de_armas: think about the data flows more than the particular parties

padler: list reminds me of a slide from the FOCAFET deck

<Joseph_Lubin> Joseph_Lubin is Joseph Lubin

padler: once we get the list, we’ll need to prioritize
… what requirements will we have on the recipient of the payment? Payment receipt?

<dezell> dezell: “throw” and “catch” have a rich semantic here.

padler: think about on-ramp

<Zakim> padler, you wanted to suggest that this reminds me of FOCAFET materials

Erik: these steps don’t match the industry standard
… lots of these things are already documented; let’s use their words
… industry has many diagrams; let’s normalize

dezell: do you have a specific pointer?

Erik: I can provide those

<Ian> [+1 to sending us diagrams ]

Erik: we’re only 5% aligned

<Laurent_> +1 for sharing diagrams

steph: which diagram are we talking about ? we don’t need the same steps as e.g. interbank transfers

Erik: business processes don’t change too much with tech

[on screen: ISO 8583- Business Processes]

Erik: We should augment the diagrams, not replace them

CyrilV: 8583 is not industry standard

dezell: these are the kinds of business processes

<padler> +1 to Stephans suggestion that we need to come up with an additional layer that interacts with Payment layer…

CyrilV: 20022 is another standard. maybe we need a part that’s link to the Web

<steph> SCT: credit transfer? sdd: direct debit ?

CyrilV: the card system is not the only system

dezell: fair enough.
… let’s try to sidestep the noise between US and European banking system terminology

Erik: payment initiation is not a step, it’s a series of steps.

<Ian> +1 to concrete proposal

Chaals: Concrete proposals for change are helpful

jheuer: instead of alignment, embrace
… you need to support legacy, but not adopt their processes

padler: as we discussed at first meeting, need to choose the scheme at the beginning of hte payment
… we need to layer on top of whichever scheme used

<Zakim> dsr, you wanted to note that Manu’s framing omits coupons etc. as a step before payment initiation, but one that involves the payment agent/wallet

dsr: framing omits coupons etc. as a step before payment initiation, but one that involves the payment agent/wallet

evanschwartz: 2 most important things: choosing scheme/mechanism
… second, using the web to improve clearing and settlement. I’d like to talk about a task force.

jean-yves: payment initiation has important step, consent to payment

<CyrilV> 8Q?

jean-yves: EU regulation will apply to requesting consent, giving consent for payment
… VAS is on the side of purchasing, not payment
… are we confusing two kinds of payments?
… existing industry standards
… ISO 20022 is compulsory for EU payment service providers
… check if world-wide web compliant
… Delivery of information, whether before or after payments
… shouldn’t we have some info functions?
… can come at different places in the transaction
… legal requirements need to be a parameter

jheuer: … support a new tf on processing
… I’d propose layering: 1st describing the transaction, usually by the merchant
… inside, a loop of iterating steps
… which could include different kinds of transactions, e.g. loyalty cards
… thinking from experience with proximity cards

Ryladog: regulatory steps, including logging, reporting, auditing
… ensuring user control before commitment step, thinking about WCAG2

<m4nu> USE CASE: Logging and auditing for the purposes of jurisdictional controls.

<Zakim> evert, you wanted to say that 8583 and friends define interface messages between actors to fulfill the payment steps we identify

dezell: please write a use case

evert: if we get to a minimal model, we’ll get steps between actors, that will need to be mapped to several standards

<chuckles> [user confirmation sounds like a (possible?) step – in support of “user knows what they are payiing when they make the payment”]

<chuckles> USE CASE: Logging transactions for users who want to know where their money meant [like cheque book reconciliation]

evert: should we ask payment processors to support a number of APIs that support use cases?

<dezell> david: +1 to the idea of identifying actor(s) in each step.

<chuckles> [+1]

<Ian> (This corresponds to my comment from yesterday that I would like to have all the roles + verbs + data exchanged clearly written down)

CyrilV: Identify actors

[break: return at 10:50]

<dsr> scribenick: dsr

we resume after the morning break.

David notes that this demo is to introduce ideas, but nothing is baked, so please keep that in mind.

Payment Agent

Demo by Joerg Heuer

<CyrilV> http://www.iso20022.org/payments_messages.page# for dowloading xsd and PDF of explanation of messages delivered by ISO 20022

The demo involves a smart phone and a tablet. Joerg sets the scene. Some years back at Deutsche Telekom, his team started to explore what could be done with NFC, SIMs and the metaphor of cards for payments.

The smart phone displays a list of cards, discount coupons, loyalty cards.

Joerg notes that the demo in implemented in HTML5, and is inspired by the infocard idiom.

Picking a card is easy for users to understand and better for consent that alternatives like opting in and out.

A web page includes a graphic for a discount coupon based upon a JSON object.

Tapping on the coupon transfers it to your wallet.

Later when buying some products in a store, when you decide to buy, the wallet asks if you want to use the coupon you got previously.

The next step is to tap the phone to the point of sales terminal (represented by the tablet).

The user experience is very important to get right.

Chaals: the basic thing is that the merchant is talking to your phone, whether this is via NFC or HTTP doesn’t really matter.

Joerg: when we heard about NFC based payments, we were surprised that no one had yet included support for coupons and loyalty cards. When we created the demo, we got very good reactions.

Ian: how did you get the wallet on your phone?

Joerg: one answer is that I installed the app from an app store/operator etc. If you have the payment solution on the SIM, this necessitates the involvement of the operator.

Nick: can you provide a reference to the GSMA recommendation?

Joerg: yes

Chaals: if I have a wallet on my phone, I could conceivably do some steps to add my card to my phone. The phone can talk to the merchant to see which payment solutions the merchant accepts and then ask the user to select between them.

Joerg: we haven’t done this just yet, but yes, that is the general idea.

Joerg demo’s the use of a coupon which appears on the tablet (the point of sales terminal). The phone shows a list of transactions, green for success.

In this case that payment has been made and the coupon redeemed.

Joerg: we would like to maintain a log, where this is legally permitted.

Once you have the history, users want to see a what a given card has been used for.

Joerg switches to a online purchase use case. He starts by loading a web page on the smart phone, and selects the option to log in with his wallet.

Allowing the app to know about the wallet has privacy implications and would require the user’s consent.

The login may involve picking a card to act as a credential, and in principle, may involve a PIN or finger print scan etc.

Joerg: when you get the wallet for the first time, you would usually be asked for a user name and password as a means to get a club card for the online store.

Android handles the asynchronous notification of the “delivery” of the club card.

Manu: I have a question about data formats and protocols used to handle the process.

… What’s sent over NFC, what’s sent over the Web, what APIs, data formats and protocols we need to standardize?

Joerg: if this approach is adopted, DT would help with that work.

… I hope we can find a home for this sort of approach, and we’re talking with Mozilla …

Manu: is the exchange over NFC the same as over the Web?

Joerg: absolutely not. We want to use the existing standards for each context.

<Zakim> m4nu, you wanted to ask about the messages and protocols being used.

Joerg: if there was one way to do things around the world, that would be great, but we need to allow for the differences.

Chaals: what you have is a fancy password manager that actually interacts.

Joerg: we have an abstraction for secure storage.

Chaals: in theory I could put in a card for my facebook account, right?

Joerg: yes.

<dezell> ?

You could be an issuer for the cards that you control.

… It has broad scope from things requiring low security to things that require really high security.

Joerg describes a scenario with a PC. The app creates and displays a QRCode on the PC screen which you can scan with the phone to invoke the wallet on the phone.

The phone can then authenticate you to the website for the app on the PC.

<Erik> NOTE: Very important. Cross device and on device use cases for payments

Joerg: this could support card present transactions using the card in the phone.

… We are agnostic as to the communication technology e.g. NFC or Bluetooth.

YY: FInancial institutions may want to create their own UX skin.

Joerg: yes indeed.

<Ryladog> USE CASE: customised (e.g. branded) UI for payment instrument found in the “wallet”

Laurent: is it really necessary to tie authentication to the web site to the payment experience?

<Ryladog> Additional info for USE CASE: Financial providers or merchants could provide their own skin for the PA

… some concerns over privacy and what info is made available to the merchant.

Joerg: this is all about UX that enables people to easily understand what is happening at each step.

I think this approach is a good fit for what W3C could standardise.

Consider what I have done as a strawman for consideration (points to the figure in his presentation at TPAC2014).

This involves a modular set of plugins for different cards.

The wallet is controlled by the user, and the cards by the issuers.

The approach works when the device is offline.

<sboyera> :nick steph

… Some features however, may require the device to be online.

Stephane: I like the diagram, but I am missing how to fit it into the payment transaction and the role of the browser, e.g. when does the browser invoke the wallet.

<wseltzer> Pat’s diagram

Pat describes his diagram illustrating the wallet interfaces. We’ve separated out the application layer from the server layer

At the top of the picture there are a number of components such as display, touch, fingerprint scanner, …

Pat explains how the wallet could be split across a local app on the phone and components on the server. This allows for offline operation with subsequent synchronization.

Some key examples of plugins include a POS (point of sales) plugin.

Joerg: we’re not yet through with the design, and this group could help to refine it.

(more details at https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force)

Pat: please don’t hesitate to provide us with feedback!

David: the reference UI shouldn’t be part of the wallet core.

… this is starting to look like a web centric solution as opposed to a hardware centric approach.

<Zakim> dezell, you wanted to ask about UI separate from agent

Laurent: Can W3C specifiy on device APIs? (as a W3C newbie)

… for data formats, I expect that to be yes

David: this is touching on a hot debate. Does it necessitate the involvement of browser vendors or not?

<Ian> [W3C WGs have dropped Web Intents -> http://www.w3.org/TR/web-intents/ ]

… should this be part of HTML6 and how do we convince the browser makers?

<NickTR> i want to be in the meeting next door

Joerg: today we need to rely on specific browsers.

Laurent: can you enable native apps to invoke the wallet?

<AndersR> https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/0000.html

Pat: certain capabilities can only be accessed from the local device

Joerg: this could defined by other orgs than W3C, e.g. GSMA

… we’re working with Firefox OS which provides a means to access NFC from JavaScript. On Android, we need glue code to bridge the gap from the web run-time to the native NFC capabilities.

I just want to standarise the minimum, the rest should be left for innovation by platform providers.

<Zakim> NickTR, you wanted to ask if payer and payee both have payment agent?

<Ryladog> Should we add ‘inner-agent APIs’ to glossary?

NickL does the payer and payee both have access to the wallet?

… right now the payment agent looks like it is controlled by the payer and not the payee

Stephane: how do you install a wallet in your web browser, and how does the merchant invoke it?

What do you see this group working on? The interface between the wallet core and the payment solutions for sure.

<Zakim> sboyera, you wanted to reask the same question no news on install/invoke

Joerg: we want to update this payment agent wiki page, please join the payment agent task force to help us do that.
… right now we’ve used different approaches for invoking the wallet on different platforms, but yes a common approach is desirable.

<Zakim> m4nu, you wanted to mention standardization around data formats, protocols, User Agent APIs, and REST APIs.

Manu: I think there are 4 things the payment agent is doing. data formats for receipts and payment request, the protocols involved, browser APIs (e.g. that the buy button invokes), and finally, the REST API definitions.

David: I agree with Manu. I want to focus on the web server as an abstraction for the payment agent that can be accessed from the browser using existing standards.

(modulo the use of CORS)

<Zakim> dezell, you wanted to say one more thing about devices.

<Vinay_Gupta_E> +q

<m4nu> +1000 to Evan, we need to have Payment Agents online at all times (we need to support that as one mode of operation)

Evan: One of the use cases we need to discuss are pull payments and subscriptions. This is needed for services that need to get money from me, so there needs to be a way for services to discover the end point (the URI for the server).

<sboyera> +1000 to evan, we should not consider user-agent interaction

Evan: we need some agent representing me that is always online. We should not standardise too much.

… we need to make it easy to adopt new solutions without waiting for new standards to be developed.

The interface that needs to be standardised in the one that other people need to access.

Chaals: I would like to disagree with Manu. W3C prefers to focus on data formats and not on protocols. We need to allow for flexibility in the underlying transport, e.g. NFC, Bluetooth, monkeys …

<jheuer> No problem with Evans concept – but not to replace the current notion of a UPA unless we found a new name for it and, thus, ‘user payment agent’ might be free to be used in a new way

We *do* need to standardise the APIs and the data formats

… We should focus on the use cases that helps us figure out what the requirements are for these from real world examples.

We will find the need to support offline payments (lots of colourful details elided)

<padler> this is where the micro-web might help… two users running a wallet can do an NFC to NFC push payment W/O being connected to the larger web…

<Ian> [Back to point from yesterday: design goals are important or solution constraints like “must work offline”]

<padler> ex. for stored value credit pushes…

<CyrilV> who grasp all, lose

Chaals: the payment transaction can be commited to offline, and finalized when the devices next go online. This is important in the real world where you can’t rely on being online all of the time every where you are.

<padler> msg/ CyrilV In the US we say “A bird in the hand is worth two in the bush” :o)

Chaals: we don’t want to constrain the implementation any more than strictly necessary

David: in summary, I am excited about modularization and payment protocols, and the important point that all of this needs to scale.

<chaals> [my random prompts for me: probably data format, APIs are part of the work we have. W3C doen’t do a lot of protocol, and tends to think data formats can be protocal-independent… Use cases that explain why the API needs to work on browser or in cloud or… minimum constraints on interaction with the agent such as accessibility but live at a separate level… offline has to work – always online is too constrained for reality]

<wseltzer> scribenick: evert

<scribe> scribenick: evert

dezell: most of today further dedicated to the payment agent, and next steps for roadmap

… before we do the roadmap, let everybody express 2-3 items as a short term outcome

… things for next 3 months

… JY will give information of regulatory items to be considered

… tomorrow pick up one use case for detailed analysis

Manu: suggests to take 4 use cases (not too deep)

David: to be decided tomorrow

Erik: Try to explain what a “wallet” is. Shows presentation.

… BIP 32 wallet, wallet is a tree of identifiers

… elliptical curve cryptography, computer generates random number as a key.

… Derive further keys for different acounts from the master key

… derive keys for ID/login, sending payments, receiving payments

… brand new key for every transaction

… when a single key is compromised, the other keys are not harmed

… chain of identifiers. The masterkey must be protected “at all costs”

… key storage on a secure device, which may communicatie via NFC

… can also be installed on a secure element.

… the master key enables the key chain to work

<jheuer> q*

… digital signatures, identification etc to be signed with keys from the chain, not the root key

… wallet is nothing but a tree of identifiers

… Shows a hardware based wallet, protected by biometrics

<padler> All… I just added an updated zoom in on the concept Erik is discussing related to the last wallet concept here -> https://www.w3.org/Payments/IG/wiki/File:WalletDetail.jpg

… What is a financial identifier?

… This concept can be used with any credential, encryption requirement etc

Ryladog: privacy : this would be personal financial information related

Erik: Trace back is not possible

… technology is part of FIDO alliance

<m4nu> +1 to key derivation

Jheuer: interesting view. Important to look into the impact of ‘device binding’

… if a credential requires a certain device to be authenticated

<m4nu> +1 to supporting newer crypto mechanisms such as Elliptic Curve and others.

… than the credential is bound to the device, cannot be used otherwise

David: you can use this to protect a chain of coupons for validity

Jheuer: finds the use of the term “wallet” confusing.

… wallet is a term where people have a definition for already, pre-empted

<padler> we need a code name for the wallet… maybe project “Costanza”?? 🙂

… the user payment agent is the connection between the network and the user

… be clear when to use the term “wallet” and “user payment agent”

… to use “wallet” for this key-chain? (sighs)

erik: this stuff is in the industry, exists already

… used for identifiers – for which the purpose still must be defined

<Laurent_> +1 on not relying on one source

<Zakim> dezell, you wanted to clarify wallet vs. payment management application

dezell: “payment management application” – is an extremely thin wallet, a credentializing system.

… isolate things on different levels

… does the bracelet constitute 2 factor authentication using biometrics?

Erik: can be 2-factor, or quasi 3-factor

dezell: will it also create a cryptogram, check signed input?

erik: you can use it to sign transactions etc

… private key will be kept on the secure device

<Vinay_Gupta_E> +q

ryladog: see the identifier-thing in the “PMA” payment management application

… this component in the credential box

… what is the effect on ledgers?

pat: explains the effects so fast that I can’t cope : )

<Zakim> m4nu, you wanted to support Elliptic Curve and Derived Keys in general.

manu: +1 to use cryptographic tools – should be looked into

… digital signatures add tremendous value

erik: technology is to be NIST standardized

Vinay: curious about the interface, how do you know what it is you are signing?

Erik: similar to a case with walmart with NFC collisions

… Evert can show a ‘what you see is what you sign device’ used by Rabobank

… enforce a one step user confirmation

Vinay: payment agent relying on the hardware token

Laurent: concept seems somewhat disconnected with the web payment. Use cases must be taken further to evaluate

<Ian> +1 that we should focus on the requirements than the solutions

… bit too soon to decide on the type of crypto required right now

… leave it to the working groups

<Joseph_Lubin> Joseph_Lubin is Joseph Lubin

… would love to use smartcards, but not yet clear at this point in time

<evanschwartz> +1 too soon to decide on particular crypto schemes now

pat: jurisdiction may define requirements for crypto

<Ian> scribenick: Ian

<m4nu> evert: As an example of what Rabobank uses for consenting with transactions (holds up device)

<scribe> scribenick: m4nu

evert: We have these crypto calculators – we forgot five digit code required to activate the device. So we moved to cards – standard EMV technology.
… In the latest iteration, it contains a camera – it communicates a color QR code that has a signed message from payment processor which is the bank, saying what you are going to consent to.
… Nobody can sit inbetween your transactions – it’s a nice evolution, it’s not free – we issue 5 million of these devices. It’s worth it because of all the man-in-the-middle attacks get a bit too much for us.
… So, for web payments, electronic transactions, this is where we’re headed.

<evert> Laurent: the term wallet for the secure device seems to be a bit specific

joseph: I think it’s important … that you can take a seed and a master device and generate subtrees. You can be locked into a separate hardware wallet if you need it to – lock in isn’t a big concern.

<padler> +1

<evert> Joseph: you can move to any type of hardware device. That will not make it a wallet, as people from bitcoin suggest

<evert> … centralization: this is a user defined way of storing tokens of identification which may be used for authentication etc. Excellent for a decentralised approach

<evert> pat: identitiy use cases as a way to get adoption. interoperability is an issue

<evert> erik: wallet as an identification factor?

<evert> joerg: wallet is an intermediary

<evert> dezell: presented as an example, not as the single way to do things

<evert> cyril: the user interface should be protected

<evert> … the wallet can be the combination of the card and the card reader as in Evert’s example device

<evert> … the wallet is not only the credentials

<evert> dezell: how much time do we need today to finish the UPA discussion?

<evert> joerg: we might need to split up in smaller groups to progress faster

<evert> … go through wiki contents

<evert> … to feed back in the roadmap document(in the end)

<evert> Ian: suggests to look into changes rather than getting on with demonstrations

<evert> joerg: inventorize required changes and applying these later offline

<evert> … most important will be the retrospect of the phases

<evert> … bridges we need to build between the use cases

<evert> … UPA, PMA – how do you come to the right name in w3C?

<evert> Ian: people write proposals, put in wiki, and vote

<evert> joerg opens the user payment agent wiki page

<evert> … a “storage area” for all what is discussed, not yet a good readable version

<evert> … created a new page

<Ian> Payment Agent Task Force wiki

<evert> … took a few of the inputs to create a new structure for the page

<evert> … high level overview, scope / key concepts / features

<evert> … lay-out still to be reviewed

<evert> … high level overview to explain the overall topic (based of Pat’s figures)

<evert> … editing / contribution can be done on the wiki

<evert> Ian: discusses diagrams on the flipchart (which I can’t get in the irc 🙂

<evert> Ian: sees a “bunch of stacks” but these do not tell a story

<padler_> for q+

<wseltzer> https://www.w3.org/Payments/IG/wiki/User_Payment_Agent_Task_Force

<evert> … must be able to walk through it

<evert> Joerg: diagrams from the old page must be drawn new, terminology has changed

<evert> … high level overview seems ok

<evert> … Scope of the User Payment Agent

<evert> … specific things to standardize (interfaces, protocols, api’s)

<evert> … we need to be really clear what picture we use

<evert> …need to have the boxes to discuss the interfaces between them

<evert> Pat: after doing the roadmap discussion, we can prio work, what details must be defined

<evert> … start with a very simple interface, with just one interface

<evert> … expand on that later

<evert> Joerg: use cases tell the story of the architecture – and vice versa

<evert> … not easy because we have to touch on the use cases again

<Vinay_Gupta_E> +q

<evert> … concerned about the clarity of the user view as we get to deep in just a collection of functionalities

<evert> … describe a meta date structure in a tangible way for the user, so it can be shaped by implementers

<evert> Vinay: gets to sketch something on the flipchart

<evert> … 3 fundamental models

<evert> … XML / EDI mesh on lowest level

<evert> … on the other end: JSON structures with signatures which is processed.

<evert> … simplest thing which could possibly work

<evert> … somewhere in the middle, a series of messages back and forwards, negotiating steps between actors

<evert> … it might help to name scenarios of these types

<evert> … to identify nomenclatures of different architectures

<jheuer> New UPA – wiki:https://www.w3.org/Payments/IG/wiki/User_Payment_Agent_Task_Force

<evert> … other point: crypto currency, VAS can be linked on the (top) model after “payment consent”

<evert> joerg: some problem when provisioning security elements for creditcards

<evert> … drove to get to a meta data structure to get to a different user experience

<evert> … could add a greyed out card which gets active after all steps are completed

<evert> … inform the user with a “token” of the fact, e.g. that the requested card is under way

<evert> … decouple user experience with the way how it is processed in the back end

<evert> Vinay: informed consent and fulfillment as different categories?

<evert> dezell: can we agree upon groups of api’s and data structures with these api’s

<evert> … use cases are abstractions (as one definition) of real life scenarios

<evert> … modeling these is the work we have not yet done

<evert> … if we put the actor and subject names consistently

<evert> … ooand done right, verbs and objects, to agree on

<evert> … distinct connection between the modeling suggested, use cases and protocols/api

<evert> Vinay: feels we are slipping down the architecture

<evert> dezell: that is why you need to do the use cases first

<evert> … a little ahead of the game with this discussion

<evert> <break>

<dezell> https://www.w3.org/Payments/IG/wiki/User_Payment_Agent_Task_Force

<Ian> scribenick: evanschwartz

<Ryladog> tt

David: discuss the high notes on what is relevant from a regulatory point of view, then we’ll do the 2 short term points everyone would like to see, then begin to revisit use cases
… also supposed to begin outline of roadmap

Jean-Yves (JY): What are Payment Services?

JY: Regulation matters because in most countries payment services are regulated, depending on service or role requirements are triggered automatically
… need to keep in mind key rules and try to draw guidelines to integrate into roadmap
… people understand the word payment but it’s more complicated from a legal perspective, “payment” in everyday life is different from the commercial/banking sense
… In most jurisdictions e-payments are “payment services”
… Should we call our IG the Web Payment Services IG? Open question
… Merchants and Payment services: depending on implementation (legal and technical), many use cases could be outside regulatory requirement fields
… in EU merchant is not providing “payment services” when invoicing and being paid, as long as it’s for themselves
… now in EU market places must comply with PSD2
… a merchant is not offering “credit” when it allows payment facilities to the debtor, easy terms of payment could be improvement for merchants and customers
… prepaid instruments are not “payment services” if they’re for one or a small number of merchants
… Payment service providers: acting as financial institutions, should be cautious not to confuse them with banks or payment processors
… in some countries banks are the only ones allowed to make payment services
… payment processor is techincal agent, subcontractor of payment service provider or bank
… in some jurisdictions payment processors can do whatever they want within AML and consumer protection laws
… Banks / Non banks – in EU bank is credit institutions, means taking deposits and making loans, money belongs to the bank
… other payment institutions are PSPs so they can transfer funds, accept or issue payment instruments, but they just “transit” through them, they never belong to the PSP
… some use cases we are discussing include regulated functionality, supervisory authorities are trying to make regulation more effective around the world, AML is a global priority
… some current trends include keeping records of sensitive payment data require PCI-DSS compliance, in EU under PSD and PSD2 some functionality will be strictly limited to regularly authorized PSPs only, including some functions we have described in use cases
… PSD2 will mainly apply to authentication, access to payment instruments, begging consent to payments, access to settlement systems, issuing e-money or prepaid accounts for general purposes, acquiring payment orders on such instruments, transfering and debiting payment accounts
… in EU if you comply with requlations you’ll have access to all settlement systems
… regulatory jurisdictions determine what kind of services should be regulated, who can provide services, what are the services/roles/functions are outside regulated activities

<Zakim> Ryladog, you wanted to keep ‘user’ in the name of the payment agent/tool/app so that the primary reason in my eyes

<evanschwartz_> Pat: when a transaction starts it creates a definition about what details need to be captured, you know what jurisdiction the payer or merchant are in

<evanschwartz_> scribenick evanschwartz_

<evanschwartz_> Pat: regulation today is after the fact, smart contracts could be built in so that regulators could authorize payments before they flow, small banks get requests for paper records and regulators are swamped under loads of paper

<floris> * legal clearing services require interpretable transaction data and information on relevant jurisdictions in the transaction

<evanschwartz_> Vinay: in south-south trade there are huge identity requirements for payments, especially because of absense of payment instruments and micropayments

<evanschwartz_> Pat: could be informed of reg requirements when you initiate the payment

<evanschwartz_> Cyril: there’s regulation and also payment schemes, including the contractual frameworks between banks and schemes like MasterCard, contracts are different with Visa, direct debit, parties need to know beforehand which scheme they’re going to use to determine what data is needed

<evanschwartz_> Cyril: it is the job of banks and PSPs and scheme managers to define good rules to coordinate with regulators

<evanschwartz_> Cyril: web payments should organize schemes so that you don’t need bilateral relationships to send payments between countries, cryptocurrencies could even be considered schemes

<evanschwartz_> David: ISO 12812 working on Mobile Financial Services, this will start appearing in legislation near you, defining “mobile financial service provider”, that should be no different than web PSPs so we should tell them that

<evanschwartz_> David: they talk about secure element, calling it “trusted execution environment”

<evanschwartz_> Tim: actually “secure element” + “trusted execution environment” = “secure environment”

<evanschwartz_> David: also includes consumer protections. We should figure out why ISO would want to create a new financial service provider and push our comments in their direction

<Zakim> dezell, you wanted to mention ISO12812

<evanschwartz_> Katie: some laws have connection to whether there’s a physical business, people want distinction to go away

<Zakim> chaals, you wanted to ask for clarification on how only PSPs being able to do payments, means there is nothing for us to do… and to ask if the differences are generally more or

<evanschwartz_> Chaals: If only PSPs can do payments and there’s nothing for us to do, it seems like that’s not the case, PSPs might appreciate us or people could become PSPs

<evanschwartz_> Chaals: if PSPs in the EU want to work with unregulated PSPs elsewhere then they might be interested in working with us, we might want to get EU regulators in the room. Also do you have a sense of whether the regulations are compatible?

<payt> +1 😀 welcome to the team evan!

<evanschwartz_> JY: at this moment when everyone is seeking new common language to operate it’s a good opportunity, one of the major risks is to just stick to one scheme even if it’s ISO

<evanschwartz_> @manu, i’ll make sure to take worse notes next time

<chaals1> [We should be looking for e.g. EU regulators to paticipate in the discussions *anyway* – but that’s a discussion for tomorrow]

<evanschwartz_> JY: someone will end up driving new regulations and standards but that’s where the W3C can help standards to be worldwide

<evanschwartz_> JY: my hint is that there are a few key points we have to be really aware of, especially AML, because that has strict requirements in every country, the other point will be around authentication

<chaals1> [AML – anti money laundering]

<evanschwartz_> Laurent: propose that we sidestep the problem in the short term by leaving this in the extensibility part of the spec, identify the things that are heavily regulated like authentication and leave that in the part that is scheme specific, focus on interoperability of the merchant talking to a fleet of user payment agents, delegate responsibilty to complying with regulations to user payment agent, from experience we could spend years on regulatory [CUT]

<evanschwartz_> Laurent: it’s a nightmare by design, US proposes something and EU thinks it’s crap

<chaals1> USE CASE: Susan lives in South Africa, but her mother in Norway passed away and left her the family home. She wants to sell it and bring the money to South Africa, and finds a buyer in Canada…

<payt> we could call it the “Paradigm Agent” LOL

<Zakim> m4nu, you wanted to ask where we put the “regulatory overview” table?

<evanschwartz_> Manu: where are we going to capture the document laying out the regulatory mapping exercise? roadmap or use cases?

<evanschwartz_> Chaals: Sounds like we make a document, and use that to generate requirements which we add to the work we’re doing right now

<evanschwartz_> Erik: need to capture what the regulated points are going to be, going back to bitcoin world the discussion with FinCen was with multi-signature, pushed Ethereuem to come on board to use smart contracts, want to use multi-sig to bring regulators into the loop, want automated reported on the payment service provider’s side

<evanschwartz_> Erik: when it comes to consumer protection, it’s going to hit us like a runaway truck because we’re going to be privy to consumer data

<evanschwartz_> Vinay: huge overlap with identity issues, most regulatory issues come down to knowing the customer

<payt> it’s not so much that the regulation needs to be implemented off the bat… just that there needs to be a “plugin” to Laurents suggestion that there should be a way to “plug-in” regulation notifications / processes once the key data about the transaction is identified (ex. location, tx value, etc)…

<payt> it is a big space, however, there are a relatvely low amount of data elements that are required across the different regulatory “schemes”…

<evanschwartz_> Jeorg: also try to talk to privacy people, lots of them in the EU, a lot of this would be a huge step forward for user control, might be easier to change a few regulations

<NickTR> The regulatory issues are, for me, business rules applied to data elements as a function of the identity of the actors (where identity includes attributes of location/appropriate regulator)

<chaals1> scribe: chaals

short term outcomes…

DEzell: Want to see published last call for use cases doc, analysed as discussed by Vinay, making Ian happy, and categorised so we can work out our requirements.

Ian: Want to see the stories driving this work clearly articulated. Some nice diagrams and consistency in teminology, so people can understand what we are doing just by looking.

Laurent: To get into the trenches especially what happens when you click “buy” on the browser.

… how do we get a WG working on that ASAP

Mario: Want to see the data formats for use cases, to identify consistency and exceptions.

Joseph: Lots of diverse tech. around the table. Want to see listing of the technologies and what they do. (and don’t). And a set of the use cases that everyone can handle.

Floris:

… iprovements in the knowledge model. There are good ideas, but inconsistencies.

… will ask my people to help.

ss/iprov/improv

Evan: Opportunity is to unify the value networks of the world.

… want to see some exploration of what it would take to make that happen and what W3C’s role could be.

<sboyera> emvco

PS: Want to see the use cases documented, to what extent they are relevant to EMVCo…

… if that’s positive, how can the two groups work together?

Vinay: What’s the simplest thing that could work? Would be nice to have a good grasp of that.

<mario_de_armas_> +1 to simplest thing that could possibly work

… The first milestones should be the simplest thing, and then a notion of the sequencing in the roadmap.

… There might be less work than we are afraid of.

<CyrilV> i’d love to see detailed flows with actors associated with responsabilities, in order to be sure to comply with legacy schemes (card, v.me wallet, SDD, SCT, SEPAmail)

<Ian> +1 as well to starting simple use case (to be decided by consensus)

Cyril: [as noted by Cyril – thanks!]

Steph: Divide and conquer. Identify the sets of independent blocks so we don’t mix the discussions together and get lost. Push payment, Pull payment, Identity, …

… so we can move on each independently

<evanschwartz_> +1 on dividing and conquering but I’d argue that the split is probably between payment and clearing/settlement

Pat: Building on that… further refined version of big picture architecture to identify what we can usefully build and work on in parallel.

… Don’t want us to get bitten by missing out a key piece because we didn’t understand overall needs.

Eddy: Flesh out use cases, see how they might apply to Visa, see what is in scope for the group

<dsr> Dave’s short term priorities:

<dsr> Published use cases and high level requirements

<dsr> White paper setting out vision, assumptions, priorities, and relationship to other groups as a means for reaching out to stakeholders globally

<dsr> More proof of concept demos

<mario_de_armas_> to evan: I think that the break down should be 1) authorization, 2) clearing & 3) settling

<Ryladog> SHORT TERM: Clear Use Cases document. NEAR TERM OBJECTIVES:….mine are really long term…. Provide users with an easy/intuitive secure interface (and framework) to empower them to control and determine with whom and with which payment vehicles/instrument they wish to use to participate in commerce/acquisition for all aspects of their lives. Can cover management of funds, funds for daily needs (food, utilities, supplies for home appliances), for medical an[CUT]

<Ian> scribenick: Ian

<scribe> scribenick: chaos

<m4nu> chaals: I want to see a bunch of stuff – I want use cases document well advanced.

<m4nu> chaals: I want to see some legal framework analysis taking shape

<m4nu> chaals: I want to see an explanation of how the payment process works.

<m4nu> chaals: If we get that far, we’ve done a reasonable job.

<m4nu> chaals: I also want a pony.

<chaals> scribe: chaals

Istvan: Want a unified standardised payment solution allowing anyone to be able to plugin. SOmething tangible delivered. Some predictions on the roadmap.

i/chaals: if we get/chaals: a pro-tem statement of what we think success looks like (i.e. scope of work)

Bernard: Expecting the group to have a growing number of participants and clear message. That leads to lots of new members… Seriously now: Make sure you bring the right people to this table.

Jean-Yves: Understand how W3C can solve the complexities we are facing. Dream that we choose some use cases and start implementing some solutions with a common vocabulary, consistency checked with other standards in industry, to deliver a first proof of concept.

Manu: Publish FPWDs of use cases, roadmap, payment agent document.

… these will let us explain our work effectively to the people we want to bring into the work.

<NickTR> I want to see good definitions of the actors and their interactions at a sufficiently generic level onto which we can then map the multiplicity of “real world” examples

<mario_de_armas_> +1 we need a d ocument that we can shop around

Nick: definitions of the actors and their interactions, at a level where we can map all our use cases into that. That picture is what we need to explain ourselves.

<evert> Limited, basic set of use cases and interactions between well defined actors (roles) for API design and data models,

<evert> Good separation of “kernel payment functionality” and “purchase related functionality” not being the payment itself

Evert: Limited set of base use cases. Interactions between the actors explained. Spearation of core payment and purchase-related payments.

Joerg: More people actively participating. Well-aligned big picture explanation, pattern description. Identifying the standardisation items.

… For long term, make the digital world a bit more transparent and secure, and W3C should digitise the rest of the world.

Wendy: See us headed toward sending work to an existing WG, or chartering a new one. That would indicate that we had got the foundations in place.

… Privacy pervasive through use cases and discussion.

<Erik> Erik Anderson and my views of the next 3 months.

<Erik> – Realistic expectations. SWIFT was built in the 70’s and we cant change the world in 3 months.

<Erik> – Published initial working draft of use cases that are implementable (not theoretical voodoo and targeting what we can standardize and what we cant)

<Erik> – Published Road Map for the 1st and 2nd phase and breakdown of building blocks in the roadmap

<Erik> – Play well with others (ISO, Glossary, Reuse of existing standards)

<Erik> – Identify the road blocks

<Erik> – Identify the regulatory points

<Erik> – As a chair I view my role as bad cop, good cop, and a bulldozer to help remove road blocks

<Erik> – When we all go home to our day jobs please continue this efforts forward

4 February

White Paper

Pat Adler: Start with audience, goals, what we want them to take away, length

m4nu: Keep the doc high-level. It typically does not work to try to address multiple audiences. Will want to address Web developers, executives at orgs
… includes people high-level in payment industyr
… but may not need to address implementers of these systems (since not detailed)
… this document should speak to orgs that we meet when talking to potential participants
… so white paper could be a 1-page summary of what is going on.
… this executive summary would be different from a roadmap (more of a plan)

<Zakim> m4nu, you wanted to mention who the intended audience is…

padler: Could be multiple docs e.g., one for execs, one for developers
… one could be business speak, the other for devs

(+1’s around the room)

m4nu: Concerned about multiple docs (multiple editors, review cycles)

stephane: I’m not convinced we have anything for devs today (since high level). I think we should emphasize exec level
… this doc should be a marketing document to convince those not here why they should be here since relevant to their work
… for me there is a notion of vision (white paper) and prioritization (road map)
… I think the document should have both
… I think we should surface the concepts of push/pull
… rather than 3-corner and 4-corner

Erik: We need the executive summary first (to ensure we have all the people in the conversation) but you also want some architecture documents so that people can determine where they fit in
… we need this exec summary quickly

padler: Would you think of two docs / 1 2-pager (1) exec summary (2) architectural picture

ach chaals

<Zakim> chaals, you wanted to say Roadmap isn’t the same as “white paper”. We should track articles written on our webpages, and write more of them. But not even try to co-write something

chaals: I think this work item is a “stupid idea”. It’s hard to work on a document between 40 people.
… we could have 40 people write 1-page documents (of various depths of detail)
… and then instantly we would have 40 document library
… we could start collecting those pieces
… I think that’s a more effective use of our time…we’d publish all of them, and when you speak to people you can point people at selected works from the library

Erik: risk of mixed messages.

Chaals: But we will have mixed messages since there will be 40 of us. We are trying to produce one standard, but it’s not clear that we need to come up with 1 message

padler: Where would docs be available?

<NickTR> +1 for Chaals’s whitepaper hailstorm

chaals: In the wiki (or linked from it)

padler: I’d like to have something to print out on glossy paper to hand out

<jean-yves> +1 for Chaal’s approach

chaals: I think there will be N different dev hooks for N different devs
… I also think that writing 1 doc for 2 audiences is harder than writing 2 documents

<Zakim> dezell, you wanted to talk about target

dezell: Intrigued by chaals’ idea.
… so I’d like to focus on content and what we’d like to say

(Pat shows original outline on screen)

<dsr> scribenick: dsr

<Zakim> Ian, you wanted to show mobile roadmap

Ian: a few things to suggest –

<Ian> http://www.w3.org/2012/10/tvandweb_salesheet_online.pdf

<stephane> -1 to marketing sheet only

<Ian> http://www.w3.org/2015/01/mobile-web-app-state/

W3C Commuications Team has produced glossy one page sheets on W3C initiatives see above for link to an example. Just enough info to set the scene and tell people where to find more. The W3C Business Development Team have found these useful for recruitment purposes.

<stephane> +1 to dom’s roadmap

The second thing is a detailed roadmap setting out how W3C is making progress including the specifications. Good example is for mobile produced by Dom (see link above).

The W3C Advisory Board would like this kind of roadmap to be produced for all of the W3C “Verticals”. Ian thinks it would be useful for payments but could be premature.

The 3rd thing would be short periodic updates on the IG’s progress. We used to do this for the W3C Technical Architecture Group.

David: could you please provide a link?

Ian: sure, later.
… I very much like Chaals proposal that individual write down and share their thoughts, even just as emails.

It is one thing to have a plan, and at some point we should have a plan, at least as soon as we have a clear idea of what we’re going to do. We should be able to sequence the topics we want to address.

I am curious whether Stephane would object to a high level description

<Vinay_Gupta_E> +q

Stephane: I think we need to go deeper and it is more than just marketing. It should make clear what the role of this group is relative to others.

Erik: people always look to see if their competitors names are listed …

<Ian> +1 to people blogging

David: we do have a blog and this is a really good place for people to post their thoughts. It doesn’t have to be long, and could just be your experience at a conference.

<Ian> http://www.w3.org/blog/category/w3cqa-news/interviews/

<Vinay_Gupta_E> interviews +1

<Vinay_Gupta_E> it’s a great format for getting good, clear explanations of things fast, through dialogue vs. the hassle of trying to write it cold

Ian: in my head of Comms role, we had a series of interviews, and one is due next week following this meeting. I would like to speak to you all individually as I will now need to focus my time on payments.

(see W3C blog for examples)

<Ian> scribenick: Ian

Nick: +1 to having people write their ideas down
… as far as 3/4 corner and push/pull, I think we don’t have the detail enough yet to speak about implementations, but speaking the language of the industry is a great way to rattle the cage

<dezell> For blog posts to this group, see https://www.w3.org/blog/wpig/wp-admin/post-new.php

katie: We are making this more complicated than it needs to be. You need an exec summary that talks about issues, current state, and what we plan to do about it.

<m4nu> +1 to Katie – executive summary should be – this is the state of the world, these are the problems, this is what we’re going to do about it.

katie: the basic document is then translated into “speak” for other audiences… current issues and our plan to do something about it
… we have to have a central belief in what we are doing….

<mario_de_armas> +1

<m4nu> +1 to Nick – we need to have enough to whet the appetite of payment industry folks – perhaps a payment industry specific executive summary?

Laurent: We need to include a bit on “Why W3C” in the materials.

<m4nu> +1 to Nick, why is W3C the right place to do this work – we need to make this very clear.

<stephane> +1

<chaals> +1 for translations – equally, into languages spoken by people who are more comfortable with payment technology than with english…

cyril: For me, the ambition of this initiative is to promote convergence of web and payments industries
… in the IG today we have a lot of web industry innovators…I do see visa and emvco and some “legacy” folks. 🙂
… this is part of the “why w3c” story

<Erik> +1 kate. Create the executive summary but allow individual contribution documents. IMO, executive summary should be about how web (aka public internet) applies to payments

Cyril: I think the group should try to get the legacy payment industry more involved (e.g., european banking authorities). If they are outside, we will not see the desired convergence.
… I think it’s important also to try to convince people in the payment industry to join the group and bring their knowledge to the conversation
… so I think the executive summary needs to be inclusive of all payment models used today

<jean-yves> +1

<Eonaga> +1 Cyril

<Zakim> evert, you wanted to say to identify market requirements (gaps) to be fulfilled and possible effect on business model

evert: I think we need to get the current industry to understand what current needs are that are not fulfilled, and why an incumbent needs to move (and fast)
… a clear message on that would help me and other banks

<mario_de_armas> +1 we need to answer why would an incumbent move

evert: what markets will open up and what companies are at risk of missing

Floris: Framed as “opportunities that will be missed”

Joseph: +1 to Nick’s comments. I like Chaals’ idea…I think 40 docs will be daunting for all but the most intrepid reader. But for a diverse community like this, a top-down process will be unmanageable. So bottom up is a better approach.
… And on top of that I would layer a single white paper
… so a few of us could read the 40 docs and synthesize

<Erik> +1 to sourcing information (base of the pyramid)

Joseph: I also like the high-level marketing approach

[Break for photo]

<Zakim> m4nu, you wanted to mention that we have another roadmap-ish document.

m4nu: I am hearing two things (1) get our marketing and messaging in line. +1 to chaals divide and conquering yet. But I am still concerned about not yet having marching orders.
… I think the roadmap document is more than 1-pager. We need a vision and how we are going to achieve the vision. That can’t be fragmented. We need to reach agreement on goals and how we achieve them
… so we need probably more than 1 executive summary (series of quick read high-level). But the roadmap needs to go into goals, aspirations, and how we will get it done.
… the latter will take more time to produce than the former.

Vinay: A quick and easy thing to do after the meeting would be to do online dialogs…interviews of each other on specific topics
… exploring not just conclusions but process conversations…would be easy to draw in others

dezell: Candidate topic?

Vinay: push/pull for example
… I think dialogs are more interesting than monologs

Pat: echoing back what I am hearing
… there is not “one roadmap” but rather we need a communications effort/strategy

<wseltzer> Group Photo

Pat: while I agree with Charles that more incremental/regular and specific updates are good to show credibility
… I also find useful the quick marketing handouts
… and I like the interview idea as well
… we can refine the mission/goals of the group now that we are getting up to speed…
… maybe there’s some value of that outside the charter
… so trying to crystalize our view of our work now that we have more participants

[+1 to getting flow of content from multiple participants since that will keep us all interested and show health as a group]

Pat: New task force on communications strategy

<dezell> ack mario*

mario: +1 to Katie’s comment that we are making this harder than it needs to be. And +1 to Evert comment about getting legacy to move.
… we’ve had some good architecture discussions but have not yet picked a direction
… from an online perspective I think all incumbents are facing the problem of online fraud
… EMV has come a long way in addressing fraud from a card present perspective
… but fraud has moved online as a result. So merchants are paying higher interchange fees for card not present transactions
… and there are huge charge back fees.
… fraud is bad for all.
… if we are looking for an online solution, there is a great opportunity to address a problem that everyone faces right now.
… this group has the opportunity to address that…if we want to recruit new participants, saying we want to address online fraud, new orgs will come running to this group
… addressing online fraud gives us good momentum
… and can be useful in the shorter term
… I think there’s an opportunity to work with incumbents to find out what they need to be sure that a person is who they say they are.

<NickTR_redux_> This is exactly why identity and credentialling are such an important part of payments – we need to consider these explicitly

mario: banks don’t like fraud, banks don’t like it, consumers don’t like it. A headache for all.

<Vinay_Gupta_E> +1 yep, nobody likes fraud 🙂

Jean-Yves: One way to encourage participation is to ensure that their natural partners are here.
… so for example, banks want merchant associations
… authorities/fed part of group will be attractive to financial institutions
… I suggest we could try to get merchants and authorities
… and what about the web actors like google, paypal, etc.?

<Zakim> m4nu, you wanted to mention that the roadmap are the marching orders.

m4nu: The roadmap is there to tell the WGs exactly what they need to do.
… if W3C WGs don’t have clear marching orders, nothing will get done.

<evert> charter vs roadmap?

m4nu: so while it’s important to get people in this group, it’s important that others know what we need from them.

<stephane> +1 to manu that it has also in a w3C internal document

<chaals> +1 to Manu

m4nu: we need the clear roadmap in the sense of “What w3c is doing.”

<Zakim> dezell, you wanted to say what we have learned.

dezell: document needs to reflect our learning since Nov.
… We have learned things since the workshop last year
… e.g., what I’ve learned…includes more more focus on push/pull, relocatable building blocks
… a web-like architecture

<Zakim> Ian, you wanted to talk about fleshing out task forces

<dsr> scribenick: dsr

I support the setting up of a task force for communicating the IG’s mission and would be happy to participate.

What are the organizations we need to be talking with, we need to make sure that we know who is important and to establish connections and communicate with them on a regular basis.

David: I agree and would like to ask Erik if he can help with that.

Claudia Swendseid could be very helpful.

Ian: we want to ensure that people know that we exist and to avoid wasteful duplication of effort.

<dezell> +1 to External Review and Industry Outreach

David: +1 for that

<Ian> Industry Outreach Task Force

<stephane> IOTF???

<Ian> And national/international orgs

<Ian> scribenick: Ian

Pat: this is where the work that the Fed is doing is relevant…town halls where we are engaging people
… if there’s an opportunity for co-location or co-marketing some of our efforts with what they are doing, it’s worth a discussion with them
… we’ve got an industry engagement program at the Fed
… this feels like there’s a lot of parallel and in-line goals
… so good idea to partner.

IJ: What countries should we be watching who are making changes?

Pat: Australia, SEPA, Target 2
… so maybe someone from ECB

<evert> EBA – for the SecurePay work assigned to them

Pat: those would be important people to hear from directly…since they are implementing
… also UK
… VocaLink on top of faster payments
… zap

Nick: Zap is in beta

<chaals> [+1 to Padler that it would be good to get some of the people working on regulation in Europe, Asia, involved. (And someone who understands Russian and Eastern European banking)]

IJ: Jeff Jaffe will be in China speaking on payments

[The group would love to know more in advance of such W3C speaking opportunities]

IJ: See our talks page http://www.w3.org/Talks/

http://www.chinaw3c.org/payment-workshop.html

Steph: The staff creates opportunities on an ongoing basis to speak with organizations about our work.

<Zakim> wseltzer, you wanted to comment on security and to comment on security and fraud: use case elaboration?

[A bit more on staff role in engaging]

wendy: On fraud…we have been hearing that it’s an important area to make progress…I would love for us to get more concrete on what that means.
… so along with use cases, we should consider requirements
… it would be great to get a task force of the technical people to explain what the sticking points are in transactions that raise fraud risk.

<Vinay_Gupta_E> +q

wendy: and where in the web infrastructure we need improvements so that we can actually meet the commitment to reduce fraud
… and since we have discussion as we speak about web security model and hardware token security models, it would be great to have people join that discussion ASAP.
… to be sure we understand all the requirements.,
… and, e.g., if the web security and origin model doesn’t meet some requirements, we should know that

<evert> https://www.eba.europa.eu/regulation-and-policy/consumer-protection-and-financial-innovation/guidelines-on-the-security-of-internet-payments

wendy: so I am interested in building interfaces to our other WGs in this space (web security IG, web crypto, web app security)

wseltzer: So might want a new security task force

cyril: You began speaking by speaking about fraud and ended on security…they are not identical, even if security is part of it

wseltzer: I recognize that
… there are pieces of fraud management that belong in business risk management where W3C would not be involved..
… but where it interacts with web security, ID, authentication, verification, channels to supply verifications…that’s where w3c is well-positioned to help address

<scribe> ACTION: Laurent to create a security task force [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action01]

<trackbot> Created ACTION-55 – Create a security task force [on Laurent Castillo – due 2015-02-11].

<scribe> ACTION: Pat to create a communications strategy task force [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action02]

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

<scribe> ACTION: paler to create a communications strategy task force [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action03]

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

<scribe> ACTION: padler to create a communications strategy task force [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action04]

<trackbot> Created ACTION-56 – Create a communications strategy task force [on Patrick Adler – due 2015-02-11].

<Zakim> stephane, you wanted to be careful about web actors

trackball, close action 2

trackbot, close action 2

<trackbot> Sorry, Ian, I don’t understand ‘trackbot, close action 2’. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

close action 2

Steph: We need value propositions per actor
… e.g., banks, merchants, etc.
… you have to look at roles which may be more specific than a company granularity
… e.g., google has a wallet team and also a browser team
… for some actors at this time we do not yet have a value proposition
… for instance, I don’t think we have our story yet for browser makers

vinay: Non-repudiable payments slices through a lot of the fraud cases
… there are some big tectonic shifts on the horizon
… when we start the discussion, we should be aware that in different jurisdictions, the market may evolve differently
… so this is a large discussion, and it’s not simply about identity
… not sure exactly what’s in our scope, but wanted to raise awareness that there is a lot of discussion out there

<Zakim> m4nu, you wanted to mention that non-repudiation doesn’t solve the fraud problem. There is a consumer protection issue here.

manu: A bit of disagreement on what Vinay just said…non-repudiation shifts risk to payer….a number of consumer protection laws are thrown out the window with that approach.

<mario_de_armas> +1 manu’s point on non-repudiable payments

manu: so we have to be aware that we have a toolbox of approaches to address the problem, but we have to be aware of using them carefully

<padler> +1 to the toolbox of payment types and technologies..

Manu…but I agree that there are new approaches out there and we need to be aware of them

<Zakim> dezell, you wanted to say how bitcoin lessons might improve the fraud situation.

dezell: What Mario said is that we should say we will address fraud.

<Zakim> nick_exp, you wanted to say fraud finds a way – I think when cryptocurrencies become mass market, repudiation “because my keys were stolen” == “my card was stolen”

Nick: +1 to what Manu said

<Vinay_Gupta_E> Risk is certainly shifted to the payer, but most of the payers are paying large entities (amazon, wal-mart etc.) which gives a very low risk transaction from end-to-end.

Nick: as crypto-currencies emerge, consumers will still need protection against fraud.
… keys will still be stolen…a mechanism will be needed to protect consumers

Mario: We should be forward thinking…but there is a very real problem that exists today that we may be uniquely positioned to help resolve

IJ: Should we create a fraud task force?

Laurent: That would be boiling the ocean, but I think that it’s not the same as the security task force

IJ: Or perhaps just fleshed out as one or more use cases?

<padler> perhaps as a key principle – Reducing Fraud – as we go through use cases this would be a great lens to look through…

<dezell> +1 to assigning use cases

Mario: Fraud is a big problem…some companies exist to deal with this…i think here’s an 80/20 rule…what are the things that can be done to address the vast majority of fraud.
… I think this will cross a lot of lines for a lot of players…banks/networks/merchants
… a problem that is worthy of our attention

<Vinay_Gupta_E> +q

<Vinay_Gupta_E> Credit card companies – those big hacks are no joke (security) (40 million cards in a single hack) – vs. the day-to-day credit card fraud based on card skimmers etc.

<jheuer> Could we have an _interpretation_ of security and processes proposed by this group in the focus of fraud reduction?

<scribe> ACTION: Mario to write up one or more fraud use cases. [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action05]

<trackbot> Created ACTION-57 – Write up one or more fraud use cases. [on Mario de Armas – due 2015-02-11].

Devell: I suggest you speak with Gray Taylor

(Mario points out that large company and small shop fraud cases may be different)

<JosephLubin> With respect to cryptocurrrencies and consumer protection: cryptos will offer choice. They offer a fair amount of choice now and the variety of different functionalities will grow over time. If youar e a naive consumer you should entrust your account and private keys to a custodian like Coinbase or Circle or BitStamp. And you are protected by well funded businesses. If you are more sophisticated and want to go it alone, your costs will be lower and you

<JosephLubin> will not be protected by your own choice.

Use Cases (high-level)

<m4nu> https://www.w3.org/Payments/IG/wiki/Use_Cases_Task_Force#Status

<dsr> scribenick: dsr

Topic Use cases

Manu: I will quickly run though them one by one.

[too fast for scribe]

<Ian> https://www.w3.org/Payments/IG/wiki/Use_Cases_Task_Force#Status

<Ian> (Nick: Treat collection from credentials from the purchase operation)

Katie: why not have a stream

<floris> +1 to Nick on separting identification from payments / purchase

<Ian> (IJ notes that the use cases have triggered a thought about modeling, which is helpful)

Nick: there could be an enormous number of use cases to cover the cross product of all the things we need to consider

<evert> A “customer journey” is constructed from a number of use cases (elements)

Chaals: the point of the use cases is to describe the set of things we want to do, and we can then use them to identify the challenges we need to address.

There won’t be a perfect matrix of everything you want to do

David: which use cases involve Nick’s issue

<chaals> s/There won’t be a perfect matrix/We don’t need (nor want to make) a complete matrix/

[nick responds too quickly for scribe]

<chaals> [nick found the explanation helpful – thought he was jumping too fast to the solutions rather than *just* looking at the problems we need to solve]

David: if we are calling out credentials then this is a clue that this needs to be addressed

Manu: do these use cases resonate with the group sufficiently for us to move them to a public draft.

<mario_de_armas> lol

Chaals: we need to take our uses cases and then see what we want to solve. We need to have a substantial set of use cases, but don’t create them to match your solutions!

David: Chaals is right but this is an iterative process. Digital receipts is example of something I would expect to appear in several use cases.

… Which of the current use cases are ripe for moving forward?

<evert> suggest to select payment related use cases rather than puchase related ones

… A straw poll on the use cases would be a good next step

<wseltzer> +1 to jheuer: use cases are usage stories more than modules of the solution

Joerg: I like Chaals point that the use cases represent the problems we need to solve, but we may want to have business process steps as something we can then list starting from the use cases.

… I would propose to address that in the user payment agent task force

Joerg cites receipting as an example

Laurent: agree that we need a flow discussion, but not sure that this is best in the use cases.

… I see a lot of categories we can think about

<Zakim> wseltzer, you wanted to sayu “issues”

Wendy: good discussion. Use cases are a good way to capture information. Some groups call them user stories, other groups, use cases. Then, they’re useful to the groups to whom you send spec requests as indicators to see whether their spec would meet user needs. The first public working draft is just a starting point and there aren’t a lot of procedural hurdles in the way of gettting that out.

… Issue tracking can then help to track the discussion points arising from the use cases

<wseltzer> [see e.g. Social API user stories, https://www.w3.org/wiki/Socialwg/Social_API/User_stories ]

(Dave has also seen the term “narratives”)

Stephane: we should ensure we have a broad range of use cases that include, for instance, push payments

Chaals: name for use case should make clear what the problem that use case captures

Annette Kik introduces herself. She is from the W3C Benelux Office.

Katie expands on Chaals description. The use cases are simple accounts of the problems, let’s not overcomplicate this.

Manu clarifies that the status section has 3 sections, the last section lists use cases that are already in the FPWD

Ian: you have a concrete text for the use cases, and the only question today is whether the current use cases as written should be in the working draft.

Wendy: for digital receipts we need this as part of a simple story (cites examples)

<wseltzer> [that way we’re leaving room for alternate solutions, if better ones are presented.]

Chaals: to a certain extent these use cases have been written based on preconceptions of the solutions that will fulfil them. That is exactly the wrong approach to take

(David displays a spreadsheet with a list of use cases that isn’t the same as the lists presented in the status section of the use cases tf wiki page)

David explains that the spreadsheet lists topics that he wants the use cases to cover.

<wseltzer> David: my use cases are verbs, e.g. “do sale”

<jheuer> Make sure we have a place where real world stories and requirements can go to – no matter what the view point is. Use cases should be the place, shouldn’t they?

Pat talks about use case groups

Stephane: just wondering if we could have a use case covering token based payments?

Chaals encourages him to add one to the wiki

Digital receipts: none against

(lots in support_

Refunds use case: 11 in favour, 1 against

Joerg doesn’t think refunds is apropriate for 1st draft

registration-less purchases: 15 for, 1 against

<Ian> [Abstaining overall: Wendy, Ian]

non-interactive purchases (making it easy to make really small payments without being pestered by the website)

Pat: this is consumption based payments, right?

[yes]

<Ian> [Ian heard that there was previous consent…e.g., you signed up for car service and each time you get in the car you pay for the ride]

9 in favour, 7 against

Psuedo anonymity (buying a single item without giving your identity info)

Chaals explains this is good for buying milk but not airplane tickets

Nick: pseudo anonymity involves a very loose coupling of identities

<Ian> IJ: I asked what the diff between registrationless and pseudo-anonymous. Charles provided example of airline tix (which require identity but may not require getting an account) v. pseudo-anonymous (which does not require identity)

Chaals: it doesn’t imply that you can’t do law enforcement

<wseltzer> [“partially private” seems a more informative name]

12 in favour, 4 against

<Vinay_Gupta_E> Gevalt.

Offer of sale (merchant showing the goods available, the search engines care about this as a means to route potential customers)

Nick: no payment so should be out of scope

David: agree that this can clearly not be in the first draft

No one in favour, many against

Parametric offers (offer with options, e.g. discount if you use your loyalty card)

Chaals: this is a really important use case

Nick: this is exactly like the previous one, so I don’t want it in the first public draft

Jean-Yves: it is relevant to where the loyalty cards are managed (e.g. by wallet)

Pat: this is important to the payment, and may related to regulatory constraints e.g. depending on the countries involved

Manu: there is no automatic way for the payment solution to pick between the options

some discussion about how many people are needed to progress the use cases to FPWD

Chaals volunteers to do 10 use cases within February

Vinay: how about we write down use cases for the common things we do on the web today!

Chaals: yes that would be a good idea

Vinay: these should be uncontroversial

David: would Vinay volunteer to add them to the wiki?

<Ian> Request an account -> https://www.w3.org/accounts/request

Vinay: okay, yes I will do that

cyril offering to write use cases for basic debit and credit

Stephane: still not getting the use cases David lists

Parametic offers: 4 in favour, 9 against

Coupons and loyalty cards (for use pre-purchase – how to get them to the merchant)

11 in favour, 4 against

<Ian> Dezell: Clarification that today we are agreeing to what will be in FPWD but we are not preventing other things from being in

<Ian> …e.g., ones added to the wiki after this meeting

<m4nu> Offer of Sale and Parametric offers didn’t make the cut

<Ian> SO RESOLVED to include the following in the FPWD:

<Ian> – digitral receipts

<Ian> -refunds

<m4nu> All the other ones are in – Digital Receipts, Refunds and Reversals, Registration-less Purchases, Non-Interactive Purchases, Pseudo-anonymity, and Coupons and Loyalty Cards.

<Ian> – registrationless

<Ian> -non-interactive

<Ian> -pseud-anonymity

<Ian> -coupons and loyalty

<Ian> In addition to previously approved ones:

<Ian> – purchase request

<Ian> – push-based

<Ian> -choice of payment instrument

<Ian> – pre-authorization with completion

<Ryladog> Scribe: Katie Haritos-Shea

<Ryladog> ScribeNick: Ryladog

Membership Brainstorm

DE: Manu I owe you discussion post mortum for Use cases

MS: We have CMN and would like to have more people to review UC

DE: Who else can help with Use cases?Thank you Laurent and Evert

EF: Will work on Glossary and maybe review UC

DE: We have to plan Next Steps – coming later this afternoon
… push/payment UC. Are there any other topics other than those two and NextsTeps

MS: We try to create the TOC for the Raodmap
… should have Vision, Statement tec sections

DE: We blew the Roadmap out of the water

PA: I would rather discuss with others on the TF

DE: I woud rather we review more UC
… Reprise of Archwhich is Push Payment. So Next Step

PA: If we do Arch Reprise as part of one of the UC
… I would like to getabetter sense of what we outlined. Do things mkae sense. Like run threw the use case framed with in our Arch

DE: Membership Barinstorm,Steph had ideas for membership

Membership

Steph: We should identify first the stakeholders in the chain – and then for each do we have a value proposition. Explain their carrot and stick if you are not part of our discussion
… and then if?? we can stop putting names. We should talk to Google wallet….

DE: Should we identify the actors/stakeholders?

JH: I have a list of those you might not think of as relevant topics – identity management and secuirity

MS: We have lost a couple of folks…

DE: Discussion about seemingly lost members….
… For some it may just have been holiday season for obvious reasons…

MS: Some high profile payments teams seems less engaged

DE: Steph can you help contact thoe with previous interest

WS: Please let us know about folks who you think may have interest
… Alan Bird leads membership for US, but the IG

DE: Interest Group is almost about trying to keep people interested…

<wseltzer> s/,but the IG//

<Zakim> m4nu, you wanted to mention who we’ve lost and whether we can get them back re: membership.

SB: Mozilla let go of MozPay….they feel that is not their business….and may engage when they see rlevance
… Can you explain more about MozPay – their focus was to be able to support several wallets – it was a nice idea

DE: It seemed like a smaller subset
… Th is not the browser vendors core competency

JH: I would disagree
… they all have payment interests

DE: We are going to have to socialize this

<Vinay_Gupta_E> +q

<Vinay_Gupta_E> (re: mozilla)

EA: Have we had contact with the large wallets and crypto-currency folks?

MS; Yes

DE: Should we have a wiki page for this?

SB: Having a per type value prop would be fine for a wiki

PA: Those who are using payments through an OS
… they should be on the actors list and their processes
… Other national banks as well..

<sboyera> Tim did a presentation at the march workshop, see links from the agenda at http://www.w3.org/2013/10/payments/agenda

PA: any payment standards bodies and regulatory bodies

CMN: regulators from around the world would be useful

PA: Include regulatory stuff in the use cases and system that we want to build

<Ian> (Inadvertent discussion of use case called real-time regulatory reporting)

DE: We need a UC for Pat to create

PA: Pat will find someone

FK: We need to include Taxing orgs as well

IJ: Reads off list of actors

<Ian> Roles we are discussing:

<Ian> * payment providers

<Ian> * browser vendors

<Ian> * cryptocurrency

<Ian> * national banks

<Ian> * standards bodies

<Ian> * regulatory bodies

<Ian> * payments processors

EF: We should have enough of each group to have proper representation

VG: mobile phone payment stuff

<scribe> ACTION: for Dave to work with Vinay on contacting people who are working on payment [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action06]

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

<scribe> ACTION: Dave to get with W3C staff contact for companies [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action07]

<trackbot> ‘Dave’ is an ambiguous username. Please try a different identifier, such as family name or username (e.g., dlongley, dsr).

<scribe> ACTION: David Ezell to work with W3C staffon contacts for IG [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action08]

<trackbot> ‘David’ is an ambiguous username. Please try a different identifier, such as family name or username (e.g., dezell2, djackso3, dlehn, mcdermittd).

<scribe> ACTION: dezell to work with W3C staffon contacts for IG [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action09]

<trackbot> Created ACTION-58 – Work with w3c staffon contacts for ig [on David Ezell – due 2015-02-11].

<Ian> pat: Personal financial management and budgeting is another type of organization

PA: Push payments for Bill Pay might be good use cases – for Personal Financial Budgeting and Payment
… It would give us an end user perspective

LC: Standards bodies and Local and International schemes

EF: Scheme management organizations

DE: Payment scheme management

<evert> http://www.currence.nl/producten/ideal/

PA: Operators

EA: EU regulators want to clearly define the roles

JH: security technology providers
… their authentication scheme, and loyalty schemes, they make use of our work, and marketing agents
… they have lots of ideas and requirements- they have a lot of web technology background.I do not knw about the international actors in this space – I am familiar with local ones

<Annette> /me IAB is a W3C Member in marketing, http://www.iab.net/

PA: we forgot about white banded provides.Web site providers, those doing payments in their social platforms

<m4nu> KHS: A lot of them are localized, so lots of folks to pick from.

LC: large chat providerss

<Zakim> m4nu, you wanted to mention MCX.

<sboyera> currentC provider

<m4nu> scribenick: m4nu

david: Any other ideas about outreach?

Ian: I need to work on an outreach plan – will need to know what the message is, then we will talk to people.

<Vinay_Gupta_E> +q

Ian: I have a list of categories and organizations, I don’t have an outreach plan since so new I haven’t thought about it.

Vinay: We have lots of additional players – what about unconventional folks?
… What about folks that are in a different regulatory bucket.

<Ryladog> DE:Other outreach ideas?

Vinay: Peer to peer lenders might be interesting.

Floris: Yes, a couple of peer to peer lenders / schemes from EU are interesting.

Vinay: They have big know your customer requirements – all somewhat marginalized within regulatory frameworks.

Pat: Corporate payments – pay statements that go over existing rails. Is there an opportunity here for most of these things to go over the Web?
… Much of this is collected and started on the Web, but then go over traditional payment rails.
… Are there reps like corporate treasurer organizations that we could work with?
… Not high priority if we are focused on end users first – but might be interesting,

Katie: Communicating between finacial organizations?

Pat: No, more like instead of payer and payee (person and corporation)… payer and payee are corporation and corporation.

Chaals: I think we need a use case for that.
… It’s a gap that we should look at.

Cyril: When you have an account for a person – credit transfer is the same for a corporation, so pretty similar stuff between person and corporation.
… Push vs. Pull – they’re the same in the corporate world as the personal world.

Chaals: Not necessarily
… For example, people reach into their pocket to pay… corporations need to approve payments for their employees.

Pat: Yes, approval in a corporate context is important.

David: B2B is clearly in our scope…

Pat: as is person to government, government to person, etc.

<Zakim> m4nu, you wanted to mention the hit list.

manu: I have a list of organizations that I’ll send Ian.

<scribe> ACTION: Manu to send list of organizations that may join to Ian. [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action10]

<trackbot> Created ACTION-59 – Send list of organizations that may join to ian. [on Manu Sporny – due 2015-02-11].

Evan: We have everything leading up to payment initiation, but nothing much for settlement.
… We should have a parallel track for faster clearing and settlement. It has to do with B2B and B2G, not just about presentation layer, but also about using Web to move money faster.

<Ryladog> EZ: Clearing and Settlement task force might address B2B

<evanschwartz> https://www.w3.org/Payments/IG/wiki/Value_Web_/_Web_Settlement_Task_Force

Evan: If anyone likes the proposal, in scope out of scope – it’s a proposal for a task force, interested in participation. Main thrust is our use cases assume we have to agree on some payment scheme in order to do commerce.
… We need a common payment scheme to transact today.
… There is a parallel, non-blocking thing – lower level – can the Web be used to improve or speed up the way money moves – clearing / settlement / etc. It’s more long-term, the use cases may be slightly different. Version 1 of this group doesn’t depend on this being moved quickly, but we should talk about it.

Mario: I disagree wrt. both parties needing the same scheme.
… Payment instrument – cash / check / credit card / etc.
… Let’s talk about the data pieces, not necessarily who needs to be involved in moving that data around.

<Ian> (Summary of Evan comment: (1) improving selection of a mechanism for payment and (2) improving how that mechanism is carried out)

pat: On the topic of scheme, it’s simple – agreement between two parties exchanging value. Whether that scheme is Ripple, that’s great – handing cash to merchant.

Cyril: Cash is a scheme, euro is a scheme, dollar is a scheme.

<Ian> [Discussion about “scheme” which identifies actors, instruments, contract to be followed, regulations, …]

<Ian> Mario: Scheme mixing scenario e.g., credit card / paypal

Pat: I can agree to use one instrument, someone else can use another scheme.
… You the merchant is exchanging value using two schemes – if we have multischeme models, it may confuse people.

<Ian> Pat: Not really “multi scheme” but there is some party that transitions from one to another

Joerg: We need to be clear in our terminology – exactly what is a scheme.

Pat: once scheme is identified, it makes it really.

<Zakim> m4nu, you wanted to talk about cross-scheme payments and faster clearing.

<padler> * we need a task force task force… 🙂

<floris> * Clearing technology is interesting, high frequency trading (algo trading) is obviously highly efficient, something we could get inspiration from?

manu: I think it’s important that we keep our eye on faster clearing.
… RIght now, nobody in this group is focusing on that and we need to keep it on our radar.

Push Payments

dezell: We need to finish up two more topics – we need to conserve our energy, let’s take a short break and then reconvene.

<Ian> DRAFT MEETING SUMMARY -> https://www.w3.org/Payments/IG/wiki/Meeting_Summary_Feb2015

Cyril: Any clearing has the same basic functionality even if it’s really fast or really slow. Basic data is exchanged – if it’s the US clearing, Ripple clearing, etc. If we can put the clearing into a TF in this group, we may be going to far – clearing is a big subject.
… There is regulation, there are directives, etc. on the clearing.
… This may be too big of a scope to include.
… Web Payments is a big task by itself – don’t know if this is in the charter.

David: If the charter doesn’t forbid it, then it’s okay to talk about it.

[7 minute break]

David: I’m interested in doing a discussion on the email that Chaals sent. If we can keep the discussion to 10 minutes, that might be good.
… Any opposition to that proposal?

No opposition.

David: Let’s consider first part of your message.
… We can consider the last part too.

Chaals: We can go through and go “yes” / “no” / “needs work”

<scribe> scribenick: m4nu

<chaals> Key outcomes thoughts from chaals and monday discussion

These are the things that Chaals said about goals: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Feb/0002.html

Chaals: There were no specific objections to the first set of points… the last set of points weren’t really in that list, but were said.
… If we put all of this in a document, people might like it as a “this is where we want to be in the future” sense.
… if we can agree on that – that’s good, because the IG can say “we like this as a first approximation”
… So, let’s go down the list and see if folks like each item.

<dezell> manu: “Enables anyone…”needs more work.

Chaals: We need to be clear about items needing more work.

Laurent: We need to be careful about “stolen card” transaction fraud, and level playing field.

<Ian> Laurent: “great reduction” may be too much “not causing more fraud” may be more appropriate….needs more work

<Zakim> dezell, you wanted to ask about the first one.

pat: I think these need more work – what makes a successful web payment – what is a successful web payment?

chaals: It’s useful in the long run, not for this exercise.

<Zakim> nick_exp, you wanted to ask for explanation of “the technology” and “to take their money out of the system”

Nick: Fast and significant adoption of the technology – will vote needs more work.

<chaals> ackjh

jheuer: Identity / identity tokens – overall I like them a lot, I think we can focus on them.
… One section missing – user privacy.

jean-yves: Greatly reduce payment provider switching costs – costs, focus on costs.
… Enables value-added services for payers payees – does not interfere w/ ability add time required – ideally helps ability to meet regulatory requirements.

Cyril: Don’t understand “allows people to take money out”

Chaals: Basic idea – do transactions on Web, that’s great – you should be able to change it into cash.
… Being locked into all your transactions on the Web isn’t good.

Pat: It’s a Web ATM.

David: I think we can go forward – put in the wiki.

<scribe> ACTION: Chaals to put goals in the wiki and send an email telling people to work on refining the goals list. [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action11]

<trackbot> Created ACTION-60 – Put goals in the wiki and send an email telling people to work on refining the goals list. [on Charles McCathie Nevile – due 2015-02-11].

David: Put comments in red, add lines underneath each one.

Chaals: I’ll come up with a convention.

<chaals> scribe: chaals

Push Payment

<m4nu> Push payment link: https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#push-based-payments

DE: We didn’t have a common definition of what push-based payments do?

Manu: THere was general confusion of how push/pull and 3-/4-corner paymetns play together.

DE: See some new things. There is 3- and 4- corner scenarios

… actual people and things.

SB: My proposal is that we give a bit more context on the push-based payment.

… had discussions in hallways, and one idea is that 3- vs 4- corner is irrelevant. But splitting the world to a schme for push and a scheme for pull payment is appropriate.

… and the way you manage the transaction.

… If that’s what we think, we should have the complete picture frame.

… Push payment isn’t a simple use case, it is a way we divide the world into categories.

DE: There is a provlem with this?

SB: No. Two of them.

… 1 – splitting into 3- and 4- corners

… 2 – discussing push payment without explaining pull only explains half the world.

DE: I thought payment request use case was that.

Manu: No, push is customer-initiated transfer, pull is merchant-initiated.

[discussion of payment request and if it is relevant]

JH: The introductory sentence is confusing. Usually invoices are itemised, this wil lead to disucssions about things users might not want. Further on there is more detail that can explain, but I wouldn’t say invoice at the start.

… Customer point of view doesn’t refer to any payment agent ideas. Which makes it hard to interpret this. Would like a notion of the user being involved and picking the payment instrument in this use case.

… The user doesn’t care about payment proessors, but has cards and tokens.

… As to 3- and 4- corner, I ask if we need to address this in here – creates a connection that isn’t mandatory.

… So it would be OK to say “pushing the information ot a backend and get feedback. Whether it is 3- or 4- corner doesn’t matter.

CV: A use case should be “is this a recurrent payment, because I subscribed to a newspaper or something”. Could be that one month I need to revalidate a payment

<Vinay_Gupta_E> +q

… Push-based payment is easier for when you want to validate each individual payment.

… With a card system we know someone can use your card. I personally ask everyone not to register my card, but they still pick it up and re-use it.

… the use case should not be push-based payment. SHould be subscription payment, clear validation, …

… (the rest is useful explanation, but for elsewhere in the document).

… e.g. direct debit and credit transfer.

DE: You object to calling it push payment?

<wseltzer> [use cases can have different levels of abstraction. a higher-level use case might describe motivations, that could be satisfied by (push payment or some other method)]

CV: Yes.

… when we have a use case you take sofort, you need to transfer id, always need basic data.

Floris: you mean intiations or payment?

CV: Maybe intiaitons more than payment.

<m4nu> -1 to splitting all of that out into separate use cases – we started there and it was a mess.

CMN: THis isn’t a use case. Nobody says “I want to make a push payment today≥” @The four exaples are each use cases@@

<m4nu> +1 to chaals saying that we should use better use case names

PA: Agree with chaals. There are some gaps here. How does the browser know who the payment processor is.

… so there might be something like “merchant shows list of available schemes. The user selects a scheme, and provides authentication to that processor”

… then in my head I can ask what has to be present for this to work?

… Where is the payment processor, how does the process work.

… Thimk we have to get to what the user is trying to do – what are the concrete tasks.

<Laurent_> +1 on focusing on concrete tasks

… we could build some concrete things around this – what does the merchant do, what do we need, …

MS: We outline in the requirements section the things that we need to fulfil the stories.

PA: It says “candycart.com doesn’t help me understand what the pieces actually are – is it a web-based processor, or …÷

<Zakim> nick_exp, you wanted to ask if the use case is aspirational or should be ‘real world’

NT: My question is the point Pat made. Are these aspirational, or de we need to be able to show this working inthe real world?

<evert> iDEAL looks like the candycart example

<wseltzer> [suggest avoiding specific UI elements: instead of “clicks buy” -> “User indicates that he wants to buy, e.g. by clicking a button”]

<Ian> manu: Some portion of each use case is aspirational

MS: Some portion can be aspirational…

NT: If this is aspirational that is fine.

CV: There are 27 push systems in europe

<Zakim> dezell, you wanted to ask about the description

NT: But they don’t meet the requirements suggested here.

DE: 2 different threads here.

… provenance of this use case – in Santa Clara people knew exactly what this was, payment experts.

… They recognised this way of doing things and that is what we got in the minutes. I reverse-engineered the examples.

… So you’re looking at a reflection and seeing the examples in them.

… We don’t need four use cases, we need to write stuff better…

… what matters is cyril’s objection.

… neither direct debit nor subscription describes this in the way people were discussing it in santa clara.

… forgetting the requirements, the details is the most interesting bit.

… This is a type of payment that isn’t well supported. Dothe details describe this one?

SB: I don’t understtand what you mean by not supported. You could pay with wire transfers.

DE: This isn’t ubiquitous.

Evan: Except that cash is a pretty common push-based payment system.

DE: This is different from almost all electronic payment systems today.

… can we approve the details and fix the rest – do they make sense?

<chaals1> … in this we have a different flow. I go to Delta and do [@@@missed]

<chaals1> … you tap a phone at walmart, it gets a token and does payment. In this system I don’t give payment to the merchant, I ask the phone to ask the bank to pay the merchant.

<Ian> (David basically gives side-by-side comparison of stories…which IMO make useful distinct use cases)

<chaals1> … That is something that has a lot of industry interest.

<chaals1> … not sure on the best way

<chaals1> MS: Best way is chaals outlines the changes.

<chaals1> JH: Chaals takes a viewpoint of a certain player, and that means you use the language of that player. Here we mix several viewpoints and mix the language.

<chaals1> … User doesn’t care if it is push or pull. I propose that when we take a viewpoint we use that viewpoint.

<chaals1> DE: There are a lot of things we can improve among our use cases.

<chaals1> VG: Actual payments exist in this context. Entire sectors. Merging with the web by the bucketload.

<chaals1> … So there are well-established divisions, there are all sorts of new things. I don’t want tolock us into locking into a model that doesn’t anticipate things that are already being done, just not the dominant paradigm.

<chaals1> … need to reserve a space.

<chaals1> CV: Agree with the details. These are true for classic push-based payment.

<chaals1> … The processor is a bank. Implication is bilateral steps. We have a new paradigm of push payments, with maybe another use case.

<chaals1> … Where the payment processor isn’t the payer’s bank. It acts for the merchant like the payer processor, in order to reduce the cost of the transaction.

<chaals1> … It isn’t a 3-corner model – there is no contractual relationship.

<chaals1> … This should be taken into account, and will be explained by DSP2. Euro bank authority should do something. If what they do is incompatible with what we do, that will be a problem

<chaals1> … We need different flows. I don’t give my sensitive data. I reveal what bank will pay, instead.

<chaals1> … So make it possible that anyone in the group has the same type of vocabulary.

<chaals1> … We need a solution for that, which is what e.g. SOFORT and 26 other payment systems in europe do.

<chaals1> … This is a good opportunity for a merchant.

<chaals1> … (not so much for the bank 🙂 ).

<chaals1> … I volunteer to describe the 2 flows and a use case for this.

<chaals1> … and maybe a proposal for clarification.

<Zakim> sboyera, you wanted to question the requirements

<chaals1> SB: We should say very clearly that push payment is a category of things, not a new way to do payment. Cite some realistic examples like paypal, google wallet, wire transfer, etc.

<chaals1> … For me the requirements are completely irrelevant in this section. I agree we want to convey this idea, the work required is how to address the requirements. here we have such specific requirements that seem irrelevant to the whole category – they are some things required for some specific implementation strategies.

<Zakim> chaals, you wanted to say this can be asspirational but must be real desires.

<chaals1> … We want to remove requirements, and describe the use case.

<m4nu> scribenick: m4nu

Chaals: Use cases can be aspirational things.
… Saying I want to go to the moon and I want to buy milk is aspirational too, we probably wouldn’t want to support it.
… Best way to make changes here are for people to suggest concrete changes.
… What Joerg said is good – but the reason you do use cases is because you can understand what’s important.
… From all of this text, I don’t know why push-based payments are important.

<Laurent_> +1 on selecting one perspective only for writing use case

Chaals: Details and requirements – I think it’s been built backwards.
… I don’t know if we’ve met the things we want to achieve because the motivations have been removed.
… We want to be more direct – merchants want this because it reduces risk to them. Customers want it because it moves risk. We need to understand the motivations behind the scenarios.
… We need to be able to go from the use cases to process flows to glossary, etc.
… For example, 4 corner should be in glossary.
… Issuer in scenario, issuer does this and that – I still think what I want to do is propose changes to rip out stories that I hear and saying that there is a use case that someone wants – here is another perspective on the story – the examples are the bit that has the use case.
… We use the use case to generate the details.
… I think use cases have been done by people that understand too much, and bias has come into the use cases.
… When they’re talking to each other, they don’t explain the motiviations.
… We need to be able to explain our motivations and goals to a much broader community. We draw out the things that are necessary, the things that are desirable, and that’s how we get down to “what do we want to do”.
… Solutions match requirements, requirements match use cases, that’s how we get there
… I think I’m going to try to pull out those examples and pull those bits of the stack out,

David: Do you mean in this use case, or in general?

Chaals: I think the same thing has happened to other use cases, we might pull detailed kernel out.

<Ian> [IJ +1 to stories being the use cases, and that there is another layer which either extracts modeling from the stories, or groups them, or whatever]

Pat: There are a couple of key things that are missing – as we look at this, we have actors, but we don’t have where they should be.

<Ian> […and extract architectural blocks]

Pat: I’m accessing an app, where I am matters.
… If I’m in my own digital app – in my own ways I might identify myself.

<Ian> (Watch as part of 2-factor authentication)

Pat: It matters what device I’m using and where I am.
… The derivatives are going to come from where are my users when they do it.
… The interaction patterns are going to differ wildly
… Once you get a good read on where they are physically and digitally, it’ll change things.

<Ian> Pat: template:

<Ian> – where is user

<Ian> – what devices does user have

<Ian> – what signal is sent by user

<Ian> – what schemes

Pat: maybe we capture this sort of stuff in each use case.

<Ian> – web or native

<Zakim> wseltzer, you wanted to comment on motivations, ui

Pat: There might be priorities here – like browser based payments, or retail payments – figuring that out is critical.

Wendy: We have use cases that are at very different levels of abstraction – partly that’s because we have many different viewpoints and levels of experience with payments processes. For those with less experience, more description of motivations will help to show the importance..
… So, for example one of the audience members for this document is the general Web community, we need to speak much more high level.
… We need help from lots more of the Web ecosystem to get things done in the end. There are no invalid use cases at this stage, there are some that are more or less useful. Let’s try to make all of them as useful as possible.

<Vinay_Gupta_E> I’m greatly in favour of doing the use cases for existing common payments first

Wendy: We want to abstract some UI stuff away, such as “user clicks buy” to “User Intiates Payment”

<Ian> (IJ: as a result of this discussion I am moving strongly in direction of stories being focused on user actions, and clarifying who the user is and framing language in terms of user POV)

<Vinay_Gupta_E> I think it’ll really help tie down the nomenclature etc.

<Vinay_Gupta_E> +1 Ian

David: It would be completely wrong to say that this has been overanalyzed. About this discussion, I think you all understand what it is we’re talking about now.
… On one hand the merchant initiates the payment (pull), on the other hand the customer initiates the payment (push)
… In the nomenclature I’m used to – the examples are the user stories.
… It gives an idea of the real world. A use case is much more terse – and it’s a flow.
… We don’t have flows here, or alternate flows. I think the requirements – don’t know why they’re there.
… The benefit of push is huge – it’s not fair to say it’s unmotivated… it’s just not clear what the motivation is.
… If we want stories, we’re probably have to reverse engineer them.
… The thing that I’m most bugged by is that we don’t have flows in these use cases.
… I think we got what we wanted out of this discussion

Cyril: My proposal – the examples should explain the motivation.
… Push-based payments are very interesting for B2B – you can start the process, give it to accountant, if we explain the example…

David: Can you work with Chaals on this?

[break for 5 minutes]

<chaals> scribe: chaals

winding up

DE: Next steps… I think we have a list of things people want to do in 3 months. Don’t think the goal has changed much – we want to publish FPWD of use cases. That may be farther away than we hoped but think we should try to do what use cases make possible.

… If you have 12 use cases, and only get 4 ready, you can publish, then make a revision.

… 2: There is no specific goal for architecture – you have some feedback, you will come back with ideas.

… 3. We have OutreachTF where Pat is going to help us develop a communication strategy and get materials together that communicate our mission.

… need to get a timeline for the next steps there.

4. Teleconf schedule and next f2f

Use cases.

DE: Date we want to aim for?

MS: March 1?

DE: April?

IJ: what is the milestone?

DE: FPWD.

… published on /TR

… Chaals will work on this. Let’s see what we can do by March 31.

CMN: OK, it is useful to have some framing like that.

payment agent

DE: timelines?

JH: Think we will need to rework diagrams, biggest task is breaking down the phases and match them to the use case descriptions.

… Don’t know how we get there, but another revision could be done in that timeframe of March 31 deadline

DE: What will we discuss in regard to the model in that time?

… this sounds like a 1-person job we have to wait on.

JH: For figures, Pat and I will probably work on them.

… for breakdown of timeline I think more people could be involved.

… need to collaborate with use case work.

… lot more communication to take place before we have a draft.

… should be able to present *something* by the end of next week, but want another couple to have a new draft

DE: Evan, you wanted to join them, right?

ES: We have to talk…

VG: I’ll do some drawings.

JH: Can you join calls?

VG: Yeah.

Floris: I’ll try to get people from my team.

DE: There is a public comments list – you can get outsiders to contribute there.
… Mario deserves to be added to a TF because he left early.

MS: I could get a couple more invited experts who would work on it.

DE: Manu, we need to talk…

Outreach

DE: Don’t think we can make a bigger statement of purpose document until after the FPWD of the use cases.

IJ: Haven’t chatted with Pat (Pat, we need to talk)…

<dezell> ACTION: david to add a communications strategy page for the TF [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action12]

<trackbot> ‘david’ is an ambiguous username. Please try a different identifier, such as family name or username (e.g., dezell2, djackso3, dlehn, mcdermittd).

… I’ll propose Pat and I confer on how to organise TF, commit to having a first draft strategy by 18 Feb, including some timelines for deliverables.

DE: Having a higher-level executive summary could start sooner.

PA: We need to confirm that timeline. I think it is realistic to talk about getting a timeline together, we need to talk about how much time you have to do work.

IJ: Let’s make it 25th as a due date.

PA: Sounds better.

Teleconf and next face to face

<evert> evert will work a bit on the glossary 🙂

DE: Next f2f tentatively first half of June, NYC. Fallback for the same time frame in Washington DC.

… That’s about halfway between here and TPAC, and doesn’t hit northern summer holidays.

IJ: Whose action is it to make sure there is a meeting

<wseltzer> TPAC 2015 (October, Sapporo, Japan)

<scribe> ACTION: DEzell confirm next face to face meeting [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action13]

<trackbot> Created ACTION-61 – Confirm next face to face meeting [on David Ezell – due 2015-02-11].

<Ian> TPAC 2015

<Ian> 26-30 October 2015

<Ian> TPAC 2015 will take place at the Sapporo Convention Center in Hokkaido.

… start planning for TPAC. Sapporo Japan. Please work with staff and me if there are people who might turn up because we are in Asia.

… e.g. as invited observers, if not members.

PA: Will that be last TPAC where we meet for 2/5 days? If so can I request meeting on early part?

DE: Yep, good time to ask.

[TPAC 26-30 Oct]

CMN: Unlikely to be able to do 1st half.

WS: Security groups likely to meet at end of week.

… IETF meeting the next week in Yokohama.

DE: Teleconf schedule…

… Think Use Case TF should keep meeting weekly…

JH: I propose to go bi-weekly for payment agent.

DE: We currently do weekly 0930 tuesday Boston standard time

… nervous of going to every other week.

MS: Think there is a lot to do, and for now we should keep meeting weekly.

SB: While we have no asian participant we can go a bit later, but if we get people in Asia we need to revisit.

DE: Anyone can’t do 1530Z?

<Ian> PROPOSED: 10:30 ET / 15:30 UTC weekly IG call

<scribe> ACTION: IJ set up survey for weekly call schedule. [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action14]

<trackbot> Created ACTION-62 – Set up survey for weekly call schedule. [on Ian Jacobs – due 2015-02-11].

Thank you…

DE: For the chairs, thanks to Staff contacts, especially to Stephane for all the work he did in getting us going, and we are sorry to see you stepping down …
… Thank you to our generous host Evert, and Rabobank…

… And that’s it for me. Any other business?

WS: Thanks to participants, scribes, and chairs.

<wseltzer> [adjourned]