Re: The difference between PaySwarm and OpenTransact

25 views
Skip to first unread message

Pelle Braendgaard

unread,
Jan 12, 2012, 2:38:15 PM1/12/12
to Dave Longley, public-we...@w3.org, opentr...@googlegroups.com
Dave,
No where does it mention that OpenTransact is for individual payment providers.

It is about creating a lively open ecosystem of payment providers, merchants, marketplaces and other kinds of apps.

The basic building block is a transfer. That transfer could encompass one or more transfers with business logic behind the scenes.

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.

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.


P

On Thu, Jan 12, 2012 at 2:25 PM, Dave Longley <dlon...@digitalbazaar.com> wrote:
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

unread,
Jan 12, 2012, 5:44:32 PM1/12/12
to Web Payments, opentr...@googlegroups.com
On Thu, Jan 12, 2012 at 3:26 PM, Dave Longley <dlon...@digitalbazaar.com> 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. On PicoMoney alone we have probably over 100 different OpenTransact assets already and there are several different OpenSource implementations already. As I mentioned earlier there are several local time banks using it. These can all interoperate together.

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.

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.

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?

 
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.

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 realize that this is an important issue and have been talking about it on the list the last 2 years. There are many ways of solving the issue and yes we also recommend using URI's as account identifiers.

When I say things are out of scope I say they are out of scope of the core 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.

 

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.

This exposes the most simple atomic structures to application developers so they can build and redefine commerce and finance in a way not possible if you structure your standard around a single commerce model.

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.
 
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.

By leaving that out of the specification you are eliminating at least the following use cases, which all rely on mobile devices:



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.

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.
 
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).

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.


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.

You have said yourself that digital signatures do not solve delegation. Signatures and delegation are two very different things that solve two very different problems.
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 beg to differ. It's SOAP vs Rest
 
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.

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 also admit my tone soured then and I should not have used the "everything is out of scope" term.

Hopefully in tomorrows call we can be more civil and and talk openly about what we can do to work together on this.

Pelle

David I. Lehn

unread,
Jan 12, 2012, 6:05:33 PM1/12/12
to opentr...@googlegroups.com, Web Payments
On Thu, Jan 12, 2012 at 5:44 PM, Pelle Braendgaard
<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

unread,
Jan 12, 2012, 7:30:22 PM1/12/12
to opentr...@googlegroups.com, Web Payments
On Thu, Jan 12, 2012 at 4:44 PM, Pelle Braendgaard
<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

unread,
Jan 12, 2012, 8:27:55 PM1/12/12
to Web Payments, opentr...@googlegroups.com
On 01/12/2012 05:44 PM, Pelle Braendgaard wrote:
> On Thu, Jan 12, 2012 at 3:26 PM, Dave Longley
> <dlon...@digitalbazaar.com <mailto:dlon...@digitalbazaar.com>>

> 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&note=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

unread,
Jan 13, 2012, 11:43:14 AM1/13/12
to opentr...@googlegroups.com, Web Payments
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.

It was particularly ridiculed when they created a "SOAP Resource Representation Header" spec:


Which was jokingly called HTTP over SOAP.


Rest on the other hand is web native and simple.

It's about resources and actions you perform on it.

OpenTransact uses the concept of Assets as the resources. Payment itself is a simple restful action on an asset.

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.



Pelle Braendgaard

unread,
Jan 13, 2012, 12:02:44 PM1/13/12
to opentr...@googlegroups.com, Web Payments
I will make my answers short.

On Thu, Jan 12, 2012 at 8:27 PM, Manu Sporny <msp...@digitalbazaar.com> wrote:
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.

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.
 

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&note=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.

This has already been answered several times.

There are many different ways of doing settlement see previous posts.
 

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.

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.

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.
 

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


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. Just by specifying a IRI does not magically route funds.
 
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.
 

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.

This is about business relationships between payment providers and not a technical standard.
 

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?

Please see previous threads where this exact issue has been discussed.
 

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.

Only business relationships solve that issue. There are many ways of doing this. 

PaySwarm does not solve this issue either.


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? 
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.
 

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.

How would you create a mobile application to pay someone or to list an item?
 

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.

It is not out of scope for OpenTransact. That is the Transfer Authorization section.

Will be on the call now and reply to the remainder later.

Manu Sporny

unread,
Jan 16, 2012, 1:57:01 PM1/16/12
to Web Payments
bcc: opentransact

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

unread,
Jan 16, 2012, 3:05:22 PM1/16/12
to Web Payments
bcc: opentransact

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

