Output from the breakout

Use Cases

• Credentials (Agreement on Terms)
  • OUT for v1
  • Should be done in parallel through a separate WG
  • Should not be tightly integrated with the payments work
  • Recommend that a Credentials WG is formed

• Registration-less (Agreement on Terms)
  • IN for v1
  • Reword to clarify misunderstanding around definition of “credential” (strip it out)
  • Optional gathering of one time user/profile data (Example: Postal address)

• Multi-Factor (Authentication to Access Instruments)
  • IN for v1
  • Important due to industry requirements but shouldn’t be on critical path

• Payer-initiated (Initiation of Processing)
  • IN for v1
  • Requires elements of invoicing (payee info and terms) which has been dropped
  • Propose that a new document be standardized - Request for payment document std

• Physical Goods (Delivery of Product)
  • IN for v1
  • Brings in a need to capture additional data during flow

• Electronic Receipts (Delivery of Receipt)
  • IN for v1
  • Issue is finding a format that will work globally
  • Don't standardize receipt, instead standardize a payment confirmation
  • Optional link to receipt (can be accessible only by end user) - merchants don't want receipts to be accessible to everyone in payment flow
  • Confirmation is done at time of auth (mandatory)
  • Other messaging/confirmations can be done in later versions

• Subscription (Agreement on Terms)
  • IN for v1 (Stretch goal)
  • Strong demand from industry

• Biometric (Authentication to Access Instruments)
  • OUT in v1
  • Incorporated into multi-factor use case

• Common Refunds (Refunds)
  • IN for v1 (Stretch goal)
  • Strong demand from esp retail industry

X9 Response

• Group approves feedback compiled by Claudia and Pat
• Scope in phases to ensure we can tackle such a large problem

Glossary

• CRUD approach (start with reading what is there)
• Needs some reorganizing (Evert will take lead)
• Before end of F2F pick a format and get consensus on a few key terms
• Diagrams - need to decide what to do with them (suggest they go in Capabilities doc)

Super Revised Use Cases List That We're Sort Of Okay With

• Website (Discovery of Offer)
• Registration-less (Agreement on Terms)
• One Time Payment (Agreement on Terms)
• Ubiquitous Schemes (Discover of Accepted Schemes)
• Discovery (Selection of Payment Instruments)
• Payer Privacy (Selection of Payment Instruments)
• Manual Selection (Selection of Payment Instruments)
• MISSING USE CASE - password-based access to cloud-based instrument (Authentication to Access Instruments)
• Multi-Factor (Authentication to Access Instruments) [includes biometric, not in critical path]
• Payee-initiated (Initiation of Processing)
• Payer-initiated (Initiation of Processing)
• Proofs (Authorization of Transfer)
• Virtual Goods (Delivery of Product)
• Physical Goods (Delivery of Product)
• Electronic Receipts (Delivery of Receipt) [extremely basic for v1]
• Subscription (Agreement on Terms) [Stretch Goal]
• Common Refunds (Refunds) [Stretch goal]

• Credentials (Agreement on Terms) [OUT for V1, but maybe in parallel group]