The path forward for Web Payments

Hi all,

Discussion on this mailing list has picked up quite a bit as of late and
we're starting to cover a very diverse set of topics. That's great, as
it shows that this group is bringing a great deal of different
perspectives into the work that we do here.

The diversity of discussion is not without its drawbacks. During my
visits with the larger tech companies and organizations on this list (in
NYC, Silicon Valley, and Bali), it's becoming apparent that the variety
of discussion is also creating some amount of confusion over the
direction of the Web Payments work.

We're also approaching a deadline, which is the creation of the charter
for the Web Payments group. We're going to need to propose /something/
at the February 2014 workshop on Web Payments in Paris. We're also going
to need to start converging on some set of proposals that we think
should be input documents into the Web Payments Working Group.

What follows is a rough proposal based on the specifications that we
have right now that could be input documents to the Web Payments WG.
Keep in mind that this is just a proposal and nothing is set in stone.
The proposal is broken into 3 broad categories: specs that are almost
done, specs that could be drafts, and specs that we need to create.

Specs that are almost done
--------------------------

In general, these specs were created out of necessity for the Web
Payments work. There are other groups that were capable of progressing
the work faster than we could here, so in each case, a number of us from
this group joined the other groups to progress the work there. These
specs would not be included in the Web Payments WG charter, but are very
relevant to the work that this group is doing.

RDFa 1.1 - Technically, RDFa 1.1 is done and shipped. We needed RDFa to
express products in a decentralized way on the Web. There could be
improvements made to RDFa, like the addition of a @graph keyword to
support graph signing, but it's not required for any of the specs we're
working on right now.

JSON-LD - This spec passed the Candidate Recommendation phase at the W3C
last week and will most likely proceed to Proposed Recommendation soon.
It'll be another month for voting after it enters PR, but if the votes
are good, then it'll be an official Recommendation six weeks after it
enters PR. We use JSON-LD to express identities, products, transactions,
contracts, and in general, all PaySwarm messages are built on top of
JSON-LD.

HTTP Signatures - This spec is waiting on the examples to be updated. I
just haven't found the time to do it and publish it via IETF. The
technical stuff in the spec has been done for some time, and we have two
implementations. HTTP Signatures are used over HTTPS for programmatic
access to PaySwarm payment processor REST APIs.

Specs that could be drafts
--------------------------

These specifications are being actively developed, either in this group
or another group. The specs have an editor and implementations that are
being actively developed. These would be in the set of work that the
first generation Web Payments WG would work on.

HTTP Keys - a secure and verifiable messaging mechanism built using
Linked Data principles to produce a distributed Public Key
Infrastructure for the Web. We need to update this spec to match current
implementations, but a good enough chunk of it is there and could easily
become a first draft of an official W3C WG.

RequestAutocomplete - a mechanism of auto-filling form data with things
like credit card information, address information, etc. Google is
probably not going to have much of an issue putting this through W3C via
Web Apps, but the Web Payments group could be another venue that they
could use to publish the specification.

Web Payments - the base layer of the PaySwarm architecture; enables the
creation of a monetary transaction between two participants on the Web.
Again, the spec is badly out of date, but it wouldn't take that much
work to bring it up to date with the current implementation and produce
a first draft for an official W3C WG.

Web Commerce - the electronic commerce portion of the PaySwarm
architecture; enabling the decentralized listing of assets for sale and
the transaction of those assets resulting in a digitally verifiable
receipt between the buyer and the vendor. Same as above. Specs out of
date, needs to be updated based on current implementation.

Specs that we need to create
----------------------------

Payment Intents - the parameterized transactions layer of the PaySwarm
architecture; enables decentralized crowd-funding for innovative
initiatives and projects. We need to re-think this specification. We do
want to support crowdfunding as a first-class function of a Web Payments
solution. However, with the advent of Ripple, the way that we go about
that might be different than when we wrote this specification.

RDF Graph Normalization - At times, it becomes necessary to compare the
differences between graphs, digitally sign graphs, or generate short
identifiers for graphs via hashing algorithms. This spec outlines an
algorithm for normalizing RDF graphs such that the previously described
operations can be performed on the normalized graphs. This is necessary
for the HTTP Keys spec to work as well as any of the digitally signed
messages for the PaySwarm specs to work. The algorithm is horribly out
of date and needs to be updated, and unfortunately, that's going to be
very time consuming due to the complexity of the deterministic graph
node/edge sorting algorithm.

Web Identity - this specification describes how you do Know Your
Customer using the HTTP Keys specification. It would describe how you
read and write information to a PaySwarm identity (or any identity URL).
It would also seamlessly integrate into Mozilla Persona such that you
could login with Persona and then the website could request extra
information from the identity owner such as shipping address, government
issued ID card data, etc. It's somewhat of a competing spec to
RequestAutocomplete, but given that it only exists in a few people's
heads right now, it's going to take some work to get the first draft of
it ready for consumption.

Secure Frame - This is the direction that the MozPay specification seems
to be taking. This approach was suggested by Kumar and would be used to
create a whitelisted payments/secure exchange dialogue that would be
very difficult to spoof by attackers. This dialogue could be used by
payments companies to implement proprietary as well as open buyflows.

External Payment Initiation - We've been talking with a few
organizations that do payments that would like a way to initiate a
payment within the browser and then hand the transaction execution off
to an external application. The general concept needs to be worked out,
and we need to find editors for this specification. If we can get
something together for this in the next 4 months, we stand a good chance
at getting a first draft ready before the Web Payments WG is chartered.

------------------------------------------------------------------

The general plan for this group would be to propose that the specs that
could be drafts would be included in the work that the Web payments
group does. A subset of the specs that we still need to create would be
included in the charter as optional deliverables if we can find editors
for those specifications and we get a good first draft done in the next
3-4 months.

So, what did I miss or exclude that probably should be included? There
is a lack of Bitcoin-related specs only because we haven't had anyone
from the Bitcoin community step forward and propose a set of specs to
take through W3C. The same applies for Ripple at this moment in time.

Are there any specs that should be added? Should some be removed?
Thoughts and general debate on the direction would be appreciated at
this point. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Tuesday, 22 October 2013 12:08:47 UTC