- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Fri, 13 Jan 2012 16:43:38 -0500
- To: Web Payments CG <public-webpayments@w3.org>
bcc: OpenTransact Thanks to Dave Lehn for scribing, the minutes for today's call are now available here: http://payswarm.com/minutes/2012-01-13/ Full text of the discussion follows for archival purposes at the W3C: Web Payments Community Group Telecon Minutes for 2012-01-13 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2012Jan/0007.html Facilitator: Manu Sporny Scribe: David I. Lehn Present: David I. Lehn, Manu Sporny, Pelle Braendgaard, David Nicol, Jeff Sayre Audio: http://payswarm.com/minutes/2012-01-13/audio.ogg David I. Lehn is scribing. Manu Sporny: Overview of agenda. Followup to PaySwarm and OpenTransact comparison and discussion over last month. Then planning a path forward once philosophical and technical issues are resolved. Topic: PaySwarm / OpenTransact Technical Comparison Highlights Manu Sporny: First is PaySwarm and OpenTransact comparions discussion happening over the last month. During the last telecon Pelle had concerns with how group was proceeding and wanted us to look at OpenTransact and see how we could merge that work. Manu Sporny: Based on request did a comparison from our perspective in a blog post and there were followup posts and responses. Manu Sporny: Web Payments: PaySwarm vs. OpenTransact Shootout (Part 1) Manu Sporny: http://manu.sporny.org/2011/web-payments-comparison/ Manu Sporny: OpenTransact the payment standard where everything is out of scope Manu Sporny: http://stakeventures.com/articles/2011/12/21/opentransact-the-payment-standard-where-everything-is-out-of-scope Manu Sporny: Web Payments: PaySwarm vs. OpenTransact Shootout (Part 2) Manu Sporny: http://manu.sporny.org/2012/web-payments-shootout-part-2/ Manu Sporny: OpenTransact vs PaySwarm part 2 - yes it's still mostly out of scope Manu Sporny: http://stakeventures.com/articles/2012/01/02/opentransact-vs-payswarm-part-2-yes-its-still-mostly-out-of-scope Manu Sporny: Web Payments: PaySwarm vs. OpenTransact Shootout (Part 3) Manu Sporny: http://manu.sporny.org/2012/web-payments-shootout-part-3/ Manu Sporny: Discussion has moved onto mailing lists, has fragmented into various topics, and is still ongoing. Manu Sporny: Modularization (PaySwarm) Manu Sporny: Pelle has said various parts of the PaySwarm spec should be out of scope for a payment standard. Specifically, digital signatures, PKI systems, listing of assets and other commerce related things. Some have said conceptual model is overly limiting to PaySwarm. Position we've had is that if there is something in the specification that should be broken out, we would do that. Pelle said he's interested in JSON-LD and to see where that goes. Some people might not know that JSON-LD started out as a part of PaySwarm. At some point it was decided to move it out and develop it in a community as its own spec. Manu Sporny: No reason that can't happen with current spec. Reason it's all in one spec now is that it's easier editorially to edit when it's together while in development. Can split out sections when it's apparent it needs to be done. Pelle Braendgaard: One reason it's important to do that is PaySwarm API standard as-is is very hard for an outsider to come in and understand. It is incredibly complex which is why some people didn't catch parts of it. Pelle Braendgaard: Can't find where it describes how to do a simple payment. OAuth being replaced by digital signatures, assumed there was some way to do delegation with it since that what OAuth does, but there isn't. Hard to read since it's so complex. It needs to be split up. Fine with commerce model part but it doesn't belong in core payment spec. Manu Sporny: Haven't speced out simple payments since it's simple to spec out. Just an extra simple object and will spec it out. We've been working on hard problems rather than easy ones. Outline of PaySwarm authority to PaySwarm authority process is on mailing list. Still needs to be speced out but we've been working on commerce flow. Manu Sporny: The way you do delegation is out of scope. Facebook and Twitter do delegation differently. Both use OAuth but that doesn't specify what rights you are granted. We think those are out of scope and it's up to PaySwarm authority to provide. Manu Sporny: When it comes to figuring out if something can a capability of running a certain command, like a grant, OAuth and digital signatures can provide that functionality. Can discuss how that works on mailing list. One thing digital signatures are used for in PaySwarm is delegation. Pelle Braendgaard: OpenTransact is clear about what is defined. Bunch of things not defined in the spec and using new 'recipes' to show best practices and how to do things. Pelle Braendgaard: Annoyed with initial post since it lists many features OpenTransact doesn't do but at same time all the fantastic features PaySwarm supports haven't been speced out yet. Table is offensive saying PaySwarm supports features that haven't been speced out yet and OpenTransact doesn't support them. Features supported in PaySwarm are not mentioned anywhere in the spec. Conversation heated up because of that. David Nicol: "delegation" == "capability model" <--- hard to change later if not fully specified early; handwaving to PKI is erroneous IMO, I can explain in voice if reqested Pelle Braendgaard: dln please do Manu Sporny: Purpose of blog post not to annoy or meant as an attack. Purpose was to outline design of what PaySwarm allows and plans to spec out that will go in 1.0 spec or modularized version of the spec. Versus things we don't think are possible with the current design of the OpenTransact specification. Did an analysis of how these types of features could be built on top of OpenTransact and found OpenTransact doesn't spec enough or mention plans to spec enough to cover those scenarios. That's where blog post came from. Think current OpenTransact design does not allow for those use cases. Manu Sporny: Tried to be factual. Please correct me if facts are wrong so post can be changed. David Nicol: wiki would be better than mailing list for that discussion Pelle Braendgaard: I've said facts are wrong before and will now. Pelle Braendgaard: Filled with cheap attacks especially when reading closely PaySwarm doesn't support these concepts. Manu Sporny: I can explain exactly how PaySwarm supports all those features. Send email showing were factual inaccuracies and we will certainly address them. Pelle Braendgaard: Ok. Everything that says OpenTransact doesn't support it, it does with an application on top of it. Manu Sporny: No, that's not what blog post says. You can add an application on top of anything to accomplish anything. Point made in blog post is that OpenTransact spec makes no recommendation on how to implement an interoperable set of applications to accomplish those features. Need to not only say post is factual inaccurate but show how OpenTransact allows that to happen. Pelle Braendgaard: That's what we are doing with recipes section of OpenTransact. Could be a never ending thing. Need full time job to reply to all these things. Will try to add to recipes with things on mailing list. Most have been discussed over last few years on OpenTransact and agile-banking list. Will try to get that into recipes. Will do a final response but don't think it helps to do the back and forth. Manu Sporny: I disagree and have found the discussion very helpful. Only way to figure out where specs overlap or how to figure out problems is to have these discussions. It is incredibly time consuming but is a necessary part of standardization process. Manu Sporny: We need to go through and update PaySwarm so it's clear how to accomplish things in the blog post. I realize not enough info in spec now to know how to do things. Need to take things we've implemented and move them into the spec and explain how that stuff works. We'll be doing that over next weeks and months. David Nicol: Can talk about capability models, delegation, and possible reference architecture of central points of software. Pelle has pointed out on mailing list that there are several alternative currency providers who are starting to federate. Makes sense to defer publishing best practices recommendation until somebody is practicing the action. Since no one has been federating with OpenTransact until now there's an argument it's premature to spec it out. David Nicol: Do we have a reference model? I've got one but haven't completely read either spec. Mine is more of a computer programmer object model reference. Starting with capabilities and both currencies and identities descend from that. Could create delegation of giving $2M budget out of $10M budget, can create identity which represents their budget and give that budget $2M and then assign control of that identity to person who has control of that budget. Manu Sporny: We don't have such a diagram. It would be very helpful if you had such a diagram and we could map it to PaySwarm and OpenTransact and see where differences are. Would help to see what different models are. Will likely see overlap in models. David Nicol: Need to define terms so we can communicate properly. Manu Sporny: Yes, we really need terms defined. PaySwarm already defines a number of terms already in conceptual model part but a number of other terms need to be defined. Didn't think we needed to define payment but even that is leading to confusion. Anytime we see disagreement on a term we need to define it. Manu Sporny: Speaking about federation, another issue with OpenTransact is to federate or not federate. Even if OpenTransact describes federation as an application that sits on top of OpenTransact that would be helpful. Currently, we don't believe model of having a single entity running transactions on a particular asset will have much of an impact on the web. Seems like siloed payment model. We want to see how that won't happen. Manu Sporny: We want to know how PayPal or Google or other small OpenTransact provider can participate in the network. David Nicol: The key to interoperability for PayPal and Google is if they decide to be OpenTransact providers dealing with some kind of proxy to USD. Way to have interoperability is to use OpenID for secure decentralized identities. You have OpenIDs instead of different accounts with each bank. You've got a common identity string for the account holders. Manu Sporny: OpenID doesn't solve the problem: How do you figure out how much money you have in your accounts? David Nicol: That requires a centralization. The question presumes centralization. Manu Sporny: That's our issue. David Nicol: You're saying an additional parameter saying to pull funds from where I have them. Manu Sporny: That's one way. Another way is to define a decentralized protocol for exchanging money between all these transaction processors. Effectively like banks; money transmittal services under the law but effectively holding on to a certain set of funds. Want to make sure buyer and vendor can exist on different payment processors. When a transaction happens the money moves from the buyer's financial account to the vendor's account. If that account is on some other third party, whether that exists in a decentralized system across the web, we just want it to be decentralized. If it is centralized you start giving people an unfair advantage in the market. Ends up like it is today with siloed payment networks and siloed accounts. Very concerned with that and want to decentralize what OpenTransact currently has now or use PaySwarm which is designed for this. David Nicol: PaySwarm effectively models interbank check clearing without the ACH network? Manu Sporny: That's a rough way to look at it, but yes. Another way to look at it is how we do email today. People wouldn't like it if you could only send email to another person on the current system. SMTP defined a protocol to send a document from one server to another. The same thing has to happen with money on the web. We have to be able to move values around multiple accounts in a decentralized system. So basically we want a decentralized ACH system and that's what we think true interoperability is. David Nicol: With same example, when you say something is centralized or not, you can't connect to Gmail server and read mail from Yahoo account, you have to connect to the other account. Manu Sporny: You can look at it as centralized. What is centralized is the application and your email exists on a Google server. But if you wanted to send email to someone on another server the protocol defines how to send it. What we're talking about is the protocol for monetary exchange on the web. We're not talking about applications built on top of that protocol. David Nicol: re Miami: is there any movement to have Conch Republic back a currency? Pelle Braendgaard: Are large existing silos (like banks, PayPal, Google Checkout) going to be a part of a federated system? Going to need strong market forces to make that happen. We cannot make decentralization a requirement. We could have Dwolla/PayPal use OpenTransact and then use an alternative currency to exchange money. Decentralization does not have to be a part of core. Only people that care about decentralization are currency implementers. We need to experiment w/ decentralization before we standardize. OpenTransact was designed to do linked transfers from the beginning - fairly simple extension on top of OpenTransact to do so. I will document how this happens. Pelle Braendgaard: Payment proviers need business connections between each other, that's the most important thing. Manu Sporny: I don't disagree on the point of needing a legal framework for backend transfers... that needs to exist. Backhaul ACH is temporary, we eventually want banks to just use PaySwarm to transfer money, not ACH. Manu Sporny: Always needs backup of legal framework. Need to ensure money transfer properly. Manu Sporny: Speaking to your point that "we should not standardize decentralized mechanism" - I disagree completely. If we don't build in payment processor interoperability into the spec then you will end up with siloed systems because that is what you have by default. That is a very important point - we absolutely want a decentralized system. By default we want decentralization, in order for that to happen, it needs to go into the core spec. Manu Sporny: Payment processor interoperability needs to go into core spec. David Nicol: Delegation is exactly the same kind of thing to get in early; there is more at stake with it. Doing delegation wrong opens security holes. Doing interop sloppily just bakes in something awkward. Pelle Braendgaard: There are many ways to talk about interoperability. You keep saying that data portability is one way to do interoperability and that it's mandatory. There is also other types of interoperability Manu Sporny: Data portability is different from payment interoperability (for payment processors). [The first has to do with moving your accounts from one system to the next, the second has to do with moving money from one system to the next.] Pelle Braendgaard: Yes, money portability is different from data portability. I agree that we want these things, if we decide that this is the most important thing, then PayPal/Google will not implement this stuff quickly. Manu Sporny: Why do you think that they will want to implement something that allows other people to compete with them? Pelle Braendgaard: The payment business is complex. PayPal is the one that has least reason to implement decentralization/portability. Banks are open to implementing OpenTransact - not open to full decentralization via open standard in the beginning. If someone can put IBAN in to field, if they can figure it out on their systems, they might be open to do stuff like that. I'd love it if the banks implement OpenTransact, but if we make decentralization a requirement, it's given that they won't adopt it. Manu Sporny: I don't think that's true. Banks buy software from software vendors, they rarely implement it. If there is a piece of software that supports PaySwarm, they will just buy that software to meet their need. Bigger players will be intersted once there is adoption. We can't say "it's a given" for many things in this specification, this is one of them. Manu Sporny: It's important to understand who the market is for these specifications - it's not PayPal, Google Checkout, or traditional Banks. They are not going to be the early adopters, the early adopters are going to be entrepreneurs setting up their companies for the first time. If the network becomes large enough, and for that to happen, we need decentralization, if the network starts processing a huge amount of money - that's when PayPal, Google Checkout and Amazon Payments and the banks become interested. In fact, the banks would become interested before Google Checkout and Amazon Payments. It would be a mistake for us to say that there are any hard and fast rules on when these things may be adopted. I don't buy the argument that because we use digital signatures or decentralization, it automatically means that banks won't adopt the technology. Pelle Braendgaard: I agree with the general analysis, but I think it will take a long time for banks to adopt PaySwarm. They're scared to open up... which is why they like OpenTransact - it doesn't require them to open up too much. Forcing too many features into the spec will limit adoption especially if all features are mandatory. Manu Sporny: If our goal is to have a decentralized payment network, why are we not building the spec in that way? Why are we not building the network in a decentralized way? If the banks can see that a group of entrepreneurs have setup a decentralized payment network that is handling a bunch of money, it reduces their risk and they'll adopt it. Another way to look at it - use OpenTransact today, move to PaySwarm for the backhaul in the future. Again - If you are focused on the established players, you're focusing on the wrong people. This is speaking from experience - we launched the PaySwarm technology around 2004 to show the music industry how they could partner with their fans to sell music. They rejected the idea outright because they were afraid of change - large, stable companies reject ideas that could disrupt their grasp on the market. Manu Sporny: The banks have system that works for them, dectralization might scare them unless it is a competitive advantage to their business model. We should be focusing on entrepreneurs and other smaller players. There may be a few people at banks that implement the idea, but focusing on them is largely a waste of time at this point. David Nicol: There are some smaller failing banks may be looking for something to diferentiate themselves. They might be a good candidate to talk to before talking to the larger players. Pelle Braendgaard: Some groups are talking to banks about using OpenTransact. Manu Sporny: That's good, but I'm not convinced that's the right way to go. I hope OpenTransact finds success doing that, but I believe that it is very difficult to convince those large organizations to take on any sort of business risk like decentralization... and we've all stated that, ultimately, that is what we want. Manu Sporny: Decentralized systems will help move more money which can benifit bigger players like PayPal, Google Checkout, and banks. We don't want them to go out of business, we want to show them that decentralization is the right way to do this. Manu Sporny: Ok, we've talked about decentralization, Pelle do you think you have a good understanding of our concerns? Pelle Braendgaard: Yes and I feel the same concerns apply to PaySwarm. All of these things have been discussed, mapped out, and it hasn't been put into specs before. Pelle Braendgaard: OpenTransact federated extension should be done once people are doing it, as David has pointed out. David Nicol: It's not just me, it's an IETF ground rule. Pelle Braendgaard: Yup. Manu Sporny: No, it isn't. It is not an IETF ground rule. W3C doesn't operate like that, I don't think IETF does either. Read the mission statement for IETF. Look across technologies, SMTP, SIP, there was not a notion where you need a great number of people doing something in the same technological way that you are proposing to write a standard. You need people attempting to do the thing you spec the solution for, but in no way does the technical solution have to be the way that it is being done today. To provide an example, there are many people doing payment on the web, there are many people exchanging digital goods over the web, but the specification to solve that doesn't need to be based on the way that is accomplished today. The specification can propose a ground-breaking/revolutionary way to address the problem, but in no way does it have to match the current state of the art. Manu Sporny: I do not agree that you need a bunch of people using OpenTransact to do decentralized payments. What you will discover is that people that implement OpenTransact will not do decentralized payments because it is a very hard problem to solve. Instead, they will focus on the centralized solution because that is the technology that they've been given. To provide another example - Microformats and RDFa came into existence because people were publishing all sorts of data on their pages but not marking it up in any particular way. Microformats and RDFa showed people how to do decentralized data publishing that was machine-readable... but it didn't follow the state of the art, which was screen scraping, it proposed a new technical solution. Manu Sporny: The idea that you need to have people attempting to solve the problem in the same technical way that you're solving it - I don't believe that for a second. Jeff Sayre: I agree with your assertion, Manu. One of the reasons I was interested in the Web Payments group is that it is a future-looking project. There is social unrest, they're trying to figure out what the future of money will be. They're trying to figure out how we make the monetary system work for the 99% of us. I think soverign currencies may give rise to more decentralized systems, you already see alternative currencies and future of payments, future of money. All of this relies upon a decentralized solution. A social Web that is decentralized, coupled with a decentralized financial layer, is a much more socially focused and future-looking solution than any solution that attempts to dove-tail into the way things are currently done. Jeff Sayre: This is exactly why PaySwarm interested me - the future is a decentralized financial system and PaySwarm shows us how to accomplish this. Pelle Braendgaard: I think we're all agreed that we want decentralization. OpenTransact only covers payments - that's it - that's by design. It uses other ways of identifying users, there are use cases about how you do different types of exchanges in OpenTransact. Delegated payments is one such use case. Most currencies are centralized, but some of them are community currencies. Currencies want to create links to each other - but that happens at the grassroots level. I think we can have an idea about how this should be done. Delegation - that's not in PaySwarm spec - but that should be a separate document. As an app developer, I don't have to understand the complexities in the other specs, I just want to do a payment, that's what the OpenTransact spec deals with. I think we're all in agreement that decentralization is good. Manu Sporny: Yes, we all want decentralization. This is good - when we look out to the horizon, we see the same place that we want to go. Decentralized payment system - that's great. What we're disagreeing about is how we get there. This is perfectly natural for a standardization process. Every standardization process has this sort of discussion in the beginning and it's a very useful/mandatory discussion to have. Manu Sporny: This notion that OpenTransact is payment only and will have other specs on top to implement other features is concerning. We've been working on PaySwarm since 2004, first in music industry, then moved to financial industry when we failed in the music industry. We looked at a payments-only solution at first as well. We don't understand how it is going to scale into a decentralized system. When you have a broader scope, you start seeing the issues with focusing only on payments. The general concern is that when you define "payments only" you don't take into account the scalability problems because you don't have to pay anyone outside of your system. Manu Sporny: The second point you made, Pelle, was on moving away from centralized currencies to alternative currencies. Digital Bazaar thinks that it is important to deal with both centralized currencies like the US Dollar and alternative currencies, like Bernal Bucks, Ven and BitCoin. For example, how many people use OpenTransact to exchange US Dollars? US Dollars are going to be the major currency used in PaySwarm - we're launching in the US and we need to prove the concept using real money, not alternative currencies... but we need to support both. David Nicol: aside - no, it will be TJ90 Manu Sporny: Your third point was that it's difficult to figure out what to standardize because there are so many competing ways to do something. However, that's exactly why a standard exists - to say that there is one single way to do something and interoperate. You do that so people don't have to implement it in a bunch of different ways. For example, if there were a Web payments standard, merchants wouldn't have to support Visa, Mastercard, Diner's Club, Google Checkout, Amazon Payments, and PayPal, they'd just support the online Web payments standard. That is not to say that it will happen overnight, but eventually, people move over to the standardized way of doing things. You standardize exactly because there are a hundred ways to do one thing - you don't wait for a solution to pop into existence. There are at least two reasons why you start standardizing - there are too many options, or no option exists. Jeff Sayre: Yes, that's right. The standards process is showing people an alternate way or a new vision of how things can be. We identify the problem, we outline the opportunities and we connect those two with the standard. We need to be currency agnostic, but we do have to take the soverign currency into account. We need to lead people in a direction that we feel takes the current problems into account and promotes a solution. It doesn't have to be /the/ solution, but we need to put a stake in the ground while being forward-looking enough to understand where all of this is going. Manu Sporny: Ok, we're at the end of the call - let's take this discussion and turn it into a couple of action points. It has become apparent as a part of this discussion that Digital Bazaar has done poor job of documenting PaySwarm features in the spec - we will correct that. Pelle Braendgaard: I'm also going to be adding more text to our recipes to show how to accomplish things with OpenTransact. Here is an example on crowdfunding: http://www.opentransact.org/recipes/crowdfunding.html Manu Sporny: We're going to have a new demo out soon, we will try to build examples on top of that work. We'll do more documentation. We'll have implementations and demos of the technology working with the specification. Pelle, you're going to add recipes? Pelle Braendgaard: OpenTransact is using it's 'recipes' site to show examples. Recipe for escrow/reserves: Pelle Braendgaard: http://www.opentransact.org/recipes/reserves.html David Nicol: http://xmlns.com/foaf/spec/#term_tipjar one way to state how one receives payments Pelle Braendgaard: will set up a federated example as well Manu Sporny: Ok, thanks for the great discussion today - this was incredibly helpful. Good to know that we all have the same goal in mind - there will be churn while we try to figure out how we get to where we want to go. Have a great weekend, we'll chat soon. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: Web Payments - PaySwarm vs. OpenTransact Shootout http://manu.sporny.org/2011/web-payments-comparison/
Received on Friday, 13 January 2012 21:47:10 UTC