UseCases

Changelog

General comments:

• Roles for entities in use cases
  • Melvin Carvalho: In crypto currency payments, generally a payment is from one public key to another (ie URI to URI), and may not include either a customer or merchant.
  • Adrian: Refer to "payers" and "payees" rather than "customers" and "merchants" unless the use case is specifically limited to these actors.
    • PROPOSAL: Assign roles to entities in each use case.
    • CHANGES: 2014-07-30 - added glossary of role terminology, did complete search/replace of unclear terminology/roles w/ specific ones

• Be specific about identity attributes
  • Adrian: Be specific when talking about identities, or identity attributes (claims), whether the use case refers to the payer's or the payee's identity or both.
    • PROPOSAL: Refer to identity attributes / aka credentials (not identitiy)
    • CHANGES: 2014-07-30 - Referred to 'identity' and attributes related to identity as 'credentials'. Attempted to more clearly specify which entity's credentials are required.

• Identity not necessary for version 1.0
  • Adrian: My suggestion would be to focus the first iteration on payment processing without a need to exchange/verify the payer identity and add this in iteration 2. In terms of discussion within the IG, I think both are appropriate.
  • PROPOSAL: This will be left for the Web Payments IG to decide. That said, implementers of the current specifications (like Digital Bazaar) and those that run payments companies don't believe that we can make a very compelling solution for payments on the Web w/o at least implementing some sort of identity attribute exchange mechanism.
  • CHANGES: 2014-07-30 - None, decision deferred to Web Payments IG

• Use Case Layout
  • Dave Longley: Use case layout should include conversational use case, then detailed roles required, credentials required, design requirements in order to make it possible.

Introduction

Glossary

There are a number of roles assigned to entities in each use case below:

• payer - the entity sending value in a transaction.
• payee - the entity receiving value in a transaction.
• buyer - an entity that is performing a purchase.
• merchant - an entity that is offering a product or service for sale.
• payment processor - an entity that is responsible for transferring value between entities and generating verifiable digital receipts.

There is terminology that is common to all use cases:

• credentials - attributes such as name, shipping address, government issued ID, or proof-of-age associated with a particular entity that may be exchanged before, during, or after a transaction.

Identity

• Use Case: Store basic credentials and payment provider information on the Web in a way that is easy to share with various payees/merchants given authorization by the owner (payee) of the credential, and that is easy to synchronize between devices.
  • Notes: This includes the ability for the credential owner to manage their credentials. It does not include the ability for the credential owner to automatically sell their credential information.
  • Steven Rowat: I think we need to have more discussion about identity's implications before deciding whether to attempt to do it together with web payments.
  • Adrian: Not required for first iteration. It is not ESSENTIAL for the payer to exchange identity credentials to complete a basic transaction. Think this should be the focus of 2nd iteration.
  • PROPOSAL: A Credentials CG is being created to handle all identity requirements for Web Payments (and other market verticals). The Web Payments CG will proceed assuming that there will be a mechanism to establish an identity URL for participants in a transaction.
• Use Case: Steve (buyer) visits a website (merchant) and authorizes the transmission of one or more credentials (such as proof-of-age, shipping address, etc.) previously stored with a credential storage service to the website to enable access or fulfillment of a transaction.
  • Adrian: Not required for first iteration. It is not ESSENTIAL for the payer to exchange identity credentials to complete a basic transaction. Think this should be the focus of 2nd iteration.
  • PROPOSAL: A Credentials CG is being created to handle all identity requirements for Web Payments (and other market verticals). The Web Payments CG will proceed assuming that there will be a mechanism to establish an identity URL for participants in a transaction.
