Network Working Group K. Fujimura
Request for Comments: 3506 NTT
Category: Informational D. Eastlake
Motorola
March 2003
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.
版权所有（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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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
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
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.
凭证是索取服务或货物权利的数字表示。使用代金券，一个交易软件模块可以统一处理各种电子价值，包括积分或优惠券。
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>的三元组。
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)
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日的“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提供商。他们的角色如下：
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.
物联网模式[物联网]包括商户、发货人、消费者和其他参与者。他们在结算中扮演不同的角色，因为例如，商户可以被视为发行人或持有人，这取决于商户是自己创建凭证还是从批发商或制造商处购买凭证。如果商店收集礼券或优惠券，商家也可以成为收藏家。
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
<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的系统，VVS是{<I，P，H>|I in is，P in PS，H in HS}的子集，其中is是发行人的集合，PS是承诺的集合，HS是持有人的集合；悉尼威立雅运输公司禁止对其进行修改或复制，但以下三种交易除外：发行、转让和赎回。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.
转让转让交易是将<I，P，H>（在VVS中）的元组重写为<I，P，H'>（H<>H'），以反映原始持有人H的意图的行为。
Redemption There are two redemption transactions: presentation and consumption.
赎回有两种赎回交易：赠送和消费。
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.
表示事务是显示<I，P，H>元组（在VVS中）以反映持有者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.
消费交易是删除<I，P，H>（在VVS中）元组以反映凭证持有人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.
请注意，这些交易中的一个或多个可以作为同一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
(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
为了实现独立VTS提供商开发的多个VTS之间的互操作性，需要用于签发、传输或兑换凭证的标准协议。但是，有几种实施VTS的方法。购买折扣券或活动
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。目前定义任何标准协议都是不切实际的。
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>的不同承诺P，以统一涵盖门票、优惠券、忠诚度积分和礼券。指定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节中描述的VTS要求，而不是GVL要求。
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) 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中凭证定义的示例如下所述。此示例定义了特定商品的五美元折扣券，即ISBN编号为0071355014的书籍。此优惠券通过称为“凭证交换”的VTS进行流通。要申请此优惠，必须使用一张优惠券。优惠券有效期为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>
<?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>
<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.
作为涉及广告、支付和交付交易的典型电子商务示例，本节介绍了凭单和VT的使用，并说明凭单可作为协调尚未建立相互信任的自主服务的有效方式。
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 |
----------
----------
------------------------------------------->| 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.
在本例中，优惠券、礼券和兑换券分别代表产生上述四项交易的媒体。
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.
以兑换券为例；即使交付处理人不信任消费者，也信任发行兑换券的商户，并且如果悉尼威立雅运输公司保证兑换券交易过程中没有重复，那么用兑换券交换商品或服务也没有问题。以同样的方式，即使商户不信任交付处理人员，也可以验证交换票证的签发，并且如果悉尼威立雅运输公司保证交换票证的交易过程中没有重复，那么交换商品或服务的交换票证就没有问题（图3）。换言之，如果发行人和悉尼威立雅运输公司之间存在信任，则不需要交易参与者之间的信任。
Exchange Exchange
---------- ticket ---------- ticket ----------
| Consumer |-------->| Delivery |-------->| Merchant |
| |<--------| Handler |<--------| |
---------- Goods or ---------- Goods or ----------
services services
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.
如果不需要可转让性，则凭证可以很容易地实现为数字证书，即签名_i（i，P，H），其中短语“签名_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.
悉尼威立雅运输公司必须处理各种类型的代金券，如礼券、优惠券或忠诚积分，这与只处理货币的数字现金系统不同。此外，凭证由不同的发行人发行。
- 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.
我要感谢Terada Masayuki和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.Fujimura、H.Kuno、M.Terada、K.Matsuyama、Y.Mizuno和J.Sekine，“数字票证控制的数字票证流通”，第八届USENIX安全研讨会，1999年8月。
[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.，“互联网开放交易协议”，RFC2801，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，“权利交易系统的分布式数字票证管理”，第一届ACM电子商务会议，1999年11月。
[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，“版权交易基础设施的防拷贝方案”，第四届智能卡研究和高级应用会议（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
藤村幸男NTT公司1-1 Hikari no oka Yokosuka shi Kanagawa，239-0847日本
Phone: +81-(0)468-59-3814
Fax: +81-(0)468-59-8329
EMail: fujimura@isl.ntt.co.jp
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
Donald E.Eastlake 3rd Motorola美国马萨诸塞州米尔福德海狸街155号01757
Phone: +1-508-851-8280
EMail: Donald.Eastlake@motorola.com
Phone: +1-508-851-8280
EMail: 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编辑功能的资金目前由互联网协会提供。