RFCs in HTML Format


RFC 1898

               CyberCash Credit Card Protocol Version 0.8


Acknowledgements

   The significant contributions of the following persons (in alphabetic
   order) to this protocol are gratefully acknowledged:

        Bruce Binder, Judith Grass, Alden Hart, Steve Kiser, Steve
        Klebe, Garry Knox, Tom Lee, Bob Lindenberg, Jim Lum, Bill
        Melton, Denise Paredes, Prasad Chintamaneni, Fred Silverman,
        Bruce Wilson, Garland Wong, Wei Wu, Mark Zalewski.

   In addition, Jeff Stapleton and Peter Wagner made useful comments on
   the first version of this memo.







Eastlake, et al              Informational                      [Page 1]

RFC 1898 CyberCash Version 0.8 February 1996 History For historic purposes, it should be noted that this document was first posted as an Internet draft, and thus made publicly available, on 8 July 1995. Table of Contents 1. Overall System..........................................3 1.1 System Overview........................................3 1.2 Security Approach......................................5 1.2.1 Authentication and Persona Identity..................5 1.2.2 Privacy..............................................6 1.3 Credit Card Operation..................................6 2. General Message Wrapper Format..........................7 2.1 Message Format.........................................7 2.2 Details of Format......................................8 2.3 Body Parts.............................................8 2.4 Transparent Part.......................................9 2.5 Opaque Part...........................................10 2.6 Trailer...............................................10 2.7 Example Messages......................................11 3. Signatures and Hashes..................................12 3.1 Digital Signatures....................................12 3.2 Hash Codes............................................13 4. Specific Message Formats...............................13 4.1 Persona Registration and Application Retrieval........14 4.1.1 R1 - registration...................................14 4.1.2 R2 - registration-response..........................15 4.1.3 GA1 - get-application...............................16 4.1.4 GA2 - get-application-response......................17 4.2 Binding Credit Cards..................................18 4.2.1 BC1 - bind-credit-card..............................18 4.2.2 BC4 - bind-credit-card-response.....................20 4.3 Customer Credit Card Purchasing Messages..............21 4.3.1 PR1 - payment-request...............................21 4.3.2 CH1 - credit-card-payment...........................23 4.3.3 CH2 - charge-card-response..........................24 4.4 Merchant Credit Card Purchasing Messages..............25 4.4.1 CM1 - auth-only.....................................26 4.4.2 CM2 - auth-capture..................................28 3.4.3 CM3 - post-auth-capture.............................28 4.4.4 CM4 - void..........................................30 4.4.5 CM5 - return........................................32 4.4.6 CM6 - charge-action-response........................32 4.4.7 The MM* Message Series..............................34 4.4.8 CD1 - card-data-request.............................35 4.4.9 CD2 - card-data-response............................37 Eastlake, et al Informational [Page 2]
RFC 1898 CyberCash Version 0.8 February 1996 4.5 Utility and Error Messges.............................38 4.5.1 P1 - ping...........................................39 4.5.2 P2 - ping-response..................................39 4.5.3 TQ1 - transaction-query.............................40 4.5.4 TQ2 - transaction-cancel............................41 4.5.5 TQ3 - transaction-response..........................42 4.5.6 UNK1 - unknown-error................................44 4.5.7 DL1 - diagnostic-log................................46 4.5.8 DL2 - merchant-diagnostic-log.......................47 4.6 Table of Messages Described...........................48 5. Future Development.....................................49 5.1 The Credit Card Authorization/Clearance Process.......49 5.2 Lessons Learned.......................................50 6. Security Considerations................................51 References................................................51 Authors' Addresses........................................52 1. Overall System CyberCash, Inc. of Reston, Virginia was founded in August of 1994 to partner with financial institutions and providers of goods and services to deliver a safe, convenient and inexpensive system for making payments on the Internet. The CyberCash approach is based on establishing a trusted link between the new world of cyberspace and the traditional banking world. CyberCash serves as a conduit through which payments can be transported quickly, easily and safely between buyers, sellers and their banks. Significantly - much as it is the real world of commerce - the buyer and seller need not have any prior existing relationship. As a neutral third party whose sole concern is ensuring the delivery of payments from one party to another, CyberCash is the linchpin in delivering spontaneous consumer electronic commerce on the Internet. 1.1 System Overview The CyberCash system will provide several separate payment services on the Internet including credit card and electronic cash. To gain access to CyberCash services, consumers need only a personal computer with a network connection. Similarly, merchants and banks need make only minimal changes to their current operating procedures in order to process CyberCash transactions, enabling them to more quickly integrate safe on-line payments into their existing service offerings. Communications with banks are over existing financial communications networks. Eastlake, et al Informational [Page 3]
RFC 1898 CyberCash Version 0.8 February 1996 To get started, consumers download free software from CyberCash on the Internet. This software establishes the electronic link between consumers, merchants and their banks as well as between individuals. To make gaining access to the CyberCash system even easier, CyberCash "PAY" buttons may be incorporated into popular on-line service and software graphical user interfaces so that consumers using these products can easily enter the CyberCash system when they are ready to make payments for goods and services. Consumers need not have any prior relationship with CyberCash to use the CyberCash system. They can easily set up their CyberCash persona on-line. Transactions are automated in that once the consumer enters appropriate information into his own computer, no manual steps are required to process authorization or clearance transactions through the entire system. The consumer need only initiate payment for each transaction by exercising the pay option on an electronic form. Transactions are safe in that they are cryptographicly protected from tampering and modification by eavesdroppers. And they are private in that information about the consumer not relevant to the transaction is not visible to the merchant. +------------+ +------------+ | | | | | Internet | | Internet | | customer +------------+ merchant + | | | / | +------------+ +------------+ / / +------------|-+ | CyberCash | | | server | | +-----+------|-+ | | | | +--------------+------|---------+ | +--------+ +--+-------+ | | | card +-------+ / charge | | | | issuer | | acquirer | | | +--------+ +----------+ | | | | The Banking System | +-------------------------------+ SYSTEM OVERVIEW Eastlake, et al Informational [Page 4]
RFC 1898 CyberCash Version 0.8 February 1996 1.2 Security Approach The CyberCash system pays special attention to security issues. It uses encryption technology from the world's leading sources of security technology and is committed over time to employing new security technologies as they emerge. 1.2.1 Authentication and Persona Identity Authentication of messages is based on Public Key encryption as developed by RSA. The CyberCash Server maintains records of the public key associated with every customer and merchant persona. It is thus able to authenticate any information digitally signed by a customer or merchant regardless of the path the data followed on its way to the server. The corresponding private key, which is needed to create such digital signatures, will be held by the customer or merchant and never revealed to other parties. In customer software, the private key is only stored in an encrypted form protected by a passphrase. While the true CyberCash identity of a customer or merchant is recognized by their public/private key pair, such keys are too cumbersome (over 100 hex digits) to be remembered or typed by people. So, the user interface utilizes short alphanumeric ID's selected by the user or merchant for purposes of specifying a persona. CyberCash adds check digits to the requested ID to minimize the chance of accidental wrong persona selection. Persona IDUs are essentially public information. Possession of an persona ID without the corresponding private key is of no benefit in the current system. Individuals or organizations may establish one or more CyberCash customer personas directly with CyberCash. Thus, an individual may have several unrelated CyberCash personas or share a CyberCash persona with other individuals. This approach provides a degree of privacy consistent with Internet presence generally and with cash transactions specifically. However, persona holders who wish to use a credit card for purchases in conjunction with their CyberCash persona must first meet such on-line identification criteria as the card issuing organization requires. Control over a CyberCash persona is normally available only to an entity that possesses the private key for that persona. However, a special provision is made to associate an emergency close out passphrase with a CyberCash persona. On receipt of the emergency close out passphrase, even if received over insecure channels such as a telephone call or ordinary email, CyberCash will suspend activity for the CyberCash persona. This emergency close-out passphrase can be stored separately from and with somewhat less security than the Eastlake, et al Informational [Page 5]
RFC 1898 CyberCash Version 0.8 February 1996 private key for the persona since the emergency passphrase can not be used to divert funds to others. This provides some protection against loss or misappropriation of the private key or the passphrase under which the private key in kept encrypted. In the cash system, the emergency close-out passpharase may also transfer the persona balance to a designated bank account. 1.2.2 Privacy Encryption of messages use the Digital Encryption Standard (DES), commonly used in electronic payment systems today. It is planned to superencrypt (i.e., encrypted more than one level) particularly sensitive information, such as PIN numbers, and handle them so that the plain text readable version never exists in the CyberCash system except momentarily, within special purpose secure cryptographic hardware that is part of the server, before being re-encrypted under another key. The processing of card charges through the CyberCash system is organized so that the merchant never learns the customerUs credit card number unless the merchantUs bank chooses to release this information to the merchant or it is required for dispute resolution. In addition, the server maintains no permanent storage of card numbers. They are only present while a transaction involving that card is in progress. These practices greatly reduce the chance of card number misappropriation. 1.3 Credit Card Operation Using the CyberCash system for credit card transactions, once price has been negotiated and the consumer is ready to purchase, the consumer simply clicks on the CyberCash "PAY" button displayed on the merchant interface, which invokes the merchant CyberCash software. The merchant sends the consumer an on-line invoice that includes relevant purchase information which appears on the customerUs screen. (See PR1 message.) The consumer adds his credit card number and other information by simply selecting from a list of credit cards he has registered to his CyberCash persona. All this information is digitally signed by the customer's CyberCash software, encrypted, and passed, along with a hash code of the invoice as seen by the customer, to the merchant. (See CH1 message.) Upon receipt, the merchant adds additional authorization information which is then encrypted, electronically signed by the merchant, and sent to the CyberCash Server. (See CM1 & CM2 messages.) The CyberCash Server can authenticate all the signatures and be sure that the customer and merchant agree on the invoice and charge amount. The CyberCash Server then forwards the relevant information to the Eastlake, et al Informational [Page 6]
RFC 1898 CyberCash Version 0.8 February 1996 acquiring bank along with a request on behalf of the merchant for a specific banking operation such as charge authorization. The bank decrypts and then processes the received data as it would normally process a credit card transaction. The bank's response is returned to the CyberCash Server which returns an electronic receipt to the merchant (see CM6 message) part of which the merchant is expected to forward to the customer (see CH2 message). The transaction is complete. 2. General Message Wrapper Format Version 0.8 of the external format for the encoding of CyberCash messages is described below. CyberCash messages are stylized documents for the transmission of financial data over the Internet. While there are numerous schemes for sending information over the Internet (HTTP, SMTP, and others), each is attached to a specific transmission mechanism. Because CyberCash messages will need to travel over each of these media (as well as others) a transmission independent mechanism is needed. 2.1 Message Format CyberCash messages consist of the following components: 1. Header - defines the start of the CyberCash message and includes version information. 2. Transparent Part - contains information that is not private. 3. Opaque Part(s) - contains the financial information in the message and is both privacy protected as well as tamper protected. An opaque part is not present in some messages. When present, the opaque part usually provides tamper protection for the transparent part. 4. Trailer - defines the end of the CyberCash message and includes a check value to enable the receiver to determine that the message has arrived undamaged. Note: this check value is intended only to detect accidental damage to the message, not deliberate tampering. No null characters (zero value) or characters with the eighth bit on are permitted inside a CyberCash message. "Binary" quantities that might have such byte values in them are encoded in base64 as described in RFC 1521. Eastlake, et al Informational [Page 7]
RFC 1898 CyberCash Version 0.8 February 1996 2.2 Details of Format The header consists of a single line which looks approximately like this $$-CyberCash-0.8-$$ or like this $$-CyberCash-1.2.3-Extra-$$ It includes a number of fields separated with the minus character "-" 1. "$$" - the literal string with the initial $ in column 1. 2. "CyberCash" - the literal string (case insensitive) 3. x.y or x.y.z - the version number of the message format. x is the primary version number. y is a subversion number. z, if present, is a subsubversion number. 4. "Extra" - an optional additional alphanumeric string. 5. "$$" - the literal string Version numbers start at 0.7 and count up. The ".z" is omitted when z is zero. 0.7 and 0.8 are the test and initial shipped version of the credit card system. 0.9 and 1.0 are expected to also incorporate the test and initial shipped versions of the cash facilities as well as improvements to the credit card system. The "Extra" string is used within secure environments so that one subcomponent can scribble a note to another with minimum overhead. For example, a server firewall could put "HTTP" or "SMTP" here before forwarding the message to the core server within the firewall perimeter. 2.3 Body Parts The body parts of the message (both transparent and opaque) consist of attribute value pairs in formats that are reminiscent of the standard electronic mail header (RFC822) format. However, there are some differences. Attribute names start with and are composed predominantly of letters and internal hyphens except that they sometimes end with a hyphen followed by a number. Such a trailing number is used when there is logically an indexed vector of values. Attribute names are Eastlake, et al Informational [Page 8]
RFC 1898 CyberCash Version 0.8 February 1996 frequently referred to as labels. If the label ends with a ":", then RFC822 processing is done. While the existence of trailing white space is significant, all leading white space on continuation lines is stripped. Such lines are wrapped at 64 characters in length, excluding any line termination character(s). However, if the label is terminated with a ";", this indicates a free-form field where new-line characters and any leading white space, after the initial space that indicates a continuation line, is significant. Such lines should not be wrapped except that, to avoid other processing problems, they are forcibly wrapped at 200 characters. Blank lines are ignored and do not signify a change to a different mode of line handling. Another way of looking at the above is as follows: after having found an initial $$ start line, you can treat any following lines according to the first character. If it is alphanumeric, it is a new label which should be terminated with a ":" or ";" and indicates a new label-value pair. If it is a white space character, it indicates the continuation of the value for the preceding new label line. (Exactly how the continuation is processed depends on the label termination character.) If it is "$", it should be the end line for the message. If it is #, it is a comment line and should be ignored. Other initial characters are undefined. (As of this date, no software sends CyberCash messages with # lines but they are convenient for commenting messages stored in files.) 2.4 Transparent Part The transparent part includes any clear-text data associated with the financial transaction as well as information needed by CyberCash and others to decrypt the opaque part(s). It always includes a transaction field which is the transaction number generated by the requester and which is repeated in the response. It always includes a date field that is the local date and time at the requester and is repeated in the response. In all cases other than an initial registration to establish a persona ID, it includes the requester's persona ID. On messages bound for the server, there is a "cyberkey:" field that identifies which server public key was used to encrypt the session key. Eastlake, et al Informational [Page 9]
RFC 1898 CyberCash Version 0.8 February 1996 2.5 Opaque Part The opaque part consists of a single block of characters encoded using base64 encoding (see RFC 1521). The data in the opaque section is always encrypted before encoding. The label "opaque" or "merchant-opaque" precedes the opaque part depending on whether the data was encrypted by the client or merchant software. On messages inbound to the server, the data to be opaqued is DES CBC encrypted under a random transacton key and then that DES key is RSA encrypted under one of the server's public keys. The RSA encrypted DES key appears as the first part of the base64 encoded field and is not broken out as a separate value in the message. The corresponding outbound reply from the server can simply be DES encrypted under this transaction key as there is enough plain text information to identify the transaction and the customer or merchant will have remembered the transaction key from the inbound message. A signature is not generally necessary in the opaque part of a reply message. Knowledge of the transaction key is adequate authentication. In order for someone to forge the response, they would have to know the server's private key to be able to get at the transaction key. It is assumed that if anyone tampered with the response opaque part, the probability that it would decrypt to something that would parse is insignificant. (Just the fact that the 8th bit has to be off means a chance of 1 in 2**n where there are n characters and that's ignoring the rest of the formatting.) While someone can tamper with the transparent part, this usually either has no effect or means that the client won't find the transaction key, in which case it's just a particular example of denial of service by damaging a message. 2.6 Trailer The trailer is intended to close the message and provide a definitive and parseable end of the message. The trailer consists of several fields separated by "-" as in header. 1. "$$" - literal string. 2. "CyberCash" - literal string (case insensitive). 3. "End" - literal string (case insensitive). 4. transmission checksum. Eastlake, et al Informational [Page 10]
RFC 1898 CyberCash Version 0.8 February 1996 5. "$$" - literal string. The transmission checksum is the MD5 has of all printable characters in the version number in the start line and those appearing after the second $$ of the start line and before the first $$ of the trailer line as transmitted. Note that all white space is left out of this hash, including any new-lines, spaces, tabs, carriage returns, etc. The exact label terminators actually used (: or ;) are included as would any # comment line. Note that the optional "Extra" string in the $ start line is not included. The idea is to check correct transmission while avoiding sensitivity to gateways or processing that might change the line terminator sequence, convert tabs to spaces, or the like. 2.7 Example Messages Simple message from a client: $$-CyberCash-0.8-$$ id: DONALD-69 transaction: 918273645 date: 199512250102 cyberkey:CC1001 opaque: GpOJvDpLH62z+eZlbVkhZJXtTneZH32Qj4T4IwJqv6kjAeMRZw6nR4f0OhvbTFfPm+GG aXmoxyUlwVnFkYcOyTbSOidqrwOjnAwLEVGJ/wa4ciKKI2PsNPA4sThpV2leFp2Vmkm4 elmZdS0Qe350g6OPrkC7TKpqQKHjzczRRytWbFvE+zSi44wMF/ngzmiVsUCW01FXc8T9 EB8KjHEzVSRfZDn+lP/c1nTLTwPrQ0DYiN1lGy9nwM1ImXifijHR19LZIHlRXy8= $$-End-CyberCash-End-jkn38fD3+/DFDF3434mn10==-$$ Message from a merchant: $$-CyberCash-a.b.c-extra-$$ merchant-ccid: acme-69 merchant-date: 19951231115959 merchant-transaction: 987654321 label: value labelx: multiple line value... # comment # another comment line label; text with a real multi-line format ! merchant-cyberkey: CC1001 merchant-opaque: Eastlake, et al Informational [Page 11]
RFC 1898 CyberCash Version 0.8 February 1996 C1Q96lU7n9snKN5nv+1SWpDZumJPJY+QNXGAm3SPgB/dlXlTDHwYJ4HDWKZMat+VIJ8y /iomz6/+LgX+Dn0smoAge7W+ESJ6d6Ge3kRAQKVCSpbOVLXF6E7mshlyXgQYmtwIVN2J 66fJMQpo31ErrdPVdtq6MufynN8rJyJtu8xSNolXlqIYNQy5G2I3XCc6D3UnSErPx1VJ 6cbwjLuIHHv58Nk+xxt/FyW7yAMwUb9YNcmOj//6Ru0NiOA9P/IiWczDe2mJRK1uqVpC sDrWehG/UbFTPD26trlYRnnY $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ 3. Signatures and Hashes Inbound CyberCash request messages normally have a signature, as described below, of all of the messages fields outside of the signature. This signature is transmitted inside the opaque part of the message. It enables the server to authenticate the source of the message. Messages from a merchant to a client initiating a purchase sequence have fields signed by the merchant. These fields and this signature are included by the client in the opaque part of their card purchase message to the merchant so that, when all is passed on to the server, it can verify that the client saw the information the merchant intended. More information on CyberCash signatures and the hash codes they are based on, is given below. 3.1 Digital Signatures Digital signatures are a means of authenticating information. In CyberCash messages, they are calculated by first taking the hash of the data to be authenticated, as described below, and then encoding the hash using an RSA private key. Anyone possessing the corresponding public key can then decrypt the hash and compare it with the message hash. If they match, then you can be sure that the signature was generated by someone possessing the private key which corresponded with the public key you used and that the message was not tampered with. In the CyberCash system, clients, merchants, and the server have public-private key pairs. By keeping the private key secret and registering their public key with the server (for a merchant or client) or publishing their public key or keys (for the server), they can provide high quality authentication by signing parts of messages. An RSA digital signature is approximately the size of the modulus used. For example, if that is 768 bits long, then the binary digital signature would be 768 bits or 96 bytes long and its base 64 encoding would be 128 bytes. Eastlake, et al Informational [Page 12]
RFC 1898 CyberCash Version 0.8 February 1996 3.2 Hash Codes The hashes used in CyberCash messages are message digests. That is, a non-invertable fingerprint of a message such that it is computationally infeasible to find an alternate message with the same hash. Thus the relatively small hash can be used to secure a larger message. If you are confident in the authenticity of the hash and are presented with a message which matches the hash, you can be sure it is the original message, at least as regards all aspects that have been included in the hash. The hash is calculated using the MD5 algorithm (see RFC 1321) on a synthetic message. The synthetic message is composed of the labels and values specified in a list for the particular hash. Since the hash is input order dependent, it is essential that the label-value pairs be assembled in the order specified. In some cases, a range of matching labels is specified. For example, "card*" to match card- number, card-expiration-date, and all other labels starting with "card". In such cases, all existing matching labels are used in ascending alphabetic order by ASCII character code. If a label is specified in a signature list but is not present in the label-value data on which the hash is being calculated, it is not included in the hash at all. That is, even the label and label terminator are omitted from the synthetic message. Before being hashed, the text of the synthetic message is processed to remove all "white space" characters. White space characters are defined as any with an ASCII value of 32 (space) or less or 127 (rubout) or greater. Thus all forms of new-line/carriage-return and distinctions such as blank lines, trailing spaces, replacement of a horizontal tab character by multiple spaces, etc., are ignored for hash purposes. MD5 hashes are 16 bytes long. This means that the base 64 encoding of such a hash will be 24 characters (of which the last two will always be padding equal signs). 4. Specific Message Formats This section describes the formats of the Verison 0.8 CyberCash messages by example with comments. The reader in assumed to be familiar with terms such as "acquirer", "PAN" (primary account number), etc., defined in ISO 8583, and currency designations as defined in ISO 4217. A few fields not relevant to current operations have been removed to simplify this exposition. Eastlake, et al Informational [Page 13]
RFC 1898 CyberCash Version 0.8 February 1996 In the following example messages, signatures, hashes, and encrypted sections are fake nonsense text and ids are fictitious. 4.1 Persona Registration and Application Retrieval The first step in customer use of CyberCash is registering a persona using the customer application. This is done with the R1 message defined below. The CyberCash server responds with the R2 message. When the customer application learns that it is out of date, it can use the GA1 request message to the server and its GA2 response to download a new signed version of itself. 4.1.1 R1 - registration Description: This is the initial message sent to create a new CyberCash persona. ##################################################################### Sender: CyberApp Receiver: CyberServer ##################################################################### Sample Message: $$-CyberCash-0.8-$$ transaction: 123123213 date: 19950121100505.nnn cyberkey: CC1001 opaque: FrYOQrD16lEfrvkrqGWkajM1IZOsLbcouB43A4HzIpV3/EBQM5WzkRJGzYPM1r3noBUc MJ4zvpG0xlroY1de6DccwO9j/0aAZgDi9bcQWV4PFLjsN604j3qxWdYn9evIGQGbqGjF vn1qI1Ckrz/4/eT1oRkBBILbrWsuwTltFd84plvTy+bo5WE3WnhVKsCUJAlkKpXMaX73 JRPoOEVQ3YEmhmD8itutafqvC90atX7ErkfUGDNqcB9iViRQ7HSvGDnKwaihRyfirkgN +lhOg6xSEw2AmYlNiFL5d/Us9eNG8cZM5peTow== $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ ##################################################################### Opaque Key: Generated using CyberCash encrypting public key identified in CyberKey. ##################################################################### Opaque Section Contents: type: registration swversion: 0.8win content-language: en-us requested-id: MyRequestedCCID Eastlake, et al Informational [Page 14]
RFC 1898 CyberCash Version 0.8 February 1996 email: myemail@myemailhost.com pubkey: 0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94 signature: v6JGmxIwRiB6iXUK7XAIiHZRQsZwkbLV0L0OpVEvan9l59hVJ3nia/cZc/r5arkLIYEU dw6Uj/R4Z7ZdqO/fZZHldpd9+XPaqNHw/y8Arih6VbwrO5pKerLQfuuPbIom ##################################################################### signature is of the following fields: transaction, date, cyberkey, type, swversion, content-language, requested-id, email, pubkey ##################################################################### Explanation: content-language is taken from the MIME header field (see RFC1766) and is the language text messages should be generated in. (only en-us implemented at this time. swversion used to check if client application is old. 4.1.2 R2 - registration-response Description: This message gives the success/failure response to R1. ##################################################################### Sender: CyberServer Receiver: CyberApp ##################################################################### Sample Message: $$-CyberCash-0.8-$$ transaction: 12312313 date: 19950121100505.nnn opaque: r1XfjSQt+KJYUVOGU60r7voFrm55A8fP5DjJZuPzWdPQjGBIu3B6Geya8AlJfHsW11u8 dIv1yQeeYj/+l9TD1dXW21/1cUDFFK++J2gUMVv8mX1Z6Mi4OU8AfsgoCliwSkWmjSOb kE62sAlZTnw998cKzMFp70TSlI3PEBtvIfpLq5lDCNbWidX8vFZV0ENUmMQ9DTP3du9w fsFGvz1mvtHLT/Gj8GNQRYKF4xiyx4HYzTkSMhgU5B/QDLPS/SawIJuR86b9X0mwsr0a gbGTzECPJTiKkrhxxMG/eymptsVQSLqNaTCx6w== $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ ##################################################################### Opaque Key: Same as session key for R1 for same Transaction and connection (there may be no ID!). ##################################################################### Opaque Section Contents: Eastlake, et al Informational [Page 15]
RFC 1898 CyberCash Version 0.8 February 1996 type: registration-response server-date: 19950121100506.nnn requested-id: MyRequestedCCID response-id: CyberCashHandle email: myemail@myemailhost.com response-code: success/failure/etc. pubkey: 0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94 swseverity: fatal/warning [absent if ok] swmessage; Tells CyberApp that it is obsolete. Display this text to the user. [only present if SWSeverity present] message; Free text of the error/success condition. This text is to be displayed to the person by the CyberCash application... In general this includes: duplicate-id, bad-signature, or ill-formed-registration ##################################################################### Signature is of the following fields: no-signature ##################################################################### Explanation: responseid is used to suggest a unique ID if the failure was due to the requested ID being already in use... If the reason fo failure was not due to duplicate ID then this field may be omitted. responseid gives the actual ID with check characters appended if success. swseverity can warn user of old client application or indicate failure due to old or known buggy version. 4.1.3 GA1 - get-application Description: Used by CyberApp to get an updated version. ##################################################################### Sender: CyberApp Receiver: CyberServer ##################################################################### Sample Message: $$-CyberCash-0.8-$$ transaction: 123123213 date: 19950121100505.nnn Eastlake, et al Informational [Page 16]
RFC 1898 CyberCash Version 0.8 February 1996
RFC 1898 CyberCash Version 0.8 February 1996 card-name: John Q. Public expiration-date: 01/99 merchant-swseverity: fatal/warning merchant-swmessage; Message for merchant about out of date protocol number in $$ start line of merchant message. merchant-message; Free text of the error/success condition. This text is for the merchant from the server... id: myCyberCashID transaction: 78784567 date: 19950121100505.nnn ##################################################################### Signature is of the following fields: no signature. ##################################################################### Explanation: This normally returns selected fields from the decoding of the opaque part of a CH1 as sent to the server in a CD1. 4.5 Utility and Error Messges A number of utility, status query, and special error reporting messages have also been found necessary in implementing the CyberCash system. It is desirable to be able to test connectivity, roughly synchronize clocks, and get an initial determination of what client protocol and software versions are accepted. This is done via the P1 client to server message and its P2 server to client response. Clients need to be able to determine the status of earlier transactions when the client or merchant has crashed during or has suffered data loss since the transaction. Two transaction query messages are defined, TQ1 and TQ2. One just queries and the other also cancels the transaction, if it has not yet completed. The response to both of these messages is a TQ3 response from the server. Since the system operates in a query response mode, there are two cases where special error messages are needed. If a query seems to be of an undeterminable or unknown type, the UNK1 response error message is sent. If a response seems to be of an undeterminable or unknown type or other serious error conditions occur at the client or merchant which should be logged at the CyberCash server, the DL1 or DL2 diagnostic log message is submitted by the client or merchant in question respectively. Eastlake, et al Informational [Page 38]
RFC 1898 CyberCash Version 0.8 February 1996 4.5.1 P1 - ping Description: Very light weight check that we have connectivity from the customer to the server. Does no crypto to minimize overhead. ##################################################################### Sender: CyberApp Receiver: CyberServer ##################################################################### Sample Message: $$-CyberCash-0.8-$$ type: ping id: myCyberCashID [optional] transaction: 123123213 date: 19950121100505.nnn $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ ##################################################################### Explanation: id optional as persona may not have been set up yet. 4.5.2 P2 - ping-response Description: Response to the P1 light weight ping. Does no crypto to minimize overhead. ##################################################################### Sender: CyberServer Receiver: CyberApp ##################################################################### Sample Message: $$-CyberCash-0.8-$$ type: ping-response id: myCyberCashID [if present in P1] transaction: 12312313 date: 19950121100505.nnn server-date: 19950121100506.nnn swseverity: fatal/warning [absent if ok] swmessage; Tells CyberApp that it is using an obsolete protocol. Display this text to the user. [only present if SWSeverity present] response-code: success/failure/etc. message; Free text of the error/success condition. This text is to be displayed to the sender Eastlake, et al Informational [Page 39]
RFC 1898 CyberCash Version 0.8 February 1996 by their CyberCash application... supported-versions: 08.win, 0.81win, 0.8mac $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ ##################################################################### Explanation: swversion does not appear in P1 for security reasons so swseverity and swmessage appear only if the server can tell that things are old from the $$ header protocol version. supported-versions lets client know as soon as possible what versions are supported and, by implication, which are not. Does not compromise security by having client say what version it is. 4.5.3 TQ1 - transaction-query Description: Client query to server for Transaction status. ##################################################################### Sender: CyberApp Receiver: CyberServer ##################################################################### Sample Message: $$-CyberCash-0.8-$$ id: MyCyberCashID date: 19950121100505.nnn transaction: 12312314 cyberkey: CC1001 opaque: VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl 21QQaHkaE3geccRk03cqFYoLNRCclImcsyeIZCgVt+2dJTj1V+E7R7ePQtCj+0gY42+V L5BWhVtmDQFyg1DdJ6n3S/er6ZuObAjpcAogG+T1Na5dJmrTA1wRMiYVkqhXi2KMYdur 3U47P8ZGUza7W0MST3DgvviN0kVhtmHEnm515mo6NTQdfdxw9WZpy6vMqrBGk2nTgi2c bnf+muO0+kiNPXVvEzRrO8o= $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ ##################################################################### Opaque Key: generated from CyberCash encryption key identified in CyberKey ##################################################################### Opaque Section Contents: type: transaction-query swversion: 0.8win begin-transaction: 1234 Eastlake, et al Informational [Page 40]
RFC 1898 CyberCash Version 0.8 February 1996 end-transaction: 4321 signature: jJfFsKvOxLaV87gxu7lIPet3wIDwh1H2F61reYC9jmUrS6WAtUVFG9aCNuTEBoMixF0X vD5oPfyheJRIlnL6i0c4o/bfyO3edKAacmWjTmKt6/4y9p3qgvKkSX8r9aym ##################################################################### signature is of the following fields: id, date, transaction, cyberkey, type, swversion, begin-transaction, end-transaction ##################################################################### Explanation: This is a client status query of a previous transaction or transactions. begin-transaction and end-transaction can be the same. 4.5.4 TQ2 - transaction-cancel Description: Client query to server for Transaction cancellation/status. ##################################################################### Sender: CyberApp Receiver: CyberServer ##################################################################### Sample Message: $$-CyberCash-0.8-$$ id: MyCyberCashID date: 19950121100505.nnn transaction: 12312314 cyberkey: CC1001 opaque: VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl 21QQaHkaE3geccRk03cqFYoLNRCclImcsyeIZCgVt+2dJTj1V+E7R7ePQtCj+0gY42+V L5BWhVtmDQFyg1DdJ6n3S/er6ZuObAjpcAogG+T1Na5dJmrTA1wRMiYVkqhXi2KMYdur 3U47P8ZGUza7W0MST3DgvviN0kVhtmHEnm515mo6NTQdfdxw9WZpy6vMqrBGk2nTgi2c bnf+muO0+kiNPXVvEzRrO8o= $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ ##################################################################### Opaque Key: generated from CyberCash encryption key identified in CyberKey ##################################################################### Opaque Section Contents: Eastlake, et al Informational [Page 41]
RFC 1898 CyberCash Version 0.8 February 1996 type: transaction-cancel swversion: 0.8win begin-transaction: 1234 end-transaction: 4321 signature: kD7DEav2uLQIYMtP9gbhYaBUpB2a5whNwnK2eXbbyTCf56F6dl3DIVf7D8Z4WxbY2YZn ByRIKeqlhmss7fbdnBiDYmKfOuc+I4bi/Oslml5riaciQhTd2JdHG+PCcHwZ ##################################################################### signature is of the following fields: id, date, transaction, cyberkey, type, swversion, begin-transaction, end-transaction ##################################################################### Explanation: This is a client attempt to cancel a previous transaction or transactions. begin-transaction and end-transaction can be the same. The transaction-cancel transaction (TQ.2) is defined between the client and the server. This transaction permits the client to query the status of an operation and to stop the operation from occurring if it has not already occurred. 4.5.5 TQ3 - transaction-response Description: Reports generated by a TQ1 or TQ2 ##################################################################### Sender: CyberServer Receiver: CyberApp ##################################################################### Sample Message: $$-CyberCash-0.8-$$ id: mycybercashid date: 19950121100505.nnn transaction: 12312314 server-date: 19950121100505.nnn opaque: eFXRL+H0J5q318M21wRdtcbhu9WCyLysQkeF9oIcjtbstymx343bbt0EAtU1gcJaUKJZ 3skgvwrhcxU4bFcE68OPlUXAvLq10I3MczPYPsiGrsU0K4bZtQvDZmn727QQAfONBm5s s1yjIha+Fj481BJQs0CTYc3ju90lAjCYgirXtnnR6yJXoDO75b7UjthvHSnrTWVZvktX PvTuUCYzbXSFoYvwFM3Y+yHqSHlmWutYKQpYze8zbUSDQfmwTCJyw3aY2JasZ+xMP/CD JWbCA+gCLBYCnvzM/ExKTZTFD3xr5JBfNbV4p6CiK6lsfRFD7maAK6TSVnWjwCEJNpOv fyllfWD04fT7LINQcjJiQK1Pk/912Tk6Q35eRaQZorwv2hnY/7By2OkPyFdAqFL+D0H6 TqzxmdEjEFKxi/PPT1+Cs/Nszy8wZzaGg8iWATfARY6stl+02dDhwOoFXSBNvchlVrcI IlvhumSIQs29Pntj3DbkYo4IEmmN/qi1vnzld22q7lA1q/CQakyc7jlQUFISx76buqwy Eastlake, et al Informational [Page 42]
RFC 1898 CyberCash Version 0.8 February 1996 35XiC9Yn8flE4Va14UxMf2RCR1B/XoV6AEd64KwPeCYyOYvwbRcYpRMBXFLyYgWM+ME1 +yp7c66SrCBhW4Q8AJYQ+5j5uyO7uKyyq7OhrV0IMpRDPjiQXZMooLZOifJPmpvJ66hC VZuWMuA6LR+TJzWUm4sUP9Zb6zMQShedUyOPrtw1vkJXU1vZ5aI8OJAgUcLEitcD+dsY Df4CzA00fC10POkJ58HZB/pSBfUrHAa+IqMHyZkV/HBi9TjTwmktJi+8T9orXS0jSvor dMTGWn0ifETy2VXt $$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$ ##################################################################### Opaque Key: Session key from TQ1/TQ2 with same Transaction and ID. ##################################################################### Opaque Section Contents: type: transaction-response response-code: success/failure/etc. message; general free form text message from server to customer.... swseverity: fatal/warning swmessage; Message indicating that CyberApp software is obsolete. May be multiple lines. report-fee: usd 0.15 [if non-zero] transaction-1: old-transaction-number transaction-status-1: success/failure/pending/cancelled/etc. server-date-1: 19951212125959.nnn date-1: 19950121100505.nnn type-1: auth-only/etc. ##################################################################### Signature is of the following fields: no signature ##################################################################### Explanation: Report-fee is the notification that this report cost a fee and is only present if there is a fee. There can be multiple transaction for the same transaction number as there could have been a auth, post-auth-capture, void, etc. Terms "original transaction" refers to the payment or other transaction that is being queried or canceled. Note: this transaction may not actually reside at the server. "request" refers to the requesting TQ.2 or TQ.1 message id: id from the request message date: date from the request message transaction: transaction from the request message Eastlake, et al Informational [Page 43]
RFC 1898 CyberCash Version 0.8 February 1996 server-date: current date/time type: transaction-response response-code: response code for request message, can be one of: "success" means the request message was processed. Does not imply query or cancellation status of the request. "failure-hard" means that the request message was not processed due to being ill-formed or otherwise inoperable. "failure-swversion" means that the request message was not processed due to software revision problems. message: the message applies only to the TQ transaction, not to the status of the transactions being queried or canceled. The message is provided according to the response-code as: "success" - message is omitted. "failure-hard" - use standard hard failure message. "failure-swversion" - use standard swversion message for fatal swseverity: applies to request message swmessage: applies to request message -- per query/cancel fields ('N' is a series from 1 to N) -- transaction-N: transaction number of original transaction, or if the original transaction is not present in server the transaction number that the query / cancel request refers to transaction-status-N: status of original transaction, may be one of: "success" the original transaction was successfully processed. If request was TQ.2, cancellation is not performed. "failure" the original transaction was not successfully processed. If request was TQ.2, cancellation is not performed (however, there is nothing to cancel, so it's all the same to the customer app). "pending" the original transaction is still being processed and final disposition is not known. "canceled" the original transaction has been canceled by the server. Later arrival of the original transaction will not be processed, but will be returned with a "failure-canceled" returned. server-date-1: server-date field from original transaction or omitted if original transaction is not present in the server" date-1: date field from original transaction or omitted if original transaction is not present in the server" type-1: type field from original transaction or omitted if original transaction is not present in the server" 4.5.6 UNK1 - unknown-error Description: This is the response sent when the request is so bad off you can't determine what type it is or the type is unknown to you. Sent from Merchant to Client or from Server to Merchant or from Server to Client. Eastlake, et al Informational [Page 44]
RFC 1898 CyberCash Version 0.8 February 1996 ##################################################################### Sender: MerchantApp or CyberServer Receiver: CyberApp or MerchantApp ##################################################################### Sample Message: $$-CyberCash-0.8-$$ type: unknown-error unknown-error-message: Text message of error condition to display to user. (CyberCash wrapper not found, wrapper integrity check fails, unknown protocol version specified, unknown type specified, etc.) { server-date: 19950121100506.nnn [if sent by server] } or { merchant-date: 19950121100506.nnn [if sent by merchant] } x-id: mycybercashID x-transaction: 123123213 x-date: 19950121100505.nnn x-cyberkey: CC1001 x-opaque: 2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G 9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7 TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw 5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$ ##################################################################### Opaque Key: see explanation ##################################################################### Opaque Section Contents: see explanation ##################################################################### Signature is of the following fields: see explanation ##################################################################### Explanation: This message is sent as a response when you can't find or understand even the type of a message to you. It will always have type and unknown-error-message fields at the beginning. Any fields from the request that are parseable are simply echoed back in the UNK1 Eastlake, et al Informational [Page 45]
RFC 1898 CyberCash Version 0.8 February 1996 message with "x-" prefixed to it. Thus, if an x-opaque appears, it was whatever the opaque was in the original request, etc. If you can decrypt the opaque section, you don't want to put the results here in the clear! {}'s in the first column are to group alternatives only and do not appear in the message. Since the customer originates exchanges with merchant and server and merchant originates exchanges with server, this message will only be emitted from the merchant to the customer or the server to the customer or merchant. It should generally just be logged for debugging purposes. You may need to watch out for denial of service via forged or replayed UNK1 messages. 4.5.7 DL1 - diagnostic-log Description: Client diagnostic log of bad message from either merchant or server. ##################################################################### Sender: CyberApp Receiver: CyberServer ##################################################################### Sample Message: $$-CyberCash-0.8-$$ id: MyCyberCashID date: 19950121100505.nnn transaction: 1234 cyberkey: CC1001 opaque: 2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G 9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7 TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw 5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ ##################################################################### Opaque Key: generated from CyberCash encryption key identified in CyberKey ##################################################################### Opaque Section Contents: Eastlake, et al Informational [Page 46]
RFC 1898 CyberCash Version 0.8 February 1996 type: diagnostic-log message: incorrect order-id swversion: 0.8win x-type: original-message-type x-transaction: original-transaction-number x-opaque: [if can't decrypt] 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw ##################################################################### Explanation: Client application does not expect a response for this message. The decrypted original message will be in the opaque section unless decryption fails. If decryption fails then un-decrypted opaque in the original will be sent. This message will be sent to a different script or socket or host than normal messages so that it will just be absorbed and never generate an UNK1 response or anything, even if this message itself is screwed up. 4.5.8 DL2 - merchant-diagnostic-log Description: Merchant diagnostic log of bad message from server. ##################################################################### Sender: CyberMerchant Receiver: CyberServer ##################################################################### Sample Message: $$-CyberCash-0.8-$$ merchant-ccid: MyCyberCashID merchant-transaction: 1234 merchant-date: 19950121100505.nnn merchant-cyberkey: CC1001 merchant-opaque: 2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G 9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7 TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw 5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW $$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$ ##################################################################### Eastlake, et al Informational [Page 47]
RFC 1898 CyberCash Version 0.8 February 1996 Opaque Key: generated from CyberCash encryption key identified in CyberKey ##################################################################### Opaque Section Contents: type: merchant-diagnostic-log server-date: 19950121100505.nnn [optional] message: incorrect order-id x-type: original-message-type x-transaction: original-transaction-number x-opaque: [if can't decrypt] 9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3 5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw ##################################################################### Explanation: Merchant application does not expect a response for this message. The decrypted original message will be in the opaque section unless decryption fails. If decryption fails then un-decrypted message will be sent. This message will be sent to a different script or socket or host than normal messages so that it will just be absorbed and never generate an UNK1 response or anything even if this message itself is screwed up. 4.6 Table of Messages Described The following 31 messages are described in this document. C = Customer App, M = Merchant App, S = CyberCash Server FLOW SECTION NAME C->S 4.2.1 BC.1 bind-credit-card S->C 4.2.2 BC.4 bind-credit-card-response C->M 4.3.2 CH.1 credit-card-payment M->C 4.3.3 CH.2 credit-card-response M->S 4.4.8 CD.1 card-data-request S->M 4.4.9 CD.2 card-data-response M->S 4.4.1 CM.1 auth-only M->S 4.4.2 CM.2 auth-capture M->S 4.4.3 CM.3 post-auth-capture Eastlake, et al Informational [Page 48]
RFC 1898 CyberCash Version 0.8 February 1996 M->S 4.4.4 CM.4 void M->S 4.4.5 CM.5 return S->M 4.4.6 CM.6 charge-action-response C->S 4.5.7 DL.1 diagnostic-log M->S 4.5.7 DL.2 merchant-diagnostic-log C->S 4.1.3 GA.1 get-application S->C 4.1.4 GA.2 get-application-response M->S 4.4.7 MM.1 merchant-auth-only M->S 4.4.7 MM.2 merchant-auth-capture M->S 4.4.7 MM.3 merchant-post-auth-capture M->S 4.4.7 MM.4 merchant-void M->S 4.4.7 MM.5 merchant-return S->M 4.4.7 MM.6 merchant-charge-action-response C->S 4.5.1 P.1 ping S->C 4.5.2 P.2 ping-response M->C 4.3.1 PR.1 payment-request C->S 4.1.1 R.1 registration S->C 4.1.2 R.2 registration-response C->S 4.5.3 TQ.1 transaction-query C->S 4.5.4 TQ.2 transaction-cancel S->C 4.5.5 TQ.3 transaction-response S->C, S->M, M->C 4.5.6 UNK.1 unknown-error 5. Future Development CyberCash is extending the facilities available through the CyberCash system. We are committed to implementing a full cash system, including efficient transfer of small amounts of money, the extension of the credit card system to handle terminal capture and clearances, and other improvements. 5.1 The Credit Card Authorization/Clearance Process There are six steps in credit card processing as listed below. The first four are always involved if a transacation is completed. The fifth and sixth are optional. (1) authorization: merchant contacts their acquiring back which normally contacts the card issung bank and returns to the merchant an approval/guarantee or a disapproval. This Eastlake, et al Informational [Page 49]
RFC 1898 CyberCash Version 0.8 February 1996 temporarily decreases the available credit on the card. (2) capture: the charge information for a purchase is entered by the merchant into a batch. (3) clearance: a batch of items is processed. This actually causes the items in the batch to appear on credit card statements as sent by the issuing bank to its carholders. (4) settlement: the actual interbank transfer of net funds. (5) void: the merchant undoes step 2 (or 6) and causes a charge (or credit) to be removed from a batch. Must be done before the batch is processed. (6) credit: the merchant causes a "negative charge" or credit to be entered into a batch. This will appear on the cardholders statement. The fourth step, settlement, is entirely within the banking community and does not concern us here. CyberCash 0.8 provides messages to do 1, 1&2, 2, 5, and 6. This is adequate for credit card processor systems where the batch is accumulated at the bank or between the bank and the merchant. CyberCash 0.8 supports such "host capture" systems. Other credit card processor systems require the merchant to accumulate the batch. Such systems are frequently referred to as "terminal capture". This makes actions 2, 5, and 6 internal to the merchant but requires messages to perform action 3. Such batch clearance messages will be included in future versions of the CyberCash merchant and server software. 5.2 Lessons Learned The continuing rapid development of the CyberCash system is an interesting experience. The system must deal with many existing browsers and legacy banking systems. Existing credit card processors that convey transactions to acquiring banks have complex and varied interfaces. The sophistication of security attacks on the Internet is growing rapidly. In the face of such a rapidly changing environment, it was essential to adopt a general message framework so that messages and fields could be added as they were found necessary. Any attempt to reduce the system to a small number of perfectly opimized messages in advance would have doomed the system to failure. (As of mid-October 1995, the total number of CyberCash messages defined, including those planned for cash and microcash, enhancements to the credit card system, and some old messages being phased out in favor of improved replacements, is just over a hundred.) Flexible operational and error handing facilities are also, as usual, the bulk of the system. Version numbering and tracking has proved to be quite important and merchant versioning is being added. Eastlake, et al Informational [Page 50]
RFC 1898 CyberCash Version 0.8 February 1996 Use of text for messages has proven very beneficial. This makes it possible to easily deal with messages using common everyday tools such as text editors and spead sheets. Use of binary TLV (type, length, value) encoding or the like is certainly possible but imposes a significantly higher level of complexity on every tool that has to deal with the messages. Encryption and decryption impose some difficulties in development. Any confusion about decryption keys or algorithms will render encrypted material meaningless and tools are needed to provide decyrption for debugging outside of normal program operation. But this pales compared with the stringencies imposed by signatures. All parts of the system must have absolutely identical ideas as to the exact bit patterns to be hashed or signed and their exact order. Seemingly trivial differences in capitalization, punctuation, framing, order, or the like, in addition to any disagreement about keys or algorithms, will lead to frustrating failures of signatures to match. Passing signatures through an intermediate system and checking them at a third system, as is done when a customer's signature is passed through a merchant and checked at the CyberCash server, compounds the problem. 6. Security Considerations The CyberCash Version 0.8 Credit Card system provides substantial protection to payment messages as described above in sections 1.2, 2.2.4, and 2.2.5. However, it provides no privacy to the shopping interaction which is essentially outside of its purview. It also provides no protection against dishonest merchants other than those normally available with credit card purchases. Care must be taken to avoid loss of control of the machines on which parts of this system runs or security may be compromised. Current credit card dispute resolution systems require deliberate bypasses be implemented for some of the security normally established by CyberCash as described in section 3.4. References [ISO 4217] - Codes for the representation of currencies and funds [ISO 8583] - Financial transaction card originated messages - Interchange message specifications, 1993-12-15. [RFC 822] - Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, UDEL, August 1982. Eastlake, et al Informational [Page 51]
RFC 1898 CyberCash Version 0.8 February 1996 [RFC 1521] - Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993. [RFC 1766] - Alvestrand, H., "Tags for the Identification of Languages", UNINETT, March 1995.



Back to RFC index

 

Associates:

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""