View source for TPAC/2013/session-web-payments

= Overview =

Discuss the role of W3C in the creation of a set of value-exchange (payment / crowdfunding / P2P finance) standards for the Web, consider PaySwarm, Bitcoin, Ripple and other emerging technologies.

= Introductory Info =

Short URL to this page: http://bitly.com/tpac-wp

IRC: irc.w3.org:6665 #webpayments

Slides: https://payswarm.com/slides/2013/w3ctpac-web-payments/

Use Cases: https://payswarm.com/specs/source/use-cases

Specs: http://payswarm.com/specs/

= Suggested Topics =

* Industries - Banking and Financial Sector, Payment Processors, Mobile Network Operators, Retail, Governments
* Identity - Secure Messaging/HTTP Keys, Persona
* Security - Web Crypto API, Secure Elements API, HTTP Signatures
* Product Discovery - Web Commerce spec
* Digital Receipts - Web Payments spec / Web Commerce spec
* Financial Backhaul - Bitcoin, Ripple

= Questions to Consider =

* Should we create a Working Group for this work?
* Which specs are of interest to the break-out attendees? Any volunteers to help develop/edit the documents?
* Should the SysApps Secure Element API be a part of this work? Who will coordinate?
* Should the Web Crypto API be a part of this work? Who will coordinate?
* Should the NFC API be a part of this work? Who will coordinate?
* Should Web and Mobile IG be a part of this work? Who will coordinate?
* How should we coordinate with the Broadcast IG, Digital Publishing IG, and the Web and TV BG? Who will coordinate?
* Are we missing anything on the list of things we should be looking at?

= Reference Info =

In general, we had to create a number of base level specs 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.

== Specs that are almost done ==

[http://www.w3.org/TR/rdfa-syntax/ 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.

[http://www.w3.org/TR/json-ld/ 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.

[https://payswarm.com/specs/source/http-signatures 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.

[https://payswarm.com/specs/source/http-keys 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.

[http://www.chromium.org/developers/using-requestautocomplete 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.

[https://payswarm.com/specs/source/web-payments 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.

[https://payswarm.com/specs/source/web-commerce 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 we need to create ==

[https://payswarm.com/specs/source/payment-intents 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.

[http://json-ld.org/spec/latest/rdf-graph-normalization/ 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.

Ripple - Do we need to create a spec for the Ripple protocol? Should the work happen in the IETF?

Bitcoin - Does the Bitcoin community want a spec published via W3C? Should the work happen in the IETF?

= Attendees =

* Mountie Lee
* Mete Balci
* Dave Raggett
* Virginie Galindo
* Takahiro Sakai
* Keiji Yanagiuchi
* Kazuhiro Hoya
* Hayato Ozawa
* Art Barstow
* Karen Myers
* Christian Fuhrhop
* Mohammed Dadas