---------- Begin Forwarded Message ---------- Date: Fri, 1 Dec 1995 22:43:46 -0500 (EST) From: "Debbie O'Dell" <dlo@dsunix2.dsrd.ornl.gov> To: Electronic Commerce Working Group Reflector <fstc-ecomm@monroe.llnl.gov> 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 -----------