ietf-trade message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-trade Home]


Subject: Re: Contracts and XML Voucher


Hi Ian,

Thank you for your comments:

Ian Grigg wrote:
> 
> Ko Fujimura wrote:
...
> > 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?

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.

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

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

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

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-trade Home]


Powered by eList eXpress LLC