• Use Case: Given the opt-in permission of the participants (payer, payee, buyer, merchant) of a transaction, the transaction metadata can be used to discover additional attributes associated with those participants. For example, given the buyer's authorization, a merchant could query the identity URL for the buyer contained in a digital receipt and obtain an up-to-date email address.
  • Steven Rowat: wouldn't someone in the NSA be doing exactly this? Or Google, to get data to drive advertising revenue? Isn't there a good case that this is unconstitutional in the US? I don't think this is what you mean...but what do you mean? Who needs to discover attributes associated with the identity of the participants? Why not just ask the participants?
  • Adrian: Not sure that I understand the need for this use case.
  • Steven Rowat: IMO, it would be best to add "opt-in" before "permission" in the first sentence. If this isn't written into the spec then I believe someone will abuse it and begin harvesting data about unsuspecting users merely on the basis that they haven't opted-out, and explain it as 'assumed permission'.
  • PROPOSAL: Rewrite use case to ensure participant permission is required. Provide example to clarify use case. Add Steven's 'opt-in' language.
  • CHANGES: 2014-08-06 - Use case text was updated.
  • CHANGES: 2014-08-26 - Steven's 'opt-in' language added.
• Use Case: Digitally verifiable credentials such that a merchant and payment processor involved in a transaction can prove that they have performed the proper due diligence when identifying the payer and the payee (KYC).
  • Adrian: Not required for first iteration. It is not ESSENTIAL for the payer to exchange identity credentials to complete a basic transaction. Think this should be the focus of 2nd iteration.
  • PROPOSAL: A Credentials CG is being created to handle all identity requirements for Web Payments (and other market verticals). The Web Payments CG will proceed assuming that there will be a mechanism to establish an identity URL for participants in a transaction.
• Use Case: A payer executes a transaction without revealing secrets that are not vital to the transaction (e.g. identity, passwords, PINs or other information that the merchant does not need to know).
• Design Criteria: Consider using existing, widely deployed identity provider mechanisms (e.g. Facebook Connect, OpenID Connect, G+ Sign-In, etc.) to integrate with the digital credentials sharing and payments initiation process. Only invent a new mechanism if the current identity provider mechanisms do not provide the functionality necessary to achieve the use cases promoted by the group.
  • Steven Rowat: would the 'existing, widely deployed' mechanism be part of the specification and go through the same W3C process, and end up being a supported (necessary? sufficient?) part of the whole mechanism? Or is it implied that the i.d. provider mechanism would remain outside the W3C process, which would nonetheless be designed as a socket for it? Or would the payment mechanism have a socket that could fit any number of identity provider mechanisms, without prejudice, but this one is being specified so that there will at least be one example that works for sure? If so, are there downsides to this? For instance, are there other provider or potential provider mechanisms whose developers will be annoyed by being passed over? Or, are there yet-to-be imagined mechanisms that might be better than the chosen existing one, potential mechanisms which will now fail to be developed because one has been already blessed by (association with) the W3C?
  • Steven Rowat: As written, this could be interpreted as using *only* OpenID Connect. Isn't that against the spirit of the open standard and W3C expectations? (Or do I misinterpret all those corporate logos at the OpenID site?) But is this actually what is intended? (And if so, is there a technical reason why OpenID Connect must be used?) --Or is it an option, ie., there will be a socket for it but there could be sockets for other things written as well? If the latter I think the wording needs to change. If the former I think that technical reason needs to be put in, or available by a link, to explain why.
  • PROPOSAL: Decouple and abstract identity away as much as possible. So, one could use whatever solution that wins in the identity space. No change required for the use case, clarifications have been made on the mailing list and telecon.
  • CHANGES: 2014-08-26 - Reword Use Case as a Design Criteria, make it clear that other IdP mechanisms should be considered. Clarify that a new mechanism should be considered if older mechanisms can't be upgraded to solve the issue at hand.
• Use Case: Transact with a merchant without revealing any identifying information. Identifying information is available to the payment processor.
• Use Case: Enable truly anonymous transactions such that the identity of the payee is not discoverable by payees, merchants, or payment processors.
  • Steven Rowat: Do you mean 'but can be discoverable by governments or law enforcement when they have appropriate authorization'? If so, +1, but I think it would be best to include that explicitly.
  • PROPOSAL: We do not believe that this is a version 1 feature because the technology to achieve it is still being actively researched and developed.
