Web Payments IG FTF Meeting

Regulatory Landscape Update

<Ian> Jean-Yves' slides

<Ian> scribe: Ian

Three goals: awareness (of regulators), alignment (of spec with regulation), guidance (to developers)

Deliverables:

* regulator-friendly description of W3C APIs

* checklist of regulatory themes

* jurisdiction inventories

* guidance to developers

<dezell> ian: We have some experience that this work, especially on the flow, is useful.

<dezell> ian: I had a meeting with European Central banks a couple of weeks ago, and the flows helped direct conversation.

jyr: (On jurisdiction summaries)

Sepa example

jyr: Jurisdiction summaries are meant to be starting points, they won't be exhaustive

regulatory themes

(The text on the screen is hard to read; see the wiki page)

jyr: Questions for the IG:

* How does the flow analysis look? What does it need?

* Do you have any contacts we can reach out to

<Zakim> manu, you wanted to ask about how often we should be meeting, face-to-face, with regulators? When would that happen? What's the plan?

manu: Ian made a comment where he had someone respond from a regulator to look at a spec; seems like a good thing to focus on.
... I want to ensure that the regulatory discussions are related to the WG
... how can we stay close to the WG's work?
... it seems like we should identify engineers at regulators to get reviews

Guy: To help the regulators....need to show "things that were already considered"
... that will help stimulate their thoughts
... starting with a blank sheet of paper will be harder for them

<Zakim> vkuntz, you wanted to indicate that requirements are two-fold: compliance with the regulation and regulatory reporting

vkuntz: You have 2 dimensions (1) compliance (2) reporting
... there are different requirements for each
... and we've not targeted reporting in our WG disucssions
... people are moving in the direction of standardized reporting (e.g., benchmark) using ISO 20022

Guy: A large percentage of my group's time at the Fed is to advocate for ISO 20022
... card messaging is not yet in ISO 20022...still in process

<Zakim> jeff, you wanted to ask what are the 1-3 biggest issues related to regulation that we would ask the CG to address

Jeff: It would be helpful to articulate what we think the most important regulatory intersections are.

jyr: One question is "do we have everything we need to fulfill reporting requirements"

<dezell> ian: I think we're teasing out the details in a series of discussions.

<dezell> ian: we discussed "other work" for the regulatory tf such as convening meetings of people interested in this topic. Maybe a CG would enable others to participate in those discussions.

<dezell> ian: first I'd like the tf to raise issues on the spec (before we're done).

<jeff> Jean-Yves: Reporting is an example of a specific that we can ask regulators - does our spec have sufficient information about reporting to meet regulatory needs?

<dezell> ian: later we can do things like produce "developer guidance" and have external discussions with fido/gsma/pci etc.

<GuyB> Comment on how to bring it to the regulators

magda: How is this going to be maintained over time
... how are we going to feed back information to the groups / documentation

jyr: Ian and I discussed this

<GuyB> It will be important to clearly state what is in scope of the API to avoid lengthy discussions with regulators that are not applicable

<Ian to Guy> The FlowAnalysis doc attempts to answer that question.

jyr: creating a "network" of people interested can help with that

jeff: In general, W3C does maintenance of its Recommendations...

<Zakim> dezell, you wanted to ask about balance between advance work (templates?) and github issues for the WG.

dezell: Thanks Ian for work on the flows...and JY

<Zakim> manu, you wanted to mention PCI wrt. building products around Web Payments APIs and what feedback we'd like wrt. PCI folks.

Manu: On PCI compliance...
... there are shorter term and longer term concerns
... e.g., I think reporting may be longer term (but others may not agree with that assessment)

Manu: we want to know about the PCI ramifications
... in the short term

<Magda> +1 to Manu's comments on PCI vs Reporting prioritization

<Ian> (We have started FAQ on rules and regulatory issues in developer portal.)

<GuyB> Should internal U.S. Gov't payment requirements be considered. They may have very specific requirements. The Mpls Fed could look into this

<GuyB> comment on scope and regulatory discussion

<dezell> ian: my next meeting with PCI is in 2 weeks.

<dezell> ian: since PCI starts with data that you have, a preliminary view is that compliance may not be affected (to be discussed, as I said).

<dezell> ian: What other things are as important as PCI?

vkuntz: Some countries have currency controls

<Magda> Suggestion: perhaps more robust commenting should be in the API about regulation compliance with a link back to flows Ian put together and similar pages.

vkuntz: you cannot initiate a payment e.g., before a contract has been registered (e.g, Brazil, Russia)

jyr: We want to provide answers to developers, and have our answers checked by, for example, PCI

<GuyB> PCI DSS is only one component of PCI

<GuyB> PCI Payment covers any application that handles payments

<Ian> We address this question in the FAQ: If a merchant develops a payment app that handles card payments what are the merchant’s obligations regarding PCI DSS and PA-DSS for that payment app?" by linking to the PCI FAQ.

<GuyB> Many of the topics thus far seem to be talking about an application level above the API. Clearly defining the narrow scope of the API may significantly reduce the regulatory relavency

Pat: it seems to me like we are asking for feedback from regulators on the APIs. What I worry about is that the regulations across the globe are not the same. Want to avoid bloat
... question is whether we should think about whether the merchant can specify a regulatory framework.
... if the merchant says "I am in Illinois" then context could determine what data is required
... my plea is to keep the API small so that it can be reused

<Zakim> padler, you wanted to pose idea on "pluggable" reporting/regulatory information needs

guyB: It's important to know what the API DOES NOT do
... that scoping is important and a lot of other regulatory issues fall away

padler: One part is scoping the API narrowly (to foster reuse) and "plug-ins" to make it easier to comply with different regulatory frameworks

<manu> Ian: Regarding Magda's question about maintenance: One of the things I'd like to do is produce as few deliverables as possible. I expect to continue to focus on (1) the FlowAnalysis as a way to raise awareness and get feedback on the spec and (2) the FAQ, including info for developers.

jeff: Regarding Pat's comments on "plug-ins"...I agree that we should make sure that the spec does not become bloated
... I also think it's useful if we document what the issues are (even if corner cases)
... do we need a regulatory wrapper API that helps adoption in some jurisdictions?

