Merge branch 'master' into gh-pages
authorAdrian Hope-Bailie <adrian@hopebailie.com>
Mon, 29 Jun 2015 13:24:18 +0200
changeset 461 5dc79237192c
parent 460 8d09e24f5991 (current diff)
parent 409 80452e34dd64 (diff)
child 462 ca94da3f144c
Merge branch 'master' into gh-pages
latest/manifesto/index.html
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/.gitmodules	Mon Jun 29 13:24:18 2015 +0200
@@ -0,0 +1,6 @@
+[submodule "prototypes/web-payment-request-chrome"]
+	path = prototypes/web-payment-request-chrome
+	url = https://github.com/emschwartz/web-payment-request-chrome
+[submodule "prototypes/web-payment-request-demo-server"]
+	path = prototypes/web-payment-request-demo-server
+	url = https://github.com/emschwartz/web-payment-request-demo-server
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/.hgsub	Mon Jun 29 13:24:18 2015 +0200
@@ -0,0 +1,2 @@
+prototypes/web-payment-request-chrome = [git]https://github.com/emschwartz/web-payment-request-chrome
+prototypes/web-payment-request-demo-server = [git]https://github.com/emschwartz/web-payment-request-demo-server
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/.hgsubstate	Mon Jun 29 13:24:18 2015 +0200
@@ -0,0 +1,2 @@
+fe72c5db9405560b603d3f9da57501fe7a00ec4a prototypes/web-payment-request-chrome
+b68e8514e8e15997e90aad7a675d3bcacf5a0c8c prototypes/web-payment-request-demo-server
--- a/README.md	Mon Jun 22 12:58:40 2015 +0200
+++ b/README.md	Mon Jun 29 13:24:18 2015 +0200
@@ -20,5 +20,6 @@
                      Editor's drafts are kept.
 * [ED](ED) - The latest time-stamped Editor's drafts are placed here.
 * [WD](WD) - The latest time-stamped Working Drafts are placed here.
