W3C Web Payments, PaySwarn and OpenTransact

[Pelle Braendgaard]

This is mainly to the web payments list, but I am cc'ing OpenTransact as well.

As I mentioned on todays talk I would like to express my dissatisfaction with the process in the W3C web payments group.

While the PaySwarm proposal has many great ideas I strongly believe that the PaySwarm proposal is fundamentally flawed:

  http://payswarm.com/specs/ED/web-api/2011-12-14/

My objections are:

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.

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.

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. While I believe this is a great pattern to implement, it makes too many assumptions about what a payment is. Not all payments are made as purchases and not all purchases are made where the purchased item will follow the PaySwarm model. At PicoMoney we have implemented essentially the same level of functionality on the application level with a much simpler OpenTransact api on top of it.

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.

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.

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

The current draft of OpenTransact is here:

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

The main site with a simple overview can be found here:

  http://www.opentransact.org/

A OpenTransact url represents a unique asset on the web. A provider can provide different URL's for different purposes. 

The 3 basic requests of OpenTransact are very simple and very similar:

 - Transfer Request - An website requests payment from a user

 - Transfer Authorization - A website requests authorization to perform a payment from a user at a later time

 - Transfer - A pre authorized website performs a payment on behalf a user

I believe there are very few of the PaySwarm use cases that couldn't be achieved through OpenTransact url's with different underlying business rules.

3 extensions that could be created on top of  OpenTransact if the community desires are:

  - Signed receipts

  - Signed transactions

  - Offers and trading (Already being discussed)

OpenTransact builds on OAuth 2 and http. It can coexists well with OpenID Connect (not to be confused with traditional OpenID).

Please feel free to comment and ask questions about how specific use cases could be implemented using OpenTransact.

Pelle

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

[David Nicol]

what's a good introductory link for "openid connect?"

On Fri, Dec 16, 2011 at 2:18 PM, Pelle Braendgaard <pe...@stakeventures.com> wrote:

OpenTransact builds on OAuth 2 and http. It can coexists well with OpenID Connect (not to be confused with traditional OpenID).

--
Application of Porter's value chain model to the executive function reveals that the executive process transforms the input of information into the output of decisions.

[Pelle Braendgaard]

Hi David,

Sorry I should have included a link.

http://openid.net/connect/

The original OpenID was incredibly complex, which is why commercial alternatives like twitter login and facebook connect gained ground using oauth and oauth2 respectively.

The problem with using a token as a user identifier is that it then needs to be permanent. OpenID Connect solves it by adding a separate id_token to a OAuth2 authentication request, which can be used as a user identifier.

The clever thing is that it can be combined with any other OAuth 2 authorization request such as an OpenTransact authorization request. This means you can authorize a payment as well as provide identity information to a merchant in a simple step.

P

[Alan DeRossett]

'Call Janrain.com

or use one or the OpenID plugins for your CMS.

Alan DeRossett

[matake@gmail]

Currently, OpenID Connect is not finalized and there are no real-world applications.

You can try Google's OpenID Connect demo site.

http://oauthssodemo.appspot.com/step/1

Or if you are rails developer, you can use my OpenID Connect sample IdP & RP which open-sourced on github.

https://connect-op.heroku.com/

https://connect-rp.heroku.com/

[Melvin Carvalho]

Thanks for posting some interesting points.

I read through the spec, and I'm looking forward to the continued
development of OpenTransact, hopefully in a way that is going to scale
to the whole web.

A couple of points:

1. It is the W3C Payments "Community" Group. Community is an
important in that it is more informal than an incubator or working
group, which are traditionally the tracks for standardization. A
community group brings like minded people together to create
implementations, prototypes and candidates for standards. In fact the
W3C has no 'standards', when an RFC is considered ready and well
reviewed, it is given REC (recommendation) status, and it's possible
to have several complimentary recommendations. So it would be a
mistake to think anything here is a cast iron standard, but certainly
things can move in that direction.

