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

Web Payments Telecon Minutes for 2014-06-17

From: <msporny@digitalbazaar.com>
Date: Wed, 18 Jun 2014 15:49:04 -0400
Message-Id: <1403120944452.0.24108@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-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-06-17

Agenda:
  http://lists.w3.org/Archives/Public/public-webpayments/2014Jun/0126.html
Topics:
  1. IGF Workshop on Identity
  2. Whitelisting 
  3. Automated Payments and Subscriptions
  4. Theft of Payment Details
  5. Intent to Pay
  6. Wallet Data Synchronization
  7. Decentralized Identity
Chair:
  Manu Sporny
Scribe:
  Dave Longley
Present:
  Dave Longley, Manu Sporny, David I. Lehn, Pindar Wong
Audio:
  https://web-payments.org/minutes/2014-06-17/audio.ogg

Dave Longley is scribing.
Manu Sporny:  Anything to add to the agenda?
David I. Lehn: Nope
Manu Sporny: Actually, one thing to add to the agenda - we need 
  to review IGF stuff

Topic: IGF Workshop on Identity

Manu Sporny: Here's the workshop description: 
  http://www.intgovforum.org/cms/wks2014/index.php/proposal/view_public/69
Manu Sporny:  The deadline to update that is on the 20th, which 
  is this friday
Pindar Wong: I will email IGF a/c details by email to Manu
Manu Sporny:  I've sent emails out to bloomberg, mozilla, US fed, 
  some others
Manu Sporny:  I've asked them to confirm by the 20th if they 
  haven't already
Manu Sporny:  The other issue is that there was a problem trying 
  to submit what we were trying to submit to the IGF, and pindar 
  submitted that on my behalf, so only he can edit the proposal, 
  but i can't edit the proposal so i'll have to send the edits 
  through pindar and make sure he applies those
Manu Sporny:  I think we answered all the questions the IGF asked 
  of us, in fact we had answered them before, meaning that the 
  things that they asked us to clarify we had already clarified
Manu Sporny:  So they wanted the complete list of panelists with 
  their status as confirmed, we're trying to confirm them, the 
  agenda of the workshop which we have, and they want a remote mod 
  for the workshop which we also put in the proposal
Manu Sporny:  They want to increase gov't participation in the 
  panel and we've asked the US fed to join
Manu Sporny:  We asked w3c, world bank, bloomberg, and mozilla to 
  respond
Manu Sporny:  We think w3c and think world bank will be there
Pindar Wong: That’s great if the US Fed can join
Manu Sporny:  We can try and bring the ripple folks in as well 
  and i think i sent something out to ask them to participate
Manu Sporny:  They asked us to frame the policy questions more 
  clearly. I'll update the current proposal.

Topic: Whitelisting 

Manu Sporny: Ok, we had a combined use case that we were dealing 
  with last week - Whitelisting like MozPay API where customer 
  needs to figure out which payment providers are supported by the 
  merchant. Customer and merchant need to be able to select a 
  payment processor that are compatible.
Manu Sporny: I think we dealt with the first item: Whitelisting 
  like MozPay API where customer needs to figure out which payment 
  providers are supported by the merchant.
Manu Sporny: But we didn't deal with the second item:  Customer 
  and merchant need to be able to select a payment processor that 
  are compatible.
Dave Longley:  This use case is about the merchant being able to 
  advertise the payment mechanisms they support, and the customer 
  being able to select which ones they have and which ones they 
  want to use. [scribe assist by Manu Sporny]
Dave Longley:  So, the use case is - A customer goes to a 
  merchant website, and upon initiating a payment, the merchant 
  provides the payment providers that they support and the customer 
  selects the one that they want to use for the purchase. [scribe 
  assist by Manu Sporny]
Dave Longley:  Unfortunately, that just sounds like the state 
  we're in right now - we want to make sure that people know that 
  this process is automatic. [scribe assist by Manu Sporny]
Manu Sporny: Right, we want to make sure that people know that 
  this should be an automatic/automated process (as much as it can 
  be).
Dave Longley:  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
Manu Sporny: So if the merchant says: I support Credit Card, ACH, 
  and Bitcoin, and the customer supports Credit Card and Bitcoin, 
  then the options presented to the customer will be: "How do you 
  want to pay? Using your Visa card, or Bitcoin?"
Manu Sporny: Ok, so this is the use case, then:  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.

Topic: Automated Payments and Subscriptions

Manu Sporny: This is the use case we have today: Automatic 
  payments, transparent to usage (subscriptions and safe 
  pay-as-you-go w/o asking/annoying the customer)
