Web Payments Telecon Minutes for 2014-07-30

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-07-30/

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-07-30

Agenda:
  http://lists.w3.org/Archives/Public/public-webpayments/2014Jul/0111.html
Topics:
  1. Credentials Community Group Formation
  2. Feedback on Use Cases Revisions
  3. General Comments on Use Cases
  4. Value-in-Exchange Benchmarking
Chair:
  Manu Sporny
Scribe:
  Dave Longley
Present:
  Dave Longley, Manu Sporny, David I. Lehn, Joseph Potvin, Timothy 
  Ng, Evgeny Vinogradov
Audio:
  https://web-payments.org/minutes/2014-07-30/audio.ogg

Dave Longley is scribing.
Manu Sporny:  Any updates or changes?
David I. Lehn:  Nope

Topic: Credentials Community Group Formation

Manu Sporny:  This is something that we've been discussing with 
  various large organizations behind the scenes for a while. At the 
  web payments workshop, identity was a common thread for the two 
  days, and we created a number of identity use cases at the 
  workshop which we later refined on these calls.
Manu Sporny:  But the discussion from march to now has been 
  quesitoning whether or not we want to tackle the identity problem 
  for payments. It's a much narrower problem, KYC, money 
  laundering,etc. making sure you can crypto-verify someone sending 
  money is who they say they are.
Manu Sporny:  Some saying we definitely need identity credential 
  verification (identity attribute exchange) for a good web 
  payments system, others saying we don't that bitcoin is good 
  enough and we can rely on legislation and other things to shore 
  up the rest
Manu Sporny:  We've been discussing splitting off the Identity 
  Credentials stuff into its own CG and now have enough large 
  corporate support to do so.
Manu Sporny: W3C Credentials Community Group Charter: 
  https://docs.google.com/document/d/1dPzWbPF0jlox8UHnr522nBWCjLJMQ_vGbbtsA5-pAsg/edit
Manu Sporny:  That is a rough draft of the Credentials CG 
  charter, we need input on it.
Manu Sporny:  It's focused on low and high stakes credentials, 
  it's for storing and transmitting creds, like govt issued 
  licenses, university degrees, etc.
Manu Sporny:  We believe we have enough momentum to launch 
  another group and w3c management at a high level seems to be 
  onboard with two separate initiatives understanding that the web 
  payments work will likely need stuff from the Credentials CG
Manu Sporny:  We want to launch the CG group next week or the 
  week after ... just to get the paperwork, etc out of the way. 
  Then we'll use it as a rallying point for a credentialing 
  initiative at W3C.
Manu Sporny:  And then ask orgs to join the work and make public 
  statements of support.
Manu Sporny:  The work is meant to be very narrowly scoped, we 
  don't want to get stuck in quagmire of identity on the web, 
  rather just work on transmitting and receiving digital 
  crypto-verifiable creds on the web
Manu Sporny:  Evgeny, Tim, it would be great to have Yandex and 
  Microsoft look at the work to see if they want to participate
Manu Sporny:  We are reaching out to US Fed, Bloomberg, etc. to 
  see if they want to participate
Manu Sporny:  This is basically our response to people saying the 
  identity/cred work should be separated from the web payments 
  work, but still making sure it supports the web payments work
Manu Sporny:  Any comments around this?
Joseph Potvin:  Sounds reasonable to me
Manu Sporny:  We're hoping to get w3c paperwork out of way and 
  launch the CG next week, we are thinking of launching with this 
  charter but we're still getting feedback from large orgs on it
Manu Sporny:  It specifies what's in scope and out of scope
Manu Sporny:  Talking about the specs that we contribute to w3c 
  in that group are patent/royalty unencumbered
Manu Sporny:  The charter is really just a modification of the 
  web payments charter, which was created after several weeks of 
  discussion, so if people are happy in web payments CG they should 
  be happy at least with the proposed initial charter
Manu Sporny:  For the Credentials CG

Topic: Feedback on Use Cases Revisions

Manu Sporny: 
  https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases
Manu Sporny:  The next few calls will likely be mostly about 
  comments on the use cases