• Use Case: Jack (payer) wants to send Jill (payee) some money and asks Jill for a short, memorable payment identifier. Jill sends the payment identifier to Jack via an SMS message. Jack makes a payment using the short payment identifier; the payment processor translates the short payment identifier into a destination financial account for Jill.
• Use Case: Gunther (payer) enters a short-identifier that he believes identifies The Widget Store (merchant) into a UI. The UI displays a certificate of authenticity that indicates the short identifier is in fact for The Widget Store. Gunther uses the short identifier to make a payment to the store.
  • Steven Rowat: Don't understand this one; ambiguity for me in at least two places. At first I believed the 'short identifier' was a label for the 'person', ie, identified the person to the merchant. Then I couldn't figure out the antecedent of 'them' in the second sentence (is it the person, or the merchant, or both of them?) Then in the last part of that sentence it seemed likely, but not certain, that 'short identifier for the merchant' indicates that it's the merchant, not the person, who is represented by the short label. It could also mean it's representing the 'person', but provided 'for' the merchant. If I had to bet I guess I'd go with the former, rather than the latter. But I'm really not sure.
  • PROPOSAL: Reword use case to clarify the bits that Steven was unclear on.
  • CHANGES: 2014-08-13 - The use case has been reworded.
• Design Criteria: A primary entity (buyer, merchant, etc.) with access to a credential service sets a second entity (buyer, merchant, etc.) as a backup for accessing their credentials should they inadvertently lose their ability to access the credential service (accidental loss of password or 2-factor authentication device).
  • Steven Rowat: In theory it seems like a good idea, but maybe is too general? What are the implications...such as, will all their credentials merely switch over seamlessly at all the providers? Will all KYC and other legal entities be in the loop, or does this cause anonymity/laundering problems? By 'lose the ability', could you also be including a government taking away someone's identity or controlling it -- let's say someone in China is blacklisted by their government, but someone in, Oh, just for a random example, the United States government, disagrees and says, fine, we'll honor your second identity and not your first, and then everybody will be happy.
  • PROPOSAL: Reword the design criteria. We're very concerned that this shouldn't be built into the specification/standard. Potential to be unnecessarily complex while not adding anything beyond the state of the art today.
  • CHANGES: 2014-08-13 - Reword of design criteria text.

Initiating Payments / Wallet APIs

• Use Case: A buyer selects an item to purchase on merchant's site, merchant generates a purchase request that will be processed by the buyer's payment processor.
  • Jorge: +1 only if generating the purchase request is equivalent to generating a link or token.
  • PROPOSAL: No change to the use case, using links or tokens adds unnecessary complexity / layers of indirection.
• Use Case: A developer can create a link with a specific payment URI scheme or rel-type such that when a buyer clicks on it, the buyer's payment processor starts the payment process.
  • Adrian: Updated use case - Is URI scheme the only way to do this?
  • Jorge: This is my favorite approach. No NASCAR problem, no list of payment processors, just an email with a payment link. It could be implemented with a simple form with text field for inputs like 'wallet.example.com/walletID' or 'walletID@walletexample.com' (maybe with a drop down menu), make an API call to the example provider and let the provider send the email with the payment link if the transaction is possible.
  • PROPOSAL: (Adrian) Add "or rel-type"
  • PROPOSAL: (Jorge) The group feels that surfacing complexity such as wallet IDs to the end customer is counter-productive and maintains the status quo.
  • CHANGES: 2014-08-02 - Minor rewording
• Use Case: When a payee intends to make a payment, they are given a choice to pick among the intersection of the payment processors they're registered with and the payment processors that are advertised by the merchant/payee.
  • Jorge: NASCAR problem.
  • Michael Williams: ideally there should be an option to set the default payment processor for that merchant, so the NASCAR selection only needs to happen once.
  • PROPOSAL: NASCAR problem is misunderstood by Jorge's comments, technology supports customer choosing their preference as well as defaults. No changes necessary.
