Web Payments Community Group Telecon

Minutes for 2014-09-24

Dave Longley is scribing.
Manu Sporny: We're doing a use case super-session today to get all of these use cases into a position where the Web Payments CG can vote on whether or not we want to use them, etc.
Manu Sporny: Then we can take them to the Web Payments IG as input to help speed things along.
Manu Sporny: There are seven use cases left and hopefully we can get it done in 1.5 hours.
Manu Sporny: We'll put them into a document that can be voted on by the community after that.
Pindar Wong: All clear.
David I. Lehn: Sounds good.

Topic: W3C TPAC and Web Payments announcement

Pindar Wong: Sorry I won't be able to make this meeting if it proceeds at such short notice
Manu Sporny: I've got some good news from W3C TPAC -- an announcement.
Manu Sporny: The TPAC registration form now includes the Web Payments work
Pindar Wong: Excellent. Excellent Excellent
Pindar Wong: I'll inform those concerned in this part of the world!
Pindar Wong: In Asia Pacific that is
Manu Sporny: This is excellent news so we can finally tell people to register and we can get a count of the people who are attending for the Web Payments work.
Manu Sporny: We may want to make a lot of noise with the people who have already with TPAC to make sure to check that item if they want to join the Web Payments work.
Pindar Wong: Thanks to all ... this is now very clear
Pindar Wong: Back to use cases

Topic: Payment Processor Selection

Manu Sporny: First up is this use case: A buyer goes to a merchant website, and upon initiating a payment, the merchant's software transmits the merchant's payment processor options to the buyer's software. The buyer's software presents a choice of payment processors the buyer has previously registered with that are compatible with the merchant's payment processors.
Manu Sporny: Jorge's feedback: NASCAR problem
Manu Sporny: As with his other responses he doesn't understand that this is a solution to the NASCAR problem.
Manu Sporny: The payment processor choice information will be transmitted and only one button will be shown.
Dave Longley: Let's not say it will be one button, rather it will only be showing the options that the user is interested in, which will also likely be configurable (defaults, etc.) in their user agent.
Manu Sporny: Michael Williams' feedback: not sure how different from "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."
Manu Sporny: Michael is right, it's redundant
Dave Longley: Yeah, I agree. [scribe assist by Manu Sporny]
Pindar Wong: So we should scrap it right?
Dave Longley: Yes
Pindar Wong: OK.
Manu Sporny: Response to Jorge - There is agreement that this isn't a NASCAR problem, there seems to be some misunderstanding around how the system is intended to work.
Manu Sporny: Yes.
Manu Sporny: Response to Michael - Michael is correct, this does seem to duplicate 100% of the functionality expressed by the use case he refers to. We should strike this use case as a duplicate.

Topic: Wallet Portability

Manu Sporny: Next use case is - An entity (payer, payee, merchant, buyer) stores their wallet, credentials, and digital receipts with a particular identity/wallet/data storage provider. The entity decides to switch to a different identity/wallet/data storage provider and all of their wallet, receipt, and credential data comes with them.
Manu Sporny: Jorge's feedback - the capability of switching wallet hosting providers would be great, but I guess it would be hard to achieve if there is balance to be transferred that would imply one provider sending actual money to another.
Dave Longley: We missed a use case -- we can go back to that one after this one.
Manu Sporny: In the future if we're going to be able to do clearing in an immediate manner, then that means that this capability that money moves with all the other information has to hold. The technology we have right now can transfer all the information because it's all linked information, so we have mechanisms to transmit that or we don't think they are that difficult to create, and if we have a system to do clearing that actually moves money from one payment processor to another then the use case can be achievable.
Pindar Wong: Just because you can does it mean you should?
Pindar Wong: Unintended consequences?
Evgeny Vinogradov: One of the possibilities ... when you are recording payments, merchants can store other information -- so if we remove the word "their" then that opens up the use case.
Manu Sporny: Now the use case reads: An entity (payer, payee, merchant, buyer) stores wallet, credentials, and digital receipts with a particular identity/wallet/data storage provider. The entity decides to switch to a different identity/wallet/data storage provider and all wallet, receipt, and credential data comes with them.
Manu Sporny: Evgeny, does that updated text work for you?
Evgeny Vinogradov: Yes.
Pindar Wong: OK... I think I understand what just happened and am fine with removal of 'their'

