Subject: Re: draft-ietf-trade-drt-requirements-03.txt
From: Ko Fujimura <[email-masked]>
To: Chris Brandt <[email-masked]>, [email-masked]
Cc: Ko Fujimura <[email-masked]>
Date: Fri, 18 Jan 2002 22:57:33 +0900
List-Id: <ietf-trade.lists.elistx.com>

Chris Brandt wrote:
> 
> 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.

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

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

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

Content-return: allowed
Date: Wed, 16 Jan 2002 16:42:48 -0800
From: Chris Brandt <[email-masked]>
Subject: RE: draft-ietf-trade-drt-requirements-03.txt
To: 'Ko Fujimura' <[email-masked]>, [email-masked]

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]

Date: Thu, 17 Jan 2002 09:13:09 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: draft-ietf-trade-drt-requirements-03.txt
To: Chris Brandt <[email-masked]>, [email-masked]

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]

Content-return: allowed
Date: Wed, 16 Jan 2002 16:22:54 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: Changes in TRADE WG Charter Milestone Dates
To: "[email-masked]'" <[email-masked]>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_b6RHdNra9O47y78xg+ZM6g)
Content-type: text/plain; charset=iso-8859-1

At the last IETF meeting, we came up with the changes below for the live
Milestones in the WG charter. This message is to see if there is any
substantial disagreement with this on the mailing list. I plan to send in a
request get the numerous old completed Milestones removed and these date
updates put in place in about a week.

Thanks,
Donald

Milestone
Old Data		New Date

Submit I-D on Secure Channel Credit Specification
January 2001		March 2002

Submit Secure Channel Credit/Debit Prop. Std.
March 2001		July 2002

Submit ECML V2.0 Specification Prop. Std.
March 2001		March 2002

Submit I-D on IOTP V2.0 Specification
April 2001		December 2002

Submit Generic Voucher Trading Specification Prop. Std.
May 2001		May 2002

Submit IOTP V2.0 Specification Prop. Std.
August 2001		July 2003

Donald E. Eastlake 3rd, +1-508-851-8280 (voice), +1-508-851-8507 (fax)
Motorola, MS: M2-450, 20 Cabot Boulevard, Mansfield, MA 02048 USA

--Boundary_(ID_b6RHdNra9O47y78xg+ZM6g)
Content-type: application/octet-stream; name="Eastlake Donald-LDE008.vcf"
Content-transfer-encoding: BASE64
Content-disposition: attachment; filename="Eastlake Donald-LDE008.vcf"

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkVhc3RsYWtlO0RvbmFsZA0KRk46
RWFzdGxha2UgRG9uYWxkLUxERTAwOA0KTk9URTpNQTA3IC0NCkFEUjtXT1JLOjtN
YW5zZmllbGQNCkxBQkVMO1dPUks6TWFuc2ZpZWxkDQpFTUFJTDtQUkVGO0lOVEVS
TkVUOkRvbmFsZC5FYXN0bGFrZUBtb3Rvcm9sYS5jb20NClJFVjoyMDAwMDQyN1Qx
NDMzMDlaDQpFTkQ6VkNBUkQNCg==

--Boundary_(ID_b6RHdNra9O47y78xg+ZM6g)--

Content-return: allowed
Date: Wed, 16 Jan 2002 12:53:12 -0800
From: Chris Brandt <[email-masked]>
Subject: draft-ietf-trade-drt-requirements-03.txt
To: [email-masked]

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.

_________________________________________________

Christopher Brandt
Interfaces Manager
Ernex Marketing Technologies
Suite 225
4259 Canada Way
Burnaby, BC, V5G 1H1
Ph:  604-415-1554
Cell: 604-728-1537
Fx:  604-415-1589
[email-masked]
www.ernexinc.com

Date: Wed, 16 Jan 2002 07:02:52 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-drt-requirements-03.txt
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]