• Use Case: A merchant advertises different details, such as price, for an offer of sale based on potential payment processor choice.
  • Jorge: It makes a lot of sense, and it happens a lot in online games, but maybe it would be hard to define or predict 'potential choice' if the user is not even registered but just browsing several sites to compare prices and make an actual choice.
  • Michael Williams: the two above that allow the merchant to limit who can be a payment processor seems like it would kill any small payment processors. i'd like to see the ability to be your own payment processor as a use case. given that there still needs to be a trusted third party between merchant and buyer, maybe a middle ground is to allow the buyer to choose a major payment processor listed by the merchant as a trusted proxy for their preferred payment processor. inter-processor transactions seem to be supported: https://web-payments.org/specs/source/web-payments/#the-decentralized-settlement-process.
  • PROPOSAL: Response to Jorge is that this is a v2 feature, and it's expected that merchants will provide a rough price for V1.
  • PROPOSAL: Response to Michael is that we agree that this would be a great feature to have, but the technology and political environment necessary to do this is not there yet.
• Use Case: A buyer can associate a membership card, coupon, or similar token with a transaction to receive a discount or other benefits.
  • Steven Rowat: I think these could wait until a later version. I know many marketing strategies use them, but many don't; essentially they're an optional add-on (IMO there's an argument that they're like tariff barriers -- somebody starts, then everybody does it, and it becomes cruft that we all pay for without good reason). I suggest putting minimal resources into it, as a socket that the vendor must provide most of the code/structure for.
  • Adrian: For later iterations
  • PROPOSAL: Shift this use case to "low priority" because it's expected that the outcome of the Credentials work will provide a mechanism for storing and transmitting loyalty cards, coupons, and other discount-enabling credentials.
• Use Case: Leveraging variable degrees of pseudo-anonymity per requirements of the payment transaction.
  • Adrian: For later iterations
  • PROPOSAL: Modify the use case to mention 'pseudo-anonymity' vs. 'anonymity'. The use case should be kept as it's important to protect people's privacy.
  • CHANGES: 2014-09-10 - Change 'anonymity' to 'pseudo-anonymity'.
• Use Case: A buyer discovers an offer for sale by a merchant under terms that the merchant is comfortable with. The offer includes a list of payment processors that the merchant is capable of receiving payment through. The buyer's software contacts a subset of those payment processors that they are capable of sending payment through to get finalized transaction details (such as price or speed) before executing the most desirable transaction.
  • Jorge: NASCAR problem
  • Michael Williams: Is there a user flow for proxying from payment processors included by merchant to another payment processor as described above?
  • PROPOSAL: For Jorge - There is agreement that this isn't a NASCAR problem, there seems to be some misunderstanding around how the system is intended to work.
  • PROPOSAL: For Michael - We would like such technology to exist, but to date, none has been invented to enable this to happen on a global scale. We will try to solve this problem during the v2 work. We should mention the idea of having more decentralized payment processors to the Web Payments IG for Design Criteria for future versions.
• Use Case: Payee and payers negotiate secure price in an open market. They are free to choose all three essential attributes of the numeric quantity expressing a price (e.g. 10.99), namely: a unit-of-account (e.g. $ £ € ¥ etc.); a medium-of-exchange (e.g. debit card, credit card, web payment etc.); and, a value-in-exchange benchmark (e.g. WM Reuters Spot Exchange; Purchasing Power Parity; Commodity Index; etc.)
• Use Case: A buyer uses a native non-browser application on their mobile phone or tablet, or a web browser to make a purchase at an app store.
  • Jorge: Native apps are ok as long as they use the Web infrastructure for the transactions (e.g. REST APIs)
  • PROPOSAL: The group agrees with Jorge's position.
• Use Case: A buyer makes a purchase from within an application for premium content, virtual goods, or subscriptions.
  • Jorge: However, without embedding wallets, but by obtaining delegated access through OAuth tokens.
  • PROPOSAL: We agree that wallets shouldn't be embedded and payment should be made via delegated access, but we don't believe that OAuth (or any specific technology) should be mentioned in the use case.
