Network Working Group K. Fujimura
Request for Comments: 3506 NTT
Category: Informational D. Eastlake
Motorola
March 2003
Requirements and Design for Voucher Trading System (VTS)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions. 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 a Voucher Trading System (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the Generic Voucher Language (GVL), with which diverse types of vouchers can be described.
ロイヤリティポイントをクレジットし、デジタルクーポンやギフト券を収集することは、購買や取引の取引に共通の機能です。これらの活動は、商品やサービスを請求する権利のデジタル表現である、「バウチャー」の概念を用いて一般化することができます。この文書では、しっかりバウチャーとその用語を循環させるクーポン取引システム（VTS）を提示します。それは、バウチャーの多様な種類が記述可能な設計原理とVTSとジェネリッククーポン言語（GVL）の要件を、一覧表示されます。
Conventions used in this document
この文書で使用されている表記
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Table of Contents
目次
1. Background ....................................................2
2. Terminology and Model .........................................3
2.1 Voucher ...................................................3
2.2 Participants ..............................................3
2.3 Voucher Trading System (VTS) ..............................4
3. VTS Requirements ..............................................5
3.1 Capability to handle diversity ............................6
3.2 Ensuring security .........................................6
3.3 Ensuring practicality .....................................7
4. Scope of VTS Specifications ...................................7
4.1 Voucher Trading Protocol ..................................7
4.2 VTS-API ...................................................8
4.3 Generic Voucher Language ..................................8
5. GVL Requirements ..............................................8
5.1 Semantics .................................................8
5.2 Syntax ....................................................9
5.3 Security .................................................10
5.4 Efficiency ...............................................10
5.5 Coordination .............................................10
5.6 Example of GVL ...........................................10
6. Application Scenarios ........................................11
7. Q & A ........................................................13
8. Security Considerations ......................................13
9. Acknowledgments ..............................................13
10. References ...................................................13
11. Authors' Addresses ...........................................14
12. Full Copyright Statement......................................15
It is often necessary to credit loyalty points, collect digital coupons or gift certificates, etc, to complete purchases or other trading transactions in the real world. The importance of these activities is also being recognized in Internet Commerce. If a different issuing or collecting system to handle such points or coupons must be developed for each individual application, the implementation cost will be excessive, inhibiting the use of such mechanisms in electronic commerce. Consumers may also be forced to install a number of software modules to handle these points or coupons.
それは多くの場合、クレジット・ロイヤルティ・ポイントが必要であり、現実の世界での購入や他の取引トランザクションを完了するなど、デジタルクーポンやギフト券を集めます。これらの活動の重要性は、インターネット商取引に認識されています。異なる発行又は点又はクーポンを処理するために収集システムは、個々のアプリケーションのために開発されなければならない場合、実装コストは、電子商取引におけるそのような機構の使用を禁止、過度であろう。消費者はまた、これらのポイントやクーポンを処理するためのソフトウェア・モジュールの数をインストールすることを強制することができます。
A voucher is a digital representation of the right to claim services or goods. Using vouchers, a wide-range of electronic-values, including points or coupons, can be handled in a uniform manner with one trading software module.
バウチャーは、サービスや物品を請求する権利のデジタル表現です。バウチャーを使用して、ポイントやクーポンなどの電子値の広い範囲は、1つの取引ソフトウェアモジュールと均一に処理することができます。
This document presents the terminology and model for a Voucher Trading System (VTS) that circulates vouchers securely; it also lists design principles and requirements for a VTS and the Generic Voucher Language (GVL), with which diverse types of vouchers can be described.
この文書では、安全にバウチャーを循環させるクーポン取引システム（VTS）のための用語とモデルを提示し、それはまた、設計原理とバウチャーの多様な種類が記述可能なVTSとジェネリッククーポン言語（GVL）、の要件を示しています。
A voucher is a digital representation of the right to claim goods or services. To clarify the difference between vouchers and electronic money/digital certificates, we introduce a formal definition of vouchers in this document.
バウチャーは、商品やサービスを請求する権利のデジタル表現です。バウチャーおよび電子マネー/デジタル証明書との違いを明確にするために、我々は、この文書でバウチャーの正式な定義を紹介します。
Let I be a voucher issuer, H be a voucher holder, P be the issuer's promise to the voucher holder. A voucher is defined as the 3-tuple of <I, P, H>.
HはPバウチャーホルダーに発行者の約束も、バウチャーホルダーも、私はバウチャーの発行者とします。バウチャーは、<I、P、H>の3タプルとして定義されます。
Examples of P are as follows:
次のようにPの例は次の通りであります：
o Two loyalty points are added to the card per purchase. If you collect 50 points, you'll get one item free. (Loyalty points)
O二つの忠誠ポイントは、購入ごとにカードに追加されます。あなたは50ポイントを収集する場合は、一つのアイテムが無料になりますよ。 （ロイヤリティポイント）
o Take 10% off your total purchase by presenting this card. (Membership card)
Oこのカードを提示することによって、あなたの合計購入10％オフを取ります。 （会員カード）
o Take 50% off your total purchase with this coupon. The purchase transaction uses up the coupon. (Coupon)
Oこのクーポンを使用して合計購入50％オフを取ります。購入取引は、クーポンを使用しています。 （クーポン）
o The bearer can access "http://..." for one month free. (Free ticket for sales promotion)
1ヶ月無料：ベアラO「// ...のhttp」にアクセスすることができます。 （販売促進のための無料チケット）
o The bearer can exchange this ticket for the ordered clothes. (Exchange ticket or Delivery note)
Oベアラが注文した服のためにこのチケットを交換することができます。 （引換券または納品書）
o Seat number A-24 has been reserved for "a-concert" on April 2. (Event ticket)
O座席番号A-24は、4月2日（イベントチケット）の「コンサート」のために予約されています
Note that P does not need to be described in terms of a natural language as long as the contents of the vouchers are specified. For example, a set of attribute name and value pairs described in XML can be employed to define the contents.
Pは限りバウチャーの内容が指定されているとして、自然言語の観点から説明する必要はないことに注意してください。例えば、XMLで記述された属性名と値のペアのセットは、内容を定義するために使用することができます。
There are four types of participants in the voucher trading model: issuer, holder, collector, and VTS provider. Their roles are as follows:
発行者、ホルダー、コレクタ、およびVTSプロバイダ：バウチャー取引モデルの参加者の4つのタイプがあります。次のように彼らの役割は以下のとおりです。
Issuer: Creates and issues a voucher. Guarantees contents of the voucher.
発行者：バウチャーを作成し、発行します。バウチャーの内容を保証します。
Holder (or user): Owns the vouchers. Transfers and redeems the voucher to other users or collector.
ホルダー（またはユーザ）：バウチャーを所有しています。譲渡および他のユーザーやコレクターにバウチャーを償還します。
Collector (or examiner): Collects or examines the voucher and implements its promise. In general, compensated by goods or services rendered.
コレクタ（または審査官は）：収集やバウチャーを調べて、その約束を実装しています。一般的には、レンダリングされた商品やサービスによって補償。
VTS Provider: Provides a VTS and guarantees that a particular voucher is not assigned to multiple holders or used multiple times unless permitted for that voucher type.
VTSプロバイダー：VTSを提供し、そのバウチャータイプに許可しない限り、特定のバウチャーが複数の所有者または使用を複数回に割り当てられていないことを保証します。
The IOTP model [IOTP] includes merchant, deliverer, consumer and other participants. They take various roles in the settlement because a merchant, for example, can be considered as an issuer, or holder depending on whether the merchant creates the voucher her/himself or purchases it from a wholesaler or manufacturer. A merchant can also be a collector if the shop collects gift certificate or coupons.
IOTPモデルは、[IOTP]商人、配達、消費者や他の参加者が含まれています。商人は、例えば、発行者とみなすことができるので、彼らは和解でさまざまな役割を取る、またはホルダーは、商人がバウチャー彼女/彼自身または卸売業者や製造業者からの購入、それを作成するかどうかによって異なります。ショップギフト券またはクーポンを収集する場合は、商人もコレクターすることができます。
A voucher is generated by the issuer, traded among holders (users), and finally is collected by the collector:
バウチャーは、発行者によって生成されたホルダ（ユーザ）間取引、及び最終的にコレクタによって収集されます。
<I, P, H> <I, P, H'> <I, P, H'>
Issuer I --------> User H ---------> User H' ---------> Collector
Issue Transfer Redemption
Figure 1. Life cycle of vouchers
バウチャーの図1.ライフサイクル
The VTS provider supplies a VTS that enables vouchers to be circulated among the participants securely.
VTSプロバイダは確実参加者の間で循環させるためのバウチャーを可能VTSを供給する。
A formal definition of VTS is as follows:
次のようにVTSの正式な定義は次のとおりです。
A voucher trading system (VTS) is a system that logically manages a set of valid vouchers VVS, which is a subset of {<I, P, H> | I in IS, P in PS, H in HS} where IS is the set of issuers, PS is the set of promises, and HS is the set of holders; VTS prevents them from being modified or reproduced except by the following three transactions: issue, transfer, and redemption. The initial state of the VVS is an empty set.
バウチャー取引システム（VTS）が論理的に有効なクーポン{のサブセットであるVVSのセットを管理するシステムである<I、P、H> |私がされているPSにおけるP HSにおいて、H}は発行者の集合であり、PSは、約束の組であり、HSは、ホルダーのセットです。問題、転送、および償還：VTSは、次の3つの取引による場合を除いて変更または再生されてからそれらを防ぐことができます。 VVSの初期状態は空集合です。
Note that this does not imply that VVS is stored physically in a centralized database. For example, one implementation may store vouchers in distributed smart cards carried by each holder [T00],
これはVVSが一元化されたデータベースに物理的に格納されていることを意味するものではないことに注意してください。例えば、一の実装では、各ホルダ[T00]によって運ば分散スマートカードにクーポンを格納することができます、
or may store them in multiple servers managed by each issuer or trusted third parties. This is a trust policy and/or implementation issue [MF99].
または、各発行体あるいは信頼できる第三者によって管理されている複数のサーバーでそれらを格納することができます。これは、信頼ポリシーおよび/または実装の問題[MF99]です。
Issue An issue transaction is the action that creates the tuple of <I, P, H> and adds it to the VVS with the issuer's intention.
問題のトランザクションを発行して、<I、P、H>のタプルを作成し、発行者の意図とVVSに追加しますアクションです。
Transfer A transfer transaction is the action that rewrites the tuple of <I, P, H> (in VVS) as <I, P, H'> (H<>H') to reflect the original holder H's intention.
転送トランザクションを転送すると、元のホルダーHの意図を反映するように<I、P、H '>として（VVSで）<I、P、H>（H <> H'）のタプルを書き換える動作です。
Redemption There are two redemption transactions: presentation and consumption.
プレゼンテーションと消費：償還2件の償還の取引があります。
A presentation transaction is the action that shows the tuple of <I, P, H> (in VVS) to reflect the holder H's intention. In this case, the ownership of the voucher is retained when the voucher is redeemed, e.g., redemption (presentation) of licenses or passports.
プレゼンテーションのトランザクションは、ホルダHの意図を反映させるために（VVS内）<I、P、H>のタプルを示したアクションです。この場合には、バウチャーの所有権は、ライセンスまたはパスポートのバウチャーを償還され、例えば、償還（プレゼンテーション）に保持されます。
A consumption transaction is the action that deletes the tuple of <I, P, H> (in VVS) to reflect the holder H's intention and properties of the voucher. The ownership of the voucher may be voided or the number of times it is valid reduced when the voucher is redeemed, e.g., redemption of event tickets or telephone cards.
消費トランザクションは、ホルダーHの意図と伝票の特性を反映する（VVSで）<I、P、H>のタプルを削除するアクションです。バウチャーの所有権が無効とされ得るか、またはバウチャーが償還された回数は、それが有効な低減され、例えば、イベントのチケットやテレホンカードの償還。
Note that one or more of these transactions can be executed as part of the same IOTP purchase transaction. See details in Section 6.
これらの取引の1つ以上が同じIOTPの購入取引の一部として実行することができることに注意してください。第6節で詳細を参照してください。
A VTS must meet the following requirements
VTSは、次の要件を満たす必要があります。
(1) It MUST handle diverse types of vouchers issued by different issuers.
（1）それは別の発行体によって発行されたバウチャーの多様な種類を処理する必要があります。
(2) It MUST prevent illegal acts such as alteration, forgery, and reproduction, and ensure privacy.
（2）そのような改変、偽造、および再生などの不正行為を防止し、プライバシーを確保しなければなりません。
(3) It MUST be practical in terms of implementation/operation cost and efficiency.
（3）これは、実装/運用コストと効率の点で実用的でなければなりません。
Each of these requirements is discussed below in detail.
これらの要件のそれぞれについて、以下に詳細に説明されています。
(a) Different issuers
（a）は別の発行体
Unlike a digital cash system that handles only the currency issued by a specific issuer such as a central bank, the voucher trading system MUST handle vouchers issued by multiple issuers.
こうした中央銀行などの特定の発行体により発行された唯一の通貨を扱うデジタル・キャッシュ・システムとは異なり、バウチャー取引システムは、複数の発行体によって発行されたバウチャーを処理する必要があります。
(b) Various types of vouchers
（b）は、バウチャーの様々な種類
Unlike a digital cash system that only handles a currency, the system MUST handle various types of vouchers, such as gift certificates, coupons, and loyalty points.
唯一の通貨を扱うデジタル・キャッシュ・システムとは異なり、システムは、商品券、クーポン、および忠誠ポイントとしてバウチャーの様々なタイプを、処理する必要があります。
(c) Preventing forgery
（c）は偽造防止
Only the issuer can cause a valid voucher to be issued. It MUST NOT be possible for other parties to cause a valid voucher to be created.
唯一の発行者が発行する有効なバウチャーを引き起こす可能性があります。他の当事者が作成する有効なバウチャーを引き起こすことが可能であるはずがありません。
(d) Preventing alteration
（d）の変化を防止
Voucher MUST NOT be altered during circulation except that the transfer transaction, in which the voucher holder is rewritten, is permitted. Only the current holder can initiate a transfer transaction.
バウチャーは、バウチャーホルダが書き換えられた転送トランザクションは、許可されていることを除いて、循環中に変更してはいけません。唯一の現在の所有者は、転送トランザクションを開始することができます。
(e) Preventing duplicate-redemption
（e）の重複償還を防止
A voucher MUST NOT be redeemable once it has been consumed (the result of some redemption transactions). Only the holder can initiate a redemption transaction.
それは（一部の償還取引の結果）が消費されたら、バウチャーを償還しているはずがありません。唯一の保有者は、償還トランザクションを開始することができます。
(f) Preventing reproduction
（f）の再生を防止
Voucher MUST NOT be reproduced while in circulation. That is, there must be only one valid holder of any particular voucher at any particular time.
バウチャーは、循環におけるながら再現してはなりません。つまり、任意の特定の時間に特定のバウチャーの唯一の有効なホルダーがなければなりません。
(g) Non-repudiation
（G）非否認
It SHOULD NOT be possible to the issuer to repudiate the issuance, or the holder to repudiate the transfer or redemption of a voucher, after it is issued, transferred or redeemed.
それはそれは、発行した転送または償還された後、バウチャーの移転や償還を否認するために発行、またはホルダーを否認する発行者に可能にすべきではありません。
(h) Ensuring privacy
（H）のプライバシーを確保
Current and previous holders of a voucher SHOULD be concealed from someone coming into possession of the voucher.
バウチャーの現在および以前の所有者は、バウチャーの所有物に入ってくる人から隠されるべきです。
(i) Trust manageability
（ⅰ）トラストの管理
If a wide variety of vouchers are in circulation, it might be difficult for users to judge whether a voucher can be trusted or not. To assist such users, a trust management function that verifies the authenticity of a voucher SHOULD be supported.
バウチャーの多種多様な流通している場合は、ユーザーがバウチャーが信頼できるかどうかを判断することは難しいかもしれません。こうしたユーザーを支援するために、バウチャーの正当性を検証信託管理機能がサポートされる必要があります。
(j) Scalability
（j）のスケーラビリティ
A single centralized broker that sells all types of vouchers, or a centralized authority that authenticates all issuers or other participants, SHOULD NOT be assumed. A system that relies on a single centralized organization is excessively frail; failure in that organization causes complete system failure.
バウチャーのすべての種類を販売している単一の集中ブローカー、またはすべての発行体や他の参加者を認証する集中型の権限は、想定されるべきではありません。単一の集中組織に依存して、システムが過度に虚弱です。その組織の障害は、完全なシステム障害が発生します。
(k) Efficiency
（K）効率
It MUST be possible to implement VTS efficiently. Many applications of vouchers, e.g., event ticket or transport passes, require high performance, especially when the voucher is redeemed.
効率的にVTSを実現することが可能でなければなりません。バウチャーの多くのアプリケーションは、例えば、イベントのチケットや輸送パスは、バウチャーが償還された場合は特に、高いパフォーマンスを必要とします。
(l) Simplicity
（L）シンプル
It SHOULD be possible to implement VTS simply. Simplicity is important to reduce the cost of implementation. It is also important in understanding the system, which is necessary for trust in the system.
単に、VTSを実装することが可能なはずです。シンプルさが、実装のコストを低減することが重要です。また、システムの信頼のために必要なシステムを、理解する上で重要です。
To implement a VTS, Voucher Trading Protocol (VTP), VTS Application Programming Interface (VTS-API), and Generic Voucher Language (GVL) must be developed. The objectives, benefits, and limitations of standardization for each specification are discussed below.
VTS、クーポン取引プロトコル（VTP）を実装するには、VTSアプリケーション・プログラミング・インタフェース（VTS-API）、および一般的なバウチャーの言語（GVL）が開発しなければなりません。各仕様の目的、利点、および標準化の制限は、以下に説明されています。
To achieve interoperability among multiple VTSs developed by independent VTS Providers, standard protocols for issuing, transferring, or redeeming vouchers will be needed. However, there are several ways of implementing VTS. For discount coupons or event tickets, for example, the smart-card-based decentralized offline VTS is often preferred, whereas for bonds or securities, the centralized online VTS may be preferred. It is impractical to define any standard protocol at this moment.
独立したVTSプロバイダによって開発された複数のVTS間の相互運用性を実現するために、発行転送、または償還バウチャーのための標準的なプロトコルが必要になります。しかし、VTSを実装するにはいくつかの方法があります。割引クーポンやイベントチケットの場合は、例えば、スマートカードベースの分散型オフラインVTSは、多くの場合、債券や証券のに対し、中央集中型のオンラインVTSが好ましいことも、好ましいです。この時点で任意の標準プロトコルを定義することは非現実的です。
To provide freedom in terms of VTS selection for issuers and application developers, a standard Voucher Trading System Application Programming Interface (VTS-API) that can encapsulate VTS implementations should be specified. It allows a caller application to issue, transfer, and redeem voucher in a uniform manner independent of the VTS implementation. Basic functions, i.e., issue, transfer, and redeem, provided by VTS-API can be straightforwardly derived from the VTS model described in this document. More design details of the VTS-API will be discussed in a separate document or a separate VTS-API specification.
発行者およびアプリケーション開発者のためのVTSの選択の面で自由を提供するには、VTSの実装をカプセル化することができ、標準のクーポン取引システムアプリケーションプログラミングインターフェイス（VTS-API）が指定されなければなりません。これは、転送、呼び出し側アプリケーションが発行することを可能にし、VTSの実装の均一な方法とは独立にバウチャーを引き換えます。基本的な機能は、VTS-APIによって提供される、すなわち、問題、転送、および償還は、直接的にこの文書に記載さVTSモデルから導出することができます。 VTS-APIのより多くの設計の詳細は、別の文書または別のVTS-API仕様書に説明されます。
To satisfy the diverse requirements placed on VTS (see Section 3), a standard Generic Voucher Language (GVL) that realizes various voucher properties should be specified. This approach ensures that VTS is application independent. The language should be able to define diverse Promises P of the voucher <I, P, H> to cover tickets, coupons, loyalty points, and gift certificates uniformly. Specifying I and H is a VTS implementation issue and can be achieved by using a public key, hash of a public key, URI or other names with scope rule.
VTS（セクション3参照）上に配置された多様な要件を満たすために、様々なバウチャーの特性を実現する標準汎用券言語（GVL）を指定しなければなりません。このアプローチは、VTSは、アプリケーションに依存していることを保証します。言語は一様に、チケット、クーポン、ロイヤリティポイント、及び商品券をカバーするために、多様な約束バウチャーのP <I、P、H>を定義することができるはずです。 IやHを指定すると、VTSの実装の問題であり、公開鍵、公開鍵のハッシュ、URIまたはスコープ規則に他の名前を使用することによって達成することができます。
In the following section, we discuss GVL Requirements in detail.
次のセクションでは、我々は詳細にGVLの要件を議論します。
Semantics supported by the language and their requirements levels are described below in detail.
言語とその要件レベルでサポートされているセマンティクスについて詳細に説明されています。
(a) Validity control
（a）は、妥当性制御
The invalidation (punching) method that is executed when the voucher is redeemed depends on the type of the voucher. For example, a loyalty point will be invalidated if the point is redeemed but a membership card can be used repeatedly regardless of the number of times presented. The language MUST be able to define how validity is modified. Additionally, the language MUST be able to define the validity period, start date and end date.
無効化（パンチング）バウチャーを償還されたときに実行される方法は、伝票のタイプに依存します。例えば、ポイントが償還された場合に忠誠ポイントが無効になりますが、会員カードを繰り返しかかわらず、提示された回数の使用することができます。言語は妥当性が修正される方法を定義することができなければなりません。また、言語は、有効期間、開始日と終了日を定義することができなければなりません。
(b) Transferability control
（b）は、転写性制御
Some types of vouchers require transferability. The language MUST be able to specify if a voucher can be transferred.
バウチャーの種類によっては、転写が必要です。言語は、バウチャーを転送することができるかどうかを指定することができなければなりません。
(c) Circulation control
（C）循環制御
Depending on the type of the voucher, various circulation requirements or restrictions must be satisfied [F99], for example, only qualified shops can issue particular vouchers or only a certain service provider can punch (invalidate) particular vouchers. The language SHOULD be able to specify such circulation requirements.
バウチャーのタイプに応じて、様々な循環要件や制限は、[F99]を満たさなければならない、例えば、唯一の資格をお店には、特定のバウチャーを発行することができますのみ、特定のサービスプロバイダは、（無効）特定のバウチャーをパンチすることができます。言語は、このような循環要件を指定することができるべきです。
(d) Anonymity control
（D）匿名制御
Different types of voucher will require different levels of anonymity. The language SHOULD be able to achieve the required level of anonymity.
バウチャーの異なるタイプの匿名性の異なるレベルを必要とします。言語は、匿名性の必要なレベルを達成することができるべきです。
(e) Understandability
（e）のわかりやすさ
The terms and description of a voucher SHOULD be objectively understood by the participants, because this will contribute to reducing the number of disputes on the interpretation of the vouchers promised.
これは約束したバウチャーの解釈上の紛争の数を減らすことに貢献していきますので、バウチャーの用語と説明は客観的、参加者が理解されるべきです。
(f) State manageability
（f）の状態の管理
Some types of vouchers have properties the values of which may change dynamically while in circulation, e.g., payment status, reservation status, or approval status. The language MAY support the definition of such properties.
バウチャーのいくつかの種類が流通している、例えば、支払い状況、予約状況、または承認ステータスながらの値が動的に変更される可能性の性質を持っています。言語は、そのような特性の定義をサポートすることができます。
(g) Composability
（G）コンポーザ
Some types of vouchers consist of several sub-vouchers, which may be issued separately from the original vouchers typically because the vouchers are issued by different organizations or issued at different times. The language MAY support compound vouchers composed of multiple sub-vouchers.
バウチャーのいくつかのタイプは、バウチャーは異なる組織によって発行された、または異なる時間に発行されるので、典型的には、元のバウチャーは別に発行することができるいくつかのサブバウチャー、から成ります。言語は、複数のサブバウチャーからなる化合物のバウチャーをサポートするかもしれません。
To achieve consistency with other related standards shown below, the syntax of the language MUST be based on XML [XML].
以下に示す他の関連規格との整合性を達成するために、言語の構文は、[XML] XMLに基づいていなければなりません。
The language syntax MUST enable any application-specific property, e.g., seat number, flight number, etc. to be defined. A schema definition language that can be translated into application-specific DTDs may be needed.
言語の構文を定義するために、例えば、等座席番号、フライト番号を、任意のアプリケーション固有のプロパティを有効にする必要があります。アプリケーション固有のDTDに変換することができ、スキーマ定義言語が必要な場合があります。
The language MUST provide the parameters necessary to establish security. Security requirements, however, mainly follow VTS requirements described in Section 3 rather than GVL requirements.
言語は、セキュリティを確立するために必要なパラメータを提供しなければなりません。セキュリティ要件は、しかし、主に第3節ではなくGVL要件で説明VTSの要件に従ってください。
The vouchers may be stored in a smart card or PDA with a restricted amount of memory. Large definitions may incur long transfer and processing times, which may not be acceptable. The language SHOULD enable the efficient definition of vouchers
バウチャーは、メモリの制限された量で、スマートカードやPDAに保存することができます。大定義は許容できない可能性がある、長い転送及び処理時間を被る可能性があります。言語は、バウチャーの効率的な定義を有効にする必要があります
The language specification SHOULD be consistent with the following specifications:
言語仕様は、以下の仕様と一致する必要があります。
(1) Internet Open Trading Protocol v1.0 [IOTP] (2) XML-Signature [XMLDSIG] (3) Extensible Markup Language (XML) Recommendation [XML] (4) ECML Version 2 [ECML]
（1）インターネットオープン取引プロトコルv1.0の[IOTP]（2）XML-署名[XMLDSIG]（3）拡張マークアップ言語（XML）勧告[XML]（4）ECMLバージョン2 [ECML]
An example of a voucher definition in GVL is described below. This example defines a five dollar discount coupon for specific merchandise, a book with ISBN number 0071355014. This coupon is circulated using a VTS called "Voucher Exchanger". To claim this offer, one coupon must be spent. The coupon is valid from April 1st in 2001 to March 31st in 2002.
GVLにおける伝票の定義の例を以下に説明します。この例では、特定の商品のために5ドルの割引クーポン、このクーポンは「クーポン交換器」と呼ばれるVTSを使用して循環させるISBN番号0071355014.で書籍を定義します。このオファーを主張するには、1つのクーポンを過ごしている必要があります。クーポンは、2002年3月31日に2001年4月1日から有効です。
<?xml version="1.0"?> <Voucher xmlns="urn:ietf:params:xml:schema:vts-lang" xmlns:vts="http://www.example.com/vts"> <Title>IOTP Book Coupon</Title> <Description>$5 off IOTP Book</Description> <Provider name="Voucher Exchanger"> <vts:Version>VE2.31</vts:Version> </Provider> <Value type="discount" spend="1"> <Fixed amount="5" currency="USD"/> </Value>
<？xml version = "1.0"？> <クーポンのxmlns = "壷：IETF：のparams：XML：スキーマ：VTS-LANG" のxmlns：VTS = "http://www.example.com/vts"> <タイトル> IOTP図書券</タイトル> IOTPブックオフ<説明> $ 5 '/記述> <プロバイダー名= "引換券交換"> <VTS：バージョン> VE2.31 </ VTS：バージョン> </プロバイダ> <値の種類=」割引」支出= "1"> <固定量= "5" 通貨= "USD" /> </バリュー>
<Merchandise> <bk:Book xmlns:bk="http://www.example.com/bk" bk:isbn="0071355014"/> </Merchandise> <ValidPeriod start="2001-04-01" end="2002-03-31"/> </Voucher>
<商品> <BK：ブックのxmlns：BK = "http://www.example.com/bk" BK：ISBN = "0071355014" /> </商品> <有効期間開始= "2001年4月1日" 終わり= "2002-03-31" /> </クーポン>
This section describes, as a typical electronic commerce example involving advertisement, payment, and delivery transactions, the use of vouchers and VTS, and shows that vouchers can be used as an effective way to coordinate autonomous services that have not yet established trust among each other.
このセクションでは、広告、支払い、配送の取引、バウチャーとVTSの使用を伴う典型的な電子商取引の一例として、説明、およびバウチャーはまだお互いの間に信頼関係を確立していない自律サービスを調整するための効果的な方法として使用できることを示しています。
Figure 2 shows a typical electronic commerce example of a consumer searching for goods or services and making a purchase:
図2は、消費者が商品やサービスを検索し、購入を行うの典型的な電子商取引の例を示します。
----------
------------------------------------------->| Ad |
| (1) Acquire a coupon | Agency |
| ----------
|
| (2) Send payment information ----------
| --------------------------------------->| Payment |
| | Acquire a gift certificate | Handler |
| | ----------
v v (3) Transfer the coupon &
---------- gift certificate ----------
| Consumer |<------------------------------------>| Merchant |
---------- Acquire an exchange ticket & ----------
^ loyalty points
|
| (4) Transfer the exchange ticket ----------
------------------------------------------->| Deliverer|
Supply goods or services | Handler |
----------
Figure 2. Application example of vouchers
バウチャーの図2.応用例
(1) Use a search engine to find the desired goods or services and acquire a coupon from an ad agency that represents the right to purchase the goods or services at a discounted price.
（1）希望の商品やサービスを検索し、割引価格で商品やサービスを購入する権利を表し広告代理店からのクーポンを取得するために検索エンジンを使用してください。
(2) Acquire a gift certificate from a payment handler in exchange for cash or payment information.
（2）現金または支払い情報と引き換えに支払いハンドラからの贈り物の証明書を取得します。
(3) Transfer the coupon and gift certificate to the merchant, and in exchange acquire an exchange ticket and loyalty points.
（3）商人にクーポン、ギフト証明書を転送し、引き換えに交換チケットとロイヤリティポイントを獲得します。
(4) Transfer the exchange ticket to the deliverer handler and receive the goods or services.
（4）配送業者ハンドラに交換チケットを転送し、商品やサービスを受けます。
In this example, the coupon, gift certificate, and exchange ticket each represent the media that yields the above four transactions.
この例では、クーポン、商品券、および交換チケットはそれぞれ、上記の4つのトランザクションを生成するメディアを表しています。
Note that it is not necessary to trust the participants involved in the transactions, but to trust the vouchers themselves. In other words, there is no need to exchange contracts among the participants beforehand if the vouchers themselves are trusted.
取引に関与し、参加者を信頼するが、バウチャー自体を信頼する必要はないことに注意してください。言い換えれば、バウチャー自体が信頼されている場合は、事前に参加者間の契約を交換する必要はありません。
Take the exchange ticket as an example; even if the delivery handler does not trust the consumer, the merchant that issued the exchange ticket is trusted, and if the VTS guarantees that there is no duplication in the trading process of the exchange ticket, there is no problem in swapping the exchange ticket for the goods or services. In the same way, even if the merchant does not trust the delivery handler, the issuance of the exchange ticket can be verified, and if the VTS guarantees that there is no duplication in the trading process of the exchange ticket, there is no problem in swapping the exchange ticket for the goods or services (Fig. 3). In other words, if there is trust in the issuer and the VTS, trust among the participants involved in the transactions is not required.
一例として、交換チケットを取ります。配信ハンドラが消費者を信頼していない場合でも、引換券を発行した商人は、信頼され、VTSは、引換券の取引過程には重複がないことを保証した場合、引き換えチケットを交換するには問題はありません商品やサービス。同様に、商人が配信ハンドラを信頼していない場合でも、引換券の発行を検証することができ、かつVTSは引換券の取引過程には重複がないことを保証した場合に問題はありません（図3）商品やサービスと引き換えチケットを交換します。発行者とVTSの信頼がある場合は、他の言葉では、取引に関わる参加者間の信頼関係は必要ありません。
Exchange Exchange
---------- ticket ---------- ticket ----------
| Consumer |-------->| Delivery |-------->| Merchant |
| |<--------| Handler |<--------| |
---------- Goods or ---------- Goods or ----------
services services
Figure 3. Coordination of untrusted participants using exchange ticket
交換チケットを使用して信頼されていない参加者の図3.コーディネーション
In general, it is more difficult to trust individuals than companies, so this characteristic of VTS is especially important.
一般的に、企業よりも個人を信頼することはより困難であるので、VTSのこの特性は特に重要です。
Moreover, the transactions involving vouchers have desirable features with respect to privacy protection. For example, in the above exchange ticket scenario, the consumer can designate the delivery service for himself, so the merchant does not even need to know any personal information such as the delivery address. Furthermore, by designating a convenience store etc. as the receiving point, the delivery service does not need to know the address of the consumer.
また、バウチャーを含む取引は、プライバシー保護に関して望ましい特徴を持っています。例えば、上記の引換券のシナリオでは、消費者が自分自身のための配信サービスを指定することができますので、商人にも、このような配信アドレスなど個人情報を知る必要はありません。さらに、受信点として、コンビニエンスストアなどを指定することにより、配信サービスは、消費者のアドレスを知っている必要はありません。
- Is it possible to implement a VTS using digital certificates?
- それは、デジタル証明書を使用してVTSを実装することは可能ですか？
If transferability is not required, a voucher can be easily implemented as a digital certificate, i.e., Signed_I(I, P, H), where the phrase "Signed_I" means that the entire block is signed by the issuer's digital signature. If transferability is required, then H is changed during the transfer, i.e., the signature is broken. Additionally, online data base checking or tamper-resistant devices are required to prevent duplicate-redemption.
転写が必要でない場合、伝票を容易語句「Signed_I」はブロック全体を発行者のデジタル署名によって署名されることを意味する。デジタル証明書、すなわち、Signed_I（I、P、H）、として実装することができます転写が必要な場合は、H、すなわち、署名が破壊され、転送中に変更されます。また、オンライン・データベースは、チェックや改ざん耐性のデバイスが重複し、償還を防止するために必要とされます。
- What is the difference from digital-cash?
- デジタル現金との違いは何ですか？
VTS must handle various types of vouchers, such as gift certificates, coupons, or loyalty points unlike a digital cash system which handles only currency. Additionally, vouchers are issued by different issuers.
VTSは、商品券、クーポン、または唯一の通貨を扱うデジタル・キャッシュ・システムとは異なり、忠誠ポイントとしてバウチャーの様々なタイプを、処理する必要があります。さらに、バウチャーは異なる発行体によって発行されています。
- Is it possible to support "digital property rights?
- それは「デジタル財産権をサポートすることは可能ですか？
Digital property rights can be represented as a voucher and can be traded using VTS. However, some protected rendering system would be required to regenerate the digital contents securely in order to support digital property rights. These requirements are out of scope of VTS.
デジタル財産権は、バウチャーのように表すことができるとVTSを使用して取引することができます。ただし、一部の保護されたレンダリングシステムは、デジタル財産権をサポートするために、安全にデジタルコンテンツを再生するのに必要とされるであろう。これらの要件は、VTSの範囲外です。
Security issues are discussed in Section 3.2 and 5.3.
セキュリティ問題はセクション3.2と5.3で説明されています。
I would like to thank Masayuki Terada and Perry E. Metzger, for their valuable comments.
私は彼らの貴重なコメントのために、正幸寺田とペリーE.メッツガーに感謝したいと思います。
[ECML] ECML Version 2, Work in Progress.
[ECML] ECMLバージョン2は、進行中の作業します。
[F99] K. Fujimura, H. Kuno, M. Terada, K. Matsuyama, Y. Mizuno, and J. Sekine, "Digital-Ticket-Controlled Digital Ticket Circulation", 8th USENIX Security Symposium, August 1999.
[F99] K.藤村、H.久野、M.寺田、K.松山、Y.水野、及びJ.関根、 "デジタル・チケット制御されるデジタルチケット循環"、第8回USENIXセキュリティシンポジウム、1999年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[IOTP] Burdett, D., "The Internet Open Trading Protocol", RFC 2801, April 2000.
[IOTP]バーデット、D.、 "インターネットのオープン・トレーディング・プロトコル"、RFC 2801、2000年4月。
[MF99] K. Matsuyama and K. Fujimura, "Distributed Digital-Ticket Management for Rights Trading System", 1st ACM Conferences on Electronic Commerce, November 1999.
[MF99] K.松山とK.藤村、「権利取引システムのための分散型デジタル・チケットの管理」、電子商取引、1999年11月に第1回ACM会議。
[T00] M. Terada, H. Kuno, M. Hanadate, and K. Fujimura, "Copy Prevention Scheme for Rights Trading Infrastructure", 4th Smart Card Research and Advanced Application Conference (CARDIS 2000), September 2000.
[T00] M.寺田、H.久野、M. Hanadate、およびK.藤村、「権利取引インフラのためのコピー防止スキーム」、第4回スマートカードの研究とアドバンスト・アプリケーション会議（CARDIS 2000）、2000年9月。
[XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October 2000.
[XML] "拡張マークアップ言語（XML）1.0（第二版）"、W3C勧告、<http://www.w3.org/TR/REC-xml>、2000年10月。
[XMLDSIG] "XML-Signature Syntax and Processing", A W3C Proposed Recommendation, <http://www.w3.org/TR/xmldsig-core>, August 2001.
[XMLDSIG] "XML-署名構文と処理"、W3C勧告案、<http://www.w3.org/TR/xmldsig-core>、2001年8月。
Ko Fujimura NTT Corporation 1-1 Hikari-no-oka Yokosuka-shi Kanagawa, 239-0847 JAPAN
こ ふじむら んっｔ こｒぽらちおん １ー１ ひかりーのーおか よこすかーし かながわ、 ２３９ー０８４７ じゃぱん
Phone: +81-(0)468-59-3814 Fax: +81-(0)468-59-8329 EMail: fujimura@isl.ntt.co.jp
電話：+ 81-（0）468-59-3814ファックス：+ 81-（0）468-59-8329 Eメール：fujimura@isl.ntt.co.jp
Donald E. Eastlake 3rd Motorola 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレーク第3モトローラ155ビーバー通りミルフォード、MA 01757 USA
Phone: +1-508-851-8280 EMail: Donald.Eastlake@motorola.com
電話：+ 1-508-851-8280 Eメール：Donald.Eastlake@motorola.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。