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

From: [email-masked]
Date: Mon, 05 Mar 2001 11:22:25 -0800

as an aside, X9.59 financial standard that recently passed (electronic standard
for all retail payments) also incorporates the message digest of the purchase
order (or contract) in the body of the payment message.

as specified in the standard, the payment message encoding format is ASN.1 ...
however the appendix includes an example in FSML (financial standards markup
language ... precursor to much of the XML financial related specifications).

financial standards bodys are at

http://www.x9.org/
http://www.tc68.org/

for some fsml related information

http://www.echeck.org/

misc. x9.59 information

http://www.garlic.com/~lynn/

Ian Grigg <[email-masked]> on 03/05/2001 08:59:35 AM

Please respond to [email-masked]

To:   Ko Fujimura <[email-masked]>
cc:   Rachel Willmer <[email-masked]>, [email-masked],
      [email-masked]
Subject:  Re: implementations of "XML Voucher: Generic Voucher Language" ?

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

---

From: Ko Fujimura <[email-masked]>
Date: Fri, 09 Mar 2001 22:17:48 +0900

Ian Grigg wrote:
> 
> [email-masked] wrote:
> ...
> >
> I printed out the 1.5.  The document formatting rules look like a
> useful starting point for XML contracts (including the Voucher
> work).
> 
> The rest of the document seems to be oriented to check processing.
> Even though it claims that it might be used for generic documents,
> I doubt it, as there are too many assumptions about how checks work
> built into it, as well as lots of protocol stuff.

Thank you for your advice. But, the FSML v1.5 spec also seems to be 
oriented to check processing.

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.

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?

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?

Regards,

Ko

---

From: Ian Grigg <[email-masked]>
Date: Fri, 09 Mar 2001 22:44:28 -0400

<snip>
> in <http://www.systemics.com/docs/ricardo/issuer/contract.html>

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

> 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.)

> 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

---

From: Todd Boyle <[email-masked]>
Date: Sat, 10 Mar 2001 10:26:38 -0800

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: [email-masked] [mailto:[email-masked]]On Behalf Of Ian Grigg
Sent: Friday, March 09, 2001 6:44 PM
To: Ko Fujimura
Cc: Rachel Willmer; [email-masked]; [email-masked]
Subject: Re: implementations of "XML Voucher: Generic Voucher Language"
?

<snip>

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

 <entity>

 <issue>
  ...
 </issue>

 <currency>

 ...

--
iang

---

From: Ko Fujimura <[email-masked]>
Date: Wed, 14 Mar 2001 20:48:43 +0900

> the full set of data, not because a program can use them.

Thank you very much for information. It's really helpful for considering the properties
of value (or voucher). 

> according to their usefulness.

I agree. It is impossible to develop a specification that covers all types of 
vouchers in the world. I think that the goal of XML voucher is to cover 90%(?)
of vouchers without introducing implementation difficulties.

> the terms of the contract in those particular areas.

It's good suggestion. I think we should introduce the <Conditions> element for 
that purpose.

> If we were to translate his contract to an XML format, it would

In the current voucher draft, there is a <Description> element. I think the purpose
of <definitions> seems to be similar...

>   <decimal_power>2</decimal_power>

In the current voucher draft, <Title> is introduced for describing the name of the
voucher (incl. currency).

I'm not sure whether <type> is really needed, since other standards, e.g., IOTP, ECML,
FTSC, X9.59, ..., does not has the property, and there is no modern currency that are 
not decimal.

I understand that you introduced <decimal_power> to give the mapping information 
between the amount managed by the account (or SOX protocol) and the unit of the 
currency displayed. This is good idea since underlying system such as VTS does not 
have to care about the unit. Using this mapping information, a wallet system can 
transform it in a human readable form.

In the current voucher draft, I introduced <Value ratio="nnnn"/> syntax for similar
purpose. Using this syntax, Ivan's dollar can be defined as follows:

