Main Page/FTF June2015/Capabilities

Goals

• Shared understanding of how these capabiltiies relate to needed working groups and charters
• Identification of any additional capabilities needed to fulfill roadmap
• Consensus on organization of capabilities

For Discussion

• Web Payments Capabilities
• Key rationale and for how these capabilities are organized
• Incremental approach to capablities (Now and Next) and relationship to charters

Not for this discussion

• Prioritization (that happens after this session)
• The order of specific capabilities beyond initial grouping
• Specific fine grained features (unless needed to discuss broad capability gaps)

Web Payments Capabilities: Where are we now?

Five Course Grained Groups of Capabilities

1. Core and Security - Includes: Key Creation and Management, Cryptographic Signatures, Encryption
2. Identity and Credentials - Includes: Identity, Credentials, Rights, Authentication, Authorization, Privacy, Discovery, Registration, Enrollment, and Legal/Regulatory concerns
3. Accounts and Settlement - Includes: Accounts, Ledgers, and Legal/Regulatory concerns related to accounting and recorded ownership.
4. Payments and Exchange - Includes: Payment, Messaging, Clearing, Markets, Foreign/Currency Exchange, and Legal/regulatory concerns specific to Payments and Exchange of Value.
5. Commerce - Includes: Offers, Invoicing, Receipts, Loyalty, Rewards, Contracts, Lending, Insurance, Taxation, Legal/Regulatory concerns related to aspects of commercial and economic interactions

UpdatedCapabilityGroups

Why did we organize capabilities in this way

• Web payments standards are intricately linked to other web interactions used outside of payment process (ex. trust, commerce and account management)
• Groupings allow for coordinated yet de-coupled implementation of standards
• Provides consistent way of grouping IG requirements and work over multiple standards versions
• Allows for foundational capabilities and interactions that are broader than payments (such as Credentials and Commerce) to incorporate features that are needed for interoperability between payments and non-payments work
• Facilitates discussion of standards using discrete interactions between roles

Now and Next: Base-lining capabilities and Capability evolution

• As mentioned earlier, by organizing capabilities into consistent groups, chartered working groups will be able to proceed on initial standards versions while IG continues work on requirements for subsequent versions.
• Also allows for loose-coupling between payments and related working groups and standards bodies
• NOTE: Focus for this meeting is to ensure that features needed to meet initial use cases and goals are captured (the "now" features)
• Groupings serve as a place to capture additional needs ("next" features) and can also be quickly captured without slowing work on immediate needs

Payments interactions

• Payments (and interconnected capabilties) can be expressed as a series of discrete interactions between two parties.
• Interactions may involve many different parties which play different roles at different times
• A payment interaction may involve just two parties (e.g., peer-to-peer) or more complex interactions may involve several collaborating parties.
• These interactions may happen in different sequences and direction depending on the payment context.

Example Interactions

Interaction 1: Payee presents request for payment to Payer with necessary payment end point details	Interaction 2: Payer connects to Payment Service Provider and intiaties Payment using provided details	Interaction 3: Payers Payment Service Provider completes payment to specific Payment End Point and sends confirmation of payment to Payee's Payment Service provider

Questions

• Are there any capabilities required for the now use cases that don't fit cleanly into this approach?
• Are there any capabilities that are missing relative to our stated goals?
• Is there agreement on the approach and initial set of capabilities needing standardization?