Leader: Joerg Heuer

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

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 the architecture of a framework identifying the various modules the IG is working on. This task force should help defining the IG roadmap deliverable.

Content

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.

High-level Overview

The user payment agent is meant to be a piece of software referred to by either a) the user, b) the W3C user agent, aka web browser, or c) any other application which asks for claims or credential presentation in order to process payment, authentication, permission control, personalization, or other transactions. The user payment agent does not usually implement any payment, authentication or authorization schema of its own; it acts, however, as the user's tool to pick the instruments to be used in such a process, to orchestrate and keep an overview of the use of its contents. To the issuer it represents the place where items are presented to the user, organized and put to use, while at the same time it mediates the capabilities of the device and functional modules provided by issuers or their technology vendors to implement e.g. a specific payment schema.

Scope of the 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 local applications, 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.)

Interfaces and protocols to be devised

• Invocation and parameterization of the user payment agent through the web browser, aka 'user agent'. Should 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.

Key Concepts

• Itemization
  

Creating a usage pattern alongside the use of objects in a physical wallet. Allows to re-create virtualizations of cards, coupons, tickets and keys in the UI, but also for their respective management processes.

• Convergence
  

Creates a harmonized handling across different dimensions of digitalization. Mainly covering the web platform and many forms of 'human-to-machine' interactions using NFC, optical codes, vicinity and proximity technologies e.g.

• Offline Capability and Hardware Security Support
  

Like a real-world wallet, the content of a digital wallet needs to be available when no Internet connection is available. If hardware security is available, this can be used to act as a token for strong authentication, as many of the SmartCard-based security tokens or more concretely, as a payment card with an autonomous authorization functionality to allow for offline payment scenarios.

Features

Layering and Architecture

Figure TBD

Item-import and Item-based Communication

Modularization of Functions

User-side Orchestration

User-control and User-side Automation

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 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(s). As a consequence, flows are to be considered on either level:

• the overall payment transaction (wallet) level

The description on the overall transactions level should allow for comprehensive, information without overloading the user interface. Very little should be required mandatorily in order to not stand in the way of innovation. On the other hand it has to make sure the user can make an 'informed decision'.

Further information elements in the overall transaction 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).

• specific functional implementation level (e.g. a specific credit card schema, a loyalty card implementation or an OpenID Connect-based login procedure)

for which this IG can make recommendations, but which needs to be open for proprietary and legacy implementations.

Generic Flow Chart for interaction between Agent and service

Elementary Phases and Usage Patterns

• Statement of Acceptence
• 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