Warning:
This wiki has been archived and is now read-only.

Meeting Summary Feb2015

From Web Commerce Interest Group
Jump to: navigation, search

This is a (draft) summary of the second FTF meeting of the Web Payments Interest Group, 2-4 Feb 2015 in Utrecht, Netherlands, hosted by Rabobank. (Minutes: 2 Feb, 3 Feb, 4 Feb and group photo)

Use Cases

Desired Outcomes

New Task Forces

The group launched new task forces on these topics:

  • Payments Communications Strategy (led by Pat Adler). This task force will propose a set of materials that will help the group communicate its work to different business and technical audiences. The task force will consider both bottom-up materials (e.g., blog posts from participants, or individual statements in other forms) as well as top-down materials (such as executive summaries or marketing materials).
  • Security (led by Laurent Castillo). This group will focus on identifying the security needs that arise from the identified use cases, and what changes may be needed in Web technology to address these needs. One topic of interest is likely to be on how payments industry needs align with the extant Web security / same origin model.
  • Value Web / Web Settlement Task Force (led by Evan Schwartz). This task force will explore how the web can connect new and existing value networks and enable cross-network clearing and settlement that is secure, low-cost, and fast. The central question will be how standardization could make web payment mechanisms more interoperable, accessible and competitive.

Glossary

  • We discussed alignment of terminology with industry terms, especially as used in ISO 20022.
  • However, we also noted there are a number of relevant standards, so reuse from a single source may not be appropriate in all cases.
  • We reviewed some diagrams and noted that they are very helpful to understanding roles, verbs, and data that is required to be exchanged as part of each transaction. We also discussed small diagrams as helpful to storytelling, perhaps being subsets of a comprehensive diagram. (see Evert's diagram)
  • We spent some time reviewing 3- and 4-corner payment models; there was some discussion about (for our purposes) focusing on a different modeling of schemes as push/pull (see diagram from Evan Schwartz, for example). Push and pull differ by who initiates the payment processing (user or merchant). We dissected the push use case.

Industry Context and Outreach

  • We reviewed relevant work outside W3C (e.g., ISO standards) and inside
  • Floris Kleemans (FOCAFET) gave a presentation on UETP and its relation to the work of this IG.
  • Jean-Yves Rossi gave a presentation on the importance of considering regulatory environments in our work.
  • We discussed a number of categories of participants that we would like to be sure are represented in this group, including (but not limited to): payment providers, browser vendors, cryptocurrency, national banks, payments standards bodies, regulatory bodies, payments processors, personal financial management, (non-international) payment schemes, loyalty schemes, security technology providers, marketing agencies, social technology providers (for social payments), and others.

Payment Agent Architecture

  • Joerg Heuer gave a demo illustrating selection of payment instrument(s), identification cards, loyalty cards, and coupons. Each of which supporting various ways of connecting to a terminal (NFC, QR code) or communicating with a web service via the browser.
  • We talked payment flows, looking for a set of steps that would suggest an architectural framework as well as building blocks. This was followed at the end of the day by vivid parallel discussions about specific use cases of initiating a purchase within a browser or delegating the power to pay on behalf of a user to an agent in the Internet.
  • We attempted to tease out a payment agenda architecture that would support both push and pull payment scenarios.
  • Eventually the idea was born that a wallet-like functionality which - according to the architecture presented, could either live in a client or be offered by a web-service through the web browser - could be modeled as a web-based service.
  • We talked about separating credentials/authentication from the payments protocols, and in general considering 'consent' as a boundary of interest.

Support

html5apps.png This work is supported by the European Union's 7th Research Framework Programme (FP7/ 2013-2015) under grant agreement nº611327 - HTML5 Apps.