Re: Payments Use Cases / Suggestions for Interest Group from Brent Shambaugh

On 12/5/14 10:07 AM, Timothy Holborn wrote:
> +1  great work.  really useful dot points (which are always more 
> difficult to build, than they are to read, when done well :) )
>
> On 5 December 2014 at 12:43, Manu Sporny <msporny@digitalbazaar.com 
> <mailto:msporny@digitalbazaar.com>> wrote:
>
>     These are a set of requirements and use cases that Brent Shambaugh
>     (of the Web Payments CG and Web and Mobile CG) has been
>     collecting/analyzing over the past year. Brent offered to send
>     these into the group on this past week's Web Payments CG call for
>     the purpose of forwarding them to the IG. We already have some of
>     them covered, others we don't have covered at all. For example,
>     the VRM principles out of Doc Searls' group at Harvard is
>     something Joerg mentioned at the Web Payments F2F, but we failed
>     to note in detail. Good stuff, we should take a look at it.
>
>     The original email from Brent can be found here:
>
>     http://lists.w3.org/Archives/Public/public-webpayments/2014Dec/0006.html
>
>     --------------------------------------------------------------------------
>
>     1.
>
>         Allow the use of multiple devices
>
>     2.
>
>         Allow the use of SMS both for notifcations and for payments
>
>     3.
>
>         Decentralize the payment authority and allow for peer-to-peer
>         payments. Decentralized domain name system.
>
>     4.
>
>         Allow pre-authorization of a single payment, or multiple payments.
>
>     5.
>
>         Automated recurring payments.
>
>     6.
>
>         Encrpyt information if it is stored on a centralized server.
>
>     7.
>
>         Risk and anti-fraud screening.
>
>     8.
>
>         Support having no account history with vendor.
>
>     9.
>
>         Support anonymous payments.
>
>    10.
>
>         Support machine readable data that is distributed.
>
>    11.
>
>         Support metadata attached to content, such as licenses, asset
>         information (e.g. description, pricining), obligations to
>         other agents...etc..
>
>    12.
>
>         Support automated vending when identity proven.
>
>    13.
>
>         Separate content from licenses.
>
>    14.
>
>         Support VRM principles for customer-vendor relationships
>
>      *
>
>         Customers must enter relationships with vendors as
>         *independent actors*.
>
>      *
>
>         Customers must be the *points of integration for their own data*.
>
>      *
>
>         Customers must have *control of data they generate and
>         gather*. This means they must be able to share data
>         selectively and voluntarily.
>
>      *
>
>         Customers must be able to *assert their own terms of engagement*.
>
>      *
>
>         Customers must be *free to express their demands and
>         intentions outside of any one company's control*.
>
>         /(http://cyber.law.harvard.edu/projectvrm/Main_Page)/
>
>    14.
>
>         Customers should only pay when the transaction closes
>
>    15.
>
>         For large payment amounts, enable two-factor authentication
>
>    16.
>
>         Support web browser and in-app payments
>
>    17.
>
>         Allow agents to make multiple payments in one action
>
>    18.
>
>         Allow agents to receive loans or payments from multiple other
>         agents
>
>    19.
>
>         Support offline mobile to mobile payments
>
>    20.
>
>         Allow agents to accept and receive payments to particular
>         destinations.
>
>    21.
>
>         Skip signatures for small payments
>
>    22.
>
>         Allow for bank issued identification
>
>    23.
>
>         Support instant (or near instant) settlement of transactions
>
>    24.
>
>         Allow editing of business and accounting information
>
>    25.
>
>         Allow for many forms of authentication of identity (including
>         possible futures). (e.g. Authenticate payments with brain
>         waves (EEG)).
>
>    26.
>
>         Allow for chargebacks (refunds due to error)
>
>    27.
>
>         Support all currencies, all cards, and all bank accounts
>
>    28.
>
>         Allow wallet to be interoperable with other wallets.
>
>    29.
>
>         Allow payment network to be interoperable with other payment
>         networks.
>
>    30.
>
>         Allow user issued pseudo-currency. Issue securities and tokens
>         of any kind.
>
>    31.
>
>         Support micropayments.
>
>    32.
>
>         List things purchased (digital receipts). Verifiable recipts.
>
>    33.
>
>         Use tokens in place of card numbers. Avoid revealing bank and
>         credit information.
>
>    34.
>
>         Allow for time delayed transactions. Hold funds in escrow
>         until transaction occurs.
>
>    35.
>
>         Distribute public key for communication.
>
>    36.
>
>         Give IDs to each object in payments.
>
>    37.
>
>         Initiate and request transactions.
>
>    38.
>
>         Refund debits, reverse credits.
>
>    39.
>
>         Support billing through subscriptions.
>
>    40.
>
>         Give a record of debts for each billing period.
>
>    41.
>
>         Buy and sell debt on the open market.
>
>    42.
>
>         Keep a balance.
>
>    43.
>
>         Include an API.
>
>    44.
>
>         Retry failed payments.
>
>    45.
>
>         PCI Compliance.
>
>    46.
>
>         Pay for items before entering store.
>
>    47.
>
>         Store information to avoid re-entering.
>
>    48.
>
>         Apply and store gifts, credits, and coupons.
>
>    49.
>
>         REST compliance.
>
>    50.
>
>         Support irreversible transactions.
>
>     51. Allow automated conversion of currency or pseudo-currency so
>         each agent receives their preferred one.
>

All good, but note point #16, where you have browsers and in-app 
purchases. That's two distinct kinds of HTTP user-agents. Mobile 
platforms don't depend on browsers (one kind of user-agent)  for HTTP 
client-server communications. Thus, its important to note that payments 
processing over HTTP MUST be abstracted in a manner to reflects user 
agent diversity.

We have:

[1] [Browser App [ OS Cryto API [ OS Cryto Services ]]] -- HTTPS --> 
[Some HTTPS Server ]
[2] [Other Apps [ OS Cryto API [ OS Cryto Services ]]] -- HTTPS --> 
[Some HTTPS  Server ] .

On mobile platforms (which are #2 oriented), you can even have 
app-specific-url as a mechanism for referencing and accessing data. That 
isn't the case when your sole user agent is a Browser where support for 
custom URL functionality varies, in the best case scenario.

In a sense, Mobile Platforms offer better exploitation of URIs, URLs, 
and HTTP than desktops which are trapped and controlled by browser 
idiosyncrasies and politics. Ironically, these Mobile Platform virtues 
are seen as replacing the Web when all they are actually doing is 
enhancing the Web :)

Web Browser dominance on the Desktop, as prime entry point for URI, URL, 
HTTP exploitation, has lead to a misconceived notion of the Web in which 
HTML, URIs, URLs, and RDF language are all mangled in a box of 
architectural confusion :(


-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this