W3C home > Mailing lists > Public > public-webpayments@w3.org > September 2014

Web Payments Telecon Minutes for 2014-09-17

From: <msporny@digitalbazaar.com>
Date: Wed, 17 Sep 2014 11:30:44 -0400
Message-Id: <1410967844220.0.15657@zoe>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:39 UTC