• Use Case: Temporary payment tokens for merchants. If token is stolen, thief does not get access to financial account. Tokenization mechanism that protects the buyer and merchant from theft of credentials.
• Use Case: The buyer goes to a merchant website and clicks a buy button to complete a purchase without having to go through any registration process. During the purchase the buyer chooses which information to share with the merchant which the merchant then uses to uniquely identify the buyer if they perform any repeat purchases.
  • Steven Rowat: Redundant? What's the difference between this and the Use Case that's third from the top, that says: "given a choice to pick among the intersection of the payment processors they're registered with and the payment processors that are advertised by the merchant"?
  • Adrian: For later iterations
  • PROPOSAL: Response to Steven - it's not redundant, this has to do w/ credential transmission + purchasing (streamlining the purchase process). The other use case has to do w/ selecting among provided credentials (selection of payment processor).
  • PROPOSAL: Reponse to Adrian - We're deferring the notion that there would be browser API calls to achieve this use case. However, we can achieve this use case with the current technology and a best-practice note, nothing new is required and therefore it doesn't make sense to postpone the use case if we can achieve it today using browser polyfills.
• Use Case: The buyer goes to a merchant website and clicks buy to initiate a purchase. The buyer is redirected to their payment processor's website which presents them with a payment UI. The buyer completes the purchase (optionally without providing any information other than their consent). The buyer is sent back to the merchant's website with a digital receipt confirming the purchase.
  • Jorge: Custom payment UIs are not the way to go in my opinion.
  • Michael Williams: if proxying as described above happens by default if chosen as an option before.
  • PROPOSAL: Response to Jorge - Merchant-based custom payment UIs that don't use a pre-authorized token from a payment processor are a bad idea, browser-based Trusted UIs don't seem to have a good solution at the moment, which means that the only payment UI that can be presented that asks for possibly private information is from the payment processor on the payment processors website. It's in the payment processor's purview to change the UI to meet their customer's expectations. We should not try to specify what a payment UI should look like.
  • PROPOSAL: Response to Michael - We would like payment proxying technology to exist, but to date, none has been invented to enable this to happen on a global scale. We will try to solve this problem during the v2 work. We should mention the idea of having more decentralized payment processors to the Web Payments IG for Design Criteria for future versions.
  • CHANGES: 2014-09-17 - Updated the use case to be more clear about where the payment UI is presented.
• Use Case: A buyer goes to a merchant website, and upon initiating a payment, the merchant's software transmits the merchant's payment processor options to the buyer's software. The buyer's software presents a choice of payment processors the buyer has previously registered with that are compatible with the merchant's payment processors.
  • Jorge: NASCAR problem
  • Michael Williams: not sure how different from "Use Case: When a customer intends to make a payment, they are given a choice to pick among the intersection of the payment processors they're registered with and the payment processors that are advertised by the merchant."
  • PROPOSAL: Response to Jorge - There is agreement that this isn't a NASCAR problem, there seems to be some misunderstanding around how the system is intended to work.
  • PROPOSAL: Response to Michael - Michael is correct, this does seem to duplicate 100% of the functionality expressed by the use case he refers to. We should strike this use case as a duplicate.
• Use Case: A buyer visits a merchant's website and initiates a payment. Their payment processor presents them with an option to subscribe to a merchant's product or service, which will result in periodic payments at a known value to the merchant.
  • Jorge: Pay-as-you-go tokens sound good, but what about choosing the payment processor first?
  • PROPOSAL: Response to Jorge - The selection of the payment process is handled by the following Use Case: When a payee intends to make a payment, they are given a choice to pick among the intersection of the payment processors they're registered with and the payment processors that are advertised by the merchant/payee.
  • CHANGES: 2014-09-24 - Split the subscription and pay-as-you-go use case into two separate use cases. This is the subscription one.
• Use Case: A buyer visits a merchant's website and initiates a payment. Their payment processor presents them with an option to assign a pay-as-you-go token with a specific spending limit (and/or other limitations) for future purchases with the merchant. An option is also presented to require the display of a receipt when a purchase occurs (and/or other interactions), or to perform the purchase in the background with no interactive purchase process required.
  • CHANGES: 2014-09-24 - Split the subscription and pay-as-you-go use case into two separate use cases. This is the pay-as-you-go-one.