Manu Sporny:  The use cases on that wiki page, the categorized 
  web payments use cases came out of the web payments workshop, we 
  tried to take every use case that was reported and refine and 
  rework them, not remove them (minus dups), but categorize and 
  make clear what each use case is suppsoed to do, we did that
Manu Sporny:  And sent to the mailing list, but about half of 
  them were still confusing
Manu Sporny:  People asking what use cases are intended to solve, 
  what they mean, terminology, etc
Manu Sporny:  I've gone through all the responses and annotated 
  all the use cases with people's comments
Manu Sporny:  The goal of the call today is to go through those 
  comments and modify the use cases so they make more sense
Manu Sporny:  Any comments on what we're trying to achieve?
Joseph Potvin:  On the item that i raised earlier is that within 
  scope here?
Manu Sporny:  Yes, i added it, we should probably discuss that 
  since we've got you on the call, we did discuss it before and the 
  finding the discussion was that we didn't know if it was 
  enforceable from a technical standpoint
Manu Sporny:  And since it's not enforceable, the likelihood that 
  people use it will be low, people won't give people an option
Joseph Potvin:  As i said in paris, paypal is already letting 
  people do this
Manu Sporny:  Let's pick this up after the general stuff
Manu Sporny:  We do have it down, it's listed as a use case, it's 
  now a use case, it's about 40% down the page (payees and payers 
  negotiate)
Manu Sporny:  It's in scope to discuss, whether or not it's going 
  to stick depends on the discussion

Topic: General Comments on Use Cases

Manu Sporny:  The general comments had to do with whether or not 
  we're calling people customers and merchants/vendors or payers 
  and payees
Manu Sporny: For example, Melvin Carvalho: In crypto currency 
  payments, generally a payment is from one public key to another 
  (ie URI to URI), and may not include either a customer or 
  merchant.
Manu Sporny:  We were using the terms customer and merchant in 
  the use cases
Manu Sporny: Adrian basically made the same point - Refer to 
  "payers" and "payees" rather than "customers" and "merchants" 
  unless the use case is specifically limited to these actors.
Manu Sporny:  Melvin makes the point that some of these are payer 
  to payee, no merchant, adrian has made the same point
Dave Longley:  I think that the general problem here is that the 
  use cases weren't written out in example text enough - throwing 
  in names and such, "this is an example of something that could be 
  supported". We have this inbetween language that makes it sounds 
  limited. [scribe assist by Manu Sporny]
Dave Longley:  If we say "payer" and "payee" we still need to 
  elaborate on who the payer and payee is.  [scribe assist by Manu 
  Sporny]
Dave Longley:  The other issue is, if we come up with those 
  examples, it'll make it look like it's a customer/merchant 
  relationship. So, I don't think we can just address this by 
  changing to payer and payee. [scribe assist by Manu Sporny]
Dave Longley:  I don't think this addresses the problem. Instead, 
  we may need to add more use cases. If they think that somethings 
  not supported, we need to add more use cases. [scribe assist by 
  Manu Sporny]
Joseph Potvin:  The idea of changing the language to payer/payee, 
  is like discussions we've had in the past, this CG that 
  communities of wider scope, this has to do with fitting neutral 
  language, it's not about CG coming up with language, it's about 
  adopting language that has been established
Dave Longley:  I'm not going to dispute that it's better. The 
  context where it's used is going to be confused. We're going to 
  use people's names or company names. Because we're drilling down 
  to an exact situation, they're losing the general scope of where 
  it's used. [scribe assist by Manu Sporny]
Dave Longley:  If we use "Jill is paying on Megacorps website", 
  they'll lose sight of the same technology being used for both 
  situations. Changing "customer" to "payer" and "merchant" to 
  payee, is an improvement, but it doesn't solve the confusion. 
  [scribe assist by Manu Sporny]
Timothy Ng:  I think we generally agree, payer/payee are roles 
  when we discuss this at MS, for example, if you look at one of 
  the roles, if you look at the use cases, Jack may be the payer, 
  identifying roles is important, and maybe even Jack is the 
  customer and his mom is the payee