Topic: Payment Tokens

Manu Sporny: Next use case - A buyer 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.
Manu Sporny: This is effectively tokenization, it's a way to support subscription.
Manu Sporny: Jorge's feedback - Pay-as-you-go tokens sound good, but what about choosing the payment processor first?
Manu Sporny: We have other use cases for choosing the payment processor.
Pindar Wong: OK
Dave Longley: Separation of concerns; this is an additional featur.e
Dave Longley: Yes, there is a separation of concerns here - pay as you go token is separate from choosing your payment processor [scribe assist by Manu Sporny]
Manu Sporny: Response to Jorge - The selection of the payment process is handled by the following Use Case: When a payee 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/payee.
Dave Longley: This is also more than subscription.
Timothy Holborn: Is pay-as-you-go different from subscribe? [scribe assist by Manu Sporny]
Pindar Wong: No zero balance?
Dave Longley: Pay-as-you-go could be viewed as subscribe, but viewed as something else. As you pay for things on the website, you're willing to give additional confirmation steps. That's slightly different from subscribe, which is that you're signing up for a membership that will be charged to your account every so often, you could use pay-as-you-go to authorize subscription. [scribe assist by Manu Sporny]
Dave Longley: You could implement this a variety of ways - you go to buy something on the site, your payment processor gives you the option to pre-authorize up to $10/month in transactions from the merchant/site. [scribe assist by Manu Sporny]
Dave Longley: You could also hand over a payment token to the merchant, so different ways to do it. [scribe assist by Manu Sporny]
Timothy Holborn: Subscribe is usually a monthly recurring charge, you agree to a certain amount to be withdrawn from you account on a certain interval. [scribe assist by Manu Sporny]
Timothy Holborn: Pay as you go could be done in an ad-hoc manner. Those are potentially two separate products. [scribe assist by Manu Sporny]
Dave Longley: Those are two different products, my only point is that they can be implemented using the same mechanism. [scribe assist by Manu Sporny]
Timothy Holborn: Subscription usually refers to a monthly reoccuring charge, you agree to some amount being taken out periodically. Pay-as-you-go is more like you pay when you use a product.
Manu Sporny: I agree with Dave in that we found that when we went to implement this they work in the same way, but at a high-level we should say there are two use cases.
Pindar Wong: Agree with manu's description to clarify the two different 'use' cases regardless that they may be imlemented the same way
Dave Longley: I still want you to show me a receipt when a purchase happens vs. I don't want to be shown a receipt, just do the purchase behind the scenes. [scribe assist by Manu Sporny]
Timothy Holborn: A subscription is a periodic basis, the other kind is a non-periodic basis (maybe with a cap) [scribe assist by Manu Sporny]
Timothy Holborn: Is a payment processor required to make a transfer that then gives credits? Rather than offer pay as you go. [scribe assist by Manu Sporny]
Manu Sporny: Let's split the use case because it confuses what we're trying to do.
Manu Sporny: One will be for a regular subscription, where the customer isn't informed asked for payment, the other is pay-as-you-go the customer needs to be shown a receipt or asked if it's ok to send the money.
Pindar Wong: Yup
Timothy Holborn: +1
Pindar Wong: +1
Manu Sporny: So, here's the first part of the split use case - A buyer visits a merchant's website and initiates a payment. Their payment processor presents them with an option to subscribe to a merchant's product or service, which will result in periodic payments at a known value to the merchant.
Pindar Wong: Works for me
Timothy Holborn: +1
Dave Longley: +1
Timothy Holborn: Actually, agreed valued.
Timothy Holborn: Or known value to the merchant? does this mean the customer knows the value too?
Dave Longley: There is a distinction between these two uses cases, when you're doing a subscription - you're pushing to merchants account. With pay-as-you-go, merchant pulls money from customer. [scribe assist by Manu Sporny]
Dave Longley: With in-app payments, it's the merchant that's going to be requesting payment. The token has to exist, the merchant is going to be using a back-end payment initiation request, which uses the token. [scribe assist by Manu Sporny]
Timothy Holborn: Is it similar to a credit card? [scribe assist by Manu Sporny]
Dave Longley: In this case, you're not transmitting credit card information to the merchant. [scribe assist by Manu Sporny]
Timothy Holborn: Is this a limitless pay as you go token? [scribe assist by Manu Sporny]
Dave Longley: We're not at all suggesting it should be limitless. There are some set of parameters that have to be met. For example, "This pay as you go token is limited to $10/month" [scribe assist by Manu Sporny]
Dave Longley: There could be other parameters that fit in there as well, it's definitely not limitless. [scribe assist by Manu Sporny]
Timothy Holborn: In the credit card world, they can preauthorize, limit up to a certain amount. [scribe assist by Manu Sporny]
Dave Longley: That's not what preauth does, preauth puts funds aside for the merchant. It's not intended to do what we're talking about here. [scribe assist by Manu Sporny]
Pindar Wong: Sorry I'm lost. What's the problem?
Dave Longley: We could say it's similar, we can't say it's a precedent, but we can't say it's the same thing. [scribe assist by Manu Sporny]
Manu Sporny: Credit card preauth is a hold of funds to ensure the merchant can get their funds. It's not the same thing as the pay-as-you-go thing we're discussing right now.
Dave Longley: It prevents the customer from being able to spend their own credit.
Manu Sporny: Here the merchant isn't placing a hold on the funds, but they are able to charge up to, for instance, $10/month.
Timothy Holborn: Is there a clearing issue here?
Manu Sporny: The credit card issue is a merchant business model issue -- the idea is to put a hold on some amount of money to ensure the merchant can collect their funds. The merchant can hold those funds between when the customer says they intend to purchase and when they actually do -- or they can delay shipment, etc. this gets complicated, etc.
Dave Longley: This is intended to work almost exactly the same way as an interactive purchase. It's designed to be a non-interactive way of buying. You're just skipping some steps here. [scribe assist by Manu Sporny]
Pindar Wong: Make a side note w.r.t. hold of funds
Pindar Wong: Kick it to the IG
Dave Longley: We've had discussions about escrow wrt. hold on funds, etc. We dont' have use cases for it yet. [scribe assist by Manu Sporny]
Pindar Wong: Good point Tim.
Manu Sporny: Ok, let's make a side note that we don't have that use case and then head back to the current use case.
Manu Sporny: So, here's the split use case - A buyer visits a merchant's website and initiates a payment. Their payment processor presents them with an option to assign a pay-as-you-go token with a specific spending limit for future purchases with the merchant. An option is also presented to require the display of a receipt when a purchase occurs, or to perform the purchase in the background with no display of the purchase process.
Timothy Holborn: +1
Dave Longley: +1
Pindar Wong: +1
Pindar Wong: Do we say no display or no interaction?
Pindar Wong: Thanks
Timothy Holborn: :)
Pindar Wong: No interruptive display
Dave Longley: What about in-app purchase process - it could be non-interactive wrt. the payment processor, but interactive wrt. the game. [scribe assist by Manu Sporny]
Timothy Holborn: Not required.
Timothy Holborn: Ie: optional
Pindar Wong: I like it
Manu Sporny: So, new language - A buyer visits a merchant's website and initiates a payment. Their payment processor presents them with an option to assign a pay-as-you-go token with a specific spending limit for future purchases with the merchant. An option is also presented to require the display of a receipt when a purchase occurs, or to perform the purchase in the background with no interactive purchase process required.
Pindar Wong: Don't forget this is a huge business
Pindar Wong: +1
Dave Longley: +1
Pindar Wong: If the parent sets it up then it should be fine
Manu Sporny: We looked into this quite a bit, there are number of online child protection acts, etc. assuming we meet those regulations, parents can set up children with certain accounts with amounts of money or they can assign pay-as-you-go tokens with spending limits to their children, and optionally the payment processor can send some kind of notification (email/text) when purchases happen so parents can follow purchase history.
Timothy Holborn: What about authorization aspect?
Manu Sporny: There is always an authorization aspect, and there are multiple ways to handle it, I think we cover them, subscription, pay-as-you-go, etc. and on top of that you can do "notify me when this token is used, etc."
Manu Sporny: All those things build off of these base use cases and are value adds that a payment processor can do.
Manu Sporny: What I thought you might be saying is "Why don't we add use cases for children spending limits, etc." but I don't know if that would buy us much except that people know it works for that sort of use case.
Pindar Wong: You can build on these base use cases
Pindar Wong: For other cases that we've not thought of yet or models that have yet to emerge
Timothy Holborn: I was just saying parents may not want to allow children to use these preauthorized tokens (?).

