idnits 2.17.1 draft-ietf-trade-voucher-lang-00.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 "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 118 has weird spacing: '...request plug...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 8469 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) == Missing Reference: 'RFC 2119' is mentioned on line 91, but not defined == Unused Reference: 'ECML' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'IOTP' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 352, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ECML' == Outdated reference: A later version (-04) exists of draft-ietf-trade-drt-requirements-02 ** Downref: Normative reference to an Informational draft: draft-ietf-trade-drt-requirements (ref. 'GVT') ** Downref: Normative reference to an Informational RFC: RFC 2801 (ref. 'IOTP') ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- No information found for draft-ietf-xmldsig- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'XMLDSIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-ns' Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Trade Working Group February 2001 2 INTERNET-DRAFT Ko Fujimura 3 Masayuki Terada 4 Expires: August 2001 NTT 6 XML Voucher: Generic Voucher Language 7 9 Status of This Document 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://www.elistx.com/archives/ietf-trade. 38 Abstract 40 This document specifies rules for defining voucher properties in 41 XML syntax. A voucher is a logical entity that represents a right 42 to claim goods or services. A voucher can be used to transfer a 43 wide-range of electronic-values, including coupons, tickets, 44 loyalty points, and gift certificates, which are often necessary to 45 process in the course of payment and/or delivery transactions. 47 Table of Contents 49 Status of this Memo ..............................................1 50 Abstract .........................................................1 51 1. Introduction ..................................................2 52 2. Processing Model ..............................................2 53 3. Trust Model ...................................................3 54 4. Component Structure ...........................................4 55 4.1 Voucher Component .........................................4 56 4.2 Promise Component .........................................4 57 5. Syntax Overview and Examples ..................................6 58 6. Semantics .....................................................7 59 7. DTD ...........................................................7 60 8. Security Considerations .......................................7 61 9. Acknowledgments ...............................................7 62 10. References ....................................................7 63 11. Author's Address ..............................................8 65 1. Introduction 67 This document, XML Voucher, specifies rules for defining voucher 68 properties in XML syntax. The motivation and background of the 69 specification is described in [GVT]. 71 A voucher is a logical entity that represents a certain right and 72 logically managed by the Voucher Trading System (VTS). A voucher is 73 generated by the issuer, and traded among users, and finally is 74 collected by the collector using VTS. 76 This document defines syntax and semantics of the Voucher Component 77 that is used to define voucher meaning and processing rules in XML 78 syntax [XML]. In a Voucher Component, properties needed to allow 79 the voucher to be processed by VTS or other trading systems, e.g., 80 wallet or merchant system, are described. VTS definitions and 81 models are also defined in [GVT]. 83 Note: This document uses a "voucher" as an "instance of voucher" 84 whose meaning is defined by Voucher Component. In other words, 85 multiple vouchers can be issued and managed by the VTS using the 86 same Voucher Component. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 90 this document are to be interpreted as described in [RFC 2119] 92 2. Processing Model 94 There are several ways of implementing VTS and technologies are 95 continuously changing. For discount coupons or event tickets, for 96 example, the smart-card-based offline VTS is often preferred, 97 whereas for bonds or securities, the centralized online VTS is 98 preferred. It is impractical to define standard protocols for 99 issuing, transferring, or redeeming vouchers at this moment. 101 To provide implementation flexibility, this document assumes a 102 modular wallet architecture that allows multiple VTS to be added as 103 plug-ins. In the architecture, instead of specifying a standard 104 voucher transfer protocol, two specifications, i.e., Voucher 105 Component and VTS API specifications, are standardized (Figure 1). 107 Sender wallet/Issuing system Receiver wallet/Collecting system 108 +---------------------------+ +---------------------------+ 109 | | | | 110 | | Voucher Component | | 111 | | (Specifies Issuer, Promise, Holder, and VTS Provider) | | 112 | |-------------------------------------------------------->| | 113 | | | | | | 114 | | Intention to receive and payment (option) | | 115 | |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | | 116 | | | | | | 117 | | Issue/transfer/ VTS | | VTS Register | | 118 | | redeem request plug-in | plug-in request | | 119 | |------------------>| | | |<------------------| | 120 | | (VTS API) |<- - - - - - - ->| (VTS API) | | 121 | | | VTS-specific | | | 122 | | | protocol if VTS | | | 123 | | | is distributed | | | 124 | | Event |<- - - - - - - ->| Event | | 125 | |<------------------| | | |------------------>| | 126 +---------------------------+ +---------------------------+ 127 Figure 1. Wallet architecture with VTS plug-ins 129 After sender and receiver agree on what vouchers are to be traded 130 and which VTS is to be used, the issuing system or wallet system 131 requests the corresponding VTS plug-in to permit the issue, 132 transfer, or redeem transactions to be performed via the VTS 133 API. The VTS then rewrites the ownership of the vouchers using a 134 VTS-specific protocol. Finally, a completion event is sent to the 135 wallet systems or issuing/collecting systems. 137 3. Trust Model 139 A voucher is trusted if the issuer and VTS provider are trusted, 140 since the issuer is responsible for the contents of the voucher and 141 the VTS provider is responsible for preventing ownership from being 142 assigned to multiple users. This model enables trading partners to 143 verify the trust of the voucher regardless of the trust of the 144 partners. 146 The trust level required for issuer and VTS provider depends on the 147 type (or Promise) of the voucher. To provide the information needed 148 for the verification, the conditions of issuer and VTS provider are 149 specified in the Voucher Component. 151 In this case, however, if a malicious user could alter the Voucher 152 Component, a forged voucher, would be verified as valid. This 153 document, therefore, assumes that such alteration is impossible 154 during delivery of the Voucher Component; this is possible with 155 existing technologies, such as [XMLDSIG] or [TLS]. 157 Note: The Voucher Component does not have to be sent from the 158 sender of the voucher. It can be directly delivered from the 159 trusted issuer or trusted third party using TLS or other secure 160 communication channel. Note also that a set of trusted Voucher 161 Components can be pre-downloaded before conducting a transaction. 163 4. Component Structure 164 4.1 Voucher Component 166 A Voucher Component provides VTS branding information, and basic 167 properties for representing a voucher, i.e., issuer, promise, and 168 holder. Implementation-specific properties are often required for 169 authenticating issuer and holder. These implementation-specific 170 properties of the VTS can be attached as child elements using 171 [XML-ns]. 173 The Voucher Component contains Provider Component, Issuer 174 Component, Promise Component, and Holder Component as follows: 176 Provider Component 178 Provides properties to specify which VTS Provider (or VTS 179 plug-in) can be used for trading the voucher. 181 Issuer Component 183 Provides properties specifying the issuer of the vouchers. This 184 is optional and can be omitted if the issuer role is delegated to 185 the VTS Provider. 187 Promise Component 189 Provides properties used by the application system of VTS, e.g., 190 wallet system, merchant system. The Promise Component is 191 transparent to the VTS and is described in Section 4.2. 193 Holder Component 195 Provides properties to specify the holder of the vouchers. This 196 is optional and can be omitted if the vouchers are 197 transferable. (Note: Even for transferable vouchers, this 198 component may be used by the VTS depending on the 199 implementation.) 201 4.2 Promise Component 203 The Promise Component provides common properties useful for 204 displaying and manipulating wallet systems. It includes monetary 205 property (value) of the voucher. These monetary properties are 206 needed to calculate the amount paid when the vouchers are redeemed 207 at Merchant site, etc. 209 The Promise Component contains Title Component, Description 210 Component, ValidPeriod Component, Redemption Component, Merchandise 211 Component, and Value Component as follows: 213 Title Component 215 Provides the title of the voucher. This is mainly for displaying 216 the list of entities stored in a wallet system. 218 Description Component 220 Provides a short description of the voucher. This is mainly for 221 displaying the entities stored in a wallet system. 223 ValidPeriod Component 225 Indicates voucher's validity period, start date and end date. 227 Redemption Component 229 Provides the number of vouchers to be redeemed for claiming the 230 merchandise or financial value specified in Merchandise Component 231 or Value Component. If "n" (>0) is specified, the merchandize can 232 be claimed in exchange with "n sheets of" vouchers. (Note: 233 Multiple vouchers for the same Voucher Component must exist in 234 this case.) If "0" is specified, the vouchers do not need to be 235 consumed. It can be used repeatedly regardless of the number of 236 times redeemed. 238 Merchandise Component 240 Provides domain-specific meaning of the voucher, e.g., reference 241 number of the merchandize or seat number for an event ticket, 242 which is needed to identify the merchandize rendered when the 243 voucher is redeemed. The properties of this component are left to 244 the other domain-specific specifications and out of scope of this 245 document. Domain-specific properties can be attached as child 246 elements using [XML-ns]. 248 Value Component 250 Provides the value of the vouchers. There are two types of 251 values, i.e., fixed and ratio values. For a fixed value, the 252 currency and amount of the value is specified. For a ratio value, 253 the discount ratio of the price of the corresponding merchandize 254 is specified. 256 Using the above Components, monetary meaning for diverse types of 257 vouchers can be defined as shown in Table 1. 259 +---------------+----------+---------------+---------------------+ 260 | |Number | | Value | 261 | Examples |needed for| Merchandise +-----+---------------+ 262 | |redemption| |Ratio| Fixed | 263 | | | | |Amount Currency| 264 +---------------+----------+---------------+-----+------+--------+ 265 |Gift certifiate| 1 |(Not specified)| | 25 | USD | 266 |Loyalty point | 20 |(Not specified)| | 200 | AUD | 267 |Member card | 0 |(Not specified)| 0.2| | | 268 |Coupon | 1 |Beef 500g | 0.3| | | 269 |Event ticket | 1 |Hall A, S ,K23 | 1.0| | | 270 |Exchange ticket| 1 |ISBN:0071355014| 1.0| | | 271 +---------------+----------+---------------+-----+------+--------+ 272 Table 1. Examples of vouchers and their properties 274 5. Syntax Overview and Examples 276 This section provides an overview and examples of Voucher 277 Component. The formal syntax and semantics are found in Sections 6 278 and 7. 280 Voucher Components are represented by the element which 281 has the following structure (where "?" denotes zero or one 282 occurrence; "+" denotes one or more occurrences; and "*" denotes 283 zero or more occurrences): 285 286 (Provider) 287 (Issuer)? 288 289 (Title)? 290 (Description)? 291 (ValidPeriod)? 292 (Redemption)? 293 (Value)? 294 (Merchandise)+ 295 296 (Holder)? 297 299 An example of a Voucher Component is described below. This is an 300 example of a five dollar discount coupon for specific merchandize, 301 a book with ISBN number 0071355014. The coupon is valid from April 302 1st in 2001 to March 31st in 2002. To claim this offer, one voucher 303 must be spent. 305 306 308 309 ... 310 311 312 ... 313 314 315 IOTP Book Coupon 316 $5 off IOTP Book 317 318 319 320 321 322 323 324 326 6. Semantics 327 (tbs) 329 7. DTD 330 (tbs) 332 8. Security Considerations 334 Security issues for delivering Voucher Components are discussed in 335 Section 3. Security is a major issue in implementing VTS. For XML 336 Voucher, however, the only requirements for achieving security are 337 to provide the parameters needed for establishing security. 339 9. Acknowledgement 340 (tbs) 342 10. References 344 [ECML] ECML Version 2, to appear. 346 [GVT] K. Fujimura, "Requirements for Generic Voucher Trading", 347 draft-ietf-trade-drt-requirements-02.txt, February 2001. 349 [IOTP] D. Burdett, "The Internet Open Trading Protocol", RFC2801, 350 April 2000. 352 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246, 356 January 1999. 358 [XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", A 359 W3C Recommendation, , October 2000. 361 [XMLDSIG] "XML-Signature Syntax and Processing", 362 draft-ietf-xmldsig- core-11.txt, in RFC Editor queue for 363 publication as Proposed Standard. 365 [XML-ns] "Namespaces in XML", A W3C Recommendation, 366 , January 1999. 368 11. Authors Address 370 Ko Fujimura and Masayuki Terada 371 NTT Corporation 372 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 373 Phone: +81-(0)468-59-3814 374 Fax: +81-(0)468-59-2241 375 Email: fujimura@isl.ntt.co.jp, terada@isl.ntt.co.jp