Re: VOTE: Revised Payment Initiation / Wallet Web Payments Workshop Use Cases

Actually for that matter, another way might be to add a vote function to cimba.co... :).  Anyhow.

Sent from my iPad

> On 19 Jul 2014, at 4:00 am, Timothy Holborn <timothy.holborn@gmail.com> wrote:
> 
> Your time on it is very much appreciated.   Good idea to get onto it too..
> 
> Separately? I do think we should be using / improving some of the tools we're so passionate about, especially when we can improve what we're doing, but using them...
> 
> But - I very much appreciate the time thing... 
> 
> Sent from my iPad
> 
>> On 19 Jul 2014, at 3:57 am, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
>> 
>> 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
>>