W3C home > Mailing lists > Public > public-webpayments@w3.org > August 2011

Focus for payment standards

From: Pelle Braendgaard <pelle@stakeventures.com>
Date: Thu, 25 Aug 2011 12:06:48 -0400
Message-ID: <CAHtLsUXiPAnF45DC2N=duk18VWmK-wwiYaC6+r9acaMPjQkOrQ@mail.gmail.com>
To: public-webpayments@w3.org
Hi,
I've been following payment standards and apis as well as security etc
standard for many years now and wanted to start the discussion here with
just a few suggestions on maintaining focus so we can actually get this
thing out there and in use in a way that works for everyone.

There are many different use cases for web payments. Here are just a few:

- pay as you go for content, which is where I think most of the focus has
been so far.
- shopping carts
- subscriptions
- fund transfer via the web (remittences etc.)
- invoicing/payments
etc. etc.

If we do a good job this standard can work these and 100s of other use cases
that no one has even thought about yet.

How do we do that?

Lets try and analyze each of these use cases to find common areas first.

Work on developing these common areas in such a way that they can be used
either separately or together and then put them back together to provided
recommended flows for each use case.

OAUTH2 AS AN EXAMPLE

A good example of this is the OAuth 2 standard which finally looks like it
has adapted to most everyone's use cases while becoming more clear and
modular.

OAuth2 now provides 2 core authentication methods (Bearer or HmacSignature)
but with the possibility of adding further types

  http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-7.1

Yet at the same time they provide various standardized flows matching
various uses cases for authorizing tokens:

  http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4

COMMON DENOMINATORS OF WEB PAYMENTS

For web payments there is at least one common denominator of all the use
cases, the simple payment.

Almost all will also need some kind of discoverability which is where the
RDF and talk of directories come in.

In the OpenTransact lists we have recently started work on discussing what
makes an offer and language surrounding it, this is also an important area
that would be useful to many but not all of the above use cases.

I personally think fraud and DRM are separate issues that may be better
discussed as best practices rather than standardized. But I may be wrong. If
we do work on this it should like almost everything else be an optional
building block in the standard.

An initial list of items I think we need to for a web payment standard:

- Value transfer ( core payment)
- Discoverability of assets and payment methods
- Offer creation and discoverability
- Offer acceptance

But lets analyze the major use cases and work out the specifics first.


-- 
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking
Received on Thursday, 25 August 2011 16:07:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 25 August 2011 16:07:25 GMT