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.
Day 1 (Monday – Start 10:00 Local Time)
- Day’s Topics – IG Review, Use Case and Glossary Discussions
- 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
- 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.
- Appointment of Scribe
- Refining the 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.
- 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 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.
- Deeper dive on the Use Cases (continued)
- 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
Indonesisch Restaurant Borobudur
- Veemarktplein 42 (facing the Jaarbeurs)
- 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
- 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
- Continue discussion of User Payment Agent and Logical Web Payments Models
- Appointment of Scribe
- Finish discussion of User Payment Agent
- 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.
- Finish Discussion of the Roadmap Outline
- Recap/overview of Day 3
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
- 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.]
- Membership brainstorm
- 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.
- 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
- 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.
- Joseph_Luben, Erik_Anderson, David_Ezell, Ian_Jacobs, Mario_de_Armas, Laurent_Castillo, Evan_Schwartz, Stefan_Thomas, Richard_Martin, Patrick_Smets, Cyril_Vignet, Stephane_Boyera, Patrick_Adler, Eddie_Onaga, Dave_Raggett, Katie_Haritos-Shea, Charles_McCathie-Nevile, Istvan_Lajtos, Bernard_Gidon, Jean-Yves_Rossi, Manu_Sporny, Nick_Telford-Reed, Evert_Fekkes, Joerg_Heuer, Vinay_Gupta, Floris_Kleemans
David: Will work on roadmap, statement of purpose so others know what we will be doing.
Manu: +1 to grounding discussion in use cases. Then we will look at how payment agenda will address use cases, then roadmap
Joerg: On term “payment agent”…ties into user agent, but some people have concerns about that term
manu: Might be good to add to the agenda where there might be “blind spots” in the group
… topics missing from our agenda
Katie: Why is “agent” problematic?
Joerg: In EU finance industry, “agent” has been used to mean “humans” (as in “standing in for other humans”). But today I would stick to agenda in the sense we’ve meant.
Pat: E.g., is a payment agenda legally binding? These are the sorts of questions finance people might ask.
Evert: We could, e.g., in definition, talk about the other meanings in industry
steph: Another good thing to do is to ensure we have all the types of actors around the table that will be part of the payments chain
Joerg: I would like to ensure we have a sufficiently generalized view, instead of focusing on a particular payment solution
… I want to ensure we are creating a level playing field, and ensuring that all the roles can interact with one another
<wseltzer> dezell: we could be discredited for being too broad or too narrow; looking for the right spot
CMN: Let’s get to use cases. Person-to-person transfer of money is an example of a use case that we can look at – is it there, a blind spot, or out of scope. So I am hoping to get started on the agenda…
Laurent: Payment slightly different from purchasing experience
<Zakim> dezell, you wanted to talk about IRC and the queue
<Zakim> dsr, you wanted to ask if everyone would be willing to participate in a group photo at some convenient point during the face to face
David: Our activities will include outreach
… milestones for getting standards work will be milestones for WGs
<Zakim> wseltzer, you wanted to talk about w3c process
[Wendy on W3C Process]
Wendy: Team is here (not just for technical work) but to help with the procedural steps
<Zakim> chaals, you wanted to correct^W augment what Wendy said…
chaals: The IG will succeed by getting changes to the existing technology stack of the Open Web Platform
… a lot of the way to get success is to look at existing groups that are “close to what we want” and to ask them to start working on a piece missing from the stack; to join the IG and make the work happen
… it’s important that people go from IG into technical group to get stuff done
… we’ll need to work with other groups (e.g., on security)
… Charles…note that if you join a WG you operate under the W3C Patent Policy
… one advantage of moving work to an existing group is that you can get greater patent coverage (due to more participants)
Manu: Two Community Groups to keep an eye on: Web Payments Community Group; Credentials Community Group
<wseltzer> IG Charter
[Quick scan of charter]
David: Any questions about the scope of work?
<Zakim> m4nu, you wanted to note that the charter is a kitchen sink.
Ryladog: Only WGs create W3C Recommendations.
Manu: One example of CG work that advanced to a WG is JSON-LD.
… went quickly through W3C Process much faster than other specs I’ve seen. CGs can speed things up.
… there are many paths to Recommendation
Getting up to speed
<chaals> [I have seen specs go from start to Rec in one year, by having a small and clear scope… whereas my experience suggests that trying to invent technology as part of devleoping a standard is usually a recipe for taking a looong time]
ISO20022, ISO12812, X9.119 Pt 2, Web Crypto, NFC, ….
Erik: ISO20022 XML Format integral to financial services.
… nice thing about ISO20022 is how they broke down the problem to come up with a standard.
… I am reviewing business processes that went into ISO20022
… we don’t want to ignore existing standards.
IJ: Can we get permission to circulate them in Member space?
David: We got permission for staff contacts to review X9…I think they don’t have a problem with us quoting them
<evert> Maybe Committee Draft (CD) documents are available public?
Steph: We are still working on this…establishing a liaison with TC68
… we are trying to see if we can get approval to share these docs within the membership or the group…we have not yet succeeded.
Joerg: Could people who know these specs give a brief overview?
Steph: there are some docs linked from the first FTF meeting on this
<steph> documents from 1st f2f linked from https://www.w3.org/Payments/IG/wiki/Reading_List
see catalog of business processes:
scribe: these will help us categorize our use cases according to ISO organization
dezell: SEPA defined under this architecture
… so for easy acceptance, we should probably think about conforming to this model.
… for the US, the standard is 8583 (older)
… so there’s one way of doing things in US and another in Europe
… seems like 20022 is the way to go, however.
Nick: Apax standard in the UK is essentially an implementation of 8583.
<jheuer> …Is this a topic we should all know – but not necessarily _talk – about repeatedly?
evert: 8583 has been massively implemented in industry…e.g., a company like ACI is not yet 20022 oriented.
… but if you look at the business descriptions, these are fine to relate to our work.
… the business concepts are well-formulated in 20022
… the fact that 8583 organizes its message framework differently should not make much of a difference
… 8583 has three versions, all differently implemented.
… so it’s not a world of perfect interop anyway; we should focus on the business concepts
EriK: the author of 20022 works at Bloomberg now….
… I am also trying to make it easier to generate code … much of that work has already been done
<wseltzer> Reading List (wiki)
dezell: In my mind, message formats will flow over HTTP
[dezell reviews 12812 briefly]
dozen; UVM – user validation mechanism…validating a user’s identity
scribe: it’s important that we not ignore 12812
… regulatory implications are important to keep in mind
scribe: basic instructions on handling secrets (PINs and keys)
… which are used to protect sensitive information
… the bar on protection of secrets is fairly absolute
… bar on protection of sensitive information is lower but still important
scribe: they have spent decades creating APIs
… mag stripe readers, etc.
scribe: another ISO 20022 EU-focused thing
… closely aligned with SEPA
EMV Payment Tokenisation
Evert: We need to understand how the act of payment is extended with something like Apple Pay
Patrik: Apple Pay’s implementation is a variant of EMV (the one used in Europe)
Evert: Chip/Contactless happen differently at different times in different markets
laurent: Apple Pay extension to online payments also relevant for this group
Nicktr: The tokenization under Apple Pay is also an EMV spec
IJ: What else is relevant context for this work?
Joerg: Identity management
… e.g., tokens are used all over now
… moving away from session-based to token-based
… for scalability
Erik: See the recommended reading list (which came from TC 68 Chair)
dezell: X9.119 Pt 2 another tokenization standard
… Three groups to pay attention to within W3C in particular: Web Crytography WG
… chaired by Virginie Galindo, Gemalto
(Headed to Candidate Rec, for implementation testing)
<wseltzer> WebCrypto API
[Laurent gives some details on implementation status]
<wseltzer> Laurent: WebCrypto is having re-charter discussions now
dezell: Secure Element API is another topic
wseltzer: Secure Element is coming up in discussion…one of the important discussions that people can contribute to is on the question of the security model
… provisioning of authentication information from the secure element differs from the web origin-based security model
… where the origin site is the only one to have access to information that it has already sent you
… so the current question is how to bring these models together
… so that, e.g., there are not privacy leaks
… as information is exposed beyond a single web origin
Joerg: Conversations with Virginie have been around services at different layers
… is there something that has already been developed?
wseltzer: We might see a submission from some groups who have done some work in this area.
Mario: Google included host card emulation, which bypasses secure element entirely (and comes from the cloud)
Joerg: We need to have right players in the group for that discussion
… e.g., mobile operators might offer a certain level of functionality from SIM cards
… or manufacturers like Samsung, or tech vendors like AMD
… important that technology approaches are supported by business models
… e.g., we should talk to GSMA
Cyril: In Europe we have PSD 2…this directive is a new way to see the payment processor…I think this context is interesting for us to take into account
… and also the European Banking authortity is supposed to deliver a protocol between all those actors
… maybe our work could help out there.
… The term “payment” also includes various activities like initiation, clearing, etc.
… perhaps we can anticipate the work of others in our work
<dsr> See http://www.w3.org/community/trustperms/ for trust & permissions CG – a new group focusing on trust & permissions for the web platform.
Evert: we might do bindings between our terms and those of other bodies (and also differences)
<Zakim> dsr, you wanted to mention that W3C is starting a Community Group to focus o trust and permissions for the web platform
DSR: Trust model and trust allocation relevant for this group
Joerg: Permission model based on attributes is evolving.
… there is increasing use of tokens.
… identification of people is less important; people can use keys
… so when you say “permissions” that could include “one who issues tokens”
wseltzer: See earlier link to workshop on Authentication, Hardware Tokens and Beyond
… we brought together there various alliances and other hardware folks + web folks and got lots of discussion going
… that is where we are aiming to bring back the discussion for extending the web crypto WG, to charter a new WG that brings these technologies closer together
… we encourage you (and people you know who are interested) to join that work
<Zakim> m4nu, you wanted to mention that secure element, while important, shouldn’t be a blocker for this group.
manu: While secure element work is important, I would not put it in the critical path for our work
… I think this group should be thinking about 2-factor authentication
<wseltzer> [discussion of the WebCrypto recharter is on the Web Security IG list, https://lists.w3.org/Archives/Public/public-web-security/ ]
manu: we don’t need secure elements for things like digital receipts
EriK: Different types of transactions will require different approaches
Manu: I think the group needs to be considering trust and credentials (e.g., related to knowing customer, anti money laundering)
… credentials means the ability to prove you have a particular capability on the web
… e.g., I am a graduate of a particular university, or I have a passport from this or that country
… I have been trained as a plumber and have a certificate that enables me to be licensed in the state in which I am operating
… these are all very real use cases, and these are organizations in the credentials CG to try to make this happen
… the people in the CG are in education, health care, some financial
… all of them need a way to “prove who you are on the web”
… we want digital signatures on credentials to be verifiable
… if that group is successful, we will likely be able to reuse most of their work in the payments work
… groups who are in the CG: ETS (Education Testing Service)…they test 5M people a year
… they want credentials for people who are receiving new training
[Manu points to 9 use cases listed in their draft document]
-> http://opencreds.org/specs/source/use-cases/ Credentials Community Group Use Cases
Manu: For assertions like on linked in, orgs want to be able to verify
… Another use case – being able to be pseudo anonymous (e.g., showing your age without giving personally identifiable information)
… the community group would like to see W3C launch a WG within the next year to work on these use cases
<Zakim> dezell, you wanted to discuss how do we include credentials into the WP use cases
Erik: Again, need for credentials, etc. will depend on application needs
<Zakim> chaals, you wanted to ask about layering of credentials after lunch
chaals: There’s a possibility we might want to do them here, or we might say it should be done elsewhere and we will rely on them – and to make sure that is reasonable, keep a close eye to make sure we can use their work
… we might operate in parallel….I think that might be a better approach
… it saves us work and also prevents us from inventing 4 competing ID systems
Laurent: You mentioned FIDO alliance….are you in discussions with them on credentials?
Manu: I don’t personally, but we need to be aware of them
padler: I would step in between the two…there are other parts of payment where context is important (e.g., long term loyalty relationship)
… there will be an interesting line we have to walk…e.g., relying on existing systems but additional things we need to provide that are not taken into account in those identity systems we use
<Zakim> m4nu, you wanted to mention loyalty cards being credential-like.
manu: We are going to have to walk a fine line
… a loyalty card – is it a payment instrument or is it a credential?
… there are different ways to model the things we are talking about
<Zakim> steph, you wanted to ask whether this is only on users?
steph: Does creds CG look at merchant side in addition to user side?
Manu: Yes. It’s a way of verifying entities, whatever they are
… Related to this is Mozilla badge alliance initiative
… to enable students to verify classes they’ve taken
… there are hundreds of institutions who are part of that alliance, and those people are part of the CG
… we are also getting big health care companies in the group
<wseltzer> [meeting resumes after lunch]
<wseltzer> [Vinay Gupta joins]
<m4nu> scribenick: m4nu
<wseltzer> [pay-your-own dinner, 7:30 at Borobudur]
Key Principles and Desired Outcomes
dezell: This is a part of our segue into our deeper dive into use cases.
… There are use cases that we’ve thought of, and use cases that we need to discuss.
… We need to go through and talk about what people want to do in this group.
Ian: Send this to the mailing list – we need to collate the key points.
… We want to build stronger messaging to go along with that.
dezell: What do we want this group’s position to be? In our roadmap, we need to figure out what we want the message to be.
… A lot of work is driven by the members of this group. A number of people that drive outcomes will see those become the stuff that ends up being accepted.
… With that, let’s talk about key principles and outcomes.
… I’m not sure if I have any key ones in my mind.
<Ian> Manu reading from goals on -> http://www.w3.org/Payments/IG/wiki/2014-02-02_Meeting_Page#Morning_1
<wseltzer> manu: [https://www.w3.org/Payments/IG/wiki/2014-02-02_Meeting_Page#Day_1_.28Monday_-_Start_10:00_Local_Time.29 reading from bullets]
steph: I’m happy with these points – I think we should add one more point – this is part of a level playing field. I think interoperability is key.
… As a wallet provider you shouldn’t have to convince every merchant.
erik: We should adopt technologies that exist, and create only when necessary.
<chaals> [+1 to Erik – minimal creation of new technology
pat: I think +1 to steph – payment participants need to have a more level playing field. The more we can do to improve interoperability through standards, we want to have more stuff that looks like the Web.
dezell: If you want to make sure something gets into the minutes – be specific about what you want in there.
evan: The biggest goal we’re interested in speaks to interoperability, but not just interoperability of browsers and phones. People store value in many places today. It’s difficult to move value from one network to another.
<padler> participants include all players in the space… not just payment technologies providers, but also individuals, networks, etc..
<steph> +1 to evan
evan: Interoperability – not just with wallet and phone, “You accept this type of value on your payment network, I store value in a different currency on a different network” – how do I do that?
Laurent: One key principle we want to maintain – we want to be as agnostic wrt. payment technology.
<steph> +1 to be payment instrument agnostic
Laurent: We should be independent as possible – we don’t need to become the 15th payment technology – big pain point we can solve – how do you bridge gap between merchant and customer.
<Erik> +1 about ripple. Remittances is a big selling point for W3C Web Payments. For that to be successful you need to be able to move value between payment types, networks, etc
Laurent: Interoperability of the payment ecosystem – that’s not solved today.
<Zakim> dezell, you wanted to talk about ui consistency and to
dezell: One of the important bits here is to have a consistent UI experience – accessibility. We want payments to be easy for people that can’t see – that are cognitively impaired. We don’t want to only target top 3% of the world.
… There are a lot of people that can take advantage of this that may not have access.
… Getting that right is going to be hard, but it’s important.
Joerg: I support the general pattern that we need to harmonize all of this into a framework. It has a lot to do with user control.
… How can we put the user in control of all of these things. Hundreds of payment mechanisms. This has a lot to do with transparency and automation.
<padler> Interesting that if we want to stay agnostic of specific payment processes… that we may need to bring the merchant use cases up a level… in other words… instead of using the terms like consumer pays merchant… we should move towards payer pays payee…
Joerg: There are a lot of things that need to work automatically, where does that automation take place?
… Pre-configure credit card with Amazon, pre-configure payment instrument with others. When it comes to things that are sensitive, you want to be confident that any automation will work in your favor / for you.
… The convergence between proximity / real-world and the Web world is difficult. We need a few elements to make this work.
<padler> +1 to keeping an eye on convergence of proximity and purely web scenarios..
<Zakim> steph, you wanted to ask to prioritize bullet points
Joerg: Not only should this be nice from a technological perspective, but we want the social aspect of this to be good as well. We want merchants to be happy, or make their businesses better as a result of this technology.
<mario_de_armas> +1 to joerg, make it easy for consumers to change/update credentials as they need to
steph: I think it’s important, when you present the work of the group – we should communicate this well to the outside world.
<padler> +1 to steph on consistent messaging for the group..
steph: Having a flat structure is ok, but we should be clear about what’s important and not important.
<steph> steph: above all, what is our first priority vs what may come later
<padler> +1 to data portablility…
floris: There are many other types of transaction domains. We need to make sure data is portable on other services.
… Make the data useful to many different domains.
erik: It costs a lot of money to add delay to payments, let’s make sure what we do is performant.
<padler> <erik> efficiency is key… this needs to be fast!!
erik: W3C is the only organization in the world that is capable of getting this stuff into the browser, mobile, etc. Integrated everywhere. W3C has the ability to reach all these devices (and people).
dezell: The desired outcome is ubiquity?
erik: Yes, full market penetration.
<Zakim> chaals, you wanted to say “anyone can effectively use a payment, and understand what they are doing, to move (money/value/…) to another person”
<mario_de_armas> “Every one additional second at POS costs us $12 million.” Bill Simon, President Walmart US
chaals: “Anybody can effectively use a payment” – a successful system is one where you can take your money out of the system.
… Exchanging currency as a service, but getting your money and moving it elsewhere is important.
… One of the things we want to come out with is some clarity of where people can add value. For example, exchanging money.
… We want to be clear about where people can add value. You shouldn’t need 5 middle-men to exchange money.
<padler> +1 to minimizing the number of “hops” to faciltate a payment…
chaals: If we do our work right, it’ll become clear about where the value is created.
… We will get in the way of services – some services will become more or less irrelevant. If things are going away – if things are put into the Web, it might be difficult to unseat that (the Web).
<padler> As the number of hops increase… so does the risk and the inefficiency of the payment..
Katie: One of the important principles – value is from perspective of various stakeholders. Nobody should be top dog here. All stakeholders should have same opportunity.
… This has to have value to the organizations / companies / financial institutions / individuals to be involved in it. Usability, portability, responsibility.
<chaals> [As the number of hops increase, so does the opportunity to charge for them – which at one level is seen as “the value of the financial services industry”…]
dezell: Our charter only mentions two stakeholders – payers and payees. One of the value adds of this group – we’ll be able to represent other stakeholders.
… Part of value add of this group is to specify how each one of the current players justify their place in the ecosystem.
Katie: The value here is for everyone.
dezell: This is about membership – we need the right balance.
wseltzer: From a W3C perspective – bringing secure, convenient payments into the Web Platform. Web platform has demonstrated that it’s good at easy communication, easy publishing. We need to take next step – easy to participate in a transaction. Let’s make payments another aspect of Web development.
dezell: That is an educational challenge – we need this group to help us get that message out.
<Zakim> padler, you wanted to discuss the idea that the payer or payee may not be people … especially in the IOT (ex. payee pays vending platform)…
dezell: You believe W3C is important in this space because you came here – important to get that message out to the public.
pat: As things move toward Internet of Things – maybe the payer isn’t a “he” or “she”… but a thing, a car paying for a parking spot.
… We need to make sure we’re forward compatible as well as backwards compatible. We need to also pay attention to ‘hops’ – minimize the hops a payment has to go through.
dezell: The W3C has it’s own activity – Web of Things.
dsr: We do have a Web of Things IG.
pat: Payee and payer may not be the entirety of the actor – machine-to-machine payments.
dezell: We already have some use cases – the ability to sanction payments on your behalf when you’re not present.
<Ian> [In W3C parlance this is called the Principle of Least Power]
evan: As a principle – standardize as little as possible. For this group, it’s useful to layout everything in scope in this group. Some of this stuff is “boiling the ocean”. For example, commercial interaction about product is a big endeavor.
<evert> +1 tot evan
evan: That is separate from one person trying to send money to someone else.
<Ian> +1 to having this group clearly say what it considers out of scope
<Laurent_> +1 to focus and standardize as little as possible
evan: Another piece is messaging around compliance – could be in scope, could be difficult.
… Another example – the payment agent – how do you authenticate with the payment agent? If I just need to talk to my agent, that doesn’t talk about anyone else. The level of security is something I need decide w/ my payment processor, not something that needs to standardize.
… Standardize as little as possible, is important to focus on – helps prevent us from getting wrapped around the axle.
pat: There is some basic level that needs to be accounted for, it’s a delicate balance.
dezell: We want to come back to this. It’s 80/20 – the problem is one person’s 80 is another’s 20.
<chaals> [Picking how much is worth standardising is the whole art of the work we are doing]
Vinay_Gupta_E: Good to remember that these things exist: repudiable vs. non-repudiable payments. This has implications on payment mechanisms.
<padler> to repudiatable/non-repudiatable payments..
<mario_de_armas> +1 on repudiable vs. non-repudiable
Vinay_Gupta_E: Legally binding digital signatures – identity / authorization / signatures – keypair management.
… Also important – transitive trust. How do you express different types of trust mechanisms. It becomes very important in an IoT concepts. For example, how does a washing machine authorize payments? How is my identity transferred through the system?
mario_de_armas: Touching on a couple of comments. Making sure stakeholders have a level paying field.
… The customer and the merchant are the people you have to have in the payment process. I’d be concerned about being too focused on keeping existing players that don’t bring value. We want this stuff to be efficient.
<Vinay_Gupta_E> On the transitivity question “ode to the granovetter diagram” and “confused deputy” are your search terms
mario_de_armas: We want the middlemen/stakeholders to bring value.
dezell: If you give all stakeholders an equal footing, how do you know which ones are the right ones.
<Zakim> chaals, you wanted to suggest that “A successful web payment meets applicable regulatory requirements across the globe”
chaals: What are the things that define a successful payment? Standardizing too much makes it too complicated, no adoption.
… Providing too many players on the field may lead to bad things.
… We go back every few weeks/months – we need to tie down the details, ensure we’re focusing on the right things.
<mario_de_armas> technology is leading regulatory requirements
dezell: Different regulations apply in different places.
mario_de_armas: Technology leads regulations.
erik: A friendly web interface doesn’t mean you’ll meet regulatory requirements.
Martin: Another way to say it is that the system should not prevent people from meeting regulatory requirements.
<padler> Is it regulatory requirements? or moreso legal/jurisdictional requirements..
<padler> just because it is not regulated does not mean that it is legal…
erik: If you’re in China, they don’t care about things that don’t leave the country. Tiers of regulatory requirements are out of scope wrt. W3C initiative.
wseltzer: Our goal is to not interfere w/ regulatory requirements. Maybe the standards should meet regulatory requirements through a hook.
Vinay_Gupta_E: We record metadata to meet regulatory requirements, we don’t say it meets it or not.
chaals: We’re trying not to interfere. if we know we can’t meet regulatory requirements, it’s a non-starter, we known that.
dezell: This is something we should talk about. We will not knowingly violate regulatory requirements, that’s about as good as we can do.
<wseltzer> [also distinguish between spec and implementers; the implementers and users should be able to meet regulatory requirements when following our specs]
Nick: Echo the language of ‘payer’ and ‘payee’ – right now we have ‘card’ in the language.
<evanschwartz_> +1 on moving away from the language of cards
Nick: About incumbents – we need stuff we can implement. We want actionable vs. aspirational.
<padler> +1 on moving away from a particular payment scheme (eg. cards)
Nick: Actionability is what we want.
<evanschwartz_> actionability + standards that entities actually have _incentives_ to adopt
<chaals> ACTION: Chaals to pull out a new list of requirements from the starting list plus this session. [recorded in http://www.w3.org/2015/02/02-wpay-minutes.html#action01]
<trackbot> Created ACTION-51 – Pull out a new list of requirements from the starting list plus this session. [on Charles McCathie Nevile – due 2015-02-09].
Cyril: There are other transactions that lead to a credential – one of the major confirmation point – we have seen a lot of payment systems. push-payments push fraud outside for later. It’s more than just ‘stolen cards’ – it’s about fraud.
<chaals> [+1 to Cyril’s point on transparency of cost – which I think is tied into the idea that people understand what they are doing when they make a payment]
Cyril: We need transparency on the fees. We talk about value that we bring, but transparency of fees – fairness of competition. Often, person-to-person payment is fine, except for the person that receives the money (remittance fees are very high).
… Sometimes, some transparency is needed – payment should be something you buy.
Katie: I agree
… This is a standards body – long-term you have to have something that countries can build. Ultimate goal is to have something that is generally agreed wrt. good way to go.
evan: There are a lot of different pieces to the process – only some of them are worth standardizing.
<Zakim> dsr, you wanted to enable value added services on behalf of end users, e.g. based upon access to standardized receipts, or facilitating user preferences relating to discount
dsr: Value-added services for end users – if a user wants to buy something, they want a 3rd party to help them with that.
… You want what you want, not what someone else wants for you.
… What do the end users expect? What value do they want?
Joerg: We want to make things more efficient than they are now. Worked with someone that worked at cashless for Aldi. The biggest thing in their world was a big clock on how much time it would consume.
… If we reduce the time in the queue, at the payment terminal, they could make use of that. They don’t do loyalty cards because it takes too much time. Loss of time, new opportunities if we can make things more efficient.
… Rather than minimize things, if there is half a second we can save – there would be new ways of making things more efficient.
Ian: This is very helpful for me as a new person – pasting something into IRC.
<Ian> * Increased security, privacy
<Ian> * Cross platform interoperability
<Ian> * Data Portability
<Ian> * Opportunities to add value
<Ian> * Reduce hops
<Ian> * Faster payments
<Ian> * Convergence of online and in-store
<Ian> Constraints on the system
<Ian> * Repudiable
<Ian> * Support for legally binding digital services
<Ian> * Enables people to meet regulatory requirements
<Ian> * Payment technology agnostic
<Ian> Scope (and out of scope / principle of least power)
<Ian> * Focus on payer / payee (abstractions) and not other parties (as much)
<Ian> * Exchange of value between parties
<Ian> …but not focused on, e.g., local interactions between myself and my agenda
Ian: I want to help all of us communicate our work – we want data security, privacy, faster payments… things we want.
… I also started to hear actual restrictions on the system – what properties the system should have.
… I also started hearing stuff about scope…
… Let’s not dive into the needs of every other party – focus on exchange of value between parties – what goes over the wire and it is interoperable.
… What we produce will conform to the constraints, here’s what we’re trying to do – we don’t want to boil the ocean.
dezell: One landmine – in financial services business – this is a renegade position – focus on payer / payee – it’s okay to have this position, but we need clear communication on why that’s ok.
pat: Going back to regulatory aspect – payments will happen in certain jurisdictions – say sending payment from US to Europe, you have to support super-set of what you need on both sides to meet regulatory.
… Those that need to know need to be able to audit payments. Payee wants a log of everything they’ve been buying.
Katie: What 25 things did I sign up for over the last few months?
<Ian> [IJ heard form use cases that there are audibility of payments….e.g., pseudo-anonymous payments]
Vinay_Gupta_E: What about saying “We won’t do payments that are evil?” (joke)
Laughing in the group.
Laurent: Mostly I’m hearing about two trends – people that want to standardize payers/payees (the exchange) – support all payment instruments in a harmless way.
<padler> correction… not to meet regulatory requirements.. more important to meet jurisdictional requirements…
Laurent: Then there are people that want to standardize universal payment instrument – those are the two trends I’m hearing – they’re independent.
… I like the first one, it’s the best place to get results quickly – trigger a payment in a universal way – easier than trying to define a single universal payment instrument.
<padler> for example if the payee’s jurisdiction requires more data than the payers, then the payer would need to provide more data than normally they might..
Laurent: Payment processor, payment provider, trying to standardize universal payment instrument would be very difficult
… Standardize stuff between merchant / customer – biggest bang for buck.
dezell: Non-goal – we don’t want one standard way of making payments – we’re not going to say “Tokenization is the way to go”
… We’re going to say “here’s how you do tokenization.” if you disagree, send it to the email list.
<padler> would that be standardizing stuff between payer/payee? vs. between merchant/customer?
dezell: End of queue, here’s what we want from the group: Send what you want to the mailing list.
… Please repeat yourself – put it in something actionable.
… We want to put this on future agendas.
Joerg: Easier to understand some of this with a demo – if you want a demo, let me know.
dezell: Let’s go through your demo tomorrow.
<chaals> scribe: chaals
Review of essential goals
DE: For the rest of the meeting we are trying to address the essential goals. If you think we are going off-track any time is a good time to say so.
… First: Use cases. That’s what we are doing now.
… You should be thinking of what use cases are missing. High level overview, then deeper into what we have done.
… Tomorrow we will look at what payment agent tf has done. A series of processes and potential APIs – a model that helps inform use cases and relationship t o the open web platform.
… on wednesday we look to creating a document that will be an IG Note published at W3C, describing what we are doing.
… The use cases, after the discussion and refinement, should become a Public Working Draft in the near future.
… That requires Group Consensus. And we want to have an outline or editors’ draft for the roadmap.
… We’ll also talk on teh last day about gaps in the group – what sort of people we need to get into the discussion.
<wseltzer> Use Cases TF wiki
-> https://www.w3.org/Payments/IG/wiki/Use_Cases_Task_Force use cases page
MS: At the first workshop there was a use case scribe – specifically trying to pick use cases out of the conversation,
… in the Web Payments CG, we refined and developed these (and dropped some that seemed way out of scope)
… and then put them back into the Task Force doc.
… There are 4 approved to go in the FPWD.
… (By the Task Force – i.e. we as a whole group could push back on the decision, which is ours to make finally)
… There are a number that are ready to go – have examples, requirements, etc. Those are the ones we should start with today.
… And then there are some in the middle that are only half-done so far.
… Does the structure make sense?
MS: I have a number I think are critical…
… there are others that are high priority but not done. Digital receipts and all that goes with it is pretty important – should we try to get as many in, or focus on key phases of payment.
DE: Does any of the content cause pain or suffering?
Laurent: On some we have to review the wording…
… you have to provide a choice of payment instrument, but not all use cases reflect that.
… e.g. purcahse request discusses payment processor.
MS: CHoice of payment instrument is in there…
Laurent: Yeah, but others that should use purchase instrument talk instead about buyer’s payment processor.
MS: They are intended to say that, so we should discuss the issue.
… How strongly do we push the idea of you choosing payment process, vs merchant, or …
… We’ve been promoting push-based payment and not looked carefully at 4-corner payments. I suspect card companies won’t love that approach.
… Push-based model is that you register your card with you provider, and that info doesn’t get passed directly to the merchant.
<Zakim> wseltzer, you wanted to ask how you prefer input
WS: What is the process to add to the use cases?
MS: Write into the Wiki. There is a feedback section, where you can raise issues…
… it is better to get stuff into the wiki so it doesn’t get lost.
DE: Hoping for a rubber stamp for those 4, but it’s good that we see the issues.
[Ian shows 2+2=5
Steph: Comments on choice fo payment instrument. Is this highlighting the interoperability of a wallet – you can negotiate different instruments if your wallet isn’t the one the merchant supports, or is it at a higher level?
… Covering both, or only the case where you pay with visa/MC/Paypal?
DE: Will q to answer
IJ: I don’t object to extensibility but it doesn’t explain what the value of making things extensible is.
… i.e. why do that work?
… (appears in various places)
IJ: Please use RFC2119 terms consistently.
… Choice of payment instrument… I circled the box “registered” – what does it mean in this context?
… where is the registry?
MS: No central registry, your device / agent understands what instruments you have, what the merchant is willing to accept, and looks for a union.
IJ: I don’t know that I understand the 1st 2 bullets yet.
… Last bullet builds list of preferred. Semi-automatic preference selection seems like a separate use case.
JH: I would take them apart. Talking about the automation isn’t something W3C should be trying to standardise.
… But the ability to choose, yes.
DE: I think we will have achieved success if we leave maximum ability to implementors to do things well.
IJ: We can say “our minimum thing is: ‘you have to allow people to choose'”.
… scope notes might be helpful like that.
IJ: Would be nice to note security / privacy implications in each use case.
<jheuer> Second the idea to not get involved with automation of payment instrument choice – it’s going to be a matter for business models and much interest in the ecosystem
Laurent: We should look at both 3- and 4-corner payment model.
<wseltzer> [I added some questions to the push-based feedback]
… the use case has only one 3-corner case, we could add a 4-corner case.
… choice of instrument is 3- and 4- corner. The others are 3-corner. Maybe we can specify different cases for each model…
<scribe> ACTION: Laurent to review purchase request use case [recorded in http://www.w3.org/2015/02/02-wpay-minutes.html#action02]
<trackbot> Created ACTION-52 – Review purchase request use case [on Laurent Castillo – due 2015-02-09].
MS: There are two things to do here. One is determine whether the use case is in scope, the other is to look at the use cases in detail.
Laurent: Is 3- and 4-corner in the glossary yet?
<Ian> (+1 to putting 3- 4- corner in the glossary)
[No, but there is a diagram that can go in the glossary]
MS: Do we want to support teh 4-corner model at all?
Laurent: Yes. Impact of moving evertything to 3-corner model is a massive amount of work, so will delay us significantly at best.
MS: Sure. But then we are standardising an inherently insecure model…
… unless we have tokenisation
Laurent: Not necessarily, there are other ways to do it securely.
… does have good property of separating user and merchant sides, so you don’t depend on a central processor.
… has some advantages. Not so insecure, if…
<Ian> Laurent: W3C should not choose the payment method…there are too many choices available
… You need a strong credential to make it work. But W3C shouldn’t try to make this choice for the industry, be agnostic
JH: Would it be OK to say we are targeting solutions that make 3-corner models possible but doesn’t exclude 4-corner models?
JH: We should not exclude 4-corner models
MS: Agree. Concern is making it easy to transmit card nmbers and having emrchants store them. If we succeed in 4-corner we can fully-automate that really dumb model.
… You are arguing that we shouldn’t automate that process, but we need to be really clear about the distinction in the use case.
Laurent: Can come with omplementation constraints.
IJ: If it is in scope to do both, it is helpful to call out implementers.
Mario: There is a principle of merchant not storing credentials.
MS: We provide mechanism so merchants don’t need ot store credentials
CV: If we look at what there is, how many 3-corner models, how many 4-corners are out there today?
…at the end of the dayt we have to think about where is the money.
<Ian> IJ: I like the idea of staying at a high level “Improved security/privacy” and then we say there are some pieces to this like not storing user credentials on merchant side. And then what are the constraints that derive from that. And then what solutions satisfy those constraints.
… we cannot just invent initiation of payment, at the end of the day we have to move funds.
… Push payment is more like credit transfer.
… We have to cope with credit transfer, direct debit, and others. If we say we always want 3-corner model, we cannot just put the payment in because the funds have to be tranferred. And that doesn’t work yet.
… I don’t know what is a payment processor today.
… Payment processor is written by acquirer. That’s not the only way. In the use case we have to figure out when the clearing and settlement happens.
… If we send to a payment processor, they need to take information and do stuff, and this should be covered. We cannot just stop at initiation.
… (because it won’t be implementable)
… For me payment processor is important. There are few push-based systems.
DE: Is that something that should be entered as a comment in the use case wiki?
MS: When things are in the FPWD doc, questions should be clearly outlined as issues in the document.
… it isn’t clear how we express need for 3- and 4-corner models. So to publish FPWD we have to label it as an issue. And we need 3-corner and 4-corner model in the glossary
DE: We were supposed to talk about Glossary. We’ll do that some time.
Steph: My question is whether you want to mix payment instrument and wallet, or you have a system with sets of instruments in a wallet, and you look for matches of one of the instruments in your wallet.
DE: It’s a matching of what payeres and payees are willing to do. In simplest, merchant says what they accept, you decide what you offer.
… there needs to be an exchange of information, and that’s I think what the use case says.
<Ian> +1 to another use case
SB: Think we should create another use case on wallet interop or include it here, but I think that is part of the bullet we discussed this morning so it is important to highlight that explicitly.
MS: I think what we have is merchant says “I accept A,B,C”. client says “I have B and C” and picks one.
SB: Today you go to a site, and can choose between payment instrument and wallter. Either that is one use case, or there is a narrow version – instruments, but not wallet. That’s how you make interop between wallets.
DE: I would say that is between payment agent and merchant. Which choices line up, which is best (without distinguishing wallets and payment instruments as different)
SB: E.g. example – I have iufyb wallet that supports visa and mastercard, and merchant doesn’t know lufyb but happily accepts visa or mastercard.
Laurent: SO in this case you display to user that there is a match on the visa/mastercards
<scribe> ACTION: Laurent clarify use case for choice of payment instruments. [recorded in http://www.w3.org/2015/02/02-wpay-minutes.html#action03]
<trackbot> Created ACTION-53 – Clarify use case for choice of payment instruments. [on Laurent Castillo – due 2015-02-09].
MS: Best approach is to send it to the mailing list as review comments. Please be very specific about exact text changes.
DE: Start your email subject with “[use case]”
VG: ANyone worked with XML??I from 15 years ago? Maybe we can salvage some of that stuff, and bring it to a modern format
<scribe> ACTION: Vinay check whether there is salvageable stuff on XML-EDI for us [recorded in http://www.w3.org/2015/02/02-wpay-minutes.html#action04]
<trackbot> Error finding ‘Vinay’. You can review and register nicknames at <http://www.w3.org/Payments/IG/track/users>.
NM: Apologies. There is a lot of heat in 3- / 4- corner debate. You can decouple credentials from payment. I think 3-corner is a special case of 4-corner. Heart of this is to define the actors properly, and I don’t think we have done that yet and this is leading to confusion in the discussion.
<Ian> +1 to understanding the roles really clearly
Laurent: Agree that diff between 3- and 4- is who is pushing the request. In 3 it is the customer, in 4- it is the merchant.
Nick: Zap is a 4-corner push model launching in the UK.
<Ian> (QUESTION: Is “double blind” a constraint anywhere?)
… we need to deal with credentials flow, 3- and 4- corner. But we need to decompose what all the roles are.
DE: We took a stab at that in the initial glossary. If we normalise the glossary, can we agree that the first 4 use cases should be there?
MS: I am concerned now, more than I was. Not being able to get through the 4 that we approved, the glossary discussion could kill us.
… We can have faith in the group to get the glossary right, look at use cases roughly, and go with it, or we can go headlong into the glossary now.
DE: Maybe others will get the fear of going forever, and will try not to be too long-winded. I suggest we start with approval of the 4 use cases, and then do glossary.
EA: Or we can adopt ISO-20022 glossary.
<Zakim> jheuer, you wanted to comment on naming
<Zakim> chaals, you wanted to suggest we revice merchant detail storage.
JH: WOuld like to see us take a look at the payment process from the user side, payer side, and checking up with the standards and models. I think we can do that with the expertise here. I would be scared to do it the other way around.
… If we start by unifying the experience from user side, we will come to a model…
… if we don’t need something, I would be happy to hear that it isn’t useful.
[scribe doesn’t think the last line captures well what was said]
… start with the user view. I think the purchase request is a bit misleading. Purchase implies receving something in return, that might be wrong.
DE: In proposed FPWD draft it says “payment”
<m4nu> Here’s the FPWD draft: https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html
<Ian> scribenick: Ian
chaals: We may want to revise the “remove storage of the details from the merchant” to making something that is “enabled”. In other words, we want to enable, not require
<m4nu> chaals: We may want to revise the remove storage of payment details from the merchant.
<scribe> scribenick: chaos
<chaals> CMN: We should rvise the “remove credentials from the merchant” to simply enable that (with security/privacy notes on why)
<chaals> scribnick: chaals.
<chaals> scribenick: chaals
KHS: If we agree that each use case should address 3- and 4- corner models, maybe we can avoid glossary discussion in advance. And do we want to split use cases to give examples of each.
… The wallet is our vehicle for payment instruments.
VG: Lot of mechanisms we are discussing are parallel things that exist inside cryptocurrency instruments.
… so there is something odd about the pushing of notifications vs the formal mechanism of payment. I wonderif the fuzziness there is generating some of the confusion.
<Ian> VG: Pushing around messages v. actual payment v. choreography of user consent
… There are elements that look like a tangle.
… messaging without transitive trust is different from doing it with it.
… Wonder if we should spearate generic messaging stuff from payment-specific pieces
PA: That’s important. the point where the execution happens is different.
… in cryptocurrencies it is from the payer, in current systems it comes from the payee.
… there are 3 actors (at elast). Each of them can execute overlapping parts of the use cases.
IJ: I started to draw these and they are helpful to understand.
PA: That is where this is going. You have 3 actors, and you see how they are done.
IJ: I wanted to see the use cases as specialisations of the core use cases.
DE: We have some candidate diagrams – they may or may not suit.
<Zakim> chaals, you wanted to prpose a straw poll
<m4nu> chaals: I suggest a straw poll – “We will accept these items in the FPWD, you can still raise issues on them.”
<m4nu> chaals: Diagrams are helpful – also write down the description below the diagram.
<Zakim> Ian, you wanted to mention point of order on publishing
IJ: A First draft can be edited…
<Ian> PROPOSED: Accept purchase_request, push-based, choose of payment, pre-authorization for FPWD
RESOLUTION: The FPWD will include the 4 use cases included.
[10 minute break]
<m4nu> scribenick: m4nu
dezell: We need to look at glossary now. It’s not necessary that we agree to everything – it’s important that we agree to use the terms in a definite way.
… We can say “not everyone understands this term”. Any one in here can defeat us utterly in what we’re going to try and do here.
… Let’s try and start with the roles.
… We have a 40 minute time box.
evert: A couple of slides – putting the roles into context – three and four corner models.
… Payment Scheme – everything is optional except for consumer and merchant.
… a payment scheme is required to make sure that everyone is keeping to the roles.
… Disputes are being settled, etc. From a legislative approach.
… Clearing and settlement – card schemes usually do that – but recently unbundling of scheme and processor happens.
… There is a issuing processor, acquiring processor and a switch processor.
… There is a thin line between acquiring processor and payment service provider.
… Value Added Services – those are where everyone makes the money (joke).
… EMV definitions – let’s see if there are multiple interpretations on those roles. This is the cards model, but it’s flexible enough for a realtime payments model.
Cyril: Does iDeaL work on t his model?
evert: iDeal does work on this model. It doesn’t use the card networks – it has a proprietary clearing system. Credit transfer is moved to acquirer to merchant.
… IDeal in itself is a four-party model – but the transaction is a credit model, not a card model.
… This is important – push vs. pull payments – whether we define the payment as a whole – including initiation/authorization phases, or just the moving of money.
… PayPal – is it a scheme or not? They started their business with their own accounts – consumers found it hard to put money into multiple wallets.
… you can still have a balance at paypal – if you pay via PayPal in the Netherlands, you use credit transfer. It’s a very flexible model because of a 3 party model.
… This approach has a price – it’s a 7 party model. The agility that the 3 party model, with the reach of the 4 party model – but it has costs and fees associated with it. Looking forward with Web Payments, these are fairly straightforward models – but neither 3 party or 4 party will work for all payment scenarios.
… Before going into glossary, last slide – phases of an economic transaction.
… If you look to economic transaction – the buying process, payment initiation, purchase request/payment request.
… First step is to do identification/authentication. What token is being used? Account that must be debited? Is the owner of the token complying with the transaction?
… Does the payment provider agree with the transaction? In my day to day retail activities, you get a long sheet of paper. Order lines, optional step. It can be a part of the data that we exchange.
… You can’t leak this data.
… There can also be a contract – if I pay at point of sale, I might get into a contract – you send a payment instruction to the bank. Direct debit, the money can be pulled back. If you have a smart contract that can describe what was bought, at what time, that can be pushed to an agent that fulfills the financial act when required.
… When you’ve bought something, you have an amount due. Then the next step – value added services. If these are food stamps, you can’t buy alcohol with it. Coupons expire, etc.
… order lines are required input for value-added services.
… could be rebate, could be partial payments, payment instruments and technology – you could initiate the processing of the contract.
… Depending on the scheme model, clearing happens after that.
<Ian> Evert: This can be used to organize use cases
<Vinay_Gupta_E> I think you might find this all a lot easier with smart contracts. Ahem.
evert: I wanted to organize use cases w/ examples on major steps. The phases of the payment transaction.
Katie: Where is records management? How do you have an audit trail?
evert: Everywhere, pretty much.
… We must be clear that order lines are not payment related. They are input for value added services.
… The middle column is out of the payment scope – value added services.
Katie: VAS is a part of the privacy discussion.
evert: I have put this diagram in the glossary.
… The glossary work was supposed to be on mailing list interactions.
… In the work I envisage on the glossary, I’d like to structure it w/ elements of these diagrams.
dezell: This is a three step diagram?
evert: it’s meant as a scoping discussion.
Cyril: We don’t see the actors in this group.
dezell: The actors exist in the other document – in the glossary.
Cyril: The diagram is misleading – all the steps are not exactly the same. Based on clearing mechanism, authentication method, etc. Authentication process at this step is important.
<Zakim> m4nu, you wanted to speak in favor of terms for glossary
<Ian> scribenick: Ian
Manu: I thought that the diagram is great…we should have it in the glossary and use the diagram as the basis
… Same thing as the “phases”
… I didn’t see anything controversial there
… Suggest a simple question put to the group to accept the diagram as shape of glossary
<Zakim> dezell, you wanted to ask about accuracy of 3-party model
Nick: Like the diagram….maybe call out the “accounts”
… there might be a processor facilitating movement of funds among accounts
<m4nu> Nick: I like the first diagram – the movement of money is done by additional actors in that space. The consumer has a bank account, the merchant has a bank account, the acquirer and issuer does. So there are two more towers – but, I like this diagram.
Nick: apart from adding those on the wings, I like the diagram
<m4nu> dezell: We need a better discussion on the payment steps – some or all of them may apply.
dezell: We need a better description of the payment steps; manu has an alternative
<scribe> scribenick: m4nu
Ian: When we have a verb like ‘authentication’ and ‘authorization’, it’s nice to know who does those verbs from the roles.
… We should have a nice glossary – nice set of roles/verbs, we need that – how they interrelate.
… In some cases, the use cases might straddle bits of this. Can we carve out use cases so they don’t overlap. We could make them simpler that way.
evert: We have to see how this works out – still unknown territory.
padler: A couple of quick thoughts – diagram is great. Certain parts of use cases are symmetrical. The part of the diagram that we react to – issuer and acquirer – maybe we can simplify them to ‘payers financial institution’ and ‘payees financial institution’.
padler: What about the forgotten phone use case? I don’t personally have anything – the payee enters all information by themselves. Payee is entering information at point of sale.
… Are we supporting a bi-modal set of use cases – part of the transaction is digital, part of it isn’t.
evert: It depends on the risk – designed to work anywhere, but it’s about risk management.
… A keyed transaction – account data has been typed in – a higher risk transaction.
… Enter data proven to be entered into your passport. If you look to scoping, that shouldn’t be in the standard. Extra services provided b y the different schemes.
evert: if you look to 3D Secure, each issuing financial institution may decide on its own model. Some banks choose different authentication mechanisms.
… The standard in itself allows for variations.
padler: Does the entire transaction need to be on the Web, or not? I’m presenting cash at POS, it’s being recorded in the event that I need a refund at a later date.
evert: We should be very careful here – if we want to facilitate payments, we need to know the attributes of price, whether we need to send price, etc.
… non-repudiable transactions – you have to prove that a payer was with a transaction, everything in the middle (value-added services) is unnecessary.
padler: Are these steps here required? Require that the payer enter their data? Use Case where we invoice and product comes 30 days later?
evert: Are we enabling economic transactions or economic payments?
padler: Are we allowing payer to enter 100% of the information, even when there are people involved.
<Ian> +1 (again) to clarifying scope in the work of the group (through use cases to start)
Vinay: Those include some chain of manual entry. It feels like there is an implicit set of changes here – are we doing something simple here, or are we in something so complex that we might as well do all of this stuff with smart contracts?
… Do we want to solve for the general case? or solve for all these other complex cases?
dezell: We have some general principles that have come out of this discussion. You need to be activists wrt. what you don’t like.
nick: How do you want us to make these changes?
evert: I’ll try to find time in the next few days to work on this. We need to scrutinize more – let’s try to implement a couple of things – how to put this terminology in. Can we identify where we can focus discussion.
<Ian> +1 to lovely integration of diagram(s), use cases, glossary
evert: This needs a bit of cleaning up.
<dezell> ACTION: Evert to revise the glossary per the discussion at the f2f, and let us know when season opens on comments. [recorded in http://www.w3.org/2015/02/02-wpay-minutes.html#action05]
<trackbot> Created ACTION-54 – Revise the glossary per the discussion at the f2f, and let us know when season opens on comments. [on Evert Fekkes – due 2015-02-09].
dezell: Let us know when it’s time to comment on the glossary again.
steph: I like the diagram, comment on privacy and how we fit privacy in this?
… Based on the discussion we had in Santa Clara – how do we fit this privacy in diagram – who has access to what?
evert: There’s nothing in the diagram that addresses that now – maybe that should be in the use case description. Interactions on diagrams should be expressed in use cases.
… This data is considered private – I don’t think they should go in the glossary.
steph: Items in the bill vs. amount.
evert: I’ve bought a car, milk, etc. The amount is a different element. order lines are sent to value-added services. it doesn’t know value-added services portion.
Laurent: I like the diagrams – couldn’t find anything to add/remove – perfect (joke)
Laughing from the group.
Laurent: Since we’re trying to build a complete picture – what the merchant really needs is an account reference. The real one, what you need to authentication – customer is the issuer in that model. Add identification box in that model.
evert: my initial goal with the diagram was to discuss with people – order lines are not in there. We need to think about how we model that.
chaals: I like first diagram, it would be useful to show where the money goes in the diagram. Cash is a three-corner system – third corner is the central government.
… Helpful in glossary to explain the flow of cash – cash is a payment scheme.
… I don’t like the second diagram – shouldn’t be in glossary.
… You should take a couple of the example transactions – here is a transaction, here’s another one, invoice and payment, value added scheme changing currency – show that.
… Lay those diagrams out first.
dezell: We have these alternative payment steps that Manu did a while ago.
chaals: Let’s start putting those diagrams together.
Joerg: I like the first diagram – wouldn’t like it to be the basis for the glossary – it’s a specialization of a generic vocabulary. This is the monetary part of the payment thing. it’s not for the presentment of the loyalty card, etc. My basis, looking at things, what’s the user experience.
… If I provide something to a clerk or a web shop – it’s something that could be out of order, how it’s processed later on – positive effect of layering something. How are the payment instruments being layered?
… If I want something, as a customer, I put it on the table and pay for it. In terms of vocabulary, I’d like to come up with generic terms where we need them, I’d rather go for generic terms and use them instead of the specific ones.
… We have terms like ‘agent’ and so on – some of the models might appear in the glossary – they should create one picture?
<CyrilV> this is not “payment vocabulary”, it is “card payment vocabulary”
Joerg: if I look into loyalty stuff, or tickets – it’s a three-corner model.
… There are also loyalty schemes that work in the four corner model. No one would say ‘acquirer’ there.
dezell: Could we just call it an industry standard – what people call it today?
Joerg: It think the only thing that creates an issue is the acquierer.
evert: If both acquirer and issuer are the same, then it’s a 3 party model.
mario_de_armas: The examples of the models vary by country, but this definition captures it.
<Ian> Mario: +1 to the diagram
Katie: Document-specific, glossary is something we add? Specific to documentation that we use. We want to identify where each term comes from – ISO20022, etc. Have we defined it? Have we gotten it from elsewhere?
… The references to each and every one – where did they come from?
evert: I’ve already done that – said where things came from
<Ian> +1 to good documentation of origins when stolen from other places
evert: Definition, references – we need to refer to official definitions.
Vinay: It’s complicated, maybe we should make it generally programmable.
Ian: I like small diagrams to illustrate each use case. When you see them side-by-side, it helps to make you understand. It helps make the content concrete.
… We may want to identify the things that are handed off from one item to another…
… Privacy was cited as a value-added service at some point.
Katie: I think privacy concerns would be most interesting to discuss.
Ian: Privacy and security considerations are good – potential value-adds would be good to discuss as well.
… Industry might want potential value-adds.
<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
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
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
<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
<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
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.
<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.
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?
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?
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?
Pat: certain capabilities can only be accessed from the local device
Joerg: this could defined by other orgs than W3C, e.g. GSMA
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.
<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
… 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
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.
<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
<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+
<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
<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
<Ian> scribenick: evanschwartz
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.
… iprovements in the knowledge model. There are good ideas, but inconsistencies.
… will ask my people to help.
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.
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
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
<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 –
<stephane> -1 to marketing sheet only
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
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.
<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….
<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.
<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
<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
<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
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/
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.
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
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> 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)
<dsr> scribenick: dsr
Topic Use cases
Manu: I will quickly run though them one by one.
[too fast for scribe]
<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.
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?
<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
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
<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> -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
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
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> (re: mozilla)
EA: Have we had contact with the large wallets and crypto-currency folks?
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
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.
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
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.
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?
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
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.
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
<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
… 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)]
… 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”
<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
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
DE: Date we want to aim for?
MS: March 1?
IJ: what is the milestone?
… 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.
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?
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…
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].
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.