Re: implementations of "XML Voucher: Generic Voucher Language" ?

[Ian Grigg <iang@systemics.com>]

Ko Fujimura wrote:
> 
> Hi Rachel,
> 
> > Are you familiar with Systemics Ricardo system, which uses Ricardian
> > contracts to implement the concept that you call "vouchers"?
> >
> > <http://www.systemics.com>
> >
> > This system has been around for about 5 years and has been used in the
> > fields of currency, stocks and bonds. The use of "Ricardian contracts" or
> > "vouchers" is a critical part of the architecture.
> 
> Yes, I read his paper presented at FC'00 about one year ago. I like the design of
> the Ricardo system since it provides both flexibility and simplicity using modular
> software components.

Thanks!  The paper is at http://www.iang.org/papers/ and the
software mentioned is at http://www.webfunds.org/ .


> > We're in the process of integrating their Ricardo system into our
> > CashBox(tm) system, and I'm interested in knowing about any other companies
> > who may be implementing other payment systems based on these concepts, so
> > please do let me know when others do implement.
> 
> Our FlexTicket system is a smartcard-based value/rights circulation system and
> provides transferability and offline capability. There are more information on
> the protocols presented at CARDIS 2000.
> <http://info.isl.ntt.co.jp/flexticket/papers/>

I had a look through this yesterday and put some information
on the proposal, as an 'alternate' to our Ricardian contract
concept, up on the webfunds site:

    http://www.webfunds.org/guide/ricardian.html

What is very interesting to us is that we may be able to use
your formats for the Ricardian Contract in XML -- it is a future
task for us to convert to the XML world for all the normal
reasons.

(The comparison come across as a little unfavourable because
it tries to measure the Voucher against our own internal
contracting requirements, which are accepted as being quite
fierce!).

> Through the development of early version of this system, we learned importance
> of standardization of "contract" or "value description language" that describes
> what/how values/rights are traded between the trading partners.

Do you mean the term "contract" in its legal sense, or in the
information sense?  That is, the law of contract applies, or,
that the "contract" or interface is specified as per programming
needs?

If you mean the term in the sense of law and negotiating parties,
I would wonder how the Voucher could stand up to a dispute?  In
the Ricardian concept, we insist that the contract be readable
by humans, linked to the asset in question, signed by the Issuer,
and some form of open PKI in operation that provides evidence of
intention, and other devices to maintain the consistency of the
contract under a wide degree of circumstances.

(Although, we are mostly concerned with English common law contracts,
I haven't got a view as to how they stand up in other legal domains.)

> We are going to implement XML voucher as soon as it completed.

You may find the framework in WebFunds to be of interest.  There,
we have a contract browser that reads in the contracts, verifies
the signatures, and can display the text.  There is also a nice
contract signing wizard that takes you through the process of
doing your own contract.  It's early days yet, this is really an
automation tool rather than a replacement for the complicated
process of underwriting;  it doesn't give you enough help in order
to write your own contract, if just automates some of the tasks
that are bothersome.

> By the way, I think that generic value transfer protocols like the Ricardo' SOX
> protocols are exciting and important. But, I think it is difficult to cover all
> application area using one universal value transfer protocol. We therefore think
> that "contract" should contain a parameter that specify which the protocols
> (or "VTS provider" in XML Voucher) are used. I think it will help to develop
> generic digital wallet like your CashBox(tm).

That's an interesting point.  In our system, the identity of the
contract is provided by a canonical message digest (calculated
over the readable contract) which is used as the identifier in
payments.  There is nothing in the SOX protocol that limits the
usage to that digest, and nothing in the Ricardian Contract that
says which protocol to use (and indeed, it is possible to plugin
a separate payment system into WebFunds, and use Ricardian Contracts),
it's mostly an implementation issue.

However, there is ample flexibility in the contract format, and 
indeed, any similar format like your XML Voucher one, to add a
limitation of protocol.  That might become interesting in the
future as we are adding different transaction types to WebFunds
as a background task, and are using Ricardian Contracts in areas
that don't involve SOX directly.

-- 
iang