Dave Longley:  That might be useful once we describe the 
  situation in personalized situations to have the roles that 
  people play. That's where this language could be useful. That's 
  where I think this language should be. We should use 'payer' and 
  'payee' as definitive roles. [scribe assist by Manu Sporny]
Evgeny Vinogradov:  It's not necessary the customer is the payer 
  and merchant is payee. In some cases, like 3rd party escrow, 
  there are different roles. 
Manu Sporny:  So evgeny, do you agree with the role-based 
  assignment, so we use an example name Jack/Jill and then specify 
  the roles they play in these payment scenarios?
Manu Sporny:  Does that seem like an incremental step in the 
  right direction?
Evgeny Vinogradov:  My idea is that we have to differentiate 
  between payer and payee and it's different for customer/merchant, 
  so yes, we need to assign roles.
Manu Sporny:  I'm hearing 4 roles: customer, merchant, payer, 
  payee and they aren't necessarily the same thing
Evgeny Vinogradov:  Yes
Manu Sporny:  Let's try to apply all these roles in the use cases
Joseph Potvin:  To be clear, is a customer not a type of payer?
Evgeny Vinogradov:  Customer can be either payer or payee
Joseph Potvin:  It's not that there are 4 roles, there are subset
Timothy Ng:  I think from "buyer" may be better than customer
Timothy Ng:  For example, when i was young i was the buyer but i 
  wasn't the payer
Timothy Ng:  Buyer may be more appropriate from customer. 
  Customer can be confusing.
Dave Longley:  This might be a level of abstraction that's out of 
  scope. We're trying to make these use cases personalized, so we 
  could have an example where a younger person is making a 
  purchase, the payer is the parent. But, this is probably out of 
  scope for the technology. It's something that happens, but it's 
  not necessarily something that we need to be involved with. 
  [scribe assist by Manu Sporny]
Dave Longley:  This might just be a discussion that we can have - 
  a side note, people can implement systems to allow minors to pay 
  for things. [scribe assist by Manu Sporny]
Manu Sporny:  I think joseph's point was that there's a 
  hierarchical relationship with the roles, evgeny doesn't seem 
  convinced, timng is saying it's better to take a role-based 
  approach, no hierarchy to start but one might show up as we go
Timothy Ng:  I think "customer" is ambiguous, i think defining 
  the roles should be clear, a payer is the source of money, the 
  payee is a receiver, in more complex use cases there may be 
  multiple parties involved in the transaction, so sorting those 
  out will be helpful
Manu Sporny:  I think we should definitely have payer/payee roles 
  in there, we should go role based in this and define what each of 
  these roles does
Dave Longley:  We can have some of the players in the use cases 
  be in multiple roles... that might automatically resolve the 
  hierarchy issue that Joseph raised. [scribe assist by Manu 
  Sporny]
Joseph Potvin: Agreed
Dave Longley:  Ok, we'll have roles, some people in multiple 
  roles. [scribe assist by Manu Sporny]
Timothy Ng:  I agree
Dave Longley:  For each use case, we may want to say something 
  about design requirements needed for use cases to work. If they 
  have this ability in the technology, it would also apply to some 
  sort of Bitcoin situation. So personalized use case, roles 
  required, design requirements in order to make it possible. 
  [scribe assist by Manu Sporny]
Manu Sporny: 
  https://www.w3.org/community/webpayments/wiki/CategorizedWebPaymentsUseCases#Introduction
Manu Sporny:  I've written a proposal, the link is in IRC
Manu Sporny:  Adrian had this comment: "Be specific when talking 
  about identities, or identity attributes (claims), whether the 
  use case refers to the payer's or the payee's identity or both."