2. The trusted third party (TTP) vs the direct PKI debate has been
going on a long time. More recently in Oauth vs digital signature
conversation. Both are have a place. But if you consider the authors
of OAuth (google, microsoft, facebook) they are understandably going
to push the TTP solution with them being the white listed trust center
(originally microsoft tried this with "passport", but oauth is
essentially a slightly more distributed replacement for that). This
is fine but I think there's also a good case for the user-centric
direct PKI solution.

In my apps I trying to use both, I'm happy to get a big OAuth user
base, but also glad for the direct connection in case OAuth
(inevitably) becomes more centralized, and also for the simplified
flows, which can present more possibilities.

Enjoyed listening to the healthy discussion in the most recent
telecon, keep up the good work.

[Melvin Carvalho]

On 16 December 2011 21:18, Pelle Braendgaard <pe...@stakeventures.com> wrote:

Very interesting spec. One question I have on this.

Why not make currency a parameter, rather than hard coded into the URI?

[David Nicol]

On Mon, Dec 19, 2011 at 5:41 AM, Melvin Carvalho <melvinc...@gmail.com> wrote:

Why not make currency a parameter, rather than hard coded into the URI?

Ha. In the tipjar.com "give" spec, (1996) currency is a parameter. Aside from that it's an opentransact url.

With the currency specified as part of the path, you can still do a multiple-currency give user experience, but it would take a little client-side scripting instead of a simple select input.

[Pelle Braendgaard]

Hi Melvin,

The main reason for it being implied by the URL was to push the idea of every value within a specific OpenTransact url as being fungible, meaning a specific kind of value. Essentially we're taking the the URL literal as being an identifier of a particular kind of fungible asset. These don't necessarily have to be monetary, but could be virtual goods in a game, a SKU in a web shop or other items.

As David Nicol says the main problem is that javascript needs to be used to pick a currency. I think that in most cases this isn't a problem as most external payment forms are meant to be used for a purchase with a preselected currency. However an optional 'currency' parameter could be added to the spec if need be.

Pelle

[Pelle Braendgaard]

See comments within:

On Sun, Dec 18, 2011 at 3:42 PM, Manu Sporny <msp...@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/

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.

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

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

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

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/

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/

[David Nicol]

On Tue, Dec 20, 2011 at 9:16 AM, Pelle Braendgaard <pe...@stakeventures.com>purchase with a preselected currency. However an optional 'currency' parameter could be added to the spec if need be.

call that parameter "currency" and you've got "the give form interface" as described http://liveweb.archive.org/http://tipjar.com/20101110index.html and other places too. Looking for an early version of that, I found
http://www.tipjar.com/doc/Manifesto.html which is interesting i posted that in 2000 :)

[Melvin Carvalho]

On 20 December 2011 16:16, Pelle Braendgaard <pe...@stakeventures.com> wrote:
> Hi Melvin,
> The main reason for it being implied by the URL was to push the idea of
> every value within a specific OpenTransact url as being fungible, meaning a
> specific kind of value. Essentially we're taking the the URL literal as
> being an identifier of a particular kind of fungible asset. These don't
> necessarily have to be monetary, but could be virtual goods in a game, a SKU
> in a web shop or other items.
>
> As David Nicol says the main problem is that javascript needs to be used to
> pick a currency. I think that in most cases this isn't a problem as most
> external payment forms are meant to be used for a purchase with a
> preselected currency. However an optional 'currency' parameter could be
> added to the spec if need be.

Looking at the spec on

http://www.opentransact.org/

And on

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

They look pretty similar (and to tipjar and bitcoin). This also looks
quite close to the json that I'll be using.

Why not try and align the two of this in terms of naming and decide
whether the currency should be a parameter. I also wonder if asset is
strictly needed.

The authentication layer can then build on top of this simple
standard. Whether you use OAuth2 via a third party, or direct PKI or
a combination will allow different usage patterns.