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

Web Payments Telecon Minutes for 2014-06-02

From: <msporny@digitalbazaar.com>
Date: Mon, 02 Jun 2014 14:43:27 -0400
Message-Id: <1401734607198.0.17107@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-06-02/

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-06-02

Agenda:
  http://lists.w3.org/Archives/Public/public-webpayments/2014Jun/0000.html
Topics:
  1. Parametric Selection of Payment Method
  2. The IGF 2014 Workshop on Payments and Identity
  3. App Stores
  4. In-app Purchases
Chair:
  Manu Sporny
Scribe:
  Dave Longley
Present:
  Dave Longley, Manu Sporny, Timothy Holborn, David I. Lehn, Pindar 
  Wong, Brent Shambaugh
Audio:
  https://web-payments.org/minutes/2014-06-02/audio.ogg

Dave Longley is scribing.
Manu Sporny:  Pindar had asked to announce some IGF information
Timothy Holborn: The outline (from IGF) looked very positive...
Manu Sporny:  Any other updates?
David I. Lehn:  Nope

Topic: Parametric Selection of Payment Method

Manu Sporny: So we have this right now for the use case: 
  Selection of payment method based upon desired payment speed and 
  cost.
Manu Sporny:  This seems to be something that the payment 
  processor would ... it's a fairly complex use case, we could say 
  it's something the payment processor could handle, but that 
  payment processor might have to know information from other 
  payment processors, etc, to produce quotes 
Dave Longley:  This sounds like a requirement, so we'd need to 
  reword it as a use case. [scribe assist by Manu Sporny]
Timothy Holborn: Should it specifically state directionality? As 
  in: capability at both merchant and end-user contact points??
Dave Longley:  Maybe the reason it was in here was because the 
  protocol would need to support it - this seems complex, 
  especially for the first version of this. [scribe assist by Manu 
  Sporny]
Timothy Holborn: Different regions might have different rates for 
  payments.  So, cms might check where end customer is..
Manu Sporny:  The problem with the complexity of the use case ... 
  is that it may require something built into the protocol and it 
  may be difficult to add in later
Dave Longley:  I'm trying to think through how this could be 
  standardized/implemented. [scribe assist by Manu Sporny]
Dave Longley:  Further problem - how would these prices be 
  displayed, does the merchant have any control over it? [scribe 
  assist by Manu Sporny]
Dave Longley:  This may or may not require the merchant to know 
  which payment provider's are available. [scribe assist by Manu 
  Sporny]
Timothy Holborn: Perhaps the requirement is being able to 
  identify the characteristics of a payment processor?
Dave Longley:  Or are we talking about merchants providing 
  different payment options. [scribe assist by Manu Sporny]
Dave Longley:  Payment speed soundsl ike something payment 
  processor could decide. Wouldn't your payment processor just 
  provide with a better rate? Payment processor can process things 
  more quickly, thus at a better rate. Seems like this is 
  out-of-band stuff. [scribe assist by Manu Sporny]
Manu Sporny:  I think the intent at the workshop was a smart 
  wallet that could auto-negotiate on your behalf to pick the best 
  payment processor option based on a number of different variables
Timothy Holborn: Perhaps a means to dynamically signal qualities.
Manu Sporny:  We want your payment agent to be able to determine 
  your fastest/cheapest payment option based on a variety of 
  different inputs
Timothy Holborn: Like petrol prices at a petrol station. Perhaps 
  the characteristics might fluctuate, and/or if a signalling 
  method existed, higher flexibility might encourage competition.
Dave Longley:  Seems to me, based on how we designed payswarm so 
  far, right now merchants put up offers for assets that indicate 
  what minimum costs are.  [scribe assist by Manu Sporny]
Dave Longley:  You turn around and give that to whatever payment 
  processor you want to. The payment processor will give you a 
  finalized price to display to you before you purchase. [scribe 
  assist by Manu Sporny]
Dave Longley:  If we don't consider this in version 1, if we 
  wanted to add something to the protocol, what would happen in 
  that case, the "Web Pyaments Commerce Protocol" would just 
  communicate with N-many payment processors to pick one offer. 
  [scribe assist by Manu Sporny]
Dave Longley:  I think we can layer this. [scribe assist by Manu 
  Sporny]
