Leader: Joerg Heuer

Members: Glen Wiley, Stephane Boyera, Pat Adler, Jean-Yves Rossi, Pascal Bazin

Tag:[user_payment_agent] (all emails related to this task force should have this tag in the subject line)

Description

The aim of this task force is to define a possible framework that identifies the various modules the IG is working on. This task force should help defining the IG roadmap deliverable.
Note: There is a new wiki page available under the name of User Payment Agent Task Force[[1]]. It will be gradually filled with input from this page and new additions. Once ready, this page will be exchanged for the new one.

Content

Mindmap

The mindmap picture below is the result of the first task force brainstorming highlighting some of the key elements. The image below is also availabe as a zipped mindmap file (mmap format)

It is proposed to use the structure for a document, including strategic goals and the discussion of generic patterns to be framed by respective standard interfaces and protocols.

User Payment Agent

The term User Payment Agent represents an abstraction from, what many might call 'a digital wallet'. It is additionally characterized by:

• User - running in the user's/ payer's domain and executing on the behalf of its owner. It is meant to become a worthy replacement for the real world objects named 'wallet', but much better prepared for the digital world.
• Payment - actually a wallet will in most cases want to hold more than a payment instrument. And even payment cards e.g. are also sometimes used to do other things than paying (e.g. putting up a deposit, acting to identify a person, or helping to confirm the holder is of a certain age). Closely connected to payments are discount coupons, loyalty cards and such, which will be considered in the 'Payment Agent' context. The design of the architecture and this work, however will allow for further capacities of the same, or further agents, like an 'identity agent', 'key agent', or others...
• Agent - the User Payment Agent could be a part of the User Agent of W3C - the web browser, but should also be implementable outside of the browser to allow for multi-browser, setups and 'wallet activities' via interfaces usually not connected to the browser. (Like proprietary NFC protocols or access to secure elements, where credit card applications are run.)

T-Labs' prototype wallet (written in HTML5/ JS and substantially capable to cope with proximity and web transactions) is used as a 'strawman' to identify standardization goals. The black-box version of the rough architecture is presented here. This illustration is to be treated as a tool only. It is not meant to be part of the results of this group's work.)

Resulting Standardization Topics

• Invocation and parameterization of the user payment agent through the web browser, aka 'user agent'. Might be generalized to also allow other apps on the device to refer to the user payment agent (e.g. to personalize an app using an ID/ credential stored in the user payment agent, or to perform in-app-payment.)
• Interactions, APIs, annotations to allow a service to detect existence of a user payment agent and start the transaction. Possibly allowing to re-iterate decisions for items/ credentials or add new ones within the transaction. Terminating with a confirmation message.
• Protocol and data elements to describe said transaction (minimum: descriptor and identifier) possibly including a 'statement of acceptance' and later on confirming items used and effects related to this use (deducted funds, points earned, coupon redeemed) optionally containing a receipt, a link to - and/or a key to retrieve - a receipt.
• It should be considered to create protocols on a meta-level, embedding a choice of existing specific elements, probably recommending new ones with a more consistent behavior and added value.

Goals

A high-level concept of the user payment agent could help to overcome a set of business, societal and person-related limitations found in the current payment situation.

Cost Reductions

• Improved fraud protection/ risk management
• Support for Strong/ H/W Security
• Reducing sensitive data handling costs
• Helping to introduce card-present online payment

Transparency and User-control

As the user payment agent is the functionality, through which the user controls interactions, transactions, and automatisms it has great potential to unify elementary parts of payment processes. Through such an agent the user might be able to keep credit card numbers to himself, decide on spot what instrument to use, understand the consequences of a choice better. Automatisms in the agent will help users to mitigate convenience and security in one place.

Level Playing Field for Innovative Services

An open and standards-based user payment agent will allow new services and solutions to find a place right next to established instruments. It will be up to the user to accept new payment instruments, coupons or cards. Introduction of a 'wallet service' should help to 'unbundle' a generic wallet functionality from a specific payment instrument, a merchant brand etc. Various business models are conceivable, while the concept will stay clear of prescribing or 'incorporating' business models in the agent specifications.

Reduction of Required Number of Involved Parties

This goal explicitly addresses the number of required parties, as every additional party might either cause an increase in costs or potential impact on privacy. It is a reverence to Kim Cameron's Laws of Identity asking for justifiable parties.

