- From: <msporny@digitalbazaar.com>
- Date: Wed, 30 Jul 2014 12:26:19 -0400
- 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-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