<Voucher>
  ...
  <Promise>
    <Title>Ivan's dollars</Title>
    <Description>
      Ivan's dollars are ...
    </Description>
    ...
    <Value ratio="0.01" currency="USD" amount="1"/>
    <Conditions>Only valid in Ivan's shops</Conditions>
    ...
  </Promise>
  ...
</Voucher>

I found currency_factor parameter in the Ricardian Contract. I think it is the same 
as the ratio attribute above. By the way, I think that either currency_factor or 
currency_decimal_power is enough for defining the mapping, am I right? If so, why 
you choose currency_decimal_power? I think currency_factor is more flexible.
Sorry for asking a lot. But, your experiences are really helpful for developping the
specification.

I didn't introduce <fraction> in the above. Because, "$0.01" seems to be ok instead of 
"1c" in many cases, and the translation is quite easy in XML using the style sheet. 

>   unit of contract of a cent.

That's fine. But I'm not sure whether the meaning should be written in natural 
language for monetary value, since its semantics is strictly defined using the 
attributes. But, non monetary value this syntax might be more appropriate...

<Voucher>
  ...
  <Promise>
    <Title>Ivan's gold voucher (1mg)</Title>
    <Description>
      This voucher can be exchanged for 1mg of gold.
    </Description>
    ...
    <Merchandise ratio="0.001" unit="g" amount="1">  [or ratio="1" unit="mg"]
      Ivan's gold vouchers are denominated in gram of gold, with a fractional
      unit of a milligram.
    </Merchandise>
    <Conditions>...</Conditions>
    ...
  </Promise>
  ...
</Voucher>

By the way, I'm not sure gold is currency or merchandise :-)

Thank you!!

Ko

---

From: Ian Grigg <[email-masked]>
Date: Wed, 14 Mar 2001 12:19:51 -0400

Ko Fujimura wrote:
...
> of vouchers without introducing implementation difficulties.

OK.  Our goal with Ricardian Contracts is more adventurous,
to cover 100% of financial instruments :)  So far we've not
struck a case we can't say something about, although I admit
that futures are a bit tricky in Ricardo -- it's not obvious
how to deliver a tonne of pork bellies over the net.

As we are trying to cover everything, we do have sections
in there for different styles of instruments, and the format
allows the addition of others.  There are certain limitations
that may mitigate against some instruments, for example, the
format assumes that there is one central signatory, which is not
always the case.  But, it is close enough to the existing set
of contracts we work with, so it is put in the "future work"
basket of tasks.

[ Vouchers in the sense of tickets and loyalty we've never
really looked at closely... ]

> voucher (incl. currency).

<Title> is fine.  There is a need for several versions of the title,
there is at least a shortname and a full, legal title.  With currencies
there are often ISO TLAs and with shares there are often "symbols".

The shortname and the symbol are important variables for the program
to read.

You could do something like:

<Title shortname="Systemics" symbol="SYX">
  Systemics Incorporated
</Title>

> FTSC, X9.59, ..., does not has the property, and there is no modern currency that are

The question revolves around whether you think that this field
forms part of the contract.  In my view, the type is a part of
the contract.

Other standards simply ignore the contract, and this is one
reason why they fail to grow into new areas.  For example, you'd
be hard pressed to find another standard that could differentiate
between a dollar issued by the Federal Reserve and a dollar issued
in the Euro markets - they pretty all much assume that the ISO has
it right and using the TLA "USD" will cover it.

You are right that there is no modern currency that is non-decimal,
and I can't even think of a bond or share or other instrument that
might be non-decimal.  So probably what I should do is make the
default for "type" be "decimal" and leave the question of other
conventions for whoever can find one.

> transform it in a human readable form.

Yes, that's right.  The nature of the "cents" in any currency is
a decided part of the contract, but software works in cents whilst
humans work in dollars.  How this difficulty is resolved is very
important to a payment system.

> currency_decimal_power is enough for defining the mapping, am I right?

That's correct.  WebFunds has a routine that searches for each of them,
and uses the best available information.

> If so, why

Currency_factor is in fact what we originally worked with, as it is
on the surface more flexible;  we can do something like .005 easily.