Timothy Holborn: Does the payment processor signal the "deal" or 
  arrangement (charge) for processing the payment?
Dave Longley:  We've completely separated concerns - the merchant 
  just states what they need. That may or may not contain some 
  price that must be met. [scribe assist by Manu Sporny]
Timothy Holborn: At the time of the transation
Dave Longley:  What might end up happening is that the payment 
  processor could give you a refund, or pay the merchant more 
  money... the merchant might say the cost does need to be a 
  dollar, but I'm willing to take between 70%-80% of that dollar. 
  The payment processor might negotiate to give you a refund. 
  [scribe assist by Manu Sporny]
Dave Longley:  In another case, the merchant could say: I just 
  want $0.80.  [scribe assist by Manu Sporny]
Dave Longley:  Version 1 could just talk to your payment 
  processor. [scribe assist by Manu Sporny]
Dave Longley:  Version 2 could talk to N-many processors. [scribe 
  assist by Manu Sporny]
Dave Longley:  Seems like this could layer and it could work. 
  [scribe assist by Manu Sporny]
Manu Sporny:  Going through tim's comments ... the directionality 
  question ... the merchant specifies the asset they are selling 
  and what they want, the customer can come in and read what the 
  merchant wants and figure out which one of their payment 
  processors would give them the best deal and would then meet that 
  offer by posting something back to the merchant
Timothy Holborn: Payment processor more likely to say, I'll 
  charge you 10c to do that transaction, in usd, within the next 30 
  seconds. The merchant says - that's the cheapest deal, do it.
Manu Sporny:  The merchant doesn't need to contact the customer, 
  the customer can make the best decision for themselves with all 
  the available information
Manu Sporny:  Because the merchant has already made all that 
  information known
Timothy Holborn: K.
Manu Sporny:  Re: different regions would provide different 
  rates.
Manu Sporny:  "Perhaps the requirement is being able to ID the 
  characteristics" that is one requirement, the other requirement 
  is being able to identify the charact. of an offer for sale, the 
  system we're discussing will know each of the payment processors 
  available, they'll be able to say "i have an offer the merchant 
  put forth, what's the fastest you can process this transaction 
  for me and what's the price" and then you pick the best quote
Manu Sporny:  "Perhaps a means to dynamically signal qualities" 
  ... i don't know what he means by that exactly, dynamic is a 
  loaded worded, perhaps the means to signal qualities is what 
  linked data is all about, we use linked data to express a whole 
  variety of different qualities
Manu Sporny:  "The characteristics might fluctuate..." ... we 
  assume the characteristics do fluctuate, we allow merchants to 
  publish whenver they want (every 100 ms or every day or year, 
  whatever works for them)
Manu Sporny:  We are enabling flexibility
Timothy Holborn: Some payment processor might fluctuate in price 
  during a given period.
Timothy Holborn: :)
Manu Sporny:  "The payment processor is more likely to say 
  10c..." ... i think this conflates what the merchant should be 
  able to say
Manu Sporny:  There's no reason to involve the merchant, it's too 
  complex to do it that way
Manu Sporny:  The merchant just has to say "these are the offers, 
  these are the terms"
Manu Sporny:  And the customer/payment processor just figures out 
  what works for them
Manu Sporny:  If the merchant won't accept something, they don't 
  offer it
Manu Sporny:  "Payment processor might fluctuate..." ... yes, 
  that's assumed
Manu Sporny:  We need to rewrite this use case
Manu Sporny: A customer discovers an offer for sale by a merchant 
  under terms that the merchant is comfortable with. The customer 
  contacts three different payment processors to get a finalized 
  transaction before accepting that transaction.
Dave Longley:  We can support that now, the way we've done this 
  (I think it already works with the protocol). [scribe assist by 
  Manu Sporny]
Timothy Holborn: I imagine their might be loyalty opportunities 
  between payment processors and their customers
Dave Longley:  I think this is already covered by the current 
  design. [scribe assist by Manu Sporny]
Manu Sporny: I don't know if we support the merchant specifying 
  which payment processors they support yet.
Dave Longley:  I think we can do that now, you can list the 
  payees as specific to certain payment processors. So, technically 
  we can do that today, but we may want to do it in a different way 
  in the future. [scribe assist by Manu Sporny]
Manu Sporny: 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.
Timothy Holborn: +1
Manu Sporny:  Pindar +1 through skype

