- From: Pelle Braendgaard <pelle@stakeventures.com>
- Date: Thu, 25 Aug 2011 12:06:48 -0400
- To: public-webpayments@w3.org
- Message-ID: <CAHtLsUXiPAnF45DC2N=duk18VWmK-wwiYaC6+r9acaMPjQkOrQ@mail.gmail.com>
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 UTC