--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/latest/requirements/browser_security_notes.txt Mon Jun 29 13:01:07 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/use-cases/index.html Mon Jun 29 13:00:54 2015 +0200
+++ b/latest/use-cases/index.html Mon Jun 29 13:01:07 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