Topic: Legacy Payment Systems

Manu Sporny: Next up - 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.)
Manu Sporny: Jorge's feedback - Compatibility is always good, but sometimes complicated, and even more for the entry-level payment provider trying to achieve PCI compliance. Excluding SMS, this is very high-end, and doesn't apply to the 2.5 billion unbanked.
Manu Sporny: While true, focusing on 2.5 billion unbanked is important.
Timothy Holborn: With the micro-payment (pre-authorisation) use-case, whilst in many use-cases of that particular high-level use-case - the user may not want to be bothered. one area of use-cases, may be children using a game that has ‘in-app’ purchases; in which case, authorisation may be required (by the parent, for example.). Sounds like we’ve got that covered in other areas though. (per discussion with Manu.. ) [scribe assist by Timothy Holborn]
Dave Longley: One comment in response to entry level payment providers, we are not saying a payment provider MUST support legacy payment systems... they may support legacy ones, they may not. [scribe assist by Manu Sporny]
Pindar Wong: Agree with must->may finesse
Manu Sporny: If a payment processor wants to come online and only support bitcoin, that's fine. If one wants to support the full array of options including shipping gold bullion, they may do so.
Manu Sporny: Response to Jorge - Focusing on the 2.5B unbanked is a priority for the group, but in order to get traction, we can't ignore also supporting legacy systems. We believe this is achievable given the right level of abstraction, and have experimental software implementation proofs of concept to demonstrate integration with legacy systems.
Pindar Wong: Yup
Timothy Holborn: +1
Dave Longley: It's fine, I do think we should mention it being difficult for new payment processors. we should mention that it's not required for new payment processors to support older legacy systems, and if they did support it it would be compatible. [scribe assist by Manu Sporny]
Pindar Wong: I'm not comfortable with the defniion of 'new'
Timothy Holborn: How about emerging?
Dave Longley: We can use "entry-level" like Jorge said.
Manu Sporny: This is what we have now - Response to Jorge - Focusing on the 2.5B unbanked is a priority for the group, but in order to get traction, we can't ignore also supporting legacy systems. We believe this is achievable given the right level of abstraction, and have experimental software implementation proofs of concept to demonstrate integration with legacy systems. We are not saying a payment provider MUST support legacy payment systems. They may support legacy ones, they may not.
Pindar Wong: I like this much better
Dave Longley: +1

