idnits 2.17.1 draft-ietf-trade-voucher-vtsapi-06.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.) ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 203 has weird spacing: '...request plug...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2004) is 7376 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: 'TLS' is mentioned on line 511, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'DOM' == Outdated reference: A later version (-07) exists of draft-ietf-trade-voucher-lang-06 ** Downref: Normative reference to an Informational draft: draft-ietf-trade-voucher-lang (ref. 'GVL') == Outdated reference: A later version (-13) exists of draft-ietf-trade-ecml2-spec-09 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Trade Working Group February 2004 2 INTERNET-DRAFT Masayuki Terada 3 NTT DoCoMo 4 Expires: August 2004 Ko Fujimura 5 NTT 7 Voucher Trading System Application Programming Interface (VTS-API) 8 10 Status of This Document 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this document is unlimited. Please send comments to 32 the TRADE working group at , which may 33 be joined by sending a message with subject "subscribe" to . 36 Discussions of the TRADE working group are archived at 37 http://lists.elistx.com/archives/ietf-trade. 39 Abstract 41 This document specifies the Voucher Trading System Application 42 Programming Interface (VTS-API). The VTS-API allows a wallet or 43 other application to issue, transfer, and redeem vouchers in a 44 uniform manner independent of the VTS implementation. The VTS is a 45 system to securely transfer vouchers, e.g., coupons, tickets, loyalty 46 points, and gift certificates; this process is often necessary in the 47 course of payment and/or delivery transactions. 49 Copyright (C) The Internet Society (2004). All Rights Reserved. 51 Acknowledgements 52 The following persons, in alphabetic order, contributed substantially 53 to the material herein: 55 Donald Eastlake 3rd 56 Iguchi Makoto 57 Yoshitaka Nakamura 58 Ryuji Shoda 60 Table of Contents 62 Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1 63 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 64 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 1 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Processing Model . . . . . . . . . . . . . . . . . . . . . 4 67 3. Design Overview . . . . . . . . . . . . . . . . . . . . . 6 68 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Interface Definitions . . . . . . . . . . . . . . . . . . 7 70 5.1 VTSManager . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.1.1 getParticipantRepository . . . . . . . . . . . . . . . . . 8 72 5.1.2 getVoucherComponentRepository . . . . . . . . . . . . . . 8 73 5.2 ParticipantRepository . . . . . . . . . . . . . . . . . . 8 74 5.2.1 lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.3 Participant . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.3.1 getIdentifier . . . . . . . . . . . . . . . . . . . . . . 9 77 5.3.2 getVTSAgent . . . . . . . . . . . . . . . . . . . . . . . 9 78 5.4 VTSAgent . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.4.1 login . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.4.2 logout . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 5.4.3 prepare . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 5.4.4 issue . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 5.4.5 transfer . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 5.4.6 consume . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 5.4.7 present . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 5.4.8 cancel . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 5.4.9 resume . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 5.4.10 create . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 5.4.11 delete . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 5.4.12 getContents . . . . . . . . . . . . . . . . . . . . . . . 17 91 5.4.13 getSessions . . . . . . . . . . . . . . . . . . . . . . . 17 92 5.4.14 getLog . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 5.4.15 addReceptionListener . . . . . . . . . . . . . . . . . . . 18 94 5.4.16 removeReceptionListener . . . . . . . . . . . . . . . . . 18 95 5.5 Session . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 5.5.1 getIdentifier . . . . . . . . . . . . . . . . . . . . . . 19 97 5.5.2 getVoucher . . . . . . . . . . . . . . . . . . . . . . . . 19 98 5.5.3 getSender . . . . . . . . . . . . . . . . . . . . . . . . 19 99 5.5.4 getReceiver . . . . . . . . . . . . . . . . . . . . . . . 20 100 5.5.5 isPrepared . . . . . . . . . . . . . . . . . . . . . . . . 20 101 5.5.6 isActivated . . . . . . . . . . . . . . . . . . . . . . . 20 102 5.5.7 isSuspended . . . . . . . . . . . . . . . . . . . . . . . 20 103 5.5.8 isCompleted . . . . . . . . . . . . . . . . . . . . . . . 20 104 5.6 Voucher . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 5.6.1 getIssuer . . . . . . . . . . . . . . . . . . . . . . . . 21 106 5.6.2 getPromise . . . . . . . . . . . . . . . . . . . . . . . 21 107 5.6.3 getCount . . . . . . . . . . . . . . . . . . . . . . . . . 21 108 5.7 VoucherComponentRepository . . . . . . . . . . . . . . . . 21 109 5.7.1 register . . . . . . . . . . . . . . . . . . . . . . . . . 22 110 5.8 VoucherComponent . . . . . . . . . . . . . . . . . . . . . 22 111 5.8.1 getIdentifier . . . . . . . . . . . . . . . . . . . . . . 22 112 5.8.2 getDocument . . . . . . . . . . . . . . . . . . . . . . . 23 113 5.9 ReceptionListener . . . . . . . . . . . . . . . . . . . . 23 114 5.9.1 arrive . . . . . . . . . . . . . . . . . . . . . . . . . . 24 115 5.10 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . 24 116 6. Example Code . . . . . . . . . . . . . . . . . . . . . . . 25 117 7. Security Considerations . . . . . . . . . . . . . . . . . 26 118 8. Normative References . . . . . . . . . . . . . . . . . . . 27 119 9. Informative References . . . . . . . . . . . . . . . . . . 27 120 10. Author's Address . . . . . . . . . . . . . . . . . . . . . 28 121 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 28 123 1. Introduction 125 This document specifies the Voucher Trading System Application 126 Programming Interface (VTS-API). The motivation and background of 127 the Voucher Trading System (VTS) are described in Requirements for 128 Generic Voucher Trading [VTS]. 130 A voucher is a logical entity that represents a certain right and is 131 logically managed by the VTS. A voucher is generated by the issuer, 132 traded among users, and finally collected using VTS. The terminology 133 and model of the VTS are also described in [VTS]. 135 While VTSs can be implemented in different ways such as a centralized 136 VTS, which uses a centralized online server to store and manage all 137 vouchers, or a distributed VTS, which uses per-user smartcards to 138 maintain the vouchers owned by each user, the VTS-API allows a caller 139 application to issue, transfer, and redeem vouchers in a uniform 140 manner independent of the VTS implementation. Several attempts have 141 been made at providing a generic payment API. Java Commerce Client 142 [JCC] and Generic Payment Service Framework [GPSF], for example, 143 introduce a modular wallet architecture that permits diverse types of 144 payment modules to be added as plug-ins and supports both check- 145 like/cash-like payment models. This document is inspired by these 146 approaches but the scope of this document is limited to the VTS 147 model, in which cash-like payment model is assumed and vouchers are 148 directly or indirectly transferred between sender (transferor) and 149 receiver (transferee) via the VTS. This document is not intended to 150 support API for SET, e-check or other payment schemes that do not fit 151 the VTS model. 153 Unlike the APIs provided in JCC and GPSF, which are designed to 154 transfer only monetary values, this API enables the transfer of a 155 wide-range of values through the use of XML-based Generic Voucher 156 Language [GVL]. The monetary meaning of the voucher is interpreted 157 by the upper application layer using the information described in the 158 language. This approach makes it possible to provide a simpler API 159 in the voucher-transfer layer and enhances runtime efficiency. The 160 API specification in this document is described in the Java language 161 syntax. Bindings for other programming languages may be completed in 162 a future version of this document or separate related specifications. 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119] 168 2. Processing Model 170 This section provides the processing model in which the VTS-API is 171 used. A part of the text in this section has been taken from the 172 Generic Voucher Language specification [GVL]. 174 There are several ways of implementing VTS. For discount coupons or 175 event tickets, for example, a smartcard-based distributed offline VTS 176 is often preferred, whereas for bonds or securities, a centralized 177 online VTS is preferred. While distributed VTSs would utilize public 178 (asymmetric) key-based or shared (symmetric) key-based cryptographic 179 challenge-and-response protocols to trade vouchers securely, 180 centralized VTSs would utilize transactions that rewrite ownerships 181 of vouchers upon their database. It is therefore impractical to 182 define standard protocols for issuing, transferring, or redeeming 183 vouchers at this moment. 185 To provide implementation flexibility, this document assumes a 186 modular wallet architecture that allows multiple VTS to be added as 187 plug-ins. In this architecture, instead of specifying a standard 188 voucher transfer protocol, two specifications, i.e., Voucher 189 Component and VTS-API specifications, are standardized (Figure 1). 191 Sender wallet/Issuing system Receiver wallet/Collecting system 192 +---------------------------+ +---------------------------+ 193 | | | | 194 | | Voucher Component | | 195 | | (Specifies VTS Provider and Promise) | | 196 | |-------------------------------------------------------->| | 197 | | | | | | 198 | | Intention to receive and payment (option) | | 199 | |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | | 200 | | | | | | 201 | | | | | | 202 | | Issue/transfer/ VTS | | VTS Register | | 203 | | redeem request plug-in | plug-in Listener(*1)| | 204 | |------------------>| | | |<------------------| | 205 | | (VTS API) |<- - - - - - - ->| (VTS API) | | 206 | | | VTS-specific | | | 207 | | | protocol if VTS | | | 208 | | | is distributed | | | 209 | | Result |<- - - - - - - ->| Notify(*2) | | 210 | |<------------------| | | |------------------>| | 211 +---------------------------+ +---------------------------+ 212 (*1) Registration is optional. Note also that the VTS plug-ins are 213 usually pre-registered when the wallet or collecting system 214 is started. 215 (*2) If a listener is registered. 217 Figure 1. Wallet architecture with VTS plug-ins 219 In this architecture, a VTS provides a logical view of vouchers 220 called Valid Voucher Set (VVS), which is a set that includes the 221 vouchers managed by the VTS [VTS]. A user's wallet can 222 access (e.g. view, transfer and redeem) the subset of VVS that 223 includes a set of vouchers owned by the user, by interacting with the 224 VTS plug-in via the VTS-API. Likewise, an issuing system can issue a 225 voucher and add it to the VVS and a collecting system can be notified 226 of the redemption of vouchers via the VTS-API. 228 After a sender and a receiver agree on what vouchers are to be traded 229 and which VTS is to be used, the issuing system or wallet system 230 requests the corresponding VTS plug-in to permit the issue, transfer, 231 or redeem transactions to be performed via the VTS-API. The VTS then 232 logically rewrites the ownership of the vouchers on the VVS using the 233 VTS-specific protocol. Since the VTS is responsible for preventing 234 illegal acts on vouchers like forgery or reproduction as required in 235 [VTS], the protocol would include a cryptographic challenge-and- 236 response (in a distributed VTS) or a transactional database manipula- 237 tion with adequate access controls (in a centralized VTS). Finally, 238 a completion event is sent to the wallet systems or issuing/collect- 239 ing systems. 241 This document describes the VTS-API specification. See [GVL] for the 242 Voucher Component specification that gives the syntax and semantics 243 for describing and interpreting meaning of vouchers. 245 3. Design Overview 247 We have adopted the following approach to specify the VTS-API. 249 1) Provide an abstract and uniform API that encapsulates the VTS 250 implementation. For example, a common API is provided for 251 both centralized and distributed VTS. It brings more freedom 252 of VTS selection for issuers and application developers. 254 2) To provide an abstract and uniform API, this document intro- 255 duces an interface called VTSAgent that is associated with a 256 holder and provides methods to manipulate vouchers held by its 257 holder. Vouchers are accessed through the methods provided by 258 the VTSAgent. 260 3) Use existing standards for the VTS branding mechanism (negoti- 261 ation). This document assumes that the VTS to be used for 262 sending a voucher has settled before calling the VTS-APIs. 263 Negotiation can be done within the upper application layer 264 using other standards, e.g., [IOTP] or [ECML], if necessary. 266 4) Support only push-type voucher transfer interface in which 267 voucher transfer session is initiated by the transferor side. 268 Pull-type voucher transfer interface can be implemented on top 269 of the push-type VTS interface at application level. 271 4. Concepts 273 The VTS-API consists of the following interfaces. A VTS is required 274 to implement all of the interfaces except ReceptionListener, which is 275 intended to be implemented by wallets or other applications that use 276 VTS. 278 VTSManager 279 Provides the starting point to use a VTS plug-in. All of the 280 objects needed to manipulate vouchers can be directly or indi- 281 rectly acquired via the VTSManager. A VTSManager maintains 282 the two repositories; a ParticipantRepository and a Voucher- 283 ComponentRepository described below. 285 ParticipantRepository 286 Provides the access points of Participants, which are to be 287 trading partners. A ParticipantRepository maintains Partici- 288 pants and acts as an "address book" of trading partners. 290 Participant 291 Represents a participant (such as issuers, holders, and 292 collectors). A Participant knows how to obtain the corre- 293 sponding VTSAgent described below. 295 VTSAgent (extends Participant) 296 Provides the access point of vouchers in Valid Voucher Set 297 (VVS) that is logically managed by VTS. A VTSAgent provides a 298 means of manipulating vouchers held by its holder; basic trad- 299 ing methods, i.e., issue, transfer, consume, and present. 300 Before calling trading methods, the application must create a 301 Session which is described below. 303 Session 304 Represents the logical connection established by the trade. A 305 Session has references to two Participants, i.e., the sender 306 and the receiver. After trading methods are called using a 307 Session, the Session holds a reference to the Vouchers to be 308 traded. 310 Voucher 311 Represents one or more vouchers of which all of the issuer 312 part and promise part of vouchers are the same. A Voucher 313 holds references to the Participant (issuer) who issued the 314 voucher and a VoucherComponent (promise) which is described 315 below. 317 VoucherComponent 318 Represents a Voucher Component described in [GVL]. It defines 319 the promise part of the voucher. 321 VoucherComponentRepository 322 Provides the access points of VoucherComponents. A Voucher- 323 ComponentRepository maintains VoucherComponents and acts as a 324 "voucher type book" managed by the VTS. This document assumes 325 that a set of VoucherComponents has been acquired and stored 326 in this repository. Delivery of VoucherComponents is beyond 327 the scope of this document. It may be delivered within the 328 VTS from the trading partners or manually acquired from a 329 trusted third party (See Section 3 of [GVL]). 331 ReceptionListener 332 Provides a listener function with regard to the receipt of a 333 voucher by VTSAgent to wallets or other applications that 334 implement this interface. (This interface may not be imple- 335 mented as part of VTS) 337 5. Interface Definitions 339 The interfaces defined in this document reside in the package named 340 "org.ietf.vts". Wallets or other applications that use this 341 API,should import this package as "import org.ietf.vts.*;". 343 5.1 VTSManager 345 public interface VTSManager 347 Provides the starting point to use a VTS plug-in. 349 All of the objects needed to manipulate vouchers can be directly or 350 indirectly acquired via a VTSManager, so that wallets or other 351 applications can make the VTS available by instantiating an object 352 implementing this interface. 354 A class that implements the VTSManager interface must have a public 355 default constructor (a constructor without any parameters). The 356 VTS provides a name for such constructor so that the implementation 357 class can bootstrap the interface. 359 5.1.1 getParticipantRepository 361 public ParticipantRepository getParticipantRepository() 363 Returns a repository that maintains Participants. 365 Returns: 367 the ParticipantRepository of the VTS, or null if no 368 ParticipantRepository is available. 370 5.1.2 getVoucherComponentRepository 372 public VoucherComponentRepository getVoucherComponentRepository() 374 Returns a repository that maintains VoucherComponents. 376 Returns: 378 the VoucherComponentRepository of the VTS, or null if no 379 VoucherComponentRepository is available. 381 5.2 ParticipantRepository 383 public interface ParticipantRepository 385 Provides the access points of Participants. A ParticipantRepository 386 maintains Participants and acts as an "address book" of trading 387 partners. 389 The object implementing this interface maintains Participants (or 390 holds a reference to an object maintaining Participants), which are 391 to be trading partners. 393 The implementation of ParticipantRepository may be either (an 394 adaptor to) "yellow pages" which is a network-wide directory 395 service like LDAP, or "pocket address book" which maintains only 396 personal acquaintances. 398 5.2.1 lookup 400 public Participant lookup(String id) 402 Retrieves the participant that has the specified id. 404 Returns: 406 the participant associated with the specified id or null if the id 407 is null or the corresponding participant cannot be found. 409 5.3 Participant 411 public interface Participant 413 Represents the participants (such as issuers, holders, and 414 collectors). 416 This interface is used as representation of the trade partners and 417 issuers of vouchers. Anyone can retrieve objects implementing 418 Participant from the participant repository. 420 5.3.1 getIdentifier 422 public String getIdentifier() 424 Returns the identifier of the participant. Each participant must 425 have a unique identifier. 427 The identifier can be used for looking up and retrieving the 428 participant via the ParticipantRepository. 430 The format of the identifier is implementation-specific. 432 Returns: 434 the identifier string of the participant. 436 5.3.2 getVTSAgent 438 VTSAgent getVTSAgent() 440 Returns a VTSAgent, whose identifier is the same as the identifier 441 of the participant. 443 Returns: 445 an object implementing VTSAgent. 447 5.4 VTSAgent 449 public interface VTSAgent extends Participant 451 Represents contact points to access vouchers in Valid Voucher Set 452 (VVS) that is managed by the VTS. 454 Each VTSAgent is associated with a holder and provides a means for 455 managing vouchers owned by the holder. The holder must be 456 authenticated using the login() method before being called by any 457 other method, or VTSSecurityException will be issue. 459 Before calling any trading method, i.e., issue(), transfer(), 460 consume(), and present(), the application must establish a session 461 by the prepare() method. 463 Sessions may often be suspended due to network failure when the 464 voucher is sent via a network. The suspended sessions can be 465 restarted by the resume() method. Details on the state management 466 of a session are described in Section 5.5. 468 Some VTSAgents may not have all of the trading methods; a voucher 469 collecting system doesn't require its VTSAgent to provide method 470 for issuing or creating vouchers. A VTSAgent returns 471 FeatureNotAvailableException when an unsupported method is invoked. 473 5.4.1 login 475 public void login(String passphrase) 476 throws VTSException 478 Authenticates the VTSAgent. The passphrase is specified if the VTS 479 requires it for authentication, otherwise it must be null. Nothing 480 is performed if the VTSAgent has already been logged-in. The 481 authentication scheme is implementation-specific. Examples of the 482 implementation are as follows: 484 1) Vouchers are managed on a remote centralized server (centralized 485 VTS), which requires a password to login. In this case, the 486 application may prompt the user to input the password and can be 487 given to the VTSAgent through this method. See Implementation 488 Notes below. 490 2) Vouchers are managed on a remote centralized server (centralized 491 VTS), which requires challenge-and-response authentication using 492 smartcards held by users. In this case, the passphrase may be 493 null since access to the smartcard can be done without 494 contacting the application or user, i.e., the VTSAgent receives 495 the challenge from the server, sends the challenge to the 496 smartcard (within the VTS), and returns the response from the 497 smartcard to the server. Note that a PIN to unlock the 498 smartcard may be given through this method depending on the 499 implementation. 501 3) Each user holds their own smartcard in which their own vouchers 502 are stored (distributed VTS). In this case, the passphrase may 503 be null since no authentication is required. Note that a PIN to 504 unlock the smartcard may be given through this depends on the 505 implementation. 507 Implementation Notes: 509 A VTS is responsible for providing secure ways for users to 510 login(); it is strongly recommended to utilize secure 511 communication channels such as [TLS] if secret or privacy 512 information is sent via networks. Fake server attacks including 513 so-called MITM (man-in-the-middle) must be considered as well. 515 Throws: 517 VTSSecurityException - if authentication fails. 519 5.4.2 logout 521 public void logout() 522 throws VTSException 524 Voids the authentication performed by the login() method. 526 After calling this method, calling any other method (except 527 login()) will cause VTSSecurityException. 529 The VTSAgent can login again by the login() method. 531 Throws: 533 VTSSecurityException - if the VTSAgent is not authenticated 534 correctly. 536 5.4.3 prepare 538 public Session prepare(Participant receiver) 539 throws VTSException 541 Establishes a session that is required for trading vouchers. The 542 trading partner who receives the vouchers is specified as receiver. 543 The vouchers to be traded will be specified later (when a trading 544 method is called). 546 The establishment of a session is implementation-specific. A 547 centralized VTS implementation may start a transaction, while a 548 distributed VTS implementation may get, from the receiver, the 549 challenge needed to create an authentic response in the 550 following trading method. 552 If the VTSAgent has no ability to establish a session with the 553 specified receiver (permanent error), the VTSAgent throws an 554 InvalidParticipantExeption. If the VTSAgent can not establish a 555 session due to network failure (transient error), the VTSAgent 556 throws a CannotProceedException. 558 Parameters: 560 receiver - the trading partner who receives vouchers. 562 Returns: 564 an established session whose state is "prepared" (see Section 5.5). 566 Throws: 568 CannotProceedException - if the preparation of the session is 569 aborted (e.g. network failures). 570 FeatureNotAvailableException - if the VTSAgent does not provide 571 any trading methods. 572 InvalidParticipantException - if the specified participant is 573 invalid. 574 VTSSecurityException - if the VTSAgent cannot be authenticated 575 correctly. 577 5.4.4 issue 579 public void issue(Session session, 580 VoucherComponent promise, 581 java.lang.Number num) 582 throws VTSException 584 Issues vouchers. This method creates the specified number of 585 vouchers and adds them to the VVS. If 586 the VTS is distributed, this method would create a "response" 587 corresponding to the challenge received in the prepare() method and 588 send it to the receiver. Note that the receiver is specified when 589 prepare() is called. Nothing is performed if the specified 590 number is 0. 592 The session MUST be "prepared" when calling this method. The state 593 of the session will be "activated" when the vouchers are created, and 594 it will be "completed" when the transaction is successfully completed 595 or "suspended" if the transaction is interrupted abnormally (e.g., 596 network failures). 598 Parameters: 600 session - the session used by the issue transaction. 601 promise - the promise part of the voucher. 602 num - the number of vouchers to be issued. 604 Throws: 606 CannotProceedException - if the transaction cannot be successfully 607 completed. 608 FeatureNotAvailableException - if the VTSAgent does not provide 609 a means of issuing vouchers. 610 InvalidStateException - if the session is not "prepared". 611 VTSSecurityException - if the VTSAgent cannot be authenticated 612 correctly. 614 5.4.5 transfer 616 public void transfer(Session session, 617 Participant issuer, 618 VoucherComponent promise, 619 java.lang.Number num) 620 throws VTSException 622 Transfers vouchers. This method rewrites the specified number of 623 vouchers to in 624 the VVS; i.e. deletes the vouchers from the sender and stores them 625 for the receiver. Similar to issue(), this method would create 626 and send the response to the receiver if the VTS is distributed. 627 The VTSAgent must have sufficient vouchers in the VVS. Nothing is 628 performed if the specified number is 0. 630 The session MUST be "prepared" when calling this method. The state 631 of the session will be "activated" when the voucher are retrieved 632 from the sender, and it will be "completed" when the transaction is 633 successfully completed or "suspended" if the transaction is 634 interrupted abnormally (e.g., network failures). 636 If null is specified for the issuer parameter, it indicates "any 637 issuer". This method selects vouchers to be transferred from the set 638 of vouchers returned by the getContents(null, promise). 640 Parameters: 642 session - the session used by the transfer transaction. 643 issuer - the issuer part of the voucher, or null. 644 promise - the promise part of the voucher. 645 num - the number of vouchers to be transferred. 647 Throws: 649 CannotProceedException - if the transaction cannot be successfully 650 completed. 651 FeatureNotAvailableException - if the VTSAgent does not provide 652 a means of transferring vouchers. 653 InsufficientVoucherException - if the VTSAgent doesn't have a 654 sufficient number of vouchers to transfer. 655 InvalidStateException - if the session is not "prepared". 656 VTSSecurityException - if the VTSAgent cannot be authenticated 657 correctly. 659 5.4.6 consume 661 public void consume(Session session, 662 Participant issuer, 663 VoucherComponent promise, 664 java.lang.Number num) 665 throws VTSException 667 Consumes vouchers. This method deletes the specified number of 668 vouchers from the VVS and notifies the 669 deletion to the receiver. Similar to issue() and transfer(), the 670 response would be created and sent to the receiver if the VTS is 671 distributed so that the receiver can obtain proof of the deletion. 672 The VTSAgent must have a sufficient number of vouchers in the VVS. 673 Nothing is performed if the specified number is 0. 675 The session MUST be "prepared" when calling this method. The state 676 of the session will be "activated" when the vouchers are deleted, 677 and it will be "completed" when the transaction is successfully 678 completed or "suspended" if the transaction is interrupted 679 abnormally (e.g., network failures). 681 If null is specified for the issuer parameter, it indicates "any 682 issuer". This method selects vouchers to be consumed from the set 683 of vouchers returned by the getContents(null, promise). 685 Parameters: 687 session - the session used by the consume transaction. 688 issuer - the issuer part of the voucher, or null. 689 promise - the promise part of the voucher. 690 num - the number of vouchers to be consumed. 692 Throws: 694 CannotProceedException - if the transaction cannot be successfully 695 completed. 696 FeatureNotAvailableException - if the VTSAgent does not provide 697 a means of consuming vouchers. 698 InsufficientVoucherException - if the VTSAgent doesn't have a 699 sufficient number of vouchers to consume. 701 InvalidStateException - if the session is not "prepared". 702 VTSSecurityException - if the VTSAgent cannot be authenticated 703 correctly. 705 5.4.7 present 707 public void present(Session session, 708 Participant issuer, 709 VoucherComponent promise, 710 java.lang.Number num) 711 throws VTSException 713 Presents vouchers. This method shows that the sender has the 714 specified number of vouchers in the VVS to 715 the receiver of the session; No modification is performed to the 716 VVS. However, the response would be sent in order to give the 717 proof to the receiver as well as consume() if the VTS is 718 distributed. The VTSAgent must have a sufficient number of 719 vouchers in the VVS. Nothing is performed if the specified number 720 is 0. 722 The session MUST be "prepared" when calling this method. The state 723 of the session will be "activated" when the vouchers are retrieved, 724 and it will be "completed" when the transaction is successfully 725 completed or "suspended" if the transaction is interrupted 726 abnormally (e.g., by network failures). 728 If null is specified for the issuer parameter, it indicates "any 729 issuer". This method selects vouchers to be presented from the set 730 of vouchers returned by the getContents(null, promise). 732 Parameters: 734 session - the session used by the present transaction. 735 issuer - the issuer part of the voucher, or null. 736 promise - the promise part of the voucher. 737 num - the number of the voucher to be presented. 739 Throws: 741 CannotProceedException - if the transaction cannot be successfully 742 completed. 743 InsufficientVoucherException - if the VTSAgent doesn't have a 744 sufficient number of vouchers to present. 745 InvalidStateException - if the session is not "prepared". 746 FeatureNotAvailableException - if the VTSAgent does not provide 747 a means of presenting vouchers. 748 VTSSecurityException - if the VTSAgent cannot be authenticated 749 correctly. 751 5.4.8 cancel 752 public void cancel(Session session) 753 throws VTSException 755 Releases the session. "Prepared" sessions MUST be canceled. An 756 implementation MAY be permitted to cancel "activated" or 757 "suspended" sessions. 759 Throws: 761 InvalidStateException - if the state of the session isn't 762 cancelable. 763 VTSSecurityException - if the VTSAgent cannot be authenticated 764 correctly. 766 5.4.9 resume 768 public void resume(Session session) 769 throws VTSException 771 Restarts the session. Only "suspended" sessions can be resumed. 772 The state of the session will be re-"activated" immediately, and it 773 will be "completed" when the transaction is successfully completed 774 or "suspended" again if the transaction is interrupted abnormally 775 (e.g., network failures). 777 Throws: 779 CannotProceedException - if the transaction cannot be successfully 780 completed. 781 InvalidStateException - if the session is not "suspended". 782 VTSSecurityException - if the VTSAgent cannot be authenticated 783 correctly. 785 5.4.10 create 787 public void create(VoucherComponent promise, java.lang.Number num) 788 throws VTSException 790 Creates vouchers where the issuer is the VTSAgent itself. This 791 method creates the specified number of vouchers and adds them to the VVS. Nothing is performed if the 793 specified number is 0. 795 Throws: 797 FeatureNotAvailableException - if the VTSAgent does not provide 798 a means of creating vouchers. 799 VTSSecurityException - if the VTSAgent cannot be authenticated 800 correctly. 802 5.4.11 delete 803 public void delete(Participant issuer, VoucherComponent 804 promise, java.lang.Number num) 805 throws VTSException 807 Deletes vouchers. This method deletes the specified number of 808 vouchers from the VVS. The VTSAgent must 809 have sufficient vouchers in the VVS. Nothing is performed if the 810 specified number is 0. 812 Throws: 814 InsufficientVoucherException - if the VTSAgent doesn't have 815 sufficient number of vouchers to delete. 816 VTSSecurityException - if the VTSAgent cannot be authenticated 817 correctly. 819 5.4.12 getContents 821 public java.util.Set getContents(Participant issuer, 822 VoucherComponent promise) 823 throws VTSException 825 Returns the set of vouchers whose issuer and promise both match the 826 issuer and promise specified in the parameters. 828 If null is specified for the issuer or promise parameter, it 829 indicates "any issuer" or "any promise", respectively. If null is 830 specified for both parameters, this method selects all vouchers 831 owned by the holder from the VVS. 833 Returns: 835 the set of vouchers held by the holder of the VTSAgent. 837 Throws: 839 VTSSecurityException - if the VTSAgent cannot be authenticated 840 correctly. 842 5.4.13 getSessions 844 public java.lang.Set getSessions() 845 throws VTSException 847 Returns a set of not-completed sessions prepared by the VTSAgent. 849 Returns: 851 the set of sessions prepared by the VTSAgent and not yet completed. 853 Throws: 855 VTSSecurityException - if the VTSAgent cannot be authenticated 856 correctly. 858 5.4.14 getLog 860 public java.lang.Set getLog() 861 throws VTSException 863 Returns a set of completed sessions prepared or received by the 864 VTSAgent. This set represents the trading log of the VTSAgent. A 865 VTS may delete an old log eventually, so that the entire log may 866 not be returned; the amount of the log kept by the VTSAgent is 867 implementation-specific. 869 Returns: 871 the set of completed sessions prepared or received by the VTSAgent. 873 Throws: 875 VTSSecurityException - if the VTSAgent cannot be authenticated 876 correctly. 878 5.4.15 addReceptionListener 880 public void addReceptionListener(ReceptionListener l) 881 throws VTSException 883 Adds a ReceptionListener to the listener list. 885 After a ReceptionListener l is registered by this method, l.arrive() 886 will be called whenever the VTSAgent receives a voucher. 888 Nothing is performed if the specified listener is null. 890 Throws: 892 VTSSecurityException - if the VTSAgent cannot be authenticated 893 correctly. 895 5.4.16 removeReceptionListener 897 public void removeReceptionListener(ReceptionListener l) 898 throws VTSException 900 Removes a ReceptionListener from the listener list. 902 Nothing is performed when the specified listener is null or not 903 registered. 905 Throws: 907 VTSSecurityException - if the VTSAgent cannot be authenticated 908 correctly. 910 5.5 Session 912 public interface Session 914 Represents the logical connection established by the trade. 915 Sessions are established by VTSAgent#prepare(). 917 A session has four states: prepared, activated, suspended, and 918 completed. The initial state of a session is "prepared", and the 919 session will be "activated" immediately when any of the trading 920 methods of VTSAgent is called. The "activated" session will be 921 "completed" after the trading method is successfully completed. If 922 the trading method is transiently failed (e.g. network failure), 923 the session will be "suspended". Suspended sessions can be 924 re-"activated" and restarted by calling VTSAgent#resume(). 926 A completed session may disappear from the VTSAgent; the session 927 will be collected by the GC unless other objects keep its 928 reference. 930 5.5.1 getIdentifier 932 public String getIdentifier() 934 Returns the identifier of the session. The generation scheme of 935 the identifier is implementation-specific. An implementation may 936 use a transaction ID as the identifier of the session. 938 Returns: 940 the string of the identifier of the session. 942 5.5.2 getVoucher 944 public Voucher getVoucher() 946 Returns the voucher to be traded using the session, or returns null 947 if the session has not been activated. 949 Returns: 951 the voucher to be traded or null if the state of the session is 952 "prepared". 954 5.5.3 getSender 956 public Participant getSender() 957 Returns the sender of the session, i.e., the creator who prepared 958 the session. 960 Returns: 962 the sender of the session. 964 5.5.4 getReceiver 966 public Participant getReceiver() 968 Returns the receiver of the session, i.e., the participant 969 specified when preparing the session (by the VTSAgent#prepare() 970 method). 972 Returns: 974 the receiver of the session. 976 5.5.5 isPrepared 978 public boolean isPrepared() 980 Verifies if the session is "prepared". 982 Returns: 984 true if the session is in "prepared" state, or false. 986 5.5.6 isActivated 988 public boolean isActivated() 990 Verifies if the session is "activated". 992 Returns: 994 true if the session is in "activated" state, or false. 996 5.5.7 isSuspended 998 public boolean isSuspended() 1000 Verifies if the session is "suspended". 1002 Returns: 1004 true if the session is in "suspended" state, or false. 1006 5.5.8 isCompleted 1007 public boolean isCompleted() 1009 Verifies if the session is "completed". 1011 Returns: 1013 true if the session is in "completed" state, or false. 1015 5.6 Voucher 1017 public interface Voucher 1019 Represents voucher(s) described in [VTS]. An object implementing 1020 this interface can represent more than one voucher if all of the 1021 issuer part and the promise part of the vouchers are the same. 1023 5.6.1 getIssuer 1025 public Participant getIssuer() 1027 Returns the issuer part of the voucher(s). 1029 Returns: 1031 the participant who issued the voucher(s). 1033 5.6.2 getPromise 1035 public VoucherComponent getPromise() 1037 Returns the promise part of the voucher(s). 1039 Returns: 1041 the voucher component that defines the promise of the voucher. 1043 5.6.3 getCount 1045 public java.lang.Number getCount() 1047 Returns the number of the voucher(s). 1049 Returns: 1051 the positive (>0) number of the voucher(s). 1053 5.7 VoucherComponentRepository 1055 public interface VoucherComponentRepository 1057 Maintains VoucherComponents. 1059 An object implementing VoucherComponentRepository provides a means 1060 of retrieving the voucher components that are the promises of 1061 vouchers in the VVS. 1063 Before issuing a voucher, the promise of the voucher must be 1064 registered with this repository. The repository can be implemented 1065 as either a network-wide directory service or personal storage like 1066 the ParticipantRepository. 1068 5.7.1 register 1070 public VoucherComponent register(org.w3c.dom.Document document) 1072 Creates a voucher component associated with the specified DOM 1073 object and registers the voucher component with the repository. 1075 A voucher component of the voucher to be issued must be registered 1076 using this method. 1078 Nothing is performed (and the method returns null) if the specified 1079 document is null or the syntax of the document does not conform to 1080 the VTS. 1082 The method returns the registered voucher component if the 1083 specified DOM object has been already registered. (No new voucher 1084 component is created in this case). 1086 Returns: 1088 a registered voucher component associated with the specified 1089 document, or null if the document is null or has wrong syntax. 1091 5.8 VoucherComponent 1093 public interface VoucherComponent 1095 Represents the voucher component that defines the promise of the 1096 voucher. 1098 Each VoucherComponent object has its own unique identifier, and it 1099 is associated with an XML document that describes the promise made 1100 by the issuer of the voucher, e.g., the goods or services can be 1101 claimed in exchange for redeeming the voucher. 1103 This interface can be implemented as sort of a "smart pointer" to 1104 the XML document. An implementation may have a reference to a 1105 voucher component repository instead of the voucher component and 1106 retrieve the document dynamically from the repository when the 1107 getDocument() method is called. 1109 5.8.1 getIdentifier 1110 public String getIdentifier() 1112 Returns the identifier of the voucher component. Each voucher 1113 component must have a unique identifier. The identifier may be 1114 used to check for equivalence of voucher components. 1116 The format of the identifier is implementation-specific, however, 1117 it is RECOMMENDED to include the hash value of the voucher 1118 component in the identifier to assure its uniqueness. For 1119 generating the hash value, it is desirable to use a secure hash 1120 function, e.g., [SHA-1], and to apply a canonicalization function, 1121 e.g., [EXC-C14N], before applying the hash function to minimize the 1122 impact of insignificant format changes to the voucher component, 1123 e.g., line breaks or character encoding. 1125 Returns: 1127 The identifier string of the voucher component. 1129 5.8.2 getDocument 1131 public org.w3c.dom.Document getDocument() 1133 Returns a Document Object Model [DOM] representation of the 1134 document associated with the voucher component by the 1135 VoucherComponentRepository#register() method. 1137 The DOM object to be returned may be retrieved from a 1138 VoucherComponentRepository on demand, instead of the 1139 VoucherComponent always keeping a reference to the DOM object. 1141 The VTS must guarantee that the getDocument method will eventually 1142 return the DOM object provided that the voucher associated with the 1143 corresponding voucher component exists in the VVS. 1145 Returns: 1147 a DOM representation of the document associated with the voucher 1148 component. 1150 Throws: 1152 DocumentNotFoundException - if the associated DOM object cannot be 1153 retrieved. 1155 5.9 ReceptionListener 1157 public interface ReceptionListener extends java.util.EventListener 1159 Provides a listener interface that provides notification that a 1160 VTSAgent has been received a voucher. 1162 When a voucher arrives at VTSAgent, the VTSAgent invokes arrive() 1163 method of each registered ReceptionListener. ReceptionListeners 1164 can obtain a Session object, which contains information about the 1165 received voucher and the sender of the voucher. 1167 This interface is intended to provide a means of notifying a wallet 1168 that "You have new vouchers", so that this interface may be 1169 implemented by wallets or other applications using VTS. 1171 5.9.1 arrive 1173 public void arrive(Session session) 1175 Provides notification of the arrival of a voucher. 1177 After the listener is registered to a VTSAgent (by the 1178 VTSAgent#addReceptionListener() method), the VTSAgent invokes this 1179 method whenever it receives a voucher. 1181 The specified session is equivalent to the session used by the 1182 sender to trade the voucher. The state of the session is 1183 "completed" when this method is called. 1185 5.10 Exceptions 1187 java.lang.Exception 1188 +-- VTSException 1189 +-- CannotProceedException 1190 +-- DocumentNotFoundException 1191 +-- FeatureNotAvailableException 1192 +-- InsufficientVoucherException 1193 +-- InvalidParticipantException 1194 +-- InvalidStateException 1195 +-- VTSSecurityException 1197 VTSException 1198 This is the superclass of all exceptions thrown by the methods 1199 in the interfaces constructs the VTS-API. 1201 CannotProceedException 1202 This exception is thrown when a trading is interrupted due to 1203 network failures or other errors. 1205 DocumentNotFoundException 1206 This exception is thrown when the document associated with a 1207 voucher component cannot be found. 1209 FeatureNotAvailableException 1210 This exception is thrown when the invoked method is not sup- 1211 ported. 1213 InsufficientVoucherException 1214 This exception is thrown when the number of the voucher is 1215 less than the number specified to trade. 1217 InvalidParticipantException 1218 This exception is thrown when the specified participant cannot 1219 be located. 1221 InvalidStateException 1222 This exception is thrown when the state of the session is 1223 invalid to proceed the operation. 1225 VTSSecurityException 1226 This exception is thrown when authentication fails or a method 1227 which requires authentication in advance is called without 1228 authentication. 1230 6. Example Code 1232 // Issue a voucher 1234 VTSManager vts = new FooVTSManager(); 1235 ParticipantRepository addrBook = vts.getParticipantRepository(); 1236 VoucherComponentRepository vcr = vts.getVoucherComponentRepository(); 1238 Participant you = addrBook.lookup("http://example.org/foo"); 1239 // looks up a trading partner identified as "http://example.org/foo". 1240 VTSAgent me = addrBook.lookup("myName").getVTSAgent(); 1241 // a short-cut name may be used if VTS implementation allows. 1243 VoucherComponent promise = vcr.register(anXMLVoucherDocument); 1244 // registers a voucher component corresponding to the voucher to 1245 // be issued. 1247 try { 1248 me.login(); 1249 // sets up the issuer's smartcard (assuming distributed VTS). 1250 s = me.prepare(you); 1251 // receives a challenge from the partner. 1252 me.issue(s, promise, 1); 1253 // sends a voucher using the received challenge. 1254 me.logout(); 1255 } catch (VTSException e) { 1256 // if an error (e.g. a network trouble) occurs... 1257 System.err.println("Sorry."); 1258 e.printStackTrace(); 1259 // this example simply prints a stack trace, but a real wallet 1260 // may prompt the user to retry (or cancel). 1261 } 1262 // Transfer all my vouchers 1264 VTSManager vts = new FooVTSManager(); 1265 ParticipantRepository addrBook = vts.getParticipantRepository(); 1267 Participant you = addrBook.lookup("8f42 5aab ffff cafe babe..."); 1268 // some VTS implementations would use a hash value of a public key 1269 // (aka fingerprint) as an identifier of a participant. 1270 VTSAgent me = addrBook.lookup("myName").getVTSAgent(); 1272 try { 1273 me.login(); 1274 Iterator i = me.getContents(null, null).iterator(); 1276 while (i.hasNext()) { 1277 Voucher v = (Voucher) i.next(); 1278 s = me.prepare(you); 1279 me.transfer(s, v.getIssuer(), v.getPromise(), v.getCount()); 1280 } 1282 me.logout(); 1283 } catch (VTSException e) { 1284 System.err.println("Sorry."); 1285 e.printStackTrace(); 1286 } 1288 // Register an incoming voucher notifier (biff) 1290 VTSManager vts = new FooVTSManager(); 1292 ParticipantRepository addrBook = vts.getParticipantRepository(); 1293 VTSAgent me = addrBook.lookup("myName").getVTSAgent(); 1295 ReceptionListener listener = new ReceptionListener() { 1296 public void arrive(Session s) { 1297 System.out.println("You got a new voucher."); 1298 } 1299 }; 1301 try { 1302 me.login(); 1303 me.addReceptionListener(listener); 1304 me.logout(); 1305 } catch (VTSException e) { 1306 System.err.println("Sorry."); 1307 e.printStackTrace(); 1308 } 1310 7. Security Considerations 1311 Security is very important for trading vouchers. VTS implementations 1312 are responsible for preventing illegal acts upon vouchers as 1313 described in [VTS], as well as preventing malicious accesses from 1314 invalid users and fake server attacks including man-in-the-middle 1315 attacks. 1317 The means to achieve the above requirements are not specified in this 1318 document since it depends on VTS implementation, however, securing 1319 communication channels (e.g. using TLS) between client VTS plug-ins 1320 and the central server in a centralized VTS (as described in 5.4.1 1321 login()) and applying cryptographic challenge-and-response techniques 1322 in a distributed VTS are likely helpful and strongly recommended to 1323 implement a secure VTS. 1325 This document assumes that the VTS plug-in is trusted by its user. 1326 The caller application of a VTS should authenticate the VTS plug-in 1327 and bind it securely using the VTS Provider information specified in 1328 the Voucher Component. This document, however, does not specify any 1329 application authentication scheme and it is assumed to be specified 1330 by other related standards. Until various VTS systems are deployed, 1331 it is enough to manually check and install VTS plug-ins like other 1332 download applications. 1334 8. Normative References 1336 [DOM] V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le 1337 Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood. "Docu- 1338 ment Object Model (DOM) Level 1 Specification", W3C Recommendation, 1339 October 1998, 1341 [GVL] K. Fujimura and M. Terada, "XML Voucher: Generic Voucher Lan- 1342 guage", draft-ietf-trade-voucher-lang-06.txt, 2004. 1344 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require- 1345 ment Levels", BCP 14, RFC 2119, 1997. 1347 9. Informative References 1349 [ECML] J. W. Parsons and D. Eastlake "Electronic Commerce Modeling 1350 Language (ECML) Version 2 Specification", draft-ietf-trade- 1351 ecml2-spec-09.txt, 2004. 1353 [EXC-C14N] J. Boyer, D. Eastlake, and J. Reagle, "Exclusive XML 1354 Canonicalization Version 1.0", W3C Recommendation, July 2002, 1355 1357 [GPSF] G. Lacoste, B. Pfitzmann, M. Steiner, and M. Waidner (Eds.), 1358 "SEMPER - Secure Electronic Marketplace for Europe," LNCS 1854, 1359 Springer-Verlag, 2000. 1361 [IOTP] D. Burdett, "Internet Open Trading Protocol - IOTP Version 1362 1.0", RFC 2801, 2000. 1364 [JCC] T. Goldstein, "The Gateway Security Model in the Java Elec- 1365 tronic Commerce Framework", Proc. of Financial Cryptography '97, 1366 1997. 1368 [SHA-1] Department of Commerce/National Institute of Standards and 1369 Technology, "FIPS PUB 180-1. Secure Hash Standard. U.S.", 1370 1372 [VTS] K. Fujimura and D. Eastlake, "Requirements and Design for 1373 Voucher Trading System (VTS)", RFC3506, 2003. 1375 10. Author's Address 1377 Masayuki Terada 1378 NTT DoCoMo, Inc. 1379 3-5 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 1380 Phone: +81-(0)46-840-3809 1381 Fax: +81-(0)46-840-3364 1382 Email: te@mml.yrp.nttdocomo.co.jp 1384 Ko Fujimura 1385 NTT Corporation 1386 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 JAPAN 1387 Phone: +81-(0)46-859-3814 1388 Fax: +81-(0)46-859-8329 1389 Email: fujimura@isl.ntt.co.jp 1391 Full Copyright Statement 1393 Copyright (C) The Internet Society (2004). All Rights Reserved. 1395 This document and translations of it may be copied and furnished to 1396 others, and derivative works that comment on or otherwise explain it 1397 or assist in its implementation may be prepared, copied, published 1398 and distributed, in whole or in part, without restriction of any 1399 kind, provided that the above copyright notice and this paragraph are 1400 included on all such copies and derivative works. However, this doc- 1401 ument itself may not be modified in any way, such as by removing the 1402 copyright notice or references to the Internet Society or other 1403 Internet organizations, except as needed for the purpose of develop- 1404 ing Internet standards in which case the procedures for copyrights 1405 defined in the Internet Standards process must be followed, or as 1406 required to translate it into languages other than English. 1408 The limited permissions granted above are perpetual and will not be 1409 revoked by the Internet Society or its successors or assigns. 1411 This document and the information contained herein is provided on an 1412 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1413 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1414 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1415 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 1416 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.