OpenTransact Coredraft-pelle-opentransact-core-02

Abstract

This document specifies the OpenTransact standard for requesting and performing transfers of assets over the http protocol.

Status of this Memo

This Internet-Draft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as “work in progress.”

This Internet-Draft will expire on July 13, 2012.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

1.
Status of Document

2.
Introduction

The goal is to develop a very simple low level standard for transferring an amount of an asset from one account to another.

Most payment systems and existing standards use the messaging paradigm for historical reasons. OpenTransact specifically rejects the message paradigm and prefers the RESTful (REpresentational State Transfer) resource approach as used on the web with URL’s and HTTP at it’s core.

We aim to create a new standard from scratch ignoring all legacy systems, while leaving it flexible enough to allow applications built on top of it to deal with legacy systems.

The standard is designed to follow standard RESTful practices and be concise and human readable.

2.1.1.
Asset Service

An Asset Service is a service maintained by an organization to manage accounts of one asset. For money and other financial assets the Asset Service would normally be run by a Financial Service Provider of some type. Other types of assets are offered by non-financial services. The regulatory definition of “financial” is of course out of the scope of this document.

2.1.2.
Transaction URL

Each Asset Service has a unique transaction URL. An informal convention is developing, but is out of the cope of this document. Guidance concerning the form of these URLs with regard to specific details like currency, card type, size, color MAY become available in a future Best Current Practices document.

The service available at the transaction URL MUST follow basic REST practices:

A transaction URL such as https://paymentsarewe.example.com/prwpoints MUST NOT contain query or fragment part.

Loading the URL into a normal web browser should present a human readable description of the asset.

A POST to the URL is used for creating a transaction transferring value.

A GET to the URL from a normal web browser with specific parameters becomes a payment request that the user can authorize.

A GET to the URL in a machine readable form such as json returns meta data about the asset and optionally a list of transactions that the current user is allowed to see.

Each transaction has a unique URL. This SHOULD be formed by appending a unique transaction identifier to the transaction URL, such as https://paymentsarewe.example.com/prwpoints/aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d.

2.1.3.
Example of Asset Services

Lets say it’s an imaginary electronic currency asset provider eepay.example.net they only offer one asset type, their currency. So they would only have one transaction url:

http://eepay.example.net/transactions

If the asset provider offered multiple currencies it should have a url for each currency as they are really separate asset types:

http://eepay.example.net/transactions/usd

http://eepay.example.net/transactions/euro

A bank offering OT as an alternative to ACH service could have a tranaction URL for each of the currencies in which it offers checking accounts. The details of interbank settlements are out of the scope of this document.

http://coolbank.example.com/current

http://coolbank.example.com/savings

http://coolbank.example.com/bonds/mortgage

A mutual fund company would have a url for each of their funds.

http://fidelify.example.com/funds/sp500

http://fidelify.example.com/funds/emergingmarkets

With relaxation of current regulations on brokerage transactions all going through markets, a broker (rather, a stock market) could implement an OpenTransact API and have a different URL for each symbol.

http://nyex.example.com/trade/AAPL

http://nyex.example.com/trade/EBAY

This would ease the barrier to registered securities being used directly as money.

If we let the URL do the describing, there are many different possibilities. This allows support for all manners of asset types.

All the above examples are fungible assets. In general it is best practice that one item of value for one asset is fungible for one another.

For unique items such as domain names, property titles and diamonds that are unique and infungible, we can still create asset urls for each item, but only accept transfer amounts of 1.

All the above examples are fungible assets.

For unique items such as domain names, property titles and diamonds that are unique and infungible, we may define a separate currency for the item representing partial ownership. The legal framework for defining the resulting partnerships and their governance is out of scope of this document.

2.1.4.
Derivative Assets

A Derivative asset is an asset that is based on the current asset but provides different semantics and business rules.

Examples:

Reserves/Escrows

Subscription services providing recurring billing

Exchanges providing exchange of asset with another asset

It is out of scope to define here exactly how these would work, but the OpenTransact community will build a list of recipes for how to implement these and may publish further drafts outlining specifics in the future.

2.4.
Transfer Request

A Transfer request is when the Transferee requests a transfer of a given amount of an asset from the Transferer.

Eg. Alice sends an invoice to Bob for $12. This is a Transfer Request from Alice to Bob where Alice is the Transferee and Bob the Transferer.

A Transfer Request is simply a specially formatted payment link that takes Bob to Asset Service if followed. The Asset Service shall present the Transfer Request to Bob who can authorize or decline it.

2.5.
Transfer Authorization

