idnits 2.17.1 draft-ietf-trade-drt-requirements-02.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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 2001) is 8442 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' Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Trade Working Group Ko Fujimura 2 INTERNET-DRAFT NTT 3 Expires: August 2001 February 2001 5 Requirements for Generic Voucher Trading 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this document is unlimited. Please send comments to 30 the TRADE working group at , which may 31 be joined by sending a message with subject "subscribe" to . 34 Discussions of the TRADE working group are archived at 35 http://www.elistx.com/archives/ietf-trade. 37 Abstract 39 In purchase and other trading transactions, it is often required to 40 credit loyalty points, collect digital coupons or gift certificates, 41 and so on. These activities can be generalized using the concept of 42 a "voucher", which is a digital representation of the right to claim 43 goods or services. This document contains a voucher trading model 44 and the requirements for the following points: 46 - A voucher trading system to circulate vouchers securely 47 - A language to describe diverse types of vouchers 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC2119]. 55 Table of Contents 57 Status of this Memo ................................................1 58 Abstract ...........................................................1 59 1. Background ......................................................2 60 2. Terminology and Model ...........................................3 61 2.1 Voucher ......................................................3 62 2.2 Participants .................................................3 63 2.3 Voucher trading system (VTS) .................................4 64 3. VTS Requirements ................................................5 65 3.1 Capability to handle diversity ...............................5 66 3.2 Ensuring security ............................................5 67 3.3 Ensuring practicality ........................................6 68 4. GVL Requirements ................................................6 69 4.1 Semantics ....................................................6 70 4.2 Syntax .......................................................7 71 4.3 Security .....................................................7 72 4.4 Efficiency ...................................................8 73 4.5 Coordination .................................................8 74 5. VTP Requirements ................................................8 75 6. Application Examples ............................................8 76 7. Q & A ..........................................................10 77 8. Security Considerations ........................................11 78 9. Acknowledgments ................................................11 79 10. References .....................................................11 80 11. Author's Address ...............................................11 82 1. Background 84 It is often necessary to credit loyalty points, collect digital 85 coupons or gift certificates, etc, to complete purchases or other 86 trading transactions in the real world. The importance of these 87 activities is also being recognized in Internet Commerce. If a 88 different issuing or collecting system to handle such points or 89 coupons must be developed for each individual application, the 90 implementation cost will be too expensive, especially for small 91 businesses. Consumers may also be forced to install a number of 92 software modules to handle these points or coupons. A voucher 93 is a digital representation of the right to claim services or 94 goods. Using the concept of a voucher, a wide-range of 95 electronic-values including points or coupons can be handled in a 96 uniform manner with one trading software module. 98 This document presents the terminology, voucher trading model, 99 requirements on Voucher Trading System (VTS) that circulate vouchers 100 securely, and Generic Voucher Language (GVL), in which diverse 101 types of vouchers can be described. 103 Along with the Voucher Trading Protocol (VTP), VTS enables companies 104 or individuals to freely issue, transfer, and redeem various 105 types of vouchers via the Internet. This document does not 106 include protocol-related requirements, which will be presented in a 107 separate document. 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 vouchers 116 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: 123 o Two loyalty points are added to the card. If you collect 50 124 points, you'll get one item free. (Loyalty points) 125 o Take 10% off your total purchase by presenting this card. 126 (Membership card) 127 o Take 50% off your total purchase with this coupon. (Coupon) 128 o The bearer can access "http://..." for one month free. (Free 129 ticket for sales promotion) 130 o The bearer can exchange the ordered clothes with this ticket. 131 (Exchange ticket or Delivery note) 132 o Seat number A-24 has been reserved for "a-concert" on April 2. 133 (Event ticket) 135 Note that P does not need to be described in terms of a natural 136 language as long as the contents of the vouchers are specified. For 137 example, a set of attribute name and value pairs described in XML can 138 be employed to define the contents. 140 2.2 Participants 142 There are four types of participants in the voucher trading model: 143 issuer, holder, collector, and VTS provider. Their roles are as 144 follows: 146 Issuer: Creates and issues a voucher. Guarantees contents of 147 the voucher. 149 Holder (or user): Owns the vouchers. Transfers and redeems 150 the voucher to other users or collector. 152 Collector (or examiner): Collects the voucher. In general, 153 compensated by goods or services rendered. 155 VTS Provider: Provides a VTS and guarantees that there are no 156 duplicate assignments or multiple use of vouchers. 158 The IOTP model [IOTP] includes merchant, deliverer, consumer and other 159 participants. They take various roles in the settlement because a 160 merchant, for example, can be considered as an issuer, or holder 161 depending on whether the merchant creates the voucher 162 her/himself or purchases it from a wholesaler or manufacturer. A 163 merchant can also be a collector if the shop collects gift certificate 164 or coupons. 166 2.3 Voucher Trading System (VTS) 168 A voucher is generated by the issuer, and traded among users, 169 and 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 Definition: 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 them 192 in distributed smart cards carried by each holder [T00], or may store 193 them in multiple servers managed by each issuer or trusted third 194 parties. This is a trust policy and/or implementation issue [MF99]. 196 Issue 197 An issue transaction is the action that creates the tuple of 198 and adds it to the VVS with the issuer's intention. 200 Transfer 201 A transfer transaction is the action that rewrites the tuple of 202 (in VVS) as (H<>H') to reflect the original 203 holder H's intention. 205 Redemption 206 There are two redemption transactions: presentation and 207 consumption. 209 A presentation transaction is the action that shows the tuple of 210 (in VVS) to reflect the holder H's intention. In this 211 case, the ownership of the voucher is retained when the voucher 212 is redeemed, e.g., redemption of licenses or passports. 214 A consumption transaction is the action that deletes the tuple of 215 (in VVS) to reflect the holder H's intention. The 216 ownership of the voucher may be voided or the number of 217 times it is valid reduced when the voucher is redeemed, e.g., 218 redemption of event tickets or telephone cards. 220 Note that one or more of these transactions can be executed as part of 221 the same IOTP purchase transaction. See details in Section 6. 223 3. VTS Requirements 225 A VTS must meet the following requirements 227 (1) It MUST handle diverse types of vouchers issued by different 228 issuers. 229 (2) It MUST prevent illegal acts such as alteration, forgery, and 230 reproduction, and ensure privacy. 231 (3) It MUST be practical in terms of implementation/operation cost and 232 efficiency. 233 Each of these requirements is discussed below in detail. 235 3.1 Capability of handling diversity 237 (a) Different issuers 238 Unlike a digital cash system that handles only the currency issued 239 by a specific issuer such as a central bank, the system MUST handle 240 the vouchers issued by different issuers. 242 (b) Various types of vouchers 243 Unlike a digital cash system that only handles a currency, the 244 system MUST handle various types of vouchers, such as gift 245 certificates, coupons, and loyalty points. 247 3.2 Ensuring security 249 (c) Preventing forgery 250 Voucher MUST NOT be counterfeited. Only the issuer can initiate an 251 issue transaction. 253 (d) Preventing alteration 254 Voucher MUST NOT be altered during circulation except for the 255 transfer transaction in which the voucher holder is rewritten. 256 Only the holder can initiate a transfer transaction. 258 (e) Preventing duplicate-redemption 259 Voucher MUST NOT be redeemable once it has been consumed (the 260 result of a redemption transaction). Only the holder can initiate a 261 redemption transaction. 263 (f) Preventing reproduction 264 Voucher MUST NOT be reproduced while in circulation. 266 (g) Non-repudiation 267 It SHOULD NOT be possible to repudiate the issuance, transfer, 268 or redemption of a voucher when it is transferred or sold. 270 (h) Ensuring privacy 271 Current and previous ownership of voucher SHOULD be concealed. 273 (i) Trust manageability 274 If diverse types of vouchers are put into circulation, it would be 275 difficult for users to judge whether a voucher can be trusted or 276 not. To support such a judgment, a trust management system that 277 automatically verifies the trust of voucher SHOULD be supported. 279 3.3 Ensuring practicality 281 (j) Scalability 282 A centralized broker who sells all types of vouchers, or 283 centralized authority that authenticates all issuers or other 284 participants, SHOULD NOT be assumed. A system that relies on a 285 global, centralized organization is excessively frail; failure 286 in the organization causes complete system failure. 288 (k) Efficiency 289 It MUST be possible to implement VTS efficiently. Many applications 290 of vouchers, e.g., event ticket or transport passes, require 291 high performance, especially when the voucher is redeemed. 293 (l) Simplicity 294 It SHOULD be possible to implement VTS simply. Simplicity is 295 important to reduce the cost of implementation. It is also 296 important in in understanding the system, which is necessary for 297 people to trust the system. 299 4. GVL Requirements 301 To satisfy the diverse requirements placed on VTS (see above), we 302 believe that a Generic Voucher Language (GVL) that realizes various 303 voucher properties should be introduced. This approach ensures that 304 VTS is application independent. 305 In this section, we mainly discuss how Promise P of the voucher 306 can be defined in GVL. Specifying I and H is an 307 implementation issue and can be achieved by using a public key, hash 308 of a public key, or other names with scope rule. 310 4.1 Semantics 312 (a) Validity control: The invalidation (punching) method that is 313 executed when the voucher is redeemed depends on the 314 type of the voucher. For example, a loyalty point will 315 be invalidated if the point is redeemed but a membership card 316 can be used repeatedly regardless of the number of times 317 presented. The language MUST be able to define how validity is 318 modified. Additionally, the language MUST be able to define the 319 validity period, start date and end date. 321 (b) Transferability control: Some types of vouchers require 322 transferability. The language MUST be able to specify if an 323 voucher can be transferred. 325 (c) Circulation control: Depending on the type of the voucher, 326 various circulation requirements or restrictions must be 327 satisfied while in circulation [F99], for example, only 328 qualified shops can issue particular vouchers or only a 329 certain service provider can punch (invalidate) particular 330 vouchers. The language SHOULD be able to specify such 331 circulation requirements. 333 (d) Anonymity control: Different types of voucher will 334 require different levels of anonymity. The language SHOULD be 335 able to control the required level of anonymity. 337 (e) Understandability: The terms and description of a voucher 338 SHOULD be objectively understood by the participants, 339 because this will contribute to reducing the number of disputes 340 on the interpretation of the vouchers promised. 342 (f) State manageability: Some types of vouchers have 343 properties the values of which may change dynamically while in 344 circulation, e.g., payment status, reservation status, or 345 approval status. The language MAY support the definition of such 346 properties. 348 (g) Composability: Some types of vouchers consist of several 349 sub-vouchers, which may be issued separately from the 350 original vouchers typically because the vouchers are 351 issued by different organizations or issued at different times. 352 The language MAY support compound vouchers comprised of 353 multiple sub-vouchers. 355 4.2 Syntax 357 (a) To achieve consistency with other related standards shown below, 358 the syntax of the language MUST be based on XML [XML]. 359 (b) The language syntax MUST enable any application-specific 360 property, e.g., seat number, flight number, etc to be defined. A 361 schema definition language that can be translated into 362 application-specific DTDs may be needed. 364 4.3 Security 365 (a) The language MUST provide the parameters necessary to establish 366 security. Security requirements, however, mainly follow VTS 367 requirements described in Section 3 rather than GVL requirements. 369 4.4 Efficiency 371 (a) The vouchers may be stored in a smart card or PDA with 372 a restricted amount of memory. Large definitions may incur long 373 transfer and processing time, which may not be acceptable. The 374 language SHOULD enable the efficient definition of vouchers 376 4.5 Coordination 378 (a) The language specification SHOULD be consistent with the 379 following specifications: 380 (1) Internet Open Trading Protocol v1.0 [IOTP] 381 (2) XML-Signature [XMLDSIG] 382 (3) Extensible Markup Language (XML) Recommendation [XML] 383 (4) ECML Version 2 [ECML] 385 5. VTP Requirements 387 Requirements for the Voucher Trading Protocol (VTP) will be 388 discussed in a separate document or future version of this document. 390 6. Application Examples 392 This section describes, as a typical electronic commerce example 393 involving advertisement, payment, and delivery transactions, the use 394 of vouchers and VTS, and shows that vouchers can be used as an 395 effective way to coordinate autonomous services that have 396 not yet established trust among each other. 398 Figure 2 shows a typical electronic commerce example of a consumer 399 searching for goods or services and making a purchase: 401 ---------- 402 ------------------------------------------->| Ad | 403 | (1) Acquire a coupon | Agency | 404 | ---------- 405 | 406 | (2) Send payment information ---------- 407 | --------------------------------------->| Payment | 408 | | Acquire a gift certificate | Handler | 409 | | ---------- 410 v v (3) Transfer the coupon & 411 ---------- gift certificate ---------- 412 | Consumer |<------------------------------------>| Merchant | 413 ---------- Acquire an exchange ticket & ---------- 414 ^ loyalty points 415 | 416 | (4) Transfer the exchange ticket ---------- 417 ------------------------------------------->| Deliverer| 418 Supply goods or services | Handler | 419 ---------- 421 Figure 2. Application example of vouchers 423 (1) Use a search engine to find the desired goods or services and 424 acquire a coupon from an ad agency that represents the right to 425 purchase the goods or services at a discounted price. 427 (2) Acquire a gift certificate from a payment handler in exchange for 428 cash or payment information. 430 (3) Transfer the coupon and gift certificate to the merchant, and in 431 exchange acquire an exchange ticket and loyalty points. 433 (4) Transfer the exchange ticket to the deliverer handler and receive 434 the goods or services. 436 In this example, the coupon, gift certificate, and exchange ticket 437 each represent media coordinating the above four transactions. 439 Note that it is not necessary to trust the participants involved in 440 the transactions, but to trust the vouchers themselves. In 441 other words, there is no need to exchange contracts among the 442 participants beforehand if the vouchers themselves are trusted. 444 Take the exchange ticket as an example; even if the delivery handler 445 does not trust the consumer, the merchant that issued the exchange 446 ticket is trusted, and if the VTS guarantees that there is no 447 duplication in the trading process of the exchange ticket, there is no 448 problem in swapping the exchange ticket for the goods or services. In 449 the same way, even if the merchant does not trust the delivery handler, 450 the issuance of the exchange ticket can be verified, and if the VTS 451 guarantees that there is no duplication in the trading process of the 452 exchange ticket, there is no problem in swapping the exchange ticket 453 for the goods or services (Fig. 3). In other words, if there is trust 454 in the issuer and the VTS, trust among the participants involved in 455 the transactions is not required. 457 Exchange Exchange 458 ---------- ticket ---------- ticket ---------- 459 | Consumer |-------->| Deliverer|-------->| Merchant | 460 | |<--------| Handler |<--------| | 461 ---------- Goods or ---------- Goods or ---------- 462 services services 464 Figure 3. Coordination of untrusted participants 465 using exchange ticket 467 In general, it is difficult to manage the trust of individuals rather 468 than companies, so this characteristic of VTS is especially effective. 470 Moreover, the transactions involving vouchers have desirable features 471 with respect to privacy protection. For example, in the above exchange 472 ticket scenario, the consumer can designate the delivery service by 473 himself, so the merchant does not even need to know any personal 474 information such as the delivery address. Furthermore, by designating 475 a convenience store etc. as the receiving point, the delivery service 476 does not need to know the address of the consumer. 478 7. Q & A 480 - Is it possible to implement a VTS using digital certificates? 482 If transferability is not required, a voucher can be easily 483 implemented as a digital certificate, i.e., Signed_I(I, P, H), where 484 the phrase "Signed_I" means that the entire block is signed by the 485 issuer's digital signature. If transferability is required, then H is 486 changed during the transfer, i.e., the signature is broken. 487 Additionally, online DB checking or tamper-resistant devices are 488 required to prevent duplicate-redemption. 490 - What is the difference from digital-cash? 492 VTS must handle various types of vouchers, such as gift certificates, 493 coupons, or loyalty points unlike a digital cash system which handles 494 only currency. Additionally, vouchers are issued by different 495 issuers. 497 - Is it possible to support "digital property rights?" 499 Digital property right can be represented as a voucher and it can 500 be traded using VTS. However, some protected rendering system would 501 be required to regenerate the digital contents securely in order to 502 support digital property rights. These requirements are out of scope 503 of VTS. 505 8. Security Considerations 507 Security issues are discussed in Section 3.2 and 4.3. 509 9. Acknowledgments 511 I would like to thank Masayuki Terada, for his valuable comments. 512 I would also like to thank all the active member of IETF Trade WG, 513 especially Donald E. Eastlake 3rd, who is the chair of the WG, for 514 his help and suggestions. 516 10. References 518 [ECML] ECML Version 2, to appear. 520 [F99] K. Fujimura, H. Kuno, M. Terada, K. Matsuyama, Y. Mizuno, and J. 521 Sekine, "Digital-Ticket-Controlled Digital Ticket Circulation", 8th 522 USENIX Security Symposium, August 1999. 524 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [IOTP] D. Burdett, "The Internet Open Trading Protocol", RFC2801, 528 April 2000. 530 [MF99] K. Matsuyama and K. Fujimura, "Distributed Digital-Ticket 531 Management for Rights Trading System", 1st ACM Conferences on 532 Electronic Commerce, November 1999. 534 [T00] M. Terada, H. Kuno, M. Hanadate, and K. Fujimura, "Copy 535 Prevention Scheme for Rights Trading Infrastructure", 4th Smart Card 536 Research and Advanced Application Conference (CARDIS 2000), September 537 2000. 539 [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A W3C 540 recommendation, , October 2000. 542 [XMLDSIG] "XML-Signature Syntax and Processing", draft-ietf-xmldsig- 543 core-11.txt, in RFC Editor queue for publication as Proposed Standard. 545 Author's Address 547 Ko Fujimura 548 NTT Corporation 549 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 550 Phone: +81-(0)468-59-3814 551 Fax: +81-(0)468-59-2241 552 Email: fujimura@isl.ntt.co.jp