Warning:
This wiki has been archived and is now read-only.

Web Credits

From Web Payments
Jump to: navigation, search

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
  • Web Credits is an simple system for storing and transferring credits between agents (denoted using URIs). Credits are a numerical amounts that are currency agnostic.
  • The 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.

Web Credits Format

  • The Credit structure specified is RDF. Turtle and JSON-LD SHOULD be supported.

Example JSON-LD for a Credit

    {
      "@id": "#1234567890",
      "@type": "https://w3id.org/cc#Credit"
      "https://w3id.org/cc#source": "https://melvincarvalho.com/#me",
      "https://w3id.org/cc#amount": 5
      "https://w3id.org/cc#currency": "https://w3id.org/cc#bit",
      "https://w3id.org/cc#destination": "https://www.w3.org/People/Berners-Lee/card#i",
      "https://w3id.org/cc#description": "Just a test Credit",
      "https://w3id.org/cc#timestamp: "2011-12-20T15:42:41.030Z",
      "https://w3id.org/cc#context: "https://example.org/pizza",
    }
  • Key
    • The @id should be a unique id representing the transaction. A sha256 of the canonical form is suggested.
    • 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
    • description is an additional description
    • timestamp is a timestamp indicating the Credit was created
    • context is optional and provides a pointer URI as to why the credit was created

Example JSON-LD for a Balance

    {
      "@id": "https://melvincarvalho.com/#me",
      "https://w3id.org/cc#amount": 15
    }

This is a short form 'unqualified' relation that is used for simplicity. It can be extended to include more feels in more complex scenarios, as needed.

The Wallet

  • The wallet is the container of the ledger, the transactions and meta data.
  • Typically to get the meta data you would use
     GET <Wallet URI>
  • While it is possible to store all data in the wallet it is normally easier to use an API to access the data.

Discovery

  • It should be possible to discover one or more wallet URIs for a user by dereferencing their user URI.
  • Wallets will also typically give an inbox and a RESTful API URI for convenience. Each API will have its own documentation.

Creating Web Credits

  • A wallet will generally have an inbox that new credits can be posted to
     POST <inbox> <webcredit>
  • After the POST you will be notified of the successful transaction added to the ledger
  • It will often also be possible to POST a credit to an API

Currencies

  • Web Credits are currency agnostic. 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.
  • If no currency is present, the default is set to bitcoin (bits).

Conclusion

  • Web Credits aims to minimally use web standards (HTTP, JSON-LD, Linked Data) 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

Out of scope

  • Authentication is out of scope of this spec, however, a number of techniques can be used to authenticate a URI. WebID+TLS SHOULD be supported.
  • Access Control is out of scope of this document, but encouraged that wallets are access controlled, using a similar mechanism as authentication. Ledgers are by default public, but due to large volume may be delivered in pieces.

Implementations