+* [prototypes](prototypes) - Code samples of prototypes built to test assumptions and elicit feedback on work in progress.
 
 
--- a/latest/manifesto/index.html	Mon Jun 22 12:58:40 2015 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,328 +0,0 @@
-<!DOCTYPE html>
-<html>
-  <head>
-    <title>The Value Web Manifesto</title>
-    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
-    <script src='//www.w3.org/Tools/respec/respec-w3c-common' 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:            "value-web-manifesto",
-
-          // if you wish the publication date to be other than today, set this
-          //publishDate:  "2015-04-16",
-
-          // 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: "http://w3c.github.io/webpayments-ig/latest/manifesto/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: "Adrian Hope-Bailie", url: "http://medium.com/@ahopebailie",
-                company: "Ripple Labs", companyURL: "http://www.ripplelabs.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:  [
-              { name: "Adrian Hope-Bailie", url: "http://medium.com/@ahopebailie",
-                company: "Ripple Labs", companyURL: "http://www.ripplelabs.com/" },
-              { 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/",
-                company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/" }
-          ],
-
-          otherLinks: [{
-            key: "Version control",
-            data: [{
-              value: "Github Repository",
-              href: "https://github.com/w3c/webpayments-ig"
-            }, {
-              value: "Issues",
-              href: "http://www.w3.org/Payments/IG/track/products/8"
-            }]
-          }],
-
-          // maximum level of table of contents
-          maxTocLevel: 3,
-
-          // name of the WG
-          wg:           "Web Payments Interest Group",
-
-          // URI of the public WG page
-          wgURI:        "http://www.w3.org/Payments/IG/",
-
-          // name of the public mailing to which comments are due
-          wgPublicList: "public-webpayments-ig-comments",
-
-          // 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",
-
-      };
-    </script>
-  </head>
-<body>
-  <section id='abstract'>
-    <p>
-This document is the vision statment of the W3C Web Payents Interest Group.
-It describes a future that the group aspires to in which value exchange 
-is performed easily and securely on the Open Web Platform and provides the
-background to the use cases, goals and architectural vision of the group.
-    </p>
-  </section>
-
-  <section id='sotd'>
-    <p>
-This document is a work in progress and is being released early and often
-using an agile process; it is currently incomplete.
-    </p>
-  </section>
-
-  <section>
-    <h2>Introduction</h2>
-    <p>
-The World Wide Web has had a tremendous global impact, increasing access to 
-information and education. However, this has not yet translated into ubiquitous 
-access to efficient financial systems and the ability to transact with anyone 
-in the world.
-    </p>
-    <p>
-The Web connected fragmented documentation systems with a common set of standards. 
-Today’s systems of value exchange lack a set of common standards, and are 
-still proprietary, disconnected, and opaque.
-    </p>
-    <p>
-This document outlines a vision for the Web where value is exchanged as 
-freely and easily as information. The Web unified varied and disparate 
-closed information networks through open standards and protocols. In the 
-same way, we should the Value Web will create an open and interconnected network 
-of value exchange linking all of the closed networks that exist today.
-    </p>
-    <p>
-Realising this vision would have profound and far reaching economic and social 
-impacts on financial inclusion, development of small businesses, liquidity of 
-markets, and greater velocity and efficiency of money. 
-    </p>
-  </section>
-  <section>
-    <h2>Principles of the Value Web</h2>
-    <p>
-This vision can only be realised through the collaboration of a variety of 
-stakeholders united in their agreement with the following principles:
-    </p>
-    <section>
-      <h3>There are many value networks and there always will be</h3>
-      <p>
-Ownership of anything of value is recorded and tracked within numerous and 
-diverse networks of trust. The changing ownership or transfer of value within 
-those networks is recorded in a ledger of some form or another. These ledgers 
-are maintained by custodians such as...
-      </p>
-      <ul>
-        <li>Commercial and Retail Banks</li>
-        <li>Central banks</li>
-        <li>Clearinghouses</li>
-        <li>Digital wallets</li>
-        <li>Registers of deeds</li>
-        <li>Stock Exchanges</li>
-        <li>Blockchains</li>
-        <li>Patent offices</li>
-      </ul>
-      <p>
-… and many more.
-      </p>
-      <p>
-Greater diversity of custodians, ledgers and assets is a good thing, but without 
-a set of Web standards to connect them, increasing the number and diversity 
-will quickly become unsustainable.
-      </p>
-      <p>
-The world is tending towards increased global trade and interconnectivity. The 
-lack of standards is likely to continue to increase costs and stand in the way 
-of economic progress.      
-      </p>
-    </section>
-    <section>
-      <h3>There are many ways to connect value networks</h3>
-      <p>
-There are numerous and varied methods of moving value between owners, both within 
-the same network and between disparate networks. Each one of these methods has 
-different strengths and weaknesses depending on the scenario.
-      </p>
-      <p>
-Some methods of moving value between owners have higher risks and lower fees.
-      </p>
-      <p>
-[Illustration - Cash]
-      </p>
-      <p>
-Others have lower risks and higher fees.
-      </p>
-      <p>
-[Illustration - Cards]
-      </p>
-      <p>
-The open architecture of the Web enables a rapid pace of innovation which has 
-increasingly resulted in new types of value exchange methods.
-      </p>
-      <p>
-[Illustration - Crypto-currencies]
-      </p>
-      <p>
-This vision embraces all of these existing technologies as well as those that 
-are in active development today.
-      </p>
-    </section>
-    <section>
-      <h3>Value moves as freely as information on the Web</h3>
-      <p>
-The Web increased efficiency and lowered costs of information exchange by many 
-orders of magnitude. These sorts of efficiency gains are possible via the Web 
-for the exchange of value.
-      </p>
-      <p>
-[Illustration - ?]
-      </p>
-    </section>
-    <section>
-      <h3>The Value Web is open and accessible</h3>
-      <p>
-It is a long-standing W3C principal to create a Web that can be used by all people 
-on any device. Nobody is arbitrarily denied access to the Internet of Value.
-      </p>
-      <p>
-[Illustration - diverse users of the Value Web]
-      </p>
-    </section>
-    <section>
-      <h3>The Value Web is built on trust and security</h3>
-      <p>
-Value exchange on the Web is done in an environment of honesty and trust built on 
-secure and resilient systems. It provides tools that allow law-abiding consumers, 
-merchants and financial institutions to have confidence in the individuals and entities 
-with whom they transact, to be free to choose who those individuals and entities are, 
-and to be able to trust that these counterparties are who they claim to be.
-      </p>
-      <p>
-[Illustration - trust/shaking hands, security/lock]
-      </p>
-    </section>
-    <section>
-      <h3>The Value Web is simultaneously private and transparent</h3>
-      <p>
-There is a need for transparency in moving value on a global network between entities 
-that are subject to different legal and regulatory systems in different jurisdictions. 
-However, privacy as a fundamental right of all participants.
-      </p>
-      <p>
-The future of value exchange via the Web offers the transparency required for all 
-participants to operate within the law but ensures that the privacy of participants 
-is always guaranteed, through the use of secure open protocols incorporating end-to-end 
-data protection.
-      </p>
-      <p>
-[Illustration - masked/protected data]
-      </p>
-    </section>
-    <section>
-      <h3>No single entity controls the Value Web</h3>
-      <p>
-The Web is a public good and is not subject to the whims of one group or another. It is 
-distributed, global, and neutral with respect to payment networks, currencies, 
-technologies, service providers, and participating entities.
-      </p>
-      <p>
-[Illustration - distributed system]
-      </p>
-    </section>
-    <section>
-      <h3>The Value Web is built on open standards</h3>
-      <p>
-In order for value networks, settlement systems, and related services to compete on a 
-level playing field, the foundations of value exchange via the Web must be open, transparent, 
-and neutral. Customers, merchants, financial institutions, and governments stand to benefit 
-from a strong foundation built on open standards..
-      </p>
-      <p>
-The Value Web is built on OpenStand’s <a href="http://open-stand.org/about-us/principles/">five 
-principles for modern standards</a> and it’s standards are free to acquire, free to adopt, 
-and not encumbered by patents.
-      </p>
-      <p>
-[Illustration - Open stand logo?]
-      </p>
-    </section>
-    <section>
-      <h3>The Value Web is simple and extensible</h3>
-      <p>
-Today’s financial system is complex and one of the key challenges for the architects of the Web 
-will be to abstract key areas of complexity and create a simple, universal framework that supports 
-existing systems while enabling a smooth transition to more advanced, extensible, and equitable 
-systems.
-      </p>
-      <p>
-Rules and regulations around the world differ widely. By creating an extensible set of standards, 
-the Web enables individuals or entire value networks to work out the details that are relevant 
-to them. This provides institutions with the flexibility to comply with their local regulations 
-and follow their local customs while connecting globally.
-      </p>
-      <p>
-The standards for value exchange on the Web should be clearly documented to lower the barrier to 
-entry for any entity that wishes to integrate with, or extend it.
-      </p>
-      <p>
-[Illustration - developer]
-      </p>
-    </section>
-  </section>
-
-  <section>
-    <h2>Building an Equitable Global Economy via the Web</h2>
-    <p>
-The Web connects three billion people today and will connect at least three billion more by the 
-year 2020. It is ubiquitous and that ubiquity will only grow over the next decade. The Web is the 
-best connector of information systems that exists today, but there is still much work that needs 
-to be done when connecting the economic systems and value networks that span the world over.
-    </p>
-    <p>
-It is our vision to connect the economic systems of the world via the Web using the principles 
-outlined in this document. Doing so will result in an global architecture for value exchange, built 
-openly, secure by design, and accessible to all.
-    </p>
-  </section>
-
-  <section class="appendix">
-    <h2>Acknowledgements</h2>
-    <p>
-The editors wish to thank the participants of the
-<a href="http://www.w3.org/Payments/IG/">Web Payments Interest Group</a>
-for discussions about and contributions to this document, as well as the
-<a href="https://www.w3.org/community/webpayments/">Web Payments Community
-Group</a> for earlier work that informed this document.
-    </p>
-  </section>
-
-  </body>
-</html>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/latest/requirements/browser_security_notes.txt	Mon Jun 29 13:24:18 2015 +0200
@@ -0,0 +1,97 @@
+https://www.youtube.com/watch?v=zKuFu19LgZA
+
+1       6:01    Deterrence is not effective….only prevention
+2       8:37    Confusion and Errors coming from multiple languages….a fact of life.
+3      15:38    Military Crypto…electronic….1850’s    point to point.
+4      17:03    Key exchange by previous arrangement necessary
+5      17:50    Engine must be open….algorithms execution for example
+6      18:37    Security by obscurity isn’t
+7      18:50    Keys must be secret
+8      19:30    One time Pad discussion
+9      22:41    Crypto by itself is not security
+10.    28:00    Do it right the first time
+11.    35:00    W3C specification for browser is horribly wrong
+12.    39:07    Encrypted code protects from injections or changes
+13.    42:18    Object Capabilities….Java script
+14.    52:25    Never trust the browser
+15.    52:26    Encode/encrypt all inputs and outputs
+16.    52:27    Context is everything.
+ 
+
+- There is no security in obscurity
+- The more secrets you have the harder they are to keep
+- No secrets inside the encryption machine. Assume the enemy finds out how it works, let having them know how it works doesnt compromise the security of the system. To be confident in the security publish it.
+- Making it hard to find isnt good enough
+- Only thing to keep secret is the keys, not the algorithms
+- Never reuse the same key
+- Cryptography isnt security.
+- Security needs to be factored into every decision
+- We will go back and make it secure later, NOOOOO. This is the hardest part. Not wait for 2.0.
+- You cant add security, just as you cant add reliability. Insecurity and unreliability must be removed. You cant add security, you can only remove insecurity
+- If you have published a platform and people have used in an insecure way, its difficult to then remove those features, because they are inherently insecure, and replace them with more reliable features. You just cant to that without causing big breakage. You need to fix it before you release it.
+- Having been secure to this point doesnt guarantee we wont be hackled. As we become more successful, as our business grows, we will become a bigger target and they will come after us.
+- Do not try and do things that wont be effective.
+- We cant stop them but we can slow them down? Speed bumps wont stop them so put your resources to do something more effective.
+- Dont prohibit what you cant prevent. Bad actors will exploit whatever you cant prevent.
+- False security is worse than no security (unnecessary expense and confusion of risk. Will make bad judgements based on false assumptions). Pursuing false security means you are not pursuing better forms of security.
+
+
+
+The browser platform
+- Horribly insecure
+- Still "fixing it later"
+- HTML5 made it worse than better (Powerful new capabilities but not constraning the ability of bad guys to get at those new capabilities)
+- The JavaScript global object -- or the window object as it's called in the browsers -- gives every scrap of script the same set of powerful capabilities, so there's no way a page can defend itself from any other script that happens to get into that page. 
+- Never trust the browser. The server should never trusted the browser to enforce policies. The browser cannot and will not protect your interests. You must properly filter and validate everything that comes from the browser.
+- A malicious party can exploit coding conventions to inject malicious code.
+- Malicious code gets all the same permissions as the site
+- Who's interest does the Browser represent? (for browser its the website its showing). It turns out there are more interests involved than the users and the sites. There can be third parties, and fourth parties, and many other parties on the same page. A malicious party can exploit code conventions to inject malicious code onto the page, and that code gets all of the rights of the site. This can compromise the site and the user.
+- So what can an attacker do if he can get some script onto your page? 
+   - The attacker can request additional scripts from any server in the world. Once it gets a foothold -- and it only needs a tiny amount of code to do that -- it can obtain all the additional scripts it wants from the most evil websites in the world. The browser has the same origin policy that limits the ability of a page to interact with other sites, but it in no way limits the ability of an attacker to get more script to run on your page.
+   - An attacker can read the document. The attacker can see everything the user can see and a lot of the things the user can't see. It can see hidden fields, comments, cookies, all sorts of stuff which is invisible on the page.
+   - The attacker can make requests of your server, and your server cannot detect that the requests did not originate from your application. Now, you should be using SSL to secure your connections, but if you do, it doesn't help you here because the attacker gets access to your secure connections. You should be authenticating your requests from the browser with a special token, sometimes called a crumb .. that doesn't help. The attacker has access to that as well.
+   - If your server accepts SQL queries then the attacker gets direct access to your database, and can do anything that SQL will allow them to do. Now, if your server application is creating SQL queries by concatenating together pieces of material that it gets from the browser, then you probably gave access to the attacker to your database, because SQL was optimized for SQL injection attacks.
+   - The attacker has control over the display and can request additional information from the user, and the user cannot detect that the request did not originate from your application. The browsers all have anti-phishing chrome in them now. The problem with it is that the users don't pay any attention to it. If they did, the chrome would be saying this is a legit request, go ahead and give it. Because what the browser is looking for is where the HTML came from, not where the script came from, and it's the script that's evil here.
+      - Some sites, whenever something scary is about the happen, think okay, let's make sure that the user is still on board, so let's ask for their password again. That doesn't help you in this case because the attacker has control of the screen, so he can go to the user and say what's your password, and everything tells the user that this is a legitimate request: give it up. In fact, if your site routinely asks the user to give up their password at unlikely times, what you're doing is training the users to give up the password anytime an attacker asks for it.
+   - The attacker can then send the information that it obtained by talking to your servers or scraping the page or talking to the user and send it to any server in the world. Again, there's the same origin policy in the browser, which does not limit the ability of the attacker to send this information to the most evil site on the planet.
+   - The above types of attacks are called XSS (Cross site scripting). Cross site scripting attacks were invented in 1995 yet we havent made any progress on the fundamental problem since then.
+   - The browser does not prevent any of these, and web standards require these weaknesses. If your browser does not expose your site and your users to all of these problems, it is not standards compliant. There's something deeply wrong in the W3C standards. To make the browser secure means breaking those W3C standards and that's going against the 'standards politicians'.
+- The consequences of an attack are horrible. 
+   - Harm to customers
+   - Loss of trust
+   - Legal liabilities. There's even been talk about criminal liabilities, because of negligence of a browser standard knowingly exposing people to harm.
+- A mashup is a self-inflicted XSS attack. Mashups are great. It's a way of creating an application of components that come from several independent parties and are letting them work together for the user's benefit. But they're not safe as currently practiced in the browser.
+- Why is there XSS?
+   - The web stack is too complicated
+   - Template based web frameworks are optimized for XSS injection.
+   - The JavaScript global object -- or the window object as it's called in the browsers -- gives every scrap of script the same set of powerful capabilities, so there's no way a page can defend itself from any other script that happens to get into that page.
+- The browser distinguishes between the interests of the user and the site, but didn't anticipate that there could be other interests represented. (Such as hardware, secure element, payment processors, cloud storage, etc.)
+- Within a page, interests are confused, and an ad, or a widget, or an Ajax library, they all get the same rights as your own script. You hope if you're loading jQuery, there's nothing to prevent jQuery from deciding we're going to go rogue today and start harvesting identities. If you're loading external stuff, it will happen.
+- These security issues will not get fixed in a hurry so its up to the application developers to create secure applications on an insecure platf
+  NOTE: This is why Paypal is successful because its an application written around the insecurities. How to deliver Paypal features on a public browser?
+- The principle of least authority - Any unit of software should be given just the capabilities it needs to do its work, and no more. Problem with browser gives capabilities to all of the scripts. Objects should be granted capabilities on a need-to-do basis.
+- Instead of trying to guess if code can do something bad, try granting it a safe capability. Most code should never be granted access to Window, Document, or innerHTML.
+- The JavaScript language doesn't match our expectations of what a traditional language provides. The fact that the language doesn't match our expectations is what leads us into these sorts of problems. Confusion is a bad thing. Confusion causes bugs, confusion gets in the way of reliability, also gets in the way of security. Confusion aids the enemy. Bugs are a manifestation of confusion. With great complexity comes great confusion. It's hard enough to reason about what our programs do just in terms of their functionality, but now we have a whole 'nother level of reasoning we have to do, so in order to have any hope of being able to do that effectively we need to keep our designs as clean and as simple as we can because complicated, busy designs are difficult to reason about. Overriding the push method of an array object myarray['push'] = function() {};
+
+
+Lazy's Programmers Guide to Secure Computing by Marc Steigler
+
+
+   
+- Browser is still better than everything else. All other application platforms and application delivery systems are strictly worse than the web. The reason for that is their blame the victim security model. One thing all those systems have in common that the web does not do is ask questions of the user about what a program should be able to do, and generally ask them in a way that the user cannot answer them correctly.  All that accomplishes is that when the thing finally goes wrong, you can say well, it's your fault, you agreed to this.
+
+
+
+Security lessons learned from using a web enabled technology in a secure application:
+  - Dont expose the window or document object to everyone. These 2 objects are the source of most insecurity. NOTE: This will break 99.99% of existing JavaScript libraries, like jQuery, because all of those modules assume window and document are global objects.
+  - Dont iterate the window and document object's to expose its members as globals that any JavaScript can get at.
+  - Make a JavaScript classing system that uses closures to protect private members inside of closures. Very much like C++ private, protected, and public members. Use the private to protect access.
+  - All HTML elements on the page must be protected against direct accessibility as well. If you grab a reference to any HTML element you can walk that element back to the document and window parents.
+  - Use a 'shadow document' or 'shadow window' object. Only expose the bare functionality required.
+  - Use Object.freeze(myObject); to prevent existing JavaScript objects from being hijacked for malicious intent.
+  - Asynchronous module loading, like require() is dangerous.
+     - Use a native version require() that allows you to enforce the use of a manifest system to ensure only authorized dependencies are loaded.
+     - All dependencies are loaded at loadtime not runtime. Any require() that is done at runtime only returns the reference to the existing loaded module. If the module wasnt loaded before this point an exception is thrown.
+     - Manifest should utilize a SHA2 hash to verify the loaded modules are the correct intended files.
+     - Native require() should never allow a fully qualified domain name to be specified. FQDN are only specified in the manifest.
+  - Create a separate JavaScript context and load all trusted JavaScript that is allowed access to insecure interfaces like window, document, HTML5 interfaces like file access, sockets, etc.
--- a/latest/roadmap/index.html	Mon Jun 22 12:58:40 2015 +0200
+++ b/latest/roadmap/index.html	Mon Jun 29 13:24:18 2015 +0200
@@ -182,28 +182,179 @@
     <h2>Version 1</h2>
 
     <p>
