Re: The difference between PaySwarm and OpenTransact
Pelle Braendgaard
My reading on the main difference between PaySwarm and OpenTransact, based on the current discussion, is this:
OpenTransact is about telling payment providers how they can communicate with their own customers and how they can let their customers delegate access to their account.
PaySwarm is about telling payment providers how they can facilitate commerce between their customers and the customers of other payment providers.
I think the latter is more about an open standard for payments and online commerce than the former.
--
Dave Longley
CTO
Digital Bazaar, Inc.
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking
Pelle Braendgaard
On 01/12/2012 02:38 PM, Pelle Braendgaard wrote:Dave,No where does it mention that OpenTransact is for individual payment providers.
To my knowledge, OpenTransact doesn't work across different payment providers -- and you seem to have said so yourself. That interoperability isn't there. Instead, it defines a standard API for working within a single payment provider. You might only have to write a tool to work with a payment provider once -- such that you can then switch it to any other payment provider that also implements the same API, but you can't communicate or initiate commerce across those two payment providers. You need a separate account with each provider.
PaySwarm, by contrast, makes online payment and commerce largely payment provider agnostic. A merchant doesn't have to list all of the payment platforms that they have an account with and then require their customers to go sign up with them in order for commerce to occur. OpenTransact makes no effort to change this current problem; it is out of scope. Similarly, it is out of scope in PaySwarm to tell a particular payment provider what API that they have to use or what authentication method they have to do other than what's necessary to facilitate commerce.
OpenTransact seems to want to be a general account delegation method, where a specific API (what to POST/GET from various URLs) must be implemented for the specific functions of financial delegation. This "encompasses only one way of doing things". Though, that's part of what a standard is about -- you provide only one way of doing things so that everyone knows what to expect.
PaySwarm doesn't tell payment providers what their API must be for delegating general access to their customer's accounts. It spec's out only the delegation that is required for online payments and commerce is standardized (based on digital signatures). In fact, for more general access, you could use OpenTransact -- or any other technology. You could also simply use Oauth2 and invent your own API should you find that OpenTransact is insufficient. I'm sure that many payment providers will have more Oauth2 functionality that they'd like to expose on top of OpenTransact. This also means that many payment providers will provide their own API access tools anyway, so the people writing tools to access various payment providers will only need to link to the library for that payment provider. In other words, most of their tool (what makes it unique) will be write-once anyway. However, if all the payment providers out there used OpenTransact, there would only be one library that had to be linked to their specific (extra-functionality) library, so there is some benefit there.
It is about creating a lively open ecosystem of payment providers, merchants, marketplaces and other kinds of apps.
I disagree. It is not about an open ecosystem, but rather a closed one where everyone has to get an account with each payment provider -- or they can't do business with each other. Instead, my reading is that OpenTransact is about making it easier for people to write tools that link to the same library; or for payment providers to cut down on development time when providing their own libraries. I'm having a hard time seeing it as more than an API standard because of its interoperability issue and its silence on the payment silo issue that exists today.
The basic building block is a transfer. That transfer could encompass one or more transfers with business logic behind the scenes.
Sure, but what I'm hearing is that someone else will have to build a standard on top of OpenTransact in order to make online commerce truly open and interoperable. At the same time, they'll have to do so with any inefficiencies that come from a standard that isn't forward looking (enough, IMO). There seem to be significant scalability (at least much is non-optimal) and atomicity issues with using OpenTransact, eg: to send payments to multiple people for the same asset. Without considering how applications may want to leverage OpenTransact to engage in more than just "the basic building block", there are a lot of open questions as to whether or not "the basic building block" is performant enough. A MySQL database stores data just fine for the most basic application. However, trying to get it to scale is a much more complex process. It is a good idea to think forward sometimes, especially when the use cases are out there -- and have been out there for many years (MySQL didn't have this advantage).
Another example of a potential issue with OpenTransact is exactly what we ran into when designing PaySwarm. You have said that digital signatures are a good idea and you'd like them to be built into OpenTransact in the future as an extension. However, if that's true, all of the same challenges that PaySwarm has solved will come up in that process. In fact, you may learn the same lessons and decide that Oauth2 duplicates the necessary delegation functionality required to facilitate commerce. Then you'd be stuck with a system with two methods of delegation that *must* be implemented in order to be compliant, instead of just one.
The biggest problem with PaySwarm is that it really encompasses only one way of doing things. Yes it's extendable but the specs makes many assumptions that limits it.
PaySwarm only "encompasses one way of doing things" for what it is that it standardizes. PaySwarm enables interoperability between payment providers and facilitates online payment and commerce. It only standardizes what needs to be delegated in order for this to happen and gets out of your way for everything else. That is not a limitation, rather just the opposite. What PaySwarm does limit is only what it standardizes, which solves the challenges that anyone who wants to engage in open online commerce would otherwise need to solve themselves. I think it does so rather minimally, without being so basic that it ignores what I think are very important and long standing use cases for online commerce.
I would really like to see a joint set of standards bringing along the best of both worlds and that is what I had originally hoped the web payments group was about. My big complaint that started this debate was a seeming lack of will to do this from the PaySwarm team.
I don't think there's a lack of will to work together at all, I just think that there's currently a misunderstanding of what the two standards do and where their strengths and weaknesses are. But that's what this conversation is about.
David I. Lehn
<pe...@stakeventures.com> wrote:
> On Thu, Jan 12, 2012 at 3:26 PM, Dave Longley <dlon...@digitalbazaar.com>
> wrote:
>> PaySwarm only "encompasses one way of doing things" for what it is that it
>> standardizes. PaySwarm enables interoperability between payment providers
>> and facilitates online payment and commerce. It only standardizes what needs
>> to be delegated in order for this to happen and gets out of your way for
>> everything else. That is not a limitation, rather just the opposite. What
>> PaySwarm does limit is only what it standardizes, which solves the
>> challenges that anyone who wants to engage in open online commerce would
>> otherwise need to solve themselves. I think it does so rather minimally,
>> without being so basic that it ignores what I think are very important and
>> long standing use cases for online commerce.
>
>
> I beg to differ. It's SOAP vs Rest
>
Could you please explain what you mean with that comparison? I think
you used that before and I didn't quite understand what you were
getting at. Both standards seem to be using RESTish ideas. Thanks.
-dave
David Nicol
<pe...@stakeventures.com> wrote:
> So it is not a centralized protocol and never was. It is just for each
> unique asset there is a central transaction processor.
and here we're talking past e/o about what "centralized" means. E-mail
is a great example of something that is in the large decentralized but
in the small centralized. the w3.org listserv is the central point for
posting to the lists there, so it might be entirely correct to say
"w3.org mailing lists are centralized."
There could be 1000s
> of different USD payment providers each one providing a USD based asset.
> These could talk to each other as has been discussed in other threads.
And there are, and they do! (just not using the internet. Well, maybe
until recently. I have no idea if ACH uses the internet or not, except
of course through intermediary liaisons.)
> OpenTransact protocol. They are certainly not out of scope of our
> discussion. But we can not standardize something yet when there are 100s of
> different ways of transporting the money.
Drawing a scope line for the discussion might be in order. Having
introduced the "liaison" concept and term, I'd like to propose that
the discussion be limited to automated book-entry accounting systems.
That makes "and then you have to drive your Ford over there and pick
up the gold bars" off-topic. Also, cryptographic bearer instruments
become off-topic, except as a supportable use case: some entity
willing to take on the risk of their bearer protocol getting cracked
may liaise an asset.
> I would argue just by virtue of our focus on delegation, OpenTransact is
> considerably more open, secure and interoperable than a system where you
> have to share your private key.
what? someone proposed a PKI system involving sharing of private keys?
Has anyone told http://en.wikipedia.org/wiki/Phil_Zimmermann so he can
laugh?
>> I disagree. It is not about an open ecosystem, but rather a closed one
>> where everyone has to get an account with each payment provider -- or they
>> can't do business with each other.
the use of openID for identity on OT means your account has the same
identity at all participating locations. Presuming of course that
particpating locations autovivify account records on validation of
openIDs. They do, right?
> As I explained above this is a huge misunderstanding and probably my fault
> for not explaining it correctly. This is not about Silos. It's about opening
> up silos and creating commerce and finance networks on the web.
But... where's the business model? With a silo, you can sell access to it.
> Bulk payment is an obvious important scaling issue we have not dealt with. A
> bulk extension on top of or included in OpenTransact Core, but using the
> exact same semantics is absolutely a good idea and does not conflict at all
> with the basic concepts or semantics of OpenTransact.
setting up an identity that periodically disburses its entire
aggregated receivable to a list based on some ratio, is entirely
tractable with donor-gives-recipient-amount-of-currency semantics.
There's no reason to complicate things at the protocol level (since
network bandwidth is no longer expensive), and various reasons against
it (hard to get right, for instance, as in DJB's justifications for
why EZMLM doesn't aggregate deliveries to multiple recipients at the
same domain http://cr.yp.to/ezmlm.html )
>
> I beg to differ. It's SOAP vs Rest
>
I didn't get that either.
> Hopefully in tomorrows call we can be more civil and and talk openly about
> what we can do to work together on this.
I intend to attempt to attend the teleconference tomorrow; I will try
to stay out of the way.
Manu Sporny
> On Thu, Jan 12, 2012 at 3:26 PM, Dave Longley
> wrote:
>
> On 01/12/2012 02:38 PM, Pelle Braendgaard wrote:
>> Dave, No where does it mention that OpenTransact is for individual
>> payment providers.
>
> To my knowledge, OpenTransact doesn't work across different payment
> providers -- and you seem to have said so yourself. That
> interoperability isn't there. Instead, it defines a standard API for
> working within a single payment provider. You might only have to
> write a tool to work with a payment provider once -- such that you
> can then switch it to any other payment provider that also
> implements the same API, but you can't communicate or initiate
> commerce across those two payment providers. You need a separate
> account with each provider.
>
> OpenTransact definitely works across different payment providers.
Please demonstrate this assertion. Show us how OpenTransact works across
payment providers. Is this functionality in the spec already, or will it
be in the core spec before it hits 1.0? You have asserted previously
that it would not be in the spec and that it is out of scope.
Below, I am going to demonstrate exactly how OpenTransact does not work
across different payment providers and thus does not meet the
interoperability criteria that has been outlined. That is, if I have
this OpenTransact payment URL:
GET
/usd?to=bi...@example.com&amount=100.00¬e=Milk&redirect_uri=http://site.example.com/callback
The OpenTransact specification says:
"When a user follows this link, the Asset Service should present the
user with a form authorizing the payment."
Now, assume that the user doesn't have an account on the Asset
Service... how do they pay bi...@example.com? What if bi...@example.com
doesn't have an account on the Asset Service? Even if it is out of
scope, please explain how money gets from the sender's bank account to
the receivers bank account.
That is, if we have these two OpenTransact asset services:
AssetServiceAlpha
AssetServiceBeta
and these two accounts:
AlphaPerson
BetaPerson
where AssetServiceAlpha contains AlphaPerson and AssetServiceBeta
contains BetaPerson. How does AlphaPerson send money to BetaPerson
without having to create an account on AssetServiceBeta? That is the
decentralized payment problem.
To come at this from another direction - let's look at the SMTP
protocol. Assume that there are two e-mail systems:
EmailServiceAlpha.com
EmailServiceBeta.com
and these two accounts:
al...@EmailServiceAlpha.com
be...@EmailServiceBeta.com
where EmailServiceAlpha.com hosts the e-mail account for
al...@EmailServiceAlpha.com and EmailServiceBeta.com hosts the e-mail
account for be...@EmailServiceBeta.com. How does
al...@EmailServiceAlpha.com send an e-mail to be...@EmailServiceBeta.com?
This is the decentralized mail problem and was solved via the SMTP
protocol, which is a specification published by the IETF. So, the answer
to this question is here:
http://tools.ietf.org/html/rfc5321#section-3.6
If you can provide an answer like that, then OpenTransact is
interoperable with other OpenTransact systems. If no such document
exists, OpenTransact is not interoperable with other OpenTransact systems.
> What I seem to have a hard time explaining is the key to
> OpenTransact is the Asset url. Each asset has one single url. However
> it can work just fine across multiple providers.
I'm trying to understand how. So far, there has been no explanation of
how this works, and no indication that such an explanation will go into
the OpenTransact 1.0 specification.
> So it is not a centralized protocol and never was. It is just for
> each unique asset there is a central transaction processor. There
> could be 1000s of different USD payment providers each one providing
> a USD based asset. These could talk to each other as has been
> discussed in other threads.
How?
> I believe that integrating with the new OpenID Connect spec solves
> most if not all the account interoperability issues. So if it is
> already being done there why do we need to include it in
> OpenTransact?
How does OpenID Connect solve the problem of crediting and debiting
financial accounts to transfer money between those accounts when the
accounts reside on different systems?
> First of all besides having a destination IRI how have you solved
> the real issues of interoperability? PaySwarm acts as it's magic. By
> adding a destination IRI the funds just magically appear on the
> other side. I have not been able to find anywhere in the spec where
> this is solved.
We have not had the time to write the complete spec text and put it into
the PaySwarm specification yet. This is how it works, though:
Assume the following setup:
PaySwarmAuthorityAlpha containing FinancialAccountAlpha
PaySwarmAuthorityBeta containing FinancialAccountBeta
A person that owns FinancialAccountAlpha executes a Transaction that
lists FinancialAccountBeta as a Payee. The (very rough) algorithm is:
1. PaySwarmAuthorityAlpha contracts PaySwarmAuthorityBeta and retrieves
its service endpoints, one of which is the transaction-backhaul
service.
2. PaySwarmAuthorityAlpha starts to process the Transaction.
3. PaySwarmAuthorityAlpha places funds from FinancialAccountAlpha
in escrow noting that they're going to FinancialAccountBeta.
4. PaySwarmAuthorityAlpha transmits the Transaction to the
PaySwarmAuthorityBeta's transaction-backhaul Web Service.
5. PaySwarmAuthorityBeta notes the incoming amount in an escrow
account for FinancialAccountBeta with the correct
amount of incoming funds.
6. PaySwarmAuthorityAlpha is notified that the funds are in escrow
on the receiving side.
7. PaySwarmAuthorityAlpha notifies PaySwarmAuthorityBeta that all escrow
has been processed and to move the funds from escrow into the
appropriate account. This two-stage commit process ensures that
in the event of a failure while contacting multiple PaySwarm
Authorities, that transactions can be backed out.
8. PaySwarmAuthorityAlpha moves the money out of escrow and notes that
it must perform an ACH transaction to PaySwarmAuthorityBeta for the
Transaction under a set of pre-agreed-upon legal terms.
Things that are out of scope: All legal agreements that ensure that
PaySwarmAuthorityAlpha transfer money to PaySwarmAuthorityBeta in an
expeditious fashion. The mechanism for performing the inter-bank transfer.
What is in-scope is how the two systems message that money has moved
between them. This algorithm /will/ be in the PaySwarm specification
before 1.0. If OpenTransact had an algorithm like this, it would be well
on its way to being interoperable.
> I would argue just by virtue of our focus on delegation,
> OpenTransact is considerably more open, secure and interoperable than
> a system where you have to share your private key.
You /never/ have to share your private key in PaySwarm. Please point out
exactly where and when you have to do this.
> PaySwarm doesn't tell payment providers what their API must be for
> delegating general access to their customer's accounts.
>
> By leaving that out of the specification you are eliminating at
> least the following use cases, which all rely on mobile devices:
>
> http://payswarm.com/specs/source/use-cases/#mobile-computing-based-purchase
> http://payswarm.com/specs/source/use-cases/#point-of-sale-device
> http://payswarm.com/specs/source/use-cases/#automated-vending
You are misunderstanding what Dave Longley was saying. He is saying that
"how a service asks a person what they want to allow a particular
grantee to perform on their behalf is out of scope." It is out of scope
for OAuth and it is out of scope for Digital Signatures.
With OAuth a service can ask their customer: "Do you want to allow
'MegaGames' to charge you up to $5 per month?". That authorization is
stored in the form of an OAuth token that can then be used by MegaGames
to charge you up to $5 per month. How service providers ask this
question and keep track of the grant is out of scope. Twitter does it
one way, Flickr does it another, and Facebook does it in yet another way.
With Digital Signatures a service "Do you want to allow 'MegaGames' to
charge you up to $5 per month?". That authorization is stored in the
form of a grant. Basically, if the request is digitally signed by
MegaGames, they're allowed to charge you up to $5 per month. How service
providers ask this question and keep track of the grant is out of scope.
So, as you can see - we're not leaving this feature out of the
specification. Digital Signatures provide this functionality and OAuth
becomes unnecessary, especially because Digital Signatures are used for
a number of other things in PaySwarm (encryption, digitally verifiable
receipts, tamper-proof assets, tamper-proof listings, tamper-proof
licenses, etc.)
> I agree there is a misunderstanding. I feel I have done more than my
> part both on the lists and on the conference calls to try and steer
> things into somewhere we can work together. I think Manu's borderline
> offensively comparison table
> http://manu.sporny.org/2011/web-payments-comparison/ really did
> nothing to help the conversation.
I went out of my way to try and make that blog post as factual and
level-headed as possible. To date, nobody has asserted that the blog
post is not factual. If there are factual discrepancies, please do point
them out and I will change them immediately.
> Hopefully in tomorrows call we can be more civil and and talk openly
> about what we can do to work together on this.
I feel that I have kept a civil tone throughout this entire process,
raising technical concerns and issues and sticking to facts and provable
assertions. If I have not, please understand that coming across as
anything other than civil and respectful certainly was not intentional
and I wholeheartedly apologize if anything to the contrary seems to have
occurred.
I am merely trying to raise a number of technical issues and concerns
with OpenTransact. I am trying to help.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/
Pelle Braendgaard
Pelle Braendgaard
On 01/12/2012 05:44 PM, Pelle Braendgaard wrote:
On Thu, Jan 12, 2012 at 3:26 PM, Dave Longley
wrote:
On 01/12/2012 02:38 PM, Pelle Braendgaard wrote:
Dave, No where does it mention that OpenTransact is for individual
payment providers.
To my knowledge, OpenTransact doesn't work across different payment
providers -- and you seem to have said so yourself. That
interoperability isn't there. Instead, it defines a standard API for
working within a single payment provider. You might only have to
write a tool to work with a payment provider once -- such that you
can then switch it to any other payment provider that also
implements the same API, but you can't communicate or initiate
commerce across those two payment providers. You need a separate
account with each provider.
OpenTransact definitely works across different payment providers.
Please demonstrate this assertion. Show us how OpenTransact works across
payment providers. Is this functionality in the spec already, or will it
be in the core spec before it hits 1.0? You have asserted previously
that it would not be in the spec and that it is out of scope.
Below, I am going to demonstrate exactly how OpenTransact does not work
across different payment providers and thus does not meet the
interoperability criteria that has been outlined. That is, if I have
this OpenTransact payment URL:
GET /usd?to=bi...@example.com&amount=100.00¬e=Milk&redirect_uri=http://site.example.com/callback
The OpenTransact specification says:
"When a user follows this link, the Asset Service should present the
user with a form authorizing the payment."
Now, assume that the user doesn't have an account on the Asset
Service... how do they pay bi...@example.com? What if bi...@example.com
doesn't have an account on the Asset Service? Even if it is out of
scope, please explain how money gets from the sender's bank account to
the receivers bank account.
That is, if we have these two OpenTransact asset services:
AssetServiceAlpha
AssetServiceBeta
and these two accounts:
AlphaPerson
BetaPerson
where AssetServiceAlpha contains AlphaPerson and AssetServiceBeta
contains BetaPerson. How does AlphaPerson send money to BetaPerson
without having to create an account on AssetServiceBeta? That is the
decentralized payment problem.
To come at this from another direction - let's look at the SMTP
protocol. Assume that there are two e-mail systems:
EmailServiceAlpha.com
EmailServiceBeta.com
and these two accounts:
al...@EmailServiceAlpha.com
be...@EmailServiceBeta.com
where EmailServiceAlpha.com hosts the e-mail account for
al...@EmailServiceAlpha.com and EmailServiceBeta.com hosts the e-mail
account for be...@EmailServiceBeta.com. How does
al...@EmailServiceAlpha.com send an e-mail to be...@EmailServiceBeta.com?
This is the decentralized mail problem and was solved via the SMTP
protocol, which is a specification published by the IETF. So, the answer
to this question is here:
http://tools.ietf.org/html/rfc5321#section-3.6
If you can provide an answer like that, then OpenTransact is
interoperable with other OpenTransact systems. If no such document
exists, OpenTransact is not interoperable with other OpenTransact systems.
What I seem to have a hard time explaining is the key to
OpenTransact is the Asset url. Each asset has one single url. However
it can work just fine across multiple providers.
I'm trying to understand how. So far, there has been no explanation of
how this works, and no indication that such an explanation will go into
the OpenTransact 1.0 specification.
So it is not a centralized protocol and never was. It is just for
each unique asset there is a central transaction processor. There
could be 1000s of different USD payment providers each one providing
a USD based asset. These could talk to each other as has been
discussed in other threads.
How?
I believe that integrating with the new OpenID Connect spec solves
most if not all the account interoperability issues. So if it is
already being done there why do we need to include it in
OpenTransact?
How does OpenID Connect solve the problem of crediting and debiting
financial accounts to transfer money between those accounts when the
accounts reside on different systems?
First of all besides having a destination IRI how have you solved
the real issues of interoperability? PaySwarm acts as it's magic. By
adding a destination IRI the funds just magically appear on the
other side. I have not been able to find anywhere in the spec where
this is solved.
We have not had the time to write the complete spec text and put it into
the PaySwarm specification yet. This is how it works, though:
Things that are out of scope: All legal agreements that ensure that
PaySwarmAuthorityAlpha transfer money to PaySwarmAuthorityBeta in an
bliexpeditious fashion. The mechanism for performing the inter-bank transfer.
What is in-scope is how the two systems message that money has moved
between them. This algorithm /will/ be in the PaySwarm specification
before 1.0. If OpenTransact had an algorithm like this, it would be well
on its way to being interoperable.
I would argue just by virtue of our focus on delegation,
OpenTransact is considerably more open, secure and interoperable than
a system where you have to share your private key.
You /never/ have to share your private key in PaySwarm. Please point out
exactly where and when you have to do this.
PaySwarm doesn't tell payment providers what their API must be for> http://payswarm.com/specs/source/use-cases/#point-of-sale-device
delegating general access to their customer's accounts.
By leaving that out of the specification you are eliminating at
least the following use cases, which all rely on mobile devices:
http://payswarm.com/specs/source/use-cases/#mobile-computing-based-purchase
http://payswarm.com/specs/source/use-cases/#automated-vending
You are misunderstanding what Dave Longley was saying. He is saying that
"how a service asks a person what they want to allow a particular
grantee to perform on their behalf is out of scope." It is out of scope
for OAuth and it is out of scope for Digital Signatures.
Manu Sporny
On 01/13/12 11:43, Pelle Braendgaard wrote:
> SOAP and it's associated standards often known as WS-* created a
> very complicated standard on top of HTTP.
>
> It was filled with complex concepts, vocabularies etc and attempted
> to reinvent everything to fit into it's large model about how the
> world should be.
Yes, we think SOAP was an awful, awful set of specifications as well.
So, full agreement here, we've failed if we end up with something like SOAP.
Keep in mind that SOAP and REST are two very different things. I think
comparing SOAP to REST is comparing apples to oranges. SOAP is a set of
specifications, REST is a design paradigm. I think the point you're
trying to make, Pelle, is that you believe that the designs are
"exceedingly complex" vs. "very simple".
> Rest on the other hand is web native and simple. It's about resources
> and actions you perform on it.
REST is a design paradigm that PaySwarm takes to heart, we even say so
directly in the spec (and have for as long as I can remember as it was
one of the first principles we used to design PaySwarm):
http://payswarm.com/specs/ED/web-api/2011-09-20/#representational-state-transfer
> OpenTransact uses the concept of Assets as the resources. Payment
> itself is a simple restful action on an asset.
The same is true for PaySwarm, in most cases this is the asset:
http://example.com/transactions
and to create a new transaction, you POST a PaySwarm Transaction object
to that URL above. So, I don't understand where we're violating REST
here. That's not to say that we're perfect... there may be places in the
specification that violate REST and in almost every case, that would be
a mistake that we'd have to fix.
> PaySwarm like SOAP builds a complex world view and eco system that
> requires reinventing TLS, OAuth (but not really as you said
> yourself) and creates a heavy conceptual model for developers and
> consumers a like to deal with.
Where do we re-invent TLS? I disagree that we do, in fact, we say that
TLS is required in certain instances and that it should be used if the
vendor wants to protect themselves from MiTM attacks (even though we
go to great length to ensure that a MiTM attack doesn't result in a
compromised system in PaySwarm):
http://payswarm.com/specs/ED/web-api/2012-01-16/#the-response-token
As far as re-implementing OAuth, we've explained why we use Digital
Signatures instead of OAuth here:
http://lists.w3.org/Archives/Public/public-webpayments/2012Jan/0011.html
It's the same reason that people that use OAuth use it instead of Basic
authentication:
http://en.wikipedia.org/wiki/Basic_access_authentication
That is Basic didn't fit their needs. OAuth didn't fit PaySwarm's needs.
Further, you asked these questions wrt a PKI in an earlier thread:
> - Who does the key belong to?
That is noted in the owner field:
http://payswarm.com/vocabs/payswarm#owner
We'll probably end up placing this into a separate spec on how all this
PKI stuff works... we're waiting on the WebID folks to push out more of
their spec before going into further detail. It may be that they end up
publishing a useful vocabulary and process for doing this. If they
don't, we will.
> - How can we revoke it?
You add a property to it called "sec:revocationDate".
> - How do we auto expire it?
You add a property to it called "sec:expirationDate".
> - When we create a new cert are our old receipts still valid?
You don't need certs for PaySwarm, you just need digital signatures. If
your question then is "When we create a new key or revoke an old key,
are our old receipts still valid?", then the answer is - of course.
> - I lost the private key what do I do
Revoke it by adding "sec:revocationDate" at the time at which you lost it.
Keep in mind that it's up to the PaySwarm Authorities to come up with
the UIs for adding/revoking keys, but in many cases, it's just a few
clicks. For example, creating and registering a key via the
PaySwarm WordPress plugin is as simple as putting in the domain name you
want to register with (such as google.com), clicking "Register" and then
clicking the financial account that you want to associate with the key.
This is detailed in the specification, here:
http://payswarm.com/specs/ED/web-api/2011-12-14/#the-registration-process
-- 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/
Manu Sporny
On 01/13/12 12:02, Pelle Braendgaard wrote:
>> Please demonstrate this assertion. Show us how OpenTransact works
>> across payment providers. Is this functionality in the spec
>> already, or will it be in the core spec before it hits 1.0? You
>> have asserted previously that it would not be in the spec and that
>> it is out of scope.
>
> It is out of scope of the core specification and there will be a
> recipe soon. How it could be done has already been answered several
> times over the last couple of days.
Could you provide a link, please? I don't see where the technical
specifics of how decentralized payments work in OpenTransact were
covered, either on the OpenTransact mailing list or the Web Payments
mailing list.
>> Now, assume that the user doesn't have an account on the Asset
>> Service... how do they pay bi...@example.com
>> <mailto:bi...@example.com>? What if bi...@example.com
>> <mailto:bi...@example.com> doesn't have an account on the Asset
>> Service? Even if it is out of scope, please explain how money gets
>> from the sender's bank account to the receivers bank account.
>
> This has already been answered several times. There are many
> different ways of doing settlement see previous posts.
I'm not talking about "how does the physical money move" :), I'm talking
about how each of these OpenTransact servers keep their electronic books
in order in a decentralized system. I'm looking for some spec text that
looks like this (as demonstrated in the PaySwarm specification):
http://payswarm.com/specs/ED/web-api/2012-01-16/#the-decentralized-settlement-process
>> where AssetServiceAlpha contains AlphaPerson and AssetServiceBeta
>> contains BetaPerson. How does AlphaPerson send money to BetaPerson
>> without having to create an account on AssetServiceBeta? That is
>> the decentralized payment problem.
>
> How they do is that they specify a uri or email address in the to
> field. The recipient service can use a discovery service such as web
> finger or those proposed in OpenID Connect.
There are many different ways that /could/ work :), I'm looking for the
exact algorithm you are proposing for OpenTransact. However, if I
understand you correctly, even if there were such an algorithm, it
wouldn't go in the core OpenTransact specification? If that is true,
then how do the systems interoperate?
> Business relationships and clearing as mentioned many times before
> can be done in many different ways and does not need to be in the
> core spec.
I agree, but that is not the question I am asking. I am asking about the
technical specifics of how two OpenTransact systems communicate to note
that money has moved from one system to the other. Without that, the
systems are not interoperable (at least, not in the way that matters for
a transaction processing network).
>> This is the decentralized mail problem and was solved via the SMTP
>> protocol, which is a specification published by the IETF. So, the
>> answer to this question is here:
>>
>> http://tools.ietf.org/html/__rfc5321#section-3.6
>> <http://tools.ietf.org/html/rfc5321#section-3.6>
>
> Sending an ascii message is very different than sending funds. You
> need an underlying clearing system either distributed as mentioned in
> many previous posts or centralized.
Sending an ASCII message is exactly what the Automated Clearing House
system does to transmit funds for every banking system in the US and
many other banks around the world! I've written software to do this,
here is the message format:
http://www.bankrcb.net/ACHOrig/achfileg.shtm
> Just by specifying a IRI does not magically route funds.
No, but nobody is claiming that it does. :) We had always planned on
specing the decentralized settlement algorithm into the PaySwarm 1.0
spec and as of this past weekend, it's spec'd:
http://payswarm.com/specs/ED/web-api/2012-01-16/#the-decentralized-settlement-process
>> If you can provide an answer like that, then OpenTransact is
>> interoperable with other OpenTransact systems. If no such document
>> exists, OpenTransact is not interoperable with other OpenTransact
>> systems.
>
> You haven't even been able to do this for PaySwarm, so please hold
> off on the intensity here.
We had worked out the details long ago but hadn't put it in the spec
yet. We've corrected that error and you can now find the spec text here:
http://payswarm.com/specs/ED/web-api/2012-01-16/#the-decentralized-settlement-process
>>> I believe that integrating with the new OpenID Connect spec
>>> solves most if not all the account interoperability issues. So
>>> if it is already being done there why do we need to include it in
>>> OpenTransact?
>>
>> How does OpenID Connect solve the problem of crediting and
>> debiting financial accounts to transfer money between those
>> accounts when the accounts reside on different systems?
>
> It does not solve that issue. It solves the issue of identifying
> users and finding out who their preferred payment providers are.
Yes, but how do the books get updated from one payment provider to the
other? What is the algorithm?
> Only business relationships solve that issue. There are many ways of
> doing this.
>
> PaySwarm does not solve this issue either.
Clearly you think that we're talking about the "how does physical money
move?" issue. We're not - we're talking about how money is transferred,
electronically, between transaction processors thus updating the books
for each payment processor in near-real-time.
PaySwarm does solve this problem:
http://payswarm.com/specs/ED/web-api/2012-01-16/#the-decentralized-settlement-process
>>> First of all besides having a destination IRI how have you
>>> solved the real issues of interoperability? PaySwarm acts as it's
>>> magic. By adding a destination IRI the funds just magically
>>> appear on the other side. I have not been able to find anywhere
>>> in the spec where this is solved.
>>
>> We have not had the time to write the complete spec text and put it
>> into the PaySwarm specification yet. This is how it works, though:
>
> So you've spent the last couple of weeks saying we don't support it
> while you don't even support it yet in the spec?
No, that is not what is going on here:
PaySwarm has always intended to specify the decentralized payment
language in the 1.0 specification.
You have claimed that OpenTransact does not intend to specify any such
language in the 1.0 specification.
I noted that you had a good point that this is not evident to people
that are not working on the specs and as a result, I added the language
this past weekend:
http://payswarm.com/specs/ED/web-api/2012-01-16/#the-decentralized-settlement-process
If you will notice, none of the underlying data model had to change when
the spec text went it because the system was designed for
interoperability from day one.
My understanding is that OpenTransact does not intend to add any such
language to the OpenTransact 1.0 specification. Is that correct?
> This is a nostro account setup and is exactly what we have proposed
> in previous threads and on the open transact list over the past 2
> years.
Yes, but unless you standardize some algorithm and detail that algorithm
in a specification, you can't hope for interoperability.
>>> I would argue just by virtue of our focus on delegation,
>>> OpenTransact is considerably more open, secure and interoperable
>>> than a system where you have to share your private key.
>>
>> You /never/ have to share your private key in PaySwarm. Please
>> point out exactly where and when you have to do this.
>
> How would you create a mobile application to pay someone or to list
> an item?
All you need to use PaySwarm on a mobile device is just a regular Web
browser. :)
If you wanted to create a native mobile application that is capable of
digital signatures, one would do this:
1. The mobile application would ask the person using it to register
with their PaySwarm Authority. The person would type in some
domain like "google.com" and click "Register".
2. The mobile application would generate a public/private keypair
and use the Vendor Registration Algorithm[1] to register their
public key with their PaySwarm Authority.
3. The PaySwarm Authority would ask the person which rights they want to
associate with any request signed using the private key associated
with the public key. For example: "simple payment only", or
"listing and asset creation", or both.
Then the mobile application would digitally sign requests (such as
Transaction requests) and send them to the PaySwarm Authority for
fulfillment via the API.
Listings could be digitally signed by the mobile application and posted
on any site on the Web. For example, one could use a simple HTTP POST
with our demo listing service to list something for sale:
http://listings.dev.payswarm.com/
The mobile app could also just send the listing directly to the buyer
who would then create a contract containing the listing, sign it and
sent it to their PaySwarm Authority to process all payments contained in
the contract.
>> You are misunderstanding what Dave Longley was saying. He is saying
>> that "how a service asks a person what they want to allow a
>> particular grantee to perform on their behalf is out of scope." It
>> is out of scope for OAuth and it is out of scope for Digital
>> Signatures.
>
> It is not out of scope for OpenTransact. That is the Transfer
> Authorization section.
The "Transfer Authorization" section in the OpenTransact specification
says this:
"When a user follows this link, the Asset Service should present the
user with a form authorizing the payment."
/What/ the Asset Service displays on that form and /how/ it processes
that form is out of scope, so it is out of scope for OpenTransact.
That's what Dave Longley is saying.
That said, I think it's clear that how one does delegation with Digital
Signatures isn't clear to those that have not implemented it and
therefore I will try to put some spec text in the spec to explain how
this process works. :)
-- manu
[1]http://payswarm.com/specs/ED/web-api/2012-01-16/#vendor-registration
--
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/
Pelle Braendgaard
bcc: opentransact
On 01/13/12 12:02, Pelle Braendgaard wrote:Could you provide a link, please? I don't see where the technical
>> Please demonstrate this assertion. Show us how OpenTransact works
>> across payment providers. Is this functionality in the spec
>> already, or will it be in the core spec before it hits 1.0? You
>> have asserted previously that it would not be in the spec and that
>> it is out of scope.
>
> It is out of scope of the core specification and there will be a
> recipe soon. How it could be done has already been answered several
> times over the last couple of days.
specifics of how decentralized payments work in OpenTransact were
covered, either on the OpenTransact mailing list or the Web Payments
mailing list.
>> <mailto:bi...@example.com>? What if bi...@example.com
>> Now, assume that the user doesn't have an account on the Asset
>> Service... how do they pay bi...@example.com
>> <mailto:bi...@example.com> doesn't have an account on the Asset
>> Service? Even if it is out of scope, please explain how money getsI'm not talking about "how does the physical money move" :), I'm talking
>> from the sender's bank account to the receivers bank account.
>
> This has already been answered several times. There are many
> different ways of doing settlement see previous posts.
about how each of these OpenTransact servers keep their electronic books
in order in a decentralized system. I'm looking for some spec text that
looks like this (as demonstrated in the PaySwarm specification):
http://payswarm.com/specs/ED/web-api/2012-01-16/#the-decentralized-settlement-process
>> where AssetServiceAlpha contains AlphaPerson and AssetServiceBetaThere are many different ways that /could/ work :), I'm looking for the
>> contains BetaPerson. How does AlphaPerson send money to BetaPerson
>> without having to create an account on AssetServiceBeta? That is
>> the decentralized payment problem.
>
> How they do is that they specify a uri or email address in the to
> field. The recipient service can use a discovery service such as web
> finger or those proposed in OpenID Connect.
exact algorithm you are proposing for OpenTransact. However, if I
understand you correctly, even if there were such an algorithm, it
wouldn't go in the core OpenTransact specification? If that is true,
then how do the systems interoperate?
I agree, but that is not the question I am asking. I am asking about the
> Business relationships and clearing as mentioned many times before
> can be done in many different ways and does not need to be in the
> core spec.
technical specifics of how two OpenTransact systems communicate to note
that money has moved from one system to the other. Without that, the
systems are not interoperable (at least, not in the way that matters for
a transaction processing network).
>> http://tools.ietf.org/html/__rfc5321#section-3.6
>> This is the decentralized mail problem and was solved via the SMTP
>> protocol, which is a specification published by the IETF. So, the
>> answer to this question is here:
>>
>> <http://tools.ietf.org/html/rfc5321#section-3.6>Sending an ASCII message is exactly what the Automated Clearing House
>
> Sending an ascii message is very different than sending funds. You
> need an underlying clearing system either distributed as mentioned in
> many previous posts or centralized.
system does to transmit funds for every banking system in the US and
many other banks around the world! I've written software to do this,
here is the message format:
http://www.bankrcb.net/ACHOrig/achfileg.shtm
No, but nobody is claiming that it does. :) We had always planned on
> Just by specifying a IRI does not magically route funds.
specing the decentralized settlement algorithm into the PaySwarm 1.0
spec and as of this past weekend, it's spec'd:
http://payswarm.com/specs/ED/web-api/2012-01-16/#the-decentralized-settlement-process
We had worked out the details long ago but hadn't put it in the spec
>> If you can provide an answer like that, then OpenTransact is
>> interoperable with other OpenTransact systems. If no such document
>> exists, OpenTransact is not interoperable with other OpenTransact
>> systems.
>
> You haven't even been able to do this for PaySwarm, so please hold
> off on the intensity here.
yet. We've corrected that error and you can now find the spec text here:
http://payswarm.com/specs/ED/web-api/2012-01-16/#the-decentralized-settlement-process
Yes, but how do the books get updated from one payment provider to the
>>> I believe that integrating with the new OpenID Connect spec
>>> solves most if not all the account interoperability issues. So
>>> if it is already being done there why do we need to include it in
>>> OpenTransact?
>>
>> How does OpenID Connect solve the problem of crediting and
>> debiting financial accounts to transfer money between those
>> accounts when the accounts reside on different systems?
>
> It does not solve that issue. It solves the issue of identifying
> users and finding out who their preferred payment providers are.
other? What is the algorithm?
Clearly you think that we're talking about the "how does physical money
> Only business relationships solve that issue. There are many ways of
> doing this.
>
> PaySwarm does not solve this issue either.
move?" issue. We're not - we're talking about how money is transferred,
electronically, between transaction processors thus updating the books
for each payment processor in near-real-time.
PaySwarm does solve this problem:
http://payswarm.com/specs/ED/web-api/2012-01-16/#the-decentralized-settlement-process
>>> First of all besides having a destination IRI how have youNo, that is not what is going on here:
>>> solved the real issues of interoperability? PaySwarm acts as it's
>>> magic. By adding a destination IRI the funds just magically
>>> appear on the other side. I have not been able to find anywhere
>>> in the spec where this is solved.
>>
>> We have not had the time to write the complete spec text and put it
>> into the PaySwarm specification yet. This is how it works, though:
>
> So you've spent the last couple of weeks saying we don't support it
> while you don't even support it yet in the spec?
PaySwarm has always intended to specify the decentralized payment
language in the 1.0 specification.
You have claimed that OpenTransact does not intend to specify any such
language in the 1.0 specification.
I noted that you had a good point that this is not evident to people
that are not working on the specs and as a result, I added the language
this past weekend:
http://payswarm.com/specs/ED/web-api/2012-01-16/#the-decentralized-settlement-process
If you will notice, none of the underlying data model had to change when
the spec text went it because the system was designed for
interoperability from day one.
My understanding is that OpenTransact does not intend to add any such
language to the OpenTransact 1.0 specification. Is that correct?
Yes, but unless you standardize some algorithm and detail that algorithm
> This is a nostro account setup and is exactly what we have proposed
> in previous threads and on the open transact list over the past 2
> years.
in a specification, you can't hope for interoperability.
All you need to use PaySwarm on a mobile device is just a regular Web
>>> I would argue just by virtue of our focus on delegation,
>>> OpenTransact is considerably more open, secure and interoperable
>>> than a system where you have to share your private key.
>>
>> You /never/ have to share your private key in PaySwarm. Please
>> point out exactly where and when you have to do this.
>
> How would you create a mobile application to pay someone or to list
> an item?
browser. :)
If you wanted to create a native mobile application that is capable of
digital signatures, one would do this:
1. The mobile application would ask the person using it to register
with their PaySwarm Authority. The person would type in some
domain like "google.com" and click "Register".
2. The mobile application would generate a public/private keypair
and use the Vendor Registration Algorithm[1] to register their
public key with their PaySwarm Authority.
3. The PaySwarm Authority would ask the person which rights they want to
associate with any request signed using the private key associated
with the public key. For example: "simple payment only", or
"listing and asset creation", or both.
Then the mobile application would digitally sign requests (such as
Transaction requests) and send them to the PaySwarm Authority for
fulfillment via the API.
Listings could be digitally signed by the mobile application and posted
on any site on the Web. For example, one could use a simple HTTP POST
with our demo listing service to list something for sale:
http://listings.dev.payswarm.com/
The mobile app could also just send the listing directly to the buyer
who would then create a contract containing the listing, sign it and
sent it to their PaySwarm Authority to process all payments contained in
the contract.
The "Transfer Authorization" section in the OpenTransact specification
>> You are misunderstanding what Dave Longley was saying. He is saying
>> that "how a service asks a person what they want to allow a
>> particular grantee to perform on their behalf is out of scope." It
>> is out of scope for OAuth and it is out of scope for Digital
>> Signatures.
>
> It is not out of scope for OpenTransact. That is the Transfer
> Authorization section.
says this:
/What/ the Asset Service displays on that form and /how/ it processes
"When a user follows this link, the Asset Service should present the
user with a form authorizing the payment."
that form is out of scope, so it is out of scope for OpenTransact.
That's what Dave Longley is saying.
That said, I think it's clear that how one does delegation with Digital
Signatures isn't clear to those that have not implemented it and
therefore I will try to put some spec text in the spec to explain how
this process works. :)
-- manu
[1]http://payswarm.com/specs/ED/web-api/2012-01-16/#vendor-registration
President/CEO - Digital Bazaar, Inc.
--
Manu Sporny (skype: msporny, twitter: manusporny)
blog: Web Payments - PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/
-P