• Design Criteria: Consider using Web Intents or Protocol Handlers to provide an abstraction layer that could be used to solve both payment initiation and other problems on the Web.
• Use Case: An entity (payer, payee, merchant, buyer) stores wallet, credentials, and digital receipts with a particular identity/wallet/data storage provider. The entity decides to switch to a different identity/wallet/data storage provider and all wallet, receipt, and credential data comes with them.
  • Jorge: The capability of switching wallet hosting providers would be great, but I guess it would be hard to achieve if there is balance to be transferred that would imply one provider sending actual money to another.
  • Evgeny: The wallet information may not just be their's, it may include other information that's not theirs. Suggest that we strike 'their'
  • PROPOSAL: Response to Jorge - while it's true that it might be hard to achieve the use case, the technology exists to transfer every piece of information except for the money. It is also a requirement of a system that payment processors are capable of transmitting money from one to another, so this use case should be achievable.
  • PROPOSAL: Response to Evgeny - we should strike the word 'their'.
  • CHANGES: 2014-09-24 - remove the word 'their' from the use case.
• Design Criteria: Require data portability for financial data and credentials that is required for core transaction functionality.
• Design Criteria: Ensure the Web payments solution can provide an abstraction layer that integrates with existing payment methods (eg: VISA, Mastercard, ACH, PayPal, debit card, Premium SMS, etc.)
  • Jorge: Compatibility is always good, but sometimes complicated, and even more for the entry-level payment provider trying to achieve PCI compliance. Excluding SMS, this is very high-end, and doesn't apply to the 2.5 billion unbanked.
  • PROPOSAL: Response to Jorge - Focusing on the 2.5B unbanked is a priority for the group, but in order to get traction, we can't ignore also supporting legacy systems. We believe this is achievable given the right level of abstraction, and have experimental software implementation proofs of concept to demonstrate integration with legacy systems. We are not saying a payment provider MUST support legacy payment systems. They may support legacy ones, they may not.
• Design Criteria: Allow payment processors to define the required level of authorization for particular transactions based on their preferences and local regulations. For example: No auth for small amounts, PIN auth for medium amounts, Secure Element for large amounts.
  • Steven Rowat: would it be possible to avoid the opening double negative, say by using a single positive, such as "Allow multiple levels..." and "Allow the implementation..."  ?
  • Michael Williams: double negative "don't prevent" is confusing, maybe allow?
  • PROPOSAL: Response to Steven and Michael - Good changes, the double negative should be removed.
  • CHANGES: 2014-09-24 - Removed double negative.
• Design Criteria: Ensure the technology can be extended or does not prohibit the implementation of simple digital contracts and smart contracts.
  • Steven Rowat: would it be possible to avoid the opening double negative, say by using a single positive, such as "Allow multiple levels..." and "Allow the implementation..."  ?
  • Michael Williams: double negative "don't prevent" is confusing, maybe allow?
  • PROPOSAL: Response to Steven and Michael - Good changes, the double negative should be removed.
  • CHANGES: 2014-09-24 - Removed double negative.

Digital Receipts

• Use Case: A payment processor tracks mandatory financial regulatory events and submits machine-readable information to a regulator-provided URL to automatically meet regulatory compliance.
• Design Critiera: Allow the digital receipt format to include domain-specific vocabulary information to support use cases such as including machine-readable licenses, nutrition and perishability information, UPC/GS1 identifiers, tax classification, and other information that can be later used to obtain access to a service.
  • Adrian: Not required for iteration 1
  • PROPOSAL: Response to Adrian - This was meant to be a general statement on the requirements around data model extensibility. The use case has been converted to a design criteria and been rewritten to capture the intent of the original use case.
  • CHANGES: 2014-09-24 - Changed from use case to design criteria and reworded heavily to convey data format extensibility requirement.
• Use Case: A merchant cryptographically-signs a standardized offer for a good or service. A buyer purchases the good or service from the merchant resulting in a standardized, cryptographically signed, machine-readable, digital receipt that is issued to the buyer. Entities involved in the transaction (merchant, buyer, payee) may then use the receipt as a proof-of-purchase for the good or service.
• Design Criteria: Don't prevent a physical version of a digital receipt that can be verified, perhaps by printing out a QR Code on a slip of paper with some additional information.