A Transfer Authorization is when the Transferee or a third party application requests an authorization to transfer of a given amount of an asset from the Transferer.

Eg. Bob wants to hire someone on an online job board to edit a document for $33. The Job Board creates a Transfer Authorization link. Bob follows this link to the Asset Service and authorizes the Job Board to transfer $33 from his account to some one else within a time period.

A Transfer Request is simply a specially formatted payment link that takes Bob to Asset Service if followed. The Asset Service shall present the Transfer Request to Bob who can authorize or decline it. If Bob authorizes it the Asset Service issues an authorization code to the Job Board that they can use to exchange for an OAuth token.

2.6.
Exchange Transaction

A Transfer is often but not always part of an exchange of value between 2 types of assets. Eg.:

10 consulting hours exchanged for 1100EUR

10 USD exchanged for 8 EURO

0.99 USD exchanged for an mp3 song

There are as many different exchange mechanisms for creating exchanges as there are exchange types.

Invoicing system

App Store

Web shop

Auction site

Stock Exchange

It is outside the scope for OpenTransact to define every single type of exchange that is possible. OpenTransact provides a fundamental building block in building such systems. It integrates well with exchange systems that don’t yet understand OpenTransact.

3.
Transfer Request

We use the following parameters from our common vocabulary. All fields are optional:

to Account identifier of Transferee. If left out it defaults to the 3rd party applications own account on Asset Service or a predefined account as specified when authorizing the access token.

amount Amount as a number with decimal points. Symbols are allowed but SHOULD be ignored. If left out it defaults to the Asset’s minimum transfer, 1 or an amount predefined when authorizing the access token.

note Textual description, which can include hash tags. Asset Service may truncate this. No default.

from Account identifier of Transferer. This should normally be left out as it is implied by the authorizer of the Access Token. The Asset Service MUST verify that the Access Token is authorized to transfer from this account. This could be useful for Asset providers charging their customers accounts.

for URI identifying the exchanged item.

redirect_uri URI for redirecting client to afterwards

callback_uri URI for performing a web callback

When a user follows this link, the Asset Service should present the user with a form authorizing the payment.

We use the following parameters from our common vocabulary. All fields are optional:

to Account identifier of Transferee. If left out it defaults to the 3rd party applications own account on Asset Service or a predefined account as specified when authorizing the access token.

amount Amount as a number with decimal points. Symbols are allowed but SHOULD be ignored. If left out it defaults to the Asset’s minimum transfer, 1 or an amount predefined when authorizing the access token.

note Textual description, which can include hash tags. Asset Service may truncate this. No default.

from Account identifier of Transferer. This should normally be left out as it is implied by the authorizer of the Access Token. The Asset Service MUST verify that the Access Token is authorized to transfer from this account. This could be useful for Asset providers charging their customers accounts.

Intervals are either 2 ISO Dates or an ISO date and a duration separated by the ‘/’ character:

2007-03-01T13:00:00Z/2008-05-11T15:30:00Z # The interval between 2 dates
2007-03-01T13:00:00Z/P1Y2M10DT2H30M # The interval starting at a date and finishing after a duration
P1Y2M10DT2H30M/2008-05-11T15:30:00Z # The interval starting with a duration and finishing at a given date
P1M # The duration starting at the time the token was authorized.

Figure 4

Repeating intervals by prefix one of the above intervals or durations with the letter ‘R’ and an optional number specifying the amount of times to repeat:

RP1M # repeat once a month
R12P1M # repeat 12 times once a month
RP1M/2008-05-11T15:30:00Z # repeat monthly until a given date

Figure 5

By supporting a single parameter with any of the above durations/intervals/repeated intervals we can support a lot of different kinds of applications:

Recurring payments (subscriptions) using the Repeated Intervals

Daily spending limits on tokens using Repeated intervals similar to what debit cards have to day. eg. $300/day

We use the following parameters from our common vocabulary in 1.6. All fields are optional:

to Account identifier of Transferee. If left out it defaults to the 3rd party applications own account on Asset Service or a predefined account as specified when authorizing the access token.

amount Amount as a number with decimal points. Symbols are allowed but SHOULD be ignored. If left out it defaults to the Asset’s minimum transfer, 1 or an amount predefined when authorizing the access token.

note Textual description, which can include hash tags. Asset Service may truncate this. No default.

from Account identifier of Transferer. This should normally be left out as it is implied by the authorizer of the Access Token. The Asset Service MUST verify that the Access Token is authorized to transfer from this account. This could be useful for Asset providers charging their customers accounts.