--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/.gitignore Sun Jul 12 07:14:14 2015 -0700
@@ -0,0 +1,1 @@
+.idea/
Binary file latest/capabilities/images/image00.png has changed
Binary file latest/capabilities/images/image01.png has changed
Binary file latest/capabilities/images/image02.png has changed
Binary file latest/capabilities/images/image03.png has changed
Binary file latest/capabilities/images/image04.png has changed
--- a/latest/capabilities/index.html Wed Jul 01 16:32:19 2015 +0200
+++ b/latest/capabilities/index.html Sun Jul 12 07:14:14 2015 -0700
@@ -1,168 +1,186 @@
<!DOCTYPE html>
<html>
- <head>
- <title>Web Payments: Capabilities 1.0</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>
- <script class='remove'>
+<head>
+<title>Web Payments: Capabilities 1.0</title>
+<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+<script src="../common/biblio.js" class="remove"></script>
+<script src='../respec-w3c-common.js' class='remove'></script>
+<script src='../respec-webpayments.js' class='remove'></script>
+<script src="../common/script/resolveReferences.js" class="remove"></script>
+<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
- specStatus: "ED",
-
- // the specification's short name, as in http://www.w3.org/TR/short-name/
- shortName: "web-payments-capabilities",
-
- // if you wish the publication date to be other than today, set this
- // publishDate: "2009-08-06",
-
- // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
- // and its maturity status
- // previousPublishDate: "1977-03-15",
- // previousMaturity: "CG-DRAFT",
+specStatus: "ED",
- // if there a publicly available Editor's Draft, this is the link
- edDraftURI: "dvcs.w3.org/hg/webpayments/raw-file/default/latest/capabilities/index.html",
-
- // if this is a LCWD, uncomment and set the end of its review period
- // lcEnd: "2009-08-05",
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "web-payments-capabilities",
- // if you want to have extra CSS, append them to this list
- // it is recommended that the respec.css stylesheet be kept
- //extraCSS: [],
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2009-08-06",
- // editors, add as many as you like
- // only "name" is required
- editors: [{
- name: "Pat Adler",
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ // previousPublishDate: "1977-03-15",
+ // previousMaturity: "CG-DRAFT",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "dvcs.w3.org/hg/webpayments/raw-file/default/latest/capabilities/index.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ //extraCSS: [],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [{
+name: "Pat Adler",
url: "https://www.linkedin.com/pub/patrick-adler/2/730/2b4",
company: "Federal Reserve Bank of Chicago",
companyURL: "http://www.federalreserve.gov/"
- }, {
- name: "Adrian Hope-Bailie",
+ }, {
+name: "Adrian Hope-Bailie",
url: "https://www.linkedin.com/in/adrianhopebailie",
company: "Ripple Labs", companyURL: "https://www.telekom.com/"
- }, {
- name: "Ian Jacobs", url: "http://www.w3.org/People/Jacobs/",
+ }, {
+name: "Ian Jacobs", url: "http://www.w3.org/People/Jacobs/",
company: "W3C", companyURL: "http://www.w3.org"
- }, {
- name: "Manu Sporny", url: "https://manu.sporny.org",
+ }, {
+name: "Shane McCarron", url: 'http://blog.halindrome.com',
company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/"
- }],
+ }, {
+name: "Manu Sporny", url: "https://manu.sporny.org",
+ company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/"
+ }],
- // authors, add as many as you like.
- // This is optional, uncomment if you have authors as well as editors.
- // only "name" is required. Same format as editors.
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
- authors: [{
- name: "Patrick Adler",
+authors: [{
+name: "Patrick Adler",
url: "",
company: "Federal Reserve Bank of Chicago",
companyURL: ""
- }, {
- name: "Adrian Hope-Bailie",
+ }, {
+name: "Adrian Hope-Bailie",
url: "",
company: "Ripple Labs",
companyURL: ""
- }, {
- name: "Ian Jacobs",
+ }, {
+name: "Ian Jacobs",
url: "",
company: "W3C",
companyURL: ""
- }, {
- name: "Manu Sporny",
- url: "",
- company: "Digital Bazaar",
- companyURL: ""
- }, {
- name: "Jörg Heuer",
- url: "",
- company: "Deutsche Telekom",
- companyURL: ""
- }, {
- name: "David Ezell",
- url: "",
- company: "National Association of Convenience Stores (NACS)",
- companyURL: ""
- }, {
- name: "Dave Raggett",
- url: "",
- company: "W3C",
- companyURL: ""
- }, {
- name: "Katie Haritos-Shea",
- url: "",
- company: "W3C Invited Expert",
- companyURL: ""
- }],
-
- // maximum level of table of contents
- maxTocLevel: 3,
-
- // name of the WG
- wg: "Web Payments Interest Group",
+ }, {
+name: "Manu Sporny",
+ url: "",
+ company: "Digital Bazaar",
+ companyURL: ""
+ }, {
+name: "Jörg Heuer",
+ url: "",
+ company: "Deutsche Telekom",
+ companyURL: ""
+ }, {
+name: "David Ezell",
+ url: "",
+ company: "National Association of Convenience Stores (NACS)",
+ companyURL: ""
+ }, {
+name: "Dave Raggett",
+ url: "",
+ company: "W3C",
+ companyURL: ""
+ }, {
+name: "Katie Haritos-Shea",
+ url: "",
+ company: "W3C Invited Expert",
+ companyURL: ""
+ }],
- // URI of the public WG page
- wgURI: "http://www.w3.org/blog/wpig/",
-
- // name (with the @w3c.org) of the public mailing to which comments are due
- wgPublicList: "public-webpayments-comments@w3.org",
+ // maximum level of table of contents
+maxTocLevel: 3,
- // URI of the patent status for this WG, for Rec-track documents
- // !!!! IMPORTANT !!!!
- // This is important for Rec-track documents, do not copy a patent URI from a random
- // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
- // Team Contact.
- wgPatentURI: "http://www.w3.org/2004/01/pp-impl/73816/status",
+ // name of the WG
+ wg: "Web Payments Interest Group",
- preProcess: [ webpayments.preProcess ]/*,
- alternateFormats: [ {uri: "diff-20111214.html", label: "diff to previous version"} ],
- */
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/blog/wpig/",
+
+ // name (with the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-webpayments-comments@w3.org",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "http://www.w3.org/2004/01/pp-impl/73816/status",
+
+ // see common/biblio.js for a list of specs that we might need to reference
+ localBiblio: biblio,
+ preProcess: [ webpayments.preProcess ]/*,
+ alternateFormats: [ {uri: "diff-20111214.html", label: "diff to previous version"} ],
+ */
};
- </script>
- </head>
+</script>
+<style>
+.group-capability
+{
+ margin-left: 2em;
+ margin-top: .5em;
+ margin-bottom: .5em;
+}
+</style>
+</head>
<body>
- <section id='abstract'>
+<section id='abstract'>
+ <p>Payments and the ability to exchange value efficiently and securely over the
+ web are critical to global commerce. Open standards for payments and value
+ exchange help ensure open access and interoperability to financial systems for
+ all the people that use the Web. This document describes aset of capabilities
+ that, if standardized, will improve payments on the Web.</p>
+</section>
+
+<section id='sotd'>
<p>
-Payments and the ability to exchange value efficiently and securely over the
-web are critical to global commerce. Open standards for payments and value
-exchange help ensure open access and interoperability to financial systems for
-all the people that use the Web. This document describes aset of capabilities
-that, if standardized, will improve payments on the Web.
+ 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>
- <section id='sotd'>
- <p>
-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 id="introduction">
+ <h2>Introduction</h2>
+ <p>This document needs an introduction! - SPM</p>
+</section>
- <section id="relationships">
+<section id="relationships">
<h2>Relationship to Other Documents</h2>
<p>In addition to this document, the Web Payments Interest Group is
developing:</p>
<ul>
- <li>A <a href="https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force/Vision">
- Vision for Web Payments</a> describes the desirable properties of a Web
- payments architecture.</li>
+ <li>A <a href="https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force/Vision">
+ Vision for Web Payments</a> describes the desirable properties of a Web
+ payments architecture.</li>
- <li><a href="http://www.w3.org/TR/web-payments-use-cases/">
- Web Payments Use Cases 1.0</a> is a prioritized list of Web payments
- scenarios that the Interest Group expects to address via the capabilities
- described in this document. The use cases establish a scope of work and a
- deeper analysis of implied requirements (technical, regulatory, etc.) will
- inform future standardization work.</li>
+ <li><a href="http://www.w3.org/TR/web-payments-use-cases/">
+ Web Payments Use Cases 1.0</a> is a prioritized list of Web payments
+ scenarios that the Interest Group expects to address via the capabilities
+ described in this document. The use cases establish a scope of work and a
+ deeper analysis of implied requirements (technical, regulatory, etc.) will
+ inform future standardization work.</li>
- <li>A <a href="https://www.w3.org/Payments/IG/wiki/Roadmap">
- Roadmap</a> proposes which groups (in or outside of W3C) should take
- the lead on creating standards for these capabilities.</li>
+ <li>A <a href="https://www.w3.org/Payments/IG/wiki/Roadmap">
+ Roadmap</a> proposes which groups (in or outside of W3C) should take
+ the lead on creating standards for these capabilities.</li>
</ul>
- </section>
+</section>
+<section id="overview">
- <section id="overview">
<h1>Overview of Capabilities</h1>
<p>Capabilities are functionalities necessary to implement payments on the
@@ -174,36 +192,36 @@
<p>We organize capabilities into five groups.</p>
<ol>
- <li>
+ <li>
<strong>Security Core</strong> - These capabilities provide the security
foundation for payments.
- <div style="margin-left:2em;"><strong>Capabilities</strong>: Key Creation and
- Management, Cryptographic Signatures, Encryption</div>
+ <div class='group-capability'><strong>Capabilities</strong>: Key Creation and
+ Management, Cryptographic Signatures, Encryption</div>
<div class="issue">Right now this group has
- only security capabilities in it. We may wish to have a more general
- purpose Core set. If so, what would this core set include?</div>
- </li>
- <li>
+ only security capabilities in it. We may wish to have a more general
+ purpose Core set. If so, what would this core set include?</div>
+ </li>
+ <li>
<strong>Trust and Identity - </strong>Includes features related to establishing
trust among parties, and credentialing or authorization of parties involved
in a transaction.
- <div style="margin-left:2em;"><strong>Capabilities</strong>:
- Identity, Credentials, Rights, Authentication, Authorization, Privacy, Discovery,
- Registration, Enrollment, and Legal/Regulatory concerns.</div>
- </li>
- <li>
+ <div class='group-capability'><strong>Capabilities</strong>:
+ Identity, Credentials, Rights, Authentication, Authorization, Privacy, Discovery,
+ Registration, Enrollment, and Legal/Regulatory concerns.</div>
+ </li>
+ <li>
<strong>Accounts and Settlement - </strong>Includes capabilities related to
managing stores of value (such as Deposit Accounts) and recorded accounts
of ownership (such as Ledger entries, Deeds, etc.) used as part of the
settlement of payments or commercial exchanges. Settlement via the Web
involves access to the accounts of the participants and ledgers of the
- account providers and capabilities to manage accounts and capture and
+ <a title="account provider">account providers</a> and capabilities to manage accounts and capture and
monitor transactions in a ledger against those accounts.<br />
- <div style="margin-left:2em;"><strong>Capabilities</strong>:
- Accounts, Ledgers, and Legal/Regulatory
- concerns related to accounting and recorded ownership.</div>
- </li>
- <li>
+ <div class='group-capability'><strong>Capabilities</strong>:
+ Accounts, Ledgers, and Legal/Regulatory
+ concerns related to accounting and recorded ownership.</div>
+ </li>
+ <li>
<strong>Payments and Clearing - </strong>These are the capabilities that help
parties in a transaction establish the mechanics of how the payment will be
executed and the directly or indirectly make this happen. This involves the
@@ -212,19 +230,19 @@
costs of making the payment, time between clearing of the payment and
settlement into the payee’s account, regulatory requirements and required
authorisations.
- <div style="margin-left:2em;"><strong>Capabilities</strong>:
- Funding, Payment, Messaging, Clearing, Markets, Foreign/Currency
- Exchange, and Legal/regulatory concerns specific to Payments and
- Exchange of Value.</div>
- </li>
- <li>
+ <div class='group-capability'><strong>Capabilities</strong>:
+ Funding, Payment, Messaging, Clearing, Markets, Foreign/Currency
+ Exchange, and Legal/regulatory concerns specific to Payments and
+ Exchange of Value.</div>
+ </li>
+ <li>
<strong>Commerce - </strong>Includes capabilities related to commercial and
economic interactions.
- <div style="margin-left:2em;"><strong>Capabilities</strong>:
- Offers, Invoicing, Receipts, Loyalty, Rewards,
- Contracts, Lending, Insurance, Taxation, Legal/Regulatory concerns related
- to aspects of commercial and economic interactions.</div>
- </li>
+ <div class='group-capability'><strong>Capabilities</strong>:
+ Offers, Invoicing, Receipts, Loyalty, Rewards,
+ Contracts, Lending, Insurance, Taxation, Legal/Regulatory concerns related
+ to aspects of commercial and economic interactions.</div>
+ </li>
</ol>
<p>The Interest Group anticipates that these groups will make it easier to
@@ -235,178 +253,1032 @@
<p class="note">Some of these capabilities are expected be useful outside of payment
scenarios.</p>
- </section>
-
- <section>
- <h2>Capabilities in Context</h2>
-
- <section>
- <h3>Digital Wallets and Payment Agents</h3>
-
- <p>Although the capabilities described in this document may be used and
- composed in a variety of ways to fulfill payments use cases, the Interest Group
- anticipates that in many cases, they will be packaged in “payment agents” (or
- “digital wallets”) that act as a bridge between the merchant, the user, and the
- user’s account providers.</p>
- </section>
-
<section>
- <h3>Payment Service Providers</h3>
-
- <p>The roles illustrated here may be carried out by many different entities.
- For example, "account provider" may be carried out by financial institutions,
- mobile operators, tech companies, or cryptocurrency systems; “payee” may be an
- individual, a business, an NGO, or any entity that can accept a payment.</p>
+ <h2>Digital Wallets and Payment Agents</h2>
- <p>A payment may involve just two parties (e.g., peer-to-peer) or may be
- carried out by several collaborating parties. For instance, a payee may use a
- payment service provider which in turn uses a card network. The actions of
- these intermediaries may vary, from simply forwarding messages to fulfilling
- regulatory obligations. Additionally, these interactions may happen in
- different sequences and direction depending on the payment context.</p>
+ <p>Although the capabilities described in this document may be used and
+ composed in a variety of ways to fulfill payments use cases, the Interest Group
+ anticipates that in many cases, they will be packaged in “payment agents” (or
+ “digital wallets”) that act as a bridge between the merchant, the user, and the
+ user’s account providers.</p>
</section>
+</section>
- <section>
- <h3>Payment Interactions</h3>
+<section>
+ <h1>Capabilities in Context</h1>
<p>To simplify and harmonize the descriptions of capabilities necessary for
payments and value exchange on the Web, it is helpful to understand the parties
involved and the direction that information flows among them at various
<a href="http://www.w3.org/TR/web-payments-use-cases/#an-overview-of-the-payment-phases">
- phases</a> of a payment. We use the following diagram to help illustrate
+ phases</a> of a payment. We use the following diagram to help illustrate
roles and information flow:</p>
- <p>@@@ Figure: Payment Interaction Wheel @@@</p>
+ <p><span><img alt="InteractionsWheel.png" src="images/image00.png" title=
+ ""></span></p>
+
+ <p>Figure: Payment Interaction Wheel</p>
<p>For example, the following diagrams illustrate three interactions in a
comment payment scenario.</p>
<p><span><img alt="Request for Payment.png" src="images/image03.png" title=
- "" /></span></p>
+ "" /></span></p>
<p>Interaction 1:</p>
- <p>Payee communicates request for payment to payer and shares payment
- instructions</p>
+ <p><a>Payee</a> communicates request for payment to <a>payer</a> and shares payment instructions</p>
<p><span><img alt="Payer-PayeeService Provider.png" src="images/image02.png"
- title="" /></span></p>
+ title=""></span></p>
<p>Interaction 2:</p>
- <p>Payer uses information received from Payee and creates a new payment
- request from Payment Service Provider with stored value.</p>
+ <p><a>Payer</a> uses information received from <a>Payee</a> and creates a new payment request
+ from <a>Payment Services Provider</a> with stored value.</p>
- <p><span><img alt="PSPtoPSP.png" src="images/image04.png" title=
- "" /></span></p>
+ <p><span><img alt="PSPtoPSP.png" src="images/image04.png" title=""></span></p>
<p>Interaction 3:</p>
- <p>Payer’s Payment Service Provider sends details to complete payment to
- Payee’s</p>
+ <p><a title="payer">Payer’s</a> <a>Payment Services Provider</a> sends details to complete payment to <a
+ title='payee'>Payee's</a> <a>Payment Services Provider</a></p>
- </section>
+ <p>The roles illustrated here may be carried out by many different entities.
+ For example, "<a>account provider</a>" may be carried out by financial institutions,
+ mobile operators, tech companies, or cryptocurrency systems; “<a>payee</a>” may be an
+ individual, a business, an NGO, or any entity that can accept a payment.</p>
- </section>
+ <p>A payment may involve just two parties (e.g., peer-to-peer) or may be
+ carried out by several collaborating parties. For instance, a <a>payee</a> may use a
+ payment service provider which in turn uses a card network. The actions of
+ these intermediaries may vary, from simply forwarding messages to fulfilling
+ regulatory obligations. Additionally, these interactions may happen in
+ different sequences and direction depending on the payment context.</p>
+</section>
+<section>
- <section>
<h2>Capabilities in Detail</h2>
<section>
- <h3>Security Core</h3>
-
- <p class="issue">Describe any key concepts/relationship to other capabilities here...</p>
-
- <section>
- <h4>Key Management</h4>
-
- <p>All participants require an interchangeable mechanism for creation,
- management, storage and exchange of cryptographic keys</p>
-
- <p>Key management capabilities are required to:</p>
-
- <ol>
- <li>Securely communicate unique identifiers of payment process
- participants</li>
-
- <li>Digitally sign and authenticate information exchanged as part of the
- payments process (ex. payments, receipts, invoices, etc.)</li>
-
- <li>Provide reference key for independent elements of the payments process to
- compose/link transactions and related data across asynchronous segments of
- the payment process</li>
- </ol>
- </section>
-
- <section>
- <h4>Cryptographic Signatures</h4>
-
- <p>Information transferred should be cryptographically signed to ensure</p>
+ <h2>Core and Security</h2>
<ol>
- <li>Authenticity of the participants and ownership of value/asset being
- transferred or exchanged</li>
-
- <li>Nonrepudiation of participants intent related to information /
- communication being exchanged</li>
- </ol>
- </section>
+ <li>Key Management
+ <ol >
+ <li>All participants require an interchangeable mechanism for creation,
+ management, storage, and exchange of cryptographic keys</li>
- <section>
- <h4>Suggested Deliverables</h4>
- <ul>
- <li>Data model with a concrete syntax for expressing data in the
- architecture</li>
+ <li>Key management capabilities are required to:
- <li>Web-based key public key infrastructure data formats and protocols</li>
+ <ol>
+ <li>Securely communicate unique identifiers of payment process
+ participants</li>
- <li>New normalization mechanisms for data model serialization (if necessary,
- for digital signatures)</li>
+ <li>Digitally sign and authenticate
+ information exchanged as part of the payments process (e.g., payments,
+ receipts, invoices, etc.)</li>
- <li>Digital signature mechanism for data model</li>
- </ul>
+ <li>Provide reference key for independent elements of the payments process to
+ compose/link transactions and related data across asynchronous segments of
+ the payment process</li>
+ </ol>
+ </li>
+ </ol>
+ </li>
+
+ <li>Cryptographic Signatures</li>
+ <ol>
+ <li>Information transferred should be cryptographically signed
+ to ensure
+ <ol >
+ <li>Authenticity of the participants and ownership of value/asset being
+ transferred or exchanged</li>
+
+ <li>Nonrepudiationof participants intent
+ related to information / communication being exchanged</li>
+ </ol>
+ </li>
+ </ol>
+ </li>
+ </ol>
+
+ <section >
+ <h4>Key Concepts:</h4>
+
+ <p>(describe any key concepts/relationship to other capabilities here)</p>
+
+ </section>
+ <section
+ <h4>Suggested Deliverables:</h4>
+
+ <ul>
+ <li>Data model with a concrete syntax for expressing data in the
+ architecture</li>
+
+ <li>Web-based key public key infrastructure data formats and
+ protocols</li>
+
+ <li>New normalization mechanisms for data model serialization (if necessary,
+ for digital signatures)</li>
+
+ <li>Digital signature mechanism for data model</li>
+ </ul>
+
+ </section>
+ <section >
+ <h4>Related Specifications:</h4>
+
+ <ul>
+ <li>Data models: Graph (RDF), Document/Tree (JSON, XML)</li>
+
+ <li>Syntaxes: XML, JSON, JSON-LD</li>
+
+ <li>Normalization: XML Canonicalization, RDF Dataset Normalization</li>
+
+ <li>Signatures: Linked Data Signatures, Javascript Object Signing and
+ Encryption, XML Digital Signature</li>
+ </ul>
+ </section>
+ <section >
+
+ <h4>Responsible Working Group(s) or Standards Bodies:</h4>
+
+ <ul>
+ <li>Linked Data Signatures Working Group (W3C)</li>
+
+ <li>JOSE (IETF)</li>
+ </ul>
+ </section>
+ </section>
+ <section>
+
+ <h2>Identity and Credentials</h2>
+
+ <ol>
+ <li>Identity
+ <ol >
+ <li>Entities in the System are able to access Identity information of other
+ parties it is interacting with if specifically required by law, or if
+ consented to by owner of the information</li>
+
+ <li>Identity and credentials of an entity are able to be linked/associated
+ with Accounts and payments to satisfy requirements for <a
+ title="account provider">Account Providers</a> and
+ <a title="payment services provider">Payments Service Providers</a> to comply with KYC/AML requirements.</li>
+ </ol>
+ </li>
+ <li>Credentials
+
+ <ol >
+ <li>Entities in the system are able to be associated with 1 or more
+ credentials. A credential is a qualification, achievement, quality, or piece
+ of information about an entity’s background such as a name, home address,
+ government ID, professional license, or university degree, typically used to
+ indicate suitability. Thisallows for the exchange of suitable qualities of
+ the entity (ex. over age 21) without divulging sensitive attributes/details
+ about the entity (ex. date of birth)</li>
+
+ <li><a>Payer</a> is able to exchange standard format credentials with <a>Payee</a> to
+ validate attributes necessary to complete the payment</li>
+ </ol>
+ </li>
+
+ <li>Rights</li>
+
+ <li>Authentication
+ <ol >
+ <li>Participants are able to authenticate the validity of identifiers
+ presented by entities that they are interacting with</li>
+ </ol>
+ </li>
+ <li>Authorization</li>
+
+ <li>Privacy
+
+ <ol>
+ <li>All capabilities in this document should be standardized in a way that
+ minimizes the inclusion/exchange of personal or other sensitive metadata that
+ are part of the payments process unless specifically required by
+ law, or consented to by the owner of the
+ information.</li>
+ </ol>
+ </li>
+ <li>Discovery
+ <ol >
+ <li><a>Payer</a> is able to securely locate public identifier of <a>Payee</a> to be used as
+ part of payment process</li>
+
+ <li><a>Payee</a> is able to obtain public identifier of <a>Payer</a> participating in
+ payment process</li>
+
+ <li><a>Payer</a> identifier is persistent across devices</li>
+ </ol>
+ </li>
+ <li>Registration
+ <ol >
+ <li><a>Payer</a> and <a>Payee</a> able to register with <a>Payment Services
+ Provider</a> to obtain
+ credentials used for payments process</li>
+ </ol>
+ </li>
+ <li>
+ Enrollment
+ <ol >
+ <li>Payment services provider is able to perform the necessary steps during
+ payer/<a>payee</a> enrollment to collect required identity and credential
+ information about the payer/<a>payee</a> and associate it with an Account.</li>
+ </ol>
+ </li>
+ <li>Legal/Regulatory concerns related to Trust and Identity</li>
+ </ol>
+
+ <section >
+ <h4>Key Concepts:</h4>
+
+ <p>TO DISCUSS: Trust Agent???</p>
+
+ </section>
+ <section >
+ <h4>Suggested Deliverables:</h4>
+
+ <ul>
+ <li>Data format and vocabularies for expressing cryptographically verifiable
+ credentials</li>
+
+ <li>Protocol to issue credentials to a recipient</li>
+
+ <li>Protocol to store credentials at an arbitrary location as decided by a
+ recipient</li>
+
+ <li>Protocol to request and transmit credentials, given a recipient’s
+ authorization, to a credential consumer</li>
+
+ <li>Protocol to strongly bind an identifier to a real world identity and a
+ cryptographic token (ex: two-factor hardware device)</li>
+
+ <li>Protocol to request and deliver untraceable, short-lived, privacy
+ enhancing credentials.</li>
+
+ <li>Protocol to discover entity’s credential service</li>
+ </ul>
+
+ </section>
+ <section >
+ <h4>Related Specifications:</h4>
+
+ <ul>
+ <li>Identity Credentials (Credentials WG)</li>
+
+ <li>Credentials Vocabulary (Credentials WG)</li>
+ </ul>
+
+ </section>
+ <section >
+ <h4>Responsible Working Group(s) or Standards Bodies:</h4>
+
+ <ul>
+ <li>Credentials Working Group (W3C)</li>
+
+ <li>Authentication Working Groups (W3C)</li>
+ </ul>
+
+ </section>
+ </section>
+ <section>
+ <h2>Accounts and Settlement</h2>
<section>
- <h5>Related Specifications</h5>
-
- <ul>
- <li>Data models: Graph (RDF), Document/Tree (JSON, XML)</li>
+ <h3>Accounts</h3>
- <li>Syntaxes: XML, JSON, JSON-LD</li>
-
- <li>Normalization: XML Canonicalization, RDF Dataset Normalization</li>
+ <ol>
+ <li>
+ Manage Accounts
+ <ol >
+ <li><a title='payer'>Payers</a> and <a title='payee'>Payees</a> (account owners) require the capability to create
+ accounts at an account provider.</li>
- <li>Signatures: Linked Data Signatures, Javascript Object Signing and
- Encryption, XML Digital Signature</li>
- </ul>
+ <li><a title='payer'>Payers</a> and <a title='payee'>Payees</a> require the capability to authorise access to their
+ accounts by third parties such as <a title="payment services provider">Payment Services Providers</a>.</li>
+
+ <li><a title='payer'>Payers</a>, <a title='payee'>Payees</a> and other authorised entities require the capability of
+ checking the current balance on an account.</li>
+ </ol>
+ </li>
+ <li>Account Registration/Enrollmentat Payments Services Providers
+ <ol >
+ <li><a title='payer'>Payers</a> and <a title='payee'>Payees</a> are able to register accounts that will be used as part
+ of the payment process with <a title="payment services provider">Payment Services Providers</a> of their choice</li>
+
+ <li><a title='payer'>Payers</a> and <a title='payee'>Payees</a> are able to delegate access to specific account
+ functions to <a title="payment services provider">Payment Services Providers</a> of their choice</li>
+ </ol>
+ </li>
+ <li>Receive Funds
+
+ <ol >
+ <li><a title='payee'>Payees</a> are able to receive funds into theiraccounts<span><br></span></li>
+ </ol>
+ </li>
+ <li>Send funds
+ <ol >
+ <li><a title='payer'>Payers</a> are able to transfer funds from their accounts</li>
+ </ol>
+ </li>
+ </ol>
+
+ <section >
+ <h4>Key Concepts:</h4>
+
+ <p>(describe any key concepts/relationship to other capabilities here)</p>
+
+ </section>
+ <section >
+ <h4>Suggested Deliverables:</h4>
+
+ <p>(include suggested/needed deliverables here)</p>
+
+ </section>
+ <section >
+ <h4>Responsible Working Group(s) or Standards Bodies:</h4>
+
+ </section>
+ <section >
+ <h4>Related Specifications:</h4>
+
+ <p>(Insert relevant related existing or in progress standards for capability
+ segment)</p>
+
+ </section>
</section>
+ <section>
+ <h3>Ledgers</h3>
+
+ <ol>
+ <li>Discovery of Ledger services
+ <ol >
+ <li>Participants require the capability to locate the endpoints at which
+ ledger services are offered by an account provider</li>
+
+ <li>Participants require the capability to discover which services are
+ available against a ledger at an account provider</li>
+ </ol>
+ </li>
+ <li>Capture transactions in ledger
+ <ol >
+ <li>Participants in the settlement process require the capability to
+ capture a transaction in a ledger transferring value from one account to
+ another on the same ledger.</li>
+ </ol>
+ </li>
+ <li>Monitor a ledger
+ <ol >
+ <li><span>Participants in the settlement process require the ability to
+ monitor a ledger for new transactions that impact a specific
+ account.<br></span></li>
+ </ol>
+ </li>
+
+ <li>Reserve funds in an account
+ <ol >
+ <li>To execute settlement across ledgers a counterparty may require the
+ ability to request that an account provider temporarily reserve funds in an
+ account while settlement is finalised on the other ledger(s).</li>
+ </ol>
+ </li>
+ </ol>
+
+ <section >
+ <h4>Key Concepts:</h4>
+
+ <p>TODO</p>
+
+ </section>
+ <section >
+ <h4>Suggested Deliverables:</h4>
+
+ <ul>
+ <li>Standardised data model for accounts and ledgers</li>
+
+ <li>Standardised interface for account management</li>
+
+ <li>Standardised interface for ledger services</li>
+
+ <li>Protocol for discovering ledger services</li>
+
+ <li>Protocol for executing settlement between participants on the open
+ Web</li>
+ </ul>
+
+ </section>
+ <section >
+ <h4>Related Specifications:</h4>
+
+ <ul>
+ <li>ISO20022 / X9 specs</li>
+
+ <li>Web Commerce Formats and Protocols (Web Payments WG)</li>
+
+ <li>Web Payments Vocabulary (Web Payments WG)</li>
+ </ul>
+
+ </section>
+ <section >
+ <h2>Responsible Working Group(s) or Standards Bodies:</h2>
+
+ <ul>
+ <li>Web Settlement Working Group (W3C)</li>
+ </ul>
+
+ </section>
+ </section>
+ </section>
+ <section>
+ <h2>Payments and Exchange</h2>
+
+ <ol>
+ <li>Payment Instrument Discovery and Selection
+ <ol >
+ <li><a>Payer</a> and <a>payee</a> are able to discover payment instruments/schemes which
+ they have in common and may be used in the payment process</li>
+
+ <li><a>Payer</a> is able to establish the different costs of making the payment
+ using the various combinations of <a>payer</a> and <a>payee</a> instruments and schemes
+ (payment methods)</li>
+
+ <li><a>Payer</a> is able to select payment instrument for use in the payment
+ process</li>
+
+ <li><a>Payee</a> is able to communicate requirements(or preference) to <a>payer</a> as to
+ whether a specific instrument is accepted and the payment terms for using
+ that instrument</li>
+ </ol>
+
+ <li>Payment Initiation
+ <ol >
+ <li><a>Payer</a> is able to initiate a payment using selected payment
+ instrument</li>
+
+ <li><a>Payer</a> is able to identify <a>Payee</a> via:
+
+ <ol>
+ <li>Information received via Invoice</li>
+
+ <li>Individual contact information</li>
+
+ <li>Information from past payees</li>
+ </ol>
+ </li>
+ <li><a>Payee</a> is able to initiate a request for payment to payee’s designated
+ account provider</li>
+
+ <li>Account provider is able to initiate a payment on behalf of the Payee
+ based on Payee’s requested schedule and frequency (recurring
+ payment)</li>
+ </ol>
+ </li>
+ <li>Payment Authorization
+ <ol >
+ <li>Payment service provider or <a>payee</a> is able to get authorization from payer
+ to execute payment either in real-time or using a preloaded authorization
+ mechanism</li>
+
+ <li>Payment service provider is able to demonstrate to <a>payer</a> account provider
+ that payment is authorised</li>
+ </ol>
+ </li>
+
+ <li>Payment Execution
+ <ol >
+ <li>Payment orchestrator is able to evaluate that all requirements have been
+ met to execute the payment including authorization(s) and compliance checks
+ as required.</li>
+
+ <li>Payment orchestrator is able to instruct all participants to execute the
+ payment and perform any roll-back steps that may be required in case of a
+ failure by any participant to complete the payment.</li>
+ </ol>
+ </li>
+
+ <li>Payment Acknowledgement
+ <ol >
+ <li><a>Payee</a> is able to receive confirmation that payment has been successfully
+ completed</li>
+
+ <li><a>Payer</a> is able to receive verification that payment has been successfully
+ received</li>
+
+ <li>Account provider is able to receive confirmation that payment is
+ complete</li>
+ </ol>
+ </li>
+ <li>Regulatory/Legal Compliance
+ <ol >
+ <li><a>Regulator</a> is able to access/view required payment, payer, and payee
+ details for payments that take place within their jurisdiction</li>
+
+ <li><a>Regulator</a> is able to intervene in payments meeting or exceeding certain
+ thresholds or criteria in order to comply with jurisdictional laws and
+ requirements</li>
+ </ol>
+ </li>
+ <li>Payment Settlement and Clearing
+ <ol >
+ <li>Payment service provider is able to provide <a>payer</a> with
+ quotesto settle <a>payee</a> via all <a>payee</a>
+ supported payment schemes</li>
+ </ol>
+ </li>
+ </ol>
+
+ <section >
+ <h4>Key Concepts:</h4>
+
+ <p>TODO: Payment Agent</p>
+
+ </section>
+ <section >
+ <h4>Suggested Deliverables:</h4>
+
+ <ul>
+ <li>Protocol for discovering all payment instruments available to a
+ payer.</li>
+
+ <li>User Agent API and REST API for initiating a payment and protocol for
+ routing an invoice to a payment service</li>
+
+ <li>Protocol for authorizing payment via regulatory API</li>
+
+ <li>User Agent API and REST API for completing a payment and protocol for
+ routing payment acknowledgement to payer</li>
+ </ul>
+
+ </section>
+ <section >
+ <h4>Related Specifications:</h4>
+
+ <ul>
+ <li>ISO20022 / X9 specs</li>
+
+ <li>Web Commerce Formats and Protocols (Web Payments WG)</li>
+
+ <li>Web Commerce User Agent API (Web Payments WG)</li>
+
+ <li>Web Payments Vocabulary (Web Payments WG)</li>
+ </ul>
+
+ </section>
+ <section >
+ <h4>Responsible Working Group(s) or Standards Bodies:</h4>
+
+ <ul>
+ <li>Web Payments Working Group (W3C)</li>
+ </ul>
+ </section>
+
+ </section>
+ <section>
+ <h2>Commerce</h2>
<section>
- <h5>Responsible Working Group(s) or Standards Bodies</h5>
-
- <ul>
- <li>Linked Data Signatures Working Group (W3C)</li>
-
- <li>JOSE (IETF)</li>
- </ul>
- </section>
- </section>
- </section>
- </section>
+ <h3>Offers</h3>
- <section class="appendix">
- <h2>Acknowledgements</h2>
+ <ol>
+ <li>Generate Offer
+ <ol >
+ <li><a>Payee</a> is able to generate a standard format offer which provides
+ information on specific products or services being offered, and additional
+ information on payment instruments accepted, or terms of the offer.</li>
- <p>
-The editors are thankful to the following contributions from ...
-(in alphabetical order):
- </p>
- <p>
-List of contributors/reviewers.
- </p>
+ <li><a>Payer</a> is able to generate a standard format offer which can be accepted
+ or declined by the payee.</li>
- </section>
+ <li><a>Payee</a> is able to create scheduled/recurring offers</li>
+ </ol>
+ </li>
+ <li>Receive Offer
+ <ol >
+ <li><a>Payer</a> is able to receive offer in machine readable format and use it to
+ initiate payment request</li>
- </body>
+ <li>Payeeis able to receive offer in
+ machine readable format and use it to create invoice</li>
+ </ol>
+ </li>
+ </ol>
+ </section>
+ <section>
+ <h3>Discounts</h3>
+
+ <ol>
+ <li>
+ <a>Payee</a> is able toable tocommunicate discounts which may be applied to
+ Offers
+ </li>
+
+ <li>
+ <a>Payee</a> is able to receive and apply discount to offer
+ </li>
+
+ <li>
+ <a>Payee</a> is able to apply standard loyalty identifiers to offers
+ </li>
+ </ol>
+ </section>
+ <section>
+ <h3>Coupons</h3>
+
+ <ol>
+ <li><a>Payer</a> is able to apply coupons to offers</li>
+
+ <li><a>Payee</a> is able to issue general use coupons</li>
+
+ <li><a>Payee</a> is able to issue coupons specific to <a>payer</a> identifier</li>
+ </ol>
+
+ </section>
+ <section >
+ <h4>Key Concepts:</h4>
+
+ </section>
+ <section >
+ <h4>Suggested Deliverables:</h4>
+
+ <ul>
+ <li>Data format and vocabularies for expressing offers and coupons</li>
+
+ <li>User Agent API for using an offer to initiate a payment</li>
+ </ul>
+
+ </section>
+ <section >
+ <h4>Related Specifications:</h4>
+
+ <ul>
+ <li>Web Commerce Formats and Protocols (Web Payments WG)</li>
+
+ <li>Web Commerce User Agent API (Web Payments WG)</li>
+
+ <li>Web Payments Vocabulary (Web Payments WG)</li>
+ </ul>
+
+ </section>
+ <section >
+ <h4>Responsible Working Group(s) or Standards Bodies:</h4>
+
+ <ul>
+ <li>Web Payments Working Group (W3C)</li>
+ </ul>
+ </section>
+
+ </section>
+ <section>
+ <h3>Invoices</h3>
+
+ <ol>
+ <li>Invoice creation
+ <ol >
+ <li><a>Payee</a> is able to generate a standard formatted invoice
+ and communicate to <a>Payer</a> as part of the negotiation
+ of payment terms</li>
+ </ol>
+ </li>
+ <li>Invoice receipt
+ <ol >
+ <li><a>Payer</a> is able to receive standard formatted invoice</li>
+ </ol>
+ </li>
+ <li>Invoice data
+ <ol >
+ <li>Invoice provides <a>payer</a> with Payment instructions for making payment to
+ Payee</li>
+
+ <li>Invoice identifier is returned to <a>Payee</a> via payment process to verify
+ payment is complete</li>
+ </ol>
+ </li>
+ </ol>
+
+ <section >
+ <h4>Key Concepts:</h4>
+
+ </section>
+ <section >
+ <h4>Suggested Deliverables:</h4>
+
+ <ul>
+ <li>Data format and vocabulary for expressing an invoice</li>
+
+ <li>User Agent API for initiating a payment and protocol for routing an
+ invoice to a payment service</li>
+ </ul>
+
+ </section>
+ <section >
+ <h4>Related Specifications:</h4>
+
+ <ul>
+ <li>Web Commerce Formats and Protocols (Web Payments WG)</li>
+
+ <li>Web Commerce User Agent API (Web Payments WG)</li>
+
+ <li>Web Payments Vocabulary (Web Payments WG)</li>
+ </ul>
+
+ </section>
+ <section >
+ <h3>Responsible Working Group(s) or Standards Bodies:</h3>
+
+ <ul>
+ <li>Web Payments Working Group (W3C)</li>
+ </ul>
+ </section>
+
+ </section>
+ <section>
+ <h3>Receipts</h3>
+
+ <ol>
+ <li>Create Receipt
+ <ol >
+ <li><a>Payee</a> is able to create receipt and communicate receipt to Payer
+ following completion of payment</li>
+ </ol>
+ </li>
+ <li>Receive Receipt
+ <ol >
+ <li><a>Payer</a> is able to receive receipt and persist for future use
+ (ex. returns, reimbursement, etc)</li>
+ </ol>
+ </li>
+ </ol>
+
+ <section >
+ <h4>Key Concepts:</h4>
+
+ </section>
+ <section >
+ <h4>Suggested Deliverables:</h4>
+
+ <ul>
+ <li>Data format and vocabulary for expressing a receipt</li>
+
+ <li>Protocol for routing an receipt to a payer’s receipt storage service</li>
+ </ul>
+
+ </section>
+ <section >
+ <h4>Related Specifications:</h4>
+
+ <ul>
+ <li>Web Commerce Formats and Protocols (Web Payments WG)</li>
+
+ <li>Web Payments Vocabulary (Web Payments WG)</li>
+ </ul>
+
+ </section>
+ <section >
+ <h2>Responsible Working Group(s) or Standards Bodies:</h2>
+
+ <ul>
+ <li>Web Payments Working Group (W3C)</li>
+ </ul>
+ </section>
+
+ </section>
+ <section>
+ <h3>Loyalty</h3>
+
+ <ol>
+ <li><a>Payer</a> is able to register with Payee’s loyalty program by requesting
+ loyalty identifier from Payee.</li>
+
+ <li><a>Payee</a> can “opt-in” to loyalty program by providing program specific
+ public identifier</li>
+ </ol>
+
+ <section >
+ <h4>Key Concepts:</h4>
+
+ </section>
+ <section >
+ <h4>Suggested Deliverables:</h4>
+
+ <ul>
+ <li>Same as “Trust” deliverables</li>
+ </ul>
+
+ </section>
+ <section >
+ <h4>Related Specifications:</h4>
+
+ <ul>
+ <li>
+ <h4>Identity Credentials (Credentials WG)</h4>
+ </li>
+
+ <li>Credentials Vocabulary (Credentials WG)</li>
+
+ <li>Web Commerce Vocabulary (Credentials WG)</li>
+ </ul>
+
+ </section>
+ <section >
+ <h4>Responsible Working Group(s) or Standards Bodies:</h4>
+
+ <ul>
+ <li>Credentials Working Group (W3C)</li>
+ </ul>
+ </section>
+ </section>
+</section>
+<section>
+ <h1>Guiding principles and key considerations</h1>
+
+ <p>Due to the breadth of the capabilities that will require standardization, it
+ is important to outline certain guiding principles which are expected to be
+ incorporated across each of the defined capabilities in this document as they
+ are undertaken by standards teams. The principles include:</p>
+
+ <section>
+ <h2>Extensibility</h2>
+
+ <ul>
+ <li>Because the Web payments architecture will accommodate a great variety of
+ payment schemes (existing and new), we expect to future standards to support
+ interoperability on a minimal set of features and also support
+ scheme-specific extensions. Therefore, data formats must be easily
+ extensible.</li>
+ </ul>
+
+ </section>
+ <section>
+ <h2>Composability</h2>
+
+ <ul>
+ <li>Different parties will want to add information to messages that are
+ forwarded.</li>
+ </ul>
+
+ </section>
+ <section>
+ <h2>Identifiers</h2>
+
+ <ul>
+ <li>Payment schemes define identifier syntax and semantics (e.g., primary
+ account numbers (PANs) for credit cards, or bitcoin account identifiers). We
+ expect to support scheme-specific identifiers. But where global identifiers
+ are required and are not scheme specific, we expect to use URIs.</li>
+
+ <li>Due to the nature of payments and the fundamental challenge of preventing
+ “double-spending” as part of the payments process, it is important that every
+ actor/system be uniquely identifiable to other actors and systems
+ participating in the payments process. While each actor must be identifiable,
+ a number of use cases that need to be addressed include low value or
+ less-sensitive payments which do not require the knowledge of a participant’s
+ identity as a part of the transaction. Because of this, it is important to
+ de-couple the identification (non-identity based unique ID) of each
+ participant in the Architecture from the Identity data (sensitive/private
+ data about the participant) which describes information about a participant
+ taking part in the system</li>
+ </ul>
+
+ </section>
+ <section>
+ <h2>Security</h2>
+
+ <ul>
+ <li>Messages must not be altered in transit, but may be included as part of
+ encapsulating messages created by intermediaries.</li>
+
+ <li>It must be possible to provide read-only access to transaction
+ information to third parties (with user consent).</li>
+
+ <li>Signatures must be non-forgeable.</li>
+ </ul>
+
+ </section>
+ <section>
+ <h2>Identity, Privacy, and Consumer Protection</h2>
+
+ <ul>
+ <li>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.</li>
+
+ <li>At the same time, any source of information that can lead to the
+ unintended disclosure or leakage of a user’s identity (or purchasing habits)
+ is likely protected in a jurisdiction somewhere in the world by a
+ legal/regulatory entity having responsibility for its citizens.</li>
+
+ <li>For discussion: the role of per-transaction pseudo-anonymous identity
+ mechanisms for some use cases. These mechanisms would make it much more
+ difficult for an unauthorized party to track a user’s purchasing habits from
+ 1 transaction to another transaction. This will also eliminate the loss of
+ that identity from affecting other services that user is enrolled in.</li>
+
+ <li>Regulations in several jurisdictions require the consumer to be notified
+ every time their personal information/credentials are accessed. To discuss:
+ cryptography requiring a user’s input/knowledge to open that
+ information.</li>
+
+ <li>Some purchases in combination (e.g., products accommodating prenatal care
+ needs) will leak sensitive information. To discuss: dynamic key construction
+ can be applied to each line item in a receipt to help prevent unauthorized
+ data mining of individuals, legal & regulatory snooping. Even if the
+ protected information is stolen or accidentally forwarded to unauthorized
+ parties they will not have the correct tokenized inputs to recreate the
+ dynamic keys to unlock access to the protected information.</li>
+
+ <li>Role based access controls when applied to dynamic key construction for
+ each individual credential or large sets of data will help facilitate
+ interoperable access without needless duplication and encryption of
+ information for each authorized party. For discussion: Use dynamic keys to
+ protect a static key where various dynamic keys can be used to unlock the
+ static key that protects the sensitive content.</li>
+
+ <li>The system should support privacy by requiring only the minimal amount of
+ information necessary to carry out a transaction. Additional considerations
+ (e.g., marketing initiatives with user consent, or legal requirements) may
+ lead to additional information exchange beyond the minimum required.</li>
+
+ <li>Payment account providers must take measures to ensure that account
+ identifiers are not, on their own, sufficient to identify the account
+ holder.</li>
+
+ <li>Another suggestion: “Don’t require personal authentication, but make sure
+ it can be done properly”</li>
+ </ul>
+
+ </section>
+ <section>
+ <h2>Legal and Regulatory</h2>
+
+ <ul>
+ <li>In some jurisdictions legal or regulatory entities may need to be granted
+ “time-limited access” to a transaction to view specific credentials and
+ purchased items of the user. The system should limit what is viewed to the
+ minimum necessary. Examples: Government subsidies such as food stamps,
+ controlled substances. In these cases those particular line items in the
+ receipt may be required to be viewable via individuals or computers charged
+ with the responsibility to prevent abuse of those programs (e.g.,
+ unauthorized reselling). There may also be a requirement to view identities
+ or credentials.</li>
+
+ <li>For certain classes of payments, such as high value or international, it
+ must be possible to provide role-based access controls to pierce a
+ pseudo-anonymous identity mechanism so the transaction can be counter signed
+ by a legal, regulatory, or KYC/AML system yet safeguard against disclosing
+ unnecessary information. It must be infeasible for the piercing of this
+ mechanisms to leak enough information for those authorities to forge user
+ information.</li>
+ </ul>
+ </section>
+ <section>
+
+ <h2>Accessibility</h2>
+
+ <ul>
+ <li>Web payment schemas, interfaces, data and the architectures that enable
+ them need to be made accessible for people with disabilities. Web APIs and
+ applications must be developed and implemented with accessibility-in-mind and
+ allow for accessibility features. If not, developers, payees, providers and
+ retailers may be in violation of disability laws.</li>
+ </ul>
+
+ </section>
+ <section>
+ <h2>Discovery and instrument selection</h2>
+
+ <ul>
+ <li>Default expectation for privacy reasons is that <a>payee</a> will present
+ accepted schemes and computation of intersection (or other compution) will
+ happen on the <a>payer</a> side.</li>
+
+ <li>There are other scenarios to discuss that would presumably involve user
+ consent (e.g., computation done on <a>payee</a> side, or by a third party
+ platform).</li>
+
+ <li>Quoting Adrian Hope-Bailie idea: “The algorithm MUST not prevent any
+ scheme from being available as a candidate for registration AND for this
+ matching/discovery process. i.e. It shouldn't be possible for the browser (or
+ any other component that executes this discovery process) to exclude schemes
+ or instruments on the basis of anything but technical incompatibility.”</li>
+
+ <li>The standard should not hard-code a selection process. Regulatory and
+ cultural preferences may vary (e.g., the <span><a href=
+ "https://www.google.com/url?q=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fpublic-webpayments-ig%2F2015Jun%2F0114.html&sa=D&sntz=1&usg=AFQjCNHM5Sh5w_M5mfM_y-jTtvIgiTNlww">
+ Alibaba escrow use case</a></span>).</li>
+ </ul>
+ </section>
+</section>
+<section class='appendix informative' id='glossary'>
+ <h1>Glossary</h1>
+ <div data-include="../common/terms.html" data-oninclude="restrictReferences"></div>
+
+ <p class='note'>@@The Web Payments Glossary@@ defines additional terms and relates
+ this group’s definitions to those from related standards.</p>
+
+</section>
+</body>
</html>
-
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/latest/charters/payments-wg-charter.html Sun Jul 12 07:14:14 2015 -0700
@@ -0,0 +1,545 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
+
+<head>
+ <meta http-equiv="content-type" content="text/html; charset=utf-8"/>
+ <title>Web Payments Working Group</title>
+ <link rel="stylesheet" href="//www.w3.org/2005/10/w3cdoc.css" type="text/css" media="screen"/>
+ <link rel="stylesheet" type="text/css" href="//www.w3.org/Guide/pubrules-style.css"/>
+ <link rel="stylesheet" type="text/css" href="//www.w3.org/2006/02/charter-style.css"/>
+</head>
+
+<body>
+<div id="template">
+ <ul id="navbar" style="font-size:
+ small">
+ <li>
+ <a href="#goals">Goals</a>
+ </li>
+ <li>
+ <a href="#scope">Scope</a>
+ </li>
+ <li>
+ <a href="#deliverables">Deliverables</a>
+ </li>
+ <li>
+ <a href="#coordination">Dependencies and Liaisons</a>
+ </li>
+ <li>
+ <a href="#participation">Participation</a>
+ </li>
+ <li>
+ <a href="#communication">Communication</a>
+ </li>
+ <li>
+ <a href="#decisions">Decision Policy</a>
+ </li>
+ <li>
+ <a href="#patentpolicy">Patent Policy</a>
+ </li>
+ <li>
+ <a href="#about">About this Charter</a>
+ </li>
+ </ul>
+ <p>
+ <a href="http://www.w3.org/" shape="rect"><img alt="W3C" height="48" src="//www.w3.org/Icons/w3c_home"
+ width="72"/></a>
+ <a class="domainlogo" href="/TandS/"><img src="http://www.w3.org/Icons/tands"
+ alt="Technology and Society Domain"/></a>
+ </p>
+
+ <h1 id="title">[DRAFT] Web Payments Working Group Charter</h1>
+
+ <p class="mission">The mission of the Web Payments Working Group is to make payments easier and more secure on the
+ Web, through incremental improvements to Web infrastructure that support and facilitate payments.
+
+ <p><strong>Note</strong>: For more information about roles involved in this payment flow (payer, payee, etc.),
+ please see the <a href="http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#terminology">Web Payments
+ Interest Group's glossary</a>.</p>
+
+ <div class="noprint">
+ <p class="join">@@Join the Web Payments Working Group.</p>
+ </div>
+ <table class="summary-table">
+ <tr id="Duration">
+ <th rowspan="1" colspan="1">End date</th>
+ <td rowspan="1" colspan="1">31 December 2017</td>
+ </tr>
+ <tr>
+ <th rowspan="1" colspan="1">Confidentiality</th>
+ <td rowspan="1" colspan="1">Proceedings are
+ <a href="http://www.w3.org/2014/Process-20140801/#confidentiality-levels">
+ public
+ </a>
+ </td>
+ </tr>
+ <tr>
+ <th rowspan="1" colspan="1">Initial Chairs</th>
+ <td rowspan="1" colspan="1">
+ <span class="toadd">CHAIR INFO</span>
+ </td>
+ </tr>
+ <tr>
+ <th rowspan="1" colspan="1">Initial Team Contacts
+ <br/>(FTE %: 45%)
+ </th>
+ <td rowspan="1" colspan="1">Doug Schepers</td>
+ </tr>
+ <tr>
+ <th rowspan="1" colspan="1">Usual Meeting Schedule</th>
+ <td rowspan="1" colspan="1">Teleconferences: Weekly
+ <br/>Face-to-face: 2-3 per year
+ </td>
+ </tr>
+ </table>
+ <h2 id="goals">Goals</h2>
+
+ <p>Under this initial charter, the Working Group defines standards that ease integration of the payments ecosystem
+ into the Web for a payment initiated by a Web application. Where practical the standards will be usable by
+ native applications/apps.</p>
+
+ <p>We anticipate the following benefits of this work:</p>
+ <ul>
+ <li>Streamlined <a href="#payment_flow">payment flow</a>, which is expected to reduce the percentage of
+ transactions abandoned prior to completion ("shopping cart abandonment").
+ </li>
+ <li>Increased customer satisfaction due to additional payment options available to users.</li>
+ <li>Improved security and privacy by providing information only to those parties that require it to complete a
+ transaction.
+ </li>
+ <li>Easier integration of new payment schemes by payment service providers, increasing merchant acceptance.</li>
+ <li>Increased scope for <a href="#wallets">digital wallet</a> innovation by banks, retailers, mobile operators,
+ card networks, and other wallet providers.
+ </li>
+ <li>Added value through machine-readable digital payment requests and payment responses.</li>
+ </ul>
+ <p>The W3C is also planning other Working Groups to develop standards, on topics such as security, that will
+ facilitate payments on the Web.</p>
+
+ <p>
+ <strong>Note</strong>: The Web Payments Interest Group expects to provide more detailed technical input to
+ relevant W3C Working Groups including this one, based on a detailed analysis of the relevant <a
+ href="http://www.w3.org/TR/web-payments-use-cases/#an-overview-of-the-payment-phases">Web Payments Use
+ Cases</a>.</p>
+
+ <div class="scope">
+ <h2 id="scope">Scope</h2>
+
+ <p>A payment, on the Web today, ordinarily starts on a payment page where the <strong>payer</strong> must
+ manually select a payment scheme, manually select their own <strong>payment instrument</strong> for that
+ payment scheme, manually capture the details of that instrument into the page (along with any other
+ essential data such as a shipping address) and then submit this data back to the <strong>payee.</strong> The
+ payment data briefly passes through the Web (from the payer's user agent to the payee's Website) on it's way
+ to a payment processor. At that point, much of the communication to complete a payment takes place among
+ banks, card networks, and other parties in the payment ecosystem typically outside of the Web.</p>
+
+ <p>In an effort to improve upon this process, various parties have innovated ways to make the payment flow
+ easier, for example by caching payment instrument information in browsers, registering users on eCommerce
+ websites to facilitate re-use of customer data and/or payment credentials, and even developing new payment
+ schemes. Unfortunately, these efforts all suffer from a lack of standardization of the high level flow of a
+ Web payment, of the interfaces between the various parties, the user agent and the Web application, or of
+ the messages exchanged between these parties over the Web.</p>
+
+ <p>This group will create open Web standards for the interfaces in and out of the Web context to provide
+ interoperability between payer and payee systems (for existing and future payment schemes), and encourage
+ greater automation of the steps in a typical payment. The interfaces between the payment schemes and the Web
+ are via the user agent and the Web application, therefore the scope of the initial charter is focused on the
+ interactions between these two components and the external actors that will interface directly with
+ them.</p>
+
+ <p>The group will focus primarily on standardisation of a set of messages and a message flow for the initiation.
+ confirmation and completion of a payment. By focusing on the message format and flow the group leaves open
+ the standardisation of the delivery mechanism for these messages as this will vary depending on the use case
+ and technology stack. The group will aim to standardise the delivery mechanism for common scenarios such as
+ WebIDL APIs for the use cases where the messages are proxied between payer and payee via a Web browser or
+ Web APIs where the messages are exchanged directly over the Web between two online entities in the classic
+ REST pattern.</p>
+
+ <p><strong>Note:</strong> W3C expects to deal with a wider variety of of eCommerce scenarios over time,
+ including digital receipts; loyalty programs and coupons; peer-to-peer payments; and harmonization of user
+ experience in-browser, in-app, and in-store. For more information, see the <a
+ href="http://www.w3.org/TR/web-payments-use-cases/">Payments Use Cases</a> published by the W3C Web
+ Payments Interest Group.</p>
+
+ <h3 id="payment_flow">Payment Flow</h3>
+
+ <p>The scope of work supports the following elements of a basic purchase triggered by user interaction with a
+ Web application initiating a new payment. These standards define a high-level message flow for a payment
+ from payer to payee either in the form of a credit push (payer initiated) or a debit pull (payee initiated)
+ payment, and can be used to facilitate a payment from any payment scheme.</p>
+ <dl>
+ <dt>Pre-Payment</dt>
+ <dd>
+ <ul>
+ <li>
+ <strong>Registration</strong>, by the payer with their <a href="#wallets">wallet</a>, of any
+ conforming <strong>payment instrument</strong> they wish to use on the Web (e.g. a credit card,
+ electronic cash, cryptocurrency, etc).
+ </li>
+ </ul>
+ </dd>
+ <dt>Negotiation of Terms</dt>
+ <dd>
+ <ul>
+ <li>
+ <strong>Payment Initiation Request</strong>, by the payee to the payer providing the terms of
+ the payment including elements such as the accepted payment schemes, price, currency,
+ recurrence, transaction type (purchase, refund etc.) and requests for any additional data that
+ is required from the payee.
+ </li>
+ </ul>
+ </dd>
+ <dt>Negotiation of Payment Instruments</dt>
+ <dd>
+ <ul>
+ <li>
+ <strong>Discovery</strong>, by the payer, of their available payment instruments that can be
+ used to make the payment. This is done by matching those registered by the payer with those
+ supported by the payee (as defined in the Payment Initiation Request), while keeping information
+ local to
+ the payer.
+ </li>
+ <li>
+ <strong>Selection of a payment instrument</strong> by the payer, confirmation of the terms, and
+ sending of any requested data back to the payee for validation.
+ </li>
+ </ul>
+ </dd>
+ <dt>Payment Processing and Completion</dt>
+ <dd>
+ <ul>
+ <li>Execution of the payment by either payer or payee.</li>
+ <li>Delivery of a <strong>Payment Completion</strong> generated by the entity that executed the
+ payment. This may contain a <strong>Proof of Payment</strong> if supported by the payment
+ scheme.
+ </li>
+ </ul>
+ </dd>
+ </dl>
+ <p>The group will also address exceptions that may occur during these steps, including payment authorization
+ failure.</p>
+
+ <h3 id="security">Security and Privacy Considerations</h3>
+
+ <p>Security is obviously critical in payments and while the initial work of the group will leave much of the
+ required security and authentication to the payment schemes it is important to ensure that any additions to
+ the Web platform are secure and tamper-proof. The ability to manipulate any message in a payment flow has
+ potentially massive financial impact therefore message integrity and verification of all message originators
+ should be a key consideration for any work done by the group.</p>
+
+ <p>Protection of the privacy of all participants in a payment is essential to maintaining the trust that payment
+ systems are dependent upon to function. Any payment process defined by the group should not disclose private
+ details of the participants identity or other sensitive information without their explicit consent and the
+ design of any public facing API should ensure it is not possible for such data to be leaked through
+ exploitation of the API.</p>
+
+ <h3 id="out_of_scope">Out of Scope</h3>
+
+ <p>This group will not define a new payment scheme, or redefine that which is already addressed today by payment
+ schemes. The standards from this group will provide a channel for protocols and messages defined by payment
+ schemes, or that can be used across payment schemes.</p>
+ </div>
+ <div>
+ <h2 id="wallets">Wallets</h2>
+
+ <p>The standards from this group may be implemented in a variety of ways, including as stand-alone applications,
+ in the cloud, or within user agents such as browsers. Some of the functionality provided by the standards
+ from this group can be found in various Web services today, as well as in digital wallets. Because the
+ "digital wallet" concept can be useful as a shorthand, but means different things to different audiences,
+ this charter includes a definition to clarify the intent of this group.</p>
+
+ <p>In this charter we define a <strong>wallet</strong> as a software service, providing similar functions in the
+ digital world to those provided by a physical wallet, namely:</p>
+ <ul>
+ <li>It holds payment instruments registered by the wallet owner.</li>
+ <li>It supports certain payment schemes and enables the payer to use registered payment instruments to
+ execute a payment in accordance with that scheme.
+ </li>
+ <li>It may hold one or more balances of some digital asset that can be used to make payments.</li>
+ </ul>
+ <p>This definition of wallet may expand in the future to include other items people find in physical wallets
+ such as digital receipts, coupons, and identification. What the group defines today as a wallet service may
+ in future offer new functionality that even makes the wallet metaphor entirely inappropriate. Therefor the
+ label <em>"wallet"</em>, while appropriate today, should not imply any limitation on the functionality that
+ this service may be expected to provide under future versions of any standards produced by the group.</p>
+
+ <p>The group intends to create a standard interface from the Web to a user's wallet so that a user with any
+ conforming wallet can seamlessly make payments with any conforming Web application running in a conforming
+ user agent. The group may define APIs that will also be used outside of a browser context (such as between
+ Web services, or from within a native application, where the browser is not the proxy between wallet and
+ payee application).</p>
+
+ <p>The group may also consider the use case where an aggregation service stands in place of a wallet service
+ and offers the user a wider choice of payment solutions by combining the functionality of multiple wallet
+ services or performing a complex payment instrument discovery process to collect the set of payment
+ instruments the user has available.</p>
+
+ <p>
+ <strong>Note:</strong> The Working Group anticipates a rich ecosystem of eCommerce and payment functionality,
+ including loyalty schemes and coupons, digital receipts, location services, marketing additions, and so on.
+ Some of this functionality may be provided by a digital wallet, or by other aggregating services available
+ to the user. This charter does not seek to preclude those additional services, and in the future W3C may
+ look for standardization opportunities to increase interoperability of such services.</p>
+ </div>
+ <div>
+ <h2 id="deliverables">Deliverables</h2>
+
+ <h3 id="rec_track">Recommendation-track deliverables</h3>
+ <h4 id="Web_Payment_Vocabularies_1.0">Web Payment Vocabularies 1.0</h4>
+
+ <p>The Working Group will develop machine-readable vocabularies that enable the following:</p>
+ <ul>
+ <li>
+ <strong>Payment Scheme Description</strong>: this vocabulary is used by payees to represent accepted
+ schemes, and by payers to represent their available payment schemes and instruments.
+ </li>
+ <li>
+ <strong>Payment Term Description</strong>: used to define the terms requested by the payee in the
+ payment initiation request and the terms accepted by the payer in the payment initiation response. It
+ includes information such as amount, currency, payee account information, recurrence, transaction
+ reference and any scheme specific data that is required.
+ </li>
+ <li>
+ <strong>Proof of Payment</strong>: a verifiable payment authorization from the account provider to the
+ payee. The proof must include information about the payment request (a transaction reference or similar)
+ and the payer's payment instrument.
+ </li>
+ </ul>
+ <h4 id="Web_Payments_1.0">Web Payments 1.0</h4>
+
+ <p>The Working Group will define standard request and response messages for:</p>
+ <ul>
+ <li>
+ <strong>Registration of a Payment Instrument</strong>: A payer wallet service processes a registration
+ request and, with user mediation as required, adds a new payment instrument to the user's wallet.
+ </li>
+ <li>
+ <strong>Web Payment Initiation</strong>: The payee passes a payment request to a payer wallet service
+ which returns the details of the payment initiation response. The payer should be presented with a set
+ of payment instruments for selection and prompted to provide any other required data to pass back to the
+ payee.
+ </li>
+ <li>
+ <strong>Web Payment Completion</strong>: The payee passes a payment completion request to a payer wallet
+ service which returns the details of the payment completion response. If this was a payer-initiated
+ payment, this is the trigger for the wallet service to execute the payment otherwise this is a message
+ advising of the result of a payee initiated payment.
+ </li>
+ </ul>
+ <p>The Working group will standardise the delivery mechanism for these messages in at least the following
+ scenarios:</p>
+ <ul>
+ <li><strong><a href="http://www.w3.org/TR/WebIDL/">WebIDL</a> API</strong>: Where the payment messages may
+ be proxied between a Web application and the payer's wallet service via a WebIDL API hosted by
+ the User Agent.
+ </li>
+ <li><strong>Web services API</strong>: Where request messages may be passed to a cloud-based wallet service
+ via that service's REST API endpoint(s) and where HTTP callbacks may be used to pass responses to other
+ Web services.
+ </li>
+ <li><strong>Inter-app on mobile devices (Optional)</strong>: If possible the group will standardise a
+ delivery mechanism for payment messages between apps on a mobile device so that wallet apps can
+ seamlessly interface with Websites running inside the mobile device's user agent (browser).
+ </li>
+ </ul>
+ <h4 id="Card_Payments_1.0">Card Payments 1.0 (optional)</h4>
+
+ <p>A very large proportion of payments on the Web are conducted using payment cards from one of the global card
+ schemes. The group should attempt to define a standardised specialisation of the payment flow specifically
+ for payment cards.</p>
+
+ <p>A generic card payment standard could:</p>
+ <ul>
+ <li>Demonstrate how a debit-pull payment scheme should be implemented using the Web Payments 1.0
+ standard.
+ </li>
+ <li>Take advantage of new security technologies such as EMVco Tokenisation to improve on the existing
+ methods of using cards on the Web.
+ </li>
+ <li>Standardise a single payment scheme that is reusable by all payment card schemes globally to kick-start
+ adoption of the Web Payments 1.0 standard.
+ </li>
+ </ul>
+ <p>Development of such a standard will require collaboration by the group with the owners of the existing global
+ card schemes.</p>
+ <h4>Milestones</h4>
+ <table width="80%" class="roadmap">
+ <tfoot>
+ <tr>
+ <td colspan="6" rowspan="1">Note: The group will document significant changes from this initial schedule
+ on the group home page.
+ </td>
+ </tr>
+ </tfoot>
+ <tbody>
+ <tr>
+ <th rowspan="1" colspan="1">Specification</th>
+ <th rowspan="1" colspan="1">
+ <acronym title="First Working Draft">FPWD</acronym>
+ </th>
+ <th rowspan="1" colspan="1">
+ <acronym title="Candidate Recommendation">CR</acronym>
+ </th>
+ <th rowspan="1" colspan="1">
+ <acronym title="Proposed Recommendation">PR</acronym>
+ </th>
+ <th rowspan="1" colspan="1">
+ <acronym title="Recommendation">Rec</acronym>
+ </th>
+ </tr>
+ <tr>
+ <th rowspan="1" colspan="1">Web Payment Vocabularies 1.0</th>
+ <td class="WD1" rowspan="1" colspan="1">March 2016</td>
+ <td class="CR" rowspan="1" colspan="1">July 2016</td>
+ <td class="PR" rowspan="1" colspan="1">April 2017</td>
+ <td class="REC" rowspan="1" colspan="1">June 2017</td>
+ </tr>
+ <tr>
+ <th rowspan="1" colspan="1">Web Transactions 1.0</th>
+ <td class="WD1" rowspan="1" colspan="1">April 2016</td>
+ <td class="CR" rowspan="1" colspan="1">September 2016</td>
+ <td class="PR" rowspan="1" colspan="1">September 2017</td>
+ <td class="REC" rowspan="1" colspan="1">November 2017</td>
+ </tr>
+ </tbody>
+ </table>
+ <h3 id="other_deliverables">Other deliverables</h3>
+
+ <p>The Working Group will document best practices and recommended algorithms for the discovery of payer payment
+ instruments by wallet services. This involves best practice approaches for discovering the supported payer
+ payment instruments given the payer's configured payment instruments and those acceptable to a payee as
+ listed in a payment initiation request.</p>
+ </div>
+ <div class="dependencies">
+ <h2 id="coordination">Dependencies and Liaisons</h2>
+
+ <h3>W3C Groups</h3>
+ <dl>
+ <dt>
+ <a href="/Payments/IG/">Web Payments Interest Group</a>
+ </dt>
+ <dd>Discussion of the use cases and requirements that led to the creation of this group, as well as the
+ overall Web payment
+ landscape of which this group's work is a part.
+ </dd>
+ <dt>
+ <a href="/community/webpayments/">Web Payments Community Group</a>
+ </dt>
+ <dd>Community group responsible for research and incubation of ideas that have been adopted by this group.
+ </dd>
+ <dt>
+ <a href="/community/credentials">Credentials Community Group</a>
+ </dt>
+ <dd>Researching methods to exchange secure, verifiable credentials.</dd>
+ <dt>
+ <a href="http://www.w3.org/Privacy/">Privacy Interest Group</a>
+ </dt>
+ <dd>For privacy reviews.</dd>
+ <dt>
+ <a href="http://www.w3.org/Security/wiki/IG">Web Security Interest Group</a>
+ </dt>
+ <dd>For security reviews.</dd>
+ <dt>
+ <a href="/International/core/">Internationalization Core
+ Working Group</a>
+ </dt>
+ <dd>Internationalization and localization review</dd>
+ <dt>
+ <a href="/2012/webcrypto/">Web Cryptography Working Group</a>
+ </dt>
+ <dd>Consultation on encryption of messages that are part of these APIs.</dd>
+ <dt>
+ <a href="/WAI/PF/">Protocols and Formats Working Group</a>(and successor)
+ </dt>
+ <dd>To help ensure the protocols support accessibility.</dd>
+ </dl>
+ <p>This group will also collaborate with future W3C Working Groups developing authentication protocols.</p>
+
+ <h3>Groups Outside W3C</h3>
+ <dl>
+ <dt>
+ <a href="http://www.gsma.com/">GSMA</a>
+ </dt>
+ <dd>GSMA is an industry association of mobile network operators with near global coverage.</dd>
+ <dt>
+ <a href="http://www.iso.org/iso/iso_technical_committee?commid=49650">ISO TC 68</a>
+ </dt>
+ <dd>Coordination with ISO TC 68 will help achieve broad interoperability of payment systems (e.g., through
+ alignment between
+ Web protocols and ISO 20022).
+ </dd>
+ <dt>
+ <a href="http://x9.org/">ASC (Accredited Standards Committee) X9</a>
+ </dt>
+ <dd>Coordination with X9 will help achieve broad interoperability of payment systems (e.g., through
+ alignment between Web protocols
+ and ISO 12812).
+ </dd>
+ </dl>
+ </div>
+ <div class="participation">
+ <h2 id="participation">Participation</h2>
+
+ <p>To be successful, the Web Payments Working Group is expected to have active participants for its duration.
+ Effective participation to Web Payments Working Group may consume for each participant; for editors. The Web
+ Payments Working Group will allocate also the necessary resources for building Test Suites for each
+ specification.</p>
+ </div>
+ <div class="communication">
+ <h2 id="communication">Communication</h2>
+
+ <p>This group primarily conducts its work on the public mailing list public-paymentsarch-wg@w3.org (archive).
+ Administrative tasks may be conducted in Member-only communications.</p>
+
+ <p>Information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is
+ available from the Web Payments Working Group home page.</p>
+ </div>
+ <div class="decisions">
+ <h2 id="decisions">Decision Policy</h2>
+
+ <p>As explained in the Process Document (<a href="/Consortium/Process/policies#Consensus">section 3.3</a>), this
+ group will seek to make decisions when there is consensus. When the Chair puts a question and observes
+ dissent, after due consideration of different opinions, the Chairs should put a question out for voting
+ within the group (allowing for remote asynchronous participation -- using, for example, email and/or
+ web-based survey techniques) and record a decision, along with any objections. The matter should then be
+ considered resolved unless and until new information becomes available.
+
+ <p>Any resolution first taken in a face-to-face meeting or teleconference (i.e., that does not follow a 7 day
+ call for consensus on the mailing list) is to be considered provisional until 5 working days after the
+ publication of the resolution in draft minutes, available from the WG's calendar or home page. If no
+ objections are raised on the mailing list within that time, the resolution will be considered to have
+ consensus as a resolution of the Working Group.</p>
+ </div>
+ <div class="patent">
+ <h2 id="patentpolicy">Patent Policy</h2>
+
+ <p>This Working Group operates under the <a href="/2014/Process-20140801/">W3C Patent Policy</a>(1 August 2014
+ Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be
+ implemented, according to this policy, on a Royalty-Free basis.</p>
+
+ <p>For more information about disclosure obligations for this group, please see the <a href="/2004/01/pp-impl/">W3C
+ Patent Policy Implementation</a>.</p>
+ </div>
+ <h2 id="about">About this Charter</h2>
+
+ <p>This charter for the Web Payments Working Group has been created according to <a
+ href="/Consortium/Process/groups#GAGeneral">section 6.2</a>of the <a href="/Consortium/Process">Process
+ Document</a>. In the event of a conflict between this document or the provisions of any charter and the W3C
+ Process, the W3C Process shall take precedence.</p>
+ <hr/>
+ <address>Participants of the Web Payments Interest Group</address>
+ <p class="copyright">
+ <a rel="Copyright" href="/Consortium/Legal/ipr-notice#Copyright">Copyright</a>© 2015
+ <a href="/"><acronym title="World Wide Web Consortium">W3C</acronym></a>
+ <sup>®</sup>(
+ <a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>,
+ <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
+ <a href="http://www.keio.ac.jp/">Keio</a>,
+ <a href="http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved.</p>
+
+ <p>$Date: 2015/06/30 18:42:23 $</p>
+</div>
+</body>
+
+</html>
\ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/latest/common/biblio.js Sun Jul 12 07:14:14 2015 -0700
@@ -0,0 +1,20 @@
+var biblio = {
+
+// capture localBiblio entries here if needed - example below
+// "WAI-ARIA-10": {
+// "authors": [
+// "James Craig",
+// "Michael Cooper"
+// ],
+// "etAl": true,
+// "href": "http://www.w3.org/TR/wai-aria/",
+// "title": "Accessible Rich Internet Applications (WAI-ARIA) 1.0",
+// "status": "REC",
+// "publisher": "W3C",
+// "deliveredBy": [
+// "http://www.w3.org/WAI/PF/"
+// ]
+// }
+
+
+};
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/latest/common/css/common.css Sun Jul 12 07:14:14 2015 -0700
@@ -0,0 +1,93 @@
+
+* {
+ /* add default line-height so different fonts don't affect the rhythm of line-box height */
+ line-height:1.2; /* [sic] unitless multiplier, not EM size */
+}
+ol{ list-style:decimal; }
+ol ol{ list-style:lower-alpha; }
+ol ol ol{ list-style:lower-roman; }
+ol ol ol ol{ list-style:upper-alpha; }
+
+table{
+ border:solid 2px #999;
+ border-width:1px 0 0 1px;
+ margin:0.1em 0 1em;
+ padding:0;
+ border-spacing:0;
+ border-collapse:collapse;
+}
+th, td{
+ border:solid 2px #999;
+ border-width:0 1px 1px 0;
+ padding:0.15em 0.3em 0.1em;
+ vertical-align:top;
+ text-align:left;
+}
+th{
+ background-color:#eee;
+}
+caption{
+ text-align:left;
+ color:#555;
+ font-style:normal;
+ margin:1em 0 0.1em;
+ padding:0 0 0 0.3em;
+}
+th+th, td+td{
+ width:auto;
+}
+html code, html pre, html kbd{ /* more specific selector than the default W3C style sheet */
+ /* Most browsers default 'monospace' to Courier, which has an ex-height of about 60% normal size. */
+ /* Monaco has a normal ex-height so font sizes appear more consistent with surrounding non-monospaced text. */
+ font-family: "Monaco", "Courier New", "Courier", monospace;
+ font-family: "Monaco", "Courier New", "Courier"; /* declare as separate rule to account for browser font-size inconsistencies, monospace fallback from previous rule should still work in the [almost non-existant] case that a user system does not have Courier */
+ font-size:0.9em;
+}
+html pre { /* more specific selector than the default W3C style sheet */
+ border: solid 1px #999;
+ background-color: #fcfcfc;
+ margin:1em 0;
+ padding:0.5em 0.8em;
+ font-size:0.75em; /* text in blocks code blocks looked too big now that font is back to normal size */
+ line-height:1.4; /* [sic] unitless multiplier, not EM size */
+}
+pre .tag, code .tag, code.tag{
+ color:#00c; /* blue */
+}
+pre .str, code .str, code.str{
+ color:#090; /* green */
+}
+pre .comment, code .comment, code.comment, .comment .str, .comment .tag{
+ color:#777; /* gray */
+}
+.termref, a.termref:link {
+ color:#006400;
+ text-decoration:none;
+ font-style:italic;
+}
+a.termref:visited {
+ color:inherit;
+}
+a.termref:hover, a.termref:focus {
+ background-color: #fafad2;
+ color: #006400;
+}
+.empty {
+ display: none;
+}
+.note {
+ color:#444;
+ border:solid 1px #ccc;
+ margin:1em 0;
+ padding:1em 2em;
+}
+.ednote {
+ border:solid 3px #cca;
+ background-color:#ffd;
+ padding:0 0.8em;
+}
+/* prevent <dt> from butting up against previous <dd> in .termlist (terms.html) */
+.termlist dt {margin-top: 1em;}
+
+
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/latest/common/script/resolveReferences.js Sun Jul 12 07:14:14 2015 -0700
@@ -0,0 +1,95 @@
+function linkCrossReferences() {
+
+ var specBaseURL = ( respecConfig.ariaSpecURLs ?
+ respecConfig.ariaSpecURLs[respecConfig.specStatus] : null
+ );
+
+ var coreMappingURL = (respecConfig.coreMappingURLs ?
+ respecConfig.coreMappingURLs[respecConfig.specStatus] : null
+ );
+
+ var accNameURL = (respecConfig.accNameURLs ?
+ respecConfig.accNameURLs[respecConfig.specStatus] : null
+ );
+
+ function setHrefs (selString, baseUrl) {
+ $ (selString).each (
+ function (idx, el) {
+ var href = $ (el).attr ('href');
+ $ (el).attr ('href', baseUrl + href);
+ });
+ }
+
+ // First the links to the definitions of roles, states, and properties.
+ if (!!specBaseURL) {
+ setHrefs ('a.role-reference, a.property-reference, a.state-reference, a.specref', specBaseURL);
+ }
+ else {
+ console.log ("linkCrossReferences(): specBaseURL is not defined.");
+ }
+
+ // Second, for links to role, state, and property mappings in the core mapping
+ // doc.
+ if (!!coreMappingURL) {
+ setHrefs ('a.core-mapping', coreMappingURL);
+ }
+ else {
+ console.log ("linkCrossReferences(): Note -- coreMappingURL is not defined.");
+ }
+
+ // Third, for links into the accname document.
+ if (!!accNameURL) {
+ setHrefs ('a.accname', accNameURL);
+ }
+ else {
+ console.log ("linkCrossReferences(): Note -- accNameURL is not defined.");
+ }
+}
+
+
+// We should be able to remove terms that are not actually
+// referenced from the common definitions
+var termNames = [] ;
+
+function restrictReferences(utils, content) {
+ var base = document.createElement("div");
+ base.innerHTML = content;
+
+ // strategy: Traverse the content finding all of the terms defined
+ $.each(base.querySelectorAll("dfn"), function(i, item) {
+ var $t = $(item) ;
+ var title = $t.dfnTitle();
+ var n = $t.makeID("dfn", title);
+ if (n) {
+ termNames[n] = $t.parent() ;
+ }
+ });
+
+ // add a handler to come in after all the definitions are resolved
+
+ respecEvents.sub('end', function(message) {
+ if (message == 'core/link-to-dfn') {
+ // all definitions are linked
+ $("a.internalDFN").each(function () {
+ var $item = $(this) ;
+ var r = $item.attr('href').replace(/^#/,"") ;
+ if (termNames[r]) {
+ delete termNames[r] ;
+ }
+ });
+ // delete any terms that were not referenced.
+ Object.keys(termNames).forEach(function(term) {
+ var $p = $("#"+term) ;
+ if ($p) {
+ var t = $p.dfnTitle();
+ $p.parent().next().remove();
+ $p.remove() ;
+ if (respecConfig.definitionMap[t]) {
+ delete respecConfig.definitionMap[t];
+ }
+ }
+ });
+ }
+ });
+ return (base.innerHTML);
+}
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/latest/common/terms.html Sun Jul 12 07:14:14 2015 -0700
@@ -0,0 +1,141 @@
+<p>The following terms are used throughout this document.</p>
+
+<dl class="termlist">
+ <dt><dfn>Account</dfn></dt>
+ <dd>[PSD2] an account held in the name of one or more payment service users
+ which is used for the execution of payment transactions</dd>
+ <dd>[Capabilities] An account is a store of value with a balance and a history
+ of debits and credits that affect that balance</dd>
+
+ <dt><dfn>Account Provider</dfn></dt>
+ <dd>[PSD2] account servicing payment service provider: a payment service provider
+ providing and maintaining the payment account from which the payer wants the
+ specific payment transaction to be made</dd>
+
+ <dt><dfn>Authentication</dfn></dt>
+ <dd>[PSD2] procedures which allow the payment service provider to verify the
+ identity of a payment service user or the validity of the use of a specific
+ payment instrument, including the use of its personalized security credentials</dd>
+ <dd>[ECB] a security mechanism for verifying: 1) the identity of an individual
+ or other entity (including verification by means of a computer or computer
+ application); and 2) the level of authority of that person or entity (i.e.
+ the ability of that person or entity to perform specific tasks or activities).</dd>
+
+ <dt><dfn>Authorization</dfn></dt>
+ <dd>[Proposed text – Evert] Requesting acceptance of a payment from a payer to a payee
+ at the account serving payment service provider or other actor
+ according to payment rules defined by the relevant payment scheme</dd>
+ <dd>[ECB] the consent given by a participant (or a third party acting on behalf of
+ that participant) in order to transfer funds or securities.</dd>
+
+ <dt><dfn>Clearing</dfn></dt>
+ <dd>[ECB] the process of transmitting, reconciling and, in some cases,
+ confirming transfer orders prior to settlement, potentially including the
+ netting of orders and the establishment of final positions for settlement</dd>
+
+ <dt><dfn>Customer</dfn></dt>
+ <dd>An entity paying to receive goods, services, or other things of value; abstractly known as a payer.</dd>
+
+ <dt><dfn>Identity</dfn></dt>
+ <dd>A set of information that can be used to identify a particular entity
+ such as a person, software agent, or organization.
+ An entity may have multiple identities associated with it.</dd>
+
+ <dt><dfn>Ledger</dfn></dt>
+ <dd>[Merriam-Webster] a book containing accounts to which debits and credits
+ are posted from books of original entry</dd>
+
+ <dt><dfn>Merchant</dfn></dt>
+ <dd>An entity receiving payment for goods, services, or other things of value;
+ abstractly known as a payee.</dd>
+
+ <dt><dfn>Payer</dfn></dt>
+ <dd>An entity that provides a source of funds as required by a transaction.</dd>
+
+ <dt><dfn>Payee</dfn></dt>
+ <dd>An entity that receives funds as required by a transaction.</dd>
+
+ <dt><dfn>Payment</dfn></dt>
+ <dd>[ECB] in a strict sense, a payment is a transfer of funds which discharges
+ an obligation on the part of a payer vis-à-vis a payee.
+ However, in a technical or statistical sense, it is often used as a synonym for “transfer order”</dd>
+
+ <dt><dfn>Payment Order</dfn></dt>
+ <dd>[PSD2] any instruction by a payer or payee to his payment service provider
+ requesting the execution of a payment transaction</dd>
+
+ <dt><dfn>Transfer Order</dfn></dt>
+ <dd>[ECB] an order or message requesting the transfer of assets
+ (e.g. funds, securities, other financial instruments or commodities)
+ from the debtor to the creditor</dd>
+
+ <dt><dfn>Payment Instrument</dfn></dt>
+ <dd>PSD2] any personalized device(s) and/or set of procedures agreed
+ between the payment service user and the payment service provider
+ and used in order to initiate a payment order</dd>
+ <dd>[ECB] a tool or a set of procedures enabling the transfer of funds from a payer to a payee.</dd>
+
+ <dt><dfn>Payment Scheme</dfn></dt>
+ <dd>[ECB] a set of interbank rules, practices and standards necessary
+ for the functioning of payment services.</dd>
+
+ <dt><dfn>Payment Service Provider</dfn></dt>
+ <dd>[PSD] A body executing payment services such as
+ <ol>
+ <li>credit institutions</li>
+ <li>electronic money institutions</li>
+ <li>post office giro institutions</li>
+ <li>payment institutions</li>
+ <li>central banks other than when acting in their capacity as a monetary authority
+ or carrying out other functions of a public nature</li>
+ <li>government departments and local authorities, other than when carrying out functions
+ of a public nature</li>
+ </ol></dd>
+
+ <dt><dfn>Credit institution</dfn></dt>
+ <dd>[ECB] a company duly authorized to carry out banking transactions on a regular basis
+ (i.e. to receive deposits from the public, carry out credit transactions,
+ make funds available and manage means of payment)</dd>
+
+ <dt><dfn>Electronic Money Institution</dfn></dt>
+ <dd>[ECB] a term used in EU legislation to designate credit institutions which
+ are governed by a simplified regulatory regime because their activity is
+ limited to the issuance of electronic money and the provision of financial
+ and non-financial services closely related to the issuance of electronic money.</dd>
+
+ <dt><dfn>Purchase</dfn></dt>
+ <dd>Activities surrounding and including a transaction
+ (e.g., discovery of an offer, negotiation of terms, selection of payment instrument, delivery, etc.).</dd>
+
+ <dt><dfn>Settlement</dfn></dt>
+ <dd>[ECB] the completion of a transaction or of processing with the aim of
+ discharging participants’ obligations through the transfer of funds and/or
+ securities. A settlement may be final or provisional.</dd>
+
+ <dt><dfn>Transaction</dfn></dt>
+ <dd>An agreement, communication, or movement carried out between a buyer and a seller
+ to exchange an asset for payment</dd>
+
+ <dt><dfn>Wallet</dfn></dt>
+ <dd>a software service, providing similar functions in the digital world to those provided
+ by a physical wallet, namely:
+ <ul>
+ <li>It holds payment instruments registered by the wallet owner;</li>
+ <li>It supports certain payment schemes and enables the payer to use registered payment
+ instruments to execute a payment in accordance with that scheme;</li>
+ <li>It may hold one or more balances of some digital asset that can be used to make payments.</li>
+ </ul>
+ This definition of wallet may expand in the future to include other items people find in
+ physical wallets such as digital receipts, coupons, and identification.</dd>
+
+
+ <dt><dfn>Payment Orchestrator</dfn></dt>
+ <dd>The payment orchestrator is the entity or entities (payer, payee or payment
+ service provider) that are orchestrating the steps required to complete the
+ payment flow.</dd>
+
+ <dt><dfn>Regulator</dfn></dt>
+ <dd>The regulator is responsible for monitoring some
+ payments activities and enforcing legal requirements.</dd>
+
+</dl>
--- a/latest/use-cases/index.html Wed Jul 01 16:32:19 2015 +0200
+++ b/latest/use-cases/index.html Sun Jul 12 07:14:14 2015 -0700
@@ -198,7 +198,7 @@
payment providers, software vendors, mobile operators, native mobile
apps, and payment networks. The roadmap will include
<a title="payment scheme">payment schemes</a> in use
-today (such as electronic cheques, credit cards, direct debit, and
+today (such as electronic checks, credit cards, direct debit, and
cryptocurrencies) and those of the future. The roadmap will be derived from
the use cases listed below.
</p>
@@ -209,8 +209,8 @@
The Web Payments work is not just about making payments easier, faster,
more secure, and more innovative. There are many people around the world that
today's financial system does not reach. These people are called the world's
-unbanked (or underbanked). The unbanked often live pay cheque to pay cheque, do
-not have access to savings accounts or low-fee cheque cashing services, lines
+unbanked (or underbanked). The unbanked often live paycheck to paycheck, do
+not have access to savings accounts or low-fee check cashing services, lines
of credit, or a way of saving for their future. Being unable to plan for one's
financial future often results in a focus on the short-term, which creates a
vicious cycle of not being able to escape one's situation. Not being able to
@@ -241,22 +241,27 @@
<ul>
<li>
-Section 2 defines basic payment terms.
+<a href="#terminology">Section 2</a> defines basic payment terms.
</li>
<li>
-Section 3 describes a common payment flow at a high
-level. The group expects to work on additional
+<a href="#an-overview-of-the-payment-phases">Section 3</a> describes a
+common payment flow at a high level. The group expects to work on additional
payment flows in future work.
</li>
<li>
-Section 4 is a specific narrative, labeled according
-to the steps of section 3. Section 7 describes
+<a href="#a-simple-example-of-the-payment-phases">Section 4</a> is a specific
+narrative, labeled according to the steps of section 3.
+<a href="#additional-examples-of-the-payment-phases">Section 7</a> describes
additional familiar narratives to give a more complete picture
of how the payment phases apply.
</li>
<li>
-Section 6 lists the use cases - short scenarios that cover
-diverse aspects of each payment step.
+<a href="#assumptions">Section 5</a> highlights general assumptions that have
+been made about the use cases.
+ </li>
+ <li>
+<a href="#use-cases-1">Section 6</a> lists the use cases - short scenarios
+that cover diverse aspects of each payment step.
</li>
</ul>
@@ -349,11 +354,16 @@
An <a>entity</a> that provides a source of funds as required by a
<a>transaction</a>.
</dd>
+ <dt><dfn>transaction</dfn></dt>
+ <dd>
+An economic exchange between a <a>payer</a> and one or more
+<a title="payee">payees</a>.
+ </dd>
<dt><dfn>payment instrument</dfn></dt>
<dd>
A mechanism used to transfer value from a <a>payer</a> to a
<a>payee</a>. Examples: Corporate Visa card, personal Visa card, a bitcoin
-account, a PayPal account, an Alipay account, etc.
+account, a PayPal account, and an Alipay account.
</dd>
<dt><dfn>payment processor</dfn></dt>
<dd>
@@ -372,12 +382,35 @@
<dt><dfn>purchase</dfn></dt>
<dd>
Activities surrounding and including a <a>transaction</a> (e.g., discovery of
-an offer, negotiation of terms, selection of <a>payment instrument</a>,
-delivery, etc.).
+an offer, negotiation of terms, selection of <a>payment instrument</a>, and
+delivery).
</dd>
- <dt><dfn>transaction</dfn></dt>
+ <dt><dfn>three corner model</dfn></dt>
<dd>
-An exchange of value (e.g., buying or selling something)
+A <a>payment scheme</a> including the following stakeholders: the <a>payer</a>
+(also known as the Card Holder), the Issuer (who has a relationship with
+the <a>payer</a>), the Acceptor and the Acquirer (who has a relationship with
+the Acceptor), but where the Issuer and the Acquirer are the same entity.
+ </dd>
+ <dt><dfn>four corner model</dfn></dt>
+ <dd>
+A <a>payment scheme</a> which includes the following stakeholders:
+the <a>payer</a> (also known as the Cardholder), the Issuer (who has a
+relationship with the Cardholder), the Acceptor and the Acquirer (which
+has a relationship with the Acceptor). The <a>payment scheme</a> defines the
+rules which apply to all parties; there are no limitations as to who may
+join the scheme, as long as the requirements of the scheme are met.
+ </dd>
+ <dt><dfn>push payment</dfn> or <dfn>payer-initiated payment</dfn></dt>
+ <dd>
+A type of <a>transaction</a> where the <a>payer</a> initiates the funds
+transfer to the <a>payee</a>. PayPal is an example of a push payment.
+ </dd>
+ <dt><dfn>pull payment</dfn> or <dfn>payee-initiated payment</dfn></dt>
+ <dd>
+A type of <a>transaction</a> where the <a>payee</a> initiates the funds
+transfer from the <a>payee</a>. A credit card payment is an example of a
+pull payment.
</dd>
</dl>
@@ -432,8 +465,8 @@
</ol>
<p>The descriptions below only discuss the interactions between the
-payer and the <a>payee</a>. We do not expose the low-level exchanges between
-banks, card associations, or other back-end "payment clearing" parties
+<a>payer</a> and the <a>payee</a>. We do not expose the low-level exchanges
+between banks, card associations, or other back-end "payment clearing" parties
in a <a>transaction</a>. Those details will be discussed in the Interest
Group's work on architecture and
requirements.</p>
@@ -578,11 +611,11 @@
<strong>Delivery of Receipt</strong>. Depending on the
<a title="payment scheme">payment scheme(s)</a> chosen, there are
various ways and times that a receipt may be delivered (e.g., credit card
-receipt, digital proof of <a>purchase</a>, encrypted line-item receipt, etc.).
+receipt, digital proof of <a>purchase</a>, or encrypted line-item receipt).
</li>
<li>
<strong>Refunds</strong>. At times exceptions may occur (e.g., defective
-product, application of store return policy, etc.). In this case, the
+product or application of store return policy). In this case, the
<a>payee</a> initiates payment to the <a>payer</a>. The refund may
take different forms, including a refund to the <a title="payer">payer's</a>
payment instrument, a refund using a different payment scheme, or store credit.
@@ -623,8 +656,10 @@
home on her laptop, where she browses the items on the PayToParty Web
site. On the way to work the next morning, she explores the catalog
further from a native app on her smart phone. Jill can't decide
-whether the dress displayed online is blue with black stripes or white
-with gold stripes, so during her lunch break, she drops into the
+whether the dress displayed online is
+<a href="https://en.wikipedia.org/wiki/The_dress_(viral_phenomenon)">
+blue with black stripes or white with gold stripes</a>,
+so during her lunch break, she drops into the
PayToParty store near her office. She spots a few more items that
she thinks she'd like to <a>purchase</a>, but decides to wait until later to
make the <a>purchase</a>.
@@ -633,7 +668,7 @@
<li>
<strong>Agreement on Terms</strong>: That same evening at home,
Jill logs into her account on the PayToParty Web site, adding her
-preferred items to her shopping cart. The total price appears on the
+chosen items to her shopping cart. The total price appears on the
page.
</li>
@@ -667,9 +702,9 @@
<li>
<strong>Authentication to Access Instruments</strong>: Jill selects
-the PayToParty loyalty card, which she enabled with theft-protection,
-and is asked to input a code that is sent to her phone before the
-<a>purchase</a> can be completed.
+the PayToParty loyalty card, the use of which is protected by two-factor
+authentication, and is asked to input a code that is sent to her phone
+before the <a>purchase</a> can be completed.
</li>
</ul>
</section>
@@ -751,7 +786,7 @@
information is not transmitted to parties that do not absolutely need to
know the information in order to complete the <a>transaction</a>.</li>
<li>
-<strong>Identity</strong>. There will be a consistent, interoperable
+<strong>Identity</strong>. There will be an interoperable
identifier used to identify the participants and accounts in a Web Payments
transaction.
</li>
@@ -859,8 +894,8 @@
</dd>
<dt>Exceptions</dt>
<dd>
-No mobile phone connectivity (visiting a different country, trip occurs
-outside the range of a mobile network, etc.)
+No mobile phone connectivity (e.g. visiting a different country or trip occurs
+outside the range of a mobile network).
</dd>
</dl>
@@ -868,7 +903,7 @@
<dt>Freemium</dt>
<dd>
Chaoxiang plays his favorite native app game and wants to upgrade his avatar
-with a few extra "power-ups." Clicking on a power-up displays the price.
+with a few extra "power-ups". Clicking on a power-up displays the price.
</dd>
<dt>Target version</dt>
<dd>Uncategorized</dd>
@@ -882,7 +917,7 @@
</dl>
<dl id="uc-email" class="dl-horizontal">
- <dt>E-mail</dt>
+ <dt>Email</dt>
<dd>
A GroupBuyCo customer receives an offer by email to <a>purchase</a> the deal
of the day.
@@ -920,8 +955,8 @@
<dt>Exceptions</dt>
<dd>
Software acting on the <a title="payer">payer's</a> behalf may keep
-track of exactly how much money the <a>payer</a> has and not allow them to
-process the offer.
+track of exactly how much money the <a>payer</a> has available and
+not allow them to process the offer.
</dd>
</dl>
@@ -948,8 +983,8 @@
</dd>
<dt>Security</dt>
<dd>
-Automated <a title="purchase">purchases</a> (e.g,. by a vehicle) should involve
-increased security (e.g., a second factor of authentication).
+Automated <a title="purchase">purchases</a> (e.g,. by a vehicle) may involve
+increased logging and security (e.g., a second factor of authentication).
</dd>
</dl>
@@ -986,7 +1021,7 @@
</dl>
<dl id="uc-trialware" class="dl-horizontal">
- <dt>Trial-ware</dt>
+ <dt>Trialware</dt>
<dd>
Amantha downloads the latest version of her favorite game and beats
the first level. The game asks her if she'd like to buy the full game
@@ -996,7 +1031,7 @@
<dd>Uncategorized</dd>
<dt>Motivation</dt>
<dd>
-There is a fairly large trial-ware industry that could benefit from
+There is a fairly large trialware industry that could benefit from
a simple way of executing a payment without requiring redirection
to another site to enter account and payment details.
</dd>
@@ -1019,8 +1054,7 @@
<dt>Accessibility</dt>
<dd>
For safety reasons, the interface used to interact with the digital offer
-must not distract the driver of the vehicle. Voice controls and other
-techniques can be used to reduce driver distraction.
+must not lead to an increase in vehicle accidents.
</dd>
</dl>
@@ -1166,12 +1200,12 @@
<dl id="uc-privacy" class="dl-horizontal">
<dt>Privacy Protection</dt>
<dd>
-Tibor orders assorted chocolates from CandyCo. CandyCo only needs Tibor's
-verified shipping address to send him the chocolates. With Tibor's
-authorization, his payment software transmits only his shipping address to
-CandyCo. Tibor's privacy is protected from the candy store, which did not
-require Tibor's name, email address, or any other personally identifying
-information to complete the <a>transaction</a>.
+Tibor orders chocolates from CandyCo. CandyCo requests Tibor's
+tokenized shipping address to send him the candy. With Tibor's
+authorization, his payment software transmits a tokenized shipping address to
+BoomCo that the shipper can decipher. Tibor's privacy is protected from the
+candy store, which did not require any personally identifying information to
+complete the <a>transaction</a>.
</dd>
<dt>Target version</dt>
<dd>Uncategorized</dd>
@@ -1191,7 +1225,8 @@
<dl id="uc-need-to-know" class="dl-horizontal">
<dt>Need to Know</dt>
<dd>
-PayCo is required to keep a certain amount of information on their customers
+PayCo, a payment processor, is required to keep a certain amount of
+information on their customers
for anti-money laundering / know your customer regulatory purposes. When a
<a>payer</a> performs a <a>transaction</a> with a <a>payee</a>, PayCo
would like to reduce the amount of information that's transmitted to the
@@ -1331,7 +1366,7 @@
<dl id="uc-ubiquitous" class="dl-horizontal">
<dt>Ubiquitous Schemes</dt>
<dd>
-A game store Web site accepts payment via credit card, e-cheque, and
+A game store Web site accepts payment via credit card, e-check, and
operator billing.
</dd>
<dt>Target version</dt>
@@ -1752,7 +1787,7 @@
Joakim uses his Bitcoin wallet to send money to his friend.
</li>
<li>
-Carson (in New York City) sends money to Vladamir (in Moscow) using
+Carson (in New York City) sends money to Vladimir (in Moscow) using
his Ripple client, which converts the currency from US Dollars to Rubels in
transit.
</li>
@@ -1763,7 +1798,7 @@
<dt>Motivation</dt>
<dd>
Payer-initiated payments, also known as "push payments",
-"three-corner model payments", or "peer-to-peer payments", are fundamentally
+"three corner model payments", or "peer-to-peer payments", are fundamentally
more secure as no information is given to the <a>payee</a> that would
allow them or an attacker to replay the <a>transaction</a> for a different
amount or to a different <a>payee</a> at a later date.
@@ -1807,8 +1842,9 @@
<dt>Motivation</dt>
<dd>
A <a>payee</a> may want to limit access to certain services to only those
-who they know can afford the good or service because the act of engaging the
-<a>payer</a> may be costly.
+who they know can afford the good or service because the act of
+providing an acceptable level of service to the <a>payee</a> during the
+pre-sale phase may be costly.
</dd>
</dl>
@@ -1881,7 +1917,7 @@
access to the funds in three days.
</li>
<li>
-Frank uses an electronic cheque to pay his rent. The rental agency has access
+Frank uses an electronic check to pay his rent. The rental agency has access
to the funds in 7 days.
</li>
<li>
@@ -1908,7 +1944,7 @@
<dl id="uc-notifications" class="dl-horizontal">
<dt>Notifications</dt>
<dd>
-Gavin sends an electronic cheque to WaveMart. WaveMart receives a notification
+Gavin sends an electronic check to WaveMart. WaveMart receives a notification
that payment has been initiated almost immediately. Four days later, WaveMart
receives a notification from their bank that payment has been received.
</dd>
@@ -1940,9 +1976,8 @@
<dl id="uc-physical-goods" class="dl-horizontal">
<dt>Physical Goods</dt>
<dd>
-Giralt orders a bicycle for his daughter through BikeSmart online. The
-bicycle is delivered a few days later with a QRCode attached to the package
-that only Giralt can access.
+Giralt orders a bicycle for his daughter through BikeSmart online and has it
+shipped to his home address.
</dd>
<dt>Target version</dt>
<dd>1.0</dd>
@@ -1993,22 +2028,30 @@
<dt>Electronic Receipts</dt>
<dd>
Ashraf pulls up to a pump at a petrol station. He pays electronically using a
-credit card (via his phone). An electronic receipt for the <a>purchase</a>
-from the gas station is displayed on his phone.
+credit card (via his phone). A machine-readable electronic receipt for
+the <a>purchase</a> from the gas station is transferred to his phone and
+displayed using his favorite expense tracking software.
</dd>
<dt>Target version</dt>
<dd>1.0 (very basic receipt container and delivery protocol)</dd>
<dt>Motivation</dt>
<dd>
-Electronic receipts will make it easier to track expenses, prove that
-certain <a title="purchase">purchases</a> were made, file tax returns, and
-simplify management of unnecessary paper.
+Standardized, machine-readable electronic receipts could make it easier to
+track expenses, prove that certain <a title="purchase">purchases</a> were
+made, file tax returns, and simplify management of unnecessary paper.
</dd>
- <dt>Privacy / Security</dt>
+ <dt>Privacy</dt>
<dd>
Many merchants want to ensure that receipts are not readable by any party
between them and their customer.
</dd>
+ <dt>Security</dt>
+ <dd>
+Electronic receipts should be tamperproof such that the information can be
+verified to have come from the merchant issuing the receipt. One mechanism
+that could be employed would be the use of digital signatures over the
+contents of the electronic receipt.
+ </dd>
<dt>Accessibility</dt>
<dd>
Protecting digital receipts may have the unintended consequence of degrading
@@ -2063,7 +2106,7 @@
manager approves. The overcharged funds are returned to his account.
</li>
<li>
-Teo claims that a blender they purchased online was faulty and returns
+Teo claims that a blender he purchased online was faulty and returns
the product to the merchant. The merchant provides the customer with a refund
in the form of store credit based on the return policy.
</li>
@@ -2115,7 +2158,7 @@
<section>
<h3>Credit Card Payment (Visa, MasterCard)</h3>
<p>
-This scenario outlines a typical card purchase using the 4 corner model.
+This scenario outlines a typical card purchase using the "four corner model".
Janet is buying an handbag online from a resale shop.
</p>
@@ -2150,8 +2193,8 @@
<li>
<strong>Selection of Payment Instruments</strong>: Janet selects her Discover
-points card that highlighted by default because she had used it for a previous
-purchase with the merchant.
+rewards credit card that is highlighted by default because she had used
+it for a previous purchase with the merchant.
</li>
<li>
@@ -2213,7 +2256,7 @@
tokenization. The merchant has provided a mobile application that
customers can download in the example below. This example may apply to
various tokenization payment systems now in use, such as ApplePay,
-CyberSource, Venmo, Square, etc.
+CyberSource, Venmo, and Square.
</p>
<section class="notoc">
@@ -2290,7 +2333,7 @@
</li>
<li>
-<strong>Delivery of Product</strong>: Terrific-Tools, Inc. ships the ax to Tom.
+<strong>Delivery of Product</strong>: Terrific-Tools ships the ax to Tom.
</li>
</ul>
</section>
@@ -2342,8 +2385,8 @@
<li>
<strong>Authentication to Access Instruments</strong>: Meihui logs in the Alipay
with her account name and password. Meihui is told that she will pay for the
-airline ticket with 600RMB and she confirms it. Meihui uses her fingerprint to
-approve the payment.
+airline ticket with 3,500 RMB and she confirms it. Meihui uses her fingerprint
+to approve the payment.
</li>
</ul>
</section>
@@ -2490,13 +2533,200 @@
</section>
<section>
- <h3>Electronic Cheque Payment</h3>
+ <h3>Electronic Check Payment</h3>
<p><em>To be completed</em>.</p>
</section>
- <section>
- <h3>Credit Transfer / Direct Debit</h3>
- <p><em>To be completed</em>.</p>
+ <section id="direct-debit">
+ <h3>Direct Debit (SEPA Direct Debit)</h3>
+ <p>
+The following scenario outlines an ideal payment experience using a
+Direct Debit (<a>payee-initiated payment</a>), also known as a
+<a>pull payment</a> in the context of a <a>four corner model</a> payment.
+In this scenario, Anna is signing up for electricity service via the
+service's website. During the payment process she will validate an electronic
+direct debit mandate.
+ </p>
+
+ <section class="notoc">
+ <h4>Negotiation of Purchase Terms</h4>
+ <ul>
+ <li>
+<strong>Discovery of Offer</strong>: Anna connects to a utility website. She
+wants to setup this new utility immediately before she moves in to a new flat.
+ </li>
+ <li>
+<strong>Agreement on Terms</strong>: Anna selects the contract she wants and
+agrees to the terms and service associated with the delivery of electricity.
+ </li>
+ <li>
+<strong>Application of Marketing Elements</strong>: <em>Not applicable to this
+particular use case.</em>
+ </li>
+ </ul>
+ </section>
+
+ <section class="notoc">
+ <h4>Negotiation of Payment Instruments</h4>
+ <ul>
+ <li>
+<strong>Discovery of Accepted Schemes</strong>: The utility website takes
+Visa, MasterCard, and SEPA Direct Debit for payment.
+ </li>
+ <li>
+<strong>Selection of Payment Instruments</strong>: Anna chooses SEPA Direct
+Debit for payment.
+ </li>
+ <li>
+<strong>Authentication to Access Instruments</strong>: Anna provides
+all the mandatory data required for a valid electronic SEPA Direct Debit
+Mandate as well as the IBAN number associated with Anna's account. Anna is
+told that she is setting up a recurring payment with the utility and the
+payment will be automatically withdrawn at the end of the month based on
+her electricity consumption. She agrees to the automatic transfer by
+entering her secret PIN.
+ </li>
+ </ul>
+ </section>
+
+ <section class="notoc">
+ <h4>Payment Processing</h4>
+ <ul>
+ <li>
+<strong>Initiation of Processing</strong>: At the end of the month the utility
+invoice system will initiate the payment by sending an invoice by email
+that will be sent directly to Anna's payment service provider.
+ </li>
+ <li>
+<strong>Verification of Available Funds</strong>: <em>Not applicable to this
+particular use case.</em>
+ </li>
+ <li>
+<strong>Authorization of Transfer</strong>: Anna's payment service provider
+authorizes the transfer based on the reference ID that was validated by
+Anna during the <strong>Authentication to Access Instruments</strong> phase.
+ </li>
+ <li>
+<strong>Completion of Transfer</strong>: The utility website gets a message
+from its payment service provider that the transfer has been completed.
+ </li>
+ </ul>
+ </section>
+
+ <section class="notoc">
+ <h4>Delivery of Product/Receipt and Refunds</h4>
+ <ul>
+ <li>
+<strong>Delivery of Receipt</strong>: The utility website sees that Anna's
+direct debit mandate has been validated and sends a receipt message to her
+digital wallet.
+ </li>
+ <li>
+<strong>Delivery of Product</strong>: The utility website sends an email to
+Anna with the contract information based on the email provided in the
+Completion of Transfer message sent to her payment service provider.
+ </li>
+ <li>
+<strong>Refunds</strong>: Anna could request a refund by contacting her bank
+if something goes wrong with the Direct Debit.
+ </li>
+ </ul>
+ </section>
+ </section>
+
+ <section id="credit-transfer">
+ <h3>Credit Transfer (SEPAmail)</h3>
+ <p>
+The following scenario outlines an ideal payment experience using a
+<a>payer-initiated payment</a>, also known as a
+<a>push payment</a> in the context of a <a>four corner model</a> payment. In
+this scenario, Anna is buying a very expensive piece of furniture that costs
+far more than the maximum amount allowed by her payment card. She pays
+using her bank account via her bank's website.
+ </p>
+
+ <section class="notoc">
+ <h4>Negotiation of Purchase Terms</h4>
+ <ul>
+ <li>
+<strong>Discovery of Offer</strong>: Anna browses a Furniture website.
+She wants to buy a desk for her new flat.
+ </li>
+ <li>
+<strong>Agreement on Terms</strong>: Anna selects a heavy oak antique desk
+from the 17th century.
+ </li>
+ <li>
+<strong>Application of Marketing Elements</strong>: <em>Not applicable to this
+particular use case.</em>
+ </li>
+ </ul>
+ </section>
+
+ <section class="notoc">
+ <h4>Negotiation of Payment Instruments</h4>
+ <ul>
+ <li>
+<strong>Discovery of Accepted Schemes</strong>: The furniture website takes
+Visa, MasterCard, and SEPA "Credit Transfer via SEPAmail" for payment.
+ </li>
+ <li>
+<strong>Selection of Payment Instruments</strong>: Anna chooses
+"Credit Transfer via SEPAmail" for payment and provides a tokenized version
+of her IBAN account number. The furniture website sends a "payment request"
+to its payment service provider which will forward it to Anna’s bank.
+ </li>
+ <li>
+<strong>Authentication to Access Instruments</strong>: Anna connects to her
+bank's website where the payment request is pending approval.
+ </li>
+ </ul>
+ </section>
+
+ <section class="notoc">
+ <h4>Payment Processing</h4>
+ <ul>
+ <li>
+<strong>Initiation of Processing</strong>: Anna approves the payment request.
+ </li>
+ <li>
+<strong>Verification of Available Funds</strong>: The availability of
+funds is verified by Anna's bank.
+ </li>
+ <li>
+<strong>Authorization of Transfer</strong>: The funds transfer is automatically
+authorized by Anna's bank.
+ </li>
+ <li>
+<strong>Completion of Transfer</strong>: Anna's bank sends the Credit Transfer,
+as well as a payment report (analogous to a signed receipt) to the furniture
+website's payment service provider. The furniture website gets a message
+(also known as a "payment advice") from its payment service provider that the
+transfer is complete depending of the Scheme of Credit Transfer used:
+within 24 hours for a SEPA Credit Transfer, often longer in International
+Credit Transfer outside Europe.
+ </li>
+ </ul>
+ </section>
+
+ <section class="notoc">
+ <h4>Delivery of Product/Receipt and Refunds</h4>
+ <ul>
+ <li>
+<strong>Delivery of Receipt</strong>: The furniture website sees that Anna's
+credit transfer has been received and sends a receipt by email to
+Anna based on the email address included in the payment report.
+ </li>
+ <li>
+<strong>Delivery of Product</strong>: The piece of furniture is shipped to
+Anna.
+ </li>
+ <li>
+<strong>Refunds</strong>: Anna must contact the furniture website directly
+since the credit transfer cannot be reversed since she initiated it.
+ </li>
+ </ul>
+ </section>
</section>
</section>