Topic: Multiple authorization levels

Manu Sporny: Currently we have: Do not 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.
Manu Sporny: Steven Rowat and Michael's feedback is: would it be possible to avoid the opening double negative, say by using a single positive, such as "Allow multiple levels..." and "Allow the implementation..." ?
Manu Sporny: Basically, changing it to this: Design Criteria: Allow 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.
Dave Longley: We explicitly chose the double negative, we didn't want to prevent it, we didn't want to put it in the spec. [scribe assist by Manu Sporny]
Dave Longley: "Allow payment processors to choose to use multiple levels..."
Manu Sporny: This is what I put in there - Allow payment processors to choose to use multiple levels of security based on the type of transaction being performed. For example: No auth for small amounts, PIN auth for medium amounts, Secure Element for large amounts.
Dave Longley: Allow payment processors to optionally define multiple levels of required authorization based on the type of transaction being performed. No auth for small amounts, PIN auth for medium amounts, Secure Element for large amounts.
Timothy Holborn: “Allow payment processor to define multiple levels of security based on the type of transaction being performed."
Pindar Wong: Still thinking
Dave Longley: "Allow payment processors to define the required level of authorization for particular transactions based on their preferences and local regulations."
Manu Sporny: I have no strong feelings, Dave's may be overly specific, Tim's is less specific, don't know if that's good.. [scribe assist by Manu Sporny]
Pindar Wong: Define could be zero
Pindar Wong: OK ... that works for me
Manu Sporny: So, this is what we're settling on? Design Criteria: Allow payment processors to define the required level of authorization for particular transactions based on their preferences and local regulations. For example: No auth for small amounts, PIN auth for medium amounts, Secure Element for large amounts.
Dave Longley: +1
Pindar Wong: +1
Timothy Holborn: +1
David I. Lehn: +1

