W3C home > Mailing lists > Public > public-webpayments@w3.org > January 2012

OpenTransact Centralization (was Re: The difference between PaySwarm and OpenTransact)

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 12 Jan 2012 20:27:55 -0500
Message-ID: <4F0F889B.7060800@digitalbazaar.com>
To: Web Payments <public-webpayments@w3.org>
CC: opentransact@googlegroups.com
On 01/12/2012 05:44 PM, Pelle Braendgaard wrote:
> On Thu, Jan 12, 2012 at 3:26 PM, Dave Longley
> <dlongley@digitalbazaar.com <mailto:dlongley@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=bill@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 bill@example.com? What if bill@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:

alpha@EmailServiceAlpha.com
beta@EmailServiceBeta.com

where EmailServiceAlpha.com hosts the e-mail account for
alpha@EmailServiceAlpha.com and EmailServiceBeta.com hosts the e-mail
account for beta@EmailServiceBeta.com. How does
alpha@EmailServiceAlpha.com send an e-mail to beta@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/
Received on Friday, 13 January 2012 01:31:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:20 UTC