<dezell> it's important to consider minimizing the footprint (avoiding reg conflicts) but we also need to consider "what might be missing," e.g. AML required fields.

padler: A standard way to plug in would be useful....even if there is variability

<Zakim> GuyB, you wanted to comment on David's comments on ISO 20022 and AML, plus new payment security technology support

GuyB: KYC is important...in addition, ensuring that new authentication technologies can be used

<manu> Ian:https://www.w3.org/2017/Talks/tg-autopay/

[Ted walks through It's not clear to me that we need to be doing a lot in regulatory topics that are jurisdiction specific. We don't have a lot of pointers like that, but we're trying to keep tabs on the primary ones, we want to be able to answer the questions that come up the most in our FAQ.

<dezell> ian: I think industry and services normally keep tabs in this area, so it's not completely clear how far the Reg TF should go.

<manu> Ian: We need expertise in these areas and a place to document them... in the FAQ.

JYR: Thanks everyone. We know that some issues will have an impact on the APIs; other issues will have an impact on usage and communications
... I think that the framework we are putting in place will help
... and building a network of experts will help us
... and this will lead either to feedback for developers or on the spec
... Let me know if you would like to get more involved in the task force

[Break]

<Ian> Framing of next discussions.

<manu> Ian: Because W3C is looking at next standardization activities, what I'd like for us to do as an IG - digital receipts, digital offers, automotive, etc., we're trying to figure out where we focus our efforts in 2017. We can best make that decision with our feet, having heard these presentations, where you would benefit the most, we may come back and try to prioritize.

Automotive Use Cases

<dezell> Automotive use cases slides

Key challenges: Intermittent Connectivity, Distractibility, Shared Vehicles.

Ted: Profiles might help in cars
... e.g., to allow payments while car is moving, or up to a certain amount for a programmed route
... want to be able to confirm payments, avoid distraction, etc.
... shared vehicles create interesting use cases

[Ted walks through a plan through October]

<Zakim> manu, you wanted to ask about next steps - something to focus on - a "compelling set of use cases" from AutoWG?

Manu: Great presentation, Ted. While you were going through it I saw some compelling use cases.
... two thoughts - of the use cases some seem to go away if you have a mobile phone with you
... the question is - at what point do you identify the most compelling use cases to bring together a community
... I think you need to say more loudly "here's the focus"

Ted: The three that stand out for me the most are relate to distractibility, shared vehicles, intermittent connectivity

Manu: Those are broader

Ted: Yes, there are more granular use cases within them
... so I want to convene a task force to pick out the most compelling one, or identify the low-hanging fruit
... I think fueling is an important use case for the automotive companies

dezell: The biggest problem we see in the petroleum space is having the right mindset of the person using the device at the right moment.
... I think there is space to define this...the whole business of pairing of phone with car is something people are familiar with. If that pairing could address these use cases, that would be great.
... You mentioned a joint task force...of whom?

Ted: Thinking Auto BG + people from the WPIG

Ryladog: Include motorcycles
... when they are being used there is an even bigger issue with distractability
... there are also ties between accessibility and these use cases (e.g., voice control)

ted: There are some scenarios where pairing with the phone is not sufficient

<manu> Ian: I've been thinking of these use cases by looking at PaymentRequest API - browser/mediator gets payment request - for many of these use cases it feels like "let's use payment request API" - what else do we need to enable that?

<manu> Ian: So, payment app can do the controls, for fleet vehicles, for example - how does the connectivity take place? (bluetooth, LAN, NFC, WiFi, etc.)

<manu> Ian: Once you can have the communication, you can have payment apps integrated.

mattS: I think Ian is right that PR API can help a lot in these cases. But PR Api is very interactive-biased
... I think we should aim to remove that bias from the specification
... and that might make it more useful for additional use cases

<Zakim> jeff, you wanted to ask who we need from WPIG for the task force

Jeff: Your next step is to create a joint task force
... the IG is not really a monolith....
... I have not yet understood which of the stakeholders from the IG you need in the joint task force
... a lot of the use cases will come from the automotive group
... to me the "Why do you need me?" question still needs to be answered
... since we are face-to-face, good opportunity to describe the value proposition for joining the task force

Ted: I would like to chat more about that, and hear perspectives
... maybe lunchtime discussion
... interested in understanding, e.g., in order to run an app on a car head unit, what is needed?

<GuyB> +1 Matt hit a core point. If the API can handle a non-distractive implementation the rest of the issues presented are an application layer issue

<Ian> (Either application layer or network layer issue...that was my comment about NFC, or bluetooth, or wifi, or 3G, etc.)

<GuyB> A work item could be to review how the API supports use cases of intermittent connectivity, none-distraction etc, but not be industry specific focused

<Ian> (Interesting.)

<dezell> katie: want to explore unintended (positive) consequences for people with disabilities.

Natasha: Some interesting telco perspective to share later.

Security

[Ken Mealey introduction]

Ken: Security is critical for payments, and cooperation is, in our view, vital
... We'll get to PR API and how to increase security. And what more can we do beyond PR API?
... Amex views security has a top priority
... Web payments growing quickly; mobile payments growing in portable; desktop still important; cross-device capabilities are important
... EMV chip deployment drives fraud online.
... we are seeing this as EMV Chip deployment increases in the use, and more fraud online as we have seen in other countries
... lesson learned from UK migration was "3D Secure"
... challenge from a W3C perspective is that it requires adoption of some software, a password, etc.

[Cost of data breaches]

Ken: An important reason for cart abandonment has to do with security concerns
... W3C work can help overcome some consumer concerns
... Forrester survey asked people about use of digital wallets...high percentage of consumers are concerned about secureity
... Amex survey also indicated merchant concern (about fraud) and user concern
... the more we can help merchants protect themselves the better
... Next steps

1) Tokenization - alignment with EMVCo spec (IN PROGRESS)

2) Build relationships with PCI, EMVCo, FIDO (IN PROGRESS)

3) Provide educational material and best practice guide at the developer portal

scribe: we have affiliates who can help with guidance
... fraud risk analysis may help inform specs
... we'd like to ensure there is greater due diligence to security
... it doesn't have to be "baked into" the spec but as long as it's part of the developer portal, that's helpful

