- From: <msporny@digitalbazaar.com>
- Date: Wed, 17 Sep 2014 11:30:44 -0400
- To: Web Payments CG <public-webpayments@w3.org>
Thanks to Dave Longley for scribing this week! The minutes for this week's Web Payments telecon are now available: https://web-payments.org/minutes/2014-09-17/ Full text of the discussion follows for W3C archival purposes. Audio from the meeting is available as well (link provided below). ---------------------------------------------------------------- Web Payments Community Group Telecon Minutes for 2014-09-17 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2014Sep/0067.html Topics: 1. W3C TPAC Web Payments / Credentials Agenda 2. Payment Initiation / Wallet Use Case Revisions 3. In-app Purchases 4. Registration-less purchasing 5. Payment UIs and Buyer Authorization 6. Finishing out the use cases Chair: Manu Sporny Scribe: Dave Longley Present: Dave Longley, Manu Sporny, David I. Lehn, Pindar Wong, Timothy Holborn, Evgeny Vinogradov Audio: https://web-payments.org/minutes/2014-09-17/audio.ogg Dave Longley is scribing. Manu Sporny: Any updates to the agenda? David I. Lehn: None Topic: W3C TPAC Web Payments / Credentials Agenda Manu Sporny: http://www.w3.org/2014/11/TPAC/ Manu Sporny: This is in Santa Clara, California, 27-31 October 2014 Manu Sporny: The Web Payments and Credentials meetings will be on Monday and Tuesday, 27-28 Manu Sporny: Anyone from the those communities should come on those days. Manu Sporny: There's also some time in the middle of the day for adhoc meetings. Manu Sporny: The charter is being reviewed for the IG and once the vote is complete they'll be able to say who they've picked as chairs and talk about all that in a face to face meeting at TPAC. Manu Sporny: If any person or organization wants to attend those meetings and is not a W3C member, they should contact me (Manu Sporny) so I can make sure you're on the list and can get into the room, if you want to bypass me talk to Stephane Boyera or Karen Myers at W3C. Manu Sporny: At the very worst at the end of this week, I'm going to write a blog post and circulate it widely in various communities to ensure people know this is happening. Manu Sporny: W3C has another group that's tentatively on the schedule and I'll ask for the same treatment, they really should have had this on the agenda but they don't have it on there since it bothers some orgs if it wasn't passed by the advisor community Pindar Wong: Agree tha we should come out a draft agenda that can be discussed and ratified Manu Sporny: The agenda has not been set yet, so we really should come up with a draft agenda because whoever is going to be chairing the work at W3C TPAC is probably not as up-to-date as we are as to what is going on. We should say "Let's look at the refined use cases, pull in updates from credentials work, etc." Manu Sporny: We need to come up with an agenda and then propose it to those chairs who I imagine will be fairly open to it because it's less work they have to do. Pindar Wong: Nope Manu Sporny: Any questions about how to participate or the agenda? Manu Sporny: Pindar, will you be able to attend? Pindar Wong: I've got Science and Technology Society, meetings in South Korea, etc. so it's unlikely that I'll be able to attend. Pindar Wong: Sorry I've an OCED meeting in Tokyo, STS in Kyoto and WKF in Seoul that month Topic: Payment Initiation / Wallet Use Case Revisions Manu Sporny: https://www.w3.org/community/webpayments/wiki/UseCases#Initiating_Payments_.2F_Wallet_APIs Manu Sporny: I think the last time we were on.. Manu Sporny: This one - Use Case: A buyer uses a native non-browser application on their mobile phone or tablet, or a web browser to make a purchase at an app store. Manu Sporny: We basically agreed with Jorge on his feedback. Topic: In-app Purchases Manu Sporny: This one is next - Use Case: A buyer makes a purchase from within an application for premium content, virtual goods, or subscriptions. Manu Sporny: Jorge's feedback: However, without embedding wallets, but by obtaining delegated access through OAuth tokens. Manu Sporny: I believe that the current mechanism doesn't require an OAuth token, you're assigned a budget, which could be viewed as OAuth-token-like mechanism, but we didn't have a use/need for OAuth in the entire stack we put together. Manu Sporny: In general we agreed with Jorge's feedback, but we don't think that the technology that should be used in the use case. So we agree with him but we don't think we should put a specific technology into the use case. Pindar Wong: Nope Manu Sporny: It's still a point to discuss later, whether we should use what we have already designed or start using OAuth. Dave Longley: Yeah, that's fine. Pindar Wong: Agreed Manu Sporny: Next week we'll likely do a longer call to get these use cases finished so they are out there well before TPAC and so the community can give feedback. Topic: Registration-less purchasing Manu Sporny: Next up - Use Case: The buyer 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 buyer chooses which information to share with the merchant which the merchant then uses to uniquely identify the buyer if they perform any repeat purchases. Manu Sporny: The idea behind this use case is that they can transmit all the credentials that are necessary and complete the financial purchase in one click. Manu Sporny: Steven Rowat's feedback: Redundant? What's the difference between this and the Use Case that's third from the top, that says: "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: The previous one (intersection of payment processors) is a choice given to them once the information has been provided to the merchant. This one has to do with doing a registration-less purchase. You click the buy button and then all the information is transmitted to the merchant. So a merchant can say "I'd like your email address and here's the offer for purchase." Manu Sporny: I don't think we can cover this right now due to how the design has changed. Dave Longley: We've decoupled identity storage and payment processors, but a browser could still turn the process into a single click. Pindar Wong: Agree with Dave's point w.r.t. streamlining of purchase Manu Sporny: Response to Steven - it's not redundant, this has to do w/ credential transmission + purchasing (streamlining the purchase process). The other use case has to do w/ selecting among provided credentials (selection of payment processor). Pindar Wong: Language looks good to me Dave Longley: I don't think we need to change the use case language. [scribe assist by Manu Sporny] Manu Sporny: Adrian's feedback: For later iterations Dave Longley: I think Adrian's general feedback is that anything identity related can be pushed off... so, this may have come from there. Some of this use case will be covered by what the credentials group is doing. [scribe assist by Manu Sporny] Manu Sporny: Yeah, plus we get this use case "for free" based on the current technology design. Dave Longley: Really, this is an API in a browser - where the merchant's javascript says "give me this credential, and here's an offer"... credentials are delivered first, then offer is processed. [scribe assist by Manu Sporny] Dave Longley: In the polyfill case, we're going to have to provide advice on how to implement a one-click flow. [scribe assist by Manu Sporny] Manu Sporny: Yeah, so we're deferring the idea of there being a single API call to do credential transmission and purchasing. Dave Longley: Not necessarily a "single API call" but some browser API (could be a chain of calls). Manu Sporny: Reponse to Adrian - We're deferring the notion that there would be a single API call to achieve this use case. However, we can achieve this use case with the current technology and a best-practice note, nothing new is required and therefore it doesn't make sense to postpone the use case if we can achieve it today using browser polyfills. Timothy Holborn: Hey, listening in but under the weather today. [scribe assist by Manu Sporny] Topic: Payment UIs and Buyer Authorization Manu Sporny: Next up - Use Case: A buyer goes to a merchant website and is presented with a payment UI from their payment processor. The purchase can be completed without any additional information from the buyer other than their consent to complete the purchase. Manu Sporny: Jorge's feedback: Custom payment UIs are not the way to go in my opinion. Manu Sporny: Michael Williams' feedback: if proxying as described above happens by default if chosen as an option before. Dave Longley: Use case is vague, is this UI just one displayed on the payment processors site after a redirect? Is it shown on the merchant's site? Is it a "trusted" payment UI on the browser? Manu Sporny: Yes, it is too vague. For a "trusted" payment UI, the UI always looks the same regardless of which merchant site you visit. However, everyone that worked on this on phones found that the phishing risk is too high. Manu Sporny: I think the general thought is that a trusted UI is problematic, not a solved problem yet. Manu Sporny: If we're not talking about that then we're talking about the UI on the payment processor site and they can customize that site however they want to reduce or prevent phishing. Manu Sporny: I think we agreed that custom payment UIs on the merchant's site are a no go, but customized payment UIs on the payment processor's site are fine. Manu Sporny: The problem is that the use case doesn't say where the payment UI shows up, it just says the payment processor provides the payment UI. Manu Sporny: It doesn't say if you're shown that on the merchant website or you see it on the payment processor website. Dave Longley: I'm trying to figure out if this is already covered in the other use cases. If this use case comes down to your payment processor just showing you a UI, do we need to say that? [scribe assist by Manu Sporny] Manu Sporny: Yes, because it means that we're not saying that we want to do hardware/Trusted UI stuff and it says that we don't want the merchant to be in control of the payment UI. Dave Longley: So we're re-writing the use case? [scribe assist by Manu Sporny] Manu Sporny: Yes, I think so. Dave Longley: Rewrite - The buyer goes to a merchant website and clicks buy to purchase an offer. The buyer is redirected to their payment processor's website which presents them with a payment UI. The buyer completes the purchase and is sent back to the merchant's website with a digital receipt confirming the purchase. Manu Sporny: Response to Jorge - Merchant-based custom payment UIs are a bad idea, browser-based Trusted UIs don't seem to have a good solution at the moment, which means that the only payment UI that can be presented safely is from the payment processor. It's in the payment processor's purview to change the UI to meet their customer's expectations. We should not try to specify what a payment UI should look like. Manu Sporny: Response to Michael - We would like payment proxying technology to exist, but to date, none has been invented to enable this to happen on a global scale. We will try to solve this problem during the v2 work. We should mention the idea of having more decentralized payment processors to the Web Payments IG for Design Criteria for future versions. Dave Longley: We should add this 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 of merchants. Later, when the buyer clicks buy on the merchant's website, the purchase process is completed immediately (consent is assumed) if the offer price is within the spending limit (and/or other limitations). Manu Sporny: I'll add it to the bottom of the wiki Dave Longley: Ok, new revision then: The buyer goes to a merchant website and clicks buy to purchase an offer. The buyer is redirected to their payment processor's website which presents them with a payment UI. The buyer completes the purchase (optionally without providing any information other than their consent). The buyer is sent back to the merchant's website with a digital receipt confirming the purchase. Evgeny Vinogradov: A quick comment about merchant-based UIs, we can't avoid it completely - think of an in-game purchase... better to make that purchase in-game w/o going to payment provider. [scribe assist by Manu Sporny] Evgeny Vinogradov: We need to think about issuing some kind of permission to spend that the customer gives to merchant. [scribe assist by Manu Sporny] Evgeny Vinogradov: We can avoid merchant-based UI completely, if you think about in-game purchases, it's better to not go to the payment provider's website at all. Which is related to the use case Dave Longley proposed. Even if some other type of permission is given there needs to be a merchant site UI. Evgeny Vinogradov: I prefer that we shouldn't say we don't support merchant-based UIs. [scribe assist by Manu Sporny] Dave Longley: Merchant UIs are only used if the buyer has previously given permission via their payment processor. That prevents the phishing attack. [scribe assist by Manu Sporny] Dave Longley: That's really how we want in-app/game purchases to work, the buyer says: I authorize this merchant to pull money from me. Particularly for in-game, in-app purchases. [scribe assist by Manu Sporny] Dave Longley: You should never be giving your consent (password, pin, etc) on a merchant website... you should be doing that on your payment processor. Merchant-based UIs should be using a payment token, not asking for payment details. [scribe assist by Manu Sporny] Manu Sporny: "Yes, I would like to spend $5 [OK]" instead of "Buy this item for $5 [Enter your payment processor password: *******]" Manu Sporny: On the merchant website. Dave Longley: You must always grant authorization via your payment processor's website, never *only* on the merchant website. You can preauthorize future consent on your payment processor's site (with certain limits) -- such that if you do click buy on a merchant's site, so long as the offer there falls within those limits then authorization will be granted. Manu Sporny: Response to Jorge - Merchant-based custom payment UIs that don't use a pre-authorized token from a payment processor are a bad idea, browser-based Trusted UIs don't seem to have a good solution at the moment, which means that the only payment UI that can be presented that asks for possibly private information is from the payment processor on the payment processors website. It's in the payment processor's purview to change the UI to meet their customer's expectations. We should not try to specify what a payment UI should look like. Manu Sporny: Ok, so this is what it looks like now - Use Case: The buyer goes to a merchant website and clicks buy to initiate a purchase. The buyer is redirected to their payment processor's website which presents them with a payment UI. The buyer completes the purchase (optionally without providing any information other than their consent). The buyer is sent back to the merchant's website with a digital receipt confirming the purchase. Topic: Finishing out the use cases Manu Sporny: We need to spend a large chunk of time to go through the rest of these use cases, we want them done before W3C TPAC, so we're going to spend a lot of time next week to finish out the payment initiation/wallet use cases Manu Sporny: Then the week after, we'll spend as much time as it takes to go through the digital receipt use cases.
Received on Wednesday, 17 September 2014 15:31:08 UTC