- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Wed, 24 Jun 2015 13:41:15 +0200
- To: David Jackson <david.dj.jackson@oracle.com>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, Web Payments IG <public-webpayments-ig@w3.org>
- Message-ID: <CA+eFz_Luj_uHw3_8FPjgWVHJm0YekeZPYJNWt7W=y0QDWAwBLA@mail.gmail.com>
There is an essential pre-payment step and that is the registration, by the payer, of the payment schemes and instruments they would like to use. I don't believe, within the v1 scope, that we will be able to recommend a process of finding the intersection of payee and payer schemes and instruments that involves "discovery" in the true sense of the word. i.e. To be "discovered" a scheme or instrument must have been registered explicitly by the user. We will describe a best practice algorithm for finding this intersection (possibly incorporating user preferences for priority and defaults). The algorithm MUST not prevent any scheme from being available as a candidate for registration AND for this matching/discovery process. i.e. It shouldn't be possible for the browser (or any other component that executes this discovery process) to exclude schemes or instruments on the basis of anything but technical incompatibility. Following registration I see the flow as being initiated by the presentation of a payment request by the payee (via their Web site or application) to the payer (via a browser API or other non-browser interface). The flow concludes with the both the payer and payee receiving a proof of payment. I am working to refine it but this is all already defined in the draft charter: https://www.w3.org/Payments/IG/wiki/Roadmap/PaymentArchitectureWG On 23 June 2015 at 22:11, David Jackson <david.dj.jackson@oracle.com> wrote: > Initiating function -- just pick a word and define it as such. And ending > state -- pick a word for that and define it. Therefore, we have a beginning > and end. :) > > -- > > David Jackson | Senior Director Financial Services > Mobile: +1.614.560.1237 | VOIP: +1.614.465.6654 > Oracle Industry Solutions Group > New York City | Columbus > > Oracle is committed to developing practices and products that help protect > the environment > > > -----Original Message----- > From: Manu Sporny [mailto:msporny@digitalbazaar.com] > Sent: Tuesday, June 23, 2015 3:47 PM > To: public-webpayments-ig@w3.org > Subject: Re: need reason description for exclusion of UseCase v1 > > On 06/23/2015 03:11 PM, Dave Raggett wrote: > > In my talk [1], I was careful to avoid the term wallet given that > > people differ in what they think it means, and instead referred to the > > roles for specific tasks, e.g. selection agent, receipt agent and > > payment instrument. For V1, we can ignore the receipt agent, and > > just talk about the selection agent and payment instrument. We can > > leave “wallet” until later, and I expect that when we want to allow > > one agent to performs multiple roles, then we want indeed want to try > > to use the term wallet for such agents. > > +1, revisiting the "wallet" terminology debate feels like it'll prevent > us from getting more pressing things done. > > While the "______ agent" terminology is a bit awkward to use, I have a > better idea of what it means than "wallet". > > -- manu > > -- > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) > Founder/CEO - Digital Bazaar, Inc. > blog: Web Payments: The Architect, the Sage, and the Moral Voice > https://manu.sporny.org/2015/payments-collaboration/ > > >
Received on Wednesday, 24 June 2015 11:41:44 UTC