Subject: RE: draft-ietf-trade-drt-requirements-03.txt

From: Chris Brandt <[email-masked]>
Date: Wed, 16 Jan 2002 16:42:48 -0800

Even after reviewing the Trust Model, I have some troubles. The trust model works for identifying
who someone is who/what is authorized to perform an action (ie, a VTS is authorized to trade a
voucher). But does that mean that the authority that issues a trust certificate for VTS-abc must do
a software evaluation on VTS-abc's software? This would seem prudent, since the authority is
putting their name on the line for VTS-abc. 

So, my question is, is it practical? What is the vision for the population of VTSs, few or many.
Are they only run by large reputable institutions, or by mom & pop shops?

If I'm out in left field with respect to how the trust model works let me know!

Chris

-----Original Message-----
From: Ko Fujimura [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 4:13 PM
To: Chris Brandt; [email-masked]
Subject: Re: draft-ietf-trade-drt-requirements-03.txt

Chris Brandt wrote:
> 
> I'm not sure if this is the forum for discuss on this draft, if not let me know.
> 
> The big question in my mind with the Voucher Trading System is how duplication is controlled. For
> example, say I'm an unscrupulous person and I setup a trading site where people can exchange one
> voucher for another. So, all my VTS is supposed to do is control the transfer of ownership of
> vouchers. What is to stop me from making the odd copy of a voucher? From the specification, it
> would seem that I have all of the information I would need, and I'm in control of the software.

VTS Provider provides a VTS and guarantees that there are no duplicate assignments 
or multiple use of vouchers as described in Section 2.2. In this sense, a VTS Provider 
is acts as a trusted third party. But, it doesn't mean that all of the information, 
e.g., contents of voucher, can be managed by the VTS Provider. A publicly verifiable
protocol can be used depending on the VTS implementation, although this is outside 
scope of the specification. See also in the Section 3 of XML Voucher specification. 
It describes the trust model we assumed in the specifications.

Thanks,

Ko
--------------------------------------------------------------
Dr. 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: Ko Fujimura <[email-masked]>
Date: Fri, 18 Jan 2002 22:57:33 +0900

> putting their name on the line for VTS-abc.

This is an issue of "software delivery". Above method might be a possibility for 
establishing a trust for downloading software, although I'm not sure how it is 
practical/effective. Today, a large number of e-commerce applications, such as 
payment and trading, have already been delivered/used without such a software 
evaluation organization. There are several ways in which people believe the 
trust of software. We wrote, therefore, the following notes in the VTS-API 
specification:

   7. Security Considerations

   This document assumes that the VTS plug-in is trusted. The caller
   application of a VTS should authenticate the VTS plug-in and bind it
   securely using the VTS Provider information specified in the Voucher
   Component. This document, however, does not specify any application
   authentication scheme and it is assumed to be specified by other
   related standards. [Editor's note: References are for further
   study. Until various VTS systems are deployed, it may be enough to
   manually check and install VTS plug-ins like other download
   applications.]

> Are they only run by large reputable institutions, or by mom & pop shops?

I guess that a few large reputable institutions will start their businesses 
in the early phase. After that, many companies follow. Finally, a free secure 
system will be appeared and it becomes a dominant -- this is a common story 
in this area :)

Regards,

Ko