- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Wed, 30 Jul 2014 17:01:29 -0400
- 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