Re: W3C workshop on payments and the Web?

On 05/11/12 14:55, Dave Raggett wrote:
> Thanks for your feedback. We have plenty of time to collect further 
> input towards a workshop, and it should be practical to arrange some 
> form of remote participation for those who are unable to travel.

I don't think mixed remote participation in workshops really works that
well (unless the entire workshop is remote participation only). We could
discuss doing a Google Hangout for the workshop. I think all the tools
are there (video, recording, screen sharing, etc.)... and I think that
would be more inclusive and less costly for folks.

> With regards to using Web Intents, study of existing and planned
> payment solutions would provide material for further discussions on
> the requirements for an agnostic payment interface between a web
> application script and the payment solution.

I agree - perhaps someone in the group would like to volunteer to put
that together?

> The CG appears to approaching this from the perspective of new
> payment solutions rather than more traditional ones.

I think that what various members in this group are focusing on are the
solutions that they think will make a difference. For example - Melvin
and Michiel are focused on Web Credits. Pelle and David are focused on
OpenTransact. Dave Longley, Dave Lehn, and Jeff Sayre are involved in
PaySwarm. I'm partial to PaySwarm and Web Credits.

The underlying issue here is that the JavaScript interface and UI comes
after we figure out how to make these systems interoperable. That's
what's really missing here - is decentralized payment and
interoperability... and unfortunately, all of the large/current payment
systems in the market are only interoperable at a very basic level -
which you have to pay large amounts of money into in order to interoperate.

So the real issue is ensuring that whatever solution is created takes
the back-end plumbing into account. Having a fancy UI that allows you to
pick between PayPal, Flattr, Google Checkout, Amazon Payments, etc. is
useless if those services can't inter-operate with one another.

> I suspect that a whitelist of services provided by the website 
> hosting the web app may prove practical especially for solutions
> built around debit and credit cards whether physical or virtual (as
> in eWallets). It is also possible to imagine trusted third parties
> that bridge between services, thereby indirectly expanding the
> coverage of a white list. The concept of a white list is an
> interesting contribution to the discussion on Web Intents.

Sure, but as I said in the previous e-mail, this problem is a bit harder
than it seems at first. For example, it requires websites to keep their
whitelist up-to-date and that's not always practical for all websites.
There are many ways to go about this, but the place we have to end up is
something equivalent to or /simpler/ than the current state of the art.

A benefit of distributed whitelists is that the choice of who to trust
is left to the web app - this is good (and is what we do in PaySwarm).
However, a down-side is that the website might not update their
whitelist and lose out on customers.

So, it's not only about the whitelist - but how the whitelist is updated
and how that impacts the customer's experience. If the whitelist is
centrally controlled (which might lead to the best customer experience)
- then listing how systems qualify for being added to the whitelist
becomes very important as you don't want the larger players raising the
bar such that the smaller players aren't allowed to compete.

> Do you have a rough idea of when the CG plans to issue a report?

My understanding is that no such report is required - we're not an XG.
That said, anyone on this mailing list is free to volunteer and generate
such a report.

> Are you interested in covering a broad range of payment solutions
> such as those in the task force wiki?

It depends on what you mean by "covering" - we have certainly discussed
most of those solutions and are aware of them. We have minutes and audio
logs of those discussions here:

http://payswarm.com/minutes/

I think the group is very welcoming of the discussion of /any/ payment
technology and how it could potentially integrate with the Web. So yes,
the topics that can be covered in this group are broad and I think the
group desires to have a wide knowledge of each of those solutions.

Finding volunteers to write a report on each technology, however,
doesn't seem to be a priority (based on the work that people are doing
in this group and where the discussions have been focused).

If I had to think of somebody that would be best suited to write such a
document, I think it would be Pelle - he has an excellent handle on many
of these technologies. However, I'm pretty sure that his time is fairly
limited and he is focusing on OpenTransact at the moment.

> Some of these involve additional hardware such as dongles functioning
> as card readers, trusted computing modules such as SIM cards, and NFC
> readers. This is common for services tied to real world locations
> such as restaurants.

Yes, all interesting technology - but not at the core of Web Payments.
In general, if you end up needing an /additional/ piece of hardware to
use something core to the Web - we're doing something wrong.

> p.s. I personally have a only a limited amount of time I can devote
> to work on payments, and as such it would be difficult for me to be
> an active member of the CG, although I will be happy to jump in now
> and then.

We'd be happy for you to jump in from time to time (or more often than
that) as well.

I think it's difficult for many of us to commit to writing a report on
all of the payment solutions out there as we're all pretty busy with
solutions that are different than what's out there right now. I would
imagine that the market leaders out there right now would only really
support a technology that ensures that they continue to be a market
leader and thus interoperability is pretty far from their minds.

Finding a way for the smaller players in the market to compete with the
800lb gorillas in the room would probably be the best path to finding an
interoperability story here.

Many of us are focusing on what we feel is the most important thing at
the moment, and it's important to have a focus if we're going to end up
with a set of specifications that are workable. I'm concerned that
taking time to write a report on what we all know is already out there
would detract from that focus.

That is not to say that it's not important work - just that many of us
have already done that work and are past it at this point. And no,
writing what's in our heads wouldn't be a very easy exercise. :)

Perhaps the best approach might be for each of the solutions to explain
the features of their system on the wiki? We've already done this for
PaySwarm here:

http://manu.sporny.org/2011/web-payments-comparison/

We also have a list of use cases that we put together last year:

http://payswarm.com/specs/source/use-cases/

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/

Received on Friday, 11 May 2012 19:58:07 UTC