Topic: Smart Contracts

Manu Sporny: We currently have - Design Criteria: Do not prevent the implementation of simple digital contracts and smart contracts.
Timothy Holborn: ECHO - if not talking please mute MIC
Manu Sporny: Steven Rowat's feedback - Would it be possible to avoid the opening double negative, say by using a single positive, such as "Allow multiple levels..." and "Allow the implementation..." ?
Manu Sporny: Michael Williams's feedback - double negative "don't prevent" is confusing, maybe allow?
Dave Longley: "Ensure the technology permits the optional implementation of simple digital contracts and smart contracts."
Evgeny Vinogradov: Let's not forget that there are other partners that may require authorization, let's not restrict it to just payment processors. [scribe assist by Manu Sporny]
Pindar Wong: Very good point
Evgeny Vinogradov: So, we shouldn't use 'choose', we should use 'define' because it enables payment processors to create new mechanisms of authorization. [scribe assist by Manu Sporny]
Pindar Wong: Can you paste the text?
Manu Sporny: Pindar, currently we have - Design Criteria: Ensure the technology allows the optional implementation of simple digital contracts and smart contracts.
Timothy Holborn: What about 'support'? [scribe assist by Manu Sporny]
Dave Longley: We specifically don't want to do that because we don't want to build that into this version of the technology. [scribe assist by Manu Sporny]
Dave Longley: "Ensure the technology allows simple digital contracts or smart contracts to be layered on top of it" ?
Pindar Wong: Thanks
Dave Longley: Trying to think about a way of saying "Does not restrict". [scribe assist by Manu Sporny]
Timothy Holborn: We may want to specify that this goes w/ a particular release. [scribe assist by Manu Sporny]
Timothy Holborn: Smart contracts / parametric contracts may be with a future release. [scribe assist by Manu Sporny]
Dave Longley: "Ensure the technology can be later extended to support ..." ?
Dave Longley: "Ensure the technology can be extended or does not prohibit the implementation of..."?
Pindar Wong: Evolve
Manu Sporny: We want to build in a path of evolution like pindar says.
Dave Longley: We want people to be able to innovate on top of version 1 Web Payments technology, so the design criteria are a way of trying to get that to happen. [scribe assist by Manu Sporny]
Timothy Holborn: “Enable interoperability with digital contracts, parametric and smart contract projects with aligned design criteria'
Timothy Holborn: Um.
Manu Sporny: So, here's the current proposal: Ensure the technology can be extended or does not prohibit the implementation of simple digital contracts and smart contracts.
Pindar Wong: I like the last version of Dave's text
Pindar Wong: OK works for me
Dave Longley: +1
Pindar Wong: +1
Timothy Holborn: +1