dezell: There is security and auth work going on elsewhere within W3C. With auto we talked about a joint task force. What is the right way to approach security work going on elsewhere in W3C?

Ken: I've heard PCI mentioned today. PCI sets minimum standards... so a good starting point but not necessarily ending point
... when our team at Amex was looking at the spec, they saw an opportunity to add more data to the API...it would be useful to our issuers for risk-based assessments

<GuyB> What is the proposal?

<dezell> How do we bring payment specific security concerns to W3C consideration?

jeff: I hope that the WPWG is getting appropriate security reviews of the spec. We have a self-assessment questionnaire.

Ian: We did the TAG self-assessment some time ago. More recently we have been seeking review from PING, Web Sec IG, TAG.

Jeff: My question has to do with developer portal

<manu> Ian: Within the Web Payments WG , we have a merchant adoption task force, which we'll talk about more on Friday has prioritized a list of things that we think are important to API adoption. We have created a developer portal, the portal intends to provide material to provide different types of questions. How are PCI compliance requirements addressed? What is the implementation status, etc. In merchant adoption task force, we have started to put content into the repo. We may make it look better. The most progress we have so far is a FAQ, some of which relate to security and PCI. We have not talked about this work in the IG, a good way to make progress in the IG, is to help continue to get people to engage and flesh this thing out. That's where I think this information will end up.

<manu> Jeff: The focus on security is not clear in the FAQ. I can remember graphics, pictures worth a thousand words, and then I look at the portal and we don't have 80% focus on fraud prevention is clear there.

<manu> Ian: The structure and content is in progress, we do highlight security, this is the first exposure to this IG. Understanding how to meet needs is important, we'll look into having Security as a high-level category. In the end, it'll be driven by the content we get. For the regulatory questions, we'll get them in time and put them in the FAQ.

<manu> Jeff: The term "fraud prevention" doesn't show up right now, I don't know if that's the proper question, it sounds important.

<manu> Ken: Has this been adequately socialized, I think the answer is not yet, but we do think highly of the work that's been done here. We need to take advantage of this, hand specifications to developers and tell them it'll be helpful for web payments. We need to let them know how to protect themselves. I'm mindful to keep regulatory focused on the spec.

<manu> GuyB: Some of the things you've brought up - networks have identified direction of where folks are going with this. They're willing and interested to discuss this. I'm leading an X9 technical report to provide guidelines in this area. Hopefully it'll be done in July timeframe. We've interviewed fraud strategists - guideline of things to take into consideration for fraud mitigation. The US Fed Faster Payments Taskforce, Standards team is looking at industry to figure out what to provide. We're engaging w/ W3C - important standards relative to payments - these are the ones that should be implemented.

[IJ would like to talk to Guy more about this task force]

Ken: I looked at contributing CNP work from X9 but we may need an MoU. The reason that tokenization is up there is that there is a W3C spec touching on tokenization.

<manu> MattS: How do we take 3DS and 3DS 2.0 into account? I would add 3DS to your list

<manu> Ken: 3D Secure v2 and later - that's very relevant - challenge that I saw was that the big effort is to make the experience seamless - how do you layer security in as you're making this a more seamless experience.

<manu> MattS: I'd like to see that in the guidelines,

<manu> Ian: Maybe we should have a 3D Secure discussion...

manu: Talking a bit about security, I think the WPWG has looked at security at a high level. There have been considerations but I continue to be concerned that we are not dealing with the sticky issues
... I don't think that there's the right level of expertise in the WG
... that sort of thing has been raised in the WG.
... when it comes to things like digital signatures we have not done a deep dive
... we have Security groups at W3C but it is hard to do a security analysis

<GuyB> +1

<CyrilV> +1

<manu> Ian: A couple of things - we did a security self-assessment and did the analysis, we're on the TAG review list, David Baron and Travis will do a review. We've also written to Web Security IG and haven't gotten a response yet. Implementers are also discussing security with their internal teams. For digital signatures, we're pushing to different payment method specifications... we hope tokenization will supplant basic card, nothing prevents, but nothing requires it for basic card. Regarding EMVCo, we are working out a MOU to enable us to work more closely together. We're trying to get tokenization right, staying informed of others work, we do have a fair amount that's gone on, we hope to do more via payment method specs.

<manu> dezell: This is important stuff, it's important to cover.

Digital Receipts

Digital Receipts Presentation from David Ezell

<manu> dezell: The problem - user is buried in options wrt. receipts. As we've progress with payments electronically - bumper sticker message - there are a number of ways a digital receipt solves certain problems.

<manu> dezell: Digital receipt may be overengineered right now... hard problem to track, not suggesting a task force yet, just trying to make folks understand that this is a problem that should be addressed.

<manu> dezell: If this isn't simpler than throwing a receipt in a shoe box, it won't fly. Throwing receipts in shoeboxes is a problem, can't do anything with that, nothing to grab onto. There are a number of problems that we can solve...

<manu> User story: Karie owns her own business, keeps track of expenses, uses digital receipts to enter information into wallet and accounting system.

<manu> dezell: There are numerous other stories wrt. digital receipt, many ways to do this.

<manu> dezell: refund support, regulatory support, reimbursment of expenses, search and display, fuel purchase... many use cases.

<manu> dezell: receipts for fuel dispensed, contents of receipts are very important,

<manu> dezell: NACS, in their current focus, supports receipts in ASA and SLA - not outside of the purview of web payments, delivery mechanism for receipt is different.

<manu> dezell: Stakeholders... consumers, consumers are probably the biggest stakeholder here, fewer lost receipts, proof of purchase, returns, rebates, etc.

<manu> dezell: Stakeholder - merchants/employers - less time spent on wasteful administrivia... there are about $1.2M /year in company time wasted in receipt entering/tracking for reimbursements.

<manu> dezell: For everyone involved, it's a greener approach.

<manu> dezell: Stakeholder - SW Vendors/Regulators - what kinds of receipts should be provided - we're throwing this over the wall wrt. everyone that deals w/ web payments, when the Web becomes more implicit in everything we make, we can make it easier for people.

