Re: W3C Web Payments, PaySwarn and OpenTransact

See comments within:

On Sun, Dec 18, 2011 at 3:42 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:

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

CSS was a monolithic spec but it took a long time before browser vendors
started implementing the full spec and I believe it was for these same
reasons. RDFa and JSON-LD I can't comment on.

I hold on my assertion that is a bad idea to create a huge monolithic
standard. The web came out of several smaller standards eg. HTTP, HTML,
URL, SSL that then became known as the web together. These all started
simple, allowed the market to extend and grow based on the imagination of
developers over the years.


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

I am sure that this is how you've developed it internally but that is not
necessarily what has been presented outwards to the group.


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

I agree.


>
> 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<http://www.opentransact.org/usecases.html>


I have nothing against use cases per say, except that they can be limiting.
They are very important but the fact is that most of the now important use
cases of most of many standards have come after the fact. 2 examples being:

1. Web site authentication via a web form and a cookie. This was not even
possible in straight http 1.0 as the cookie needed to be invented first.
Almost none of the Authentication schemes from http 1.1 are in common use
today.

2. Logging in via OAuth. I don't think even Twitter realized this would
happen when they implemented OAuth. But now OAuth based login via third
party systems is one of the most important applications of OAuth. Now that
the use case has been thoroughly validated OpenID is learning from this
market created authentication scheme and OpenID Connect is the new enhanced
version.



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


Maybe I was wrong in mentioning this, yet I feel we have debated the
digital signature issue non stop yet PaySwarm seems permanently married to
the idea.


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

You are correct. I should have acknowledged that.


>
> 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/**
> 4df3077a78552a84d4fce42c536f7f**dcce8f663c/payswarm-config.inc<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.
>

I agree that OAuth favors centralization, but it doesn't have to be that
way. A lot of work has been done in discovery which I think will solve a
lot of these issues. Here is the Simple Web Discovery spec which could
apply to anything from OpenTransact to OpenID:

  http://self-issued.info/docs/draft-jones-simple-web-discovery.html

Granted large players like twitter and Facebook are not so into this
aspect, but that doesn't mean that other players can't push for it.

As I've mentioned repeatedly I like digital signatures for receipts, asset
descriptions etc. However there are many very good reasons that I feel like
I've mentioned repeatedly that means that it can not be a fundamental part
of a new internet standard until many things change.

A. End users do not have access to signing in browsers
B. Even if they could sign in their browsers, they can't sign if they
forget their password and thus some sort of escrow system needs to be in
place with a TTP
C.  Digital signatures them selves while beautiful are not legal signatures
unless the other aspects of a signature are there such as intent.
D. Most developers don't understand them or how to deal with them.
E. Several large services who have option of using digital signatures such
as PayPal and Amazon Web Services had to scrap it or create a completely
dumbed down version of it thus eliminating the benefits due to D.

That said I believe that signatures are eminently suitable as an optional
field. Good providers will sign things on behalf of their customers, which
hopefully would be a good competitive practice leading to the majority of
providers supporting it.


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

Signatures and AES are 2 very different things. I don't recall any of the
use cases that depend on AES. Generally encryption would be handled over
the wire by HTTPS.

* That you can achieve those 10+ Web Payments use cases using OAuth.


I will happily go through each use case and outline how it can be done
using OAuth/OpenTransact. Give me a bit of time.


>  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<http://purl.org/commerce#Transaction>
>
> A Contract is type of Transaction (it's modeled as a mix-in):
>
> http://purl.org/payswarm#**Contract <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. :)


I'll be looking forward to seeing this as it is the most important aspect
of a payment.


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


We have generally not added anything to the spec until a specific
requirement has happened in a real world application. Adding additional
parameters such as signatures are pretty easy. Managing a PKI is more
difficult and likely out of scope of OpenTransact itself. For this we would
defer to some separate PKI proposal. Either based on traditional certs (yes
I know they are broken) or something new like the EFF's new Sovereign Keys
proposal:

  https://www.eff.org/sovereign-keys

The signature itself just needs a parameter in the receipt json such as
"receipt_signature" and some identifier such as cert id or digest of the
public key. I'm happy to hear suggestions here.



>  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/<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. :)
>

My livelihood also depends on it. I have seen so many alternative payment
standard and api proposals over the last 15 year. All of them have failed
due to them being too complex and wanting to do too much from the outset.
Because of that PayPal is the defacto simple web payment api today and
payment innovation means creating plastic dongles to read credit cards and
taking pictures of checks to deposit them.

Most of us on the OpenTransact list have many different specific goals for
how we want to use OpenTransact, but I think I can speak for most of us
that we desperately want an alternative to the existing banking/payment
systems. The easy default should be picking one or more OpenTransact
providers and not just going with PayPal or integrating with a merchant
account.


>
> 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.
>
> Thanks Manu. I am looking forward to reading it.


> -- 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/<http://manu.sporny.org/2011/data-driven-standards/>
>

Pelle


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