You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<divclass="comment"><spanclass="name">Manu Sporny</span>: Discussion has moved onto mailing lists, has fragmented into various topics, and is still ongoing.</div>
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
104
104
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
105
105
<divclass="comment"><spanclass="name">Pelle Braendgaard</span>: 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.</div>
106
106
<divclass="comment"><spanclass="name">Pelle Braendgaard</span>: 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.</div>
107
107
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
108
108
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
109
109
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
<divclass="comment"><spanclass="name">Pelle Braendgaard</span>: 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.</div>
111
112
<divclass="comment"><spanclass="name">Pelle Braendgaard</span>: 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.</div>
112
113
<divclass="comment"><spanclass="name">David Nicol</span>: "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</div>
<divclass="comment"><spanclass="name">Pelle Braendgaard</span>: 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.</div>
123
124
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
124
125
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
126
+
<h1id=topic-4class="topic">Topic: The Conceptual Model and Definitions</h1>
125
127
<divclass="comment"><spanclass="name">David Nicol</span>: 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.</div>
126
128
<divclass="comment"><spanclass="name">David Nicol</span>: 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.</div>
127
129
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
128
130
<divclass="comment"><spanclass="name">David Nicol</span>: Need to define terms so we can communicate properly.</div>
129
131
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
131
134
<divclass="comment"><spanclass="name">Manu Sporny</span>: We want to know how PayPal or Google or other small OpenTransact provider can participate in the network.</div>
132
135
<divclass="comment"><spanclass="name">David Nicol</span>: 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.</div>
<divclass="comment"><spanclass="name">David Nicol</span>: 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.</div>
150
153
<divclass="comment"><spanclass="name">Pelle Braendgaard</span>: 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</div>
151
154
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.]</div>
155
+
<h1id=topic-6class="topic">Topic: Target Market and Implementation</h1>
152
156
<divclass="comment"><spanclass="name">Pelle Braendgaard</span>: 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.</div>
153
157
<divclass="comment"><spanclass="name">Manu Sporny</span>: Why do you think that they will want to implement something that allows other people to compete with them?</div>
154
158
<divclass="comment"><spanclass="name">Pelle Braendgaard</span>: 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.</div>
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
164
168
<divclass="comment"><spanclass="name">Manu Sporny</span>: Ok, we've talked about decentralization, Pelle do you think you have a good understanding of our concerns?</div>
165
169
<divclass="comment"><spanclass="name">Pelle Braendgaard</span>: 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. </div>
170
+
<h1id=topic-7class="topic">Topic: Premature Standardization of Decentralization</h1>
166
171
<divclass="comment"><spanclass="name">Pelle Braendgaard</span>: OpenTransact federated extension should be done once people are doing it, as David has pointed out.</div>
167
172
<divclass="comment"><spanclass="name">David Nicol</span>: It's not just me, it's an IETF ground rule.</div>
<divclass="comment"><spanclass="name">David Nicol</span>: aside - no, it will be TJ90</div>
179
184
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
180
185
<divclass="comment"><spanclass="name">Jeff Sayre</span>: 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.</div>
186
+
<h1id=topic-8class="topic">Topic: The Path Forward</h1>
181
187
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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.</div>
182
188
<divclass="comment"><spanclass="name">Pelle Braendgaard</span>: 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: <ahref="http://www.opentransact.org/recipes/crowdfunding.html">http://www.opentransact.org/recipes/crowdfunding.html</a></div>
183
189
<divclass="comment"><spanclass="name">Manu Sporny</span>: 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?</div>
0 commit comments