Web Payments Telecon Minutes for 2012-01-13
Manu Sporny
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/
David Nicol
4.1.3 Internet Standard A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (which may simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community.
Manu Sporny
On 01/13/12 18:23, David Nicol wrote:
> On Fri, Jan 13, 2012:
>> 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.
>
> characterized by a high degree of technical maturity and by a
> generally held belief that the specified protocol or service
> provides significant benefit to the Internet community.
>
> I was talking about standards-track RFCs, not any other track with a
> lower bar.
Yes, as was I. Pelle had said that he doesn't believe that standardizing
payment decentralization right now should be done because you don't have
implementation experience for OpenTransact in a decentralized network.
My point was that you probably won't get implementation experience for
OpenTransact in a decentralized network unless you spec something that
people can implement.
Waiting for the decentralization solution to evolve out of the current
OpenTransact specification is not a good strategy. This is exactly why
we didn't wait for that to happen with PaySwarm... you have to propose
something for people to implement it in an interoperable fashion. That
is the type of "significant implementation and successful operation
experience" that the IETF is talking about.
Here is the entire transcript of the conversation you quoted, I make
these points (and more) in there as well:
http://payswarm.com/minutes/2012-01-13/#topic-7