unread,
Jan 24, 2012, 10:09:47 AM1/24/12
to opentr...@googlegroups.com, Web Payments
On Mon, Jan 16, 2012 at 5:05 PM, Manu Sporny <msp...@digitalbazaar.com> wrote:
bcc: opentransact
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.

David Nicol wrote up an example here:


Also remember that at the time of writing this there was no PaySwarm definition either. 

By next week I will have written up a federated asset clearing recipe.

It is very important to understand why we don't want this to be in the core spec.

OpenTransact was designed not just for traditional monetary transactions, but also for other kinds of digital assets. Many of these digital assets don't make sense to use in a federated way and are not denominated in national currency units.

PaySwarm can insist that this has to be in the core spec as it merges multiple layers together and this belongs at a higher level. OpenTransact Core specifically only deals with transfers and as such lies at a lower layer.

I think the community currency world is the best place to implement/experiment with this. One of the primary use cases mentioned at the Complimentary Currency conference last year was a member moving from one community to another. Which would be fairly simple to implement.


Anyway I'll write more on this over the next week. Just getting settled in in Chile.

 

>> 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

I will write up this as I said in a  separate recipe. It may very well look similar.

I'll repeat, this was not around on either of our specs at the time of this original discussion, so I'm glad it was written up, so we can have a better discussion.

>> 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?

See David Nicol's write up for a possible implementation. 

> 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

Of course a message is one part of it, yet the most important part of it is the business relations supporting it.

OpenTransact in this way is like an IP packet. It specifies a source, destination and amount but not how to route it.

Routing is handled by various different mechanisms that are out of scope at this particular layer of the protocol.

Routing protocols are important, but not part of this layer. An application sending an IP message does not need to understand the magic that routes an IP packet across the net. Similarly OpenTransact applications do not need to understand these things.

There will also always be many different ways of routing. As we've mentioned before it can be done centralized or through various different distributed methods such as Melvin's WebCredits or Ripple. Obliging implementors to follow one specific method is not a good idea and halts innovation in a field where lots of innovation is possible.

That said as I've mentioned, I'm all for having a suggested way of doing it to open the discussion.



> 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:

This is where I think our conversation went off track. 

You can not come up with a comparison list like you did in your original blog post, listing features you support that are only specced in your head while demanding write ups from us. That is not the way to do this.

We have taken the criticism to heart on creating proper recipes and are working on it.
 

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

This simply explains how to do a payment via nostro accounts. Which is in itself a very simple process. 

The hard issue, which is what various people are trying to solve including Melvin's WebCredit, Ripple and Rivulet (https://github.com/jplewicke/rivulet) is the trust network that allows payments between 2 arbitrary financial institutions without prior contractual relationships.

As we've said repeatedly there are many different ways of doing this and many of them will use something like the nostro account based method you outline. But there may be other ways of doing it. BitCoin or Fellow Travelers OpenTransactions https://github.com/FellowTraveler/Open-Transactions are possibilities.

 
>>> 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?

For the reasons I and others have outlined repeatedly, no. This will not be in OpenTransact Core. Just like the core IP protocol does not specify routing. This has to be done at a different layer to allow innovation and simplify application development

That does not mean that OpenTransact does not support it, just that it belongs in different specs. Just like IP doesn't specify how to route a packet from China to Chile, IP still supports doing it through other specs.


> 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.

Yes you need to have some (not one) standard ways of doing things  but this does not belong in the core OpenTransact spec.

>>> 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. :)

I prefer mobile web over custom applications. However IOS and Android apps present a market place where large amounts of innovation is happening. Things that just aren't possible on the mobile web today. 

A community currency could create a mobile payment app using NFC, Bump, GPS or other kind of technologies to interface with one or more OpenTransact endpoints to allow people to use the currency in their community. This is not possible with the PaySwarm spec since it doesn't support delegation.

 

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.

This is why OpenTransact piggy backs on top of OAuth2 It describes this flow very clearly. It could be used well from within PaySwarm even with the use of digital signatures.

OAuth 2 has split out the actual authorization headers into separate specs such as the bearer token or Mac schemes. OAuth 2 really just deals with the delegation part now and it does it in a very clear well understood way.
 

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.

How the form is displayed and how asset services implement it is clearly out of scope but the behavior that applications/merchants should expect is very clearly described and very much in scope of OpenTransact.
 

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/

-P
Reply all
Reply to author
Forward
0 new messages