From Web Payments

Contents 1 Web Credits 1.1 Introduction 1.2 Authentication 1.3 Displaying a Wallet 1.4 Adding Transfers 1.5 JSON Messaging Format 1.6 Alternative Currencies 1.7 Discovery 1.8 ACL 1.9 Encryption 1.10 Conclusion 1.11 More Info

Web Credits

The way the Web spread was a piece at a time. So you could take html without taking http. So the failure of NEXT was a lesson, don’t try to sell it all at one time. Sell each piece on its own merits. Never insist that everybody take all. They will take all the pieces once they see how it fits together.

--Tim Berners-Lee

Introduction

• The aim of this spec is not to exceed 2 pages

• 95%+ of the money in the world is in the form of an IOU. A bank balance is an IOU from the bank to you, Cash is often an IOU from a govt. to an individual.

• Web Credits is an simple system for storing and transferring IOUs (credits) between agents.

• To goal of Web Credits is to be used as a simple kernel to create distributed payments, but to be arbitrarily extensible to add encryption, workflow, trust and aggregation systems of your choosing.

• The protocol is inspired by the Linked Data and PaySwarm standards, and is a usable subset that focuses on the data layer (JSON) and communication to apps (HTTP).

Authentication

• Authentication is out of scope of this spec, however, a number of techniques are listed on the linked page.
• It is assumed that the app is able to obtain a user URI after authentication.

Displaying a Wallet

• Applications are able to aggregate IOUs from one or more wallets, and display the totals for the user to see.
• Applications can be programmed for browsers, desktop, mobile and even the command line, all that is required is an HTTP interface.

• Example to get a list of IOUs to display in JSON:

     GET <Wallet URI>

Adding Transfers

• A transfer can be added generally using HTTP verb of POST with a JSON payload.
• POSTing to a wallet or notification area should add that IOU to the recipient's wallet (perhaps after approval)

• Example to write IOUs to an wallet:

     POST <Wallet URI> JSON

JSON Messaging Format

• The IOU structure specified is in JSON-LD
• JSON LD has the advantage of being self documenting and fully namespaced to allow distributed scaling
• While only JSON is covered in this spec, the flexibile nature of web architecture allows messaging and storing to be extended to different serializations using MIME types and RESTful services. These techniques are not covered in this spec, but may be documented on request.

    {
      "@context": "http://purl.org/commerce/context",

      "@id": "#1234567890",
      "@type": "http://purl.org/commerce#Transfer"

      "source": "http://melvincarvalho.com/#me",
      "amount": "5.00",
      "currency": "EUR",
      "destination": "http://webr3.org/nathan#me",
      "comment": "Just a test IOU",
      "created": "2011-12-20T15:42:41.030Z",
    }

• IOU Format
  • Source is any URI representing the source of the transfer
  • Amount is the size/quantity of the amount owed
  • Currency can be any URI or 3 letter ISO code
  • Destination is any URI representing the destination of the transfer
  • Comment is an additional description
  • Created is a timestamp indicating the IOU was created
  • The id should be a unique id representing the transaction. A sha256 of the canonical form is suggested.

• Notes
  • All fields are mandatory
  • The definition of a URI (anyURI) is not covered in this spec, but deferred to web architecture
  • As linked data is based on the notion of a set, different IOUs should have varied data such as a distinct timestamp, description or ID, to ensure uniqueness.
  • Any web or file system cable of delivering json can be used as a wallet. It is possible to use WebDAV stores, DB's such as couch / mongo. A file system such as TahoeFS or a SCM system such as github.

Alternative Currencies

• Currencies such as time banks, bitcoin, virtual items and karma are supported.
• In fact any user generated currency or personal currency mint can be added as a URI.

Discovery

• Discovery of a user's wallet is outside of the scope of this spec. Possibilities are linked to this page, examples will be provided in a Primer Document (coming soon)
• It should be possible to discover one or more wallet URIs for a user from their user URI.

ACL

• Access Control is again out of scope of this document, but encouraged that wallets are secured by a similar mechanism as auth.
• Example workflows will be added to a primer document illustrate examples of how to do this.

Encryption

• Encryption and signatures are out of scope but can be layered on top of the base protocol.
• Examples of encrypted json and digital signatures can be found in a PaySwarm Web Key spec. and elsewhere

Conclusion

• Web Credits aims to minimally use web standards (HTTP, JSON-LD, Linked Data, PaySwarm) in order to iteratively develop working applications that use the system.
• This is an skeleton draft that hopefully will be fleshed out further to provide both a developers guide together with a reference implementation.

More Info

Money... how it works. http://www.youtube.com/watch?v=CI5CFQXJxcA