- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Fri, 18 Jul 2014 13:42:11 -0400
- To: Timothy Holborn <timothy.holborn@gmail.com>
- Cc: Web Payments CG <public-webpayments@w3.org>
... actually, the options ought to be - In favor for v1.0 - In favor for later version - Opposed - Open-ended text field for comments/suggestions On Fri, Jul 18, 2014 at 1:38 PM, Timothy Holborn <timothy.holborn@gmail.com> wrote: > > > Sent from my iPad > >> On 19 Jul 2014, at 3:35 am, Joseph Potvin <jpotvin@opman.ca> wrote: >> >> I'd offer to put it up, but am overcommitted presently. >> >> Each item should have, I think, radio buttons foy Y/N, plus an >> open-ended text field for comments. >> > +1 and use some basic formatting for the output, like csv - good for importing into a spreadsheet... > >> Joseph >> >>> On Fri, Jul 18, 2014 at 1:27 PM, Tim Holborn <timothy.holborn@gmail.com> wrote: >>> Nice Idea. >>> >>> Could simply be a form that’s run on rww.io / data.fm - mind, people would need to get a WebID (cimba.co makes that simple…) >>> >>>> On 19 Jul 2014, at 3:08 am, Joseph Potvin <jpotvin@opman.ca> wrote: >>>> >>>> Is anybody in this GC running an instance of LimeSurvey or equivalent >>>> that we might conduct a more efficient poll on, or use SurveyMonkey? >>>> (Or did I miss something about that?) >>>> >>>> Joseph >>>> >>>> On Fri, Jul 18, 2014 at 12:14 PM, Adrian Hope-Bailie >>>> <adrian@hopebailie.com> wrote: >>>>> Use Case: Customer selects item to purchase on merchant's site, merchant >>>>> generates a purchase request that will be processed by the customer's >>>>> payment processor. >>>>> +1 >>>>> >>>>> Use Case: A developer can create a link with a specific “attribute (custom >>>>> URI >>>>> scheme or rel type)” such that when a customer clicks on it, the customer's >>>>> payment >>>>> processor starts the payment process. >>>>> +1 Updated use case - Is URI scheme the only way to do this? >>>>> >>>>> 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. >>>>> +1 >>>>> >>>>> Use Case: A merchant advertises different details, such as price, for an >>>>> offer of sale based on potential payment processor choice. >>>>> +1 >>>>> >>>>> Use Case: A customer can associate a membership card, coupon, or similar >>>>> token with a transaction to receive a discount or other benefits. >>>>> +0 For later iterations >>>>> >>>>> Use Case: Leveraging variable degrees of identity/anonymity per >>>>> requirements of the payment transaction. >>>>> +0 For later iterations >>>>> >>>>> Use Case: A customer 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 customer 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. >>>>> +1 >>>>> >>>>> Use Case: A customer uses a native non-browser application on their >>>>> mobile phone or tablet, or a web browser to make a purchase at an app store. >>>>> +1 >>>>> >>>>> >>>>> Use Case: A customer makes a purchase from within an application for >>>>> premium content, virtual goods, or subscriptions. >>>>> +1 >>>>> >>>>> >>>>> 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. >>>>> +1 >>>>> >>>>> Use Case: The customer 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 customer chooses which >>>>> information to share with the merchant which the merchant then uses to >>>>> uniquely identify the customer if they perform any repeat purchases. >>>>> +0 For later iterations >>>>> >>>>> Use Case: A customer goes to a website and is presented with a payment >>>>> UI from their payment processor. The purchase can be completed without >>>>> any additional information from the customer other than their consent to >>>>> complete the purchase. >>>>> +1 >>>>> >>>>> Use Case: A customer goes to a merchant website, and upon initiating a >>>>> payment, the merchant's software transmits the merchant's payment >>>>> processor options to the customer's software. The customer's software >>>>> presents a choice of payment processors the customer has previously >>>>> registered with that are compatible with the merchant's payment processors. >>>>> +1 >>>>> >>>>> Use Case: A customer visits a merchant's website and initiates a >>>>> payment. Their payment processor presents them with an option to >>>>> subscribe or add a pay-as-you-go token for future purchases from the >>>>> merchant. >>>>> +1 >>>>> >>>>> 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. >>>>> +1 >>>>> >>>>> Use Case: A customer stores their wallet, credentials, and digital >>>>> receipts with a particular identity/wallet/data storage provider. The >>>>> customer decides to switch to a different identity/wallet/data storage >>>>> provider and all of their wallet, receipt, and credential data comes >>>>> with them. >>>>> +1 >>>>> >>>>> Design Criteria: Require data portability for customer financial data >>>>> and identity data that is required for core transaction functionality. >>>>> +1 >>>>> >>>>> 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.) >>>>> +1 >>>>> >>>>> Design Criteria: Don't prevent multiple levels of security based on the >>>>> type of transaction being performed. No auth for small amounts, PIN auth >>>>> for medium amounts, Secure Element for large amounts. >>>>> +1 >>>>> >>>>> Design Criteria: Don't prevent the implementation of simple digital >>>>> contracts and smart contracts. >>>>> +1 >>>>> >>>>> >>>>> >>>>>> On 17 July 2014 03:51, Manu Sporny <msporny@digitalbazaar.com> wrote: >>>>>> >>>>>> Please +1/+0/-1 each payment initiation / wallet use case below in order >>>>>> to show whether or not you agree that we should try and attempt >>>>>> addressing the use case in the first iteration of the Web Payments work. >>>>>> If you +0 or -1 the use case, please specify why as well as changes that >>>>>> could be made that would result in you +1'ing the use case. >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> Use Case: Customer selects item to purchase on merchant's site, merchant >>>>>> generates a purchase request that will be processed by the customer's >>>>>> payment processor. >>>>>> >>>>>> Use Case: A developer can create a link with a specific payment URI >>>>>> scheme such that when a customer clicks on it, the customer's payment >>>>>> processor starts the payment process. >>>>>> >>>>>> 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. >>>>>> >>>>>> Use Case: A merchant advertises different details, such as price, for an >>>>>> offer of sale based on potential payment processor choice. >>>>>> >>>>>> Use Case: A customer can associate a membership card, coupon, or similar >>>>>> token with a transaction to receive a discount or other benefits. >>>>>> >>>>>> Use Case: Leveraging variable degrees of identity/anonymity per >>>>>> requirements of the payment transaction. >>>>>> >>>>>> Use Case: A customer 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 customer 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. >>>>>> >>>>>> Use Case: A customer uses a native non-browser application on their >>>>>> mobile phone or tablet, or a web browser to make a purchase at an app >>>>>> store. >>>>>> >>>>>> Use Case: A customer makes a purchase from within an application for >>>>>> premium content, virtual goods, or subscriptions. >>>>>> >>>>>> 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 customer 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 customer chooses which >>>>>> information to share with the merchant which the merchant then uses to >>>>>> uniquely identify the customer if they perform any repeat purchases. >>>>>> >>>>>> Use Case: A customer goes to a website and is presented with a payment >>>>>> UI from their payment processor. The purchase can be completed without >>>>>> any additional information from the customer other than their consent to >>>>>> complete the purchase. >>>>>> >>>>>> Use Case: A customer goes to a merchant website, and upon initiating a >>>>>> payment, the merchant's software transmits the merchant's payment >>>>>> processor options to the customer's software. The customer's software >>>>>> presents a choice of payment processors the customer has previously >>>>>> registered with that are compatible with the merchant's payment >>>>>> processors. >>>>>> >>>>>> Use Case: A customer visits a merchant's website and initiates a >>>>>> payment. Their payment processor presents them with an option to >>>>>> subscribe or add a pay-as-you-go token for future purchases from the >>>>>> merchant. >>>>>> >>>>>> 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: A customer stores their wallet, credentials, and digital >>>>>> receipts with a particular identity/wallet/data storage provider. The >>>>>> customer decides to switch to a different identity/wallet/data storage >>>>>> provider and all of their wallet, receipt, and credential data comes >>>>>> with them. >>>>>> >>>>>> Design Criteria: Require data portability for customer financial data >>>>>> and identity data 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.) >>>>>> >>>>>> Design Criteria: Don't prevent multiple levels of security based on the >>>>>> type of transaction being performed. No auth for small amounts, PIN auth >>>>>> for medium amounts, Secure Element for large amounts. >>>>>> >>>>>> Design Criteria: Don't prevent the implementation of simple digital >>>>>> contracts and smart contracts. >>>>>> >>>>>> -- manu >>>>>> >>>>>> -- >>>>>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >>>>>> Founder/CEO - Digital Bazaar, Inc. >>>>>> blog: The Marathonic Dawn of Web Payments >>>>>> http://manu.sporny.org/2014/dawn-of-web-payments/ >>>> >>>> >>>> >>>> -- >>>> Joseph Potvin >>>> Operations Manager | Gestionnaire des opérations >>>> The Opman Company | La compagnie Opman >>>> jpotvin@opman.ca >>>> Mobile: 819-593-5983 >> >> >> >> -- >> Joseph Potvin >> Operations Manager | Gestionnaire des opérations >> The Opman Company | La compagnie Opman >> jpotvin@opman.ca >> Mobile: 819-593-5983 -- Joseph Potvin Operations Manager | Gestionnaire des opérations The Opman Company | La compagnie Opman jpotvin@opman.ca Mobile: 819-593-5983
Received on Friday, 18 July 2014 17:43:00 UTC