Webcredits

Draft Community Group Report

Latest editor's draft:
https://webcredits.github.io/spec/
Editor:

Abstract

The aim of this spec is not to exceed two pages.

Webcredits is an extremely simple way to model decentralized payments, balances and wallets on the world wide web, using Linked Data. This specification deals with credits between counterparites, a ledger that stores balances, and a wallet to allow discovery.

Status of This Document

This specification was published by the W3C Payments Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

This document in an informal draft discussed in the w3c web payments community group.

If you wish to make comments regarding this document, please send them to public-webpayments@w3.org (subscribe, archives).

1. Introduction

Most of the money in the world exists in the form of Credit. Yet there is no way to easily model a credit between counterparites on the web using Linked Data. This specification proposes a vocabulary and examples that model credits between two agents, which can also be used to send payments, building up a ledger of balances. In this sense, a modular kernel of an economy can be created while delegating other functions such as, authentication, signing, discovery and identity to other specifications.

1.1 Web Payments Community Group

Webcredits is one of several related specifications being discussed by the w3c web payments community group.

1.2 Overview

Figure 1 Overview of webcredits.

1.3 Vocabulary

The ontology / vocabulary is at https://w3id.org/cc. The prefix cc will be used in examples, which use the Turtle serialization.

1.4 Summary

Webcredits will show how to model ledgers, credits and wallets, the building blocks of financial systems.

2. Credits

Credits are the main class in webcredits. They represent a payment from one counterparty to another. This creates a change in the ledger.

2.1 Example

<#this> a cc:Credit;
cc:source <#alice> ;
cc:destination <#bob> ;
cc:amount 11.11 .

The Source indicates the source of the credit.

The Destination indicates the destination of the credit.

The Amount indicates the amount of the credit.

A cc:timestamp is an optional field of type xsd date

A cc:description is an optional field of type xsd string

A cc:currency is an optional field of type anyURI

3. Ledgers

A ledger is a two column list that contains a URI and a balance, or amount. Each Ledger will generally be linked to a wallet that contains the default currency.

3.1 Example

<#alice> cc:amount 1.23 .
<#bob> cc:amount 3.77 .

The Amount indicates the balance of the agent.

4. Wallets

A wallet is a container of a ledger, it is the authority by which the ledger is defined. It also will show how to find balances, and change the state of the ledger.

An API will typically be a self describing resource which will allow you to get the balance for a given user or recent transactions. Functions of the API SHOULD include getting a balance for a user, and list transactions for a user. Pagination is encouraged, but out of scope of this spec.

An inbox is where you POST a new credit which SHOULD return an HTTP 200 or 201 if accepted.

4.1 Example

<#this> a Wallet ;
cc:inbox <#inbox> ;
cc:currency <#mark> ;
cc:api <#api> .

The api shows where to get balances and add new credits.

The inbox shows where to send new web credits.

The currency is the default currency of that wallet.