Topic: Machine-readable licenses

Manu Sporny: We currently have Use Case: A payer purchases access to a service on a payee's website. Included in their digital receipt is a machine-readable license (rights and responsibilities) that indicates what kind of access they've been granted and for how long. The payee can use this machine-readable license to enforce access to the service.
Manu Sporny: Feedback from Adrian is that this shouldn't be a version 1.0 feature.
Manu Sporny: Response to Adrian could be -While it isn't required for the first iteration, the use case can be achieved via a single vocabulary term and URL in the digital receipt. The group shouldn't attempt to define the vocabulary terminology to express the machine-readable license, but rather provide a hook for another group such as the ODRL community or Creative Commons to define what this looks vocabulary looks like.
Timothy Holborn: Did we miss: “ A payment processor tracks mandatory financial regulatory events and submits machine-readable information to a regulator-provided URL to automatically meet regulatory compliance.”
Dave Longley: I think we might want to mention that JSON-LD has a lot to do with this use case. We use a technology that allows domain-specific vocabularies to be included into digital receipts, there's not much that needs to be done to achieve the use case. [scribe assist by Manu Sporny]
Pindar Wong: One of the problems is that the capabilities of JSON-LD is not widely known (yet)
Manu Sporny: It makes it sound like we are going to define the license/rights vocabulary. [scribe assist by Manu Sporny]
Dave Longley: Maybe this should be a design criteria instead of a use case. [scribe assist by Manu Sporny]
Pindar Wong: Agree that it should be a design criteria
Pindar Wong: Smart move
Pindar Wong: For tading in virtual goods for example
Dave Longley: "Allow the digital receipt format to include domain-specific vocabulary information to support use cases such as including machine-readable license information that can be later used to obtain access to a service."
Timothy Holborn: Why are we being specific about licenses? Perishable goods are a bigger industry, why not them? For example, food needs to be tracked, this is about generic linked data expression in digital licenses. [scribe assist by Manu Sporny]
Pindar Wong: Yup ... I like this wording
Pindar Wong: GS-1 identifiers
Manu Sporny: So, this? Allow the digital receipt format to include domain-specific vocabulary information to support use cases such as including machine-readable licenses, nutrition and perishability information, UPC/GS1 identifiers, tax classification, and other information that can be later used to obtain access to a service.
Pindar Wong: These are just examples
Timothy Holborn: Some receipt examples are here (for later, offline review): https://nrf.com/resources/retail-technology-standards/xml-schemas
Manu Sporny: Response to Adrian - This was meant to be a general statement on the requirements around data model extensibility. The use case has been converted to a design criteria and been rewritten to capture the intent of the original use case.

Topic: Unclassified/Unreviewed use cases

