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

On Mon, Jan 16, 2012 at 5:05 PM, Manu Sporny <msporny@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:

http://groups.google.com/group/opentransact/browse_frm/thread/5f8c8fb0fb8f760f

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.

http://www.nesta.org.uk/assets/blog_entries/opentransact_chosen_for_intertrading_protocol

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


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

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