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

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 bill@example.com 
>> <mailto:bill@example.com>? What if bill@example.com 
>> <mailto: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.

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/

Received on Monday, 16 January 2012 20:05:49 UTC