doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc3506.txt b/doc/rfc/rfc3506.txt
new file mode 100644
index 0000000..da20a53
--- /dev/null
+++ b/doc/rfc/rfc3506.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+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.
+
+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.
+
+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].
+
+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
+
+
+
+Fujimura & Eastlake          Informational                      [Page 1]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+   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
+
+1. Background
+
+   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.
+
+
+
+
+
+
+
+
+
+Fujimura & Eastlake          Informational                      [Page 2]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+2. Terminology and Model
+
+2.1 Voucher
+
+   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>.
+
+   Examples of P are as follows:
+
+   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  Take 10% off your total purchase by presenting this card.
+      (Membership card)
+
+   o  Take 50% off your total purchase with this coupon.  The purchase
+      transaction uses up the coupon.  (Coupon)
+
+   o  The bearer can access "http://..." for one month free.  (Free
+      ticket for sales promotion)
+
+   o  The bearer can exchange this ticket for the ordered clothes.
+      (Exchange ticket or Delivery note)
+
+   o  Seat number A-24 has been reserved for "a-concert" on April 2.
+      (Event ticket)
+
+   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.
+
+2.2 Participants
+
+   There are four types of participants in the voucher trading model:
+   issuer, holder, collector, and VTS provider.  Their roles are as
+   follows:
+
+   Issuer: Creates and issues a voucher.  Guarantees contents of
+      the voucher.
+
+
+
+
+
+Fujimura & Eastlake          Informational                      [Page 3]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+   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.
+
+   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.
+
+2.3 Voucher Trading System (VTS)
+
+   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
+
+   The VTS provider supplies a VTS that enables vouchers to be
+   circulated among the participants securely.
+
+   A formal definition of VTS is as follows:
+
+      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.
+
+      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],
+
+
+
+
+
+Fujimura & Eastlake          Informational                      [Page 4]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+      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].
+
+   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.
+
+   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.
+
+   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.
+
+      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.
+
+   Note that one or more of these transactions can be executed as part
+   of the same IOTP purchase transaction.  See details in Section 6.
+
+3. VTS Requirements
+
+   A VTS must meet the following requirements
+
+   (1) It MUST handle diverse types of vouchers issued by different
+       issuers.
+
+   (2) It MUST prevent illegal acts such as alteration, forgery, and
+       reproduction, and ensure privacy.
+
+   (3) It MUST be practical in terms of implementation/operation cost
+       and efficiency.
+
+   Each of these requirements is discussed below in detail.
+
+
+
+
+
+Fujimura & Eastlake          Informational                      [Page 5]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+3.1 Capability of handling diversity
+
+   (a) Different issuers
+
+   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
+
+   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.
+
+3.2 Ensuring security
+
+   (c) Preventing forgery
+
+   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
+
+   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
+
+   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
+
+   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
+
+   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.
+
+
+
+
+
+
+Fujimura & Eastlake          Informational                      [Page 6]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+   (h) Ensuring privacy
+
+   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.
+
+3.3 Ensuring practicality
+
+   (j) Scalability
+
+   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
+
+   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.
+
+   (l) Simplicity
+
+   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.
+
+4. Scope of VTS Specifications
+
+   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.
+
+4.1 Voucher Trading Protocol
+
+   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
+
+
+
+Fujimura & Eastlake          Informational                      [Page 7]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+   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.
+
+4.2 VTS-API
+
+   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.
+
+4.3 Generic Voucher Language
+
+   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.
+
+   In the following section, we discuss GVL Requirements in detail.
+
+5. GVL Requirements
+
+5.1 Semantics
+
+   Semantics supported by the language and their requirements levels are
+   described below in detail.
+
+   (a) Validity control
+
+   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.
+
+
+
+
+Fujimura & Eastlake          Informational                      [Page 8]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+   (b) Transferability control
+
+   Some types of vouchers require transferability.  The language MUST be
+   able to specify if a voucher can be transferred.
+
+   (c) Circulation control
+
+   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.
+
+   (d) Anonymity control
+
+   Different types of voucher will require different levels of
+   anonymity.  The language SHOULD be able to achieve the required level
+   of anonymity.
+
+   (e) Understandability
+
+   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
+
+   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
+
+   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.
+
+5.2 Syntax
+
+   To achieve consistency with other related standards shown below, the
+   syntax of the language MUST be based on XML [XML].
+
+
+
+
+
+
+Fujimura & Eastlake          Informational                      [Page 9]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+   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.
+
+5.3 Security
+
+   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.
+
+5.4 Efficiency
+
+   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
+
+5.5 Coordination
+
+   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]
+
+5.6 Example of GVL
+
+   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.
+
+   <?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>
+
+
+
+Fujimura & Eastlake          Informational                     [Page 10]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+     <Merchandise>
+       <bk:Book xmlns:bk="http://www.example.com/bk"
+                bk:isbn="0071355014"/>
+     </Merchandise>
+     <ValidPeriod start="2001-04-01" end="2002-03-31"/>
+   </Voucher>
+
+6. Application Scenarios
+
+   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.
+
+   Figure 2 shows a typical electronic commerce example of a consumer
+   searching for goods or services and making a purchase:
+
+                                                      ----------
+         ------------------------------------------->| 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
+
+   (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.
+
+   (2) Acquire a gift certificate from a payment handler in exchange for
+       cash or payment information.
+
+
+
+
+
+Fujimura & Eastlake          Informational                     [Page 11]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+   (3) Transfer the coupon and gift certificate to the merchant, and in
+       exchange acquire an exchange ticket and loyalty points.
+
+   (4) Transfer the exchange ticket to the deliverer handler and receive
+       the goods or services.
+
+   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.
+
+                      Exchange             Exchange
+          ----------  ticket   ----------  ticket   ----------
+         | Consumer |-------->| Delivery |-------->| Merchant |
+         |          |<--------| Handler  |<--------|          |
+          ----------  Goods or ----------  Goods or ----------
+                      services             services
+
+           Figure 3. Coordination of untrusted participants
+                              using exchange ticket
+
+   In general, it is more difficult to trust individuals than companies,
+   so this characteristic of VTS is especially important.
+
+   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.
+
+
+
+
+Fujimura & Eastlake          Informational                     [Page 12]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+7. Q & A
+
+   - Is it possible to implement a VTS using digital certificates?
+
+      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.
+
+   - 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.
+
+8. Security Considerations
+
+   Security issues are discussed in Section 3.2 and 5.3.
+
+9. Acknowledgments
+
+   I would like to thank Masayuki Terada and Perry E. Metzger, for their
+   valuable comments.
+
+10. References
+
+   [ECML]    ECML Version 2, Work in Progress.
+
+   [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.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Fujimura & Eastlake          Informational                     [Page 13]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+   [IOTP]    Burdett, D., "The Internet Open Trading Protocol", RFC
+             2801, April 2000.
+
+   [MF99]    K. Matsuyama and K. Fujimura, "Distributed Digital-Ticket
+             Management for Rights Trading System", 1st ACM Conferences
+             on Electronic Commerce, November 1999.
+
+   [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.
+
+   [XML]     "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A
+             W3C Recommendation, <http://www.w3.org/TR/REC-xml>, October
+             2000.
+
+   [XMLDSIG] "XML-Signature Syntax and Processing", A W3C Proposed
+             Recommendation, <http://www.w3.org/TR/xmldsig-core>, August
+             2001.
+
+11. Authors' Addresses
+
+   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
+
+   Phone:  +1-508-851-8280
+   EMail:  Donald.Eastlake@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+Fujimura & Eastlake          Informational                     [Page 14]
+
+RFC 3506              Voucher Trading System (VTS)            March 2003
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fujimura & Eastlake          Informational                     [Page 15]
+