Web Payments Community Group Telecon

Minutes for 2014-07-30

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: 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: 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: 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

Created by the Web Payments Community Group. Shared with love under a CC-BY license. Thanks to our contributors.