Uncertain Classification

• Use Case: Payments / digital receipts should be applicable to Encrypted Media Extension authorization to show content.
• Use Case: Knowing through which financial network your transaction will be delivered (you might care?).
• Use Case: Knowing what info will be required to supplement a transaction (unclear what 'supplement' means, might be covered).
• Use Case: Knowing that data minimization principles are followed by systems in a payment chain.
• Use Case: Allow for a settlement that is based on a cash transfer.
• Use Case: Protect privacy when making purchases using geolocation technologies.

Policy Use Cases

• Use Case: National incentives for using web-based payments due to beneficial effects upon economy.
• Use Case: Ensure access to payment systems by non-traditional channels, where barriers exist for traditional channels
• Use Case: Payment process includes user informed consent requirements about "what they are getting into".

Not in Scope for First Iteration

• Use Case: Merchant and User reputation system accessible to the payments mechanism.
• Use Case: Bots that execute financial operations on behalf of users.
• Use Case: Secure Element-based offline payment.
• Use Case: Browser-mediated offline transactions.
• Use Case: Enable Zero-trust transactions.
• Use Case: Realtime purchases involving prerequisite reception of funds from international sources (e.g. family).
• Use Case: Mixed sources of payment for a single transaction, using multiple payments with minimal transaction overhead.
• Use Case: Selection of payment service based upon ability to handle escrow for untrusted merchants.
• Use Case: Reputation based selection of providers in a payment transaction, or info about merchants to help the user choose whether to complete the transaction.
• Use Case: Enable the customer and the merchant to choose foreign exchange rates and how foreign exchange affect their prices, give them the choice, not the financial network/intermediary.
• Use Case: Realtime checks on account balances in wallets to help decide how to pay.
• Use Case: Show added/stored value from things you already do (discounts on gas purchases associated with a grocery store you shop at regularly).
• Use Case: When doing a payment, need a way to assure the customer he is his payment service provider and is not subject to phising. Specially problematic in mobile when browser chrome is not available.
• Use Case: Associate fraud information and signals with identities.
• Use Case: Keeping your web of trust in your wallet and only expose it to the outside world when necessary.
• Use Case: Secure backup wallet data info to a friends wallet.
• Use Case: Take the change for your $100 bill through a web payment.
• Use Case: Send money in any currency, have the network automatically do currency conversion, give currency at the other end in the receivers native currency.
• Use Case: Market makers acting as a transfer agent (foreign exchange happens automatically)
• Use Case: Transfer money through gateway providers of financial networks.
• Use Case: The wallet as an expert system - decide the best mode of operation for the purchase, make wallet providers compete on that metric.
• Use Case: Enable people to transfer tokens of value between their wallets (digital cash equivalent).
• Best Practice Consideration: Where is the wallet, how is it protected, is it stored on the same device as your 2-factor authentication device? Security side-effects of mobile-as-wallet are not straightforward.
• Use Case: Prevent corporate man-in-the-middle attacks that are commonly used in corporate environments.

Unclassified/Unreviewed

• Use Case: When a customer intends to make a payment, it is possible to pick a payment processor trusted by the merchant as an intermediate proxy for a payment processor not trusted by the merchant.
  • PROPOSAL: Response to Michael - This requires a decentralized clearing mechanism and we don't have that yet, it's a version 2 feature. It's important, we want to do it, we don't have the technical bandwidth to solve this problem and all of the other problems in version 1.0.
• Use Case: The buyer uses their payment processor's website to set a spending limit (and/or other limitations) for a particular merchant or set or merchants. Later, when the buyer clicks buy on the merchant's website, the purchase process is completed immediately (assumed consent) if the offer price is within the spending limit (and/or other limitations).
  • PROPOSAL: Response to Dave Longley: This is largely a duplicate of the pay-as-you-go token use case, the only bit that we could add to the pay-as-you-go use case is the ("and/or other limitations") language.