Manu Sporny: So, basically what we want to enable here is a 
  customer going to a website, selecting a payment method and then 
  authorizing the website to pull an amount of money (with limits) 
  from their account on a weekly, monthly, yearly, etc. basis.
Dave Longley:  What about: 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.
Manu Sporny: It's not just the payment processor - the merchant 
  could ask them to subscribe.
Dave Longley:  I was trying to be vague on purpose - the merchant 
  would include that information in the information they'd pass on 
  to the payment processor. [scribe assist by Manu Sporny]
Manu Sporny: Ok
Dave Longley:  The merchant would include information indicating 
  that they'd like the customer to subscribe/add a pay-as-you-go 
  token

Topic: Theft of Payment Details

Dave Longley:  The payment processor would present that to the 
  customer
Manu Sporny: So, we have this right now - Use Case: Theft of 
  payment details results in very low return on investment.
Dave Longley:  I think we have this use case covered. [scribe 
  assist by Manu Sporny]
Manu Sporny: We already have this one - Use Case: A customer 
  executes a transaction without revealing secrets that are not 
  vital to the transaction (i.e. identity, passwords, PINs or other 
  information that the merchant does not need to know).
Manu Sporny: And we also have this one: 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.
Manu Sporny: So, I think we're covered.
Dave Longley:  Yeah, both of those cover this use case [scribe 
  assist by Manu Sporny]
Manu Sporny: Ok, so we're striking - Use Case: Theft of payment 
  details results in very low return on investment.

Topic: Intent to Pay

Manu Sporny: This is the use case that we have for this one: 
  Decouple payments as much as possible. Base on an intent-to-pay 
  mechanism
Manu Sporny:  This was a proposal made by robin berjon
Manu Sporny:  He said that we could use something like a protocol 
  handler
Manu Sporny:  We could revive the web intents stuff or add a 
  protocol handler for initiating a payment
Manu Sporny:  For any new payment mechanism you wanted to add to 
  the web could just be a new protocol
Manu Sporny:  We should explore this design criteria
Manu Sporny:  We need to phrase it in a way that's useful
Manu Sporny:  I listed this as a design criteria, it's not really 
  a use case
Dave Longley:  I'm trying to figure out how it's different from 
  the use cases we've discussed thus far. This sounds like an 
  implementation detail (the use of web intents or protocol 
  handlers) [scribe assist by Manu Sporny]
Dave Longley:  That is, you initiate a transaction and hand the 
  data blob over to the protocol handler. [scribe assist by Manu 
  Sporny]
Dave Longley:  This is really a question of whether or not we 
  have a specific payments API for browsers, or if we should use a 
  protocol handler or a Web Intent. [scribe assist by Manu Sporny]
Dave Longley:  I think payments are decoupled already regardless 
  of what the implementation detail would be. [scribe assist by 
  Manu Sporny]
Manu Sporny:  I don't know if we would consider web intents or 
  protocol handlers very heavily if we didn't have anything in 
  there mentioning it
Manu Sporny: I'm concerned that we're going to overlook Web 
  Intents or Protocol Handlers if we don't preserve this in some 
  way.
Manu Sporny: So, something like this? Design Criteria: Consider 
  using Web Intents or Protocol Handlers to provide a more abstract 
  implementation solution for payment initiation as well as a 
  technology that could be used for solving other intent-related 
  problems on the Web.
Dave Longley:  What about: 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.
Manu Sporny: Ok, sounds good.

Topic: Wallet Data Synchronization

Manu Sporny: We have this use case now: Sync wallet data, 
  password data, and credential data to the cloud - use the same 
  mechanism for all three.
Manu Sporny:  This was proposed as a general cloud storage 
  mechanism
Manu Sporny:  I think that wallet and credential data are 
  supported by the identity credential spec and you could argue 
  that password is as well
Manu Sporny:  It's also RWW (read write web) stuff
Manu Sporny:  You write things to your personal data space online
Manu Sporny:  Your personal data vault, is another way to put it
Manu Sporny:  I think the basic use case is being able to store 
  your private information in a place of your choosing that is not 
  the originator of that data
Dave Longley:  The purpose of standardization here is so that you 
  could just click a button and switch your data to another storage 
  location. We're talking about a storage API for data. [scribe 
  assist by Manu Sporny]
Manu Sporny: It does seem like the main thing we're talking about 
  is ensuring that you can store your data securely in some place 
  and that you can change that location at will.
Dave Longley:  I don't think that inventing a whole other API to 
  do that is useful. [scribe assist by Manu Sporny]
