Re: The difference between PaySwarm and OpenTransact

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/

Received on Monday, 16 January 2012 18:57:30 UTC