W3C

- DRAFT -

Web Payments F2F - Day 3
04 Feb 2015

Agenda

See also: IRC log

Attendees

Present
Annette, Chaals, Cyril, DaveR, David, Erik, Evert, Ian, Istvan, KAtie, Manu, Nick, Pat, Patrik, Steph, Vinay, Wendy, Joseph, Jean-Yves, Floris, Laurent, Evan, Mario, Eddie, Joerg
Regrets
Chair
David
Scribe
Katie Haritos-Shea, chaals

Contents


<stephane> rrsagent make log member

<wseltzer> Date: 04 February, 2015

<Ian> scribenick: Ian

<Vinay_Gupta_E> Good morning

[Agenda bashing]

<wseltzer> [agenda bashing]

<stephane> +1 to go for push-payment

(proto-architecture discussion from yesterday might be discussed)

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]

Summary of Action Items

[NEW] 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]
[NEW] ACTION: Dave to get with W3C staff contact for companies [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action07]
[NEW] ACTION: David Ezell to work with W3C staffon contacts for IG [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action08]
[NEW] ACTION: david to add a communications strategy page for the TF [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action12]
[NEW] ACTION: DEzell confirm next face to face meeting [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action13]
[NEW] ACTION: dezell to work with W3C staffon contacts for IG [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action09]
[NEW] 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]
[NEW] ACTION: IJ set up survey for weekly call schedule. [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action14]
[NEW] ACTION: Laurent to create a security task force [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action01]
[NEW] 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]
[NEW] ACTION: Mario to write up one or more fraud use cases. [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action05]
[NEW] ACTION: padler to create a communications strategy task force [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action04]
[NEW] ACTION: paler to create a communications strategy task force [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action03]
[NEW] ACTION: Pat to create a communications strategy task force [recorded in http://www.w3.org/2015/02/04-wpay-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015-02-04 16:32:24 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/wow, there are lots of me//
Succeeded: s/03 February/04 February/
Succeeded: s/topic/topic?/
Succeeded: s/exmaple/example/
Succeeded: s/Spencer/Swenseid/
Succeeded: s/Swenseid/Swendseid/
Succeeded: s/focal length/VocaLink/
Succeeded: s/focal length above = Vocalink//
Succeeded: s/involve.d/involved with./
Succeeded: s/involved with/involved./
FAILED: s/There won't be a perfect matrix/We don't need (nor want to make) a complete matrix/
Succeeded: s/user/usage/
Succeeded: s/use cases./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./
Succeeded: s/Benilux/Benelux/
Succeeded: s/exapands/expands/
Succeeded: s/exacly/exact/
Succeeded: s/exact/exactly/
Succeeded: s/none/1/
Succeeded: s/Jean-Yves/cyril/
Succeeded: s/and others/and would like to have more people/
FAILED: s/,but the IG//
Succeeded: s/crypot/crypto/
Succeeded: s/global regulator/regulators from around the world/
Succeeded: s/use case/type of organization/
Succeeded: s/Locan/Local/
Succeeded: s/actorsinthis/actors in this/
Succeeded: s/amfamiiar/am familiar/
Succeeded: s/nothing solid/I don't have an outreach plan since so new I haven't thought about it/
Succeeded: s/whois Ian//
Succeeded: s/TOp/top/
Succeeded: s/~q?//
Succeeded: s/@@/The four exaples are each use cases@@/
Succeeded: s/viewpoints/viewpoints and levels of experience with payments processes. For those with less experience, more description of motivations will help to show the importance./
Succeeded: s/should/… should/
Found ScribeNick: Ian
Found ScribeNick: dsr
Found ScribeNick: Ian
Found ScribeNick: dsr
Found ScribeNick: Ian
Found ScribeNick: dsr
Found Scribe: Katie Haritos-Shea
Found ScribeNick: Ryladog
Found ScribeNick: m4nu
Found ScribeNick: m4nu
Found Scribe: chaals
Inferring ScribeNick: chaals
Found ScribeNick: m4nu
Found Scribe: chaals
Inferring ScribeNick: chaals
Scribes: Katie Haritos-Shea, chaals
ScribeNicks: Ian, dsr, Ryladog, m4nu, chaals
Present: Annette Chaals Cyril DaveR David Erik Evert Ian Istvan KAtie Manu Nick Pat Patrik Steph Vinay Wendy Joseph Jean-Yves Floris Laurent Evan Mario Eddie Joerg
Agenda: https://www.w3.org/Payments/IG/wiki/2014-02-02_Meeting_Page
Found Date: 04 Feb 2015
Guessing minutes URL: http://www.w3.org/2015/02/04-wpay-minutes.html
People with action items: chaals confirm dave david dezell ezell face for ij laurent manu mario next padler paler pat

[End of scribe.perl diagnostic output]