Dave Longley:  I think the use case is more about making it easy 
  for people to store their data where they want to store it rather 
  than synchronizing their data. [scribe assist by Manu Sporny]
Dave Longley:  Effectively, this is about discoverability and 
  reading that information (which needs to be standardized in some 
  way).  [scribe assist by Manu Sporny]
Dave Longley:  Where you write the data doesn't need to be 
  standardized. That's what the sync thing is about. In the 
  Identity Credentials spec, we do talk about other people being 
  able to write to your personal data vault.  [scribe assist by 
  Manu Sporny]
Dave Longley:  If there were 3 different providers for storing 
  your personal data, you could switch to them based on the 
  software you're using. As long as the 3 storage mechanisms 
  allowed reads and discoverability in the same way, you could sync 
  to all three. [scribe assist by Manu Sporny]
Dave Longley:  Maybe this is too far down in the weeds. Maybe the 
  use case should be: A customer is storing their wallet, 
  credential data, passwords, and other sensitive information at 
  one identity provider / wallet provider, then they should be able 
  to switch to a new one and make a payment w/o going through a 
  painful setup process. [scribe assist by Manu Sporny]
Dave Longley:  I'm wondering if we don't already have this 
  covered. [scribe assist by Manu Sporny]
Dave Longley:  This is another design criteria - decouple storage 
  of your identity information from where your identity provider 
  is. [scribe assist by Manu Sporny]
Manu Sporny: Also, keep in mind that we have this use case next - 
  Wallet portability to move to a new wallet service provider at 
  will.
Dave Longley:  Well, doing that requires that you are able to 
  move your data with you (synching it across websites easily) 
  [scribe assist by Manu Sporny]
Dave Longley:  Proposal: A customer currently stores their wallet 
  and credentials with a particular identity/wallet provider. The 
  customer decides to switch to a different identity/wallet 
  provider and all of their wallet and credential data comes with 
  them.
Manu Sporny: So, that takes care of both use cases? 
Dave Longley:  Yeah, I think so [scribe assist by Manu Sporny]
Manu Sporny: I agree, I think... trying to think if there is any 
  part of both of those use cases that aren't covered with the text 
  above.
Manu Sporny: Ok, so reword: A customer stores their wallet and 
  credentials 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 and 
  credential data comes with them.
Dave Longley:  I don't think we need to standardize /how/ the 
  data is stored... just the protocol for querying and retrieving 
  the data. [scribe assist by Manu Sporny]
Dave Longley:  All we need to standardize is the mechanism that 
  allows you to easily move the data between providers. We have 
  that with the Linked Data solution - you'd expect the data to be 
  available in the cloud, but you can also run your own data 
  provider and run it all on one device w/o any backups and lock it 
  down to that device. [scribe assist by Manu Sporny]
Dave Longley:  You still have to provide access to it if anyone 
  wants to interface w/ you. [scribe assist by Manu Sporny]
Dave Longley:  What I'm trying to say is that we were originally 
  trying to conflate too many things, and if we focus too much on 
  all this "cloud" stuff, we lose the kernel of the problem that 
  needs to be solved. [scribe assist by Manu Sporny]
Dave Longley:  Other people need to be able to get access to 
  whatever data they need to complete a transaction w/ you. 
  Whatever minimal set of data that needs to be transferred to 
  that. [scribe assist by Manu Sporny]
Dave Longley:  You also need to be able to give another storage 
  provider access to the data to move/migrate/sync it. All that we 
  require of the data provider is that if someone wants to change 
  data providers, they can do so. [scribe assist by Manu Sporny]
Dave Longley:  I'm pretty sure the Identity Credentials spec 
  handles this stuff now... there are implementation details we 
  need to work out, but the general design is capable of addressing 
  these issues. [scribe assist by Manu Sporny]
Manu Sporny: Ok, so we're accepting that use case above and 
  striking the two in there now - removing sync specifics, since 
  portability should take care of synching as well.

Topic: Decentralized Identity

Manu Sporny: We only have a few items left in payment 
  initiation... decentralized identity is one of them... two use 
  cases.
Dave Longley:  They could be combined. [scribe assist by Manu 
  Sporny]
Manu Sporny: Agreed, let's do that.
Dave Longley:  These are really identity use cases [scribe assist 
  by Manu Sporny]
Manu Sporny: Yeah, ok out of time for today. We'll chat again 
  next week - same time and day of week. Tuesday 9:30pm Boston.
Received on Wednesday, 18 June 2014 19:49:27 UTC

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