It turned out to be more of a nuisance than a feature.  Just as all
currencies are decimal, they are also all powers of ten.  By that, I
mean there was no *useful* scenario where we came across that required
a 200 cents in the dollar breakup.

[ I.e., in the beloved guilder economy, there are only 5c coins, they
abandoned the 1c a long time ago.  So, yes, if we wanted to issue
Ricardian guilders, we might want to set the factor to 0.05.  However,
it's all a matter of convenience, and there is more sense in setting
it to 0.01 and running with single cents as the software solves the
cost factor that caused the Dutch mint to drop the 1c coin. ]

And, the reason that sparked the change to decimal_power was that
programming with factors was hard.  Whilst accurate in the contract,
we had continual problems where the program code would trip up on
the fixed point calculations.  So, it became easier to set the power
as an integer 2, -2, whatever, and then write some support code that
produced the strings when necessary.  More code, but easier to control.

> Sorry for asking a lot. But, your experiences are really helpful for developping the

No problem - as I say I intend to use your Voucher as the starting
point for the Ricardian conversion to XML.  The more work we get
done now, the easier it will be later :)

> "1c" in many cases, and the translation is quite easy in XML using the style sheet.

OK.  Another thing to be aware of is what it is you are defining.
In Ricardian Contracts, they define the "unit of contract" which
is always the unit that the software deals in.  I.e., cent or
milligram.  Then, the power/fraction/factor is used to define an
alternate representation for humans, called the "unit of account."

Getting this right is important - it needs to be part of the standard,
as software needs to agree and account for each and every cent.  Most
payment systems define both the unit of account and the unit of contract
as being equally important, and thus get themselves into all sorts of
knots trying to work out how to deal with them.

Also, bear in mind that I've moved the power into the previous section
so that *all* contracts are now subject to the units capability.  This
is because we've found that issuing shares or bonds with units of account
and distinct units of contract actually makes sense.  That is, millishares
is a "good idea" under some circumstances.

[ The best example of this is the shares in Warren Buffet's company,
Berkshire-Hathaway, which he deliberately never split as he wanted to
only keep large, important shareholders.  When they got to be worth 5
figures in dollars, even the papers had to stop quoting the share
price because the price columns only supported 4 figures.  Now, we
of course could break his game by issuing what I call Bufflets,
being microshares.  The unit of account would be one BH share, and
the unit of contract could be a millionth of that. ]
 
> attributes. But, non monetary value this syntax might be more appropriate...

Correct, this is one of the legal conundrums of a digital contract, what
happens when a defined field disagrees with a comment?

In my view, the fields dominate and the comments should be written to
explain the fields.  That's what I tell all the issuers, and in time I'd
hope that would become established as a custom (assuming my view is
valuable, that is).

What happens when a comment disagrees with a field is a gray area, and
I'm deliberately leaving this as a gray area.  That is, a judge would have
to rule.  So, an issuer would write a contract, and check the fields and
comments match.  And if they don't, then there are consequences.  But the
nature of those consequences are, IMHO, more properly determined in the
courts than in the technology.

[ For similar reasons, I will probably deliberately ban any "critical"
bit as exists in the FSML spec.  The effect of that is a legal nightmare,
only plausible in FSML because they are not really doing contracts, just
checks/cheques. ]

>     <Merchandise ratio="0.001" unit="g" amount="1">  [or ratio="1" unit="mg"]

Right, so here you need to make clear what both the minor unit
is and what the major unit is.  You will need a name for both of
them, and of course the ratio between them.  Something like:

<... ratio="0.001" major_unit="g" minor_unit="mg">

where I've used major and minor rather than my terms "unit of account"
and "unit of contract" to avoid assuming your intentions :)

> By the way, I'm not sure gold is currency or merchandise :-)

You may not be aware of the emerging gold economy, originated by the
e-gold company, with something like a tonne of gold in issuance as a
currency.  Digital gold is mostly a currency, sometimes a financial
instrument, but it is unlikely to make much impact as merchandise,
as digital gold doesn't have the allure and fashionability that
physical gold jewellry has.

-- 
iang