idnits 2.17.1 draft-ietf-trade-drt-requirements-01.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: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: (c) Preventing forgery Electronic-right MUST not be counterfeited. Only the issuer can initiate an issue transaction. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: (d) Preventing alteration Electronic-right MUST not be altered during circulation except for the transfer transaction in which the electronic-right holder is rewritten. Only the holder can initiate a transfer transaction. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: (e) Preventing duplicate-redemption Electronic-right MUST not be redeemable once it has been consumed (the result of a redemption transaction). Only the holder can initiate a redemption transaction. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: (f) Preventing reproduction Electronic-right MUST not be reproduced while in circulation. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: (g) Non-repudiation It SHOULD not be possible to repudiate the issuance, transfer, or redemption of an electronic-right when it is transferred or sold. -- 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 (December 2000) is 8533 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: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 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: June 2001 December 2000 5 Requirements for Generic Rights Trading 6 draft-ietf-trade-drt-requirements-01.txt 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. The IETF Trade Working Group is investigating how these 42 activities can be generalized using the concept of a "electronic- 43 right", which is a digital representation of the right to claim goods 44 or services. This document contains a rights trading model and the 45 requirements for the following points: 47 - A rights trading system to circulate electronic-rights securely 48 - A language to describe diverse types of electronic-rights 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 1. Background ......................................................2 61 2. Terminology and Model ...........................................3 62 2.1 Electronic-right .............................................3 63 2.2 Participants .................................................3 64 2.3 Rights trading system (RTS) ..................................4 65 3. RTS Requirements ................................................5 66 3.1 Capability to handle diversity ...............................5 67 3.2 Ensuring security ............................................5 68 3.3 Ensuring practicality ........................................6 69 4. GRDL Requirements ...............................................6 70 4.1 Semantics ....................................................6 71 4.2 Syntax .......................................................7 72 4.3 Security .....................................................7 73 4.4 Efficiency ...................................................8 74 4.5 Coordination .................................................8 75 5. GRTP Requirements ...............................................8 76 6. Application Examples ............................................8 77 7. Q & A ..........................................................10 78 8. Security Considerations ........................................11 79 9. Acknowledgments ................................................11 80 10. References .....................................................11 81 11. Author's Address ...............................................11 83 1. Background 85 It is often necessary to credit loyalty points, collect digital 86 coupons or gift certificates, etc, to complete purchases or other 87 trading transactions in the real world. The importance of these 88 activities is also being recognized in Internet Commerce. If a 89 different issuing or collecting system to handle such points or 90 coupons must be developed for each individual application, the 91 implementation cost will be too expensive, especially for small 92 businesses. Consumers may also be forced to install a number of 93 software modules to handle these points or coupons. An electronic- 94 right is a digital representation of the right to claim services or 95 goods. Using the concept of an electronic-right, a wide-range of 96 electronic-values including points or coupons can be handled in a 97 uniform manner with one trading software module. 99 This document presents the terminology, rights trading model, 100 requirements on Rights Trading System (RTS) that circulate electronic- 101 rights securely, and Generic Rights Definition Language (GRDL), in 102 which diverse types of rights can be described. 104 Along with the Generic Rights Trading Protocol (GRTP), RTS enables 105 companies or individuals to freely issue, transfer, and redeem various 106 types of electronic-rights via the Internet. This document does not 107 include protocol-related requirements, which will be presented in a 108 separate document. 110 2. Terminology and Model 112 2.1 Electronic-right 114 An electronic-right is a digital representation of the right to claim 115 goods or services. To clarify the difference between electronic-rights 116 and electronic money/digital certificates, we introduce a formal 117 definition of electronic-rights in this document. 119 Let I be an electronic-right issuer, H be an electronic-right 120 holder, P be the issuer's promise to the electronic-right holder. 121 An electronic-right is defined as the 3-tuple of . 123 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 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 rights 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 rights trading model: 144 issuer, holder, collector, and RTS provider. Their roles are as 145 follows: 147 Rights Issuer: Creates and issues an electronic-right. Guarantees 148 contents of the electronic-right. 150 Rights Holder (or user): Owns the electronic-rights. Transfers and 151 redeems the electronic-right to other users or rights collector. 153 Rights Collector (or examiner): Collects the electronic-right. In 154 general, compensated by goods or services rendered. 156 RTS Provider: Provides an RTS and guarantees that there are no 157 duplicate assignments or multiple use of electronic-rights. 159 The IOTP model includes merchant, deliverer, consumer and other 160 participants. They take various roles in the settlement because a 161 merchant, for example, can be considered as an issuer, or holder 162 depending on whether the merchant creates the electronic-right 163 her/himself or purchases it from a wholesaler or manufacturer. A 164 merchant can also be a collector if the shop collects gift certificate 165 or coupons. 167 2.3 Rights Trading System (RTS) 169 An electronic-right is generated by the issuer, and traded among users, 170 and finally is collected by the collector: 172 173 Issuer I --------> User H ---------> User H' ---------> Collector 174 Issue Transfer Redemption 176 Figure 1. Life cycle of electronic-rights 178 The RTS provider provides an RTS that enables electronic-rights to be 179 circulated among the participants securely. 181 A formal definition of RTS is as follows: 183 Definition: A rights trading system (RTS) is a system that logically 184 manages a set of valid electronic-rights RS, which is a subset of 185 { | I in IS, P in PS, H in HS} where IS is the set of 186 issuers, PS is the set of promises, and HS is the set of holders; 187 RTS prevents them from being modified or reproduced except where 188 for the following three transactions: issue, transfer, and 189 redemption. The initial state of the RS is an empty set. 191 Note that this does not imply that RS is stored physically in a 192 centralized database. For example, one implementation may store them 193 in distributed smart cards carried by each holder [T00], or may store 194 them in multiple servers managed by each issuer or trusted third 195 parties. This is a trust policy and/or implementation issue [MF99]. 197 Issue 198 An issue transaction is the action that creates the tuple of 199 and adds it to the RS with the issuer's intention. 201 Transfer 202 A transfer transaction is the action that rewrites the tuple of 203 (in RS) 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 RS) to reflect the holder H's intention. In this 212 case, the ownership of the ticket is retained when the electronic- 213 right is redeemed, e.g., redemption of licenses or passports. 215 A consumption transaction is the action that deletes the tuple of 216 (in RS) to reflect the holder H's intention. The 217 ownership of the electronic-right may be voided or the number of 218 times it is valid reduced when the ticket 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 of 222 the same IOTP purchase transaction. See details in Section 6. 224 3. RTS Requirements 226 An RTS must meet the following requirements 228 (1) It MUST handle diverse types of rights issued by different 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. 234 Each of these requirements is discussed below in detail. 236 3.1 Capability of handling diversity 238 (a) Different issuers 239 Unlike a digital cash system that handles only the currency issued by 240 a specific issuer such as a central bank, the system MUST handle the 241 electronic-rights issued by different issuers. 243 (b) Various types of rights 244 Unlike a digital cash system that only handles a currency, the system 245 MUST handle various types of rights, such as gift certificates, 246 coupons, and loyalty points. 248 3.2 Ensuring security 250 (c) Preventing forgery 251 Electronic-right MUST not be counterfeited. Only the issuer can 252 initiate an issue transaction. 254 (d) Preventing alteration 255 Electronic-right MUST not be altered during circulation except for the 256 transfer transaction in which the electronic-right holder is rewritten. 257 Only the holder can initiate a transfer transaction. 259 (e) Preventing duplicate-redemption 260 Electronic-right MUST not be redeemable once it has been consumed (the 261 result of a redemption transaction). Only the holder can initiate a 262 redemption transaction. 264 (f) Preventing reproduction 265 Electronic-right MUST not be reproduced while in circulation. 267 (g) Non-repudiation 268 It SHOULD not be possible to repudiate the issuance, transfer, or 269 redemption of an electronic-right when it is transferred or sold. 271 (h) Ensuring privacy 272 Current and previous ownership of electronic-right SHOULD be concealed. 274 (i) Trust manageability 275 If diverse types of electronic-rights are put into circulation, it 276 would be difficult for users to judge whether an electronic-right can 277 be trusted or not. To support such a judgment, a trust management 278 system that automatically verifies the trust of electronic-right 279 SHOULD be supported. 281 3.3 Ensuring practicality 283 (j) Scalability 284 No centralized broker who sells all types of electronic-rights, or 285 centralized authority that authenticates all issuers or other 286 participants, SHOULD be assumed. A system that relies on a global, 287 centralized organization is excessively frail; failure in the 288 organization causes complete system failure. 290 (k) Efficiency 291 It MUST be possible to implement RTS efficiently. Many applications of 292 electronic-rights, e.g., event ticket or transport passes, require 293 high performance, especially when the electronic-right is redeemed. 295 (l) Simplicity 296 It SHOULD be possible to implement RTS simply. Simplicity is important 297 to reduce the cost of implementation. It is also important in 298 understanding the system, which is necessary for people to trust the 299 system. 301 4. GRDL Requirements 303 To satisfy the diverse requirements placed on RTS (see above), we 304 believe that a Generic Rights Definition Language (GRDL) that realizes 305 various electronic-right properties should be introduced. This 306 approach ensures that RTS is application independent. 307 In this section, we mainly discuss how Promise P of the electronic- 308 right can be defined in GRDL. Specifying I and H is an 309 implementation issue and can be achieved by using a public key, hash 310 of a public key, or other names with scope rule. 312 4.1 Semantics 314 (a) Validity control: The invalidation (punching) method that is 315 executed when the electronic-right is redeemed depends on the 316 type of the electronic-right. For example, a loyalty point will 317 be invalidated if the point is redeemed but a membership card 318 can be used repeatedly regardless of the number of times 319 presented. The language MUST be able to define how validity is 320 modified. Additionally, the language MUST be able to define the 321 validity period, start date and end date. 323 (b) Transferability control: Some types of electronic-rights require 324 transferability. The language MUST be able to specify if an 325 electronic-right can be transferred. 327 (c) Circulation control: Depending on the type of the electronic- 328 right, various circulation requirements or restrictions must be 329 satisfied while in circulation [F99], for example, only 330 qualified shops can issue particular electronic-rights or only a 331 certain service provider can punch (invalidate) particular 332 electronic-rights. The language SHOULD be able to specify such 333 circulation requirements. 335 (d) Anonymity control: Different types of electronic-right will 336 require different levels of anonymity. The language SHOULD be 337 able to control the required level of anonymity. 339 (e) Understandability: The terms and description of an electronic- 340 right SHOULD be objectively understood by the participants, 341 because this will contribute to reducing the number of disputes 342 on the interpretation of the rights promised. 344 (f) State manageability: Some types of electronic-rights have 345 properties the values of which may change dynamically while in 346 circulation, e.g., payment status, reservation status, or 347 approval status. The language MAY support the definition of such 348 properties. 350 (g) Composability: Some types of electronic-rights consist of 351 several sub-rights, which may be issued separately from the 352 original rights typically because the electronic-rights are 353 issued by different organizations or issued at different times. 354 The language MAY support compound electronic-rights comprised of 355 multiple sub-rights. 357 4.2 Syntax 359 (a) To achieve consistency with other related standards shown below, 360 the syntax of the language MUST be based on XML. 361 (b) The language syntax MUST enable any application-specific 362 property, e.g., seat number, flight number, etc to be defined. A 363 schema definition language that can be translated into 364 application-specific DTDs may be needed. 366 4.3 Security 367 (a) The language MUST provide the parameters necessary to establish 368 security. Security requirements, however, mainly follow RTS 369 requirements described in Section 3 rather than GRDL requirements. 371 4.4 Efficiency 373 (a) The electronic-rights may be stored in a smart card or PDA with 374 a restricted amount of memory. Large definitions may incur long 375 transfer and processing time, which may not be acceptable. The 376 language SHOULD enable the efficient definition of electronic- 377 rights. 379 4.5 Coordination 381 (a) The language specification SHOULD be consistent with the 382 following specifications: 383 (1) Internet Open Trading Protocol v1.0 [IOTP] 384 (2) XML-Signature [XMLDSIG] 385 (3) Extensible Markup Language (XML) Recommendation [XML] 386 (4) ECML Version 2 [ECML] 388 5. GRTP Requirements 390 Requirements for the Generic Rights Trading Protocol (GRTP) will be 391 discussed in a separate document or future version of this document. 393 6. Application Examples 395 This section describes, as a typical electronic commerce example 396 involving advertisement, payment, and delivery transactions, the use 397 of electronic-rights and RTS, and shows that electronic-rights can be 398 used as an effective way to coordinate autonomous services that have 399 not yet established trust among each other. 401 Figure 2 shows a typical electronic commerce example of a consumer 402 searching for goods or services and making a purchase: 404 ---------- 405 ------------------------------------------->| Ad | 406 | (1) Acquire a coupon | Agency | 407 | ---------- 408 | 409 | (2) Send payment information ---------- 410 | --------------------------------------->| Payment | 411 | | Acquire a gift certificate | Handler | 412 | | ---------- 413 v v (3) Transfer the coupon & 414 ---------- gift certificate ---------- 415 | Consumer |<------------------------------------>| Merchant | 416 ---------- Acquire an exchange ticket & ---------- 417 ^ loyalty points 418 | 419 | (4) Transfer the exchange ticket ---------- 420 ------------------------------------------->| Deliverer| 421 Supply goods or services | Handler | 422 ---------- 424 Figure 2. Application example of electronic-rights 426 (1) Use a search engine to find the desired goods or services and 427 acquire a coupon from an ad agency that represents the right to 428 purchase the goods or services at a discounted price. 430 (2) Acquire a gift certificate from a payment handler in exchange for 431 cash or payment information. 433 (3) Transfer the coupon and gift certificate to the merchant, and in 434 exchange acquire an exchange ticket and loyalty points. 436 (4) Transfer the exchange ticket to the deliverer handler and receive 437 the goods or services. 439 In this example, the coupon, gift certificate, and exchange ticket 440 each represent media coordinating the above four transactions. 442 Note that it is not necessary to trust the participants involved in 443 the transactions, but to trust the electronic-rights themselves. In 444 other words, there is no need to exchange contracts among the 445 participants beforehand if the electronic-rights themselves are 446 trusted. 448 Take the exchange ticket as an example; even if the delivery handler 449 does not trust the consumer, the merchant that issued the exchange 450 ticket is trusted, and if the RTS guarantees that there is no 451 duplication in the trading process of the exchange ticket, there is no 452 problem in swapping the exchange ticket for the goods or services. In 453 the same way, even if the merchant does not trust the delivery handler, 454 the issuance of the exchange ticket can be verified, and if the RTS 455 guarantees that there is no duplication in the trading process of the 456 exchange ticket, there is no problem in swapping the exchange ticket 457 for the goods or services (Fig. 3). In other words, if there is trust 458 in the issuer and the RTS, trust among the participants involved in 459 the transactions is not required. 461 Exchange Exchange 462 ---------- ticket ---------- ticket ---------- 463 | Consumer |-------->| Deliverer|-------->| Merchant | 464 | |<--------| Handler |<--------| | 465 ---------- Goods or ---------- Goods or ---------- 466 services services 468 Figure 3. Coordination of untrusted participants 469 using exchange ticket 471 In general, it is difficult to manage the trust of individuals rather 472 than companies, so this characteristic of RTS is especially effective. 474 Moreover, the transactions involving electronic-rights have desirable 475 features with respect to privacy protection. For example, in the 476 above exchange ticket scenario, the consumer can designate the 477 delivery service by himself, so the merchant does not even need to 478 know any personal information such as the delivery address. 479 Furthermore, by designating a convenience store etc. as the receiving 480 point, the delivery service does not need to know the address of the 481 consumer. 483 7. Q & A 485 - Is it possible to implement an RTS using digital certificates? 487 If transferability is not required, an electronic-right can be easily 488 implemented as a digital certificate, i.e., Signed_I(I, P, H), where 489 the phrase "Signed_I" means that the entire block is signed by the 490 issuer's digital signature. If transferability is required, then H is 491 changed during the transfer, i.e., the signature is broken. 492 Additionally, online DB checking or tamper-resistant devices are 493 required to prevent duplicate-redemption. 495 - What is the difference from digital-cash? 497 RTS must handle various types of rights, such as gift certificates, 498 coupons, or loyalty points unlike a digital cash system which handles 499 only currency. Additionally, electronic-rights are issued by different 500 issuers. 502 - Is it possible to ensure digital "property" rights? 504 Yes, since digital property rights can be considered as a kind of 505 electronic-right. RTS, however, would need to be extended by adding 506 some protected rendering system that would regenerate the original 507 digital contents securely. 509 8. Security Considerations 511 Security issues are discussed in Section 3.2 and 4.3. 513 9. Acknowledgments 514 T.B.S. 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 Right 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, A W3C recommendation, 540 http://www.w3.org/TR/REC-xml. 542 [XMLDSIG] XML-Signature Syntax and Processing, A W3C Candidate 543 Recommendation, http://www.w3.org/TR/xmldsig-core/. 545 Author's Address 547 Ko Fujimura 548 NTT Corporation 549 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 550 Phone: +1-81-(0)468-59-3814 551 Fax: +1-81-(0)468-59-2241 552 Email: fujimura@isl.ntt.co.jp