Re: The path forward for Web Payments

On 22 October 2013 13:10, Manu Sporny <msporny@digitalbazaar.com> wrote:

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

+1

One thing I'd like to see is a vocabulary that can describe the current set
of crypto currencies.  This would not need to go to a formal working group,
however.  Additionally I'd like to complete my two page mini spec on web
credits ( webcredits.org ), which should be a short introductory primer to
the larger payswarm work, again this would not need to be part of the WG.

Things I'd like to see modelled

Transfers (already part of commerce)
Balances and Ledgers
A block chain (this is a time stamped server of transaction blocks)
The ripple protocol

I've spoken to Arto Bendiken who well known in both the bitcoin and linked
data communities and he is interested on working on a vocab.  Few others in
the bitcoin or ripple community really are focussed on linked data
integration at this point.

But I would not want the work on ontologies to distract overly from the
workshop, charter or working group, so how would you suggest to proceed.


>
> -- 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/ <http://blog.meritora.com/launch/>
>
>