[Webfunds-commits] html/guide ricardian.html
Ian Grigg
iang@cypherpunks.ai
Fri, 2 Mar 2001 17:16:26 -0400 (AST)
iang 01/03/02 17:16:25
Modified: guide ricardian.html
Log:
added form, requirements and alternate (vouchers)
Revision Changes Path
1.3 +300 -3 html/guide/ricardian.html
Index: ricardian.html
===================================================================
RCS file: /home/webfunds/cvsroot/html/guide/ricardian.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ricardian.html 2000/07/05 14:28:52 1.2
+++ ricardian.html 2001/03/02 21:16:25 1.3
@@ -13,9 +13,70 @@
yet to be seen or incorporated.
</p>
-<h2>Reading</h2>
+<h2><a name="form">Form</a></h2>
<p>
+In the simplest possible terms, a Ricardian Contract
+is an Ini-formatted document that is both human readable
+and program parsable. It identifies a Legal Issuer
+and an Issuance Server, and includes OpenPGP keys for
+those parties. The document is signed in OpenPGP cleartext
+form by the Legal Issuer's contract signing key.
+</p>
+
+<p>
+A unique identifier is formed by a canonical message digest
+(hash) which provides an unforgeable link to the accounting system.
+</p>
+
+<h2><a name="goal">Goal</a></h2>
+
+<p>
+The mission of the Ricardian Contract is to provide a
+document that can be a <i>primary</i> contract for the
+issuance of a digital asset.
+</p>
+
+<ul><li>
+
+<p>
+As a contract, parties to the contract must be identified,
+and signatures affixed. It should look and feel like a contract.
+</p>
+
+</li><li>
+
+<p>
+There is no other document. A lawyer, judge or arbitrator
+can unambigiously work with the Ricardian Contract in order to
+resolve disputes. As these parties prefer to work with the
+source document, it must be the primary.
+</p>
+
+</li><li>
+
+<p>
+The document must describe the digital asset, and this must
+be parsable by programs.
+</p>
+
+</li><li>
+
+<p>
+Issuance implies that other parties, roles within the issuance,
+must be identified, and thus
+signatures and authentication must be included.
+</p>
+
+</li></ul>
+
+<p>
+See below for more.
+</p>
+
+<h2><a name="dox">Reading</a></h2>
+
+<p>
Documentation is a little scattered. Here's some from the
various Systemics' sources:
</p>
@@ -42,11 +103,64 @@
FC in 7 layers</a>
is a broad, sweeping architectural model that in one tiny
section, discusses how contracts fit into the whole FC context.
- Read the full paper quickly, and concentrate on the (small)
- Static Governance section, about half way down.
+ Read the full paper quickly, and concentrate on the
+ Example's Value section and the next
+ Static Governance subsection,
+ about half way down.
</li></ol>
+<p>
+You can find some
+<a href="http://www.webfunds.org/ricardo/contracts/">
+examples of Ricardian Contracts</a>
+on our site. WebFunds.org does not endorse these, so
+don't put your money where our mouth is.
+</p>
+
+<h2><a name="requirements">Requirements</a></h2>
+
+<p>
+The requirements for a Ricardian Contract can be specified as
+</p>
+
+<ol><li>
+ Human parsable
+ </li><li>
+ Program parsable
+ </li><li>
+ Represents a contract
+ </li><li>
+ Can be identified uniquely
+ </li><li>
+ Signed by Issuer
+ </li><li>
+ All pertinant information in one single document
+ </li><li>
+ Document is printable
+ </li><li>
+ All forms (displayed, printed) are manifestly equivalent
+ </li><li>
+ Supported by financially capable PKI (such as OpenPGP)
+ </li><li>
+ Extensible
+ </li><li>
+ Identifies Legal Issuer (signer of contract)
+ </li><li>
+ Identifies Issuance Server (accounter of contract)
+ </li><li>
+ Unchangeable by Legal Issuer or other parties
+ </li><li>
+ Supports content verifiability
+</li></ol>
+
+<p>
+As a brief list. There doesn't appear to be a document
+that defines the Ricardian Contract, just documents on
+how to use them
+(<a href="#dox">above</a>).
+</p>
+
<h2><a name="terms">Terms</a></h2>
<p>
@@ -105,6 +219,189 @@
<p>
So, DigiGold might be an instrument, a contract, and an item,
depending on the context...
+</p>
+
+<h2><a name="alternates">Alternates</a></h2>
+
+<p>
+Up until recently, the idea of Ricardian Contracts has not
+been copied or independantly developed as far as we know.
+Even though the concept was announced as far back as 1996,
+and source code was made available in Feb of 1997, interest
+in applied Financial Cryptography, and how to describe real
+assets, has not arisen until lately.
+</p>
+
+<h3><a name="alternates">Voucher Trading</a></h3>
+
+<p>
+One recent development is the
+<a href="http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-lang-00.txt">
+Voucher definition</a>
+published by
+Ko Fujimura
+<<a href="mailto:fujimura@isl.ntt.co.jp">
+fujimura@isl.ntt.co.jp</a>>
+and Masayuki Terada
+(both from NTT, Japan)
+as an Internet Draft:
+</p>
+
+<pre>
+ Title : XML Voucher: Generic Voucher Language
+ Author(s) : K. Fujimura
+ Filename : draft-ietf-trade-voucher-lang-00.txt
+ Pages : 8
+ Date : 21-Feb-01
+
+ This document specifies rules for defining voucher properties in
+ XML syntax. A voucher is a logical entity that represents a right
+ to claim goods or services. A voucher can be used to transfer a
+ wide-range of electronic-values, including coupons, tickets,
+ loyalty points, and gift certificates, which are often necessary to
+ process in the course of payment and/or delivery transactions.
+
+ A URL for this Internet-Draft is:
+ http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-lang-00.txt
+</pre>
+
+<p>
+This is part of a "generic value circulation system"
+that is further described in a set of requirements for
+<a href="http://www.ietf.org/internet-drafts/draft-ietf-trade-drt-requirements-02.txt">
+Generic Voucher Trading</a>:
+</p>
+
+<pre>
+ Title : Requirements for Generic Voucher Trading
+ Author(s) : K. Fujimura
+ Filename : draft-ietf-trade-drt-requirements-02.txt
+ Pages : 11
+ Date : 15-Feb-01
+
+ In purchase and other trading transactions, it is often required to
+ credit loyalty points, collect digital coupons or gift certificates,
+ and so on. These activities can be generalized using the concept of
+ a 'voucher', which is a digital representation of the right to claim
+ goods or services.
+
+ A URL for this Internet-Draft is:
+ http://www.ietf.org/internet-drafts/draft-ietf-trade-drt-requirements-02.txt
+</pre>
+
+<p>
+(Ricardo pretty much meets the requirements above.)
+</p>
+
+<p>
+As far as voucher trading goes, the requirements need not be as stringent
+as for money or asset systems, but the effective nature of the
+system is equivalent. Indeed, the Voucher ID mentions stocks and bonds
+at one place, so maybe the system is headed there.
+</p>
+
+<p>
+In terms of the contrast between Ricardian Contracts
+and Fujimura/Terada Vouchers,
+there appear to be these :
+
+</p>
+<p></p>
+
+<table border=1>
+
+<tr bgcolor="#FFFFDD">
+ <td> <b>Feature</b>
+ </td><td> <b>Ricardian Contracts</b>
+ </td><td> <b>Vouchers</b>
+ </td><td> <b>Comments</b>
+ </td>
+
+</tr><tr>
+ <td bgcolor="#FFFFF0">Signature
+ </td><td> OpenPGP cleartext
+ </td><td bgcolor="#FF8800"> (external)
+ </td><td> suggests XMLDSIG
+ </td>
+
+</tr><tr>
+ <td bgcolor="#FFFFF0">PKI
+ </td><td> OpenPGP
+ </td><td bgcolor="#FF8800"> (external)
+ </td><td> no requirements
+ </td>
+
+</tr><tr>
+ <td bgcolor="#FFFFF0">Format
+ </td><td bgcolor="#FF8800"> Ini/custom
+ </td><td> XML
+ </td><td> XML is much better
+ </td>
+
+</tr><tr>
+ <td bgcolor="#FFFFF0">Identifies parties
+ </td><td> yes
+ </td><td> yes
+ </td><td> Legal Issuer, Issuance Server
+ </td>
+
+</tr><tr>
+ <td bgcolor="#FFFFF0">Extensible
+ </td><td> yes
+ </td><td> yes
+ </td><td> Allows other types of instruments
+ </td>
+
+</tr><tr>
+ <td bgcolor="#FFFFF0">Separates value from contract
+ </td><td> yes
+ </td><td> yes
+ </td><td> Units are accounted for in parent Payment System
+ </td>
+
+</tr><tr>
+ <td bgcolor="#FFFFF0">Provides Unique Identifier
+ </td><td> yes
+ </td><td bgcolor="#FF8800"> no
+ </td><td> how to identify the document with no ambiguity and no change
+ </td>
+
+</tr><tr>
+ <td bgcolor="#FFFFF0">program-parsable
+ </td><td> yes
+ </td><td> yes
+ </td><td>
+ </td>
+
+</tr><tr>
+ <td bgcolor="#FFFFF0">human-parsable
+ </td><td> yes
+ </td><td bgcolor="#FF8800"> maybe
+ </td><td> can humans read the document without confusion?
+ </td>
+
+</tr><tr>
+ <td bgcolor="#FFFFF0">Contractual
+ </td><td> yes
+ </td><td bgcolor="#FF8800"> no
+ </td><td> lacks defined signature, PKI, human parsability, unique id
+ </td>
+
+</tr><tr>
+ <td bgcolor="#FFFFF0">Implementation
+ </td><td> yes
+ </td><td> no
+ </td><td>
+ </td>
+
+</tr></table>
+
+<p> </p>
+<p>
+As a contract in the terms that the Ricardian Contract
+attempts to meet, the Voucher does not succeed. However,
+it may be that we can use the Voucher ID as the starting
+point for the future XML format for the Ricardian Contract.
</p>
</body></html>