-The initial implementation of the Web Payments work will focus on delivering
-standards for a Minimum Viable Platform (MVP) by December 2017.
+The initial implementation of the Web Payments work will start in October 2015
+and will focus on delivering standards for a Minimum Viable Platform (MVP)
+by December 2017.
     </p>
 
     <section>
       <h3>Goals</h3>
       <ul>
         <li>
-Lower cost of integration of payment services via standard wallet
-(payment agent) APIs.
+<strong>Payment ecosystem integration</strong>: Interoperable support for a
+simple payment scenario. This includes the steps of 1) invoking a payment
+request, 2) selecting a payment instrument, 3) initiating funds transfer,
+and 4) delivering a proof of payment.
         </li>
         <li>
-Lower cost of satisfying Know Your Customer (KYC) requirements when
-performing payments.
-        </li>
-        <li>
-Increased usability, privacy, and security for users.
+<strong>Security</strong>: Digital signatures, encryption, and
+multi-factor authentication.
         </li>
       </ul>
     </section>
+
     <section>
-      <h3>Implementation Plan</h3>
+      <h3>Use Cases</h3>
+      <p>
+The following use cases are in scope for version 1 with specific limitations
+expressed beside each use case:
+      <table>
+        <thead>
+          <tr>
+            <th style="white-space: nowrap;">Use Case</th>
+            <th style="white-space: nowrap;">Notes</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-website">Website</a>
+            </td>
+            <td>
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-registrationless">Registration-less</a>
+            </td>
+            <td>
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-one-time-payment">One Time Payment</a>
+            </td>
+            <td>
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-ubiquitous">Ubiquitous Schemes</a>
+            </td>
+            <td>
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-discovery">Discovery</a>
+            </td>
+            <td class="align-left">
+<span class="issue">Unclear about how much wallet/payment instrument
+discovery flexibility should be in version 1.</span>
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-payer-privacy">Payer Privacy</a>
+            </td>
+            <td class="align-left">
+The use case where the payer shares a subset of their payment instruments
+with the payee before the purchase is not in scope for this version.
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-manual-selection">Manual Selection</a>
+            </td>
+            <td>
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-password">Password Authentication</a>
+            </td>
+            <td>
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-multifactor">Multifactor Authentication</a>
+            </td>
+            <td class="align-left">
+Stretch goal for version 1 with a focus on FIDO-based authentication and 
+mobile phone-based fingerprint authentication.
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-payee-initiated">Payee-initiated</a>
+            </td>
+            <td>
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-payer-initiated">Payer-initiated</a>
+            </td>
+            <td>
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-proofs">Proofs</a>
+            </td>
+            <td class="align-left">
+Very basic proof of initiation of funds transfer for version 1.
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-virtual-goods">Virtual Goods</a>
+            </td>
+            <td>
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-physical-goods">Physical Goods</a>
+            </td>
+            <td>
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-electronic-receipts">Electronic Receipts</a>
+            </td>
+            <td class="align-left">
+Very basic receipt container and delivery protocol for version 1.
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-subscription">Subscription</a>
+            </td>
+            <td class="align-left">
+Stretch goal for version 1.
+            </td>
+          </tr>
+          <tr>
+            <td class="align-left">
+<a href="../use-cases/index.html#uc-refund">Basic Refund</a>
+            </td>
+            <td class="align-left">
+Stretch goal for version 1.
+            </td>
+          </tr>
+        </tbody>
+      </table>
+    </section>
+
+    <section>
+      <h3>Capabilities</h3>
+      <p class="issue">
+This section is out of date and needs to be re-aligned with the latest
+capabilities document.
+      </p>
       <p>
 The following table shows the capabilities for this version, with annotations
 about where those capabilities arise in the payment flow and which groups will
@@ -339,79 +490,97 @@
       </p>
     </section>
     <section>
-      <h3>Groups</h3>
+      <h3>Groups and Scope</h3>
       <p>
 A list of relevant groups that will participate in the first iteration of
 specification creation.
       </p>