Reduced Abandonment in Online Shopping

The Payment Activity's charter states: '...the average shopping cart abandonment rate is 72% across all devices, and 97% on mobile.' A situation with hints to great acceptance barriers to users, with a heavy impact on business.

Business Processes

The user payment agent is defined on a level above individual solutions or practices which might have evolved in industries over decades or centuries. But it will have to categorize processes in order to achieve the unification according to usable patterns on the payer's side, like selecting an instrument, authenticating, communicating with the payee. With the ambition to cover web, proximity and further - perhaps not yet known - scenarios, the user payment agent needs to be positioned within relevant constellations of other actors and modules.

Device and Service Constellations

User Payment Agent on Device

A shopping website rendered in the browser of a device asks for payment, triggering the user payment agent (within the user agent - aka web browser - or outside of it, but on the same device - e.g. 'a wallet'). The user payment agent is started with a set of parameters and context information to present applicable options to the user, authenticate if needed and create feedback to the website.

Online User Payment Agent (Wallet in the Cloud)

A shopping website rendered in the browser of a device asks for payment, triggering a user payment agent in the web, which starts a new window, frame, pop-up or similar, passing a set of parameters and context information to the 'user payment agent service' in the web, which in turn is to present applicable options to the user, authenticate if needed and create feedback to the website.

User Payment Agent on 2nd Device (ffs)

A shopping website rendered in the browser of a device asks for payment, but there is either no user payment agent on or via the device available or the user decides to not use it. The website may be able to initiate ways to communicate with a second factor device (which may run a regular user payment agent) or a local instance on the device might be able to communicate with another device which actually runs the user's payment agent. (Example: a wallet on a mobile device is used to establish secure payment for a shopping cart created after a browsing session on a desktop)

Online Payment Service

The use of an online payment service through a user payment agent to serve a web shop scenario should be optional, as online payment services are built to integrate with shops directly. Essentially, replacing the use of a payment instrument authorizing the transaction with an online login and a confirmation of the transaction through the user. On the other hand, these services could be used in proximity cases in the same way, if represented in a user payment agent, creating a consistency and symmetry users might cherish. On the other hand merchants might like to support just one set of APIs in the future. Being able to also handle online payment services within a setup with a user payment agent should ease migration from legacy online payment to W3C payment standards.

2nd Factor Authentication

While the decomposition of payment services and the user payment agent promises several advantages, strong authentication has already practiced a separation of the communication device and the authentication hardware for security reasons. It doesn't seem unlikely that additional devices for strong authentication will come up in the payment scenarios. E.g. a service represented in a user payment agent on a PC might send a TAN to the user's pre-configure mobile device. Also authentication devices like a FIDO USB stick might be used for secure authentication in future payment implementations.

ID/ Payment Instrument Orchestration

The Payment CG has already stated the close relationship between Identity and Payment concepts. This relationship might be confused with authentication or at times even authorization functionality, it is per se, however, undeniable, and needs to be taken into account when working on the user payment agent.

No ID required

As to cover scenarios like we know them from the use of cash - payments might just need to be made with an appropriate instrument. From a privacy-perspective it might be even desirable to favor these scenarios. Upcoming 'tokenization' type payment instruments will even help to make the payment instruments hard to track for merchants, so better privacy may be achievable in the future. From an architecture point of view this might be considered as the 'base scenario' with the least context and processing requirements.

Pre-established Identity

Assuming a user has already been identified or logged in, the association between the user's identity and the payment transaction can be done in the website.

Pre-established Payment Instrument

The norm today for online shopping is to store payment information with e.g. a shop for use in all upcoming purchases. This has several consequences like a 'vendor lock-in' wrt/ payment service and shop, as well as between shop and payment service. It creates the necessity to store sensitive information, making it harder for the user to change payment instruments, update them and consequently creates problems with stale information on the merchant or payment service side. It is, however, conceivable, that a function within a user payment agent supports the user in authenticating to the site, helping to change payment instruments from a list of pre-registered ones, or migrating to a payment user agent-oriented solution.

Ad-hoc Identity at Payment

Internet businesses have learned that obstacles, like login or requesting payment information, should be postponed to the latest possible moment. It is, thus, conceivable that an anonymous shopping cart gets filled until the user is ready to pay. In the course of the following steps, the user payment agent should allow to transfer identity information - and authentication proof alongside the payment functionality.

Legacy Support

