RFC 3506

Requirements and Design for Voucher Trading System (VTS)

📅 published March 2003, from ietf

RFC 3506: Requirements and Design for Voucher Trading System (VTS) 💖 (Part 1 of 3)

okay bestie, welcome to RFC 3506 🎀✨ it's giving Informational, so it's just here to share info, not a standard 💅

  • Request for Comments: 3506
  • Network Working Group
  • Authors: K. Fujimura (NTT) and D. Eastlake (Motorola)
  • Category: Informational
  • Date: March 2003
  • Obsoletes / Updates: nothing listed in this document 🙈

Status of This Memo 🌸

this memo is just giving info for the Internet community 🦋 it does not specify an Internet standard of any kind, and distribution of it is unlimited.

Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒

Abstract ✨

so crediting loyalty points and collecting digital coupons or gift certificates is super common in shopping and trading, right? 🛍️ these activities can all be generalized with the idea of a "voucher", which is a digital representation of the right to claim goods or services. this doc presents a Voucher Trading System (VTS) that circulates vouchers securely, plus its terminology. it also lists design principles and requirements for VTS and for the Generic Voucher Language (GVL), which lets you describe all kinds of vouchers 🧚

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

   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 🧚

okay so real talk, people constantly need to credit loyalty points, collect digital coupons or gift certificates, and so on, just to finish purchases or other trading transactions IRL. internet commerce is catching on too 📈 but if every single application needed its own issuing and collecting system for these points or coupons, the implementation cost would be excessive. that would seriously block these mechanisms from being used in electronic commerce 😭 consumers might also end up having to install a bunch of software modules just to handle these points or coupons 💀

a voucher is a digital representation of the right to claim services or goods 🎟 with vouchers, a wide range of electronic values, including points or coupons, can be handled in a uniform way with one trading software module. no cap, that's so clean 🫶

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 for the Generic Voucher Language (GVL), which lets you describe all kinds of vouchers 🌈

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 or digital certificates, this document gives a formal definition of vouchers, and it's iconic 👑

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:

  • Two loyalty points are added to the card per purchase. If you collect 50 points, you'll get one item free. (Loyalty points) 🍓
  • Take 10% off your total purchase by presenting this card. (Membership card) 💳
  • Take 50% off your total purchase with this coupon. The purchase transaction uses up the coupon. (Coupon) ✂️
  • The bearer can access "http://..." for one month free. (Free ticket for sales promotion) 🎁
  • The bearer can exchange this ticket for the ordered clothes. (Exchange ticket or Delivery note) 👗
  • Seat number A-24 has been reserved for "a-concert" on April 2. (Event ticket) 🎶

note that P doesn't need to be described in 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 used 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:

  • Issuer: creates and issues a voucher. Guarantees the 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. 🔐

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 an issuer or a 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 certificates or coupons 🛒

2.3 Voucher Trading System (VTS) 🔄

a voucher is generated by the issuer, traded among holders (users), and finally 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 🔐 the formal definition of VTS is:

   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 mean VVS is stored physically in one 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 by trusted third parties. this is a trust policy and/or implementation issue [MF99] 🧠

here are the three transactions:

  • 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. 🎁
    • Presentation: 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 🛂
    • Consumption: 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 👀

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. this is the main character energy of the whole design 👑

