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

Re: Web Payments Telecon Minutes for 2014-07-30

From: Joseph Potvin <jpotvin@opman.ca>
Date: Wed, 30 Jul 2014 17:01:29 -0400
Message-ID: <CAKcXiSrrkq0_iRryTeOqib1LDQ3FB_0TH1=6ug2BADkrPHWR+w@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: Web Payments CG <public-webpayments@w3.org>
This note is just to complete a missed sentence:

RE: " 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]"

Should be:

if it proceeds to pave the cow path when it's an unfair cow path. A
W3C specification should not conflate a microeconomic "fee for
service" with a macroeconomic "value benchmark" just because doing so
is a common error amongst some major incumbents.

-- 
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983

On Wed, Jul 30, 2014 at 12:26 PM,  <msporny@digitalbazaar.com> wrote:
> 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 21:02:17 UTC

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