--Boundary_(ID_M5eE5a6JEGd/nHPPP1Xc9g)
Content-type: TEXT/PLAIN

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Requirements and Design for Voucher Trading System 
                          (VTS)
	Author(s)	: K. Fujimura
	Filename	: draft-ietf-trade-drt-requirements-03.txt
	Pages		: 13
	Date		: 15-Jan-02
	
Functions common in purchasing and general trading transactions,
include crediting loyalty points and collecting digital coupons or
gift certificates.  These activities can be generalized using the
concept of a 'voucher', which is a digital representation of the
right to claim goods or services. This document presents the
terminology of and a model for a Voucher Trading System (VTS) that
circulates vouchers securely; it lists design principles and
requirements for VTS and the Generic Voucher Language (GVL), with
which diverse types of vouchers can be described.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-drt-requirements-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-drt-requirements-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-drt-requirements-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Boundary_(ID_M5eE5a6JEGd/nHPPP1Xc9g)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_26/HGhmHmFt+3uhZ+bMong)"

--Boundary_(ID_26/HGhmHmFt+3uhZ+bMong)
Content-type: Message/External-body; server="[email-masked]";
 access-type=mail-server

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-drt-requirements-03.txt

--Boundary_(ID_26/HGhmHmFt+3uhZ+bMong)
Content-type: Message/External-body; directory=internet-drafts;
 access-type=anon-ftp; site=ftp.ietf.org;
 name=draft-ietf-trade-drt-requirements-03.txt

Content-Type: text/plain
Content-ID:	<[email-masked]>

--Boundary_(ID_26/HGhmHmFt+3uhZ+bMong)--

--Boundary_(ID_M5eE5a6JEGd/nHPPP1Xc9g)--

Content-return: allowed
Date: Mon, 14 Jan 2002 12:55:47 -0500
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: Slides from Salt Lake City
To: "[email-masked]'" <[email-masked]>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_TSWwIgXyE1f92I38r3KYMQ)
Content-type: text/plain; charset=iso-8859-1

The slides shown at the working group meeting at the last IETF meeting in
Salt Lake City are in
<ftp://ftp.pothole.com/pub/ietf-trade/IETF-SaltLakeCity/>. Sorry it has
taken a while to get them
up.

Donald

Donald E. Eastlake 3rd, +1-508-851-8280 (voice), +1-508-851-8507 (fax)
Motorola, MS: M2-450, 20 Cabot Boulevard, Mansfield, MA 02048 USA

--Boundary_(ID_TSWwIgXyE1f92I38r3KYMQ)
Content-type: application/octet-stream; name="Eastlake Donald-LDE008.vcf"
Content-transfer-encoding: BASE64
Content-disposition: attachment; filename="Eastlake Donald-LDE008.vcf"

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkVhc3RsYWtlO0RvbmFsZA0KRk46
RWFzdGxha2UgRG9uYWxkLUxERTAwOA0KTk9URTpNQTA3IC0NCkFEUjtXT1JLOjtN
YW5zZmllbGQNCkxBQkVMO1dPUks6TWFuc2ZpZWxkDQpFTUFJTDtQUkVGO0lOVEVS
TkVUOkRvbmFsZC5FYXN0bGFrZUBtb3Rvcm9sYS5jb20NClJFVjoyMDAwMDQyN1Qx
NDMzMDlaDQpFTkQ6VkNBUkQNCg==

--Boundary_(ID_TSWwIgXyE1f92I38r3KYMQ)--

Date: Fri, 04 Jan 2002 08:52:14 -0500
From: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-iotp2-req-02.txt
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]

--Boundary_(ID_BTqcMiV97+0PQMapgewLYA)
Content-type: TEXT/PLAIN

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: Internet Open Trading Protocol Version 2 Requirements
	Author(s)	: D. Eastlake
	Filename	: draft-ietf-trade-iotp2-req-02.txt
	Pages		: 8
	Date		: 03-Jan-02
	