<manu> dezell: consistent tracking/control of merchandise - regulations in placce, have to track certain things, receipt is a good place to do this.

<manu> dezell: There are a number of iniatives out there... NRF, ARTS, UBL, and GS1

<manu> dezell: Marginal update of all of them, not one of them is a real standard wrt. what people do.

<manu> dezell: Benefits of interop - everyone can manage and audit their purchases, everything is consistent.

<manu> dezell: Who should be a part of this - Web payments WG.

<manu> dezell: There is a digital signatures on receipts that hits Web App Sec WG... There are several groups in W3C.

<manu> dezell: Payment App implementers are critical, people that consume digital receipts...

<manu> dezell: Why W3C? W3C does not concentrate on industry verticals, we work on items broadly, we have potential to span technology layers, international/legal/regulatory issues.

<manu> dezell: W3C - developer outreach is crucial for success - receipts are typically home cooked - developers don't have a common strategy.

<manu> dezell: We have a few capabilities that are missing in the digital receipt use case - storage of receipts, requesting refunds, displaying receipts in a consistent way.

<manu> dezell: ReceiptReliance has created a way to list all payments and receipts.

<manu> dezell: We probably need a Task Force for Digital Receipts, API requirements in lieu of the use cases, something for task force to do.

<manu> dezell: There are several receipt formats out there - we don't need to adopt a single one, but we need to align how they can be used in certain places could be useful. Ultimately, we should produce a statement of work, could be a charter for a new Digital Receipt WG... maybe request for Web Payments WG to figure out what to do.

<manu> dezell: We will want to identify participants by May 8th w/ Topic List and straw statement of work.

<manu> Ryladog: I was looking at this from accessibility point of view. Keeping everything in the electronic world is compelling. Having an interoperable way to do this by the W3C, why isn't that something we'd want to do?

<manu> dezell: The Task Force would figure out what to do.

<manu> Jeff: I think this is terrific. The way things get done today is through incubation, the Task Force could sit in a Community Group, we could start developing a spec, your description sounded a bit waterfall-ish. If people are motivated to do something, get to it.

<manu> Ryladog: This is W3C's wheelhouse, bringing all these verticals together.

<manu> Jeff: You may want to consider a faster path.

<Zakim> jeff, you wanted to discuss incubation

<manu> Ian: I don't think we'll be successful creating a digital receipt format - different formats in different areas. Not a lot of stories where we have standardized industry vocabulary. I don't think we can add a lot there. On the other hand, if there is interest, I think we could be successful getting a digital receipt from the merchant back to the payment app. A sort of "next step" following the flow of payment request API. We have the right people at the table to get that to happen. I don't know if that's interesting, but it makes sense to me.

<GuyB> +1

<mweksler> +1

<todd_a> +1

<Ken> +1. I'd like to voice my support for this effort as well.

<padler> +1 for suggestion of "closing the transaction" - assuming the payer receives information on goods/services to be purchased, it could be valuable to also include a token or hash of the information and transaction reference which could be linked to the payment app or wallet during this completion process.

<Ian> Cyril: Another use case is "notice of reimbursement". My understanding is that this is about consumer experience, it's more related to interacting w/ payment after it's received. How is all this information going to interact security w/ the payment app? So +1 to this topic on the table, but may be more general than digital receipts. What can we propose wrt. information - we pull that invoice, that receipt, if they don't match - relationship/link with payment app - I'd like to focus more on consumer experience.

