Use Cases Task Force/Requirements

Status: This is a work in progress. This document is a list of requirements derived by analyzing the use cases of the Web Payments Interest Group. Interest Group participants are invited to add to this document!

How this document is organized

• This document lists the complete set of Web Payments Use Cases, grouped by the four phases defined in that document.
  • Note: This document does not prioritize those use cases; see separate prioritization discussion
• We are developing a set of topics to help us analyze each use case systematically. These topics are experimental and may change based on our experience.
• The topics are:
  • Core Web Technology
  • Operating System
  • Identity and Authentication
  • Security and Privacy
  • Usability
  • Accessibility
  • Vocabulary / Machine readability
  • Exceptions
  • Regulatory and reporting
  • Clearing and Settlement
  • Digital Marketing
• It is likely that there will not be requirements for all these topics for many of the use cases.
• Each use case may have a "comments" subsection.
• Please use must, should, and may in accordance with RFC 2119

Negotiation of Payment Terms

Discovery of Offer

Website

• Vocabulary / Machine readability
  • Question: What is the expectation that there is a standardized format (in markup or JSON) for expression of the offer?

Comments

• We do not anticipate requiring additional core Web technology specific for payments for the expression of the offer.

Point of Sale Kiosk

Mobile

Freemium

E-mail

Hold Funds

Pre-authorization

Machine Readability

Live Market Prices

Trial-ware

In-vehicle

Agreement on Terms

Credentials

Privacy Protection

Need to Know

One-time Payment

Invoices

Subscription

Registration-less

Full Disclosure

Application of Marketing Elements

Coupons

Loyalty Cards

Store Credit

Negotiation of Payment Instruments

Discovery of Accepted Schemes

Ubiquitous Schemes

Emerging Schemes

Selection of Payment Instruments

Discovery

Manual Selection

Automatic Selection

Payer Privacy

Authentication to Access Instruments

Multi-Factor

Regulatory Blocks

Biometric

Payment Processing

Initiation of Processing

Payee-initiated

Payer-initiated

Verification of Available Funds

Hold Verification

Funds Verification

Authorization of Transfer

Proofs

Completion of Transfer

Variation of Delay

Notifications

Delivery of Product/Receipt and Refunds

Delivery of Product

Physical Goods

Virtual Goods

Delivery of Receipt

Electronic Receipts

Physical Receipts

Refunds

Common Refunds

Notes based on Erik Anderson Comments

Identifiers

• We expect to need identifiers for:
  • Accounts. These identifiers may be scheme-specific.
  • Invoices (e.g., for receipts). These identifiers may be scheme-specific.
• Where we need identifiers and they are not yet defined (e.g., within a given scheme), we will tend to use URIs.

Account Identifiers

• Account providers will issue account identifiers, which may vary in structure and syntax according to payment scheme.
• Account providers must take measures to ensure that account identifiers are not, on their own, sufficient to identify the account holder.
  • Erik: there are legal reasons for this requirement.

Identity

• To satisfy regulatory requirements and financial industry expectations, some use cases will require strong assurances of connections between a Web identity and a real-world identity.
• Parties will establish identity through a variety of attributes; the system must be flexible enough to support diverse digitally expressed attributes.
• There are use cases where identity must be pseudo anonymous and unique per transaction but forensically linkable back to the user.

Authentication

• Account providers will determine what degree of certainty they require for a given payment (e.g., more required for large sums or cross-border transactions).
• We anticipate multi-factor authentication will be used increasingly, although the techniques used will continue to evolve and will depend on the needs of the account provider and the capabilities available to the user.
  • Question: Does this imply some negotiation of acceptable authentication schemes between account provider and user (about their context)? If so, what are the privacy implications?
• It is important to take into account accessibility requirements when using biometrics for authentication.

Delegation

• Need to support delegation of identity including to machines.
  • We don't yet know how identifiers fit into the delegation.

Invoices

• How to avoid spoofing
• How obscure must information be when given to payment instrument? (so that merchant receives obscure version of invoice number, for example).

Crypto

• Question: Will we require usage of WebCrypto API? What if industry requirements involve other standards?
• We anticipate that cryptographic objects will contain another cryptographic objects (e.g., encrypted information from the merchant may be sent to a regulatory inside a package with additional information from the account provider that is itself encrypted).