Manu Sporny: I don't think we need to do anything about either one.
Manu Sporny: The first one is: When a customer intends to make a payment, it is possible to pick a payment processor trusted by the merchant as an intermediate proxy for a payment processor not trusted by the merchant.
Manu Sporny: This requires decentralized clearing which we don't have in here for v1.
Pindar Wong: Sorry... what's he trying to say... I don't understand
Timothy Holborn: I understand.
Pindar Wong: OK
Manu Sporny: Response to Michael - This requires a decentralized clearing mechanism and we don't have that yet, it's a version 2 feature. It's important, we want to do it, we don't have the technical bandwidth to solve this problem and all of the other problems.
Pindar Wong: More trust helps ;)
Pindar Wong: Works for me
Dave Longley: +1
Timothy Holborn: +1
Manu Sporny: Next use case: The buyer uses their payment processor's website to set a spending limit (and/or other limitations) for a particular merchant or set or merchants. Later, when the buyer clicks buy on the merchant's website, the purchase process is completed immediately (assumed consent) if the offer price is within the spending limit (and/or other limitations).
Pindar Wong: +1
Manu Sporny: This is a duplicate use case? [scribe assist by Manu Sporny]
Dave Longley: We may want to specify other limitations, can we move that into the prior pay-as-you-go token use case? [scribe assist by Manu Sporny]
Timothy Holborn: Within agree terms.
Pindar Wong: Purchase bomb attack?
Timothy Holborn: Only within agreed terms
Manu Sporny: Response to Dave Longley: This is largely a duplicate of the pay-as-you-go token use case, the only bit that we could add to the pay-as-you-go use case is the ("and/or other limitations") language.
Pindar Wong: For example: very small deltas in offer price by a dodgy merchant?
Manu Sporny: You can put other limits on it - per purchase, per month, etc. to protect against purchase bombs. [scribe assist by Manu Sporny]
Dave Longley: Or you can say up to $10 can be spent at this merchant, but for any single offer, only up to $1 can be spent, for instance.
Dave Longley: A variety of parameters can be offered by payment processors to their users to manage convenience and trust.
Manu Sporny: I modified the pay as you go use case a bit: A buyer visits a merchant's website and initiates a payment. Their payment processor presents them with an option to assign a pay-as-you-go token with a specific spending limit (and/or other limitations) for future purchases with the merchant. An option is also presented to require the display of a receipt when a purchase occurs (and/or other interactions), or to perform the purchase in the background with no interactive purchase process required.
Pindar Wong: Thinking
Pindar Wong: Ok that works for me tks!
Manu Sporny: I think we're done. Does anyone think we aren't?
Cheering / celebration.

Topic: Voting on the Use Cases

Manu Sporny: We can clean it up in the wiki and go through another set of comments -- but I don't think that would be a good idea at this point because we've discussed them to death.
Manu Sporny: Let's just put them in a document and see if the community agrees to it; it's not a final document but let's try to get agreement on it being a solid starting document.
Manu Sporny: The alternative is allowing everyone to vote on each individual use case, which might be an issue.
Pindar Wong: I prefer a vote on the entire document, and allow people to note objections for each use case
Pindar Wong: Vote on whole document but not objections
Dave Longley: I think we should allow people to make notes for each individual use case. So, vote on document, then leave feedback on individual use cases that can be integrated into next revision of the document. [scribe assist by Manu Sporny]
Manu Sporny: The vote is a yay or nay for the document and then there can be comments on each individual use case.
Timothy Holborn: +1
Pindar Wong: +1
Manu Sporny: We can't go through another round of comments because it will take too long.
Dave Longley: +1
PROPOSAL: There will be a vote on all of the use cases that the group has revised over the past 3 months with an option to make additional comments on each individual use case.
Pindar Wong: Good way fwd.
Dave Longley: +1
Manu Sporny: +1
David I. Lehn: +1
Pindar Wong: +1
Timothy Holborn: +1
RESOLUTION: There will be a vote on all of the use cases that the group has revised over the past 3 months with an option to make additional comments on each individual use case.
Pindar Wong: I think we're done! :)
Pindar Wong: HURRAY!
Yay!
PROPOSAL: Open a vote by the end of the week on the whether or not to accept the use case document as the CG's official position, the vote will be open for 2 weeks from the time the polls open.
Manu Sporny: +1
Dave Longley: +1
Timothy Holborn: +1
David I. Lehn: +1
Pindar Wong: +1
RESOLUTION: Open a vote by the end of the week on the whether or not to accept the use case document as the CG's official position, the vote will be open for 2 weeks from the time the polls open.
Pindar Wong: Thank you one and all... thanks Tim for staying up so very late for you.
Dave Longley: Yeah, thanks tim!
Pindar Wong: Cheers! :)
Timothy Holborn: Cheers ;)

Created by the Web Payments Community Group. Shared with love under a CC-BY license. Thanks to our contributors.