(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. it's giving variety, bestie 💖

3.2 Ensuring security 🔐✨

(c) Preventing forgery 🎀

Okay so only the issuer can make a valid voucher appear, bestie. Nobody else is allowed to make one happen, so it MUST NOT be possible for other parties to cause a valid voucher to be created. 🙅‍♀️

(d) Preventing alteration 🛡️

Vouchers are not allowed to get edited while they're floating around. The one exception is the transfer transaction, where the voucher holder gets rewritten, and that's totally fine. Only the current holder can start a transfer transaction, so the Voucher MUST NOT be altered during circulation, except for that transfer. 💅

(e) Preventing duplicate-redemption 🎟️

Once a voucher has been consumed (that's what happens after some redemption transactions), it MUST NOT be redeemable again. Double-dipping is a no-go. Only the holder can start a redemption transaction. 🚫

(f) Preventing reproduction 👯

A voucher MUST NOT be reproduced while it's in circulation. There has to be only one valid holder of any particular voucher at any particular time. No clones, no copies, no drama. 🫶

(g) Non-repudiation 📜

Once something is issued, transferred, or redeemed, it SHOULD NOT be possible for the issuer to repudiate the issuance, or for the holder to repudiate the transfer or redemption. Like, no "that never happened" after the fact. 🙈

(h) Ensuring privacy 🤫

Current and previous holders of a voucher SHOULD be concealed from anyone who comes into possession of the voucher. Main character privacy energy. 🦋

(i) Trust manageability 🔍

If a wide variety of vouchers are in circulation, it might be hard for users to tell whether a voucher can be trusted. To help with that, a trust management function that verifies the authenticity of a voucher SHOULD be supported. Think of it as a vibe check for vouchers. ✨

3.3 Ensuring practicality 🛠️

(j) Scalability 📈

A single centralized broker that sells every type of voucher SHOULD NOT be assumed. Same goes for a centralized authority that authenticates all issuers or other participants. Relying on one central organization is excessively frail 😭, because if that organization fails, the whole system fails. Not it. 💀

(k) Efficiency ⚡

It MUST be possible to implement VTS efficiently. Lots of voucher uses, like event tickets or transport passes, need high performance, especially when the voucher is redeemed. No lag allowed. 🚀

(l) Simplicity 🧸

It SHOULD be possible to implement VTS simply. Simplicity keeps implementation costs down, and it also helps people understand the system, which is needed if they're going to trust it. 🌸

4. Scope of VTS Specifications 🗺️✨

To implement a VTS, you need three things: the Voucher Trading Protocol (VTP), the VTS Application Programming Interface (VTS-API), and the Generic Voucher Language (GVL). Each one needs to be developed. Here's the tea on what standardizing each one does, and doesn't, do. 🍵

4.1 Voucher Trading Protocol 🤝

For different VTS providers to work together with each other, standard protocols for issuing, transferring, or redeeming vouchers will be needed. But there are lots of ways to implement a VTS. For discount coupons or event tickets, a smart-card-based decentralized offline VTS is often preferred. For bonds or securities, a centralized online VTS may be preferred instead. So defining one standard protocol right now is impractical. 🙅‍♀️💖

4.2 VTS-API 🔌

Issuers and application developers should get to pick whichever VTS they like, so a standard Voucher Trading System Application Programming Interface (VTS-API) that can wrap around VTS implementations should be specified. It lets a caller application issue, transfer, and redeem vouchers in a uniform way, no matter which VTS is underneath. 🧁 The basic functions (issue, transfer, and redeem) can be pretty easily derived from the VTS model in this document. More design details will be covered in a separate document or a separate VTS-API specification. 📚

4.3 Generic Voucher Language 🗣️

To meet the many different requirements placed on VTS (see Section 3), a standard Generic Voucher Language (GVL) that makes various voucher properties possible should be specified. This keeps VTS application independent. The language should be able to define the many Promises P of a voucher <I, P, H> so it can cover tickets, coupons, loyalty points, and gift certificates in one uniform way. ✨ How I and H get specified is a VTS implementation issue, and it can be done with a public key, a hash of a public key, a URI, or other names with a scope rule. 🔑

In the following section, we get into the GVL Requirements in detail. 👀

5. GVL Requirements 📝💜

5.1 Semantics 🧠

Here are the semantics the language supports, along with their requirement levels. Let's go through them. 💅

(a) Validity control 🎫

How a voucher gets invalidated (punched) when it's redeemed depends on what type of voucher it is. A loyalty point gets invalidated once it's redeemed, but a membership card can be used over and over, no matter how many times it's presented. The language MUST be able to define how validity is modified. It MUST also be able to define the validity period, with a start date and an end date. 📅

(b) Transferability control 🔁

Some vouchers need to be transferable. The language MUST be able to specify whether a voucher can be transferred. 🦋

(c) Circulation control 🌀

Different voucher types come with different circulation requirements or restrictions that 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 these circulation requirements. 🏪

(d) Anonymity control 🕶️

Different types of voucher need 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. This helps cut down on disputes about how the promised vouchers should be interpreted. Clear rules, no arguments. 🙌

(f) State manageability 🔄

Some vouchers have properties whose values can change while they're in circulation, like payment status, reservation status, or approval status. The language MAY support defining such properties. 🪄

(g) Composability 🧩

Some vouchers are made up of several sub-vouchers. Those might get issued separately from the original voucher, usually because different organizations issued them or they were issued at different times. The language MAY support compound vouchers made of multiple sub-vouchers. 🪆

5.2 Syntax 💻

To stay consistent with the related standards listed below, the syntax of the language MUST be based on XML [XML]. 🌷

The language syntax MUST enable any application-specific property to be defined, like a seat number, a flight number, and so on. A schema definition language that can be translated into application-specific DTDs may be needed. 🧚

5.3 Security 🔒

The language MUST provide the parameters needed to establish security. Honestly though, the security requirements mainly follow the VTS requirements in Section 3, not the GVL requirements. 🫶

5.4 Efficiency 🏃‍♀️💨

Vouchers might get stored on a smart card or PDA with limited memory. Big definitions can take a long time to transfer and process, and that might not be acceptable. The language SHOULD enable 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 🍓📚

Okay, here's a sample voucher definition in GVL. It's a five dollar discount coupon for specific merchandise, a book with ISBN number 0071355014. The coupon is circulated using a VTS called "Voucher Exchanger". To claim the offer, one coupon must be spent. It's valid from April 1st, 2001 to March 31st, 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>
  <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 🛍️✨

okay so this section walks through a super typical online shopping situation: ads, paying, and getting your stuff. It's a great example of how vouchers can coordinate services that don't trust each other yet. 💖

Figure 2 shows a consumer searching for something and buying it:

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

Here's the play-by-play 🎀:

  1. Step 1: Search for the thing you want, then grab a coupon from an ad agency. It's basically a ticket to buy that stuff at a discount 🏷️.
  2. Step 2: Get a gift certificate from a payment handler by trading cash or your payment info 💳.
  3. Step 3: Hand the coupon and gift certificate to the merchant, and in return you get an exchange ticket and loyalty points 🌈.
  4. Step 4: Give the exchange ticket to the delivery handler and receive your goods or services 📦.

In this example, the coupon, the gift certificate, and the exchange ticket are each the thing that makes those four transactions happen 🦋.

Here's the tea 🍵: you don't actually have to trust the people you're dealing with. You just have to trust the vouchers themselves. So there's no need to set up contracts between everyone beforehand, as long as the vouchers are trustworthy 🫶.

Take the exchange ticket. Even if the delivery handler doesn't trust the consumer, the merchant that issued the ticket is trusted. And if the VTS makes sure the ticket can't be duplicated while it's being traded, swapping it for goods or services is totally fine 💅. Flip it around: even if the merchant doesn't trust the delivery handler, the merchant can verify that it issued the ticket. Again, as long as the VTS guarantees no duplication during trading, the swap works 🔥 (see Fig. 3). Basically, if you trust the issuer and the VTS, you don't need trust between everyone in the transaction. Iconic 👑.

                      Exchange             Exchange
          ----------  ticket   ----------  ticket   ----------
         | Consumer |-------->| Delivery |-------->| Merchant |
         |          |<--------| Handler  |<--------|          |
          ----------  Goods or ----------  Goods or ----------
                      services             services

           Figure 3. Coordination of untrusted participants
                              using exchange ticket

This matters a lot because it's generally harder to trust individual people than companies 🥺.

Vouchers also come with some really nice privacy perks 🙈. In the exchange ticket scenario, the consumer can pick the delivery service for themselves, so the merchant doesn't even need personal info like your delivery address. And if you choose a convenience store or something similar as the pickup point, the delivery service doesn't need to know your home address either 🧚.

7. Q & A 💜

  • Is it possible to implement a VTS using digital certificates?

If transferability isn't required, a voucher can be implemented pretty easily as a digital certificate, like Signed_I(I, P, H). Here, "Signed_I" means the whole block is signed with the issuer's digital signature 🖋️. If transferability is required, then H changes during the transfer, which means the signature breaks 💔. On top of that, online database checking or tamper-resistant devices are required to prevent duplicate redemption 🔒.

  • What is the difference from digital-cash?

A VTS has to handle all kinds of vouchers, like gift certificates, coupons, or loyalty points, while a digital cash system only handles currency 💸. Plus, vouchers come from different issuers 🎟️.

  • Is it possible to support "digital property rights?

Digital property rights can be represented as a voucher and traded using VTS ✨. But to support them, you'd also need some protected rendering system that can regenerate the digital content securely 🛡️. Those requirements are out of scope for VTS 🙅‍♀️.

8. Security Considerations 🚨

Security issues are discussed in Section 3.2 and 5.3. Go check those sections, bestie, because security is no joke 😭🔐.

9. Acknowledgments 🫶

I would like to thank Masayuki Terada and Perry E. Metzger, for their valuable comments. Thank you both, you're the real MVPs 🏆💕.

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.
  • [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

Here's the legal stuff, kept complete and word for word because it matters 📜:

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. Thank you for keeping the lights on, Internet Society 🌈✨.

📦 where this page comes from