-      <ul class="note">
-        <li>
-We may not develop requirements for all these groups.
-        </li>
-        <li>
-There are additional groups where we will have dependencies or liaisons and
-individual charters will address them.
-        </li>
-      </ul>
-      <ul>
-        <li>Payments
+
+      <table>
+        <thead>
+          <tr>
+            <th style="white-space: nowrap;">Group</th>
+            <th style="white-space: nowrap;">Scope</th>
+            <th style="white-space: nowrap;">Charter</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td>
+<a href="http://www.w3.org/Payments/IG/">Web Payments Interest Group</a>
+            </td>
+            <td>
+Continued development of use cases and requirements for version 2.
+Liason between larger W3C community and other relevant standards bodies.
+            </td>
+            <td>
+<a href="http://www.w3.org/2014/04/payments/webpayments_charter.html">
+October 2014 - December 2017</a>
+            </td>
+          </tr>
+          <tr>
+            <td>
+Web Payments Working Group
+            </td>
+            <td>
+Invoking a payment request, selecting a payment instrument, initiating funds
+transfer, delivering a proof of payment.
+            </td>
+            <td>
+<a href="https://www.w3.org/Payments/IG/wiki/Roadmap/PaymentArchitectureWG">
+Draft Charter
+</a>
+            </td>
+          </tr>
+          <tr>
+            <td>
+Web Authentication Working Group
+            </td>
+            <td>
+Secure authentication of entities (users, systems and devices) to enable
+high-security Web applications. Based on FIDO Alliance work.
+            </td>
+            <td>
+No charter yet
+            </td>
+          </tr>
+          <tr>
+            <td>
+Hardware-based Security Working Group
+            </td>
+            <td>
+A set of Hardware-Based Web Security standard services providing Web
+Applications usage of secure services enabled by hardware modules
+(Trusted Execution Environments, Secure Elements, and other secure enablers).
+            </td>
+            <td>
+No charter yet.
+            </td>
+          </tr>
+        </tbody>
+      </table>
+
+      <p class="issue">
+It is currently unknown whether or not a Credentials WG or Linked Data
+Security WG will be created.
+      </p>
+
+          <li>
+Related W3C Groups
           <ul>
           <li>
-<a href="https://www.w3.org/Payments/IG/">Web Payments IG</a> (industry use cases and requirements as input to these various groups)
-          </li>
-          <li>
-Payment WG (see <a href="https://www.w3.org/Payments/IG/wiki/Roadmap/PaymentArchitectureWG">draft charter</a>)
-          </li>
-          </ul>
-          </li>
-          <li>
-Credentials (linking real-world identities to Web identities)
-          <ul>
-          <li>
-Web Credentials WG (see <a rel="nofollow" class="external text" href="https://docs.google.com/document/d/1xfdzFahQpaQKGL4aOvePlIdsJO6Q5OJkPgSIxtUx9Vc/edit">draft charter</a>)
-          </li>
-          </ul>
+Technical Architecture Group (TAG) (for reviews related to Web Architecture)
           </li>
           <li>
-Authentication
-          <ul>
-          <li>
-FIDO-based authentication Working Group
-          <ul>
-          <li>
-Addresses enrollment and framework for two-factor authentication (allows various approaches).
-          </li>
-          <li>
-May have a dependency on WebAppSec work
-          </li>
-          </ul>
-          </li>
-          <li>
-Hardware-based authentication Working Group
+Security IG (for reviews about security)
           </li>
-          </ul>
-          </li>
-          <li>
-Security
-          <ul>
-          <li>
-Still unknown: encryption, signature, key management requirements for Web App Security WG and Web Crypto WG?
-          </li>
-          <li>
-Linked Data Security WG
-          </li>
-          </ul>
-          </li>
-          <li>
-Related Interest Groups
-          <ul>
           <li>
 Privacy IG (for reviews about sharing of sensitive information)
           </li>
           </ul>
           </li>
           <li>
-Related Community Groups
+Related W3C Community Groups
           <ul>
           <li>
 Credentials
--- a/latest/use-cases/index.html	Mon Jun 22 12:58:40 2015 +0200
+++ b/latest/use-cases/index.html	Mon Jun 29 13:24:18 2015 +0200
@@ -268,12 +268,11 @@
 A title and short description.
         </li>
         <li>
-Goals. How the use case advances one or more of the
-<a href="https://www.w3.org/Payments/IG/wiki/ExecSummary#Goals">goals
-for an interoperable Web payments framework</a>.
+A <em>Target version</em> which specifies the intended version of the Web
+Payments Architecture that will enable the use case.
         </li>
         <li>
-Motivation. This is commentary to help explain why the use
+A short <em>Motivation</em> statement to help explain why the use
 case has been included, including how it relates to similar use cases.
         </li>
       </ul>
@@ -288,15 +287,19 @@
 case.
         </li>
         <li>
+Accessibility. Accessibility considerations (e.g., in multi-factor
+authentication, management of biometrics in the case of users with some
+disabilities).
+        </li>
+        <li>
+Regulatory. Regulatory considerations (e.g., anti-money laundering
+clearing, suspicious activity reporting, tax collection, trade compliance).
+        </li>
+        <li>
 Exceptions. Considerations in the case of specific exceptions (e.g., if a
 user pays with a voucher and the <a>transaction</a> fails, the user's voucher
 should be restored).
         </li>
-        <li>
-Accessibility. Accessibility considerations (e.g., in multi-factor
-authentication, management of biometrics in the case of users with some
-disabilities).
-        </li>
       </ul>
 
       <p class="issue">
@@ -308,13 +311,6 @@
 X9 Security subgroups, and ISO security subgroups.
       </p>
 
-      <p>
-The Interest Group (currently) regards some of the use cases as "essential" to
-addressing their
-<a href="https://www.w3.org/Payments/IG/wiki/ExecSummary#Goals">goals</a> and
-others as "non-essential."
-      </p>
-
       <p class="note">
 All character names appearing in this document are fictitious. Any resemblance
 to real persons, living or dead, is purely coincidental. Some organizations,
@@ -793,14 +789,12 @@
           <dd>
 Penny uses the HobbyCo website to select a $15 model train for <a>purchase</a>.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
           <dt>Motivation</dt>
           <dd>
-This is the most common type of offer on the Web circa 2015 and is included
-for the sake of completeness.
+A human being seeing a visual offer of sale on a website is the most common
+way offers are discovered on the Web today (2015).
           </dd>
         </dl>
 
@@ -811,10 +805,8 @@
 all of the items he wants to <a>purchase</a> at the automated kiosk, requests
 a cash back amount, and is presented with a total amount.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience, and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 Unifying point of sale interaction w/ the Web Payments architecture is
@@ -851,11 +843,8 @@
 touch their mobile devices to each other. The total appears on Hani's mobile
 device.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience, Greater security, Innovation, Automatability, and
-rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 Unifying the way proximity mobile offers work with the Web Payments
@@ -881,10 +870,8 @@
 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.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience, Innovation, and Transparency.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 Many of the very successful games these days run on the freemium model,
@@ -894,201 +881,166 @@
           </dd>
         </dl>
 
-        <section>
-          <h5>Non-Essential Use Cases</h5>
-
-          <dl id="uc-email" class="dl-horizontal">
-            <dt>E-mail</dt>
-            <dd>
+        <dl id="uc-email" class="dl-horizontal">
+          <dt>E-mail</dt>
+          <dd>
 A GroupBuyCo customer receives an offer by email to <a>purchase</a> the deal
 of the day.
-            </dd>
-            <dt>Goals</dt>
-            <dd>
-Improved user experience, and Automatability.
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
+          </dd>
+          <dt>Target version</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
 Unifying how people initiate payments from email, at a point of sale,
 and via a Web site will help ensure the ubiquity of the Web payment
 technology platform.
-            </dd>
-            <dt>Privacy / Security</dt>
-            <dd>
+          </dd>
+          <dt>Privacy / Security</dt>
+          <dd>
 It is important to recognize that initiating a payment from within an
 email application could lead to a wholly new category of phishing/fraud.
-            </dd>
-          </dl>
+          </dd>
+        </dl>
 
-          <dl id="uc-hold-funds" class="dl-horizontal">
-            <dt>Hold Funds</dt>
-            <dd>
+        <dl id="uc-hold-funds" class="dl-horizontal">
+          <dt>Hold Funds</dt>
+          <dd>
 Renne checks into a hotel and is asked for a deposit for any damages
 to the room.
-            </dd>
-            <dt>Goals</dt>
-            <dd>
-Improved user experience, Increased user choice, and rapid, widespread adoption.
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
+          </dd>
+          <dt>Target version</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
 Some <a title="transaction">transactions</a>, such as a hold of funds,
 do not always reach completion and are primarily used
 to protect the <a>payee</a> from negligence on the part of the
 <a>payer</a> (e.g., such as a <a>payer</a> damaging a hotel room).
-            </dd>
-            <dt>Exceptions</dt>
-            <dd>
+          </dd>
+          <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.
-            </dd>
-          </dl>
+          </dd>
+        </dl>
 
-          <dl id="uc-preauth" class="dl-horizontal">
-            <dt>Pre-authorization</dt>
-            <dd>
+        <dl id="uc-preauth" class="dl-horizontal">
+          <dt>Pre-authorization</dt>
+          <dd>
 Krishna pulls up to a pump at a petrol station. His in-vehicle application
 recognizes the station location and the pump. The pump communicates which
 fuels it has and their price in an offer. Krishna's car asks if he wants to
 approve a fill up for up to €35.
-            </dd>
-            <dt>Goals</dt>
-            <dd>
-Improved user experience, Greater security, Innovation, Transparency,
-Automatability, and rapid, widespread adoption.
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
+          </dd>
+          <dt>Target version</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
 Some offers are not aware of the final price but would rather set limits on
 the amount of the <a>purchase</a> before a particular metered good or service is
 delivered.