The better the user payment agent support existing mechanisms, the more likely it will make its way into the user's hands, while services are still running the most established systems. Convenience, transparency and security reasons should influence all actors into the direction of adopting user payment agents and the associated solutions. This should be an important step in the building of an ecosystem like a unified and convergent digital payment system.

Flows

• Push
• Pull

Layering and Architecture

Draft Framework

The diagram below is a very first proposal for a possible framework that split topics in various modules.

This diagram shows a layered architecture that could be a possible design of a wallet.

• The transport layer ensures convergence of payment solutions. layers on top of it should be able to work online (http) or through proximity interface (NFC, BTLE,etc.)
• The negotiation layer will allow payers and payees to negotiate the subset of payment instruments accepted by both parties with associated costs/benefits/etc. This layer is useful in the case of a multi-purpose wallet but optional for organizations interested in only one payment instrument.
• The payment layer deals with individual payment instrument. A few types of instruments are listed where standardization might be needed:
  • token-based payment where a user transfer a one time token to the merchant for the requested payment (similar to card-present scenario).
  • Push-based payment where a merchant push a bill to the customer who then send an order to his/her payment provider to pay the bill
  • CC-info payment is the case when a customer gives his/her credit card information to the merchant. While the objective is to replace this instrument on the long term, it is important to have a framework in which 99% of today's way of payment is still working.

A part from the type of payments, other modules needs to be considered to improve security and user experience. three have been identified and listed in the diagram: authentication, credential management, and digital receipt. Finally, during the first face2face meeting, the use of secure storage and secure element in particular has been mentioned as a critical element for security, and should therefore be adressed.

For each module, it will be essential to:

• identify the information that need to be exchanged between payers and payees, the data format for this information, the protocols and flow of information, and if needed the API needed for the module (right-side block)
• take into consideration the user privacy in the information that is exchanged (left-side block)
• identify the set of key players required to implement the module: mobile operator, secure hardware manufacturer, browser maker, device manufacturers (POS, mobile, etc.)

And an alternative technology stack.

The stack roughly follows a pattern which should be maintainable on various layers as a kind of 'self-likeness' of its components.

• the UI and Meta-data abstraction are meant to be unique and allow to combine legacy with new web standards, bridging web and proximity use if required.
• The capabilities and the respective abstraction layer is also meant to be unique, but explicitly allows for solutions to 'have their own ways' with hardware and OS capabilities if it can't be avoided.
• The middle section represents the functionality per se. The left hand side is basically blank to illustrate that proprietary and existing legacy solutions can be fitted into the framework. (Doesn't work for everything - but for most.) The right hand side would be the main job for the W3C standardization activities - and liaisons with other bodies - to plug standards together and come up with new ones if needed.

Each of the individual boxes might be 'zoomed' into, and appear as another 'middle section' of the stack: allowing for legacy/ proprietary technology and specifying a most desirable stack as a standard for that specific function. The 'Web Payment Transaction Protocol' serves as a bracket, representing the ambitions of the Payment IG with respect to payment transactions in the widest sense.

(to be discussed in the task force call on Dec. 5)

Attempt at harmonizing versions 1 and 2 above

Version 3 of the Payment Agent (Wallet) big picture overview

Flows and Protocols

Transaction Definition

The User Payment Agent will primarily be called when a transaction is to be carried out and user confirmation, authentication or authorization is needed, using one of the payment instruments available. A specification for such a transaction must, thus, contain all information needed to inform the user and feed all required information into the payment instrument. The description should allow for comprehensive, information without overloading but require very little mandatorily in order to not stand in the way of innovation. On the other hand it should require information which is definitely needed to make sure the user can make an 'informed decision'. Further uses of information elements required may support automation, transparency, or data to solve more complex transactions (as 'dutch bills' or compound transactions open for multiple items from the agent (payment, coupons, loyalty).

Generic Flow Chart for interaction between Agent and service

Sub-routines of Importance

• Statement of Accepted Means
• Authentication of Payment Instrument
• Authentication of User
• Authorization of Transaction
• Feedback by Merchant
• ...

Data Elements

• Meta-Data on Payment Instrument
• Meta-Data on Identity
• Meta-Data on Coupon/ Loyalty, ...
• Transaction Data
• Receipting Data

Contributions

Ideas on flows to be supported and other topics are parked on the Payment Agent Contributions page pending acceptance by the task force.