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/

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

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 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.

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

TPAC/2013/session-web-payments