-            </dd>
-            <dt>Privacy</dt>
-            <dd>
+          </dd>
+          <dt>Privacy</dt>
+          <dd>
 Due to the sensitivity of location data, individuals should be able to make
 small fuel <a title="purchase">purchases</a> in a way that respects their privacy.
-            </dd>
-            <dt>Security</dt>
-            <dd>
+          </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).
-            </dd>
-          </dl>
+          </dd>
+        </dl>
 
-          <dl id="uc-machine-readability" class="dl-horizontal">
-            <dt>Machine Readability</dt>
-            <dd>
+        <dl id="uc-machine-readability" class="dl-horizontal">
+          <dt>Machine Readability</dt>
+          <dd>
 BigBoxCo expresses their entire product catalog online as machine-readable
 information so that SearchCo may index their content more easily and direct
 more customer traffic to BigBoxCo's website.
-            </dd>
-            <dt>Goals</dt>
-            <dd>
-Increased user choice, Improved user experience, Innovation, Lower Costs,
-Transparency, Automatability, Portability, Monetization,
-and rapid, widespread adoption.
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
+          </dd>
+          <dt>Target version</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
 Machine-readable offers will have a direct positive impact on store sales
 if they are indexed by search engines.
-            </dd>
-          </dl>
+          </dd>
+        </dl>
 
-          <dl id="uc-live-prices" class="dl-horizontal">
-            <dt>Live Market Prices</dt>
-            <dd>
+        <dl id="uc-live-prices" class="dl-horizontal">
+          <dt>Live Market Prices</dt>
+          <dd>
 EnergyCo lists barrels of refined oil for sale on their website based on an
 algorithm that uses the cost of coal and crude oil as inputs. EnergyCo
 guarantees their prices for up to 24 hours from the posting date.
-            </dd>
-            <dt>Goals</dt>
-            <dd>
-Increased user choice,
-Improved user experience,
-Innovation,
-Transparency, and
-Automatability
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
+          </dd>
+          <dt>Target version</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
 The ability to express a non-repudiable offer as the basis of a legally
 enforceable contract will reduce <a>transaction</a> friction.
-            </dd>
-          </dl>
+          </dd>
+        </dl>
 
-          <dl id="uc-trialware" class="dl-horizontal">
-            <dt>Trial-ware</dt>
-            <dd>
+        <dl id="uc-trialware" class="dl-horizontal">
+          <dt>Trial-ware</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
 to play further levels.
-            </dd>
-            <dt>Goals</dt>
-            <dd>
-Improved user experience,
-Monetization,
-and rapid, widespread adoption.
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
+          </dd>
+          <dt>Target version</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
 There is a fairly large trial-ware 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>
-          </dl>
+          </dd>
+        </dl>
 
-          <dl id="uc-vehicle" class="dl-horizontal">
-            <dt>In-vehicle</dt>
-            <dd>
+        <dl id="uc-vehicle" class="dl-horizontal">
+          <dt>In-vehicle</dt>
+          <dd>
 Jeff listens to a lot of music on the way to work. The music station
 serves a digital offer along with the music stream. This enables Jeff to
 easily buy music that he really likes.
-            </dd>
-            <dt>Goals</dt>
-            <dd>
-Improved user experience,
-Innovation,
-Monetization,
-and rapid, widespread adoption.
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
+          </dd>
+          <dt>Target version</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
 Car manufacturers and the entertainment industry may be interested in
 extending their sales channels into vehicles.
-            </dd>
-            <dt>Accessibility</dt>
-            <dd>
+          </dd>
+          <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.
-            </dd>
-          </dl>
+          </dd>
+        </dl>
 
-          <dl id="uc-memorable-ids" class="dl-horizontal">
-            <dt>Memorable Ids</dt>
-            <dd>
+        <dl id="uc-memorable-ids" class="dl-horizontal">
+          <dt>Memorable Ids</dt>
+          <dd>
 Vern sends money to his friend Milena by typing in Milena's mobile phone number
 and the amount he wants to send.
-            </dd>
-            <dt>Goals</dt>
-            <dd>
-Improved user experience,
-Innovation,
-Monetization,
-and rapid, widespread adoption.
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
+          </dd>
+          <dt>Target version</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
 Some countries, like the United Kingdom, maintain registries that map
 memorable identifiers like mobile phone numbers to bank accounts. These
 memorable payment identifiers can be used to transmit money from person to
 person using direct bank to bank transfers.
-            </dd>
-          </dl>
+          </dd>
+        </dl>
 
-        </section>
       </section>
 
       <section>
@@ -1096,6 +1048,78 @@
         <p>
         </p>
 
+        <dl id="uc-one-time-payment" class="dl-horizontal">
+          <dt>One-time Payment</dt>
+          <dd>
+Jamie wishes to pay for a single article from a market analyst.
+          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
+          <dt>Motivation</dt>
+          <dd>It should be clear to a
+<a title="payer">payer</a> whether a
+<a>purchase</a> is one-time or recurring, prior to initiation of
+the payment.
+          </dd>
+        </dl>
+
+        <dl id="uc-registrationless" class="dl-horizontal">
+          <dt>Registration-less</dt>
+          <dd>
+Some <a title="payee">payees</a> would rather not require a <a>payer</a> to
+register at their site before initiating a purchase:
+            <ul>
+              <li>
+Sven wants to view a pay to read article and does so without needing to
+pre-register with the website.
+              </li>
+              <li>
+Reiko finds a blowtorch for sale at a local digital resale website and
+places money into escrow without needing to register with the website.
+              </li>
+              <li>
+Olaseni is listening to music in a local coffee shop and likes a song he hears.
+He initiates a purchase of the song from the local "music beacon" without
+needing to register with the coffee shop or the music service.
+              </li>
+            </ul>
+          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
+          <dt>Motivation</dt>
+          <dd>
+There are a large number of "paywall" websites on the Web that require a
+customer to register before they may use the website. In many cases, if the
+site isn't regularly visited by the customer, they abandon the transaction
+when they see the paywall requirement. Providing a mechanism to sell an
+inexpensive item to a customer without requiring registration would be of
+great benefit to not only the merchants selling goods and services, but
+customers that would like to avoid lengthy registration processes.
+          </dd>
+          <dt>Accessibility</dt>
+          <dd>
+People who are on the Autistic spectrum may require trust with the merchant
+to be established through a more formal means to prevent distress and
+abandonment of the transaction.
+          </dd>
+        </dl>
+
+        <dl id="uc-subscription" class="dl-horizontal">
+          <dt>Subscription</dt>
+          <dd>
+Larissa subscribes to a site that provides a monthly analysis of the world
+of finance.
+          </dd>
+          <dt>Target version</dt>
+          <dd>1.0 (if time permits)</dd>
+          <dt>Motivation</dt>
+          <dd>
+<a title="payer">Payers</a> should be able to understand if a
+particular <a>purchase</a> is a recurring payment prior to initiating
+the payment.
+          </dd>
+        </dl>
+
         <dl id="uc-credentials" class="dl-horizontal">
           <dt>Credentials</dt>
           <dd>
@@ -1122,16 +1146,8 @@
               </li>
             </ul>
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience,
-Greater security,
-Regulatory acceptance,
-Innovation,
-Transparency,
-Automatability, and
-Portability.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 There are certain types of  <a title="purchase">purchases</a> that cannot
@@ -1157,10 +1173,8 @@
 require Tibor's name, email address, or any other personally identifying
 information to complete the <a>transaction</a>.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience, and Greater security.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 Certain low-value <a>transaction</a>s shouldn't require the
@@ -1183,10 +1197,8 @@
 would like to reduce the amount of information that's transmitted to the
 <a>payee</a> while ensuring that PayCo complies with regulations.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Greater security, and Regulatory acceptance.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 There are types of information, such as personally identifiable information,
@@ -1197,39 +1209,25 @@
           </dd>
         </dl>
 
-        <dl id="uc-one-time-payment" class="dl-horizontal">
-          <dt>One-time Payment</dt>
-          <dd>
-Jamie wishes to pay for a single article from a market analyst.
-          </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience
-          </dd>
-          <dt>Motivation</dt>
-          <dd>It should be clear to a
-<a title="payer">payer</a> whether a
-<a>purchase</a> is one-time or recurring, prior to initiation of
-the payment.
-          </dd>
-        </dl>
-
         <dl id="uc-invoices" class="dl-horizontal">
           <dt>Invoices</dt>
           <dd>
+There are a large variety of invoices that are used in the world:
+<ul>
+  <li>
 Sunan goes to SuperVoices to download a voiceover that he commissioned for
 his new pet sitting service. SuperVoices generates a detailed invoice for the
 service and provides it to Sunan.
+  </li>
+  <li>
+João is given an electronic
+<a href="https://en.wikipedia.org/wiki/Boleto">Boleto</a> by
+a technology website to pay for a new laptop.
+  </li>
+</ul>
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience,
-Greater security,
-Transparency,
-Automatability,
-Portability, and
-Monetization.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 For certain <a title="payment scheme">payment schemes</a>, the <a>payer</a>
@@ -1238,97 +1236,25 @@
           </dd>
         </dl>
 