Manu Sporny:  That's good advice, we should be specific about 
  identity, we are talking about identity attributes, credentials, 
  claims about a particular identity URL, in general (unless 
  there's disagreement here), we're just talking about the minimum 
  number of attributes about the identity required to complete the 
  txn
Dave Longley:  That's another piece of meta-information that we 
  can include for the use case writeup - "identity attributes 
  required for use case". [scribe assist by Manu Sporny]
Dave Longley:  That'll help us stake out exactly what the Web 
  Payments group needs from the Credentials CG technological 
  solutions. [scribe assist by Manu Sporny]
Manu Sporny:  The other general comment, is basically "do we 
  really need to address this identity attribute issue or can we 
  create a payment solution without any identity exchange at all", 
  could we come up with a digital receipt standard without talking 
  about how the identity is referred to in that receipt
Manu Sporny:  The main sticking point here is not whether or not 
  we can do this
Manu Sporny: So there is an issue about whether or not we can do 
  identity: My suggestion would be to focus the first iteration on 
  payment processing without a need to exchange/verify the payer 
  identity and add this in iteration 2. In terms of discussion 
  within the IG, I think both are appropriate.
Manu Sporny:  In terms of the web payments steering group both 
  are in scope, but the discussion shouldn't focus on identity
Manu Sporny:  It's certainly possible to come up with a payments 
  solution without any identity attached to it, you can transmit 
  value from point A to point B, the problem is that when it comes 
  to the regulatory frameworks in most nations, it's not good 
  enough to have cash going from A to B because you run afoul of 
  anti-money laundering regulation, stored-value regulation, etc.
Manu Sporny:  For example, if you want to be a money transmitter 
  in the US, you have to deal with identity.
Manu Sporny:  Digital Bazaar's position is that identity 
  credentials is definitely in scope because otherwise you fall 
  into the nascar payment problem very quickly, if you can't 
  transmit at least your payment processor list, then almost 
  automatically the payment UI requires you to put all the payment 
  solutiosn you can think of
Dave Longley:  And that shuts out smaller players that want to 
  provide payment solutions. That's the other knock-on effect of 
  that. [scribe assist by Manu Sporny]
Manu Sporny:  Identity attribute exchange is in scope at a 
  minimum to eliminate the nascar problem, and while we're doing 
  that there's a lot that could be transmitted to boost 
  trustworthiness of txns online
Manu Sporny:  Does anyone think that a first iteration of 
  payments without any identity stuff would be interesting or 
  useful to implementors?
Evgeny Vinogradov:  I'm thinking about which use cases could be 
  done without identity, i can't think of them easily, you really 
  need identity for even the most basic ones.
Evgeny Vinogradov:  I think there aren't many cases where we can 
  go without the identity data at all
Manu Sporny:  In general it seems we need identity to do anything 
  decent with this payments stuff
Joseph Potvin:  "Value and Exchange Benchmarking" is the phrase 
  is use to describe this

Topic: Value-in-Exchange Benchmarking

Manu Sporny: So, we have this Use Case: Payee and payers 
  negotiate secure price in an open market. They are free to choose 
  all three essential attributes of the numeric quantity expressing 
  a price (e.g. 10.99), namely: a unit-of-account (e.g. $ £ € ¥ 
  etc.); a medium-of-exchange (e.g. debit card, credit card, web 
  payment etc.); and, a value-in-exchange benchmark (e.g. WM 
  Reuters Spot Exchange; Purchasing Power Parity; Commodity Index; 
  etc.)
Joseph Potvin:  I'm talking with a number of people in different 
  communities for the right terminology
Joseph Potvin:  The issue is... paypal has seen it useful to 
  provide a choice of more than one benchmark when there are txns 
  involving more than one currency, it's not very hard to 
  implement, paypal has done too much on it, but the reason they do 
  that, it's a complex thing to wrap your head around it, they do 
  an incredible job attempting to explain it, in terms of a use 
  case it's actually quite simple, the choice of the benchmark is 
  obviously relevant when there's more than one currency, just as 
  relevant when there's payment over time
Joseph Potvin:  So even in a single currency the issue arises for 
  subscriptions, etc
Joseph Potvin:  As soon as someone needs to think about it they 
  have to scratch their head and think about it, the challenge we 
  have is that not addressing it is a default decision to leave 
  this aspect to an arbitrary supplier, paypal says you can do that 
  or choose ours, there should be more general w3c ways to approach
Manu Sporny:  I don't think the question is whether this is 
  useful to society, etc. it should definitely exist
Manu Sporny:  The question is whether we can technically enforce 
  it
Manu Sporny:  If a merchant specifies a benchmark, is it then 
  "illegal" for a payment processor to ignore that and use whatever 
  they want
Manu Sporny:  Payment processors might just run through anyway, 
  you could argue the merchant could jump in and sue the payment 
  processor because they didn't follow the contract the merchant 
  specified, there's a destabilizing risk there that the payment 
  processors then don't process anything with a pricing benchmark
Joseph Potvin:  I think all of these specifications are 
  voluntary, if i'm a vendor and i have a catalog for something for 
  $10.99 and the intermediary makes it $11.99 and takes a dollar, 
  it's an external issue if the intermediary is imposing
Joseph Potvin:  The problem that we have in the last two decades 
  is we've gotten used to a certain way of doing things because of 
  the way it organically emerged in the web payments space, but the 
  question that arises with the creation of the w3c web payments 
  standard if it proceeds to pave the cow path when it's an unfair 
  cow path or if it specifies out macroeconomic fee for service 
  vs.. microeconomic [missed]
Manu Sporny:  No disagreement from me personally, the concern i 
  have is whether or not this is technically something that is 
  fairly simple to implement; we don't know any of the details for 
  how to implement because we haven't put a lot of thought into it, 
  if we put this feature in, at a minimum, we'll need a protocol 
  for reading the benchmark data, some query protocol saying the 
  merchant set the price on this date, so they are expecting the 
  unit of account and price to be .... they set it in jan 2013 and 
  now someone wants to purchase and now they have to figure out the 
  difference between jan 2013 and jul 2014, and we need a 
  full-blown protocol to do all that
Manu Sporny:  The concern is that every payment processor will 
  have to implement that and if it's not simple to implement, we 
  could see that as one more argument as to why they don't want to 
  use web payments
Manu Sporny:  I know that doesn't resonate with you, as this is 
  the right thing to do because we have an unfair system and if we 
  can right it, we should
Manu Sporny:  My concern is that in trying to do that it may 
  become something payment processors don't want to do
Joseph Potvin:  I think you're over-complicating it, paypal is 
  already doing this, shouldn't there be a spec describing what 
  paypal is already doing
Joseph Potvin:  As with anything, there's a really complex way to 
  look at this and a simple way
Joseph Potvin:  If the CG says paypal is doing that and we don't 
  want to address that use case, then I don't get it.
Manu Sporny:  You're talking about paypal which is a gigantic 
  corp, and implementing this as small players might be difficult
Manu Sporny:  It's non-trivial from an implementation standpoint, 
  ... secondly, we add fragility to the system, if the benchmark 
  goes down, can't get access to it, etc you can't buy things on 
  the system
Manu Sporny:  Counter-arguments, we're talking about a single 
  REST call out, any kind of pricing index that's fragile won't be 
  used by people, they'll just switch to one that isn't fragile, 
  it's about trying to figure out the benefits of doing this and if 
  they outweight the cost
Manu Sporny:  I'm making these arguments more as a devil's 
  advocate
Manu Sporny:  Personally i'd love to see this tech
Manu Sporny:  These are the arguments you'll get from 
  implementors
Joseph Potvin:  This is, at this scope, just the CG identifying 
  use cases for the IG to talk about
Joseph Potvin:  If the IG determines it's too much of a headache 
  to implement, that's a stage one could arrive at
Joseph Potvin:  I think taking it out at this point is to accept 
  one of the great blockages of transparency of web payments off 
  the bat
Dave Longley:  I think it should go in, let's put it in at this 
  stage. Let's get the IG to make the determination. We should put 
  it out there as something that the community has discussed. 
  [scribe assist by Manu Sporny]
Joseph Potvin:  I'll go back and look at the use case and see if 
  i can make it seem less problematic
Manu Sporny:  I think the use case is pretty clear regarding what 
  you're asking for
Manu Sporny:  But we can discuss offline

Received on Wednesday, 30 July 2014 16:26:42 UTC