idnits 2.17.1 draft-ietf-trade-drt-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 105 has weird spacing: '...ely; it also ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2002) is 8127 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ECML' -- Possible downref: Non-RFC (?) normative reference: ref. 'F99' ** Downref: Normative reference to an Informational RFC: RFC 2801 (ref. 'IOTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'MF99' -- Possible downref: Non-RFC (?) normative reference: ref. 'T00' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLDSIG' Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Trade Working Group Ko Fujimura 3 INTERNET-DRAFT NTT 4 Expires: July 2002 January 2002 6 Requirements and Design for Voucher Trading System (VTS) 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Distribution of this document is unlimited. Please send comments to 31 the TRADE working group at , which may 32 be joined by sending a message with subject "subscribe" to . 35 Discussions of the TRADE working group are archived at 36 http://lists.elistx.com/archives/ietf-trade/. 38 Abstract 40 Functions common in purchasing and general trading transactions, 41 include crediting loyalty points and collecting digital coupons or 42 gift certificates. These activities can be generalized using the 43 concept of a "voucher", which is a digital representation of the 44 right to claim goods or services. This document presents the 45 terminology of and a model for a Voucher Trading System (VTS) that 46 circulates vouchers securely; it lists design principles and 47 requirements for VTS and the Generic Voucher Language (GVL), with 48 which diverse types of vouchers can be described. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [RFC2119]. 56 Table of Contents 58 Status of this Memo ................................................1 59 Abstract ...........................................................1 60 Conventions used in this document ..................................1 61 1. Background ......................................................2 62 2. Terminology and Model ...........................................3 63 2.1 Voucher ......................................................3 64 2.2 Participants .................................................3 65 2.3 Voucher Trading System (VTS) .................................4 66 3. VTS Requirements ................................................5 67 3.1 Capability to handle diversity ...............................5 68 3.2 Ensuring security ............................................5 69 3.3 Ensuring practicality ........................................6 70 4. Scope of VTS Specifications .....................................6 71 4.1 Voucher Trading Protocol .....................................7 72 4.2 VTS-API ......................................................7 73 4.3 Generic Voucher Language .....................................7 74 5. GVL Requirements ................................................7 75 5.1 Semantics ....................................................7 76 5.2 Syntax .......................................................8 77 5.3 Security .....................................................9 78 5.4 Efficiency ...................................................9 79 5.5 Coordination .................................................9 80 5.6 Example of GVL ...............................................9 81 6. Application Scenarios ...........................................9 82 7. Q & A ..........................................................11 83 8. Security Considerations ........................................12 84 9. Acknowledgments ................................................12 85 10. References .....................................................12 86 11. Author's Address ...............................................12 88 1. Background 90 It is often necessary to credit loyalty points, collect digital 91 coupons or gift certificates, etc, to complete purchases or other 92 trading transactions in the real world. The importance of these 93 activities is also being recognized in Internet Commerce. If a 94 different issuing or collecting system to handle such points or 95 coupons must be developed for each individual application, the 96 implementation cost will be too expensive, especially for small 97 businesses. Consumers may also be forced to install a number of 98 software modules to handle these points or coupons. A voucher is a 99 digital representation of the right to claim services or goods. 100 Using the concept of a voucher, a wide-range of electronic-values 101 including points or coupons can be handled in a uniform manner with 102 one trading software module. 104 This document presents the terminology and model for a Voucher Trading 105 System (VTS) that circulates vouchers securely; it also lists design 106 principles and requirements for VTS and the Generic Voucher Language 107 (GVL), with which diverse types of vouchers can be described. 109 2. Terminology and Model 111 2.1 Voucher 113 A voucher is a digital representation of the right to claim goods or 114 services. To clarify the difference between vouchers and electronic 115 money/digital certificates, we introduce a formal definition of 116 vouchers in this document. 118 Let I be a voucher issuer, H be a voucher holder, P be the 119 issuer's promise to the voucher holder. A voucher is defined as 120 the 3-tuple of . 122 Examples of P are as follows: 124 o Two loyalty points are added to the card. If you collect 50 125 points, you'll get one item free. (Loyalty points) 126 o Take 10% off your total purchase by presenting this card. 127 (Membership card) 128 o Take 50% off your total purchase with this coupon. (Coupon) 129 o The bearer can access "http://..." for one month free. (Free 130 ticket for sales promotion) 131 o The bearer can exchange the ordered clothes with this ticket. 132 (Exchange ticket or Delivery note) 133 o Seat number A-24 has been reserved for "a-concert" on April 2. 134 (Event ticket) 136 Note that P does not need to be described in terms of a natural 137 language as long as the contents of the vouchers are specified. For 138 example, a set of attribute name and value pairs described in XML can 139 be employed to define the contents. 141 2.2 Participants 143 There are four types of participants in the voucher trading model: 144 issuer, holder, collector, and VTS provider. Their roles are as 145 follows: 147 Issuer: Creates and issues a voucher. Guarantees contents of 148 the voucher. 150 Holder (or user): Owns the vouchers. Transfers and redeems 151 the voucher to other users or collector. 153 Collector (or examiner): Collects the voucher. In general, 154 compensated by goods or services rendered. 156 VTS Provider: Provides a VTS and guarantees that there are no 157 duplicate assignments or multiple use of vouchers. 159 The IOTP model [IOTP] includes merchant, deliverer, consumer and 160 other participants. They take various roles in the settlement because 161 a merchant, for example, can be considered as an issuer, or holder 162 depending on whether the merchant creates the voucher her/himself or 163 purchases it from a wholesaler or manufacturer. A merchant can also 164 be a collector if the shop collects gift certificate or coupons. 166 2.3 Voucher Trading System (VTS) 168 A voucher is generated by the issuer, and traded among users, and 169 finally is collected by the collector: 171 172 Issuer I --------> User H ---------> User H' ---------> Collector 173 Issue Transfer Redemption 175 Figure 1. Life cycle of vouchers 177 The VTS provider provides a VTS that enables vouchers to be 178 circulated among the participants securely. 180 A formal definition of VTS is as follows: 182 A voucher trading system (VTS) is a system that logically 183 manages a set of valid vouchers VVS, which is a subset of 184 { | I in IS, P in PS, H in HS} where IS is the set of 185 issuers, PS is the set of promises, and HS is the set of holders; 186 VTS prevents them from being modified or reproduced except where 187 for the following three transactions: issue, transfer, and 188 redemption. The initial state of the VVS is an empty set. 190 Note that this does not imply that VVS is stored physically in a 191 centralized database. For example, one implementation may store 192 them in distributed smart cards carried by each holder [T00], or 193 may store them in multiple servers managed by each issuer or 194 trusted third parties. This is a trust policy and/or 195 implementation issue [MF99]. 197 Issue 198 An issue transaction is the action that creates the tuple of 199 and adds it to the VVS with the issuer's intention. 201 Transfer 202 A transfer transaction is the action that rewrites the tuple of 203 (in VVS) as (H<>H') to reflect the original 204 holder H's intention. 206 Redemption 207 There are two redemption transactions: presentation and 208 consumption. 210 A presentation transaction is the action that shows the tuple of 211 (in VVS) to reflect the holder H's intention. In this 212 case, the ownership of the voucher is retained when the voucher 213 is redeemed, e.g., redemption of licenses or passports. 215 A consumption transaction is the action that deletes the tuple 216 of (in VVS) to reflect the holder H's intention. The 217 ownership of the voucher may be voided or the number of 218 times it is valid reduced when the voucher is redeemed, e.g., 219 redemption of event tickets or telephone cards. 221 Note that one or more of these transactions can be executed as part 222 of the same IOTP purchase transaction. See details in Section 6. 224 3. VTS Requirements 226 A VTS must meet the following requirements 228 (1) It MUST handle diverse types of vouchers issued by different 229 issuers. 230 (2) It MUST prevent illegal acts such as alteration, forgery, and 231 reproduction, and ensure privacy. 232 (3) It MUST be practical in terms of implementation/operation cost 233 and efficiency. 235 Each of these requirements is discussed below in detail. 237 3.1 Capability of handling diversity 239 (a) Different issuers 241 Unlike a digital cash system that handles only the currency issued 242 by a specific issuer such as a central bank, the system MUST handle 243 the vouchers issued by different issuers. 245 (b) Various types of vouchers 247 Unlike a digital cash system that only handles a currency, the 248 system MUST handle various types of vouchers, such as gift 249 certificates, coupons, and loyalty points. 251 3.2 Ensuring security 253 (c) Preventing forgery 255 Voucher MUST NOT be counterfeited. Only the issuer can initiate an 256 issue transaction. 258 (d) Preventing alteration 260 Voucher MUST NOT be altered during circulation except for the 261 transfer transaction in which the voucher holder is rewritten. 262 Only the holder can initiate a transfer transaction. 264 (e) Preventing duplicate-redemption 266 Voucher MUST NOT be redeemable once it has been consumed (the 267 result of a redemption transaction). Only the holder can initiate a 268 redemption transaction. 270 (f) Preventing reproduction 272 Voucher MUST NOT be reproduced while in circulation. 274 (g) Non-repudiation 276 It SHOULD NOT be possible to repudiate the issuance, transfer, 277 or redemption of a voucher when it is transferred or sold. 279 (h) Ensuring privacy 281 Current and previous ownership of voucher SHOULD be concealed. 283 (i) Trust manageability 285 If diverse types of vouchers are put into circulation, it would be 286 difficult for users to judge whether a voucher can be trusted or 287 not. To support such a judgment, a trust management system that 288 automatically verifies the trust of voucher SHOULD be supported. 290 3.3 Ensuring practicality 292 (j) Scalability 294 A centralized broker who sells all types of vouchers, or 295 centralized authority that authenticates all issuers or other 296 participants, SHOULD NOT be assumed. A system that relies on a 297 global, centralized organization is excessively frail; failure 298 in the organization causes complete system failure. 300 (k) Efficiency 302 It MUST be possible to implement VTS efficiently. Many applications 303 of vouchers, e.g., event ticket or transport passes, require 304 high performance, especially when the voucher is redeemed. 306 (l) Simplicity 308 It SHOULD be possible to implement VTS simply. Simplicity is 309 important to reduce the cost of implementation. It is also 310 important in understanding the system, which is necessary for 311 people to trust the system. 313 4. Scope of VTS Specifications 315 To implement a VTS, Voucher Trading Protocol (VTP), VTS Application 316 Programming Interface (VTS-API), and Generic Voucher Language (GVL) 317 must be developed. The objectives, benefits, and limitations of 318 standardization for each specification are discussed below. 320 4.1 Voucher Trading Protocol 322 To achieve interoperability among multiple VTSs developed by 323 independent VTS Providers, standard protocols for issuing, 324 transferring, or redeeming vouchers will be needed. However, there 325 are several ways of implementing VTS. For discount coupons or event 326 tickets, for example, the smart-card-based decentralized offline VTS 327 is often preferred, whereas for bonds or securities, the centralized 328 online VTS may be preferred. It is impractical to define any 329 standard protocol at this moment. 331 4.2 VTS-API 333 To provide freedom in terms of VTS selection for issuers and 334 application developers, we believe that a standard Voucher Trading 335 System Application Programming Interface (VTS-API) that can 336 encapsulate any VTS implementation should be specified. It allows a 337 caller application to issue, transfer, and redeem voucher in a 338 uniform manner independent of the VTS implementation. Basic 339 functions, i.e., issue, transfer, and redeem, provided by VTS-API 340 can be straightforwardly derived from the VTS model described in 341 this document. More design details of the VTS-API will be discussed 342 in a separate document or a separate VTS-API specification. 344 4.3 Generic Voucher Language 346 To satisfy the diverse requirements placed on VTS (see Section 3), we 347 believe that a standard Generic Voucher Language (GVL) that realizes 348 various voucher properties should be specified. This approach ensures 349 that VTS is application independent. The language should be able to 350 define diverse Promise P of the voucher to cover tickets, 351 coupons, loyalty points, and gift certificates uniformly. Specifying 352 I and H is a VTS implementation issue and can be achieved by using a 353 public key, hash of a public key, or other names with scope rule. 355 In the following section, we discuss GVL Requirements in detail. 357 5. GVL Requirements 359 5.1 Semantics 361 Semantics supported by the language and their requirements levels are 362 described below in detail. 364 (a) Validity control 366 The invalidation (punching) method that is executed when the voucher 367 is redeemed depends on the type of the voucher. For example, a 368 loyalty point will be invalidated if the point is redeemed but a 369 membership card can be used repeatedly regardless of the number of 370 times presented. The language MUST be able to define how validity is 371 modified. Additionally, the language MUST be able to define the 372 validity period, start date and end date. 374 (b) Transferability control 376 Some types of vouchers require transferability. The language MUST be 377 able to specify if a voucher can be transferred. 379 (c) Circulation control 381 Depending on the type of the voucher, various circulation 382 requirements or restrictions must be satisfied while in circulation 383 [F99], for example, only qualified shops can issue particular 384 vouchers or only a certain service provider can punch (invalidate) 385 particular vouchers. The language SHOULD be able to specify such 386 circulation requirements. 388 (d) Anonymity control 390 Different types of voucher will require different levels of 391 anonymity. The language SHOULD be able to achieve the required level 392 of anonymity. 394 (e) Understandability 396 The terms and description of a voucher SHOULD be objectively 397 understood by the participants, because this will contribute to 398 reducing the number of disputes on the interpretation of the 399 vouchers promised. 401 (f) State manageability 403 Some types of vouchers have properties the values of which may 404 change dynamically while in circulation, e.g., payment status, 405 reservation status, or approval status. The language MAY support the 406 definition of such properties. 408 (g) Composability 410 Some types of vouchers consist of several sub-vouchers, which may be 411 issued separately from the original vouchers typically because the 412 vouchers are issued by different organizations or issued at 413 different times. The language MAY support compound vouchers 414 comprised of multiple sub-vouchers. 416 5.2 Syntax 418 To achieve consistency with other related standards shown below, 419 the syntax of the language MUST be based on XML [XML]. 421 The language syntax MUST enable any application-specific 422 property, e.g., seat number, flight number, etc to be defined. A 423 schema definition language that can be translated into 424 application-specific DTDs may be needed. 426 5.3 Security 428 The language MUST provide the parameters necessary to establish 429 security. Security requirements, however, mainly follow VTS 430 requirements described in Section 3 rather than GVL requirements. 432 5.4 Efficiency 434 The vouchers may be stored in a smart card or PDA with a restricted 435 amount of memory. Large definitions may incur long transfer and 436 processing times, which may not be acceptable. The language SHOULD 437 enable the efficient definition of vouchers 439 5.5 Coordination 441 The language specification SHOULD be consistent with the 442 following specifications: 444 (1) Internet Open Trading Protocol v1.0 [IOTP] 445 (2) XML-Signature [XMLDSIG] 446 (3) Extensible Markup Language (XML) Recommendation [XML] 447 (4) ECML Version 2 [ECML] 449 5.6 Example of GVL 451 An example of a voucher definition in GVL is described below. This 452 example defines a five dollar discount coupon for specific 453 merchandise, a book with ISBN number 0071355014. This coupon is 454 circulated using a VTS called "Voucher Exchanger". To claim this 455 offer, one coupon must be spent. The coupon is valid from April 1st 456 in 2001 to March 31st in 2002. 458 459 461 IOTP Book Coupon 462 $5 off IOTP Book 463 464 VE2.31 465 466 467 468 469 470 472 473 474 476 6. Application Scenarios 477 This section describes, as a typical electronic commerce example 478 involving advertisement, payment, and delivery transactions, the use 479 of vouchers and VTS, and shows that vouchers can be used as an 480 effective way to coordinate autonomous services that have not yet 481 established trust among each other. 483 Figure 2 shows a typical electronic commerce example of a consumer 484 searching for goods or services and making a purchase: 486 ---------- 487 ------------------------------------------->| Ad | 488 | (1) Acquire a coupon | Agency | 489 | ---------- 490 | 491 | (2) Send payment information ---------- 492 | --------------------------------------->| Payment | 493 | | Acquire a gift certificate | Handler | 494 | | ---------- 495 v v (3) Transfer the coupon & 496 ---------- gift certificate ---------- 497 | Consumer |<------------------------------------>| Merchant | 498 ---------- Acquire an exchange ticket & ---------- 499 ^ loyalty points 500 | 501 | (4) Transfer the exchange ticket ---------- 502 ------------------------------------------->| Deliverer| 503 Supply goods or services | Handler | 504 ---------- 506 Figure 2. Application example of vouchers 508 (1) Use a search engine to find the desired goods or services and 509 acquire a coupon from an ad agency that represents the right to 510 purchase the goods or services at a discounted price. 512 (2) Acquire a gift certificate from a payment handler in exchange 513 for cash or payment information. 515 (3) Transfer the coupon and gift certificate to the merchant, and in 516 exchange acquire an exchange ticket and loyalty points. 518 (4) Transfer the exchange ticket to the deliverer handler and 519 receive the goods or services. 521 In this example, the coupon, gift certificate, and exchange ticket 522 each represent the media that yields the above four transactions. 524 Note that it is not necessary to trust the participants involved in 525 the transactions, but to trust the vouchers themselves. In other 526 words, there is no need to exchange contracts among the participants 527 beforehand if the vouchers themselves are trusted. 529 Take the exchange ticket as an example; even if the delivery handler 530 does not trust the consumer, the merchant that issued the exchange 531 ticket is trusted, and if the VTS guarantees that there is no 532 duplication in the trading process of the exchange ticket, there is 533 no problem in swapping the exchange ticket for the goods or services. 534 In the same way, even if the merchant does not trust the delivery 535 handler, the issuance of the exchange ticket can be verified, and if 536 the VTS guarantees that there is no duplication in the trading 537 process of the exchange ticket, there is no problem in swapping the 538 exchange ticket for the goods or services (Fig. 3). In other words, 539 if there is trust in the issuer and the VTS, trust among the 540 participants involved in the transactions is not required. 542 Exchange Exchange 543 ---------- ticket ---------- ticket ---------- 544 | Consumer |-------->| Deliverer|-------->| Merchant | 545 | |<--------| Handler |<--------| | 546 ---------- Goods or ---------- Goods or ---------- 547 services services 549 Figure 3. Coordination of untrusted participants 550 using exchange ticket 552 In general, it is more difficult to trust individuals than 553 companies, so this characteristic of VTS is especially effective. 555 Moreover, the transactions involving vouchers have desirable features 556 with respect to privacy protection. For example, in the above 557 exchange ticket scenario, the consumer can designate the delivery 558 service by himself, so the merchant does not even need to know any 559 personal information such as the delivery address. Furthermore, by 560 designating a convenience store etc. as the receiving point, the 561 delivery service does not need to know the address of the consumer. 563 7. Q & A 565 - Is it possible to implement a VTS using digital certificates? 567 If transferability is not required, a voucher can be easily 568 implemented as a digital certificate, i.e., Signed_I(I, P, H), where 569 the phrase "Signed_I" means that the entire block is signed by the 570 issuer's digital signature. If transferability is required, then H is 571 changed during the transfer, i.e., the signature is broken. 572 Additionally, online DB checking or tamper-resistant devices are 573 required to prevent duplicate-redemption. 575 - What is the difference from digital-cash? 577 VTS must handle various types of vouchers, such as gift certificates, 578 coupons, or loyalty points unlike a digital cash system which handles 579 only currency. Additionally, vouchers are issued by different 580 issuers. 582 - Is it possible to support "digital property rights?" 583 Digital property rights can be represented as a voucher and can be 584 traded using VTS. However, some protected rendering system would be 585 required to regenerate the digital contents securely in order to 586 support digital property rights. These requirements are out of scope 587 of VTS. 589 8. Security Considerations 591 Security issues are discussed in Section 3.2 and 5.3. 593 9. Acknowledgments 595 I would like to thank Masayuki Terada and Perry E. Metzger, for their 596 valuable comments. I would also like to thank all the active member 597 of IETF Trade WG, especially Donald E. Eastlake 3rd, who is the chair 598 of the WG, for his help and suggestions. 600 10. References 602 [ECML] ECML Version 2, to appear. 604 [F99] K. Fujimura, H. Kuno, M. Terada, K. Matsuyama, Y. Mizuno, and 605 J. Sekine, "Digital-Ticket-Controlled Digital Ticket Circulation", 606 8th USENIX Security Symposium, August 1999. 608 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, March 1997. 611 [IOTP] D. Burdett, "The Internet Open Trading Protocol", RFC2801, 612 April 2000. 614 [MF99] K. Matsuyama and K. Fujimura, "Distributed Digital-Ticket 615 Management for Rights Trading System", 1st ACM Conferences on 616 Electronic Commerce, November 1999. 618 [T00] M. Terada, H. Kuno, M. Hanadate, and K. Fujimura, "Copy 619 Prevention Scheme for Rights Trading Infrastructure", 4th Smart Card 620 Research and Advanced Application Conference (CARDIS 2000), September 621 2000. 623 [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A W3C 624 Recommendation, , October 2000. 626 [XMLDSIG] "XML-Signature Syntax and Processing", A W3C Proposed 627 Recommendation, , August 2001. 629 11. Author's Address 631 Ko Fujimura 632 NTT Corporation 633 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 634 Phone: +81-(0)468-59-3814 635 Fax: +81-(0)468-59-2241 636 Email: fujimura@isl.ntt.co.jp