CyberCash Credit Card Protocol Version 0.8
draft-eastlake-cybercash-v08-00
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 1898.
|
|
|---|---|---|---|
| Authors | Lt. Col. Brian P. Boesch , Donald E. Eastlake 3rd , Magdalena Yesil , Steve Crocker | ||
| Last updated | 2013-03-02 (Latest revision 1995-07-10) | ||
| RFC stream | Legacy stream | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Legacy state | (None) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Became RFC 1898 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-eastlake-cybercash-v08-00
INTERNET-DRAFT Donald E. Eastlake 3rd
Expires: 7 January 1996 CyberCash
Brian Boesch
CyberCash
Steve Crocker
CyberCash
Magdalena Yesil
CyberCash
8 July 1995
CyberCash Credit Card Protocol Version 0.8
--------- ------ ---- -------- ------- ---
Status of This Document
This draft, file name draft-eastlake-cybercash-v08-00.txt, is intended
to be become an Informational RFC. Distribution of this document is
unlimited. It does not specify a standard but is intended for the
information of the Internet community. Comments should be sent to
dee@cybercash.com.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu,
munnari.oz.au, or ftp.is.co.za.
Eastlake, Boesch, Crocker, Yesil [Page 1]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
Abstract
CyberCash is developing a general payments system for use over the
Internet. The structure and communications protocols of version 0.8
are described. This version includes credit card payments only.
Additional capabilities are planned for future versions.
This document covers only the current CyberCash system which is one
of a few operational systems in the rapidly evolving area of Internet
payments. CyberCash is committed to the further development of its
system and to cooperation with the Internet Engineering Task Force
and other standards organizations.
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, Fred Silverman, Bruce Wilson,
Garland Wong, Wei Wu, Mark Zalewski.
Eastlake, Boesch, Crocker, Yesil [Page 2]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Acknowledgements...........................................2
Table of Contents..........................................3
1. Overall System..........................................5
1.1 System Overview........................................5
1.2 Security Approach......................................6
1.2.1 Authentication and Persona Identity..................6
1.2.2 Privacy..............................................7
1.3 Credit Card Operation..................................7
2. General Message Wrapper Format..........................9
2.1 Message Format.........................................9
2.1 Details of Format......................................9
2.2 Body Parts............................................10
2.3 Transparent Part......................................11
2.4 Opaque Part...........................................11
2.5 Trailer...............................................12
2.6 Example Messages......................................12
3. Signatures and Hashes..................................14
3.1 Digital Signatures....................................14
3.2 Hash Codes............................................14
4. Specific Message Formats...............................16
4.1 Persona Registration and Application Retrieval........16
4.1.1 R1 - registration...................................16
4.1.2 R2 - registration-response..........................17
4.1.3 GA1 - get-application...............................18
4.1.4 GA2 - get-application-response......................19
4.2 Binding Credit Cards..................................20
4.2.1 BC1 - bind-credit-card..............................20
4.2.2 BC4 - bind-credit-card-response.....................22
4.3 Customer Credit Card Purchasing Messages..............23
4.3.1 PR1 - payment-request...............................23
4.3.2 CH1 - credit-card-payment...........................25
4.3.3 CH2 - charge-card-response..........................26
4.4 Merchant Credit Card Purchasing Messages..............27
4.4.1 CM1 - auth-only.....................................28
4.4.2 CM2 - auth-capture..................................30
3.4.3 CM3 - post-auth-capture.............................30
4.4.4 CM4 - void..........................................32
4.4.5 CM5 - return........................................33
4.4.6 CM6 - charge-action-response........................34
4.4.7 The MM* Message Series..............................36
Eastlake, Boesch, Crocker, Yesil [Page 3]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
4.4.8 CD1 - card-data-request.............................36
4.4.9 CD2 - card-data-response............................38
4.5 Utility and Error Messges.............................39
4.5.1 P1 - ping...........................................40
4.5.2 P2 - ping-response..................................40
4.5.3 TQ1 - transaction-query.............................41
4.5.4 TQ2 - transaction-cancel............................42
4.5.5 TQ3 - transaction-response..........................43
4.5.6 UNK1 - unknown-error................................45
4.5.7 DL1 - diagnostic-log................................47
4.5.8 DL2 - merchant-diagnostic-log.......................48
4.6 Table of Messages Described...........................49
5. Future Development.....................................51
6. Security Considerations................................52
References................................................52
Authors Addresses.........................................53
Expiration and File Name..................................53
Eastlake, Boesch, Crocker, Yesil [Page 4]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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 Q much as it is the
real world of commerce Q 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.
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 settlement transactions through
the entire system. The consumer need only initiate payment for each
transaction by exercising the pay option on a CyberCash 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
Eastlake, Boesch, Crocker, Yesil [Page 5]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
the transaction is not visible to the merchant.
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
determined 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 IDUs 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 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 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
Eastlake, Boesch, Crocker, Yesil [Page 6]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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
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. Particularly
sensitive information, such as PIN numbers, will be superencrypted
(i.e., encrypted more than one level) and handled 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 simple selecting from a list of credit cards he
has registered to his CyberCash persona. All this information is
digitally signed by the customer, encrypted, and passed, along with a
hash code of the invoice as seen by the customer, to the merchant.
(See CH1 message.)
Eastlake, Boesch, Crocker, Yesil [Page 7]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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 message.) 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
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 bankUs 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.
Eastlake, Boesch, Crocker, Yesil [Page 8]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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 - contains the financial information in the message
and is both privacy protected as well as tamper protected. The opaque
part is not present in some messages. When present, the opaque part
also 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.
2.1 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-$$
Eastlake, Boesch, Crocker, Yesil [Page 9]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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.
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.2 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
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
Eastlake, Boesch, Crocker, Yesil [Page 10]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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.3 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 parts. It always includes a transaction
field which is the transaction number generated by the requester and
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 requesters persona ID.
2.4 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.
On messages inbound to the server, the data to be opaqued is
encrypted under a random session key and then that DES key is RSA
encrypted under one of the server's public keys. The corresponding
outbound reply can simply be DES encrypted under this session key as
there is enough plain text information to identify the session and
the customer or merchant will have remembered the session key from
the inbound message.
Eastlake, Boesch, Crocker, Yesil [Page 11]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
2.5 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.
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.6 Example Messages
Simple message from a client:
$$-CyberCash-0.8-$$
id: DONALD-69
transaction: 918273645
date: 199512250102
opaque:
ABCEDSUDSAKJDSALKJSALKJSADLKASJASDJIIClaksdjiLADjlasdji34
DAJKASLKDJIWalkdlakdlakLAKsdalkjdlKaldjlakdakjakldskajlkj
adsjlsdkdlaskdjaksldjalksjdlsakdjlsakjdlkjskalkjalsdjlkjj
alkjda=
$$-End-CyberCash-End-jkn38fD3+/DFDF3434mn10==-$$
Eastlake, Boesch, Crocker, Yesil [Page 12]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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-opaque: ABCEDSUDSA+/KJDSALKJSALKJSADLKASJASDJIICla
DAJKASLKDJIWalkdlakdlakLAKsdalkjdlKaldjlakdakjakldskajlkj
adsjlsdkdlaskdjaksldjalksjdlsakdjlsakjdlkjskalkjalsdjlkjj
alkjda=
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
Eastlake, Boesch, Crocker, Yesil [Page 13]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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.
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
Eastlake, Boesch, Crocker, Yesil [Page 14]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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, Rcard*S to match card-
number, card-expiration-date, and all other labels starting with
RcardS. 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 Rwhite spaceS characters. White space characters are
defined as any with an ASCII value of 32 (space) or less. 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).
Eastlake, Boesch, Crocker, Yesil [Page 15]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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.
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:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7n4
3ard3Q==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Eastlake, Boesch, Crocker, Yesil [Page 16]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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
email: myemail@myemailhost.com
pubkey: aslfjflasdflasj;lfdjsl;afkjfjslakjf;ldskaj;flkajs;ldfjlaskf
aslfjflasdflasj;lfdjsl;afkjfjslakjf ==
signature: alsdjflsajflksjdlkfjlsakjflkdsajflksjfjslakjf;ldskaj;jfj
slakjf;ldskaj;djlfasd===
#####################################################################
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:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
Eastlake, Boesch, Crocker, Yesil [Page 17]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
#####################################################################
Opaque Key: Same as session key for R1 for same Transaction and
connection (there may be no ID!).
#####################################################################
Opaque Section Contents:
type: registration-response
server-date: 19950121100506.nnn
requested-id: MyRequestedCCID
response-id: CyberCashHandle
email: myemail@myemailhost.com
response-code: success/failure/etc.
pubkey: aslfjflasdflasj;lfdjsl;afkj;ldkfjslakjf;ldskslakjf;ldskslakjf;
ldskslakjf;ldskslakjf;ldskaj;flkajs;ldfjlaskf==
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 for
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
#####################################################################
Eastlake, Boesch, Crocker, Yesil [Page 18]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
Sample Message:
$$-CyberCash-0.8-$$
transaction: 123123213
date: 19950121100505.nnn
cyberkey: CC1001
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
3ard3Q==
$$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$
#####################################################################
Opaque Key: Generated using CyberCash encrypting public key identified
in CyberKey.
#####################################################################
Opaque Section Contents:
type: get-application
swversion: 0.8win
#####################################################################
Signature is of the following fields: no signature
#####################################################################
Explanation:
There may not be a customer persona so there is no ID. There
may not be a customer public/private key pair so there is
no signature. The swversion is mandatory so the server can
tell what to return.
4.1.4 GA2 - get-application-response
Description: Return success and URL of up to date copy of CyberApp
or failure.
#####################################################################
Sender: CyberServer
Receiver: CyberApp
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
transaction: 12312313
date: 19950110102333.nnn
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
Eastlake, Boesch, Crocker, Yesil [Page 19]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
3ard3Q==
$$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$
#####################################################################
Opaque Key: session key from GA1
#####################################################################
Opaque Section Contents:
type: get-application-response
server-date: 19950110102334.nnn
response-code: success/failure/etc.
message; Text message to be displayed to the user providing more
information on the success/failure.
swversion: 0.8win
application-url: http://foo.cybercash.com/server/0.8WIN.EXE
application-hash: lSLzs/vFQ0BXfU98LZNWhQ==
#####################################################################
Signature: none.
#####################################################################
Explanation:
application-hash is the MD5 of the binary of the application.
application-url & application-hash omitted on failure.
swversion is the version being transmitted to the customer.
4.2 Binding Credit Cards
The CyberCash system is design to give the card issuing organization
control over whether a card may be used via the CyberCash system.
The customer, after having registered a persona with CyberCash as
described above, must then bind each credit card they wish to use to
their CyberCash persona. This is done via the BC1 message from the
customer to their CyberCash server and the BC4 response from the
server.
4.2.1 BC1 - bind-credit-card
Description: This is the initial message in the process of binding a
credit card to a CyberCash persona.
Eastlake, Boesch, Crocker, Yesil [Page 20]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
#####################################################################
Sender: CyberApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 12312314
cyberkey: CC1001
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Opaque Key: generated from CyberCash encryption key identified in
CyberKey
#####################################################################
Opaque Section Contents:
type: bind-credit-card
swversion: 0.8win
card-number: 1234567887654321
card-type: mastercard
card-salt: 46735210
card-expiration-date: 05/99
card-name: John Q. Public
card-street:
card-city:
card-state:
card-postal-code:
card-country:
signature: sjadlkasl;f;lksaj;lfjs;lfjsldfjl;lfjs;lfjsldfjl;lfjs;lfjsl
;lfjs;lfjsldfjl;lfjs;lfjsldfjlskflsajfsa==
#####################################################################
signature is of the following fields: id, date, transaction,
cyberkey, type, swversion, card-number, card-salt,
card-expiration-date, card-name, card-street, card-city,
card-state, card-postal-code, card-country
#####################################################################
Explanation:
salt is needed so that the hash stored at the server is less
Eastlake, Boesch, Crocker, Yesil [Page 21]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
informative. Server just remembers the "prefix" of the card
number and the hash of the combined card number and salt. If it
just hashed the card number, it would be recoverable with modest
effort by trying to hash all plausible numbers. We don't want
to store the card numbers on the server because it would make
the server files too valuable to bad guys.
4.2.2 BC4 - bind-credit-card-response
Description: Indicates that the process of binding a credit card
terminated. Returns success or failure.
#####################################################################
Sender: CyberServer
Receiver: CyberApp
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
id: mycybercashid
transaction: 12312314
date: 19950121100505.nnn
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Opaque Key: Session key from BC1 with same Transaction and ID
#####################################################################
Opaque Section Contents:
type: bind-credit-card-response
server-date: 19950121100506.nnn
swseverity: fatal/warning [absent if ok]
swmessage; message about obsoleteness of customer software
to be shown to the customer. [only present if SWSeverity present]
response-code: success/failure/etc.
card-number: 1234567887654321
card-type: visa
card-salt: 47562310
card-expiration-date: 01/99
card*: [other card* lines to also be given in CH.1 message]
message; Plain text for the user
Eastlake, Boesch, Crocker, Yesil [Page 22]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
can be multiple lines
#####################################################################
Signature is of the following fields: no-signature
#####################################################################
Explanation: All the card* lines can be saved as a blob to be
submitted in CH.1. card-expiration-date, card-number, card-salt,
and card-type should always be present.
Depending on reason for failure, not all fields may be present.
4.3 Customer Credit Card Purchasing Messages
In general, CyberCash involvement in the credit card purchasing cycle
starts after the user has determined what they are buying. When they
click on the CyberCash payment button, a PR1 message is sent by the
merchant to the customer as the body of a message of MIME type
application/cybercash.
If the customer wishes to proceed, they respond to the merchant with
a CH1. The merchant responds with a CH2 but between the receipt of
the CH1 and issuance of the CH2, the merchant usually communicates
with the CyberCash server via the CM* messages.
4.3.1 PR1 - payment-request
Description: This message is the first message that is defined
by CyberCash in the purchase from a merchant process. The
shopping has completed. Now we are at the point of paying
for the purchases.
#####################################################################
Sender: MerchantApp
Receiver: CyberApp
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
type: payment-request
merchant-ccid: ACME-012
merchant-order-id: 1231-3424-234242
merchant-date: 19950121100505.nnn
note;
ACME Products
Purchase of 4 pairs "Rocket Shoes" at $39.95 ea.
Eastlake, Boesch, Crocker, Yesil [Page 23]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
Shipping and handling $5.00
Total Price: 164.80
Ship to:
Wily Coyote
1234 South St.
Somewhere, VA 12345
merchant-amount: usd 164.80
accepts: visa:CC001, master:CC001,amex:CC001,JCPenny:VK005,macy:VK006
url-pay-to: http://www.ACME.com/CybercashPayment
url-cancel: http://www.ACME.com/CyberPaymentCancel
url-success: http://www.ACME.com/ordersuccess
url-fail: http://www.ACME.com/orderfail
merchant-signed-hash: asfkjslkjflskdfjwerwerwrlkwfjwerwerwrlkwfjwerwer
rwerwrlkwjrlkjwlejrjwelrkwk=
$$-CyberCash-End-lSLzs/vFQ0BXfU98LZNWhQ==-$$
#####################################################################
Opaque Key: no opaque section
#####################################################################
Opaque Section Contents: no opaque section
#####################################################################
merchant-signed-hash is the signature under the merchant's
private key of the hash of the following fields: type,
merchant-ccid, merchant-order-id, date, note, merchant-amount,
accepts, url-pay-to, url-cancel, url-success, url-fail
#####################################################################
Explanation:
This message is signed by the merchant but the customer cannot
directly verify this signature. When the payment is made, the
Customer includes the signature with the hash (derived by the
customer directly) in the payment. If these do not match, the
CyberCash will not perform the payment function.
accepts: The client software will only recognized single word card
name in the accepts field of PR1. For example,
MasterCard
AmericanExpress
are recognized where as
Master card
American express
are not recognized. MasterCard and masterCard are both
recognized as master card.
Card type followed by key designator. For main line credit cards,
this will be a CC*. Client can use or ignore the * number as
it chooses. For proprietary card, this will be VK* where * is
the CheckFree key to use (1 based). Cards separated by comma,
Eastlake, Boesch, Crocker, Yesil [Page 24]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
key designator follows card type and colon.
4.3.2 CH1 - credit-card-payment
Description: This message represents the presentation of a "credit
card for payment".
#####################################################################
Sender: CyberApp
Receiver: MerchantApp
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
type: card-payment
id: myCyberCashID
order-id: 1231-3424-234242
merchant-ccid: ACME-012
transaction: 78784567
date: 19950121100505.nnn
pr-hash: kjdsalfjlejelkjeljwlkjerljweklkjerljweklkjerljweklkjerljwekl
jerljwekrlwekrjlwekjfwe==
pr-signed-hash: sfljlkjflkjseljljljkjseljljljkjseljljljkjseljljljkjse
jljkjseljljljwlkjrwlejrlwkjlerkjwelr=
cyberkey: CC1001
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Opaque Key: Created using CyberCash encrypting public key in
CyberKey.
#####################################################################
Opaque Section Contents:
swversion: 0.8win
amount: usd 10.00
card*: [from successful BC4 (includes card-expiration-date,
card-number, card-type, and card-salt)]
signature: dfdsfffffsfdZydMAGVasdflkkjasdflkkjasfdlkjasdflkajsdlfkjas
fjaAqbat2d6hlC/mSw==
#####################################################################
Eastlake, Boesch, Crocker, Yesil [Page 25]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
signature is under client private key of the following fields:
type, id, order-id, merchant-ccid, transaction, date,
pr-hash, pr-signed-hash, cyberkey, swversion, amount,
card*
4.3.3 CH2 - charge-card-response
Description: Return to customer from a CH1 attempt to pay via credit
card. Indicates success/failure.
#####################################################################
Sender: MerchantApp
Receiver: CyberApp
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
type: charge-card-response
merchant-ccid: ACME-012
id: myCyberCashID
transaction: 78784567
date: 1995121100500.nnn
merchant-date: 19950121100505.nnn
merchant-response-code: failure/success/etc.
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash: sfljlkjflkjseljljljkjseljljljkjseljljljkjseljljljkjse
jljkjseljljljwlkjrwlejrlwkjlerkjwelr=
merchant-message; This is a message to display to the user from the
merchant. Can be multiple lines... Is not secure.
opaque: [might not be present, see explanation]
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Opaque Key: Same customer session key from CH1 passed through CM1
for ID and Transaction
#####################################################################
Opaque Section Contents (from CM.6):
server-date: 19950121100706.nnn
amount: usd 10.00
order-id: 1231-3424-234242
card*: [from successful BC4]
Eastlake, Boesch, Crocker, Yesil [Page 26]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
response-code: failure/success/etc.
swseverity: fatal/warning
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 customer
by the CyberCash application...
#####################################################################
Signature is of the following fields: no signature
#####################################################################
Explanation:
Opaque section optional because the CH1 to the merchant can fail due
to bad order-id, date, wrong merchant-ccid, etc., etc. So the
server may not be involved at all in which case there is no
mechanism for generating a secure opaque section. (It could even
be that merchant attempt to contact the server times out.)
If transaction makes it through server (via CM*) then
Response-Code at top level should mirror response-code to
merchant from server. (Hopefully the same as the
response-code to customer from server but the merchant can't
tell that.)
Note that there can be two messages, one from merchant and one
from the server.
4.4 Merchant Credit Card Purchasing Messages
The merchant presents credit card purchases, makes adjustments, and
the like via the CM* series. In general, the credit card cycle is
one of getting authorization for a purchase, then capturing the
purchase in a batch for settlement, then performing the settlement.
It is also possible to void a capture (i.e., remove an item from a
batch), and process credits (returns).
Authorizations always come from an acquirer via a CM1 or CM2 message.
If capture is being performed by the acquirer or some entity between
the CyberCash server and the acquirer, this is done via a CM3 or CM2
message depending on the arrangement between the merchant and the
entity doing the capture. Returns (credits) are handled via message
CM5. Message CM4 is provided for voiding a capture or return before
the batch is settled. CM6 is the message format used for responses
to all the other CM* messages.
An MM* series has also been implemented for purely merchant
originated CyberCash charges as described in section 3.4.7
Eastlake, Boesch, Crocker, Yesil [Page 27]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
Current credit card dispute resolution systems assume that the
merchant knows the card number. Thus, to work with these systems,
special bypass messages have been set up that allow the merchant to
obtain, for a particular transaction, the information that CyberCash
otherwise goes to lengths to hide from the merchant. See sections
3.4.8 and 3.4.9.
Many present day merchants operate in a "terminal capture" mode where
the authorizations are captured by the merchant and the merchant
submits the settlement batch. Messages have been defined and are
being implemented so that such merchant captured batches can be
submitted via CyberCash.
4.4.1 CM1 - auth-only
Description: This message is used by the merchant to perform an
authorization operation on the credit card sent in by the
customer.
#####################################################################
Sender: MerchantApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-69
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3ard3Q==
merchant-opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
Eastlake, Boesch, Crocker, Yesil [Page 28]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Merchant-Opaque Section Contents:
type: auth-only
order-id: 12313424234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
sfljlkjflkjseljljljwlkjrweljljljwlkjrweljljljwlkjrweljljlj
kjrweljljljwlkjrwlejrlwkjlerkjwelr=
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
merchant-signature: lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjfl+w
flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf=
#####################################################################
merchant-opaque key is generated from the CyberCash encrypting public
key identified in merchant-cyberkey.
Customer opaque section (Opaque) - see CH1.
#####################################################################
Opaque Section Contents & Signature: (exactly as in CH1)
swversion: 0.8win
amount: usd 10.00
card*: [from successful BC4 (includes card-expiration-date,
card-number, and card-salt)]
signature: dfdsfffffsfdZydMAGVasdflkkjasdflkkjasfdlkjasdflkajsdlfkjas
fjaAqbat2d6hlC/mSw==
#####################################################################
merchant-signature is on the following fields: merchant-ccid,
merchant-transaction, merchant-date, merchant-cyberkey, type,
order-id, merchant-amount, pr-hash, pr-signed-hash, id,
transaction, date, cyberkey
Customer Signature: see CH1
#####################################################################
Explanation:
The merchant signature ensures integrity of the majority of the
message. validation of the customer signature ensures that the
customer opaque part was not tampered or replaced.
Eastlake, Boesch, Crocker, Yesil [Page 29]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
4.4.2 CM2 - auth-capture
Description: Do authorization and actually enters charge for
settlement. Message just like CM1 except for different
type.
#####################################################################
Sender: MerchantApp
Receiver: CyberServer
#####################################################################
Sample Message:
[exactly the same as CM1 except
type: auth-capture
]
3.4.3 CM3 - post-auth-capture
Description: Captures a charge previously authorized. Message is
the same as CM1 except that it also has an authorization-code
field (which is also included in the signature) and the type
is different.
#####################################################################
Sender: MerchantApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ube
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3ard3Q==
merchant-opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
Eastlake, Boesch, Crocker, Yesil [Page 30]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Merchant-Opaque Section Contents:
type: post-auth-capture
authorization-code: a12323
order-id: 1231-3424-234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash: sfljlkjflkjseljljljwlkjrweljljljwlkjrweljljljwlkjrwe
kjrweljljljwlkjrwlejrlwkjlerkjwelr=
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
merchant-signature: lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjflkj
flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf=
#####################################################################
merchant-opaque key is generated from the CyberCash encrypting public
key identified in merchant-cyberkey.
Customer opaque section (Opaque) - see CH1.
#####################################################################
Opaque Section Contents & Signature: (exactly as in CH1)
swversion: 0.8win
amount: usd 10.00
card*: [from successful BC4 (includes card-salt, card-number,
and card-expiration)]
signature: dfdsfffffsfdZydMAGVasdflkkjasdflkkjasfdlkjasdflkajsdlfkjas
fjaAqbat2d6hlC/mSw==
#####################################################################
merchant-signature is on the following fields: merchant-ccid,
merchant-transaction, merchant-date, merchant-cyberkey, type,
authorization-code, order-id, merchant-amount, pr-hash,
pr-signed-hash, id, transaction, date, cyberkey
#####################################################################
Explanation:
The merchant signature ensures integrity of the majority of the
message validation of the customer signature ensures that the
Eastlake, Boesch, Crocker, Yesil [Page 31]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
customer opaque part was not tampered or replaced.
4.4.4 CM4 - void
Description: Voids out a charge/return if received before
settlement. Message is the same as CM1 except that it also has
a retrieval-reference-number field (which is also included in the
signature) and the type is different.
#####################################################################
Sender: MerchantApp
Receiver: CyberServer
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff4
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3ard3Q==
merchant-opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Merchant-Opaque Section Contents:
type: void
retrieval-reference-number: 432112344321
order-id: 1231-3424-234242
merchant-amount: usd 10.00
pr-hash:
Eastlake, Boesch, Crocker, Yesil [Page 32]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
kjdsalfjlejelkjeljwlkjerljwwlkjerljwwlkjerljwwlkjerljwwlkjerljwwl
kjerljwwlkjerljwekrlwekrjlwekjfwe==
pr-signed-hash:
sfljlkjflkjseljljljwlkjrweljljljwlkjrweljljljwlkjrweljljljwl
kjrweljljljwlkjrwlejrlwkjlerkjwelr=
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Merchant-Signature: lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjflkj
flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf=
#####################################################################
Merchant-Opaque key is generated from the CyberCash encrypting public
key identified in Merchant-CyberKey.
Customer opaque section (Opaque) - see CH1.
#####################################################################
Opaque Section Contents & Signature: (exactly as in CH1)
swversion: 0.8win
amount: usd 10.00
card*: [from successful bc4 (includes card-salt, card-number,
and card-expiration)]
signature: dfdsfffffsfdZydMAGVasdflkkjasdflkkjasfdlkjasdflkajsdlfkjas
fjaAqbat2d6hlC/mSw==
#####################################################################
merchant-signature is on the following fields: merchant-ccid,
merchant-transaction, merchant-date, merchant-cyberkey, type,
retrieval-reference-number, order-id, merchant-amount, pr-hash,
pr-signed-hash, id, transaction, date, cyberkey
#####################################################################
Explanation:
The merchant signature ensures integrity of the majority of the
message. Validation of the customer signature ensures that the
customer opaque part was not tampered or replaced.
4.4.5 CM5 - return
Description: Reverse a previous charge. Really sort of a negative
charge. Message just like CM1 except for different type.
#####################################################################
Sender: MerchantApp
Receiver: CyberServer
#####################################################################
Eastlake, Boesch, Crocker, Yesil [Page 33]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
Sample Message:
[exactly the same as CM1 except
type: return
]
4.4.6 CM6 - charge-action-response
Description: This receipt is given to the merchant as a receipt
for a completed charge action. Indicates success/failure/etc.
#####################################################################
Sender: CyberServer
Receiver: MerchantApp
#####################################################################
Sample Message:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Merchant-Opaque Key: Session key same as that of CM1/2/3/4/5 for
same Merchant-Transaction and Merchant-CCID.
Opaque Key: Same customer session key from CH1 passed through CM*
for ID and Transaction
Eastlake, Boesch, Crocker, Yesil [Page 34]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
#####################################################################
Merchant-Opaque Section Contents:
type: charge-action-response
server-date: 19950121100706.nnn
action-code: XXX [per ISO 8583]
response-code: failure/success/etc.
order-id: 1231-3424-234242
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash: sfljlkjflkjseljljllkjseljljllkjseljljllkjseljljllkjse
ljljwlkjrwlejrlwkjlerkjwelr=
retrieval-reference-number: 432112344321
authorization-code: a12323
card-hash: 7Tm/djB05pLIw3JAyy5E7A==
{
card-prefix: nnxxxx [Returned if merchant is not full-PAN]
}
or
{
card-number: 1234567890123456 [Returned if merchant is full-PAN]
}
expiration-date: 12/34 [always present]
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
Opaque (Customer) contents:
server-date: 19950121100706.nnn
amount: usd 10.00
order-id: 1231-3424-234242
card*: [from successful BC4]
response-code: failure/success/etc.
swseverity: fatal/warning
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 customer
by the CyberCash application...
#####################################################################
Signature is of the following fields: no signature
Eastlake, Boesch, Crocker, Yesil [Page 35]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
#####################################################################
Explanation:
retrieval-reference-number is needed for voids. authorization-code
is needed for post-auth-capture. These fields are each only
present in the CM6 if they were returned by the bank which
depends on what operation was being done.
card-prefix is first two and last four digits of card-number.
At bank's discretion the card-number or card-prefix is
returned.
card-hash is really the hash of the full card number and the salt
provided by the customer. card-hash is needed so the merchant
can, if they wish, sort customer transactions by card without
knowing the card number.
card* is th card* fields delivered in the CM* messages being
responded to. They appear in alphabetic order.
server-date duplicated in customer opaque area for security.
{}'s in column one just for clarity of alternatives and do not
actually appear in the message.
[]ed comments appear after some fields.
4.4.7 The MM* Message Series
The CM* message series above is the primary CyberCash credit card
purchase system for securely handing charges from CyberCash
customers. However, merchants, who are authorized by their acquiring
bank to accept such charges, may also receive telephone, mail, and
over the counter sales. To avoid any necessity for the merchant to
have a second parallel system to handle these charges, an MM1 through
MM6 message series is defined and has been implemented for these less
secure transactions.
The MM* messages look very similar to the CM* series but the
"customer opaque" section is actually signed by the merchant and no
separate customer CyberCash ID or prior card binding is required.
4.4.8 CD1 - card-data-request
Description: Used by merchant to get card-number, etc., if
information needed by merchant to resolve a dispute.
#####################################################################
Sender: MerchantApp
Receiver: CyberServer
#####################################################################
Sample Message:
Eastlake, Boesch, Crocker, Yesil [Page 36]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
$$-CyberCash-0.8-$$
merchant-ccid: ACME-69
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
merchant-opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Merchant-Opaque Section Contents:
type: card-data-request
password: xyzzy
server-date: 19950121100505.nnn [optional]
order-id: 12313424234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
sfljlkjflkjseljljljwlkjrweljljljwlkjrweljljljwlkjrweljljlj
kjrweljljljwlkjrwlejrlwkjlerkjwelr=
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
merchant-signature: lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjflkj
flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf=
#####################################################################
merchant-opaque key is generated from the CyberCash encrypting public
key identified in merchant-cyberkey.
Customer opaque section (Opaque) - see CH1.
#####################################################################
Opaque Section Contents & Signature: (exactly as in CH1)
swversion: 0.8win
amount: usd 10.00
card*: [from successful BC4 (includes card-expiration-date,
Eastlake, Boesch, Crocker, Yesil [Page 37]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
card-number, and card-salt)]
signature: dfdsfffffsfdZydMAGVasdflkkjasdflkkjasfdlkjasdflkajsdlfkjas
fjaAqbat2d6hlC/mSw==
#####################################################################
merchant-signature is on the following fields: merchant-ccid,
merchant-transaction, merchant-date, merchant-cyberkey, type,
password, server-date, order-id, merchant-amount, pr-hash,
pr-signed-hash, id, transaction, date, cyberkey
Customer Signature: see CH1
#####################################################################
Explanation:
[see also CM1 explanation]
The merchant may need to know the card involved and other
information in order to resolve a disputed transaction. This
information is all contained in the original CH1 embedded in the
CM1 for the transaction. If the merchant saves the CM1 and other
transaction information, they can send this CD1 message to the
server. While this reduces the pass through confidentiality of
the system, the merchant is then on record as asking for this
particular credit card number and excessive CD1's from a merchant
can be flagged.
password is an extra level of security intended to be manually entered
at the merchant to authorize the unusual action. Server stores a
hash of the merchant-ccid and the password.
4.4.9 CD2 - card-data-response
Description: Respond to CD1 with failure or with success and card
data.
#####################################################################
Sender: CyberServer Receiver: MerchantApp
#####################################################################
Sample Message:
$$-CyberCash-0.7-$$ merchant-ccid: ACME-012 merchant-transaction:
123123 merchant-date: 19950121100705.nnn merchant-opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q== $$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
Eastlake, Boesch, Crocker, Yesil [Page 38]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
#####################################################################
Opaque Key: session key from CD1.
#####################################################################
Opaque Section Contents:
type: card-data-response server-date: 19950121100706.nnn response-
code: failure/success/etc. order-id: 1231-3424-234242 pr-hash:
7Tm/djB05pLIw3JAyy5E7A== pr-signed-hash:
sfljlkjflkjseljljllkjseljljllkjseljljllkjseljljllkjse
ljljwlkjrwlejrlwkjlerkjwelr= card-hash: 7Tm/djB05pLIw3JAyy5E7A==
card-number: 4811123456781234 card-type: visa 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
Eastlake, Boesch, Crocker, Yesil [Page 39]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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.
4.5.1 P1 - ping
Description: Very light weight check that we have connectivity
from the customer to the server.
#####################################################################
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.7-$$
type: ping-response
id: myCyberCashID [if present in P1]
transaction: 12312313
date: 19950121100505.nnn
server-date: 19950121100506.nnn
Eastlake, Boesch, Crocker, Yesil [Page 40]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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
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:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Opaque Key: generated from CyberCash encryption key identified in
CyberKey
Eastlake, Boesch, Crocker, Yesil [Page 41]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
#####################################################################
Opaque Section Contents:
type: transaction-query
swversion: 0.8win
begin-transaction: 1234
end-transaction: 4321
signature: sjadlkasl;f;lksaj;lfjs;lfjsldfjl;lfjs;lfjsldfjl;lfjs;lfjsl
;lfjs;lfjsldfjl;lfjs;lfjsldfjlskflsajfsa==
#####################################################################
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:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Opaque Key: generated from CyberCash encryption key identified in
CyberKey
Eastlake, Boesch, Crocker, Yesil [Page 42]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
#####################################################################
Opaque Section Contents:
type: transaction-cancel
swversion: 0.8win
begin-transaction: 1234
end-transaction: 4321
signature: sjadlkasl;f;lksaj;lfjs;lfjsldfjl;lfjs;lfjsldfjl;lfjs;lfjsl
;lfjs;lfjsldfjl;lfjs;lfjsldfjlskflsajfsa==
#####################################################################
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:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
Eastlake, Boesch, Crocker, Yesil [Page 43]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
3ard3Q==
$$-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
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
Eastlake, Boesch, Crocker, Yesil [Page 44]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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.
#####################################################################
Sender: MerchantApp or CyberServer
Receiver: CyberApp or MerchantApp
#####################################################################
Sample Message:
Eastlake, Boesch, Crocker, Yesil [Page 45]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
$$-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:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-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
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
Eastlake, Boesch, Crocker, Yesil [Page 46]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ffs
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKXx
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Opaque Key: generated from CyberCash encryption key identified in
CyberKey
#####################################################################
Opaque Section Contents:
type: diagnostic-log
server-date: 19950121100505.nnn [optional]
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:
Eastlake, Boesch, Crocker, Yesil [Page 47]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
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
Eastlake, Boesch, Crocker, Yesil [Page 48]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
#####################################################################
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
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
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
Eastlake, Boesch, Crocker, Yesil [Page 49]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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
Eastlake, Boesch, Crocker, Yesil [Page 50]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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 settlements, and other
improvements.
Eastlake, Boesch, Crocker, Yesil [Page 51]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
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] - D. Crocker, "Standard for the format of ARPA Internet
text messages", 08/13/1982.
[RFC 1521] - N. Borenstein, N. Freed, "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", 09/23/1993.
[RFC 1766] - H. Alvestrand, "Tags for the Identification of
Languages", 03/02/1995.
Eastlake, Boesch, Crocker, Yesil [Page 52]
INTERNET-DRAFT CyberCash Version 0.8 8 July 1995
Authors Addresses
Donald E. Eastlake 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 508 287 4877
EMail: dee@cybercash.com
Brian Boesch
CyberCash, Inc.
2100 Reston Parkway, Suite 430
Reston, VA 22091 USA
Telephone: +1 703-620-4200
email: boesch@cybercash.com
Steve Crocker
CyberCash, Inc.
2100 Reston Parkway, Suite 430
Reston, VA 22091 USA
Telephone: +1 703-620-4200
email: crocker@cybercash.com
Magdalena Yesil
CyberCash, Inc.
555 Twin Dolphin Drive, Suite 570
Redwood City, CA 94065 USA
Telephone: +1 415-594-0800
email: magdalen@cybercash.com
Expiration and File Name
This draft expires 7 January 1996.
Its file name is draft-eastlake-cybercash-v08-00.txt.
Eastlake, Boesch, Crocker, Yesil [Page 53]