-        <section>
-          <h5>Non-essential Use Cases</h5>
-
-          <dl id="uc-subscription" class="dl-horizontal">
-            <dt>Subscription</dt>
-            <dd>
-Larissa subscribes to a site that provides a monthly analysis of the world
-of finance.
-            </dd>
-            <dt>Goals</dt>
-            <dd>
-Improved user experience,
-Transparency, and
-Automatability.
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
-<a title="payer">Payers</a> should be able to understand if a
-particular <a>purchase</a> is a recurring payment prior to initiating
-the payment.
-            </dd>
-          </dl>
-
-          <dl id="uc-registrationless" class="dl-horizontal">
-            <dt>Registration-less</dt>
-            <dd>
-Some <a title="payee">payees</a> would rather not require a <a>payer</a> to
-register at their site before initiating a purchase:
-              <ul>
-                <li>
-Sven wants to view a pay to read article and does so without needing to
-pre-register with the website.
-                </li>
-                <li>
-Reiko finds a blowtorch for sale at a local digital resale website and
-places money into escrow without needing to register with the website.
-                </li>
-                <li>
-Olaseni is listening to music in a local coffee shop and likes a song he hears.
-He initiates a purchase of the song from the local "music beacon" without
-needing to register with the coffee shop or the music service.
-                </li>
-              </ul>
-            </dd>
-            <dt>Goals</dt>
-            <dd>
-Improved user experience,
-Greater security,
-Innovation, and
-Automatability
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
-There are a large number of "paywall" websites on the Web that require a
-customer to register before they may use the website. In many cases, if the
-site isn't regularly visited by the customer, they abandon the transaction
-when they see the paywall requirement. Providing a mechanism to sell an
-inexpensive item to a customer without requiring registration would be of
-great benefit to not only the merchants selling goods and services, but
-customers that would like to avoid lengthy registration processes.
-            </dd>
-            <dt>Accessibility</dt>
-            <dd>
-People who are on the Autistic spectrum may require trust with the merchant
-to be established through a more formal means to prevent distress and
-abandonment of the transaction.
-            </dd>
-          </dl>
-
-          <dl id="uc-full-disclosure" class="dl-horizontal">
-            <dt>Full Disclosure</dt>
-            <dd>
+        <dl id="uc-full-disclosure" class="dl-horizontal">
+          <dt>Full Disclosure</dt>
+          <dd>
 Marge wishes to renew her passport online which requires transmission
 of a fee and a great deal of information about her real-world identity.
-            </dd>
-            <dt>Goals</dt>
-            <dd>
-Improved user experience.
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
+          </dd>
+          <dt>Target version</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
 Some <a>transaction</a>s will require very sensitive personally identifiable
 information to be transmitted by the <a>payer</a>.
-            </dd>
-            <dt>Privacy / Security</dt>
-            <dd>We must ensure adequate security for these highly sensitive
-	      transactions to reduce the likelihood of phishing attacks.</dd>
-          </dl>
-        </section>
+          </dd>
+          <dt>Privacy / Security</dt>
+          <dd>We must ensure adequate security for these highly sensitive
+      transactions to reduce the likelihood of phishing attacks.</dd>
+        </dl>
 
-      </section>
+    </section>
 
       <section>
         <h4>Application of Marketing Elements</h4>
@@ -1342,10 +1268,8 @@
 <a title="purchase">purchases</a>. The offer takes the form of a coupon that
 may be applied during payment.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Automatability and Portability.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 Providing a mechanism to apply digital coupons before a payment is initiated
@@ -1361,10 +1285,8 @@
 gives him a discount on gas  <a title="purchase">purchases</a> performed at the
 FoodCo gas station.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience and Portability.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 Loyalty cards may be used at multiple locations to effect the price of a
@@ -1382,15 +1304,8 @@
 a new store credit card is placed in her payment application on her mobile
 phone.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Increased user choice,
-Improved user experience,
-Automatability,
-Portability,
-Monetization,
-and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 Merchants often provide discounts to customers if they sign up for a
@@ -1419,20 +1334,12 @@
 A game store Web site accepts payment via credit card, e-cheque, and
 operator billing.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Increased user choice,
-Improved user experience,
-Minimal standardization,
-Lower Costs,
-Automatability,
-and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
           <dt>Motivation</dt>
           <dd>
-We have a goal for the Web payment architecture to support existing
-ubiquitous <a title="payment scheme">payment schemes</a> without
-changes to how they operate.
+Ubiquitous <a title="payment scheme">payment schemes</a> should be supported
+without changes to how the schemes or payment instruments operate.
           </dd>
         </dl>
 
@@ -1441,15 +1348,8 @@
           <dd>
 CrowdFundCo supports Bitcoin, Ripple, Google Wallet, and PayPal.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Increased user choice,
-Improved user experience,
-Minimal standardization,
-Lower Costs,
-Automatability,
-and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 The same mechanism used to support existing
@@ -1472,19 +1372,15 @@
 cloud (but on different websites), and one on his smart watch. Each one has
 a credit card that he may want to use for a credit card-based <a>purchase</a>.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Increased user choice,
-Improved user experience,
-Automatability,
-Portability,
-and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
           <dt>Motivation</dt>
           <dd>
 A <a>payer</a> will most likely use multiple digital wallets over time. It is
 important to ensure that the wallets that they use are presented to them in a
 consistent manner across devices.
+<span class="issue">The amount of wallet/payment instrument discovery
+flexibility that version 1.0 should support is currently unknown.</span>
           </dd>
           <dt>Accessibility</dt>
           <dd>
@@ -1500,6 +1396,39 @@
           </dd>
         </dl>
 
+        <dl id="uc-payer-privacy" class="dl-horizontal">
+          <dt>Payer Privacy</dt>
+          <dd>We anticipate a range of privacy scenarios:
+            <ul>
+                <li>
+Lucio sends information about instruments he is willing to use to
+TrustedMerchant, who provides a discount for access to his information.
+              </li>
+                <li>
+Carla does not want to share information about the
+<a title="payment instrument">payment instruments</a> she uses with any
+merchants, so that information is not shared with any online merchants.
+              </li>
+            </ul>
+          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
+          <dt>Motivation</dt>
+          <dd>
+Sharing or protecting data on the sorts of
+<a title="payment instrument">payment instruments</a> available to
+a <a>payer</a> should be a decision made by the <a>payer</a>.
+          </dd>
+          <dt>Privacy / Security</dt>
+          <dd>
+The types of <a title="payment instrument">payment instruments</a> available
+to a <a>payer</a> could be
+used to digitally fingerprint a <a>payer</a> even if they were using an
+pseudo-anonymous payment mechanism. Merchants and <a>payee</a>s may be legally
+obligated to protect this kind of <a>payer</a> payment information.
+          </dd>
+        </dl>
+
         <dl id="uc-manual-selection" class="dl-horizontal">
           <dt>Manual Selection</dt>
           <dd>In many cases, the <a>payer</a> will select a payment instrument manually:
@@ -1531,15 +1460,8 @@
               </li>
             </ul>
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Increased user choice,
-Improved user experience,
-Innovation,
-Transparency,
-Portability,
-and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
           <dt>Motivation</dt>
           <dd>
 There are scenarios, such as the first interaction/use of a payment instrument,
@@ -1577,60 +1499,14 @@
               </li>
             </ul>
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Increased user choice,
-Improved user experience,
-Innovation,
-Lower Costs,
-Transparency,
-Automatability,
-and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 Payment solutions providers can make payments easier and faster through automation.
           </dd>
         </dl>
 
-        <dl id="uc-payer-privacy" class="dl-horizontal">
-          <dt>Payer Privacy</dt>
-          <dd>We anticipate a range of privacy scenarios:
-            <ul>
-                <li>
-Lucio sends information about instruments he is willing to use to
-TrustedMerchant, who provides a discount for access to his information.
-              </li>
-                <li>
-Carla does not want to share information about the
-<a title="payment instrument">payment instruments</a> she uses with any
-merchants, so that information is not shared with any online merchants.
-              </li>
-            </ul>
-          </dd>
-          <dt>Goals</dt>
-          <dd>
-Increased user choice,
-Improved user experience,
-Innovation, and
-Monetization.
-          </dd>
-          <dt>Motivation</dt>
-          <dd>
-Sharing or protecting data on the sorts of
-<a title="payment instrument">payment instruments</a> available to
-a <a>payer</a> should be a decision made by the <a>payer</a>.
-          </dd>
-          <dt>Privacy / Security</dt>
-          <dd>
-The types of <a title="payment instrument">payment instruments</a> available
-to a <a>payer</a> could be
-used to digitally fingerprint a <a>payer</a> even if they were using an
-pseudo-anonymous payment mechanism. Merchants and <a>payee</a>s may be legally
-obligated to protect this kind of <a>payer</a> payment information.
-          </dd>
-        </dl>
-
       </section>
 
       <section>
@@ -1638,6 +1514,21 @@
         <p>
         </p>
 
