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

[Todd Boyle <tboyle@rosehill.net>]

I would like to point out the unmet need in the webledger space,
for any practical or standard technique by which a subscriber
might issue securitized payables obligations.

A webledger is a general accounting platform that runs in a
browser, and is only one of a large category of web apps in
which subscribers buy stuff or form accounts payable liabilities
of some sort.

At present, the banking industry (and a ravenous horde of billing
and payments solutions hardwired to the banking industry) are
pushing all kinds of **payment** solutions, i.e. crap that makes
you push every settlement thru a bank someplace.

There is considerable awareness in the webledger communities
that intercompany journal entries can be used to perform very
simple, well-understood balance sheet transfers to reassign
payables and receivables, from one party to another in your
ledger i.e. zero out all your payables or receivables and
send the information to a settlement agent.  This is obviously
an appealing idea to most small businesses if issues can be
put to rest regarding cost, trust, confidentiality and so forth.

Your role, as cryptologist is to show the webledger community
your least-common-denominator, absolutely common-sense software
algorithm and workflow for securitizing payables.  You need an
object that accepts rows of accounts payable ledger in some
standard such as OMG GL or emerging OMG AR/AP schemas, and
signs them somehow to be nonrepudiable by the issuer and prevents
double-spending.

The vision is that a recipient such as a settlement agent, will
receive a bundle of signed payables from a particular party,
such as MyWebledger:Subscriber234234 and there would be some
kind of protocol to contact MyWebledger over the intenret,
making MyWebledger, in effect, the host to prevent doublespending.
After a bit of round-trip verifying, the settlement agent would
have some measurable improvement in confidenc that the payable
was bonafide and hasn't been a complete fraud.   Yeah I know,
crackers might still find a hole.  Well, that's ok. This is
way better than sendnig GL rows in the clear over a VPN connection
or something-- all the solutions are nonstandard, today.

Another deliverable from this project might be that the
securitized payables message optionally, is encrypted to
be readable only by the intended addressee.  THe preferred
application however, is a free-for-all in which reputable
small businesses issue their own money and we all trade using
that money.  Obviously the large corps will collude to not
use this system but small businesses operate under different
incentives and cost pressures.

Finally, the receiver's object would extract, from the securitized
payables, the sets of accounts payable rows in ledger format
so that they can be managed and processed by the AR/AP system
of the receiver.

TOdd

-----Original Message-----
From: dbs@philodox.com [mailto:dbs@philodox.com]On Behalf Of Ian Grigg
Sent: Friday, March 09, 2001 6:44 PM
To: Ko Fujimura
Cc: Rachel Willmer; dbs@philodox.com; ietf-trade@lists.elistx.com
Subject: Re: implementations of "XML Voucher: Generic Voucher Language"
?


<snip>
> By the way, I'm studying how to write your bond and currency defined
> in <http://www.systemics.com/docs/ricardo/issuer/contract.html>
> in XML voucher.

Great!  Let me know when you're ready to issue :)

> I think some of properties of the contract do not have to be interpreted
> by the program and they are defined only for clarifying its legal meaning.
> In case of bond, for example, bond_face, bond_currency, and
> bond_maturity_date are needed to be processed especially when it is
> redeemed. But, bond_issue_date and bond_total_issue_number seem to be
> defined only for clarifying its legal meaning, am I right?

That's correct - the intention is to let a bond
writer put in the fields he wants, and guide the important
fields with conventions.  Obviously, things like face and
maturity are needed so that calculations can be done.  The
addition of the issue_date, etc, is simply there to complete
the full set of data, not because a program can use them.

IMHO, there is no useful meaning to a Ricardian contract
"conforming" to a particular layout such as that described
for bonds.  Every bond is different, and there is no good
reason to make them all the same.  What will happen over
time is that new bonds will introduce new tags, and software
vendors will be encouraged to interpret these extra fields
according to their usefulness.

(Another thing to bear in mind is that the bonds area, whilst
the original genesis of the Ricardo project, has not been
used since the early days.  We've done most of the last 3
years doing commodity currencies (precious metals) and are
currently experimenting with shares and national currencies.)

> I think that we do not have to introduce specific tags for these
> properties which are not interpreted by the software, since it is
> sufficient to write them in a plain text in "one" XML element such as
> <Contract>...</Contract>. I think it can be used as a criteria whether we
> introduce as an element in XML voucher or not.
> How do you think this approach?

Initially that would be fine - experience would guide us as to
how to develop the inner parts.

One thing that happened with currency contracts that I didn't
predict was that a currency issuer added a complete section
called [conditions] and a lot of fields like conditions_backing,
conditions_reserves, conditions_audit...  which all specified
the terms of the contract in those particular areas.

Likewise, a new contract that is being worked on by an issuer
has added a complete [definitions] section at the very beginning.
If we were to translate his contract to an XML format, it would
look like:

<contract>
 <definitions>
  <dollars>
   [ivan's] dollars are ...
  </dollars>
  ...
 </definitions>

 <entity>
  <shortname>...</shortname>
 </entity>

 <issue>
  ...
 </issue>

 <currency>
  <name>[ivan's] dollars</name>
  <tla>USD</tla>
  <type>decimal</type>
  <decimal_power>2</decimal_power>
  <fraction>c</fraction>
 </currency>
 ...
</contract>

(for example ...)  One thing I'm unsure of is the appropriate form,
should it be tags everwhere or fields?  E.g., would the following
be more appropriate:

 ...
 <currency name="ivan's dollars" type="decimal" power=2 fraction="c">
  Ivan's dollars are denominated in dollar units, with a fractional
  unit of contract of a cent.
 </currency>

--
iang