Topic: The IGF 2014 Workshop on Payments and Identity

Manu Sporny: 
  http://www.intgovforum.org/cms/wks2014/index.php/proposal/view_public/69
Pindar Wong:  The IGF, the good news, is that our proposal has 
  been accepted, and therefore we will present in Instanbul, 
  Turkey, at the panel, well ... it's actually a working group, i 
  had a few names presented to me at the stockholm forum, I just 
  wanted to have it on the record during this call
Timothy Holborn: +1
Timothy Holborn: Looks great
Manu Sporny:  The comments that we got back seemed very 
  reasonable, things we should definitely address
Pindar Wong:  A lot of the time was taking up with presentations 
  in last years IGF, so this time there will be some videos and 
  those will get out of the way to have more time
Pindar Wong:  We've had some comments from the federal reserve 
  and they might be ideal in terms of reaching out to
Manu Sporny:  I can reach out to them
Pindar Wong:  I'll bounce some names later this week, i know 
  you're traveling, we can let the list know about the comments
Manu Sporny:  Right, which list?
Manu Sporny:  The web payments CG would be good to hear the 
  comments, the ... actually, maybe it would be good to let them 
  both know, and let the IG list know the MAG is interested in 
  payments
Pindar Wong:  This would be a good test case to figure out how we 
  should work the messaging around this.
Manu Sporny:  I forwarded the comments from the MAG to the web 
  payments list, i blanked out email addresses, names, etc. 
Manu Sporny: Here are the comments we got back from the IGF MAG: 
  http://lists.w3.org/Archives/Public/public-webpayments/2014May/0149.html
Manu Sporny:  I'll send this onto the web payments chartering IG 
  so they're aware of this happening
Pindar Wong:  Thank you
Brent Shambaugh: +1
Manu Sporny:  We're hoping to send out a pretty big advance in 
  the payments privacy/policing area, it's a new proof of concept 
  we've been working on for the last month ... to demonstrate that 
  this isn't just theoretical, showing how to put all these things 
  together, such as high-stacks credentials, passport, proof of 
  age, driver's license, etc. and digitally signing those so that 
  they can be trusted by third party sites, these credentials
Could be issued by bank, etc.
Manu Sporny:  National ID card could have signature on it from 
  US, Canadian, Hong Kong gov't, etc.
Manu Sporny:  And be stored with your identity document and be 
  able to be transferred to third parties and would be digitally 
  verifiable
Manu Sporny:  Anything else on this topic before moving on?
Dave Longley:  Tim holborn wanted some clarification on something
Timothy Holborn:  What did you want to be clarified?

Topic: App Stores

Manu Sporny: This is what we have for the app store use case so 
  far: App Stores - selling apps in mobile scenarios.
Timothy Holborn: Oh.  Just seemed like a long pause...
Manu Sporny:  Number of problems with this, it's not very 
  specific, it's only mentioning mobile... the problem with mobile 
  is.... the general discussion we had at the workshop was that 
  mobile is *part* of the web, this mechanism is built for the web, 
  it's not "non-mobile" or "non-tablet" the key here is that 
  there's a programmatic way to utilize HTTP and other low-level 
  protocols to execute payment
Timothy Holborn: My app interface hung...  Now I'm catching up.  
  Sorry.  Gimme a tic
Manu Sporny:  A browser is not required
Manu Sporny:  With in-app purchases, etc. typically a browser is 
  not used, but what we mean by web payments is to use the web as 
  the substrate on top of which payments are built
Manu Sporny:  No browser is required
Manu Sporny:  We can't say "mobile scenario" because what is and 
  isn't mobile is pretty shaky these days
Brent Shambaugh: So apps use HTTP?
Manu Sporny:  Is a transforming tablet with a keyboard on it a 
  mobile? 
Manu Sporny:  So we should probably just remove the whole "mobile 
  thing" from the use case and just talk about app stores
Manu Sporny:  And app stores that just happen to use the web 
  payments protocol to do payments
Pindar Wong:  I agree mobile/non-mobile is not a useful 
  distinction [scribe assist by Manu Sporny]
Manu Sporny: We also have this for the next use case: In-app 
  purchases in mobile scenarios for purchasing premium content, 
  virtual goods, or subscriptions.