Version 2 of the Internet Open Trading Protocol (IOTP) will extend
the interoperable framework for Internet commerce capabilities of
Version 1 while replacing the XML messaging and digital signature
part of IOTP v1 with standards based mechanisms. Additional features
are listed and divided into those the will, may, and will not be
included.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp2-req-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-iotp2-req-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-iotp2-req-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Boundary_(ID_BTqcMiV97+0PQMapgewLYA)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_3+d+Dz5KDb8FxsLvtTgBtQ)"

--Boundary_(ID_3+d+Dz5KDb8FxsLvtTgBtQ)
Content-type: Message/External-body; server="[email-masked]";
 access-type=mail-server

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-iotp2-req-02.txt

--Boundary_(ID_3+d+Dz5KDb8FxsLvtTgBtQ)
Content-type: Message/External-body; directory=internet-drafts;
 access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-trade-iotp2-req-02.txt

Content-Type: text/plain
Content-ID:	<[email-masked]>

--Boundary_(ID_3+d+Dz5KDb8FxsLvtTgBtQ)--

--Boundary_(ID_BTqcMiV97+0PQMapgewLYA)--

Date: Thu, 03 Jan 2002 09:00:04 -0700
From: [email-masked]
Subject: Re: Small/Secure Payment Business Models
To: [email-masked]

somewhat related from basel (aka BIS ... bank for international
settlements):

Sound Practices for the Management and Supervision of Operational Risk
http://www.bis.org/publ/bcbs86.htm

Electronic finance: a new perspective and challenges
http://www.bis.org/publ/bispap07.htm

from above

A workshop on electronic finance was convened by the BIS on 2-3 July
2001. The internet and related technology has begun to have a profound
effect on how financial services are delivered. Discussion about e-
finance is widespread within the financial community, covering both
its potential to improve efficiency but also possible challenges it
poses to financial and monetary stability. Rapid innovation and the
paucity of reliable data are creating considerable uncertainty about
the nature and size of these challenges. The workshop brought together
a diverse group of experts (listed on pages iii-vi) from a range of
economies, backgrounds and sectors; including practitioners, academics
and central bankers. It focused on current and potential changes in
trading systems and exchanges, payment systems and financial
institutions.

This volume starts with an overview based on the presentations given
during the workshop, some of which are also included in the volume,
and the ensuing discussions. The individual papers cover, inter alia,
trading in wholesale financial markets, emerging competition in the
payment system and the progress of virtual banks. Implications for
financial supervision and monetary policy are also specifically
addressed in separate papers. As there are a plethora of technical
terms associated with the subject, a glossary is included at the end
of this volume.

Date: Tue, 01 Jan 2002 14:18:53 -0700
From: [email-masked]
Subject: Re: Small/Secure Payment Business Models
To: Steve Schear <[email-masked]>
Cc: [email-masked], Ronald Duncan <[email-masked]>

actually, i've heard some number of organizations about not wanting to be a
FDIC insured institution, part of the banking federal reserve system,
and/or a holding company that "owns" such an instutition because of the
regulatory, audit, and fidiciary requirements placed on them

analysis of some types of systemic risks in discussion of risk management
and information security
(including the section towards the end on ARMS & Citicorp getting out of
the home mortgage business as well as  the FIRREA Act of 1989):
http://www.garlic.com/~lynn/aepay3.htm#riskm
http://www.garlic.com/~lynn//aepay3.htm#riskaads

also the gao report listed:
http://www.garlic.com/~lynn/aadsm5.htm#epaym "e-payments" email discussion
list is now "Internet-payments"

also "secure" payment discussion in sci.crypt "CFP: PKI research workshop"
thread:
http://www.garlic.com/~lynn/aadsm10.htm#cfppki14

<[email-masked]> on 12/31/2001 9:55pm wrote:

Politically: having enough juice to buy off Congress and get regulations
favoring/protecting your turf.  Regulations always favor the regulated