[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Meeting notes from ANSI X.9 Meeting on Electronic Payment Standard
---------- Begin Forwarded Message ----------
Date: Fri, 1 Dec 1995 22:43:46 -0500 (EST)
From: "Debbie O'Dell" <[email protected]>
To: Electronic Commerce Working Group Reflector <[email protected]>
Subject: Meeting notes from ANSI X.9 Meeting on Electronic Payment Standard
ABA Meeting of the X.9 ANSI Meeting 11/29/95, on Electronic Payments:
Cindy Katzen (?) gave an introduction. She said that the ANSI X.9 which is
accredited to develop financial industry standards, has approved this work
item on Electronic Payments. X.9 has 6 subcommittees, 30 active working
groups, and manage 70 standards, and technical specifications. We do 5 year
reviews on each. Also they are the US technical advisory group to ISO
Technical Committee 68 (TC68), and they also provide a secretariat. TC68
has 3 subcommittees. Mark Zalewski of Cybercash is nominated chair for TC68.
This is domestic standards development. Define work and tell them what
needs to be done. If there does not need to be a domestic standard but an
international one that is okay. Intel has offered to provide a Chairperson,
Tom Jones.
Tom lead the meeting with the following agenda:
Scope of work item
Proposal to extend the work item into other areas
2 presentations on other standards, Taher Elgamal on SEPP, and FSTC on Echeck
The general purpose of this work item is to produce an American national
standard on secure electronic payment syntax. Since the group is large, Tom
suggested nominating a small editing group of 6-10 people to put together a
document and bring it back to the larger group.
Tom said that he wanted to get through the work item in 18 months, and to do
that there would have to be a draft in 9 months. The following document was
a strawman distributed to start discussion on a proposed X9 new work item.
"Towards an American National Standard: Secure Payment Syntax
Scope:
The payment syntax described in this standard is designed to order a
Financial Institution to make a payment to a merchant from an account of a
purchaser based on the near term delivery of low monetary value goods or
services. It should be possible to include this payment order in any
electronic protocol that is based on communications between the purchaser
and the merchant, and between the merchant and a Financial Institution.
This standard does not describe, nor recommend, any particular communication
protocol.
When used within a complete payment infrastructure, the secure payment order
described below shall offer privacy and integrity of the purchaser's payment
information, and shall prevent the purchaser from successfully repudiating
the sending, or the merchant from successfully repudiating the receiving, of
a valid payment order. Non-repudiation of receipt will require secure
acknowledgment messages. Thus the Financial Institution can be sure that
its customer requested the payment and that the merchant can be accurately
identified on the account statement.
Purpose:
Consumers, operating from within their own home or business, have access to
an increasingly wide range of electronic displays of merchant's wares. The
source of this electronic cornucopia can be provided by networked
connections, broadcast or narrowcast TV, the physical distribution of
electronic media, such as CD-ROM, or future media connections which are now
only in the conceptual stage. Regardless of the source of the information,
there is an increasingly urgent demand that user's make the purchase
decision directly from the electronic media, and the purchase decision be
transmitted together with payment information to the merchant. The merchant
wants to receive the payment information prior to delivering the merchandise
to cut down on fraud loss and the purchaser seems to want immediate access
to the goods or services, purchased.
This standard is intended to close the electronic loop by providing a secure
means for the purchaser to make payment information available to the
merchant, without revealing any secret information that could be used in a
fraudulent manner to access the purchaser's accounts. The payment
information will only be accessible by the purchaser, and the purchaser's
Financial Institution, but the merchant can be assured, in real-time, that
payment will be honored by his Financial Institution.
Content of the Payment Order:
The fields required for the payment order are separated into the plain text
segment and enciphered segment.
Transparent fields from CyberCash Credit Card Protocol (CH1)
type: card-payment
id
order-id
merchant-ccid
transaction
date
pr-hash
pr-signed-has
cyberkey
EPO fields from "NetBill Security and Transaction Protocol"
purchaser's ID
Product ID
Negotiated Price
Merchant ID
Crypto Checksum of Product Request Data
Crypto Checksum of Purchaser's Account No with a nonce
Globally-unique EPOID (Transaction ID)
Security for the Payment Order (from the Purchaser)
Only those fields that are in the enciphered segment will be protected from
disclosure or alteration by cryptographic means.
Opaque fields from CyberCash Credit Card Protocol (CH1)
swversion
amount¤cy
card (expiry, number, type, salt) - must be pre-approved
signature
EPO fields from "NetBill Security and Transaction Protocol"
Ticket proving the customer's TRUE ID
Authorization Tokens
Purchaser's Account No
nonce
Purchaser's memo field
Security for Merchant Fields
Those fields that are in the merchant's enciphered segment will be protected
from disclosure or alteration by cryptographic means.
Merchant Opaque fields from CyberCash Credit Card Protocol (CM1/2)
type
order-id
merchant-amount¤cy
pr-hash
pr-signed-hash
id
transaction
date
merchant-signature
EPO fields from "NetBill Security and Transaction Protocol" added by merchant
Merchant's account number
Merchant's memo field
Goods decryption key
Merchant signature
"
Discussion on scope:
The result of this group will be a message set and sequence diagram. There
will be a lot of work going into what is in those messages.
There was some discussion about the use of the terms low monetary value and
merchant.
Graham asked if other payment flows would be considered. Tom said that he
wanted to have a scope that is small and easily achievable, so that is why
we are focusing the flow from consumer to merchant to financial institution.
Right now this cannot support cash, as it requires the consumer to have a
bank account. It can support credit or debit.
There are a relatively small group of encryption algorithms about to be
approved by X-9.
Three have been approved: DES, Triple DES is in the works, RSA and
Vhelman (?). Digital Signature and Secure Hash is a standard; attribute
lists are being worked on. Security folks in X9f will be active in this
work item.
It may be necessary to specify encryption schemes. Key exchange is quite
different. If you allow more than one, you get into interoperability
problems.
NSA representative said that the length of the encryption key should not be
an issue, but what is encrypted should be of more concern for the group.
The group should not limit this standard based on a regulation that could
change in a few months.
The 820 is complicated and could be used to accomplish this activity, but
this work item is trying to come up with a relatively simple consumer
oriented transaction.
If you are going to say privacy, integrity and non-repudiation, then you
will have to define cryptography. X.9 has standards that define the
cryptography protocols so we can reference them.
The comments on the scope will be incorporated and a new draft will be
submitted to the group for review.
Will the usage specification operate with current regulation and clearing
and settlement system?
If you use Party A, Party B and a Bank, instead of using the term merchant,
then you could move it in any way. If there are 2 parties and only one
bank, then this will not effect any clearing system. If it is 2 parties and
2 banks then the clearing system comes into play.
Should the second bank be added to the scope? Do we want to support flows
between financial institutions.
We need to rely on the banks to tell us if this is implementable. Dan
suggested that the standard be expanded to support information exchanged
between banks.
Tom said that we should work to understood the needs of customers and limit
ourselves to the problems that we know and not try and solve problems we
don't know about.
We can produce guidelines for reference implementations, but they are not
part of the standard. We encourage organizations that are developing
implementations to advise us of any issues in implementing the standard.
Tom said that he will do best to narrow the scope. If any suggestion
increases the scope significantly, I will recommend that they become a
separate work item.
Talk on SEPP: John Gould of MasterCard said that the Secure Electronic
Payment Protocol (SEPP) is intended to solve MC's business model. We expect
to conclude revision to the SEPP review process in less than 60 days. We
have a time pressure by customers and member banks to secure our brand
products quickly. We will be piloting the result hopefully with VISA and
X9. Take the SEPP document as an informational, living, document. We will
not know how good it is until we start to pilot it.
Taher Elgamal, of Netscape, said that SEPP is a vertical solution rather
than a horizontal message format. SEPP solves the credit card transaction
where there is a consumer, merchant and merchant's bank. We were not trying
to solve the world's payment problems. Credit cards are the simplest model
to use. People feel comfortable because the liability is to the benefit of
the consumer most of the time. We tried to minimize the impact on the
existing medium, banking protocols and networks. The design is a front end
to the existing bank network.
We had to solve the authentication problem. It is not really exactly known
how this will work and if it will scale properly. We tried not to change
relationship between parties. We started with a generic philosophy to use
standards where they exist.
SEPP will be implemented independently by different vendors that have to
achieve interoperability. The merchant does not have to see the credit card
number even though he does today. The payment/order has dual encryption.
The payment instruction is opaque to the merchant. The order details are
not of interest to the bank.
The message formats are the tools in SEPP, to achieve the product, that is
useful. There is an attempt to solve the grand picture. The credit card
system is complex.
Does the merchant really need to know the identity of the consumer. The
merchant is only interested that the person is capable of using the amount.
They may want to know, but they may not need to know.
We built in an online certification system, which certifies consumers and
merchants. For SEPP, the acquiring bank does the certification. Dan
mentioned that this is not quite analogous to how it works in the paper model.
Frank Jaffe spoke about Echeck.
He said that the future is likely to bring more alternatives, not less. We
wanted to move the check to a paperless instrument. Eliminate paper and use
cryptographic methods to secure it. We're looking at digital signatures to
replace hand signatures.
The Electronic Check supports multiple check flows. Deposit and Clear
(Normal) flow, Cash Check, Z flow, Lockbox flow, and transfer flow.
Electronic Check supports multiple business models: Certified Check flow,
Interchange, Third Party Payer.
Overview:
-Develop a secure, all-electronic instrument modeled on paper check
primarily for use in electronic commerce
-Enable this instrument to be flexible and represent other physical
instruments such as cashier's checks, traveler's checks
-Develop a general programmatic set of tools and standard interfaces,
protocols and formats so that E-Check functions can be used for other
applications.
-Test approach through a commercial pilot.
We would like to develop a reference implementation and tools to make it
easier to use it.
Electronic Check objectives:
-provide individuals and businesses a safe convenient debit payment option
-use inexpensive public networks
-enable merchants to automate complete transactions
We're not trying to specify encryption, to allow parties to use what they
want.
Key component summary:
-hardware token for electronic and checkbook cryptographic key storage
-digital signatures for transaction authentication
-electronic certificates for account and bank authentication
-secure hash for tamper-proofing
-encryption for privacy is optional
-remittance/invoice/order form included for automated accounts receivable
processes
-public networks for transmission
The scope of the project is to issue payment orders against accounts in banks.
If customer wants it, banks can afford it, and it can be done securely than
why not?
Tom started discussion again on the X.9 Work item. He said that we need to
address: what do customers want, what risks do banks want to take and how
fast do you want to do it?
The banking industry needs a protocol standard for electronic payments.
This could be the beginning of something bigger; define a scope for this
work item, but as the beginning of a payment protocol.
Frank suggested that the project should focus more than just consumer to
merchant.
Several people suggested trying to develop a more encompassing payment
protocol than just consumer to merchant payments, because it is easier to
design up front than redesign after it has been implemented.
Others suggested that we ought to start with something manageable, like
debit or credit cards, but not design ourselves into a corner.
If this group does not address payment types, than client software will have
to identify between payment types and what merchants and/or banks take what.
Taher pointed out that SEPP will not do debit cards well.
Will consumers use account based systems in the volume that you expect?
Many agreed that speed is important, and encouraged staying focused for time
considerations.
There was a suggestion to have separate groups developing payment syntax for
credit, debit, echeck.
One suggestion was to help the consumer to quickly negotiate a payment
system of choice.
Spending time on credit seems to make sense since it is more widely used on
the Internet.
NACHA is addressing the check issue.
Tom summarized the discussion saying that it appeared that most agreed to
stay cognizant of all issues, but focus on the credit model and allow the
architecture to expand.
We should find what is in common to all payment systems. Make it modular to
add on types or variations.
Someone suggested a steering committee to address these extensions.
Tom proposed an editing group of 6-10 people to get document out on the
credit model. He proposed having a meeting of the editing group on January
16th in San Francisco.
The full group will meet Feb. 29th at Cylink in Sunnyvale.
and tentatively June 7th in Boston at the Fed.
However other groups would like to deal with the other issues is up to them.
FSTC will find a way to work with this committee through their joint
membership.
Tom asked Frank to feed back to X9 how FSTC wants to fit Echeck into this
work group.
All this work item was written to deal with is the syntax, we are not going
to deal with the protocol. There would be a multiplicity of protocols that
would use it, phone, modem, http.
SEPP has an application protocol that is independent of communications.
Mohammad Khan volunteered to lead a group to discuss management issues
including negotiation. VISA, MC, Discover, IBM, and Cybercash volunteered
to participate in that group.
----------- End Forwarded Message -----------