+        <dl id="uc-password" class="dl-horizontal">
+          <dt>Password Auth</dt>
+          <dd>
+When Suresh attempts to pay online, he is asked for a username and password
+by his payment service provider before the payment is approved.
+          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
+          <dt>Motivation</dt>
+          <dd>
+The most common mechanism for protecting access to payment instruments on the
+Web in 2015 is the use of a username and password.
+          </dd>
+        </dl>
+
         <dl id="uc-multifactor" class="dl-horizontal">
           <dt>Multi-Factor</dt>
           <dd>
@@ -1648,6 +1539,10 @@
 When Ian selects his debit card, he is prompted for a PIN.
               </li>
               <li>
+Horace presses the biometric fingerprint reader on his phone to authorize a
+purchase.
+              </li>
+              <li>
 An authentication code is sent to Tony's mobile phone as a text message
 to ensure that he is the one that initiated the payment. Once he enters the
 authentication code, the payment proceeds.
@@ -1669,16 +1564,8 @@
               </li>
             </ul>
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Increased user choice,
-Improved user experience,
-Greater security,
-Minimal standardization,
-Regulatory acceptance,
-Innovation,
-and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
           <dt>Motivation</dt>
           <dd>The payments architecture should support
 	    the authentication devices available today for
@@ -1699,10 +1586,8 @@
 PayCo must ensure that their customers do not appear on any regulatory
 blacklists when performing <a>transaction</a>s above a certain monetary amount.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Regulatory acceptance, and Automatability.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 Easing compliance with Know Your Customer (KYC) and
@@ -1716,8 +1601,6 @@
           </dd>
         </dl>
 
-        <section>
-          <h5>Non-essential Use Cases</h5>
           <dl id="uc-biometric" class="dl-horizontal">
             <dt>Biometric</dt>
             <dd>
@@ -1740,16 +1623,8 @@
                 </li>
               </ul>
             </dd>
-            <dt>Goals</dt>
-            <dd>
-Increased user choice,
-Improved user experience,
-Greater security,
-Minimal standardization,
-Regulatory acceptance,
-Innovation,
-and rapid, widespread adoption.
-            </dd>
+            <dt>Target version</dt>
+          <dd>Uncategorized</dd>
             <dt>Motivation</dt>
             <dd>
 Biometrics can be utilized on point of sale terminals, mobile, and wearable
@@ -1794,12 +1669,8 @@
 by an access control list as well as limits on the amount that each
 employee can spend without authorization by management.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience,
-Greater security, and
-Regulatory acceptance.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 There are many types of accounts that are accessed via different payment
@@ -1807,8 +1678,6 @@
 are typically protected by one or more sets of authorization rules.
           </dd>
         </dl>
-        </section>
-
       </section>
 
     </section>
@@ -1850,10 +1719,8 @@
               </li>
             </ul>
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Automatability, and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
           <dt>Motivation</dt>
           <dd>
 Payee-initiated payments, also known as "pull payments" or
@@ -1891,13 +1758,8 @@
               </li>
             </ul>
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience,
-Greater security,
-Innovation, and
-Automatability.
-          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
           <dt>Motivation</dt>
           <dd>
 Payer-initiated payments, also known as "push payments",
@@ -1922,10 +1784,8 @@
 room. She uses her phone to provide a proof-of-hold until she checks out of
 the hotel, at which time the hold on her funds will be released.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience, and Transparency.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 Delivering services or products that are difficult to "undo," such
@@ -1935,28 +1795,23 @@
           </dd>
         </dl>
 
-        <section>
-          <h5>Non-essential Use Cases</h5>
-          <dl id="uc-funds-verification" class="dl-horizontal">
-            <dt>Funds Verification</dt>
-            <dd>
+        <dl id="uc-funds-verification" class="dl-horizontal">
+          <dt>Funds Verification</dt>
+          <dd>
 When Mario wishes to <a>purchase</a> a race car through the manufacturer,
 the company that makes the car requires a proof of funds from Mario's bank
 in order for the customization of the car to proceed.
-            </dd>
-            <dt>Goals</dt>
-            <dd>
-Greater security and Transparency.
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
+          </dd>
+          <dt>Target version</dt>
+        <dd>Uncategorized</dd>
+          <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.
-            </dd>
-          </dl>
+          </dd>
+        </dl>
 
-        </section>
       </section>
 
       <section>
@@ -1971,12 +1826,16 @@
 <a>transaction</a> being performed:
             <ul>
                 <li>
+Sung-hyun provides a proof of initiation of funds transfer to get access to
+an online streaming music service.
+              </li>
+                <li>
 Zhang Wei orders 10 large boxes of envelopes from an online shop in
 Tianjin. He uses an escrow service to provide a proof of escrow to the
 online shop in order to get them to initiate the shipment.
               </li>
                 <li>
-To protect Tibor's privacy when he  <a title="purchase">purchases</a> candy
+To protect Tibor's privacy when he <a title="purchase">purchases</a> candy
 online, the store asks only for Tibor's verified shipping address and a
 proof of payment to send him the chocolates.
               </li>
@@ -1988,16 +1847,8 @@
               </li>
             </ul>
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Increased user choice,
-Improved user experience,
-Greater security,
-Regulatory acceptance,
-Innovation,
-Transparency,
-Automatability, and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
           <dt>Motivation</dt>
           <dd>
 At times, it is safe to release a good
@@ -2044,14 +1895,8 @@
               </li>
             </ul>
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Increased user choice,
-Improved user experience,
-Transparency,
-Automatability,
-and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Exceptions</dt>
           <dd>
 If the funds are sent but never received, then the <a>payee</a> will
@@ -2060,34 +1905,27 @@
           </dd>
         </dl>
 
-        <section>
-          <h5>Non-essential Use Cases</h5>
-          <dl id="uc-notifications" class="dl-horizontal">
-            <dt>Notifications</dt>
-            <dd>
+        <dl id="uc-notifications" class="dl-horizontal">
+          <dt>Notifications</dt>
+          <dd>
 Gavin sends an electronic cheque 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>
-            <dt>Goals</dt>
-            <dd>
-Innovation,
-Automatability,
-and rapid, widespread adoption.
-            </dd>
-            <dt>Motivation</dt>
-            <dd>
+          </dd>
+          <dt>Target version</dt>
+        <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
 It is difficult for an organization to know when a payment has been received
 without depending on proprietary software.
-            </dd>
-            <dt>Exceptions</dt>
-            <dd>
+          </dd>
+          <dt>Exceptions</dt>
+          <dd>
 It may also be important to be notified when a payment that was initiated
 has not been received, or when a payment has been reversed after it had been
 received.
-            </dd>
-          </dl>
-        </section>
+          </dd>
+        </dl>
       </section>
 
     </section>
@@ -2106,10 +1944,8 @@
 bicycle is delivered a few days later with a QRCode attached to the package
 that only Giralt can access.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
           <dt>Motivation</dt>
           <dd>
 The <a>purchase</a> and delivery of physical goods via an online marketplace
@@ -2117,23 +1953,6 @@
           </dd>
         </dl>
 
-        <dl id="uc-dropshipping" class="dl-horizontal">
-          <dt>Dropshipping</dt>
-          <dd>
-Takeru orders a new backpack online and has it shipped to a nearby department
-store for pickup.
-          </dd>
-          <dt>Goals</dt>
-          <dd>
-Rapid, widespread adoption.
-          </dd>
-          <dt>Motivation</dt>
-          <dd>
-It is common in Japan and the United Kingdom to purchase items online and then
-have them shipped to a nearby department store to save on shipping.
-          </dd>
-        </dl>
-
         <dl id="uc-virtual-goods" class="dl-horizontal">
           <dt>Virtual Goods</dt>
           <dd>
@@ -2142,16 +1961,8 @@
 proof of <a>purchase</a> that is sent to the band's website, after which
 MusicBox provides Lilith a link to download the additional content.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience,
-Greater security,
-Minimal standardization,
-Innovation,
-Automatability,
-Portability, and
-Monetization.
-          </dd>
+          <dt>Target version</dt>
+          <dd>1.0</dd>
           <dt>Motivation</dt>
           <dd>
 Delivery of product can happen on any site that accepts a proof of purchase
@@ -2159,6 +1970,21 @@
           </dd>
         </dl>
 
+        <dl id="uc-dropshipping" class="dl-horizontal">
+          <dt>Dropshipping</dt>
+          <dd>
+Takeru orders a new backpack online and has it shipped to a nearby department
+store for pickup.
+          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
+          <dt>Motivation</dt>
+          <dd>
+It is common in Japan and the United Kingdom to purchase items online and then
+have them shipped to a nearby department store to save on shipping.
+          </dd>
+        </dl>
+
       </section>
 
       <section>
@@ -2170,14 +1996,8 @@
 credit card (via his phone). An electronic receipt for the <a>purchase</a>
 from the gas station is displayed on his phone.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience,
-Greater security,
-Innovation,
-Automatability, and
-Portability.
-          </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
@@ -2205,13 +2025,8 @@
 terminal he taps his phone to a kiosk and receives a printed physical receipt
 that he can use on the bus.
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience,
-Innovation,
-Portability,
-and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>Uncategorized</dd>
           <dt>Motivation</dt>
           <dd>
 There will be a transition period from the use of physical receipts and
