- From: <msporny@digitalbazaar.com>
- Date: Thu, 12 Feb 2015 11:56:36 -0500
- To: Web Payments CG <public-webpayments@w3.org>
Thanks to Dave Longley and Manu Sporny for scribing this week! The minutes for this week's Web Payments telecon are now available: https://web-payments.org/minutes/2015-02-10/ 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 2015-02-10 Agenda: https://lists.w3.org/Archives/Public/public-webpayments/2015Feb/0004.html Topics: 1. F2F Use Cases 2. Desired Outcomes from the Face-to-face 3. F2F Credentials Discussion 4. Next 3-6 Months of Work 5. Decentralized identifiers Chair: Manu Sporny Scribe: Dave Longley and Manu Sporny Present: Dave Longley, Manu Sporny, David I. Lehn, Joseph Potvin Audio: https://web-payments.org/minutes/2015-02-10/audio.ogg Dave Longley is scribing. Manu Sporny: Any changes to the agenda? None Topic: F2F Use Cases Manu Sporny: https://www.w3.org/Payments/IG/wiki/Meeting_Summary_Feb2015#Use_Cases Manu Sporny: The following use cases were approved at the Utrecht F2F. It basically covers the steps of a transaction. Manu Sporny: Initiating a Payment Manu Sporny: Partially Blinding Payment Information Manu Sporny: Choosing a Payment Instrument Manu Sporny: Making a Payment Without Registering Manu Sporny: Payer-initiated Funds Transfer Manu Sporny: Limiting Payee-initiated Payments Manu Sporny: Proof of Payment, Hold, or Funds Manu Sporny: Refunds Manu Sporny: Applying Coupons and Loyalty Cards to a Payment Manu Sporny: Performing a Payment in Multiple Phases Manu Sporny: The text looks different from the use cases we were looking on because people had problems with us saying "push based payments" or "pseudo anonymity" which was changed to "partially blinding payment information" and "push based payments" was changed to "payer-initiated funds transfer". There were people who had issues with "pull vs. push" payment language, so we'll have to change that. Manu Sporny: All the use cases were integrated into the spec, so for example... Manu Sporny: For example, this is a link to the payment initiation use case: https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#initiating-a-payment Manu Sporny: We're going to need to refine the use cases a bit and need the web payments CG to review, we'd like to get it out by march so the more reviews we get in the better. People have said that they want the requirements to be stripped out of there. Manu Sporny: A number of people felt that the generalized introduction isn't what we wanted to do, rather we wanted a more loosely defined introduction, but the problem with that is the same problem we had when we tried a loose introduction before where people thought it was too vague, etc. So right now we have, in the spec, a fairly technical high-level 1-2 sentence description of it and then talk about points of view (payer, payment processor, etc.) and then we talk about why it's important and a requirements section. That's the template we have right now for the use cases. Topic: Desired Outcomes from the Face-to-face Manu Sporny: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Feb/0002.html Manu Sporny: Chaals put together a desired outcomes list; people didn't have an issue with them, he said they were apple pie statements (they are benign). The goals of the group are fast adoption of the technology, create a level playing field, reduce transaction fraud, reduce amount of software necessary, removal of need for merchant to hold onto customer data, etc. Manu Sporny: - A fast and significant adoption of the technology (>100M+ in the first two years). Manu Sporny: - Level playing field (aka fair competition) for merchants, payment providers, customers, software vendors, and payment networks. Manu Sporny: - A great reduction in "stolen card" transaction fraud. Manu Sporny: - A great reduction in the amount of custom software that a merchant must write to integrate with new payment products. Manu Sporny: - Removal of the need for a merchant to hold on to sensitive customer data. Manu Sporny: - Greatly reduced payment provider switching costs for customers and merchants. Manu Sporny: Chaals added these items: Manu Sporny: - Does not add (ideally reduces) the time required to make a payment Manu Sporny: - Enables value-added services to help payers Manu Sporny: - Requires as little new technology and as few standards as possible Manu Sporny: - Enables anyone to understand what they are doing (esp. its cost) when they make a payment to another person (or system or company or object) Manu Sporny: - Does not interfere with the ability to meet regulatory requirements Manu Sporny: - Enables people to "take their money out of the system" Manu Sporny: - Can be delegated to an "agent" (device, automated process, etc). Manu Sporny: Some of them are vague so he's reworking them in the wiki. The idea here is that there's a set of desired outcomes that will probably go in the roadmap doc and maybe in the use cases doc as well., Manu Sporny: We want to quickly outline high-level goals. Topic: F2F Credentials Discussion Manu Sporny: https://www.w3.org/Payments/IG/wiki/Meeting_Summary_Feb2015#Use_Cases Manu Sporny: The group discussed the importance of Credentials for Know-Your-Customer and Anti-Money Laundering regulation, and seemed to indicate loose consensus on the following: Manu Sporny: Credentials are an important part of Payments. Manu Sporny: It would be very difficult to meet regulatory compliance without some basic credential support. Manu Sporny: If a Credentials Working Group is recommended, it should be separate but coordinated-closely with the Payments work. Manu Sporny: The group talked about the need for credentials for KYC, anti-money laundering, etc. There was loose consensus in that people agreed they were important (credentials) for payments. If a credentials WG is recommended, everyone agreed that it should probably not be lumped in with the payments work. If a payments WG is created at W3C a separate credentials WG should be created and they should work independently but closely. Manu Sporny: The credentials work is important to more than just financial services, eg: health care, government service-type orgs, etc. Manu Sporny: Education, etc. Manu Sporny: There were a number of other new task forces that were created and I'm a bit concerned that we have a lot of task forces now. We have like eight now and that may be spreading people thin. Manu Sporny: We may need more concentrated work on use cases, roadmap, and payment agent design. Manu Sporny: https://www.w3.org/Payments/IG/wiki/File:Extended_four_corner_model.png Manu Sporny: There was a pretty interesting diagram -- there was a discussion about a vocabulary that's been used and ... Manu Sporny: Everyone in the group was able to make the three corners models google wallet, etc. and the four corners models like visa, MC onto this diagram. Manu Sporny: All of those things are glossary terms that we need to pay attention to. Manu Sporny: We want to do some industry outreach and I think all that stuff... we're going to wait until the minutes are published until we talk about that with any more detail. Manu Sporny: There was quite a bit of discussion about the payment agent architecture and how that's being done and we need to have a pretty deep discussion on exactly what the architecture for that kind of stuff is. In general that's a summary of what happened at the F2F. I think we were expecting 18 and we got around 30, it was great. Around two crypto-currency orgs showed up, Ripple Labs joined W3C and attended and so did Ethereum, so now we have some cryptocurrency folks involved now. Any questions before we move into the next topic? Topic: Next 3-6 Months of Work Manu Sporny: * Proof-of-Purchase/Hold/Funds Manu Sporny: * Digital Receipts Manu Sporny: * WebDHT / Where are you From Manu Sporny: * Identity Credentials Manu Sporny: The way the current CG work is going, the p3 implementation is going, we made an assumption that the payment system would have some mechanism for encoding a digital receipt as a core part of the payment network. For example, when you buy something you can use Linked Data and attach the entire inventory of what you're buying and include it in what you're buying. And we've discovered that the retailers don't want the payments systems to see that data, that it's proprietary, it's their data. They dont' want the big tech companies to see the products they are buying, etc. They don't want to be disrupted by sharing this data. Manu Sporny: If you can advertise to people because you know what they want before they head into the store the brick and mortars may have reduced business, etc. Manu Sporny: So when we talk about digital receipt and proof of payment, the problem with the digital receipt and offer portion... that's the other part that came up is that the group doesn't think that offers are essential for v1. The idea that you'd put an offer up on a website and a search engine would index it, etc. they aren't concerned with achieving that. Manu Sporny: The best I could do is say that there are large search companies that are interested in that. The idea that there would be a machine-readable offer on a webpage didn't seem compelling to many participants in the room. We need to also find a way to decouple the digital receipt from the payment request. Maybe you could encrypt the digital receipt all the way through to the customer. Someone else said all they need is a merchant reference number and then they can reconstruct it on their side. But this is a problem for customers getting really detailed receipts for them to store. Manu Sporny: If that's not in the critical path then it becomes an afterthought and maybe the merchant will write the receipt somewhere that the customer can access but maybe not. Manu Sporny: It could end up that retailers just don't implement this. Manu Sporny: So we might have to back off of digital receipts and focus on proof of purchase/hold/funds. The other thing that we need to talk about is this whole decentralized identifier thing, WebDHT, etc. and how that fits in with the identity credentials stuff. We could end up reusing the decentralized identifiers for identifying financial accounts, identities in the system of course, and creating pseudo-anonymous identifiers as well, so it has a big impact on that as well. Manu Sporny is scribing. Dave Longley: My thoughts on digital receipts/offers - at a bare minimum, what I'd like to see - payment initiation messages should be in JSON-LD / Linked Data format, so if you want to offer information to end up in a digital receipt, at a bare minimum you can offer that information. Dave Longley: So, people can offer that as a value-add. Same thing for digital receipt on way back - should be JSON-LD. We should spec out ways to include encrypted data if they want to. All of this can work, but for larger retailers/small retailers - if you don't want to include your items in the receipt, you don't have to - you can use an identifier. They can keep their information private if they want to. However, if they don't have a problem doing that, they can put that information in there and run it through the transaction. Dave Longley: We don't want to prescibe stuff that retailers /have/ to do - we don't want to push show stoppers on people. These are JSON-LD messages, you can put what you want in them. Manu Sporny: People were concerned about digital receipts and offers - they were afraid it would take it into the weeds. Dave Longley: We should provide those as options, it's achievable - payment processors need to preserve information in the request and include it in the receipt. Larger retailers would want that anyway - preserve my merchant IDs in there. Dave Longley: All data from payment initiation should pass through - if we figure out a way to do pass-through data, then we enable innovation to happen. The other thing that's important is, it might be difficult for flows/use cases we've had in the past if payment processors can't display to their users what they're buying. Dave Longley: If you start requiring a trusted UI, you have problems. So, when you go to pay for these things, we want to be on a payment processors site for a lot of these use cases. Merchant X wants $5 - if that's all you can see, then it's not as nice as what we've designed before. Merchant X wants $Y for Z items. Manu Sporny: One of the other things that came up was that many people were concerned about ensuring that legacy payment systems operated in this new frame that we were outlining. A number of people were really concerned that we kept talking about push payments and the card network folks wanted to know about their industry (incredibly large) supports that as well. I pushed back quite a bit that we would start handing over information [scribe assist by Dave Longley] Dave Longley: To the merchant in these messages and most other people said we don't want to do that, but what we do want to do is be able to pass through proprietary card network data, like emv code tokenization cryptogram. So from the payment terminal to the payment system that can go into the legacy payment system by the merchant to initiate the funds transfer. Manu Sporny: So we have to start demonstrating some of the other stuff as well, like, how does the proof of funds or proof of payment, can we pass back an emv co cryptrogram and can the merchant use that and pass it into the legacy system. [scribe assist by Dave Longley] Dave Longley: I think the simple answer is "yes" we need to support that and it shouldn't be a very big change to what we're doing. Dave Longley: The general flow is still the same - you use the "proof-of-*" to get what you want from the legacy network. Dave Longley: Unfortunately for the customer, that doesn't quite work in the ideal way, but we can support that w/o changing much at all. Manu Sporny: This agenda topic is basically, what are we going to focus on for the next 3-6 months of work. I guess this concept of ... we need to decouple the offer and the line items a bit more and the thing we return back isn't necessarily a digital receipt but a proof of purchase/hold/funds and in that thing the merchant might get some token to do pull payments. [scribe assist by Dave Longley] Manu Sporny: We want to have the ability to include the list of goods that would be purchased and we want to be able to put cryptograms, etc in the response. [scribe assist by Dave Longley] Manu Sporny: What we might want to do is detail exactly what these messages look like. [scribe assist by Dave Longley] Manu Sporny: There are a number of people that wnat to see what the messages look like. [scribe assist by Dave Longley] Dave Longley: I actually don't think much has to change. Instead of payment initiation being an offer... we can have a payment initiation object that could contain an offer. If there is no offer - it's just a request for money. Manu Sporny: I think the focus is, let's get the messages correct and into a presentable form for the Web Payments IG and see if that's what they're looking for. For the next 2 months use cases will be sent out there and hopefully the Web payments CG can say those are the use cases and these are what the messages could look like with JSON-LD and signatures, etc. [scribe assist by Dave Longley] Manu Sporny: I agree it's not a huge change but it is a change to the underlying messaging format. [scribe assist by Dave Longley] Manu Sporny: So the last two things have to do with the WebDHT, where are you from problem, etc. and the DID/Credentials spec. [scribe assist by Dave Longley] Topic: Decentralized identifiers http://opencreds.org/minutes/2015-02-10/#topic-4 Manu Sporny: This is something we shouldn't put in the critical path for anything, but it's something the Web Payments CG should look at. We do believe there's a solution for it, but we need to work through all the technical details for it to see if it's something that's doable. [scribe assist by Dave Longley] Dave Longley: General agreement that there are a lot of ideas out there to explore to solve the problem. It's probably a solvable problem, but we're trying to reduce complexity. Can we fit it in w/ the rest of the work? Implementation and testing work to do. Manu Sporny: We'll need to raise some foundation money to put some people on it, because it's a fairly large task. [scribe assist by Dave Longley] Manu Sporny: I don't know if it would be as big as JSON-LD but I could see it becoming nearly that size. [scribe assist by Dave Longley] Manu Sporny: I think the group is going to start hearing more about it, this WebDHT, IC stuff. The IC stuff is being taken care of in the Credentials CG and the WebDHT hasn't really been started and needs to get started sooner than later. [scribe assist by Dave Longley] Manu Sporny: Anything else to discuss or be concerned about? [scribe assist by Dave Longley] Joseph Potvin: Yup Manu Sporny: We'll do one more of these at night and if we don't get anyone else from asia pacific we'll move back to day time in the US. [scribe assist by Dave Longley] Joseph Potvin: Is payment attributes use case still "in"? Manu Sporny: Well, it's not out, it hasn't been voted on by the group because the people assigned to fill out the use case haven't filled it out yet. [scribe assist by Dave Longley] Manu Sporny: It hasn't come up on the docket yet. [scribe assist by Dave Longley] Manu Sporny: So, no, it's not out. And the group seems to be fairly reluctant to say anything is out, it's just a question of priority. [scribe assist by Dave Longley] Manu Sporny: Let me check the use cases, one sec. [scribe assist by Dave Longley] Joseph Potvin: Lots of work going on here on that one -- but not yet coherent Joseph Potvin: So here it's okay if it's empty presently -- we'll be contributing soon https://www.w3.org/Payments/IG/wiki/Use_Cases_Task_Force#Choosing_the_Attributes_of_Price Joseph Potvin: Ya, saw that -- I was just checking if it's "up to date" as such Manu Sporny: If joseph is going to be contributing to it, he should do it ASAP; it would be best if joseph took what's in the wiki and filled out the examples details, etc. all that. [scribe assist by Dave Longley] Manu Sporny: That would be good. [scribe assist by Dave Longley] Manu Sporny: It is up-to-date [scribe assist by Dave Longley] Manu Sporny: It just hasn't been filled out yet. [scribe assist by Dave Longley] Joseph Potvin: Okay -- i'd like if you could point me to the section of the wiki Manu Sporny: Since Ripple Labs has joined they might be fairly interested in the whole value exchange stuff ... Ethereum as well. Joseph should talk to Evan from Ripple and Vinay from Ethereum [scribe assist by Dave Longley] Manu Sporny: If they have any thoughts on the use case. [scribe assist by Dave Longley] Manu Sporny: Jpotvin, here's the section of the wiki you should fill out: https://www.w3.org/Payments/IG/wiki/Use_Cases_Task_Force#Choosing_the_Attributes_of_Price Joseph Potvin: I'm working on this with http://www.dkl.com/corporate_overview.html Manu Sporny: And unfortunately, you need to be a W3C member to do that - but you can also send your comments into the public-webpayments-ig-comments mailing list. Joseph Potvin: All good -- our work can be contributed anyways Manu Sporny: The team looks fairly impressive. [scribe assist by Dave Longley] Joseph Potvin: Cool bunch Manu Sporny: The Web Payments IG has to respond to comments you send in, so send them in early and often :) Manu Sporny: Ok, anything else? [scribe assist by Dave Longley] Joseph Potvin: Ya, we've been deep-thinking some things Joseph Potvin: That's all for now Joseph Potvin: Thanks Manu Sporny: Send it to the mailing list if you can share. Manu Sporny: Ok, thanks - ending the call, then. Joseph Potvin: G'night
Received on Thursday, 12 February 2015 16:57:05 UTC