Rework document structure to incorporate requirements and refined architecture focus on a unified representation.
--- a/latest/payment-agent/index.html Sun Apr 12 23:06:01 2015 -0500
+++ b/latest/payment-agent/index.html Fri Apr 17 01:23:27 2015 -0500
@@ -1,7 +1,7 @@
<!DOCTYPE html>
<html>
<head>
- <title>Web Payments Payment Agent</title>
+ <title>Towards a Unified Architecture for Payments on the Web</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<script src='../respec-w3c-common.js' class='remove'></script>
<script src='../respec-webpayments.js' class='remove'></script>
@@ -86,173 +86,115 @@
<section id='sotd'>
<p>
-Custom Status of the Document language goes here.
+ This document is in early draft state and is expected to rapidly evolve based on broad feedback and input from the Web Payments Interest Group
</p>
</section>
- <section>
- <h2>Introduction</h2>
- This section will provide introductory context and outline key problems that the Conceptual Architecture for payments on the Web is trying to address
-
-
- <section>
- <h3>The Challenge with Payments on the Web</h3>
- This section will provide introductory context and outline key problems that the Payment Agent Architecture is trying to address
- </section>
-
- <section>
- <h3>Key Principles and Goals</h3>
- <p>This Section will provide an introduction to Key principles, abstractions and rationale behind the subsequent proposal. This section should also clearly outline what the architecture is NOT intended to do. (ex. replace existing payments standards such as ISO20022 or IS12812.</p>
- <p>
- Key Principles/Goals that this Conceptual Architecture is intended to address:
- <ol type='1'>
- <li>Provide a standard inteface for the collection and exchange of payment related information from user agents (ex. browsers, apps, or other web-enabled clients) which meets the following criteria:
- <ol type='a'>
- <li>Supports consistent, secure interface and apis for communication of payment data required to support payment schemes (ex. cards, digital currency, etc.) for common data elements</li>
- <li>Provides ability to access information needed as part of the payment process in a standard way (ex, authentication data, account information, loyalty cards, etc.)</li>
- <li>Is consistent across multiple deployment contaniners found on the web (ex. Mobile, Laptop, etc)/li>
- <li>Supports access from either local or remote user agents</li>
- <li>Supports communication with existing and future payment schemes/infrastructure to facilitate value tranfer</li>
- <li>Coordinates with other payment agents to facilitate payments related information flows</li>
- <li>Supports accessbility of payments on the web by incorporating all accessibility standards and promoting interoperabiltiy with user agents which support users with diabilities.
-
- </ol>
- </li>
- </ol>
- </p>
- </p>
- </section>
+ <section> <h2>Introduction</h2>
+ <section> <h3>Purpose of this document</h3>
+ This document is intended to outline key characteristics, requirements and desired goals of a unified architecture for payments and related services on the world wide web. This document and the conceptual architecture it is intended to describe are based on the use cases defined as part of the W3C's Web Payments Interest Group which can be found <a href="http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/">here</a>.
+ </section>
+ <section> <h3>How this document is organized</h3> </section>
+</section>
+<section><h2>Summary Requirements</h2>
+ <section><h3>Functional Requirements</h3>
+This goal of this section is to outline a high level, easy to understand description of summary requirements that the proposed architecture must provide to support unified payments on the web in a manner which also addresses the overarching goals outlined in the <a href="http://www.w3.org/2014/04/payments/webpayments_charter.html">W3C Web Payments Charter</a> . Requirements have been grouped into functional categories to:
+<ul>
+ <li>facilitate readability of this document</li>
+ <li>outline and identify relevant or related standards specific to the category</li>
+ <li>communicate functional needs for additinal standards that may be needed to technical working groups</li>
+</ul>
+ The functional requirements categories used by this document are:
+ <ul>
+ <li><b>UA</b> - User Agent:</li>
+ <li><b>IA</b> - Identity and Authentication</li>
+ <li><b>CA</b> - Credentials and Authorization</li>
+ <li><b>CS</b> - Digital Contracts and Signatures</li>
+ <li><b>LD</b> - Loyalty and Discounts</li>
+ <li><b>LA</b> - Ledgers and Accounting</li>
+ <li><b>T</b> - Taxation</li>
+ <li><b>FX</b> - Currency Conversion and Foreign Exchange</li>
+ <li><b>RI</b> - Receipts and Invoicing</li>
+ <li><b>PS</b> - Payment Messaging, Clearing and Settlement</li>
+ <li><b>DS</b> - Delivery and Shipping</li>
+ <li><b>SC</b> - Payment Scheduling and Calendering</li>
+ <li><b>RR</b> - Regulatory and Reporting</li>
+ <li><b>WA</b> - Wallet and Paymnet Instrument Provisioning and Administration</li>
+ <li><b>SA</b> - Security and Auditing</li>
+ </ul>
+ <p class="note">Following the introduction of categories above, this section will include a categorized table of mandatory list of core/functional requirements that the architecture must support </p>
+</section>
- <section>
- <h3>Elements of a Unified Web Payments Architecture</h3>
- This section outlines a higher level, easy to understand description of elements needed to support payments on the web in a manner which acheives above listed goals. This section may also list known available or in process standards that can help to leverage corresponding standards that have already been created.
- <section><h4>Towards a unified Web Payments Architecture - Simple example and core functionality</h4></section>
- <section><h4>User Agent</h4></section>
- <section><h4>Identity and Authentication Functionality</h4></section>
- <section><h4>Credential Functionality</h4></section>
- <section><h4>Digital Signature Functionality</h4></section>
- <section><h4>Loyalty Functionality</h4></section>
- <section><h4>Ledger and Accounting Functionality</h4></section>
- <section><h4>Taxation Functionality</h4></section>
- <section><h4>Receipts and Invoicing Functionality</h4></section>
- <section><h4>Payment Messaging, Clearing and Settlement Functionality</h4></section>
- <section><h4>Delivery and Shipping Functionality</h4></section>
- <section><h4>Payment Scheduling and Calendering</h4></section>
- <section><h4>Receipts and Invoicing Functionality</h4></section>
- <section><h4>Regulatory and Reporting</h4></section>
- <section><h4>Wallet and Instrument provisioning and administration</h4></section>
- <section><h4>Security and Auditing</h4></section>
- </section>
-
- <section>
- <h3>Deployment Contexts (Containers)</h3>
- This section of the document provides an introduction to the types of infrastructure (ex. mobile device, Server, etc) that would likely host components of the architecture. This is important as specific deployment contexts may create constraints that impact how elements of the architecture can be implemented. This section will also highlight specfic standards that may apply to a speicific portion of the overll architecture.
- <section><h4>Overview</h4></section>
- <section><h4>Mobile Device</h4>
- <section><h5>Web Browser</h5></section>
- <section><h5>Native Application</h5></section>
- </section>
- <section><h4>Personal Computer</h4>
- <section><h5>Web Browser</h5></section>
- <section><h5>Native Application</h5></section>
- </section>
- <section><h4>WebSite</h4>
- <section><h5>Application Server</h5></section>
- <section><h5>Stand alone process</h5></section>
- </section>
- <section><h4>Point of Sale Device</h4></section>
- <section><h4>Screen Reader</h4></section>
- <section><h4>Watch</h4></section>
- <section><h4>Other Devices (IOT)</h4></section>
- </section>
-
- <section>
- <h3>Functional Contexts (Role)</h3>
- This section of the document outlines examples of functional contexts for components of a web paymnets architecture and outlines considerations regarding their needs.
- <section><h4>Payer Context</h4></section>
- <section><h4>Payee Context</h4></section>
- <section><h4>Wallet Provider Context</h4></section>
- <section><h4>Payment System Context</h4></section>
- <section><h4>Regulatory Context</h4></section>
- <section><h4>3rd Party Service Provider Context</h4></section>
- </section>
-
- <section>
- <h3>Putting things together</h3>
- <p>
- This section of the document will outline a more detailed view of how the payment architecture concepts might be deployed in context as part of a multi-user agent payment processing flow. For example, this section could include an overview of how specific user agents of the Payer such as a digital Wallet interact with specific user agents of the Payee such as a digital POS terminal and user agents of payment processors such as payment processing schemes to facilitate payment.
-
- </p>
- </section>
+<section><h3>Role Based Contextual Requirements</h3>
+ In addition to functional groupings of requirements, this document also identifies requirements which are based on the role or context of the actors in the payments process and which may be unique to the actors role in the process. The following roles/contexts have been identified for use in this document:
+ <ul>
+ <li><b>PC</b> - Payer Context</li>
+ <li><b>EC</b> - Payee Context</li>
+ <li><b>WP</b> - Wallet Provider Context</li>
+ <li><b>PS</b> - Payment System Context</li>
+ <li><b>RG</b> - Regulatory Context</li>
+ <li><b>TP</b> - Third Party Service Provider Context</li>
+ <p class="note">Not sure if this is better covered in the detailed use case illustration section below</p>
+ </ul>
+</section>
+<section><h3>Non-Functional and Aggregate Architecture Requirements</h3>
+ This section captures identified non-functional and aggregate architecture requirements which are required to support overarching goals such as security, interoperability, etc.
+ Non-Functional and Aggregate Architecture Requirements have been captured using the following categories:
+ <ul>
+ <li><b>KP</b> - Key Principles</li>
+ <li><b>SE</b> - Security</li>
+ <li><b>IO</b> - Interoperability</li>
+ <li><b>SC</b> - Scalability</li>
+ <li><b>ETC</b> - ETC</li>
+ <li><b>ETC</b> - ETC</li>
+ </ul>
+</section>
+</section>
+
+<section> <h2>Key Architecture Concepts and Terminology</h2>
+ <p>This section of the document will outline key concepts and terminology used to describe a unified architure for payments on the web. This architecture is might be deployed in context as part of a multi-user agent payment processing flow. For example, this section could include an overview of how specific user agents of the Payer such as a digital Wallet interact with specific user agents of the Payee such as a digital POS terminal and user agents of payment processors such as payment processing schemes to facilitate payment. </p>
+ <section><h3>Simple example</h3>
+ <p class="note">This section will contain one or more simple diagrams and descriptions which are intended to introduce key architecture concepts </p>
+ </section>
+ <section><h3>Key Concept: The Symetrical Web of Payments</h3>
+ <p class="note">This section will focus on illustrating the key architectural principle of Symetry of core capabilities</p>
+ </section>
+ <section><h3>Key Concept: Payment Relays</h3>
+ <p class="note">This section will focus on illustrating the key architectural principle that allows for multiple parties in the payment process to use one or more "agents" to facilitate the payments process</p>
+ </section>
+</section>
</section>
<section>
<h2>Detailed Requirements and Use Case Illustration</h2>
- <section>
- <h3>Required (core) Capabilities</h3>
- <p>This section outlines the required capabilities that all User Agents involved with the payments process and associated communication protocols must provide to meet minimal viable requirements:
- <ul>
- <li>Ability to receive and reply with standard formatted messages following payment agent functional/protocol specifications</li>
- <li>Abiltiy to interact with user agent Display Services for displaying payment related information</li>
- <li>Ability support synchornization between multiple payment agents operating on behalf of a single user agent</li>
- <li>Ability to support user agents running locally and remotely from payment agent</li>
-
- (NEED TO TIE TO CORE STANDARDS)
-
- </ul>
- </p>
- </section>
-
- <section>
- <h3>Optional Capabilities</h3>
- <p>This section outlines the capabilities that User Agents involved with the payments process could provide but are not required in all contexts
-
- <ul>
- <li>Ability to communicate with Host Device Camera for accepting payment related info via visual input (ex. QR code or Bar code, etc)</li>
- <li>Abiltiy to interact with Host Device Microphone for accepting payment related information via transmission of sound</li>
- <li>Ability to interact with Host Biometric Services for accepting biometric authentication data required for payment process</li>
- <li>Ability to interact with Host NFC (Near Field Contact) services to support proximity payments flows</li>
- <li>Ability to interact Host with BLE (Blue Tooth Low Energy) services to support local/proximity information exchange needed to support localized offers (ex. in store beacons)</li>
- </ul>
- (NEED TO TIE TO CORE STANDARDS)
- </p>
- </section>
+ <section><h3>Negotiation of Payment Terms</h3>
+ <p class="note">This section will contain one or more simple diagrams and descriptions which are intended to illustrate key architecture concepts in the context of each phase of the payments process. It will also describe any specific architecture variations specific to use cases to help provide guidance to working groups and technical architecture groups that will be working on developing specifications and standards to meet the outlined requirements</p>
+ General Overview </br>
+ 1.1 Discovery of Offer</br>
+ 1.2 Agreement on Terms</br>
+ 1.3 Application of Marketing Elements</br>
+ </section>
+ <section><h3>Negotiation of Payment Instruments</h3>
+ General Overview </br>
+ 2.1 Discovery of Accepted Schemes</br>
+ 2.2 Selection of Payment Instruments</br.>
+ 2.3 Authentication to Access Instruments</section>
+ <section><h3>Payment Processing</h3>
+ General Overview</br>
+ 3.1 Initiation of Processing</br>
+ 3.2 Verification of Available Funds</br>
+ 3.3 Authorization of Transfer</br>
+ 3.4 Completion of Transfer</br>
+ </section>
+ <section><h3>Delivery of Product/Receipt and Refunds</h3>
+ General Overview</br>
+ 4.1 Delivery of Product</br>
+ 4.2 Delivery of Receipt</br>
+ 4.3 Refunds</br>
+ </section>
- <section><h3>Use Case Illustration</h3> </section>
- </section>
- <section><h2>Reference</h2>
-
- <section>
- <h2>API Reference</h2>
- <p>
- The Payment Agent Protocol is a standard protocol and set of capabilities's which facilitate exchange of payment related data in a standard manner with user agents. The following is a list of the capabilities's that the Payment Agent protocol will support:
- <ul>
- <li>Identification and Authentication of Payment Participants</li>
- <li>Payment Scheme/Instrument selection, clearing and settlement</li>
- <li>Contracts and conditional payment</li>
- <li>Authorization, Monitoring and Control</li>
- <li>Ledger and Accounting</li>
- <li>Taxation</li>
- <li>Delivery and Shipping</li>
- <li>Payment Scheduling and Calendering</li>
- <li>Regulatory and Reporting</li>
- <li>Wallet and Instrument provisioning and administration</li>
- <li>Security and Auditing</li>
- </ul>
- </p>
- </section>
- <section>
- <h2>Standards Reference</h2>
- <p>
- The following standards are included due to their relevance to the goals of the Web Payments initiative.
- <ul>
- <li>ISO20022</li>
- <li>ANSI X9<li>
- <li>ETC</li>
- </ul>
- </p>
- </section>
+
<section>
<h2>Additional Use Cases and Examples</h2>
@@ -262,6 +204,7 @@
</p>
</section>
</section>
+
<section>
<h2>Acknowledgements</h2>
@@ -274,6 +217,8 @@
</p>
</section>
+ <section><h2>Appendix</h2></section>
+ <section><h3>Detailed Requirements Traceability Matrix</h3></section>
</body>
</html>