@@ -2235,8 +2050,8 @@
       </section>
       <section>
         <h4>Refunds</h4>
-        <dl id="uc-refunds" class="dl-horizontal">
-          <dt>Common Refunds</dt>
+        <dl id="uc-refund" class="dl-horizontal">
+          <dt>Basic Refund</dt>
           <dd>
 At times, it becomes necessary to refund a <a title="payer">payer's</a>
 payment:
@@ -2265,16 +2080,8 @@
               </li>
             </ul>
           </dd>
-          <dt>Goals</dt>
-          <dd>
-Improved user experience,
-Greater security,
-Regulatory acceptance,
-Innovation,
-Automatability,
-Portability,
-and rapid, widespread adoption.
-          </dd>
+          <dt>Target version</dt>
+          <dd>1.0 (if time permits)</dd>
           <dt>Motivation</dt>
           <dd>
 Some <a>transaction</a>s are the result of human error or fault. In these
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/latest/vision/index.html	Mon Jun 29 13:24:18 2015 +0200
@@ -0,0 +1,235 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>A Vision for a Web Payments Architecture</title>
+    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+    <script src='//www.w3.org/Tools/respec/respec-w3c-common' 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-vision",
+
+          // if you wish the publication date to be other than today, set this
+          //publishDate:  "2015-04-16",
+
+          // 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: "http://w3c.github.io/webpayments-ig/latest/vision/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: "Adrian Hope-Bailie", url: "http://medium.com/@ahopebailie",
+                company: "Ripple Labs", companyURL: "http://www.ripplelabs.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:  [
+              { name: "Adrian Hope-Bailie", url: "http://medium.com/@ahopebailie",
+                company: "Ripple Labs", companyURL: "http://www.ripplelabs.com/" },
+              { name: "Ian Jacobs", url: "http://www.w3.org/People/Jacobs/",
+                company: "W3C", companyURL: "http://www.w3.org/" }
+          ],
+
+          otherLinks: [{
+            key: "Version control",
+            data: [{
+              value: "Github Repository",
+              href: "https://github.com/w3c/webpayments-ig"
+            }, {
+              value: "Issues",
+              href: "http://www.w3.org/Payments/IG/track/products/8"
+            }]
+          }],
+
+          // maximum level of table of contents
+          maxTocLevel: 3,
+
+          // name of the WG
+          wg:           "Web Payments Interest Group",
+
+          // URI of the public WG page
+          wgURI:        "http://www.w3.org/Payments/IG/",
+
+          // name of the public mailing to which comments are due
+          wgPublicList: "public-webpayments-ig-comments",
+
+          // 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",
+
+      };
+    </script>
+  </head>
+<body>
+  <section id='abstract'>
+    <p>
+This document is the architecture vision statment of the W3C Web Payments Interest 
+Group. It describes the principles upon which a Web Payments architecture should be built.
+    </p>
+  </section>
+
+  <section id='sotd'>
+    <p>
+Previous versions of this document were maintained on the group's 
+<a href="https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force/Vision">wiki</a>.
+    </p>
+    <p>
+On <strong>28 May 2015</strong> the chairs of the Web Payments Interest Group issued 
+a <a href="https://lists.w3.org/Archives/Public/public-webpayments-ig/2015May/0220.html"><strong>call for consensus</strong></a></a> 
+  to determine whether the group will publish this as an endorsed vision for Web payments.
+    </p>
+  </section>
+
+  <section>
+    <h2>Web Principles</h2>
+    <p>
+Any architecture grounded in the Web should respect well-known Web principles such as:
+    </p>
+    <ul>
+      <li>Adhering to Web architecture fundamentals</li>
+      <li>Supporting network independence</li>
+      <li>Supporting device independence</li>
+      <li>Providing accessibility for payers and payees with disabilities</li>
+      <li>Being machine-readable where possible to enable automation and engagement of non-human entities</li>
+      <li>Protecting the privacy of all participants</li>
+      <li>Being open and usable by anyone, including those who are not yet connected to the Web</li>
+    </ul>
+  </section>
+  
+  <section>
+    <h2>Desireable properties of a Web Payments Architecture</h2>
+    <p>
+In addition to the priciples above, the following are desirable properties specific to a Web payments architecture:
+    </p>
+    <section>
+      <h3>Provides payees and payers unencumbered knowledge and choice in how to undertake payments</h3>
+      <p>
+It is consistent with the purpose of the Web to enable payees to receive payments, and payers to pay, 
+using their preferred payment instruments and payment schemes. The Web payments architecture must not 
+restrict these choices but rather foster transparency of choices available. 
+      </p>
+    </section>
+    <section>
+      <h3>Improves the user experience</h3>
+      <p>
+We want to improve the user experience in a variety of ways. These include reducing the need to provide 
+data as part of a transaction (helpful on mobile in particular), simplifying payment user interfaces and 
+interactions, standardizing the payment flow across all Web applications, and making it easier to make 
+payments from a wide range of devices, such as computers, portable devices, televisions, eBooks, and 
+automobiles. 
+      </p>
+      <p>
+Taken together, we expect these improvements will lower the rate of "cart abandonment" and 
+increase the velocity of payments made over the Web.
+      </p>
+    </section>
+    <section>
+      <h3>Supports a wide spectrum of security and privacy needs to meet industry expectations</h3>
+      <p>
+Trust in Web payments is critical to their widespread adoption. Because of this the architecture must provide 
+the ability for participants in the payment process to confidently, securely and accurately identify and 
+connect to other participants that are party to the payment. 
+      </p>
+      <p>
+The architecture should not disclose private details of the participants identity or other sensitive information 
+as part of the payment process unless required by operational, legal or jurisdictional rules, or when deliberately 
+consented to (e.g. as part of a loyalty program) by the owner of the information. 
+      </p>
+      <p>
+The Web payments architecture should make this easy by standardizing the mechanisms available to issue, exchange 
+and verify credentials as part of a payment transaction, as well as a secure mechanism for the exchange of identity 
+information when it is explicitly required as part of a payment. To accomplish this, it is expected that the 
+architecture will also need to support an evolving variety of authentication and identification techniques 
+(e.g. multifactor, biometric, etc.) which can be used independent of or in concert with a participants identity data. 
+      </p>
+    </section>
+    <section>
+      <h3>Encapsulates existing payment schemes and enables new schemes</h3>
+      <p>
+In order to achieve this, we anticipate that the architecture will be:
+      </p>
+      <ul>
+        <li><strong>Minimalist</strong>, in order to accommodate diverse existing and emerging schemes.</li>
+        <li><strong>Extensible</strong>, so that above and beyond the minimum information required for interoperability, parties 
+          involved in payments can exchange the information they require, using the formats and protocols they prefer.</li>
+      </ul>
+    </section>
+    <section>
+      <h3>Encourages efficient settlement</h3>
+      <p>
+Different payment schemes move value at different speeds. The Web payments architecture should not impose additional 
+delays, so that payment information circulates as efficiently as possible and the final settlement (exchange of value) 
+is done as quickly as possible.
+      </p>
+    </section>
+    <section>
+      <h3>Facilitates compliance with legal & regulatory obligations</h3>
+      <p>
+The Web is a global system which must operate across many legal and regulatory jurisdictions. While there are common 
+requirements across jurisdictions, it is not cost-effective to create a single system that satisfies all legal and 
+regulatory obligations in all jurisdictions. 
+      </p>
+      <p>
+As a result, a successful architecture for payments on the web will account 
+for variability with regard to legal and regulatory frameworks it can support. The group envisions an extensible set of 
+'hooks' that enable participant-authorized parties to comply with legal and regulatory requirements in different 
+jurisdictions in a secure and more standard manner.
+      </p>
+      <p>
+We believe the industry will benefit from standards that lower the cost (e.g. through automation) of addressing 
+needs related to Know Your Customer, Anti-Money Laundering, and other requirements related to due diligence and 
+customer identity.
+      </p>
+    </section>
+    <section>
+      <h3>Enables monetization on the spectrum of Web to native apps</h3>
+      <p>
+Web developers will be able to integrate payments smoothly into a variety of user experiences on the Web, including 
+in-app payments, downloads, and subscriptions. This is key to opening up new revenue generating opportunities on the 
+Web that were not previously viable due to the costs incurred and poor user experiences required in processing payments.
+      </p>
+    </section>
+    <section>
+      <h3>Bridges distributed value networks</h3>
+      <p>
+The Web will ultimately serve as a bridge between open and closed value exchange networks, enabling interoperable value 
+exchange. This will enable both payers and payees to seamlessly make payments using a variety of previously 
+non-interoperable payment instruments. 
+      </p>
+    </section>
+  </section>
+
+  <section class="appendix">
+    <h2>Acknowledgements</h2>
+    <p>
+The editors wish to thank the participants of the
+<a href="http://www.w3.org/Payments/IG/">Web Payments Interest Group</a>
+for discussions about and contributions to this document, as well as the
+<a href="https://www.w3.org/community/webpayments/">Web Payments Community
+Group</a> for earlier work that informed this document.
+    </p>
+  </section>
+
+  </body>
+</html>