[要約] 要約：RFC 3506は、Voucher Trading System（VTS）の要件と設計に関する情報を提供するものである。 目的：VTSの実装と運用に必要な要件と設計を明確にし、効果的なバウチャー取引システムの開発を支援する。
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)
バウチャー取引システムの要件と設計（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.
Copyright（c）The Internet Society（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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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はバウチャーホルダーになります。バウチャーは、<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 購入ごとに2つのロイヤルティポイントがカードに追加されます。50ポイントを収集すると、1つのアイテムが無料になります。（ロイヤルティポイント）
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)
o ベアラーは、「http：// ...」に1か月無料にアクセスできます。（販売促進のための無料チケット）
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日に「A-concert」のために予約されています（イベントチケット）
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.
Collector（またはExaminer）：バウチャーを収集または調査し、その約束を実装します。一般に、提供された商品またはサービスによって補償されます。
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）は、{<i、p、h> |のサブセットである有効なバウチャーVVSのセットを論理的に管理するシステムです。私はps、p in ps、h in hs}ここで、ここでは発行者のセット、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], 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].
これは、VVが集中データベースに物理的に保存されていることを意味するものではないことに注意してください。たとえば、1つの実装では、各所有者[T00]が運ぶ分散スマートカードにバウチャーを保存するか、各発行者または信頼できるサードパーティが管理する複数のサーバーに保存する場合があります。これは、信頼ポリシーおよび/または実装の問題[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 '>（h <> h'）として<i、p、h>（vvs）のタプルを書き換えるアクションです。
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の意図を反映するための<I、P、H>（VVS）のタプルを示すアクションです。この場合、バウチャーの所有権は、バウチャーが引き換えられたときに保持されます。たとえば、ライセンスまたはパスポートの償還（プレゼンテーション）です。
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の意図と特性を反映するために<i、p、h>（VVS）のタプルを削除するアクションです。バウチャーの所有権は無効になる場合があります。または、イベントチケットや電話カードの償還など、バウチャーが引き換えられたときに有効な回数が減少します。
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) 重複したredいの防止
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.
循環中はバウチャーを複製してはなりません。つまり、特定のバウチャーの有効な保有者が1つだけである必要があります。
(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
(i) 信頼の管理性
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が優先されることがよくありますが、債券または証券の場合、集中化されたオンラインVTが好ましい場合があります。現時点で標準プロトコルを定義することは非現実的です。
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がアプリケーションに依存しないことが保証されます。言語は、チケット、クーポン、ロイヤルティポイント、ギフト券を均一にカバーするために、バウチャー<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.
言語は、セキュリティを確立するために必要なパラメーターを提供する必要があります。ただし、セキュリティ要件は、主にGVL要件ではなくセクション3で説明されている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]
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ドル割引クーポン、ISBN番号0071355014の本を定義しています。このクーポンは、「バウチャー交換器」と呼ばれるVTSを使用して配布されます。このオファーを主張するには、1つのクーポンを費やす必要があります。クーポンは、2001年4月1日から2002年3月31日まで有効です。
<?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>
<Merchandise>
<bk:Book xmlns:bk="http://www.example.com/bk"
bk:isbn="0071355014"/>
</Merchandise>
<ValidPeriod start="2001-04-01" end="2002-03-31"/>
</Voucher>
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. Exchangeチケットを使用した信頼されていない参加者の調整
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.
転送可能性が不要な場合、バウチャーはデジタル証明書、つまり署名_i（i、p、h）として簡単に実装できます。ここで、「signed_i」というフレーズは、ブロック全体が発行者のデジタル署名によって署名されることを意味します。転送可能性が必要な場合、転送中に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.
貴重なコメントをしてくれたMasayuki TeradaとPerry E. Metzgerに感謝したいと思います。
[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。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[IOTP] Burdett, D., "The Internet Open Trading Protocol", RFC 2801, April 2000.
[IOTP] Burdett、D。、「The Internet Open Trading Protocol」、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. MatsuyamaおよびK. Fujimura、「Ridesed Digital-Ticket Management for Rights Trading System」、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. Terada、H。Kuno、M。Hanadate、およびK. Fujimura、「権利取引インフラストラクチャのコピー予防スキーム」、第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（第2版）」、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-signature syntax and processing"、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
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
Donald E. Eastlake 3rd Motorola 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク第3モトローラ155ビーバーストリートミルフォード、マサチューセッツ州01757 USA
Phone: +1-508-851-8280
EMail: Donald.Eastlake@motorola.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。