Manu Sporny: So, we might want to combine these two use cases.
Pindar Wong:  Yes, combine them makes sense [scribe assist by 
  Manu Sporny]
Timothy Holborn: I'm not sure the issues exhibited in those older 
  paradigms apply here.
Dave Longley:  A customer uses their mobile phone or browser to 
  access an app store to make a purchase.  [scribe assist by Manu 
  Sporny]
Dave Longley:  A customer purchases premium content, virtual 
  goods, or a subscription from inside of an application. [scribe 
  assist by Manu Sporny]
Timothy Holborn: Can a link be provided in the AppStore to make 
  the purchase in a browser?
Dave Longley:  I think there are two different cases. You are at 
  an app store making a purchase. You are in an app making a 
  purchase. [scribe assist by Manu Sporny]
Dave Longley:  What device you're doing that with, doesn't really 
  matter. [scribe assist by Manu Sporny]
Dave Longley:  If we can mention mobile as an example, that may 
  assuage some people's concerns. [scribe assist by Manu Sporny]
Dave Longley:  So, with your mobile device, with your browser, it 
  just works wherever. [scribe assist by Manu Sporny]
Timothy Holborn: Might be in a browser making a purchase for an 
  AppStore or an app...
Pindar Wong:  Leave out desktop [scribe assist by Manu Sporny]
Timothy Holborn: Ie: kid has phone, with no credit card details 
  in AppStore.  Parents use laptop to buy app or send credit to 
  kids appstore
Timothy Holborn: K.
Manu Sporny: Then how about this for the first use case: A 
  customer uses a native non-browser application on their mobile 
  phone or tablet, or a web browser to access an app store to make 
  a purchase.
Pindar Wong:  Yup, works for me. [scribe assist by Manu Sporny]
Timothy Holborn: +1
Dave Longley:  I think we need to be slightly more clear about 
  "need to make a purchase via an app store". [scribe assist by 
  Manu Sporny]
Manu Sporny: Ok, so change to:  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.
Dave Longley:  Your application or web browser can use the same 
  protocol to initiate the payment. [scribe assist by Manu Sporny]
Pindar Wong: +1
Timothy Holborn: +1

Topic: In-app Purchases

Manu Sporny: What we have right now is: In-app purchases in 
  mobile scenarios for purchasing premium content, virtual goods, 
  or subscriptions.
Timothy Holborn: Why are the principles different for mobile.
Timothy Holborn: Is this due to carrier direct billing?
Timothy Holborn: Arguably, these models also apply to many games 
  for desktop / other platforms.
Manu Sporny:  Re: tim, no this was just something that was 
  mentioned at the workshop because people were thinking that 
  mobile-based payments were different
Manu Sporny: Tim, no - this is mostly because people at the 
  workshop were too fixated on Mobile.
Timothy Holborn: Or advanced apps. 
Manu Sporny:  From other payments, and they really shouldn't be
Manu Sporny:  Carrier-direct billing is different, but the only 
  thing that's different is the payment processor
Manu Sporny:  Your payment processor is your mobile carrier, not, 
  for example, paypal or google wallet
Manu Sporny: Ok, so this? A customer makes a purchase from within 
  an application for premium content, virtual goods, or 
  subscriptions.
Pindar Wong:  I think we need to ensure that mobile-based 
  payments is not perceived as different even though the payment 
  processor may be different [scribe assist by Manu Sporny]
Timothy Holborn: Yup.
Dave Longley: +1
Timothy Holborn: +1
Pindar Wong: +1
Timothy Holborn: I think people forget mobile started with wap
Timothy Holborn: Or similar.
Timothy Holborn: Now, the apps are much more capable of speaking 
  www.
Manu Sporny:  Next week the meeting time is up in the air, we may 
  or may not have a call next week
Manu Sporny:  We're just going to keep going through the use 
  cases, if we don't do it, the web payments IG will have to, it's 
  better that we do some front running and get some solid use cases 
  down related to the tech we're building
Manu Sporny:  I think so far many of the use cases are already 
  met with at least the payswarm stuff we've put out into the 
  public
Manu Sporny:  That's good that they are met by the tech we've 
  been building over the last 4+ years
Manu Sporny:  Any other comments we should be aware of before the 
  call next week?
Received on Monday, 2 June 2014 18:43:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:31 UTC