Goals and Scope

The goals for this workshop are to bring together people from a variety of relevant backgrounds to discuss the opportunities and motivation for open standards for Web payments, and to discuss whether it is timely to initiate standardization and what additional work is needed to accompany that.

In particular, this workshop plans to address the following key questions:

• What are the scenarios for payments on the Web and where do they currently break down? How can both legacy business models and new business models involving payment be better enabled on the Web?
• What gaps exist in the current Web platform that make payment more difficult than it needs to be? What are the pervasive work-arounds that are used to bridge these gaps and how can the Web platform adapt to make such work-arounds unnecessary?
• The Web is increasingly becoming a mobile platform. How does this impact the payments landscape? How can the Web on mobile platforms become more friendly?
• How can the World Wide Web create a better environment for global transactions while still respecting local laws, regulation and both existing and new business models?
• What alternative platforms, technologies and business models are developing in this area?

In more detail, payments on the Web today present a set of challenges for all the actors of the ecosystem, from application developers (merchants), to payment systems to end-users (buyers). To reduce the burden on developers, and to give users greater freedom of choice in how they pay, we need to decouple payment requests and payment providers, with a trusted intermediary functioning as a virtual wallet. Payment requests would be passed to the wallet, and the user allowed to choose the means for payment from amongst those available. For a level playing field, the wallet needs to be independent of the payment solution providers. This implies the requirement for users to be able to install and uninstall payment solutions after a device has been shipped. Likewise, the choice of payment solutions shouldn't be tied to the web browser.

Payment solutions are likely to want to handle user identity and authentication for themselves. For small payments, no further user interaction is desirable, but for larger payments, some form of proof of the user's presence is required. This could involve asking the user to enter a password or PIN, or to make a personalized touch gesture, or to swipe a finger past a scanner, or some other biometric technique. Ideally, this action should be authenticated locally on the device rather than relying on remote authentication, and the associated risk of spoofing. To combat phishing, we should avoid the need for users to enter information that an attacker could reuse for fraudulent transactions. An obvious example is credit card details.

A tamper proof secure element, such as a SIM, microSD card, USB dongle or contactless card could be used to provide proof of presence of that secure element, but this won't be sufficient to guard against fraudulent use of stolen or misplaced devices. This suggests the requirement for being able to revoke the use of a given device for all of the payment solutions in the user's wallet, perhaps based upon device and payment solution specific credentials. Payment solution providers would need to associate device specific credentials across each of the user's devices, and to handle revocation as appropriate.

Secure elements could provide the basis for local authentication of the user's presence, but some form of trusted execution environment is needed to prevent hijacking of the user's action. The combination of a user action and a secure element can be used to greatly improve security. On a given device there are limited options for the choice of secure element. How can a single secure element be used for multiple payment solutions in a way that is neutral with respect to payment solution providers?

Payment solutions could be installed on a device as trusted web applications that are executed in a security sandbox. As such they would have access to system APIs, including access to secure elements. Payment solutions could also be implemented as remotely hosted trusted applications. In both cases, there is a need to support interaction with the user. This raises questions as to the means to support that. One approach is via a secure IFRAME element.

To enable the virtual wallet to span your phone, tablet, laptop and so forth, some form of synchronization is essential. Each device could have a local version of the wallet, thereby allowing for offline payments, and perform synchronization when online. Synchronization could involve a master/slave model, or it could be peer to peer based. It seems natural to consider the role of a wallet provider as a personal service. Third party services could add value to the wallet, such as helping you to keep track of your payments, and offering advice of various kinds based upon what you bought. This would leverage existing standards for product identification.

Work on standards needs to be founded on agreed use cases, so we are looking for contributions covering use cases and requirements, for example, from businesses seeking an alternative to advertising and proprietary payment APIs. Related concerns are how to deal with prepaid vouchers and discount coupons or award points in connection to Web payments and wallets. Does it make sense to hold vouchers and coupons within the wallet for use in future transactions? Can these be exchanged for their equivalents as a form of community currency? What are the requirements for proof of purchase, and what would be entailed in supporting escrow mechanisms? Is there a need for further agreements on systems of identifiers, e.g. for people, organizations, currencies and products? What are the requirements in regard to taxation and cross border payments?

Other possible topics could include online and offline payments, small payments as part of prior arrangements, and person to person payments. Finally, how can Web payments be related to contact-less payment solutions, e.g. based upon vouchers represented as printed barcodes, or more generally, using NFC? In principle, a smart phone could be used to execute a trusted Web application to arrange a payment with another device. For example, imagine using your phone to request a payment from another person. You launch the wallet and type in the amount to be paid. You tap your phone against the other person's to trigger that phone to launch its wallet to invite that person to confirm and make the payment.

The idea of trusted Web apps with rich access to device capabilities is the focus of the W3C System Applications Working Group, and one of their work items is an API for access to secure elements. The W3C NFC Working Group is developing an API to enable trusted apps to access device resident NFC hardware. In essence, it makes little difference whether the app requesting the payment is in the same device as the wallet making the payment or in another device coupled via NFC. In principle, both the wallet and the payment solutions could be implemented as trusted web applications. The Web Crypto Working Group is developing an API for cryptographic operations without requiring access to the raw keying material, and seems like a promising building block for such applications.