(IJ counts 6 or 7 +1's for an API to return receipt to a payment app through the mediator)

Manu: Our company wants to provide a service for digital wallets
... it seems like we could do something analogous to what is done with PR API - where PR API is a pipe and there are different payment methods
... so a digital receipt API could be a similar conduit, whatever the digital receipt format
... w3c could not take a position on a particular receipt format, just enable the exchange of the data

(IJ: +1 to Manu)

<GuyB> There is the option to return the last four digits of the orginal funding PAN to the receipt. This helps merchants link a receipt to the person's card

jyr: One use case is "lo scontrino" in Italy
... receipts in Italy important. getyourbill.com... you may recognize Nicolas, he may be happy to contribute to digital receipts.

dezell: Very quick clarification for Task Force going forward, there is no recommendation that we create a format - if you imagine a world - if we recommend you use UBL invoices - that would have a huge impact on industry adopting that standard. I don't know if we want to do that, not writing a standard, signaling out / limiting scope of what we might actually adopt.

<Ian> dezell: We might limit scope of "what we adopt" in terms of format

<Ian> (Reply to David's comment): -1 to recommending a specific format and -1 to an API that excludes some formats.

Jeff: There is work going on elsewhere, small suggestion that you add somewhere into the workplan for your task force, that early on the work should be scoped, focus (receipts could be a very big topic), what piece needs additional attention. That will help communications.

dezell: This is a very complex topic, we'll have to focus.

<Ian> (IJ summary: I heard a lot of support for a protocol to get data (digital receipt data at least) back to the payment app.)

Digital Offers (Introduction)

<Ian> Linda's slides, which reference Digital Offers use cases

ltoth: Conexxus does standards for fuel/retail
... We've been involved in Digital Offers work for a while now. We've been concentrating on getting members on board, use cases, priorities.

ltoth: We have a report describing use cases, we did analysis of what standards exist out there, how do they address use cases... optionally report on how to address use cases.
... We've been focusing on several areas - one area management and distribution
... User Action - what has to happens so that consumers know what's out there -
... Settlement - 3 areas that we talk about... there are use cases there...

ltoth: they start at the top - we want your input on use cases. We'll spend about 30 minutes going through them if you haven't seen it yet.

Manu: It's hard to not have a technical discussion about how some of these will take out
... eg., decentralized lookup. some of us are working on blockchain and this might be relevant
... how can we track that there is interest....that we've identified some technical approaches that might work.

<manu> Ian: The CG's wiki is useful for tracking items that come up here (as well as in the Community Group)

Jeff: The use cases I would have prioritized higher are the ones I thought merchants would be more likely to use
... should we do a survey or otherwise reach out to merchants

<manu> Linda: We are trying to reach out to groups now, it will take time.

<manu> dezell: We're reaching out to large consumer packaged goods companies.

<manu> ltoth: Unless you have the CPGs on board, merchants will probably not come on board.

<manu> dezell: We're trying to get all these organizations involved, we may need to create a Workshop.

<manu> padler: One of the things that's problematic in the payments space today is malware, malvertising, are any of these use cases focused on identifying legit/valid merchant offer. From a consumer protection perspective, have we thought about that?

<manu> ltoth: We have talked about being able to validate that the offer is one time use - offer directed at particular person - we should add something for that.

<dezell> manu: Question - do we need CPGs involved week to week? Or do we contact them through groups like Conexxus?

<manu> ltoth: There is a big disconnect between technology folks and marketing folks. We have connections at those organizations, but haven't reached the right people at those orgs. We need to make sure tech people and marketing people are on the same page.

<manu> ltoth: We need to get them on board first, get everyone on the same page.

<manu> Magda: Can you elaborate on the CPG use case?

<manu> ltoth: We've tried to keep some of these use cases w/ minimal verbiage, manufacturer website - there is a difference between merchant doing the offer vs. a manufacturer doing the offer. Primarily a CPG when manufacturer does the offer.

<manu> dezell: There is an 80% non-redemption rate w/ paper coupons. They want some sort of systematic acceptance. They want help to prevent breakage. Don't want to do manual counting... coupons take a long time to clear. Long cost of capital for merchants.

<manu> dezell: Merchants want to be able to incentivize their customers - they have that interest - a marketing interest. How does it integrate w/ payment flow. How can they do that AND make their customers think that they're doing that for them.

<manu> dezell: This was baked into the Alibaba ecosystem from the beginning - there is always a marketing aspect, if you're paying w/ a credit card.

<manu> dezell: People want to offer added value.

<manu> mweksler: I'd like to focus on blurring of lines w/ offers, coupons, and payment - coupons are another way of transferring value, they are more narrow.

<manu> mweksler: They're more effective at affecting consumer behavior - it's not very different from payments in that sense.

<manu> mweksler: How blurry this stuff is is something we should think about. If you think about it that way, Blockchain is just another conduit - important wrt. what conduit we want to support, but doing coupons/offers is important as well.

<manu> ltoth: With coupons today, in order to validate the coupon's barcode, you have to go to the GS1 database - ongoing maintenance, POS systems can't do that, not having to validate a coupon by looking at GS1 database is an important use case.

<manu> ltoth: David mentioned that there are a huge number of coupons that get kicked back, we don't do validation, we rely on a highschooler to check the coupon. It automates some of that manual intervention.

<manu> dezell: Let's go through these items.

<GuyB> There have been numerous efforts to attempt to standardize coupons in the brick and mortar world that has really never gotten much traction - that I am aware of

<Ian> (I don't think we should standardize coupon formats; same obesrvation as with digital receipts.)

<manu> dezell: There are a couple of things wrt. receiving coupons over SMS.

<manu> dezell: do we provide an overarching way of looking at this?

<manu> Ian: I continue to think of this, work around coupons, to have best chances of success to stick close to payment request API. There are lots of digital coupon formats, standardizing coupon formats. With PaymentRequest API we have coupon format... merchant can offer relevant coupons, what merchant requests, feels a lot like payment request API. There is a bunch of streamlining that we could do - in my view we shouldn't do realtime settlement, it's far away from user experience.

Magda: Marketers likely to not want coupons to be invisible. This is a personal comment - Isn't the purpose of this brand awareness? This is two competing things.

IJ: Good point; I only meant that automatic redemption is one way of streamlining but that is not a requirement nor the only way to streamline.

<manu> dezell: One of the things wrt. immediate settlement, if we have a payment app in the web payment API - people that want to use me as ... (scribe missed comment) ... depending on how ecosystem is setup, people can route payments, coupons, etc.

<GuyB> why would the coupon have anything to do with settlement?

<manu> Ian: I hear from people in the CG that real-time settlement is something that some people would like, but my view is that it is farther away from areas where W3C can add the most value.

<GuyB> That seems to be connected to the payment processor not anything in the web interface level

<todd_a> +1 support not dealing with the back end settlement

<GuyB> The frontend has no control or influence over settlement

<manu> ltoth: From a merchant perspective, it's a big deal if they don't get paid, so faster settlement of coupons is important.

<Zakim> padler, you wanted to

<manu> padler: How does the merchant know who the coupon has been issued by?

UNKNOWN_SPEAKER: is there a sub use case of "required information to validate coupons as having been issued by a vendor"
... and if, e.g., keys are not validated, coupon is not shown

Manu: I think that it's a bit cart before the horse that we should tack this on to PR API.
... we have Verifiable Claims work that we think is relevant to coupons
... extension points in PR API is a good path to follow
... would not want to build everything into the browser in a tightly bound way
... so I am all for using the momentum of PR API to be successful...but concerned about saying the natural way to do this is through PR API

<manu> Ian: I think we have better chances of success closer to user experience part. If we do something that resembles the PR API flow, I believe we can get similar levels of support. And this is independent of data format, if Verifiable Claims are used to represent coupons, and if special validation is done, all that is possible through a pipe that can foster streamlined interaction.

<Zakim> jeff, you wanted to be a broken record about incubation

Jeff: Listening to the Ian/Manu debate; reminds me of incubation!
... it can be hard to determine these things in the abstract
... it might be good to get some CG work going taking both approaches and seeing what it looks like

<manu> Ian: The CG has an expectation of doing some incubation, one way to prioritize use cases is to vote, another is to just start coding. Maybe CG folks can start coding use case they care about.

<manu> Jeff: Answering architectural question, how much of this do you put really close to Payment Request API, and how much do you put away.

<manu> Ian: We don't have the browser vendors in the CG to do the thinking from their perspective.

<manu> Jeff: You don't need browser vendors to do that sort of experimentation.

<manu> Ian: I dont't think we've had good outcomes when we don't include vendors from the start.

manu: I note that with Web Payments CG we took this approach and the CG's approach didn't align with the browser approach
... so early engagement with browser vendors is important, especially if we are talking about a browser API
... danger to go too far down the road without browser implementer experience

Linda reviews discussion topics, grouped by themes:

1. Management and Distribution — how coupons are managed and made available to users

2. User Action — how users clip, store, review, and redeem coupons (or pair an offer with a buy action) during a transaction

3. Settlement — how merchants and coupon distributors settle

IJ: One interesting thread in the CG has been "not having to install an app"
... e.g., you just visit a web site (payment app, for example) or your browser is the repository

[Manu demo]

Manu: Costly to run a loyalty program.
... small merchants competing with larger merchants
... merchant has a strong desire to get a digital loyalty card to their customer
... loyalty card is a channel for merchant to reach out to the customer

padler_: Is there a process by which the consumer requests the loyalty card?

manu: We want to be able to do that, yes.
... both push and pull scenarios
... merchant can easily design a loyalty card
... user scans a QR code to get the loyalty card

<adam> Merchant flyer and flyer QR code

manu: user needs a digital wallet to store the loyalty card
... wallet prompts user to confirm storing of loyalty card
... flow for wallet is similar to flow for coupon or receipt
... merchant then sends offers to loyalty card
... Note that there was no request for phone or email from customer
... notification uses standard notification technology
... missing capabilities for this use case:

- creating / encoding digital offers

- merchant notifications to customer

- visual rendering of digital offer

manu: Rendering of information is important; may happen on a site not controlled by the merchant

Ted: I liked the ability to opt out
... by and large I don't let apps send me push notifications
... when user opts out, it would be useful for merchants to know opt-out patterns (while not revealing too much information about users)

IJ: Most notifications through apps...this feels like a new way to get messaged. Are there examples of this?

Manu: Not exactly, but there are web-based clients (e.g., for email) that ping the user

IJ: I think email notifications are not exactly it; all that going through your app
... your model has other origins being able to notify; seems different

Manu: Agree it email is not quite parallel.

dezell: App fatigue is an issue; web can help

Manu: People are reluctant to install apps
... what this model could help with is to allow merchants to be part of the ecosystem without having to create an entire app

manu: People have on average 29 loyalty cards
... but hard to manage them all

magda: A think bothering me about this topic in general is "all the technologies" interacting well together. There are touch points along the way that are interesting to the merchant
... I hesitate to think that working in the web space will solve enough of the problem

[Manu reviews more use cases / capabilities they imply]

(IJ thinks that specific rendering issues should go to the CSS/HTML/SVG WGs)

Manu: For notifications, we are not sure whether to use social web messaging, PUSH , other
... Merchants concerned about using google/mozilla servers for push notifications. Encryption is possible, but metadata can still be mined and analyzed
... PUSH not available on Safari, Edge
... There are also some responsive images needs but more is needed
... specifically HTML Import and Shadow DOM

[Manu shows another use case of redeeming a coupon]

[Manu shows another demo - recommended digital wallet]

<dezell> ian: so if merchants don't want other merchants to know what they're doing, why would a merchant be ok with a wallet distributor knowing about the merchant's interactions with their cutomers? Why wouldn't the merchant want to be more "like an app" and simply interact directly with their customer?

Manu: Small merchants and large will have different incentives
... e.g., for a small merchant to interact directly with user may need richer set of permissions on the notifications API
... we'd have to figure out how to work that out with push notifications. That might be good for some merchants
... but other merchants might want to be part of the user's daily transaction life cycle
... and be part of the wallet when the user takes the wallet out to pay
... the proposal around digital wallets attempts to tie together a number of things together that are going on at w3c
... Fraud is another situation where an intermediary would be valued by (e.g.) the merchant

Linda: We would like to hear about which digital offers use cases you would like us to focus on. Please complete the survey during the break.

GSMA Mobile Money

David: I'm going to be demoing the GSMA Mobile Money API.
... Last year, GSMA's membership had issues w/ their mobile money platforms.
... We launched MMAPI last year... available publicly
... There were multiple custom APIs in the ecosystem, not like SWIFT/ISO formats - when these parties come together, one to one engagement. These tend to be one-to-one, vendor locked, we tried to fix this in the ecosystem.
... How do we connect smaller players to the larger players in the ecosystem.
... The MMAPI is transactionally heavy - we had billing, quotations, P2P, cross-border.
... We looked at tech standards that we wanted to put in place - Swagger + JSON + RESTful services.
... We wanted to promote new technology standards... Swagger, JSON, and RESTful.
... The emerging developer community is much more aware of these technologies.
... After the design phase, the API specification was supplied in october - what use cases are missing, what is needed for v2.0, we set up a developer portal/hub.
... We wanted to start testing against the use cases we have - collaboration portal by industry invitation only. What do we need for v2.0? Part different verticals together, offer guidance.
... SDKs as code examples, We have 50% coverage - publicly the company Terra Pay is owned by Comviva - enable millions of mobile money transactions per hour.
... We have a hackathon in Nairobi - best practices and security guidelines... to clarify - when I joined GSMA, people were talking about adoption overriding existing APIs. This will be for new partners/new functionality.
... All systems tend to be locked away - what can be done at a more product/subscriber level - streamline integrations between utility vendors. Improve it, streamline the process, code snippets that they can import - collaboration at industry level.
... API specification is public, that's very important - if you try to connect to a mobile money vendor, there is quite a lot of enterprise tier discussion before developer gets access to API platform.
... API is completely publicly accessible, plug and play ecosystem, getting feedback from Fintech companies - mobile money platforms are offered via different products and so connecting is difficult.
... We want to provide boost to industry, grow developer community organically, hackathons.
... There has been a lot of talk of ISO20022 - we're working on it, keen to work on W3C on Web Payments and how we can move forward with that. From an industry standpoint, how different parts can work together.
... We're also looking at India w/ UPI initiative - Indian central bank is trying to standardize how their payment flows work.
... They did 1.0 last year, now they're doing 2.0.
... We are additionally working with the Gates Foundation, working with Tanzania, Myanmar, ensuring we provide services that don't overlap too much. We're working with CGAP to enable smaller developers to connect up. Collaborative workspace so we can connect the pieces when everyone is finished.
... We want adoption, we want compatability, we're opening up a compatible vendor list, not a certification, us looking at implementation being made, regardless of what vertical it's being made in.
... What services in what regions, developer portal work against a staging environment, once they've done a POC, we want to be able to give them something to take that learning, recyclable, go into production w/ whatever vendor they want to.
... The reason we're trying to do this - trying to give this ecosystem a boost in the arm, it's getting static, implementation times/speed to market, promote pluggable ecosystem.
... We want people to be able to promote the ability to connect vendors, connecting different parties across verticals, the ability to go off and get new use cases supported by using same standard makes sense for them.
... We're starting to see aggregated services... we've seen shift away from SOAP to REST. We have an activity calendar... we have collaboration portal...
... the developer portal is in beta, the good news is that we have Swagger so we have code generation out of the box, we will make refinement out of them.
... We are looking to collaborate w/ industry as much as possible to catch bugs. There will be at least four hackathons this year.
... Because there are a lot of industries, we are reaching out - want SWIFT, ISO20022, etc. involved. Q3/Q4 - we are focusing on approving use cases incrementally.

Ian: The way this works, you have a bunch of vendors that provide mobile money services and under the hood, they use the GSMA API.
... When they provide payment apps to their customers, merchants can declare they take mobile money payments, then any app distributed by mobile money providers, user picks app, payment app packages mobile money API, data goes back to the merchant. I drafted a rudimentary Mobile Money Payment Method spec to show the way we could organize data from the merchant and data gathered directly by the payment app, then mashed up and sent through the GSMA API. Basically that payment spec says "here's what the merchant provides in the payment request, here's what the payment app adds, and all that data goes into the Mobile Money API." (I have not yet proposed to the WPWG that we work on this payment method spec; this is for discussion purposes for the time being.)

David: User portal, to sign up, we have staging environments, facilitate use cases/payments. To reiterate what Ian was saying, this is the flow, W3C standard.
... Hackathon will be looking at IDP, OAuth, SAML, OpenID, Cognito, etc.
... This is primarily a B2B model for APIs... showing preview. We wanted to get developers setup in 30 minutes and using it.
... We have two documents, 80 pages, 120 pages... we don't want to overwhelm developers. We focus on giving API keys, postman, and they're off to the races.
... We have a developer portal, strict separation between user credentials/sign up, and actual content, community to collaborate.

<Ian> [Demo]

David: We jump into postman, staging, enter API key, then check for heartbeat.
... Body for mandatory field, request quotation against service, quote Id, business logic uses Terra Pay, has all business logic necessary, gets telephone number, calculates FX, does transaction, checks status of transaction.

dezell: I accept at face value, this is a payment app problem. This fits nicely, that sort of means that this is a payment service provider API?

David: I would say that payment services is a large chunk of the API, I wouldn't say that it's the only thing in there. Batch transactions, accounts information, statements, which a PSP would probably not do.

<Manash> +q MTL - Money Transfer License and UPI

David: So, there is a list of bills for given utility providers, direct debit mandates, transaction piece itself has enumerability.

<Zakim> dezell, you wanted to ask about 1) w3c interoperability and 2) ISO12812 (mobile payments, MPSPs)

dezell: So, this is a client-centric part of the API, if I have a mobile money API, connected to solar power, if I want to get bills for user, to siphon it back to user, make the payment, that's why that use case is there.
... For the ISo20022 folks, rhetorical question, there seems to be a lot of interaction with ISO12812 stack, what is a mobile service provider, consumer protection, rhetorical question - have you looked at that? Part 1 is an international standard, parts 2-5 are technical standards, there has been thinking about all of this. I encourage you to look at ISO stuff.

David: There is a lot of specification to absorb, it's quite large, quite cumbersome, not everyone is expected to apply this in full.
... That's why it looks quite large.

<Zakim> manu, you wanted to ask about the touch points w/ the WPIG WPWG

<Zakim> Manash, you wanted to discuss MTL

Manash: Mastercard had released P2P APIs and B2B APIs, issues we found was that money transfer licensing you need.

David: We've solved a technical problem, we expect implementers to have their affairs in order wrt. PCI, licenses, etc.

Manash: How are you integrating with UPI?

David: UPI tends to be very centric on B2B2C, phone-based API requests/calls. We're trying to understand how to be compatible, they're using our APIs, they have everything they need to go off and work with UPI. We want all these standards to fit together. We don't want to create a zero-sum game.

jean-yves: Let's talk about functionality
... Do you have the ability to issue money, or just to transfer money?

David: The transactional object, do you mean cash-out?

jean-yves: When you do mobile money, you have to have control of mobile money

David: The mobile money ecosystem is very new, so there is a lot of infrastructure in place on the ground. Mobile money operator will go in, they will have agents on the ground, Myanmar, Tanzania, kenya - they talk to operators to control flow on what's available.
... Operator divvys out money via agents at different tiers, when you join GSMA, Africa is a different world... MPesa, you will find 5 agents that can pay for goods with SMS, top off mobile money account, or sign up for mobile money account.

<Zakim> CyrilV, you wanted to ask as possible synergies with PSD2 API

CyrilV: You manage money, do you manage accounts?

David: We don't have a use case for creating accounts, we don't tell people how to setup accounts. We track against identities, last statement, status, who it was to, any KYC involved, account management piece is quite limited.
... Let me see what their KYC is, who is officiating digital identity, get their statements, get their bills, we don't deal w/ account creation. Do it in coordination w/ industry.
... We want to get everyone involved.

CyrilV: How can you manage money w/o mananging account.

David: To clarify, we're primarily looking at emerging markets, the way people put cash into accounts, same way that people walk into bank.
... I want to put $15K canadian shillings - you can put it into bank account, you can give it to an agent, wrt. transferring in/out, you can do that.
... We track payments in and out, last transactions made, identity is generally against MSDIN

CyrilV: Are you working w/ countries - more than requested, part of work - solved in this type of API - we're aware of OpenBank, talking w/ them a bit, see adoption w/ this, financial institutes being compatible... we're at beginning of implemntation phase. Start working w/ industry players. We want a new harmonized API.

padler_: What sort of access does system accept? Secure Element?

David: No, we assume ID is federated, we try to check device IDs, we expect the party to federate the identity. We have two forms of security, Base64 encoded JWT and different flavors of OAuth2.

Rechartering Introduction

<Ian> I created a draft charter to start discussion.

Ian: Our charter expires September 30th, end of presentation, timeline, chartering process takes time, we need to get on it.
... Our topics have gone beyond payments before, topics in CGs, nearby things - paid content on the Web, digital marketing is interesting, so, proposed revision is to expand scope to be slightly broader and include E-Commerce.
... If you look at the charter, wanted to focus on scope, make charter shorter. First charter was good tool to talk to industry. This time around I wanted a more terse charter with clearer statements about the scope of our activities rather than too deep a focus on topics we might cover.
... In practice, we do things like have conversations w/ other standards bodies, worked on vision, roadmap, we've kicked off CGs to pursue topics.
... That is a way that W3C is working now, kick off CGs for deeper exploration. Review deliverables, may not be formal review, be aware of ecosystem, broader community. Call out some activities as out of scope, no detailed technical requirements, our capabilities pointed in a direction of stop at high level, but detailed technical requirements happens in WG discussion.
... We never had anything like that in the IG, IG should stay away from detailed technical requirements... Focus on use cases and capabilities suggested by use cases. We should stay away from industry vocabularies, dedicated standards bodies to do that... we should do web-like things.
... Digital payments from devices, regulations, harmonization w/ other standards, fraud reduction, security...
... Out of scope, security specifically (find someone else to do the work), some fraud mitigation things involve some data... for security, go to Security IG.
... Advertising (in the sense of banner ads on Web pages) is out...
Regarding timeline: working backwards - we need the IG to be supportive of new charter by end of May, we should iterate over the charter, small charter makes it easier. It's a little bit above certain topics.
... It says ECommerce, but doesn't talk about digital receipts, offers, etc. We may need to provide examples, how detailed do we need to be?
... I didn't write deliverables down... we kick off TFs and CGs to do the w ork.
... Who in practice is available, what orgs should be involved?

padler: I like the broader charter, let's drop the "E-", it's 1990s.

dezell: We have been talking about formats, industry vocabulary - not stalled attempts at creating glossary, you don't meant not to work on that.
... I'm curious to get thoughts on industry vocabulary thoughts on this.
... There may be other ways to achieve our goals.

Ryladog: I don't think we should take out of scope a discussion on anything wrt. discussions shouldn't be off the table.

<Ian> Manu: Regarding working on vocabularies; W3C has one vocabulary...that's schema.org

<Ian> IJ: Schema.org works on vocabularies, but that is not a W3C Working Group and they do not do rec track specifications.

<Ian> Manu: Also not clear where a vocabulary starts and where it stops

<Ian> I agree that if you squint sideways at an API, parts of it can be viewed as a vocabulary. I am ok with an API; I want to avoid vocabularies for objects (such as digital receipt format or digital offer format).

<Ian> padler_: Reason that "glossary" was important when we started was we were getting to know one another. I don't think we should try to copy all the sources of terms and decide which is the appropriate one

<Ian> GuyB: This group should not seek to coin industry terms...but terms used within the confines of this group, sure

<Zakim> manu, you wanted to note we have a terminology issue with "vocabulary" - Data Format, Data Format Terms, Terminology

CyrilV: In SEPA, we changed the name, name adapted to different scheme, sometimes we need to change the name to adapt.

Next steps for work

Regulatory

<Ian> ACTION: Padler to identify someone at the Fed to work in the regulatory task force [recorded in http://www.w3.org/2017/03/22-wpay-minutes.html#action01]

<trackbot> Created ACTION-191 - Identify someone at the fed to work in the regulatory task force [on Patrick Adler - due 2017-03-29].

Automotive

<Ian> Joint task force volunteers: Nick, Linda, DavidE, Manu, Ted, Pascal

Security

<Ian> volunteers: Manu, Manash, Ken, MichelW, Olivier, DavidE, Todd, Cyril

Digital Receipts

<Ian> Volunteers: dezell, ted, jean-yves, katie, adam, olivier, michelw, toddA

CyrilV: For digital receipt, digital receipt with all remarks - what is the focus there?
... Interaction w/ digital receipt outside of payments... haven't seen that proposal.

Ian: DavidE will take that back to Digital Receipts discussion.

Digital Offers

<Ian> dezell: Who is interested in a digital offers workshop?

<Ian> linda, david, manu (.5), katie

IG Charter revision

Volunteers: Ian (Lead), David, Manu, Ken, Max

Jeff: In the last segment, Ian talked about the last charter, wanted to wrap it up by May. It is devoid of specifics, vision topics are candiate specifics.
... It feels like we should say something, maybe as things mature. Broadly working on commerce, and then be specific.

Ryladog: How long is the charter going to be?

Jeff: 2-3 years, it would be good to advance things and then state it in the charter.

dezell: Conundrum - approving charter comes before workshop... the way the IG is doing its work currently, each TF runs separately, we are focusing in the TFs.
... Incubation or pre-incubation work... how do we capture that in charter proposal.

Ian: Monthly meetings, work happens in Task Forces. Just an example; state the expectation in the charter.

Integration of Diverse Activities

<Ian> Ken: How do we integrate the activities of various groups into the WPWG or vice-versa

Ian: We will find that there are a variety of answers for that, one of the goals is to do security reviews of specs... current expectations, join the security IG, make sure this IG reviews web payments specs.
... The Digital Offers CG, doesn't have anything else going on at W3C... trying to whittle down use cases, most people step up, biggest impact, etc. To do these use cases, you need these capabilities of the Web, we need a new WG, incubate more... etc.
... There is experimentation that has to happen to answer the question. There will be a variety of solutions. We can help direct conversations to useful places.

July IG FTF Meeting?

dezell: Before we leave, what is the taste to have a group meeting between now and TPAC.

<Ian> David: I assume we will NOT have a FTF Meeting between now and November TPAC

Ken: Next face to face meeting?
... If there is a WPWG meeting, would folks like to meet F2F for WPIG?

dezell: Yes, that's entirely possible.

jeff: If there is a desire to meet, then we can decide to meet at that time.