Re: W3C Web Payments, PaySwarn and OpenTransact

Hi Pelle,

Thank you for bringing your concerns to the mailing list. :)

As I mentioned in the telecon, it is very important that we fully vet
each one of these technologies to ensure that we truly understand the
state of the art across all of the technologies in use today. For those
that missed the discussion that kicked off Pelle's e-mail, please see
the minutes for Friday's telecon:

http://payswarm.com/minutes/2011-12-16/

My initial thoughts on your proposal are below, mostly corrections to a
few assertions that you make that are not accurate.

I have also taken it upon myself to do a complete technical review of
OpenTransact as it relates to PaySwarm and will be writing up a blog
post of that within the next few days. I had done a fairly thorough
vetting of OpenTransact a few months ago, but since we're having this
discussion now, I thought it would be best to capture that vetting in a
blog post and then perhaps turn it into a list of features for PaySwarm.
It'll take me a day or two to put it together, at which time
I'll notify the list and we can make any corrections that are necessary.

On 12/16/2011 03:18 PM, Pelle Braendgaard wrote:
> It's a huge monolithic standard designed using waterfall methodology
>  to support a large list of predefined use cases:
>
> http://payswarm.com/specs/ED/use-cases/2011-10-20/
>
> I think it's better to create smaller standards using real needs of
> today. These standards can be expanded on as various real word cases
>  are deployed and or experimented with.

What is a monolithic document today is a set of layered specs tomorrow.
CSS started out as a monolithic spec, RDFa started out as a monolithic
spec, JSON-LD started out as a monolithic spec. It helps to have all of
your ideas in a cohesive document before you split everything up as the
lines where you split it change over time. For all three examples above,
what started out as a monolithic spec ended up as a set of
lighter-weight specs in the end (I was directly involved as a Chair of
the group in two of these initiatives). Just because the document is
monolithic today says nothing about what it could be when we're done
with the technical work.

Additionally, you are assuming that we designed PaySwarm using a
waterfall methodology when what you do not see is the 7 years of work
that went into PaySwarm to get it to this point. Some of that
development was agile, some waterfall, some hacking, lots of
refactoring, but mostly lots of iterations on the concept until we felt
where we are today is the general direction that makes sense for the
Web.

We threw a great deal of use cases out in the process.

The methodology used, however, is neither here nor there - what is
important is a technical solution that is secure, relatively simple to
implement, and that works for the use cases that we agree to as a group.
There are many roads to a successful Internet standard. :)

If your concern is that we identified a large set of use cases before we
started technical discussion, and your assertion is that is not how
successful standards are created, then I provide the following counter
examples (all Web standards which have lists of use cases):

HTML5, CSS3, RDFa, Microdata, and OAuth.

Even OpenTransact started out with Use Cases:

http://www.opentransact.org/usecases.html

This is, in fact, the standard way that we develop Web standards.
However, this is beside the point - we should be focusing on technical
issues, not the methodology used to design the technology.
Methodological arguments are fantastic perma-thread food and I'd like to
avoid the meta-discussion of /how/ the specification is built and
instead focus on actually building useful specifications.

So, I think statements like:

"I believe that digital signatures are not necessary to create a secure
financial system." are actionable

Whereas statements like:

"I believe that the methodology used to build PaySwarm is wrong" end up
getting us into a meta-debate on the best methodology to use when
building a standard.

> PaySwarm rejects the use of standard internet protocols such as OAuth
> 2, rather builds it's on custom authentication scheme using digital
> signatures. I believe there is no better option right now than using
> OAuth 2 for the majority of server to server authentication. With
> OAuth 2 this is a solved issue and should not be reimplemented.

This statement is very misleading. PaySwarm builds upon the following
set of standards:

HTTP, HTML, RDFa, JSON, JSON-LD, TLS, AES, and REST

PaySwarm only rejects pre-existing Internet standards if they are a bad
fit for the technology.

OAuth is a bad fit because it overly complicates implementations - it
requires people to implement both OAuth and digital signatures when they
only need to implement digital signatures. We are not just postulating
that, we actually implemented PaySwarm using OAuth, here's the proof:

https://github.com/digitalbazaar/payswarm-wordpress/blob/4df3077a78552a84d4fce42c536f7fdcce8f663c/payswarm-config.inc

As Melvin outlined in a previous e-mail, OAuth favors centralization and
limits the number of use cases that we can address via PaySwarm. OAuth
is great for access control delegation, but digital signatures allow
that as well /and/ have the added benefit of enabling things like
digital contracts, signed receipts, signed assets, listings, proxy-based
purchases and a variety of other use cases that we would like to address
with PaySwarm. Digital signatures do this while reducing the code
complexity of the system.

So, if you want PaySwarm to use OAuth and drop digital signatures, then
you must convince us of one of these two things:

* That the 10+ Web Payments use cases that depend on AES should not be
   supported.
* That you can achieve those 10+ Web Payments use cases using OAuth.

> PaySwarm has as it's fundamental model a purchase which is a contract
> which consists of a digital signed combination of a signed offer and
> a signed payment.

That is incorrect. PaySwarm's fundamental model is a transaction:

http://purl.org/commerce#Transaction

A Contract is type of Transaction (it's modeled as a mix-in):

http://purl.org/payswarm#Contract

Unfortunately, the spec does not outline a simple Transfer/Transaction
yet because that's the easy part of the standard... we were more
concerned about getting the difficult bits sorted out because we had
solved the "Transfer/Transaction" problem long ago. Our bad, as this is
causing a great deal of confusion around the issue, so we'll try to
outline how this is done in the next revision of the spec. :)

> The digital signature requirement is unfortunate. I have always been
>  a big believer in digital signatures for many things, yet they
> complicate matters terribly particularly when involving users with
> web browsers. A simple signature extensions can be added to
> OpenTransact to handle those instances where it is required.

Yes, but this is not in the OpenTransact spec. I'd like to see some
spec language on how you accomplish this via OpenTransact. We should not
fall into the trap of stating that implementing something like digital
signatures "can be added where it is required" and then not actually
solve the technical issues that enable that in OpenTransact.

> Since I joined this process I have tried hard to push for a layered
> approach utilizing OpenTransact for the payment specific layers and
> separate work for creation offers and product listings.

Yes, and we have always appreciated your input, Pelle. :) The Payment
Links specification is one of the results of your input into the group:

http://payswarm.com/specs/source/payment-links/

Just because we don't bring all of your input on board immediately does
not mean that we're ignoring it. It means that a solid technical case
for some of your input has not been made so as to be convincing enough
for us to effect change in the PaySwarm specification. Convince us and
we'll change the spec. I think you'll find that we're very reasonable
when it comes to attempting to make sure that the standard is
successful. Afterall, our livelihood depends on it. :)

An alternative is co-developing OpenTransact and PaySwarm as two
separate specifications. That would also be a perfectly reasonable way
to ensure that we have all of our bases covered.

> So I am now officially proposing OpenTransact to the W3C web payments
> group.

Thank you, it is vital that we vet all of these technologies and see how
they compare against one another. Personally, I am very appreciative of
the time and work that you have put into OpenTransact and hope to
demonstrate my appreciation by doing a thorough review and analysis of
the protocol.

I'm currently writing up a blog post analyzing both technologies and
will post it publicly as soon as it is done.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Need for Data-Driven Standards
http://manu.sporny.org/2011/data-driven-standards/

Received on Sunday, 18 December 2011 20:43:24 UTC