- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 17 Jul 2013 13:52:14 -0400
- To: Web Payments <public-webpayments@w3.org>
Thanks to Dave Longley for scribing. The minutes for this week's Web Payments telecon are now available here: https://payswarm.com/minutes/2013-07-17/ Full text of the discussion follows for archival purposes at the W3C. Audio of the meeting is available as well (link provided below). -------------- Web Payments Community Group Telecon Minutes for 2013-07-17 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2013Jul/0013.html Topics: 1. Update on GSoC Student Progress 2. Conference Presentations for Web Payments 3. Browser Payments Updates 4. ISSUE-2: Pure chrome-based buyflow 5. Application-specific data in a JWT Chair: Manu Sporny Scribe: Dave Longley Present: Dave Longley, Manu Sporny, Andrei Oprea, Travis Choma, Kumar McMillan, David I. Lehn Audio: http://payswarm.com/minutes/2013-07-17/audio.ogg Dave Longley is scribing. Manu Sporny: Agenda today is covering Andrei's progress, some discussion about upcoming conferences about web payments, spec updates, browser payments single-click purchasing. Topic: Update on GSoC Student Progress Andrei Oprea: currently i'm trying to purchases available in my marketplace example, you can make listings but i've run into some problems that i'm trying to fix with purchases Andrei Oprea: afterwards i'd like to focus on more options like reselling (make that available in the marketplace) Andrei Oprea: and add validation for the data because currently anything typed in is accepted Manu Sporny: we've been trying to help with issues on IRC ... is there anything else you want to cover on the call today? Andrei Oprea: one question i have is about the listing ... it has fields like "destination" and "payee" and all of those aren't quite clear to me Andrei Oprea: there are identities that you have to fill in Andrei Oprea: so.. destination is where the money is going, who is going to receive the money Manu Sporny: yes, that's correct, if a purchase occurs that's where the money should go Andrei Oprea: is the vendor is marketplace or the person who created the asset/is selling it Manu Sporny: it can be either, it depends on the use case, for a large music provider they might allow fans to sell their music but for each sale they want 80% of the sale, sony would create the asset and describe some restrictions there, but a fan could then list (create a listing for the asset) on their blog and talk about it Manu Sporny: and in this case the assetProvider would be the music provider (eg: Sony) and vendor would be the fan selling Dave Longley: Before we go further, I want to clarify - the vendor is going to be the marketplace in your use case. [scribe assist by Manu Sporny] Dave Longley: The use cases Manu just described probably don't apply to you. If you want to make assets in the marketplace available for sale on other websites, you can do that, but the vendor would have to sign that listing, not the marketplace. [scribe assist by Manu Sporny] Andrei Oprea: so my last question was about the assetHash/licenseHash Dave Longley: What is the license hash? [scribe assist by Manu Sporny] Dave Longley: In PaySwarm, since you're putting things out on the Web, when you retrieve the URL you might get content back that's different from day to day. In order to deal with that problem, we hash the contents to make sure that the contents are what are expected. [scribe assist by Manu Sporny] Dave Longley: The license hash is a hash of all of the data about the license. So if someone goes out and retrieves all of the information, the PA will go out and check to make sure the hash is the same thing. [scribe assist by Manu Sporny] Dave Longley: We have to ensure that everyone in this process sees the same license. It's a way of verifying that the information has not changed. [scribe assist by Manu Sporny] Manu Sporny: Andrei asked how the hash is generated. [scribe assist by Manu Sporny] Dave Longley: The license page has to have a syntax that can be converted into RDF - either JSON-LD or RDFa right now. We retrieve all of the information from a web page, we normalize the RDF, and the stream of bytes is sent through a hashing algorithm. [scribe assist by Manu Sporny] Dave Longley: You can put a license up as RDFa or JSON-LD, either one. [scribe assist by Manu Sporny] Manu Sporny: There is a utility in payswarm.js that helps you generate hashes. [scribe assist by Manu Sporny] Dave Longley: You can just use the API calls to generate a hash, and there is a tool that can give you the hash bundled with payswarm.js. [scribe assist by Manu Sporny] Travis Choma: hi guys, was stuck in traffic. dialed in now. Manu Sporny: kumar have you guys dealt with associating licenses with purchases, etc? Kumar McMillan: we don't have anything like that specified, it's up to the app that does the sale right now Kumar McMillan: so an app will get a receipt to make sure something was paid for, but it's all in their hands to manage [licenses, etc] Topic: Conference Presentations for Web Payments Manu Sporny: so the first conference will be Inside Bitcoins: http://www.mediabistro.com/insidebitcoins/ Manu Sporny: so we're going to talk about how the browser payments API and the payswarm protocol will be used to support bitcoin Manu Sporny: i'm going to try and recruit folks there, we're going to have some core bitcoin software developers there and we're going to try to get them involved in this group so we can get some inputs on how to process bitcoin payments so we can talk about how to properly do it in the browser. Manu Sporny: the other thing that might come out of this is that payswarm is currency agnostic and bitcoin is one of the features that's next on our timeline (hopefully within the next year) and we want to get people involved from that community Manu Sporny: kumar, anything w/respect to mozilla you'd like me to mention? Kumar McMillan: i'd like to know if it would be possible to use navigator.mozPay() to do a bitcoin purchase without any intermediate server whatsoever Kumar McMillan: i know there are ways to generate a bitcoin wallet in JS (generate the keys on the client, etc) but i don't know about sending the payment to another party, i think there needs to be servers involved somewhere, but it would be cool if not Manu Sporny: the biggest thing working against bitcoin payments like that is the time it takes to verify payments on the network (it can take up to 30-90 minutes), so the idea that you can get instant access to stuff is kinda shaky Manu Sporny: but new services are providing short term credits to people so that people can buy things instantaneously online without the transaction going through immediately Manu Sporny: and that's kind of the way payswarm was going to work with bitcoin here -- the biggest blocker is that you can't get a receipt back immediately, you have to wait for stuff to get integrated into the blockchain Manu Sporny: but i'd like to be able to say mozilla's really interested in getting this to work so who can we work with, who is interested in joining us to make this happen Travis Choma: if we can find a proof of concept that makes sense for the minimal use case that would be great, i'm sure we can find some resources as mozilla to help out too Manu Sporny: with payswarm the vendor could sign something and give it back to you and you could submit it Manu Sporny: there are a lot of offline use cases in payswarm that could apply here to bitcoin as well Travis Choma: is the 30-90 minute window a fixed window? Manu Sporny: it's been increasing because the number of txns has been going up, it depends on the number of txns on the network/hashes to verify/etc. Manu Sporny: there are fees you can pay to move things into a block that's sooner vs. later, etc. Manu Sporny: most importantly, it's probably not ever going to go down below 10 minutes, at least that's what a lot of people think Manu Sporny: unless you allow the miners to take high fees out of the txn Manu Sporny: there are all kinds of trade offs when dealing with bitcoins, but the idea that it would be instantaneous won't work with the traditional model (there are some forks trying to work on this) Manu Sporny: if you trust the entity doing the purchase you can always essentially extend credit for that period of time Manu Sporny: but i dont' see people like NYT, apple, larger companies taking on that much risk, etc. Manu Sporny: so that's inside bitcoin, and i'll tell them we really want to work with them to make browser bitcoin work Manu Sporny: next is SIBOS 2013: http://www.sibos.com/sibos_2013_dubai.page Manu Sporny: this is when all the member banking companies involved with swift meet up Manu Sporny: i'm giving 5 talks, one on financial standards, i'll be talking about payswarm, mozPay, JSON-LD and data about financial info, and how all this changes the way people deal with money, etc. Manu Sporny: and tchoma, kumar, you want me to reach out the same way there? Kumar McMillan: yeah, i think so Kumar McMillan: if there's anyone that wants to work on the spec that would be a good place to pitch that Manu Sporny: there's a workshop too, some of that has to do with payments in the browser, i'm trying to get 30-60 minutes and maybe get someone from mozilla there Manu Sporny: i've arranged so that it would be paid for, but it's more of a time thing Manu Sporny: it's in dubai, so it's kinda a long trip Travis Choma: we can discuss offline, sure Kumar McMillan: there's an email floating around but no definitive responses yet Manu Sporny: after that are a couple of talks in LA Manu Sporny: mostly the same approach about payswarm mozPay, etc. payments in browser -- come join us if interested Manu Sporny: then the united nations internet goverence forum: http://www.intgovforum.org/cms/aboutigf Manu Sporny: they are interested in IP dissemination and having standards for doing that on the web, so it's a lot about payswarm, but i'll try to also cover payments in the browser Manu Sporny: then onto W3C TPAC in china: http://www.w3.org/2013/11/TPAC/ Manu Sporny: anyone from mozilla? Kumar McMillan: i'm not sure, not that i know of Manu Sporny: we'd like to try and get more W3C member companies to join web payments, chrome team, apple, MS, to participate in payswarm browser API work , etc Manu Sporny: let's get a working group started, get some W3C staff assigned, etc. -- to get stuff moving faster than we're able to do by ourselves, do a workshop there to try and get interest Kumar McMillan: yeah, sounds like a good idea Manu Sporny: there's Edge too: http://edgeconf.com/ Manu Sporny: I'll meet you there, Kumar - we'll focus on browser payments and PaySwarm. Topic: Browser Payments Updates Manu Sporny: https://github.com/web-payments/browser-payments/commit/4ab74174b6440697b0f08a2279b4cdbecb18fb8a Manu Sporny: so i updated the browser payments spec, made a fairly simple set of commits, mostly what we discussed on the call last week Manu Sporny: http://web-payments.github.io/browser-payments/ Manu Sporny: i know you had some questions in there that i haven't been able to look at in there Kumar McMillan: the only main question was that we were going to just specify the .well-known path and the fields needed Manu Sporny: ok, i wasn't sure we agreed to that, i can take a pass and just put it in there Manu Sporny: so right now they specify an ID and a services URL which is going to be that .well-known path, i didn't know if we wanted to keep the ID for the service provider separate from the path used to look up the information Manu Sporny: about the service, because you could provide different services, there could be a payswarm URL and a browser payments URL ,etc Manu Sporny: there are two ways to do things, could just have an ID and based on the type of provider they would know what suffix to put onto .well-known Manu Sporny: is that what you were thinking? Kumar McMillan: it seemed like we have a need to declare a registration URL and for mozPay we already need a URL for the beginning of the payment flow, so i figured that since there are 2 URLs already we could start the .well-known spec now and add more things later, otherwise we're going to clutter up the object Manu Sporny: yeah, exactly, i'll go ahead and add .well-known/payments for now Kumar McMillan: maybe /transact Dave Longley: yeah, it's more generic but not too generic for what we want Kumar McMillan: i think transact is better than payments Dave Longley: also, donations - people might not consider them payments. [scribe assist by Manu Sporny] David I. Lehn: Is 'transact' the right form? 'transactions' [scribe assist by Manu Sporny] Dave Longley: let's look at what other people have done for naming and figure out the details of what we want later Manu Sporny: the other question that came up is whether or not refund should be a different call Manu Sporny: should we have navigator.transaction.refund()? Manu Sporny: should we have navigator.transact.refund()? Manu Sporny: should we have navigator.transact.donate()? Manu Sporny: should we have navigator.transact.crowdfund()? Dave Longley: We should talk about JWT vs. JSON-LD first. [scribe assist by Manu Sporny] Manu Sporny: my preference is to use an object because it's more extensible Dave Longley: i agree for the same reason Kumar McMillan: i agree Topic: ISSUE-2: Pure chrome-based buyflow Manu Sporny: https://github.com/web-payments/browser-payments/issues/2 Manu Sporny: https://github.com/web-payments/browser-payments/commit/a0885d71abbc90efad5743752f67b014f7143b26#L0R735 Manu Sporny: two high-level use cases to support, 1. in-app payments where customer clicks buy and automatic budget/authorization so that when they click payment just goes through automatically Manu Sporny: 2. where a customer doesn't have a budget set up and they click buy and see a receipt Manu Sporny: any other main uses caseS? Kumar McMillan: no, makes sense to me, we should call that out in the spec as something that's required of the user-agent, the one-click payment might require a slightly different implementation, some memory to store something to make repeat payments Kumar McMillan: maybe there would be prefetching of a URL to check for authorization for one-clicks, etc. Manu Sporny: the flows would be different for providers, for payswarm, the customer would click the button and the browser itself would digitally sign the contract to make a purchase Manu Sporny: for google wallet it would require a different kind of flow Manu Sporny: i'm wondering if we need something in the spec to say a one-click purchase has been started and the vendor has to implement some part of it, so having a callback where the browser is going to contact the payment provider, etc. Kumar McMillan: i think it's very possible to make it work generically so it's about making things route properly Dave Longley: I'm not sure that this is even required for the PaySwarm case. The vendor knows if payments are pre-authorized. [scribe assist by Manu Sporny] Dave Longley: In the PaySwarm case, the vendor doesn't even need to use this API. [scribe assist by Manu Sporny] Manu Sporny: What about the non-preauthorized case? [scribe assist by Manu Sporny] Dave Longley: That's a different use case. [scribe assist by Manu Sporny] Travis Choma: In the case of pre-authorized cases, this could be a zero-click purchase... payments made by regular use of website. [scribe assist by Manu Sporny] Dave Longley: yeah, it doesn't matter at all for pre-authorization, it could be a subscription, etc. no user input Manu Sporny: so maybe one-click is a red-herring, we're talking about payments that need authorization vs. ones that don't Kumar McMillan: i agree, but i dont' think we need to make any changes to the spec, we just need to call things out in the spec because it may require changes to how navigator.pay is implemented in the user agent, because, for instance, it's implemented right now so that a window is always opened which we wouldn't want in some cases Kumar McMillan: we might need to add something like the register call that says "set a preference" to remember one-click payments Manu Sporny: yeah maybe just a set of prefs that says if the payment is under X then don't ask me, etc. Manu Sporny: for this vendor, etc. Kumar McMillan: mozilla is very interested in one-click payments, so it's on our radar next, we haven't put any thought into it yet because we're always showing a pin before the user can make a purchase Manu Sporny: maybe what we need is to suggest that the browser/user agent implement a set of preferences that are associated with each website Manu Sporny: those preferences could allow payments to be done automatically, could allow receipts to always been shown after purchases, etc. Manu Sporny: in addition to the API ... when a purchase is done they could add something to indicate that something has been preauthorized Kumar McMillan: we need to be able to set a preference on the device Manu Sporny: so there is going to be a section of the spec for preferences for user agents to implement Kumar McMillan: maybe just saying that the user-agent needs to support one-click payments Manu Sporny: ok, i'll take a cut at some text for this Topic: Application-specific data in a JWT Manu Sporny: kumar, could you outline what the thought process was for selecting JWT? Manu Sporny: and where mozilla would like to see things go in the future Kumar McMillan: JWT was just selected so we could verify a signature ... and it seemed straightforward, we looked at google wallet and wanted to keep parity with their format, we could change if there are some good arguments, it's not a big deal Kumar McMillan: we want it to be as simple as possible as devs will have to deal with this Kumar McMillan: there are probably good arguments to this Kumar McMillan: but it definitely seems to add a little bit of complexity Kumar McMillan: i've looked at some of how MS's payment API works and it's pretty complex with a lot of types and restrictions, some sort of XML format and i don't think it has to be that complex, we want to avoid complexity it's a goal Manu Sporny: so the goal behind JSON-LD was to make something familiar to JSON devs without adding too much complex Manu Sporny: there's complexity in the background but it's hidden by just using a library Manu Sporny: the reason we're using JSON-LD -- the primary reason -- is to support decentralized extensibility, we want people to be able to provide more information in digital contracts that they can't do otherwise Manu Sporny: say like you buy things at home depot, could home depot embed data that is very specific to home depot into that digital contract to the customer and then keep that data as the data for the sale, is it possible for the vendor to extend the data in there Manu Sporny: if we can do the same sort of thing with JWT that's great, but the downside of JWT is that there are two different signature stacks for JSON-LD vs. JWT Manu Sporny: i think the goals are aligned, in that we're trying to reduce complexity as much as possible, we don't want to get into a situation where we are at MS-XML format level Manu Sporny: i was going to try and sit down and do a comparison between them Manu Sporny: of JWT and JSON-LD Dave Longley: I think that we may find that JSON-LD has features that you don't /have/ to use. The JSON will probably not look very different from what the JWT already looks like. [scribe assist by Manu Sporny] Manu Sporny: yeah, i already went through and saw that we could use the same format with JWT as JSON-LD Dave Longley: JSON-LD would be used for decentralization. [scribe assist by Manu Sporny] Manu Sporny: does mozilla use a JS JWT lib? Kumar McMillan: we do it on the server, so it's python Manu Sporny: for JSON-LD we have python, JS, php, ruby Manu Sporny: would you need anything in C++ for the client? Kumar McMillan: i don't know, we could ship that i guess Kumar McMillan: we're just doing stuff on the server now for signatures, etc. Manu Sporny: we can do that stuff in JS now, we have https://github.com/digitalbazaar/forge Kumar McMillan: yeah, right, it can be done, but from a security standpoint there's no good way to store a private key yet Kumar McMillan: on the client Manu Sporny: right Kumar McMillan: i think that calling things out with JWT like it isn't very extensible because it just has a string field for 255 chars of user data Kumar McMillan: would be helpful Manu Sporny: ok, makes sense -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/
Received on Wednesday, 17 July 2013 17:52:36 UTC