- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Fri, 18 Jul 2014 19:57:25 +0200
- To: Timothy Holborn <timothy.holborn@gmail.com>
- Cc: Joseph Potvin <jpotvin@opman.ca>, Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CA+eFz_Ju=pVCAxkU+GVD8iwA_EhzB1BUs=FH3-T=aux0upRa0w@mail.gmail.com>
Getting on a plane now but have a look and let me know if this format will work. https://docs.google.com/a/hopebailie.com/forms/d/1_vuxlxdL0MCf5eudEG--2kJFUbcYFPvhvzYT3OSOxRw/viewform Will add all use cases later today On 18 July 2014 19:51, Timothy Holborn <timothy.holborn@gmail.com> wrote: > FYI - https://ld-cal.rww.io/ > > Sent from my iPad > > On 19 Jul 2014, at 3:47 am, Adrian Hope-Bailie <adrian@hopebailie.com> > wrote: > > Will throw a quick sample together on a Google Form and share the link. > If you we're all happy I will add all of the use cases. > > > On 18 July 2014 19:42, Joseph Potvin <jpotvin@opman.ca> wrote: > >> ... 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:57:54 UTC