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

I will make my answers short.

On Thu, Jan 12, 2012 at 8:27 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:

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

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=bill@example.com&**amount=100.00&note=Milk&**redirect_uri=
> http://site.**example.com/callback <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.
>

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


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

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/#mobile-computing-based-purchase>
>>
> > http://payswarm.com/specs/**source/use-cases/#point-of-**sale-device<http://payswarm.com/specs/source/use-cases/#point-of-sale-device>
>
>> http://payswarm.com/specs/**source/use-cases/#automated-**vending<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.


>
> 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/<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/<http://manu.sporny.org/2011/web-payments-comparison/>
>



-- 
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking