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

From: Ko Fujimura <[email-masked]>
Date: Thu, 01 Mar 2001 14:29:20 +0900

Rachel Willmer wrote:
> 
> Have there been any implementations of this Internet Draft on "XML Voucher:
> Generic Voucher Language" ?
> 
> Thanks
> Rachel

Not yet. This document is newly designed and not completed as you see t.b.s. 
sections. If major design issues are acceptable for the WG members, we would 
like to go into detail.

But I think it is easy to implement on top of existing value transfer protocols
since we designed it based on our implementation experiences of several types 
of value transfer protocols and languages. I hope some volunteers could also 
help to check feasibility and give feedback about the specification.

Thanks,

Ko

---

From: Rachel Willmer <[email-masked]>
Date: Fri, 02 Mar 2001 14:37:01 +0000

Rachel Willmer wrote on the IETF IOTP mailing list:

>> Have there been any implementations of this Internet Draft on "XML
>> Voucher: Generic Voucher Language" ?

On 01 March 2001 14:29 +0900 Ko Fujimura <[email-masked]> replied

> Not yet. This document is newly designed and not completed as you see
> t.b.s.  sections. If major design issues are acceptable for the WG
> members, we would  like to go into detail.
>
> But I think it is easy to implement on top of existing value transfer
> protocols since we designed it based on our implementation experiences of
> several types  of value transfer protocols and languages. I hope some
> volunteers could also  help to check feasibility and give feedback about
> the specification.

Ko

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.

I've copied this mail to Ian Grigg from Systemics <[email-masked]>, 
because I think it may be worth you both engaging in some dialogue.

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.

Regards
Rachel

---

From: Ko Fujimura <[email-masked]>
Date: Mon, 05 Mar 2001 11:05:38 +0900

Hi Rachel,

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

> because I think it may be worth you both engaging in some dialogue.

Thank you.

> 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/>

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. 
We are going to implement XML voucher as soon as it completed.

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

Regards,

Ko
----------------------------------------------------------
Ko Fujimura, NTT Information Sharing Platform Laboratories
1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN
Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-2241
Email: [email-masked]

---

From: Ian Grigg <[email-masked]>
Date: Mon, 05 Mar 2001 12:59:35 -0400

> the Ricardo system since it provides both flexibility and simplicity using modular

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

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

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

> 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

---

From: Ko Fujimura <[email-masked]>
Date: Tue, 06 Mar 2001 19:18:05 +0900

Hi Ian,

Thank you for your comments:

> Ko Fujimura wrote:
...
> that the "contract" or interface is specified as per programming

I used it in the legal sense, but rather weak meaning. In other words,
It can be used it legally if the issuer provides enough information within the 
Promise element. Using the XML-naming facility, any application-specific 
properties can be extended in the Merchandise element. For example:

<Promise>
  ...
  <Merchandise xmlns="http://www.example.org/bond.txt">
     <Bond identitiy="..." issueDate="..." .../>
  </Merchandise>
<Promise>

(I'm not sure tag name "Merchandise" is appropriate.) 

But, strictly speaking, it might be a fragment of a contract, since issuer's 
signature is attached externally as you pointed out.

> by humans, linked to the asset in question, signed by the Issuer,

Right. Readability is an important issue of XML. Plain text is a good approach
in this sense. But, it was also discussed in the XMLDSIG WG and summary of the 
discussion is incorporated in Section 8 of the current XMLDSIG spec:
<http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/#sec-Security>.

> contract under a wide degree of circumstances.

My basic idea is to leave this issue to other specification, i.e., XMLDSIG,
since it seems to be a general issue of XMLDSIG.
We haven't specified how <vts:KeyInfo> is used in the current draft.
But, one idea is to adopt/refer <KeyInfo> defined in the XMLDSIG spec as it is. 

Recently, the spec of KeyInfo have been discussed actively in the XMLDSIG WG.
(See archive below:)

"Donald E. Eastlake 3rd" wrote in: 
<http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0073.html>
 
> I think the various sides of this issue
> <http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JanMar/0039.html>
> have been well argued and that it is unlikely there will be much
> furhter change in opinion.  The consensus of the Working Group is for
> option 2 and we will proceed on the basis of that choice.  This also
> means including clearer criterion as to when elements other than those
> we have defined can be included within the {X509|PGP|SPKI}Data
> element.
> 
> I suggest the text in the editors draft at
> <http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-KeyInfo>
> be changed to be the HTML appended below.

Regards, 

Ko