idnits 2.17.00 (12 Aug 2021) /tmp/idnits62178/draft-eastlake-cybercash-v08-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-eastlake-cybercash-v08-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-eastlake-cybercash-v08-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-eastlake-cybercash-v08-00.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-eastlake-cybercash-v08-00.txt,', but the file name used is 'draft-eastlake-cybercash-v08-00' == 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 Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 286 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 9 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 18 has weird spacing: '...ard but is i...' == Line 19 has weird spacing: '...rmation of t...' == Line 22 has weird spacing: '...ment is an I...' == Line 23 has weird spacing: '...cuments of t...' == Line 24 has weird spacing: '...ups may also ...' == (281 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (8 July 1995) is 9807 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ISO 4217' is defined on line 2246, but no explicit reference was found in the text == Unused Reference: 'RFC 822' is defined on line 2251, but no explicit reference was found in the text == Unused Reference: 'RFC 1521' is defined on line 2254, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 4217' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) Summary: 15 errors (**), 1 flaw (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 Expires: 7 January 1996 CyberCash 3 Brian Boesch 4 CyberCash 5 Steve Crocker 6 CyberCash 7 Magdalena Yesil 8 CyberCash 9 8 July 1995 11 CyberCash Credit Card Protocol Version 0.8 12 --------- ------ ---- -------- ------- --- 14 Status of This Document 16 This draft, file name draft-eastlake-cybercash-v08-00.txt, is intended 17 to be become an Informational RFC. Distribution of this document is 18 unlimited. It does not specify a standard but is intended for the 19 information of the Internet community. Comments should be sent to 20 dee@cybercash.com. 22 This document is an Internet-Draft. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months. Internet-Drafts may be updated, replaced, or obsoleted by 29 other documents at any time. It is not appropriate to use Internet- 30 Drafts as reference material or to cite them other than as a 31 ``working draft'' or ``work in progress.'' 33 To learn the current status of any Internet-Draft, please check the 34 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 35 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, 36 munnari.oz.au, or ftp.is.co.za. 38 Abstract 40 CyberCash is developing a general payments system for use over the 41 Internet. The structure and communications protocols of version 0.8 42 are described. This version includes credit card payments only. 43 Additional capabilities are planned for future versions. 45 This document covers only the current CyberCash system which is one 46 of a few operational systems in the rapidly evolving area of Internet 47 payments. CyberCash is committed to the further development of its 48 system and to cooperation with the Internet Engineering Task Force 49 and other standards organizations. 51 Acknowledgements 53 The significant contributions of the following persons (in alphabetic 54 order) to this protocol are gratefully acknowledged: 56 Bruce Binder, Judith Grass, Alden Hart, Steve Kiser, Steve 57 Klebe, Garry Knox, Tom Lee, Bob Lindenberg, Jim Lum, Bill 58 Melton, Denise Paredes, Prasad, Fred Silverman, Bruce Wilson, 59 Garland Wong, Wei Wu, Mark Zalewski. 61 Table of Contents 63 Status of This Document....................................1 65 Abstract...................................................2 66 Acknowledgements...........................................2 68 Table of Contents..........................................3 70 1. Overall System..........................................5 71 1.1 System Overview........................................5 72 1.2 Security Approach......................................6 73 1.2.1 Authentication and Persona Identity..................6 74 1.2.2 Privacy..............................................7 75 1.3 Credit Card Operation..................................7 77 2. General Message Wrapper Format..........................9 78 2.1 Message Format.........................................9 79 2.1 Details of Format......................................9 80 2.2 Body Parts............................................10 81 2.3 Transparent Part......................................11 82 2.4 Opaque Part...........................................11 83 2.5 Trailer...............................................12 84 2.6 Example Messages......................................12 86 3. Signatures and Hashes..................................14 87 3.1 Digital Signatures....................................14 88 3.2 Hash Codes............................................14 90 4. Specific Message Formats...............................16 91 4.1 Persona Registration and Application Retrieval........16 92 4.1.1 R1 - registration...................................16 93 4.1.2 R2 - registration-response..........................17 94 4.1.3 GA1 - get-application...............................18 95 4.1.4 GA2 - get-application-response......................19 96 4.2 Binding Credit Cards..................................20 97 4.2.1 BC1 - bind-credit-card..............................20 98 4.2.2 BC4 - bind-credit-card-response.....................22 99 4.3 Customer Credit Card Purchasing Messages..............23 100 4.3.1 PR1 - payment-request...............................23 101 4.3.2 CH1 - credit-card-payment...........................25 102 4.3.3 CH2 - charge-card-response..........................26 103 4.4 Merchant Credit Card Purchasing Messages..............27 104 4.4.1 CM1 - auth-only.....................................28 105 4.4.2 CM2 - auth-capture..................................30 106 3.4.3 CM3 - post-auth-capture.............................30 107 4.4.4 CM4 - void..........................................32 108 4.4.5 CM5 - return........................................33 109 4.4.6 CM6 - charge-action-response........................34 110 4.4.7 The MM* Message Series..............................36 111 4.4.8 CD1 - card-data-request.............................36 112 4.4.9 CD2 - card-data-response............................38 113 4.5 Utility and Error Messges.............................39 114 4.5.1 P1 - ping...........................................40 115 4.5.2 P2 - ping-response..................................40 116 4.5.3 TQ1 - transaction-query.............................41 117 4.5.4 TQ2 - transaction-cancel............................42 118 4.5.5 TQ3 - transaction-response..........................43 119 4.5.6 UNK1 - unknown-error................................45 120 4.5.7 DL1 - diagnostic-log................................47 121 4.5.8 DL2 - merchant-diagnostic-log.......................48 122 4.6 Table of Messages Described...........................49 124 5. Future Development.....................................51 126 6. Security Considerations................................52 127 References................................................52 129 Authors Addresses.........................................53 130 Expiration and File Name..................................53 132 1. Overall System 134 CyberCash, Inc. of Reston, Virginia was founded in August of 1994 to 135 partner with financial institutions and providers of goods and 136 services to deliver a safe, convenient and inexpensive system for 137 making payments on the Internet. The CyberCash approach is based on 138 establishing a trusted link between the new world of cyberspace and 139 the traditional banking world. CyberCash serves as a conduit through 140 which payments can be transported quickly, easily and safely between 141 buyers, sellers and their banks. Significantly Q much as it is the 142 real world of commerce Q the buyer and seller need not have any prior 143 existing relationship. 145 As a neutral third party whose sole concern is ensuring the delivery 146 of payments from one party to another, CyberCash is the linchpin in 147 delivering spontaneous consumer electronic commerce on the Internet. 149 1.1 System Overview 151 The CyberCash system will provide several separate payment services 152 on the Internet including credit card and electronic cash. To gain 153 access to CyberCash services, consumers need only a personal computer 154 with a network connection. Similarly, merchants and banks need make 155 only minimal changes to their current operating procedures in order 156 to process CyberCash transactions, enabling them to more quickly 157 integrate safe on-line payments into their existing service 158 offerings. Communications with banks are over existing financial 159 communications networks. 161 To get started, consumers download free software from CyberCash on 162 the Internet. This software establishes the electronic link between 163 consumers, merchants and their banks as well as between individuals. 164 To make gaining access to the CyberCash system even easier, CyberCash 165 "PAY" buttons may be incorporated into popular on-line service and 166 software graphical user interfaces so that consumers using these 167 products can easily enter the CyberCash system when they are ready to 168 make payments for goods and services. Consumers need not have any 169 prior relationship with CyberCash to use the CyberCash system. They 170 can easily set up their CyberCash persona on-line. 172 Transactions are automated in that once the consumer enters 173 appropriate information into his own computer, no manual steps are 174 required to process authorization or settlement transactions through 175 the entire system. The consumer need only initiate payment for each 176 transaction by exercising the pay option on a CyberCash electronic 177 form. Transactions are safe in that they are cryptographicly 178 protected from tampering and modification by eavesdroppers. And they 179 are private in that information about the consumer not relevant to 180 the transaction is not visible to the merchant. 182 1.2 Security Approach 184 The CyberCash system pays special attention to security issues. It 185 uses encryption technology from the world's leading sources of 186 security technology and is committed over time to employing new 187 security technologies as they emerge. 189 1.2.1 Authentication and Persona Identity 191 Authentication of messages is based on Public Key encryption as 192 developed by RSA. The CyberCash Server maintains records of the 193 public key associated with every customer and merchant persona. It 194 is thus able to authenticate any information digitally signed by a 195 customer or merchant regardless of the path the data followed on its 196 way to the server. The corresponding private key, which is needed to 197 create such digital signatures, will be held by the customer or 198 merchant and never revealed to other parties. In customer software, 199 the private key is only stored in an encrypted form protected by a 200 passphrase. 202 While the true CyberCash identity of a customer or merchant is 203 determined by their public/private key pair, such keys are too 204 cumbersome (over 100 hex digits) to be remembered or typed by people. 205 So, the user interface utilizes short alphanumeric IDUs selected by 206 the user or merchant for purposes of specifying a persona. CyberCash 207 adds check digits to the requested ID to minimize the chance of 208 accidental wrong persona selection. Persona IDUs are essentially 209 public information. Possession of an persona ID without the 210 corresponding key is of no benefit in the current system. 212 Individuals or organizations may establish one or more CyberCash 213 customer personas directly with CyberCash. Thus, an individual may 214 have several unrelated CyberCash personas or share a CyberCash 215 persona with other individuals. This approach provides a degree of 216 privacy consistent with Internet presence generally and with cash 217 transactions specifically. However, persona holders who wish to use 218 a credit for purchases in conjunction with their CyberCash persona 219 must first meet such on-line identification criteria as the card 220 issuing organization requires. 222 Control over a CyberCash persona is normally available only to an 223 entity that possesses the private key for that persona. However, a 224 special provision is made to associate an emergency close out 225 passphrase with a CyberCash persona. On receipt of the emergency 226 close out passphrase, even if received over insecure channels such as 227 a telephone call or ordinary email, CyberCash will suspend activity 228 for the CyberCash persona. This emergency close-out passphrase can 229 be stored separately from and with somewhat less security than the 230 private key for the persona since the emergency passphrase can not be 231 used to divert funds to others. This provides some protection against 232 loss or misappropriation of the private key or the passphrase under 233 which the private key in kept encrypted. In the cash system, the 234 emergency close-out passpharase may also transfer the persona balance 235 to a designated bank account. 237 1.2.2 Privacy 239 Encryption of messages use the Digital Encryption Standard (DES), 240 commonly used in electronic payment systems today. Particularly 241 sensitive information, such as PIN numbers, will be superencrypted 242 (i.e., encrypted more than one level) and handled so that the plain 243 text readable version never exists in the CyberCash system except 244 momentarily, within special purpose secure cryptographic hardware 245 that is part of the server, before being re-encrypted under another 246 key. 248 The processing of card charges through the CyberCash system is 249 organized so that the merchant never learns the customerUs credit 250 card number unless the merchantUs bank chooses to release this 251 information to the merchant or it is required for dispute resolution. 252 In addition, the server maintains no permanent storage of card 253 numbers. They are only present while a transaction involving that 254 card is in progress. These practices greatly reduce the chance of 255 card number misappropriation. 257 1.3 Credit Card Operation 259 Using the CyberCash system for credit card transactions, once price 260 has been negotiated and the consumer is ready to purchase, the 261 consumer simply clicks on the CyberCash "PAY" button displayed on the 262 merchant interface, which invokes the merchant CyberCash software. 263 The merchant sends the consumer an on-line invoice that includes 264 relevant purchase information which appears on the customerUs screen. 265 (See PR1 message.) The consumer adds his credit card number and 266 other information by simple selecting from a list of credit cards he 267 has registered to his CyberCash persona. All this information is 268 digitally signed by the customer, encrypted, and passed, along with a 269 hash code of the invoice as seen by the customer, to the merchant. 270 (See CH1 message.) 271 Upon receipt, the merchant adds additional authorization information 272 which is then encrypted, electronically signed by the merchant, and 273 sent to the CyberCash Server. (See CM1 message.) The CyberCash 274 Server can authenticate all the signatures and be sure that the 275 customer and merchant agree on the invoice and charge amount. The 276 CyberCash Server then forwards the relevant information to the 277 acquiring bank along with a request on behalf of the merchant for a 278 specific banking operation such as charge authorization. The bank 279 decrypts and then processes the received data as it would normally 280 process a credit card transaction. The bankUs response is returned 281 to the CyberCash Server which returns an electronic receipt to the 282 merchant (see CM6 message) part of which the merchant is expected to 283 forward to the customer (see CH2 message). The transaction is 284 complete. 286 2. General Message Wrapper Format 288 Version 0.8 of the external format for the encoding of CyberCash 289 messages is described below. CyberCash messages are stylized 290 documents for the transmission of financial data over the Internet. 292 While there are numerous schemes for sending information over the 293 Internet (HTTP, SMTP, and others), each is attached to a specific 294 transmission mechanism. Because CyberCash messages will need to 295 travel over each of these media (as well as others) a transmission 296 independent mechanism is needed. 298 2.1 Message Format 300 CyberCash messages consist of the following components: 302 1. Header - defines the start of the CyberCash message and includes 303 version information. 305 2. Transparent Part - contains information that is not private. 307 3. Opaque Part - contains the financial information in the message 308 and is both privacy protected as well as tamper protected. The opaque 309 part is not present in some messages. When present, the opaque part 310 also provides tamper protection for the transparent part. 312 4. Trailer - defines the end of the CyberCash message and includes a 313 check value to enable the receiver to determine that the message has 314 arrived undamaged. Note: this check value is intended only to detect 315 accidental damage to the message, not deliberate tampering. 317 No null characters (zero value) or characters with the eighth bit on 318 are permitted inside a CyberCash message. "Binary" quantities that 319 might have such byte values in them are encoded in base64 as 320 described in RFC 1521. 322 2.1 Details of Format 324 The header consists of a single line which looks approximately like 325 this 327 $$-CyberCash-0.8-$$ 329 or like this 331 $$-CyberCash-1.2.3-Extra-$$ 333 It includes a number of fields separated with the minus character "-" 335 1. "$$" - the literal string with the initial $ in column 1. 337 2. "CyberCash" - the literal string (case insensitive) 339 3. x.y or x.y.z - the version number of the message format. 341 4. "Extra" - an optional additional alphanumeric string. 343 5. "$$" - the literal string 345 Version numbers start at 0.7 and count up. The ".z" is omitted when 346 z is zero. 0.7 and 0.8 are the test and initial shipped version of 347 the credit card system. 0.9 and 1.0 are expected to also incorporate 348 the test and initial shipped versions of the cash facilities as well 349 as improvements to the credit card system. 351 The Extra string is used within secure environments so that one 352 subcomponent can scribble a note to another with minimum overhead. 353 For example, a server firewall could put "HTTP" or "SMTP" here before 354 forwarding the message to the core server within the firewall 355 perimeter. 357 2.2 Body Parts 359 The body parts of the message (both transparent and opaque) consist 360 of attribute value pairs in formats that are reminiscent of the 361 standard electronic mail header (RFC822) format. However, there are 362 some differences. 364 Attribute names start with and are composed predominantly of letters 365 and internal hyphens except that they sometimes end with a hyphen 366 followed by a number. Such a trailing number is used when there is 367 logically an indexed vector of values. Attribute names are 368 frequently referred to as labels. 370 If the label ends with a ":", then RFC822 processing is done. While 371 the existence of trailing white space is significant, all leading 372 white space on continuation lines is stripped. Such lines are 373 wrapped at 64 characters in length, excluding any line termination 374 character(s). 376 However, if the label is terminated with a ";", this indicates a 377 free-form field where new-line characters and any leading white 378 space, after the initial space that indicates a continuation line, is 379 significant. Such lines should not be wrapped except that, to avoid 380 other processing problems, they are forcibly wrapped at 200 381 characters. 383 Blank lines are ignored and do not signify a change to a different 384 mode of line handling. 386 Another way of looking at the above is as follows: after having 387 found an initial $$ start line, you can treat any following lines 388 according to the first character. If it is alphanumeric, it is a new 389 label which should be terminated with a ":" or ";" and indicates a 390 new label-value pair. If it is a white space character, it indicates 391 the continuation of the value for the preceding new label line. 392 (Exactly how the continuation is processed depends on the label 393 termination character.) If it is "$", it should be the end line for 394 the message. If it is #, it is a comment line and should be ignored. 395 Other initial characters are undefined. (As of this date, no 396 software sends CyberCash messages with # lines but they are 397 convenient for commenting messages stored in files.) 399 2.3 Transparent Part 401 The transparent part includes any clear-text data associated with the 402 financial transaction as well as information needed by CyberCash and 403 others to decrypt the opaque parts. It always includes a transaction 404 field which is the transaction number generated by the requester and 405 is repeated in the response. It always includes a date field that is 406 the local date and time at the requester and is repeated in the 407 response. In all cases other than an initial registration to 408 establish a persona ID, it includes the requesters persona ID. 410 2.4 Opaque Part 412 The opaque part consists of a single block of characters encoded 413 using base64 encoding (see RFC 1521). The data in the opaque section 414 is always encrypted before encoding. 416 The label "opaque" or "merchant-opaque" precedes the opaque part. 418 On messages inbound to the server, the data to be opaqued is 419 encrypted under a random session key and then that DES key is RSA 420 encrypted under one of the server's public keys. The corresponding 421 outbound reply can simply be DES encrypted under this session key as 422 there is enough plain text information to identify the session and 423 the customer or merchant will have remembered the session key from 424 the inbound message. 426 2.5 Trailer 428 The trailer is intended to close the message and provide a definitive 429 and parseable end of the message. 431 The trailer consists of several fields separated by "-" as in header. 433 1. "$$" - literal string. 435 2. "CyberCash" - literal string (case insensitive). 437 3. "End" - literal string (case insensitive). 439 4. transmission checksum. 441 5. "$$" - literal string. 443 The transmission checksum is the MD5 has of all printable characters 444 in the version number in the start line and those appearing after the 445 second $$ of the start line and before the first $$ of the trailer 446 line as transmitted. Note that all white space is left out of this 447 hash, including any new-lines, spaces, tabs, carriage returns, etc. 448 The exact label terminators actually used (: or ;) are included as 449 would any # comment line. Note that the optional "Extra" string in 450 the $ start line is not included. The idea is to check correct 451 transmission while avoiding sensitivity to gateways or processing 452 that might change the line terminator sequence, convert tabs to 453 spaces, or the like. 455 2.6 Example Messages 457 Simple message from a client: 459 $$-CyberCash-0.8-$$ 460 id: DONALD-69 461 transaction: 918273645 462 date: 199512250102 463 opaque: 464 ABCEDSUDSAKJDSALKJSALKJSADLKASJASDJIIClaksdjiLADjlasdji34 465 DAJKASLKDJIWalkdlakdlakLAKsdalkjdlKaldjlakdakjakldskajlkj 466 adsjlsdkdlaskdjaksldjalksjdlsakdjlsakjdlkjskalkjalsdjlkjj 467 alkjda= 468 $$-End-CyberCash-End-jkn38fD3+/DFDF3434mn10==-$$ 469 Message from a merchant: 471 $$-CyberCash-a.b.c-extra-$$ 472 merchant-ccid: acme-69 473 merchant-date: 19951231115959 474 merchant-transaction: 987654321 475 label: value 477 labelx: multiple line 478 value... 479 # comment 480 # another comment line 481 label; text with a real 482 multi-line 483 format ! 484 merchant-opaque: ABCEDSUDSA+/KJDSALKJSALKJSADLKASJASDJIICla 485 DAJKASLKDJIWalkdlakdlakLAKsdalkjdlKaldjlakdakjakldskajlkj 486 adsjlsdkdlaskdjaksldjalksjdlsakdjlsakjdlkjskalkjalsdjlkjj 487 alkjda= 488 $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ 490 3. Signatures and Hashes 492 Inbound CyberCash request messages normally have a signature, as 493 described below, of all of the messages fields outside of the 494 signature. This signature is transmitted inside the opaque part of 495 the message. It enables the server to authenticate the source of the 496 message. 498 Messages from a merchant to a client initiating a purchase sequence 499 have fields signed by the merchant. These fields and this signature 500 are included by the client in the opaque part of their card purchase 501 message to the merchant so that, when all is passed on to the server, 502 it can verify that the client saw the information the merchant 503 intended. 505 More information on CyberCash signatures and the hash codes they are 506 based on, is given below. 508 3.1 Digital Signatures 510 Digital signatures are a means of authenticating information. In 511 CyberCash messages, they are calculated by first taking the hash of 512 the data to be authenticated, as described below, and then encoding 513 the hash using an RSA private key. 515 Anyone possessing the corresponding public key can then decrypt the 516 hash and compare it with the message hash. If they match, then you 517 can be sure that the signature was generated by someone possessing 518 the private key which corresponded with the public key you used and 519 that the message was not tampered with. 521 In the CyberCash system, clients, merchants, and the server have 522 public-private key pairs. By keeping the private key secret and 523 registering their public key with the server (for a merchant or 524 client) or publishing their public key or keys (for the server), they 525 can provide high quality authentication by signing parts of messages. 527 An RSA digital signature is approximately the size of the modulus 528 used. For example, if that is 768 bits long, then the binary digital 529 signature would be 768 bits or 96 bytes long and its base 64 encoding 530 would be 128 bytes. 532 3.2 Hash Codes 534 The hashes used in CyberCash messages are message digests. That is, 535 a non-invertable fingerprint of a message such that it is 536 computationally infeasible to find an alternate message with the same 537 hash. Thus the relatively small hash can be used to secure a larger 538 message. If you are confident in the authenticity of the hash and 539 are presented with a message which matches the hash, you can be sure 540 it is the original message, at least as regards all aspects that have 541 been included in the hash. 543 The hash is calculated using the MD5 algorithm (see RFC 1321) on a 544 synthetic message. The synthetic message is composed of the labels 545 and values specified in a list for the particular hash. Since the 546 hash is input order dependent, it is essential that the label-value 547 pairs be assembled in the order specified. In some cases, a range of 548 matching labels is specified. For example, Rcard*S to match card- 549 number, card-expiration-date, and all other labels starting with 550 RcardS. In such cases, all existing matching labels are used in 551 ascending alphabetic order by ASCII character code. 553 If a label is specified in a signature list but is not present in the 554 label-value data on which the hash is being calculated, it is not 555 included in the hash at all. That is, even the label and label 556 terminator are omitted from the synthetic message. 558 Before being hashed, the text of the synthetic message is processed 559 to remove all Rwhite spaceS characters. White space characters are 560 defined as any with an ASCII value of 32 (space) or less. Thus all 561 forms of new-line/carriage-return and distinctions such as blank 562 lines, trailing spaces, replacement of a horizontal tab character by 563 multiple spaces, etc., are ignored for hash purposes. 565 MD5 hashes are 16 bytes long. This means that the base 64 encoding 566 of such a hash will be 24 characters (of which the last two will 567 always be padding equal signs). 569 4. Specific Message Formats 571 This section describes the formats of the Verison 0.8 CyberCash 572 messages by example with comments. The reader in assumed to be 573 familiar with terms such as "acquirer", "PAN" (primary account 574 number), etc., defined in ISO 8583, and currency designations as 575 defined in ISO 4217. A few fields not relevant to current operations 576 have been removed to simplify this exposition. 578 In the following example messages, signatures, hashes, and encrypted 579 sections are fake nonsense text and ids are fictitious. 581 4.1 Persona Registration and Application Retrieval 583 The first step in customer use of CyberCash is registering a persona 584 using the customer application. This is done with the R1 message 585 defined below. The CyberCash server responds with the R2 message. 587 When the customer application learns that it is out of date, it can 588 use the GA1 request message to the server and its GA2 response to 589 download a new signed version of itself. 591 4.1.1 R1 - registration 593 Description: This is the initial message sent to create a new 594 CyberCash persona. 596 ##################################################################### 597 Sender: CyberApp 598 Receiver: CyberServer 599 ##################################################################### 600 Sample Message: 602 $$-CyberCash-0.8-$$ 603 transaction: 123123213 604 date: 19950121100505.nnn 605 cyberkey: CC1001 606 opaque: 607 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 608 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 609 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 610 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7n4 611 3ard3Q== 612 $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ 614 ##################################################################### 615 Opaque Key: Generated using CyberCash encrypting public key 616 identified in CyberKey. 618 ##################################################################### 619 Opaque Section Contents: 621 type: registration 622 swversion: 0.8win 623 content-language: en-us 624 requested-id: MyRequestedCCID 625 email: myemail@myemailhost.com 626 pubkey: aslfjflasdflasj;lfdjsl;afkjfjslakjf;ldskaj;flkajs;ldfjlaskf 627 aslfjflasdflasj;lfdjsl;afkjfjslakjf == 628 signature: alsdjflsajflksjdlkfjlsakjflkdsajflksjfjslakjf;ldskaj;jfj 629 slakjf;ldskaj;djlfasd=== 631 ##################################################################### 632 signature is of the following fields: transaction, date, cyberkey, 633 type, swversion, content-language, requested-id, email, pubkey 635 ##################################################################### 636 Explanation: 637 content-language is taken from the MIME header field. (see RFC1766) 638 and is the language text messages should be generated in. (only 639 en-us implemented at this time. 640 swversion used to check if client application is old. 642 4.1.2 R2 - registration-response 644 Description: This message gives the success/failure response to R1. 646 ##################################################################### 647 Sender: CyberServer 648 Receiver: CyberApp 649 ##################################################################### 650 Sample Message: 652 $$-CyberCash-0.8-$$ 653 transaction: 12312313 654 date: 19950121100505.nnn 655 opaque: 656 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 657 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 658 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 659 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 660 3ard3Q== 661 $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ 662 ##################################################################### 663 Opaque Key: Same as session key for R1 for same Transaction and 664 connection (there may be no ID!). 666 ##################################################################### 667 Opaque Section Contents: 669 type: registration-response 670 server-date: 19950121100506.nnn 671 requested-id: MyRequestedCCID 672 response-id: CyberCashHandle 673 email: myemail@myemailhost.com 674 response-code: success/failure/etc. 675 pubkey: aslfjflasdflasj;lfdjsl;afkj;ldkfjslakjf;ldskslakjf;ldskslakjf; 676 ldskslakjf;ldskslakjf;ldskaj;flkajs;ldfjlaskf== 677 swseverity: fatal/warning [absent if ok] 678 swmessage; Tells CyberApp that it is obsolete. Display this 679 text to the user. [only present if SWSeverity present] 680 message; 681 Free text of the error/success condition. 682 This text is to be displayed to the person 683 by the CyberCash application... 685 In general this includes: duplicate-id, bad-signature, 686 or ill-formed-registration 688 ##################################################################### 689 Signature is of the following fields: no-signature 691 ##################################################################### 692 Explanation: 693 responseid is used to suggest a unique ID if the failure was due 694 to the requested ID being already in use... If the reason for 695 failure was not due to duplicate ID then this field may be 696 omitted. 697 responseid gives the actual ID with check characters appended if 698 success. 699 swseverity can warn user of old client application or indicate 700 failure due to old or known buggy version. 702 4.1.3 GA1 - get-application 704 Description: Used by CyberApp to get an updated version. 706 ##################################################################### 707 Sender: CyberApp 708 Receiver: CyberServer 709 ##################################################################### 710 Sample Message: 712 $$-CyberCash-0.8-$$ 713 transaction: 123123213 714 date: 19950121100505.nnn 715 cyberkey: CC1001 716 opaque: 717 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 718 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 719 3ard3Q== 720 $$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$ 722 ##################################################################### 723 Opaque Key: Generated using CyberCash encrypting public key identified 724 in CyberKey. 726 ##################################################################### 727 Opaque Section Contents: 729 type: get-application 730 swversion: 0.8win 732 ##################################################################### 733 Signature is of the following fields: no signature 735 ##################################################################### 736 Explanation: 737 There may not be a customer persona so there is no ID. There 738 may not be a customer public/private key pair so there is 739 no signature. The swversion is mandatory so the server can 740 tell what to return. 742 4.1.4 GA2 - get-application-response 744 Description: Return success and URL of up to date copy of CyberApp 745 or failure. 747 ##################################################################### 748 Sender: CyberServer 749 Receiver: CyberApp 750 ##################################################################### 751 Sample Message: 753 $$-CyberCash-0.8-$$ 754 transaction: 12312313 755 date: 19950110102333.nnn 756 opaque: 757 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 758 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 759 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 760 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 761 3ard3Q== 762 $$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$ 764 ##################################################################### 765 Opaque Key: session key from GA1 767 ##################################################################### 768 Opaque Section Contents: 770 type: get-application-response 771 server-date: 19950110102334.nnn 772 response-code: success/failure/etc. 773 message; Text message to be displayed to the user providing more 774 information on the success/failure. 775 swversion: 0.8win 776 application-url: http://foo.cybercash.com/server/0.8WIN.EXE 777 application-hash: lSLzs/vFQ0BXfU98LZNWhQ== 779 ##################################################################### 780 Signature: none. 782 ##################################################################### 783 Explanation: 784 application-hash is the MD5 of the binary of the application. 785 application-url & application-hash omitted on failure. 786 swversion is the version being transmitted to the customer. 788 4.2 Binding Credit Cards 790 The CyberCash system is design to give the card issuing organization 791 control over whether a card may be used via the CyberCash system. 792 The customer, after having registered a persona with CyberCash as 793 described above, must then bind each credit card they wish to use to 794 their CyberCash persona. This is done via the BC1 message from the 795 customer to their CyberCash server and the BC4 response from the 796 server. 798 4.2.1 BC1 - bind-credit-card 800 Description: This is the initial message in the process of binding a 801 credit card to a CyberCash persona. 803 ##################################################################### 804 Sender: CyberApp 805 Receiver: CyberServer 806 ##################################################################### 807 Sample Message: 809 $$-CyberCash-0.8-$$ 810 id: MyCyberCashID 811 date: 19950121100505.nnn 812 transaction: 12312314 813 cyberkey: CC1001 814 opaque: 815 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 816 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 817 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 818 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 819 3ard3Q== 820 $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ 822 ##################################################################### 823 Opaque Key: generated from CyberCash encryption key identified in 824 CyberKey 826 ##################################################################### 827 Opaque Section Contents: 829 type: bind-credit-card 830 swversion: 0.8win 831 card-number: 1234567887654321 832 card-type: mastercard 833 card-salt: 46735210 834 card-expiration-date: 05/99 835 card-name: John Q. Public 836 card-street: 837 card-city: 838 card-state: 839 card-postal-code: 840 card-country: 841 signature: sjadlkasl;f;lksaj;lfjs;lfjsldfjl;lfjs;lfjsldfjl;lfjs;lfjsl 842 ;lfjs;lfjsldfjl;lfjs;lfjsldfjlskflsajfsa== 844 ##################################################################### 845 signature is of the following fields: id, date, transaction, 846 cyberkey, type, swversion, card-number, card-salt, 847 card-expiration-date, card-name, card-street, card-city, 848 card-state, card-postal-code, card-country 850 ##################################################################### 851 Explanation: 852 salt is needed so that the hash stored at the server is less 853 informative. Server just remembers the "prefix" of the card 854 number and the hash of the combined card number and salt. If it 855 just hashed the card number, it would be recoverable with modest 856 effort by trying to hash all plausible numbers. We don't want 857 to store the card numbers on the server because it would make 858 the server files too valuable to bad guys. 860 4.2.2 BC4 - bind-credit-card-response 862 Description: Indicates that the process of binding a credit card 863 terminated. Returns success or failure. 865 ##################################################################### 866 Sender: CyberServer 867 Receiver: CyberApp 868 ##################################################################### 869 Sample Message: 871 $$-CyberCash-0.8-$$ 872 id: mycybercashid 873 transaction: 12312314 874 date: 19950121100505.nnn 875 opaque: 876 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 877 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 878 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 879 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 880 3ard3Q== 881 $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ 883 ##################################################################### 884 Opaque Key: Session key from BC1 with same Transaction and ID 886 ##################################################################### 887 Opaque Section Contents: 889 type: bind-credit-card-response 890 server-date: 19950121100506.nnn 891 swseverity: fatal/warning [absent if ok] 892 swmessage; message about obsoleteness of customer software 893 to be shown to the customer. [only present if SWSeverity present] 894 response-code: success/failure/etc. 895 card-number: 1234567887654321 896 card-type: visa 897 card-salt: 47562310 898 card-expiration-date: 01/99 899 card*: [other card* lines to also be given in CH.1 message] 900 message; Plain text for the user 901 can be multiple lines 903 ##################################################################### 904 Signature is of the following fields: no-signature 906 ##################################################################### 907 Explanation: All the card* lines can be saved as a blob to be 908 submitted in CH.1. card-expiration-date, card-number, card-salt, 909 and card-type should always be present. 910 Depending on reason for failure, not all fields may be present. 912 4.3 Customer Credit Card Purchasing Messages 914 In general, CyberCash involvement in the credit card purchasing cycle 915 starts after the user has determined what they are buying. When they 916 click on the CyberCash payment button, a PR1 message is sent by the 917 merchant to the customer as the body of a message of MIME type 918 application/cybercash. 920 If the customer wishes to proceed, they respond to the merchant with 921 a CH1. The merchant responds with a CH2 but between the receipt of 922 the CH1 and issuance of the CH2, the merchant usually communicates 923 with the CyberCash server via the CM* messages. 925 4.3.1 PR1 - payment-request 927 Description: This message is the first message that is defined 928 by CyberCash in the purchase from a merchant process. The 929 shopping has completed. Now we are at the point of paying 930 for the purchases. 932 ##################################################################### 933 Sender: MerchantApp 934 Receiver: CyberApp 935 ##################################################################### 936 Sample Message: 938 $$-CyberCash-0.8-$$ 939 type: payment-request 940 merchant-ccid: ACME-012 941 merchant-order-id: 1231-3424-234242 942 merchant-date: 19950121100505.nnn 943 note; 944 ACME Products 946 Purchase of 4 pairs "Rocket Shoes" at $39.95 ea. 948 Shipping and handling $5.00 950 Total Price: 164.80 952 Ship to: 953 Wily Coyote 954 1234 South St. 955 Somewhere, VA 12345 956 merchant-amount: usd 164.80 957 accepts: visa:CC001, master:CC001,amex:CC001,JCPenny:VK005,macy:VK006 958 url-pay-to: http://www.ACME.com/CybercashPayment 959 url-cancel: http://www.ACME.com/CyberPaymentCancel 960 url-success: http://www.ACME.com/ordersuccess 961 url-fail: http://www.ACME.com/orderfail 962 merchant-signed-hash: asfkjslkjflskdfjwerwerwrlkwfjwerwerwrlkwfjwerwer 963 rwerwrlkwjrlkjwlejrjwelrkwk= 964 $$-CyberCash-End-lSLzs/vFQ0BXfU98LZNWhQ==-$$ 966 ##################################################################### 967 Opaque Key: no opaque section 969 ##################################################################### 970 Opaque Section Contents: no opaque section 972 ##################################################################### 973 merchant-signed-hash is the signature under the merchant's 974 private key of the hash of the following fields: type, 975 merchant-ccid, merchant-order-id, date, note, merchant-amount, 976 accepts, url-pay-to, url-cancel, url-success, url-fail 978 ##################################################################### 979 Explanation: 980 This message is signed by the merchant but the customer cannot 981 directly verify this signature. When the payment is made, the 982 Customer includes the signature with the hash (derived by the 983 customer directly) in the payment. If these do not match, the 984 CyberCash will not perform the payment function. 985 accepts: The client software will only recognized single word card 986 name in the accepts field of PR1. For example, 987 MasterCard 988 AmericanExpress 989 are recognized where as 990 Master card 991 American express 992 are not recognized. MasterCard and masterCard are both 993 recognized as master card. 994 Card type followed by key designator. For main line credit cards, 995 this will be a CC*. Client can use or ignore the * number as 996 it chooses. For proprietary card, this will be VK* where * is 997 the CheckFree key to use (1 based). Cards separated by comma, 998 key designator follows card type and colon. 1000 4.3.2 CH1 - credit-card-payment 1002 Description: This message represents the presentation of a "credit 1003 card for payment". 1005 ##################################################################### 1006 Sender: CyberApp 1007 Receiver: MerchantApp 1008 ##################################################################### 1009 Sample Message: 1011 $$-CyberCash-0.8-$$ 1012 type: card-payment 1013 id: myCyberCashID 1014 order-id: 1231-3424-234242 1015 merchant-ccid: ACME-012 1016 transaction: 78784567 1017 date: 19950121100505.nnn 1018 pr-hash: kjdsalfjlejelkjeljwlkjerljweklkjerljweklkjerljweklkjerljwekl 1019 jerljwekrlwekrjlwekjfwe== 1020 pr-signed-hash: sfljlkjflkjseljljljkjseljljljkjseljljljkjseljljljkjse 1021 jljkjseljljljwlkjrwlejrlwkjlerkjwelr= 1022 cyberkey: CC1001 1023 opaque: 1024 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1025 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1026 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1027 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1028 3ard3Q== 1029 $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1031 ##################################################################### 1032 Opaque Key: Created using CyberCash encrypting public key in 1033 CyberKey. 1035 ##################################################################### 1036 Opaque Section Contents: 1038 swversion: 0.8win 1039 amount: usd 10.00 1040 card*: [from successful BC4 (includes card-expiration-date, 1041 card-number, card-type, and card-salt)] 1042 signature: dfdsfffffsfdZydMAGVasdflkkjasdflkkjasfdlkjasdflkajsdlfkjas 1043 fjaAqbat2d6hlC/mSw== 1045 ##################################################################### 1046 signature is under client private key of the following fields: 1047 type, id, order-id, merchant-ccid, transaction, date, 1048 pr-hash, pr-signed-hash, cyberkey, swversion, amount, 1049 card* 1051 4.3.3 CH2 - charge-card-response 1053 Description: Return to customer from a CH1 attempt to pay via credit 1054 card. Indicates success/failure. 1056 ##################################################################### 1057 Sender: MerchantApp 1058 Receiver: CyberApp 1059 ##################################################################### 1060 Sample Message: 1062 $$-CyberCash-0.8-$$ 1063 type: charge-card-response 1064 merchant-ccid: ACME-012 1065 id: myCyberCashID 1066 transaction: 78784567 1067 date: 1995121100500.nnn 1068 merchant-date: 19950121100505.nnn 1069 merchant-response-code: failure/success/etc. 1070 pr-hash: 7Tm/djB05pLIw3JAyy5E7A== 1071 pr-signed-hash: sfljlkjflkjseljljljkjseljljljkjseljljljkjseljljljkjse 1072 jljkjseljljljwlkjrwlejrlwkjlerkjwelr= 1073 merchant-message; This is a message to display to the user from the 1074 merchant. Can be multiple lines... Is not secure. 1075 opaque: [might not be present, see explanation] 1076 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1077 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1078 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1079 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1080 3ard3Q== 1081 $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1083 ##################################################################### 1084 Opaque Key: Same customer session key from CH1 passed through CM1 1085 for ID and Transaction 1087 ##################################################################### 1088 Opaque Section Contents (from CM.6): 1090 server-date: 19950121100706.nnn 1091 amount: usd 10.00 1092 order-id: 1231-3424-234242 1093 card*: [from successful BC4] 1094 response-code: failure/success/etc. 1095 swseverity: fatal/warning 1096 swmessage; Tells CyberApp that it is obsolete. Display this 1097 text to the user. [only present if SWSeverity present] 1098 message; 1099 Free text of the error/success condition. 1100 This text is to be displayed to the customer 1101 by the CyberCash application... 1103 ##################################################################### 1104 Signature is of the following fields: no signature 1106 ##################################################################### 1107 Explanation: 1108 Opaque section optional because the CH1 to the merchant can fail due 1109 to bad order-id, date, wrong merchant-ccid, etc., etc. So the 1110 server may not be involved at all in which case there is no 1111 mechanism for generating a secure opaque section. (It could even 1112 be that merchant attempt to contact the server times out.) 1113 If transaction makes it through server (via CM*) then 1114 Response-Code at top level should mirror response-code to 1115 merchant from server. (Hopefully the same as the 1116 response-code to customer from server but the merchant can't 1117 tell that.) 1118 Note that there can be two messages, one from merchant and one 1119 from the server. 1121 4.4 Merchant Credit Card Purchasing Messages 1123 The merchant presents credit card purchases, makes adjustments, and 1124 the like via the CM* series. In general, the credit card cycle is 1125 one of getting authorization for a purchase, then capturing the 1126 purchase in a batch for settlement, then performing the settlement. 1127 It is also possible to void a capture (i.e., remove an item from a 1128 batch), and process credits (returns). 1130 Authorizations always come from an acquirer via a CM1 or CM2 message. 1131 If capture is being performed by the acquirer or some entity between 1132 the CyberCash server and the acquirer, this is done via a CM3 or CM2 1133 message depending on the arrangement between the merchant and the 1134 entity doing the capture. Returns (credits) are handled via message 1135 CM5. Message CM4 is provided for voiding a capture or return before 1136 the batch is settled. CM6 is the message format used for responses 1137 to all the other CM* messages. 1139 An MM* series has also been implemented for purely merchant 1140 originated CyberCash charges as described in section 3.4.7 1141 Current credit card dispute resolution systems assume that the 1142 merchant knows the card number. Thus, to work with these systems, 1143 special bypass messages have been set up that allow the merchant to 1144 obtain, for a particular transaction, the information that CyberCash 1145 otherwise goes to lengths to hide from the merchant. See sections 1146 3.4.8 and 3.4.9. 1148 Many present day merchants operate in a "terminal capture" mode where 1149 the authorizations are captured by the merchant and the merchant 1150 submits the settlement batch. Messages have been defined and are 1151 being implemented so that such merchant captured batches can be 1152 submitted via CyberCash. 1154 4.4.1 CM1 - auth-only 1156 Description: This message is used by the merchant to perform an 1157 authorization operation on the credit card sent in by the 1158 customer. 1160 ##################################################################### 1161 Sender: MerchantApp 1162 Receiver: CyberServer 1163 ##################################################################### 1164 Sample Message: 1166 $$-CyberCash-0.8-$$ 1167 merchant-ccid: ACME-69 1168 merchant-transaction: 123123 1169 merchant-date: 19950121100705.nnn 1170 merchant-cyberkey: CC1001 1171 cyberkey: CC1001 1172 opaque: 1173 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1174 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1175 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1176 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1177 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1178 3ard3Q== 1179 merchant-opaque: 1180 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1181 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1182 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1183 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1184 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1185 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1186 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1187 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1188 3ard3Q== 1190 $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1192 ##################################################################### 1193 Merchant-Opaque Section Contents: 1195 type: auth-only 1196 order-id: 12313424234242 1197 merchant-amount: usd 10.00 1198 pr-hash: 7Tm/djB05pLIw3JAyy5E7A== 1199 pr-signed-hash: 1200 sfljlkjflkjseljljljwlkjrweljljljwlkjrweljljljwlkjrweljljlj 1201 kjrweljljljwlkjrwlejrlwkjlerkjwelr= 1202 id: myCyberCashID 1203 transaction: 78784567 1204 date: 19950121100505.nnn 1205 merchant-signature: lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjfl+w 1206 flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf= 1208 ##################################################################### 1209 merchant-opaque key is generated from the CyberCash encrypting public 1210 key identified in merchant-cyberkey. 1212 Customer opaque section (Opaque) - see CH1. 1214 ##################################################################### 1215 Opaque Section Contents & Signature: (exactly as in CH1) 1217 swversion: 0.8win 1218 amount: usd 10.00 1219 card*: [from successful BC4 (includes card-expiration-date, 1220 card-number, and card-salt)] 1221 signature: dfdsfffffsfdZydMAGVasdflkkjasdflkkjasfdlkjasdflkajsdlfkjas 1222 fjaAqbat2d6hlC/mSw== 1224 ##################################################################### 1225 merchant-signature is on the following fields: merchant-ccid, 1226 merchant-transaction, merchant-date, merchant-cyberkey, type, 1227 order-id, merchant-amount, pr-hash, pr-signed-hash, id, 1228 transaction, date, cyberkey 1230 Customer Signature: see CH1 1232 ##################################################################### 1233 Explanation: 1234 The merchant signature ensures integrity of the majority of the 1235 message. validation of the customer signature ensures that the 1236 customer opaque part was not tampered or replaced. 1238 4.4.2 CM2 - auth-capture 1240 Description: Do authorization and actually enters charge for 1241 settlement. Message just like CM1 except for different 1242 type. 1244 ##################################################################### 1245 Sender: MerchantApp 1246 Receiver: CyberServer 1247 ##################################################################### 1248 Sample Message: 1250 [exactly the same as CM1 except 1252 type: auth-capture 1254 ] 1256 3.4.3 CM3 - post-auth-capture 1258 Description: Captures a charge previously authorized. Message is 1259 the same as CM1 except that it also has an authorization-code 1260 field (which is also included in the signature) and the type 1261 is different. 1263 ##################################################################### 1264 Sender: MerchantApp 1265 Receiver: CyberServer 1266 ##################################################################### 1267 Sample Message: 1269 $$-CyberCash-0.8-$$ 1270 merchant-ccid: ACME-012 1271 merchant-transaction: 123123 1272 merchant-date: 19950121100705.nnn 1273 merchant-cyberkey: CC1001 1274 cyberkey: CC1001 1275 opaque: 1276 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ube 1277 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1278 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1279 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1280 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1281 3ard3Q== 1282 merchant-opaque: 1283 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1284 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1285 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1286 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1287 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1288 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1289 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1290 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1291 3ard3Q== 1292 $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1294 ##################################################################### 1295 Merchant-Opaque Section Contents: 1297 type: post-auth-capture 1298 authorization-code: a12323 1299 order-id: 1231-3424-234242 1300 merchant-amount: usd 10.00 1301 pr-hash: 7Tm/djB05pLIw3JAyy5E7A== 1302 pr-signed-hash: sfljlkjflkjseljljljwlkjrweljljljwlkjrweljljljwlkjrwe 1303 kjrweljljljwlkjrwlejrlwkjlerkjwelr= 1304 id: myCyberCashID 1305 transaction: 78784567 1306 date: 19950121100505.nnn 1307 merchant-signature: lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjflkj 1308 flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf= 1310 ##################################################################### 1311 merchant-opaque key is generated from the CyberCash encrypting public 1312 key identified in merchant-cyberkey. 1314 Customer opaque section (Opaque) - see CH1. 1316 ##################################################################### 1317 Opaque Section Contents & Signature: (exactly as in CH1) 1319 swversion: 0.8win 1320 amount: usd 10.00 1321 card*: [from successful BC4 (includes card-salt, card-number, 1322 and card-expiration)] 1323 signature: dfdsfffffsfdZydMAGVasdflkkjasdflkkjasfdlkjasdflkajsdlfkjas 1324 fjaAqbat2d6hlC/mSw== 1326 ##################################################################### 1327 merchant-signature is on the following fields: merchant-ccid, 1328 merchant-transaction, merchant-date, merchant-cyberkey, type, 1329 authorization-code, order-id, merchant-amount, pr-hash, 1330 pr-signed-hash, id, transaction, date, cyberkey 1332 ##################################################################### 1333 Explanation: 1334 The merchant signature ensures integrity of the majority of the 1335 message validation of the customer signature ensures that the 1336 customer opaque part was not tampered or replaced. 1338 4.4.4 CM4 - void 1340 Description: Voids out a charge/return if received before 1341 settlement. Message is the same as CM1 except that it also has 1342 a retrieval-reference-number field (which is also included in the 1343 signature) and the type is different. 1345 ##################################################################### 1346 Sender: MerchantApp 1347 Receiver: CyberServer 1348 ##################################################################### 1349 Sample Message: 1351 $$-CyberCash-0.8-$$ 1352 merchant-ccid: ACME-012 1353 merchant-transaction: 123123 1354 merchant-date: 19950121100705.nnn 1355 merchant-cyberkey: CC1001 1356 cyberkey: CC1001 1357 opaque: 1358 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1359 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff4 1360 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1361 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1362 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1363 3ard3Q== 1364 merchant-opaque: 1365 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1366 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1367 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1368 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1369 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1370 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1371 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1372 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1373 3ard3Q== 1374 $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1376 ##################################################################### 1377 Merchant-Opaque Section Contents: 1379 type: void 1380 retrieval-reference-number: 432112344321 1381 order-id: 1231-3424-234242 1382 merchant-amount: usd 10.00 1383 pr-hash: 1385 kjdsalfjlejelkjeljwlkjerljwwlkjerljwwlkjerljwwlkjerljwwlkjerljwwl 1386 kjerljwwlkjerljwekrlwekrjlwekjfwe== 1387 pr-signed-hash: 1388 sfljlkjflkjseljljljwlkjrweljljljwlkjrweljljljwlkjrweljljljwl 1389 kjrweljljljwlkjrwlejrlwkjlerkjwelr= 1390 id: myCyberCashID 1391 transaction: 78784567 1392 date: 19950121100505.nnn 1393 Merchant-Signature: lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjflkj 1394 flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf= 1396 ##################################################################### 1397 Merchant-Opaque key is generated from the CyberCash encrypting public 1398 key identified in Merchant-CyberKey. 1400 Customer opaque section (Opaque) - see CH1. 1402 ##################################################################### 1403 Opaque Section Contents & Signature: (exactly as in CH1) 1405 swversion: 0.8win 1406 amount: usd 10.00 1407 card*: [from successful bc4 (includes card-salt, card-number, 1408 and card-expiration)] 1409 signature: dfdsfffffsfdZydMAGVasdflkkjasdflkkjasfdlkjasdflkajsdlfkjas 1410 fjaAqbat2d6hlC/mSw== 1412 ##################################################################### 1413 merchant-signature is on the following fields: merchant-ccid, 1414 merchant-transaction, merchant-date, merchant-cyberkey, type, 1415 retrieval-reference-number, order-id, merchant-amount, pr-hash, 1416 pr-signed-hash, id, transaction, date, cyberkey 1418 ##################################################################### 1419 Explanation: 1420 The merchant signature ensures integrity of the majority of the 1421 message. Validation of the customer signature ensures that the 1422 customer opaque part was not tampered or replaced. 1424 4.4.5 CM5 - return 1426 Description: Reverse a previous charge. Really sort of a negative 1427 charge. Message just like CM1 except for different type. 1429 ##################################################################### 1430 Sender: MerchantApp 1431 Receiver: CyberServer 1432 ##################################################################### 1433 Sample Message: 1435 [exactly the same as CM1 except 1437 type: return 1439 ] 1441 4.4.6 CM6 - charge-action-response 1443 Description: This receipt is given to the merchant as a receipt 1444 for a completed charge action. Indicates success/failure/etc. 1446 ##################################################################### 1447 Sender: CyberServer 1448 Receiver: MerchantApp 1449 ##################################################################### 1450 Sample Message: 1452 $$-CyberCash-0.8-$$ 1453 merchant-ccid: ACME-012 1454 merchant-transaction: 123123 1455 merchant-date: 19950121100705.nnn 1456 merchant-opaque: 1457 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1458 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1459 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1460 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1461 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1462 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1463 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1464 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1465 3ard3Q== 1466 opaque: 1467 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1468 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1469 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1470 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1471 3ard3Q== 1472 $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1474 ##################################################################### 1475 Merchant-Opaque Key: Session key same as that of CM1/2/3/4/5 for 1476 same Merchant-Transaction and Merchant-CCID. 1478 Opaque Key: Same customer session key from CH1 passed through CM* 1479 for ID and Transaction 1481 ##################################################################### 1482 Merchant-Opaque Section Contents: 1484 type: charge-action-response 1485 server-date: 19950121100706.nnn 1486 action-code: XXX [per ISO 8583] 1487 response-code: failure/success/etc. 1488 order-id: 1231-3424-234242 1489 pr-hash: 7Tm/djB05pLIw3JAyy5E7A== 1490 pr-signed-hash: sfljlkjflkjseljljllkjseljljllkjseljljllkjseljljllkjse 1491 ljljwlkjrwlejrlwkjlerkjwelr= 1492 retrieval-reference-number: 432112344321 1493 authorization-code: a12323 1494 card-hash: 7Tm/djB05pLIw3JAyy5E7A== 1495 { 1496 card-prefix: nnxxxx [Returned if merchant is not full-PAN] 1497 } 1498 or 1499 { 1500 card-number: 1234567890123456 [Returned if merchant is full-PAN] 1501 } 1502 expiration-date: 12/34 [always present] 1503 merchant-swseverity: fatal/warning 1504 merchant-swmessage; Message for merchant about out of date 1505 protocol number in $$ start line of merchant message. 1506 merchant-message; 1507 Free text of the error/success condition. 1508 This text is for the merchant from the server... 1509 id: myCyberCashID 1510 transaction: 78784567 1511 date: 19950121100505.nnn 1513 Opaque (Customer) contents: 1515 server-date: 19950121100706.nnn 1516 amount: usd 10.00 1517 order-id: 1231-3424-234242 1518 card*: [from successful BC4] 1519 response-code: failure/success/etc. 1520 swseverity: fatal/warning 1521 swmessage; Tells CyberApp that it is obsolete display this 1522 text to the user. [only present if SWSeverity present] 1523 message; 1524 Free text of the error/success condition. 1525 This text is to be displayed to the customer 1526 by the CyberCash application... 1528 ##################################################################### 1529 Signature is of the following fields: no signature 1530 ##################################################################### 1531 Explanation: 1532 retrieval-reference-number is needed for voids. authorization-code 1533 is needed for post-auth-capture. These fields are each only 1534 present in the CM6 if they were returned by the bank which 1535 depends on what operation was being done. 1536 card-prefix is first two and last four digits of card-number. 1537 At bank's discretion the card-number or card-prefix is 1538 returned. 1539 card-hash is really the hash of the full card number and the salt 1540 provided by the customer. card-hash is needed so the merchant 1541 can, if they wish, sort customer transactions by card without 1542 knowing the card number. 1543 card* is th card* fields delivered in the CM* messages being 1544 responded to. They appear in alphabetic order. 1545 server-date duplicated in customer opaque area for security. 1546 {}'s in column one just for clarity of alternatives and do not 1547 actually appear in the message. 1548 []ed comments appear after some fields. 1550 4.4.7 The MM* Message Series 1552 The CM* message series above is the primary CyberCash credit card 1553 purchase system for securely handing charges from CyberCash 1554 customers. However, merchants, who are authorized by their acquiring 1555 bank to accept such charges, may also receive telephone, mail, and 1556 over the counter sales. To avoid any necessity for the merchant to 1557 have a second parallel system to handle these charges, an MM1 through 1558 MM6 message series is defined and has been implemented for these less 1559 secure transactions. 1561 The MM* messages look very similar to the CM* series but the 1562 "customer opaque" section is actually signed by the merchant and no 1563 separate customer CyberCash ID or prior card binding is required. 1565 4.4.8 CD1 - card-data-request 1567 Description: Used by merchant to get card-number, etc., if 1568 information needed by merchant to resolve a dispute. 1570 ##################################################################### 1571 Sender: MerchantApp 1572 Receiver: CyberServer 1573 ##################################################################### 1574 Sample Message: 1576 $$-CyberCash-0.8-$$ 1577 merchant-ccid: ACME-69 1578 merchant-transaction: 123123 1579 merchant-date: 19950121100705.nnn 1580 merchant-cyberkey: CC1001 1581 cyberkey: CC1001 1582 opaque: 1583 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1584 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1585 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1586 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1587 3ard3Q== 1588 merchant-opaque: 1589 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1590 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1591 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1592 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1593 3ard3Q== 1594 $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1596 ##################################################################### 1597 Merchant-Opaque Section Contents: 1599 type: card-data-request 1600 password: xyzzy 1601 server-date: 19950121100505.nnn [optional] 1602 order-id: 12313424234242 1603 merchant-amount: usd 10.00 1604 pr-hash: 7Tm/djB05pLIw3JAyy5E7A== 1605 pr-signed-hash: 1606 sfljlkjflkjseljljljwlkjrweljljljwlkjrweljljljwlkjrweljljlj 1607 kjrweljljljwlkjrwlejrlwkjlerkjwelr= 1608 id: myCyberCashID 1609 transaction: 78784567 1610 date: 19950121100505.nnn 1611 merchant-signature: lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjflkj 1612 flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf= 1614 ##################################################################### 1615 merchant-opaque key is generated from the CyberCash encrypting public 1616 key identified in merchant-cyberkey. 1618 Customer opaque section (Opaque) - see CH1. 1620 ##################################################################### 1621 Opaque Section Contents & Signature: (exactly as in CH1) 1623 swversion: 0.8win 1624 amount: usd 10.00 1625 card*: [from successful BC4 (includes card-expiration-date, 1626 card-number, and card-salt)] 1627 signature: dfdsfffffsfdZydMAGVasdflkkjasdflkkjasfdlkjasdflkajsdlfkjas 1628 fjaAqbat2d6hlC/mSw== 1630 ##################################################################### 1631 merchant-signature is on the following fields: merchant-ccid, 1632 merchant-transaction, merchant-date, merchant-cyberkey, type, 1633 password, server-date, order-id, merchant-amount, pr-hash, 1634 pr-signed-hash, id, transaction, date, cyberkey 1636 Customer Signature: see CH1 1638 ##################################################################### 1639 Explanation: 1640 [see also CM1 explanation] 1641 The merchant may need to know the card involved and other 1642 information in order to resolve a disputed transaction. This 1643 information is all contained in the original CH1 embedded in the 1644 CM1 for the transaction. If the merchant saves the CM1 and other 1645 transaction information, they can send this CD1 message to the 1646 server. While this reduces the pass through confidentiality of 1647 the system, the merchant is then on record as asking for this 1648 particular credit card number and excessive CD1's from a merchant 1649 can be flagged. 1650 password is an extra level of security intended to be manually entered 1651 at the merchant to authorize the unusual action. Server stores a 1652 hash of the merchant-ccid and the password. 1654 4.4.9 CD2 - card-data-response 1656 Description: Respond to CD1 with failure or with success and card 1657 data. 1659 ##################################################################### 1660 Sender: CyberServer Receiver: MerchantApp 1661 ##################################################################### 1662 Sample Message: 1664 $$-CyberCash-0.7-$$ merchant-ccid: ACME-012 merchant-transaction: 1665 123123 merchant-date: 19950121100705.nnn merchant-opaque: 1666 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1667 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1668 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1669 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1670 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1671 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1672 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1673 3ard3Q== $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1675 ##################################################################### 1676 Opaque Key: session key from CD1. 1678 ##################################################################### 1679 Opaque Section Contents: 1681 type: card-data-response server-date: 19950121100706.nnn response- 1682 code: failure/success/etc. order-id: 1231-3424-234242 pr-hash: 1683 7Tm/djB05pLIw3JAyy5E7A== pr-signed-hash: 1684 sfljlkjflkjseljljllkjseljljllkjseljljllkjseljljllkjse 1685 ljljwlkjrwlejrlwkjlerkjwelr= card-hash: 7Tm/djB05pLIw3JAyy5E7A== 1686 card-number: 4811123456781234 card-type: visa card-name: John Q. 1687 Public expiration-date: 01/99 merchant-swseverity: fatal/warning 1688 merchant-swmessage; Message for merchant about out of date 1689 protocol number in $$ start line of merchant message. merchant- 1690 message; 1691 Free text of the error/success condition. 1692 This text is for the merchant from the server... id: 1693 myCyberCashID transaction: 78784567 date: 19950121100505.nnn 1695 ##################################################################### 1696 Signature is of the following fields: no signature. 1698 ##################################################################### 1699 Explanation: This normally returns selected fields from the decoding 1700 of the 1701 opaque part of a CH1 as sent to the server in a CD1. 1703 4.5 Utility and Error Messges 1705 A number of utility, status query, and special error reporting 1706 messages have also been found necessary in implementing the CyberCash 1707 system. 1709 It is desirable to be able to test connectivity, roughly synchronize 1710 clocks, and get an initial determination of what client protocol and 1711 software versions are accepted. This is done via the P1 client to 1712 server message and its P2 server to client response. 1714 Clients need to be able to determine the status of earlier 1715 transactions when the client or merchant has crashed during or has 1716 suffered data loss since the transaction. Two transaction query 1717 messages are defined, TQ1 and TQ2. One just queries and the other 1718 also cancels the transaction, if it has not yet completed. The 1719 response to both of these messages is a TQ3 response from the server. 1721 Since the system operates in a query response mode, there are two 1722 cases where special error messages are needed. If a query seems to 1723 be of an undeterminable or unknown type, the UNK1 response error 1724 message is sent. If a response seems to be of an undeterminable or 1725 unknown type or other serious error conditions occur at the client or 1726 merchant which should be logged at the CyberCash server, the DL1 or 1727 DL2 diagnostic log message is submitted by the client or merchant in 1728 question respectively. 1730 4.5.1 P1 - ping 1732 Description: Very light weight check that we have connectivity 1733 from the customer to the server. 1735 ##################################################################### 1736 Sender: CyberApp 1737 Receiver: CyberServer 1738 ##################################################################### 1739 Sample Message: 1741 $$-CyberCash-0.8-$$ 1742 type: ping 1743 id: myCyberCashID [optional] 1744 transaction: 123123213 1745 date: 19950121100505.nnn 1746 $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1748 ##################################################################### 1749 Explanation: 1750 id optional as persona may not have been set up yet. 1752 4.5.2 P2 - ping-response 1754 Description: Response to the P1 light weight ping. Does no 1755 crypto to minimize overhead. 1757 ##################################################################### 1758 Sender: CyberServer 1759 Receiver: CyberApp 1760 ##################################################################### 1761 Sample Message: 1763 $$-CyberCash-0.7-$$ 1764 type: ping-response 1765 id: myCyberCashID [if present in P1] 1766 transaction: 12312313 1767 date: 19950121100505.nnn 1768 server-date: 19950121100506.nnn 1769 swseverity: fatal/warning [absent if ok] 1770 swmessage; Tells CyberApp that it is using an obsolete protocol. 1771 Display this text to the user. [only present if SWSeverity 1772 present] 1773 response-code: success/failure/etc. 1774 message; 1775 Free text of the error/success condition. 1776 This text is to be displayed to the sender 1777 by their CyberCash application... 1778 supported-versions: 08.win, 0.81win, 0.8mac 1779 $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 1781 ##################################################################### 1782 Explanation: 1783 swversion does not appear in P1 for security reasons so 1784 swseverity and swmessage appear only if the server can tell 1785 that things are old from the $$ header protocol version. 1786 supported-versions lets client know as soon as possible what 1787 versions are supported and, by implication, which are not. Does 1788 not compromise security by having client say what version it 1789 is. 1791 4.5.3 TQ1 - transaction-query 1793 Description: Client query to server for Transaction status. 1795 ##################################################################### 1796 Sender: CyberApp 1797 Receiver: CyberServer 1798 ##################################################################### 1799 Sample Message: 1801 $$-CyberCash-0.8-$$ 1802 id: MyCyberCashID 1803 date: 19950121100505.nnn 1804 transaction: 12312314 1805 cyberkey: CC1001 1806 opaque: 1807 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1808 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1809 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1810 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1811 3ard3Q== 1812 $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ 1814 ##################################################################### 1815 Opaque Key: generated from CyberCash encryption key identified in 1816 CyberKey 1818 ##################################################################### 1819 Opaque Section Contents: 1821 type: transaction-query 1822 swversion: 0.8win 1823 begin-transaction: 1234 1824 end-transaction: 4321 1825 signature: sjadlkasl;f;lksaj;lfjs;lfjsldfjl;lfjs;lfjsldfjl;lfjs;lfjsl 1826 ;lfjs;lfjsldfjl;lfjs;lfjsldfjlskflsajfsa== 1828 ##################################################################### 1829 signature is of the following fields: id, date, transaction, 1830 cyberkey, type, swversion, begin-transaction, 1831 end-transaction 1833 ##################################################################### 1834 Explanation: 1835 This is a client status query of a previous transaction or 1836 transactions. 1837 begin-transaction and end-transaction can be the same. 1839 4.5.4 TQ2 - transaction-cancel 1841 Description: Client query to server for Transaction 1842 cancellation/status. 1844 ##################################################################### 1845 Sender: CyberApp 1846 Receiver: CyberServer 1847 ##################################################################### 1848 Sample Message: 1850 $$-CyberCash-0.8-$$ 1851 id: MyCyberCashID 1852 date: 19950121100505.nnn 1853 transaction: 12312314 1854 cyberkey: CC1001 1855 opaque: 1856 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1857 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1858 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1859 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1860 3ard3Q== 1861 $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ 1863 ##################################################################### 1864 Opaque Key: generated from CyberCash encryption key identified in 1865 CyberKey 1867 ##################################################################### 1868 Opaque Section Contents: 1870 type: transaction-cancel 1871 swversion: 0.8win 1872 begin-transaction: 1234 1873 end-transaction: 4321 1874 signature: sjadlkasl;f;lksaj;lfjs;lfjsldfjl;lfjs;lfjsldfjl;lfjs;lfjsl 1875 ;lfjs;lfjsldfjl;lfjs;lfjsldfjlskflsajfsa== 1877 ##################################################################### 1878 signature is of the following fields: id, date, transaction, 1879 cyberkey, type, swversion, begin-transaction, end-transaction 1881 ##################################################################### 1882 Explanation: 1883 This is a client attempt to cancel a previous transaction or 1884 transactions. 1885 begin-transaction and end-transaction can be the same. 1887 The transaction-cancel transaction (TQ.2) is defined between the 1888 client and the server. This transaction permits the client to 1889 query the status of an operation and to stop the operation from 1890 occurring if it has not already occurred. 1892 4.5.5 TQ3 - transaction-response 1894 Description: Reports generated by a TQ1 or TQ2 1896 ##################################################################### 1897 Sender: CyberServer 1898 Receiver: CyberApp 1899 ##################################################################### 1900 Sample Message: 1902 $$-CyberCash-0.8-$$ 1903 id: mycybercashid 1904 date: 19950121100505.nnn 1905 transaction: 12312314 1906 server-date: 19950121100505.nnn 1907 opaque: 1908 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 1909 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1910 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1911 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1912 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 1913 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 1914 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 1915 3ard3Q== 1916 $$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$ 1918 ##################################################################### 1919 Opaque Key: Session key from TQ1/TQ2 with same Transaction and ID. 1921 ##################################################################### 1922 Opaque Section Contents: 1924 type: transaction-response 1925 response-code: success/failure/etc. 1926 message; general free form text message from server to 1927 customer.... 1928 swseverity: fatal/warning 1929 swmessage; Message indicating that CyberApp software is obsolete. 1930 May be multiple lines. 1931 report-fee: usd 0.15 [if non-zero] 1933 transaction-1: old-transaction-number 1934 transaction-status-1: success/failure/pending/cancelled/etc. 1935 server-date-1: 19951212125959.nnn 1936 date-1: 19950121100505.nnn 1937 type-1: auth-only/etc. 1939 ##################################################################### 1940 Signature is of the following fields: no signature 1942 ##################################################################### 1943 Explanation: 1944 Report-fee is the notification that this report cost a fee and is 1945 only present if there is a fee. 1946 There can be multiple transaction for the same transaction number as 1947 there could have been a auth, post-auth-capture, void, etc. 1949 Terms 1950 "original transaction" refers to the payment or other transaction 1951 that is being queried or canceled. 1952 Note: this transaction may not actually reside at the server. 1953 "request" refers to the requesting TQ.2 or TQ.1 message 1955 id: id from the request message 1956 date: date from the request message 1957 transaction: transaction from the request message 1958 server-date: current date/time 1959 type: transaction-response 1960 response-code: response code for request message, can be one of: 1961 "success" means the request message was processed. Does not imply 1962 query or cancellation status of the request. 1963 "failure-hard" means that the request message was not processed 1964 due to being ill-formed or otherwise inoperable. 1965 "failure-swversion" means that the request message was not 1966 processed due to software revision problems. 1967 message: the message applies only to the TQ transaction, not to the 1968 status of the transactions being queried or canceled. The 1969 message is provided according to the response-code as: 1970 "success" message is omitted. "failure-hard" use standard hard 1971 failure message. "failure-swversion" use standard swversion 1972 message for fatal 1973 swseverity: applies to request message 1974 swmessage: applies to request message 1976 -- per query/cancel fields ('N' is a series from 1 to N) -- 1977 transaction-N: transaction number of original transaction, or if 1978 the original transaction is not present in server the transaction 1979 number that the query / cancel request refers to 1980 transaction-status-N: status of original transaction, may be one of: 1981 "success" the original transaction was successfully processed. 1982 If request was TQ.2, cancellation is not performed. 1983 "failure" the original transaction was not successfully processed. 1984 If request was TQ.2, cancellation is not performed (however, 1985 there is nothing to cancel, so it's all the same to the customer 1986 app). 1987 "pending" the original transaction is still being processed and 1988 final disposition is not known. 1989 "canceled" the original transaction has been canceled by the server. 1990 Later arrival of the original transaction will not be processed, 1991 but will be returned with a "failure-canceled" returned. 1992 server-date-1: server-date field from original transaction or 1993 omitted if original transaction is not present in the server" 1994 date-1: date field from original transaction or omitted if original 1995 transaction is not present in the server" 1996 type-1: type field from original transaction or omitted if original 1997 transaction is not present in the server" 1999 4.5.6 UNK1 - unknown-error 2001 Description: This is the response sent when the request is so 2002 bad off you can't determine what type it is or the type is 2003 unknown to you. Sent from Merchant to Client or from Server 2004 to Merchant or from Server to Client. 2006 ##################################################################### 2007 Sender: MerchantApp or CyberServer 2008 Receiver: CyberApp or MerchantApp 2009 ##################################################################### 2010 Sample Message: 2012 $$-CyberCash-0.8-$$ 2013 type: unknown-error 2014 unknown-error-message: 2015 Text message of error condition to display to user. (CyberCash 2016 wrapper not found, wrapper integrity check fails, unknown protocol 2017 version specified, unknown type specified, etc.) 2018 { 2019 server-date: 19950121100506.nnn [if sent by server] 2020 } 2021 or 2022 { 2023 merchant-date: 19950121100506.nnn [if sent by merchant] 2024 } 2025 x-id: mycybercashID 2026 x-transaction: 123123213 2027 x-date: 19950121100505.nnn 2028 x-cyberkey: CC1001 2029 x-opaque: 2030 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 2031 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 2032 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 2033 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 2034 3ard3Q== 2035 $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ 2037 ##################################################################### 2038 Opaque Key: see explanation 2040 ##################################################################### 2041 Opaque Section Contents: see explanation 2043 ##################################################################### 2044 Signature is of the following fields: see explanation 2046 ##################################################################### 2047 Explanation: 2048 This message is sent as a response when you can't find or understand 2049 even the type of a message to you. It will always have type and 2050 unknown-error-message fields at the beginning. Any fields from 2051 the request that are parseable are simply echoed back in the UNK1 2052 message with "x-" prefixed to it. Thus, if an x-opaque appears, 2053 it was whatever the opaque was in the original request, etc. If 2054 you can decrypt the opaque section, you don't want to put the 2055 results here in the clear! 2056 {}'s in the first column are to group alternatives only and do not 2057 appear in the message. 2058 Since the customer originates exchanges with merchant and server 2059 and merchant originates exchanges with server, this message 2060 will only be emitted from the merchant to the customer or the 2061 server to the customer or merchant. It should generally just 2062 be logged for debugging purposes. 2063 You may need to watch out for denial of service via forged or 2064 replayed UNK1 messages. 2066 4.5.7 DL1 - diagnostic-log 2068 Description: Client diagnostic log of bad message from either 2069 merchant or server. 2071 ##################################################################### 2072 Sender: CyberApp 2073 Receiver: CyberServer 2074 ##################################################################### 2075 Sample Message: 2077 $$-CyberCash-0.8-$$ 2078 id: MyCyberCashID 2079 date: 19950121100505.nnn 2080 transaction: 1234 2081 cyberkey: CC1001 2082 opaque: 2083 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 2084 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ffs 2085 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKXx 2086 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 2087 3ard3Q== 2088 $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ 2090 ##################################################################### 2091 Opaque Key: generated from CyberCash encryption key identified in 2092 CyberKey 2094 ##################################################################### 2095 Opaque Section Contents: 2097 type: diagnostic-log 2098 server-date: 19950121100505.nnn [optional] 2099 message: incorrect order-id 2100 swversion: 0.8win 2102 x-type: original-message-type 2103 x-transaction: original-transaction-number 2104 x-opaque: [if can't decrypt] 2105 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 2106 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 2108 ##################################################################### 2109 Explanation: 2111 Client application does not expect a response for this message. The 2112 decrypted original message will be in the opaque section unless 2113 decryption fails. If decryption fails then un-decrypted opaque 2114 in the original will be sent. 2115 This message will be sent to a different script or socket or host 2116 than normal messages so that it will just be absorbed and never 2117 generate an UNK1 response or anything, even if this message 2118 itself is screwed up. 2120 4.5.8 DL2 - merchant-diagnostic-log 2122 Description: Merchant diagnostic log of bad message from server. 2124 ##################################################################### 2125 Sender: CyberMerchant 2126 Receiver: CyberServer 2127 ##################################################################### 2128 Sample Message: 2130 $$-CyberCash-0.8-$$ 2131 merchant-ccid: MyCyberCashID 2132 merchant-transaction: 1234 2133 merchant-date: 19950121100505.nnn 2134 merchant-cyberkey: CC1001 2135 merchant-opaque: 2136 iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg 2137 3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3 2138 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 2139 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 2140 3ard3Q== 2141 $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ 2143 ##################################################################### 2144 Opaque Key: generated from CyberCash encryption key identified in 2145 CyberKey 2147 ##################################################################### 2148 Opaque Section Contents: 2150 type: merchant-diagnostic-log 2151 server-date: 19950121100505.nnn [optional] 2152 message: incorrect order-id 2154 x-type: original-message-type 2155 x-transaction: original-transaction-number 2156 x-opaque: [if can't decrypt] 2157 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 2158 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw 2160 ##################################################################### 2161 Explanation: 2162 Merchant application does not expect a response for this message. The 2163 decrypted original message will be in the opaque section unless 2164 decryption fails. If decryption fails then un-decrypted message 2165 will be sent. 2166 This message will be sent to a different script or socket or host 2167 than normal messages so that it will just be absorbed and never 2168 generate an UNK1 response or anything even if this message 2169 itself is screwed up. 2171 4.6 Table of Messages Described 2173 C = Customer App M = Merchant App S = CyberCash Server 2175 FLOW SECTION NAME 2177 C->S 4.2.1 BC.1 bind-credit-card 2178 S->C 4.2.2 BC.4 bind-credit-card-response 2180 C->M 4.3.2 CH.1 credit-card-payment 2181 M->C 4.3.3 CH.2 credit-card-response 2183 M->S 4.4.8 CD.1 card-data-request 2184 S->M 4.4.9 CD.2 card-data-response 2186 M->S 4.4.1 CM.1 auth-only 2187 M->S 4.4.2 CM.2 auth-capture 2188 M->S 4.4.3 CM.3 post-auth-capture 2189 M->S 4.4.4 CM.4 void 2190 M->S 4.4.5 CM.5 return 2191 S->M 4.4.6 CM.6 charge-action-response 2193 C->S 4.5.7 DL.1 diagnostic-log 2194 M->S 4.5.7 DL.2 merchant-diagnostic-log 2196 C->S 4.1.3 GA.1 get-application 2197 S->C 4.1.4 GA.2 get-application-response 2199 M->S 4.4.7 MM.1 merchant-auth-only 2200 M->S 4.4.7 MM.2 merchant-auth-capture 2201 M->S 4.4.7 MM.3 merchant-post-auth-capture 2202 M->S 4.4.7 MM.4 merchant-void 2203 M->S 4.4.7 MM.5 merchant-return 2204 S->M 4.4.7 MM.6 merchant-charge-action-response 2206 C->S 4.5.1 P.1 ping 2207 S->C 4.5.2 P.2 ping-response 2209 M->C 4.3.1 PR.1 payment-request 2211 C->S 4.1.1 R.1 registration 2212 S->C 4.1.2 R.2 registration-response 2214 C->S 4.5.3 TQ.1 transaction-query 2215 C->S 4.5.4 TQ.2 transaction-cancel 2216 S->C 4.5.5 TQ.3 transaction-response 2218 S->C, S->M, M->C 2219 4.5.6 UNK.1 unknown-error 2221 5. Future Development 2223 CyberCash is extending the facilities available through the CyberCash 2224 system. We are committed to implementing a full cash system, 2225 including efficient transfer of small amounts of money, the extension 2226 of the credit card system to handle settlements, and other 2227 improvements. 2229 6. Security Considerations 2231 The CyberCash Version 0.8 Credit Card system provides substantial 2232 protection to payment messages as described above in sections 1.2, 2233 2.2.4, and 2.2.5. However, it provides no privacy to the shopping 2234 interaction which is essentially outside of its purview. It also 2235 provides no protection against dishonest merchants other than those 2236 normally available with credit card purchases. Care must be taken to 2237 avoid loss of control of the machines on which parts of this system 2238 runs or security may be compromised. 2240 Current credit card dispute resolution systems require deliberate 2241 bypasses be implemented for some of the security normally established 2242 by CyberCash as described in section 3.4. 2244 References 2246 [ISO 4217] - Codes for the representation of currencies and funds 2248 [ISO 8583] - Financial transaction card originated messages - 2249 Interchange message specifications, 1993-12-15. 2251 [RFC 822] - D. Crocker, "Standard for the format of ARPA Internet 2252 text messages", 08/13/1982. 2254 [RFC 1521] - N. Borenstein, N. Freed, "MIME (Multipurpose Internet 2255 Mail Extensions) Part One: Mechanisms for Specifying and Describing 2256 the Format of Internet Message Bodies", 09/23/1993. 2258 [RFC 1766] - H. Alvestrand, "Tags for the Identification of 2259 Languages", 03/02/1995. 2261 Authors Addresses 2263 Donald E. Eastlake 3rd 2264 CyberCash, Inc. 2265 318 Acton Street 2266 Carlisle, MA 01741 USA 2268 Telephone: +1 508 287 4877 2269 EMail: dee@cybercash.com 2271 Brian Boesch 2272 CyberCash, Inc. 2273 2100 Reston Parkway, Suite 430 2274 Reston, VA 22091 USA 2276 Telephone: +1 703-620-4200 2277 email: boesch@cybercash.com 2279 Steve Crocker 2280 CyberCash, Inc. 2281 2100 Reston Parkway, Suite 430 2282 Reston, VA 22091 USA 2284 Telephone: +1 703-620-4200 2285 email: crocker@cybercash.com 2287 Magdalena Yesil 2288 CyberCash, Inc. 2289 555 Twin Dolphin Drive, Suite 570 2290 Redwood City, CA 94065 USA 2292 Telephone: +1 415-594-0800 2293 email: magdalen@cybercash.com 2295 Expiration and File Name 2297 This draft expires 7 January 1996. 2299 Its file name is draft-eastlake-cybercash-v08-00.txt.