|
|
Electronic Payment MechanismsThis section of the OII Standards and Specifications List provides information on specifications and applications that can be used for financial transactions over the Internet. It is restricted to those methods that can be employed in a multinational context, so does not cover mechanisms that cannot be exported from their country of origin.Note: This preliminary list is not exhaustive. If you are aware of a mechanism that we have not listed that is being used in a multinational context, we would appreciate receiving information relating to it for adding to this list. Two main categories of electronic settlement are covered:
 Entry updated this month
It should be noted that some of these mechanisms include additional security refinements and facilities, such as authentication, message integrity and choice of key management. Other mechanisms for supporting these techniques can be found in the section onInformation Security Standards. Unlike other parts of the OII Standards and Specifications List, this section does not restrict itself to proven standards. Because the electronic payment marketplace is so new, the protocols discussed in this section are mainly at prototype stage, and have yet to achieve formal status. Only where the specifications are publicly available are they formally cited under theSponsoring bodies and standards details heading. In all other cases references to relevant Internet sites will be found under the Further details available from heading. The dynamic nature of the marketplace may lead to some of these mechanisms becoming obsolete. It is felt, however, that this area of development is of such significance that timely information will be valuable to users. The Payments group of the World Wide Web Consortium (W3C) maintains a roadmap that lists most of the mechanisms for electronic payment over the Internet that are currently available, including many proprietary solutions for which no publicly available specifications have been prepared. This roadmap can be contacted athttp://www.w3.org/pub/WWW/Payments/roadmap.html. A report about the fact-finding mission for the Financial Issues Working Group (FIWG) of the European Commission which took place between August 25th and September 5th 1996 can be found in Electronic Money in the United States: Current Status, Prospects and Major Issues. Standards for electronic banking within Europe are developed by the European Committee for Banking Standards, whose TC4 Security group have prepared a report of Secure Banking over the Internet. The ISO committee responsible for this area is ISO TC68, Banking, securities and other financial services. |
Digital Money Transfer MethodsMethods for making electronic payments whereby the receiver obtains a signal that can be used for further transactions. This section is restricted to applications that are being used in more than one country, with at least one of the countries being within Europe, and to those applications where transfer can take place over the Internet. Note: Applications that rely on bank-operated telecommunications networks are specifically excluded. The methods currently listed in this section are: |
ecashExpanded name Area covered Sponsoring body and standard details Characteristics/description Using the ecash client software a customer withdraws ecash (a form of digital money) from a bank and stores it on his local computer. The user can spend the digital money at any shop accepting ecash, without the trouble of having to open an account there first, or having to transmit credit card numbers. Ecash provides the highest security possible by applying public key digital signature techniques. Additional security features of ecash include the protection of ecash withdrawals from your account with a password that is only known to you; not even to your bank. One of the features of ecash is payer anonymity. When paying with ecash the identity of the payer is not revealed. Usage (Market segment and penetration) At the end of 1995 a number of banks became ecash issuers. These banks issue ecash denominated in real currencies. Unfortunately there are currently no facilities for exchanging ecash tokens of different denominations. Further details available from: For more information on ecash contact http://www.digicash.nl/ |
EMV 96Expanded nameIntegrated Circuit Card (ICC) Specifications for Payments Area covered Sponsoring body and standard details
Characteristics/description
An Application File Locator (AFL) determines the files and records to be used for processing a transaction. Descriptions of the file structure and commands for accessing the files can be found in the card specification, as can the definition of each of the data objects. Files may contain multiple records. Each record is limited to 254 bytes, including tag and length data. Each record is coded as a constructed data object. Either static or dynamic data authentication may be performed, but not both. Static data authentication authenticates static data put into the card by the issuer. Dynamic data authentication authenticates ICC-resident data, data from the terminal, and the card itself. Proprietary functions may be added to the terminal and the ICC application as long as they do not interfere with processing of terminals and ICCs not implementing the function. Usage (Market segment and penetration) Further details available from: For details of bank- or network-specific forms of 'electronic purse' refer to Leo Van Hove's Selected bibliography on Electonic Purses. |
GlobeIDExpanded name Area covered Sponsoring body and standard details Characteristics/description The Globe ID Wallet concept is very close to the traditional wallet. A customer may own several Globe ID Wallets. If the customer wants to be able to do transactions using different currencies, he will have to open a wallet for each currency. Each wallet is associated to a credit card number. Using the "Globe ID Wallet consultation service" users can retrieve cash from their credit card account and deposit it on their wallet. Only payment transactions (debit) and refill from account operations are allowed with a Globe ID Wallet. For credit transactions (selling), a Globe ID Merchant Wallet must be used. A Transaction Confirmation form is dispayed on the screen for each transaction. This provides an overview of the relevant parameters for the transaction (product reference, price, wallet used, etc.). If the customer agrees with what is displayed he should enter his "Wallet PIN" and confirm the transaction. If he disagrees, the Cancel button should be used. Usage (Market segment and penetration) Further details available from: Information on GlobeID can be obtained via the World Wide Web from http://globeid.gctech.fr/. |
MillicentArea covered Sponsoring body and standard details
Characteristics/description A vendor-specific piece of "scrip" represents an account the customer has established with a vendor. At any given time, a vendor has outstanding scrip (open accounts) with the recently active customers. The balance of the account is kept as the value of the scrip. When the customer makes a purchase with scrip, the cost of the purchase is deducted from the scrip's value and new scrip (with the new value/account balance) is returned as change. When the customer has completed a series of transactions, he can "cash in" the remaining value of the scrip (close the account). The text of the scrip gives its value and identifies the vendor. The scrip has a serial number to prevent double spending. There is a digital signature to prevent tampering and counterfeiting. The customer signs each use of scrip with a "secret" that is associated with the scrip. The signatures can be efficiently created and checked using a fast one-way hash function (like MD5 or SHA). There are three "secrets" involved in producing, validating, and spending scrip. The customer is sent one secret, the "customer_secret", to prove ownership of the scrip. The vendor uses one secret, the "master_customer_secret", to derive the customer_secret from customer information in the scrip. The third secret, the "master_scrip_secret", is used by the vendor to prevent tampering and counterfeiting. Note: The protocol calls for invalid elements to be added to the header of HTML files using Millicent. It is unclear how such files will be treated by web browsers that are not Millicent-enabled. Usage (Market segment and penetration) Further details available from: |
MondexArea covered Sponsoring body and standard details Characteristics/description As with cash, Mondex payment transactions do not need authorisations or signature and, just like cash, Mondex value can be moved directly between individuals. Because Mondex security resides in the chip on the card - not the network - it allows money to be moved safely over any 'unsecured' network, including the Internet. Each time a Mondex card is used the chip on the card generates a unique 'digital signature', which can be recognised by the other Mondex card involved in the transaction. This 'digital signature' is the guarantee that the cards involved are genuine Mondex cards and that they are dealing with untampered Mondex signals. This recognition process also identifies the card for which the cash is intended - so funds cannot be intercepted by a third party. Usage (Market segment and penetration) Mondex has recently (1997) announced alliances with CyberCash, VeriFone and Sun Microsystems. Further details available from: Information on Mondex can be obtained via the World Wide Web from http://www.mondex.com/index.html. |
WorldPayArea covered Sponsoring body and standard details Characteristics/description Note: Technical details about the services are not available to the public. Usage (Market segment and penetration) Note: There is a £1000 fee for connecting a web site to the WorldPay server. Further details available from: |
Secure Electronic Transaction ProtocolsProtocols for recording payments to be made through a third-party (e.g. bank, credit card company, etc). These protocols cover the forms of the transmitted message, rather than the methods used to ensure the privacy of the message. The protocols currently listed in this section are: |
CyberCashExpanded name Area covered Sponsoring body and standard details Characteristics/description Upon receipt, the merchant adds additional authorization information which is then encrypted, electronically signed by the merchant, and sent to the CyberCash Server. 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 bank's response is returned to the CyberCash Server which returns an electronic receipt to the merchant, part of which the merchant is expected to forward to the customer to complete the transaction. For small payments on the Internet, ranging from $0.25 to $10.00, the CyberCoin system can be used in the US. Consumers use an existing bank account to transfer money to an Electronic Wallet. Money is never moved onto or stored on the consumer's PC. CyberCoin is a notational system. When the consumer transfers money into his/her wallet, it is legal record of the money, but not the money itself. When money is moved with CyberCoin, it is "noted" by existing banking networks and deducted or added to the proper account. Until delivery of the goods has reached the consumer's computer through the transfer of the encrypted key, the funds will not be moved. When it is confirmed that the message digest has reached the consumer's hard disk, the money is instantaneously moved to the merchant's "CashRegister." At the close of each business day, the true funds are reconciled within the existing banking networks, similar to the ways bank accounts are managed today. In a CyberCoin transaction, the financial information is encrypted and digitally signed, but the message itself is not. The CyberCoin system is completely private, but it is not "anonymous" - the consumer always has a record of his/her transactions and can prove them but the merchant will not know the consumer's identity unless the consumer reveals it. As a consumer is not asked to show an ID when purchasing an item with cash in the real world, it is the same when making a purchase with CyberCoin on the Internet. The consumer's Electronic Wallet keeps a transaction log or "receipt" of every transaction ever made. These receipts are claimed to "act the same as any receipt in the physical world". CyberCash protects the consumer through the use of 768-bit RSA encryption with the password-protected wallet. CyberCash is also working with VeriSign to incorporate Digital IDs for instantaneous validation of an individual and merchants identity. Usage (Market segment and penetration) Merchant CyberCoin software is available for free from CyberCash on the Solaris and BSDI platforms. Windows NT merchant software will be available by the end of 1996. There is a limit on CyberCoin transactions of $80 a month which is likely to limit the practicability of its use. In the US funds in the CyberCoin system are FDIC insured. For the consumer this guarantees that if the CyberCoin issuing bank goes out of business, the consumer's money is insured by the Federal government. It is unclear at present what restrictions would be place on the use of this service outside of the US, but the use of a 768-bit RSA encryption algorithm would seem to make export of CyberCoin problematical. CyberCash says that it "is working towards a solution to support global currency transactions". CyberCash's electronic cheque exchange service will not be available until at least 1997. In August 1997 CyberCash announced the setting up of a Yen-based service in Japan, including a CyberCoin service for transactions as small as 25 Yen. Further details available from: Version 0.8 of the CyberCash protocol, which was issued in February 1996, can be obtained fromftp://ds.internic.net/rfc/rfc1898.txt.
|
HBCIExpanded nameHomebanking Computer Interface Area covered Sponsoring body and standard details
Characteristics/description HBCI uses the ISO 8859 character set. The EDIFACT-like syntax is based on the use of 5 delimiters:
An HBCI message consists of a message header, a signature header, one or more business message segments, a signature trailer and a message trailer. An optional ciphering header allows tailored security facilities to be added to the message. Processing of messages can be done synchronously or asynchronously Banks are identified using Bank Parameter Data (BPD). Users are identified using User Parameter Data (UPD). Data can be encrypted using symetrical Data Encryption Algorithm (DEA) keys, defined using the Data Encryption Standard (DES) and stored in a ZKA chipcard, or by using software-generated assymetrical RSA keypairs, Usage (Market segment and penetration) Further details available from: A (German) website has been set up at http://members.aol.com/sxsigma/hbci.htm. |
JEPIExpanded nameJoint Electronic Payments Initiative Area covered Sponsoring body and standard details
Characteristics/description Usage (Market segment and penetration) Further details available from: |
MPTPExpanded name Area covered Sponsoring body and standard details Characteristics/description MPTP involves three parties, a customer C who makes the payment, a vendor V who receives the payment and a broker B who keeps accounts for the parties concerned. At present only a single broker model is considered: this means that both customer and vendor must share the same broker. MPTP permits use of double payment chains. This allows implementation of a broker mediated satisfaction guarantee scheme. The pair of payment chains represent the high and low watermarks for the payment order. The low watermark chain represents the amount that the customer has fully committed to pay. The high watermark chain represents partial commitments. The vendor exposure is the difference between the counter values. MPTP provides protection against double spending through vendor and broker checking of authority identifiers. MPTP supports use of multiple payment counters denoting different units of currency. MPTP permits use of both shared secret and public key based signature schemes. Usage (Market segment and penetration) Further details available from: The current draft for this protocol can be obtained from http://www.w3.org/pub/WWW/TR/WD-mptp. |
OFXExpanded nameOpen Financial Exchange Area covered Sponsoring body and standard details
Characteristics/description Open Financial Exchange uses widely accepted open standards for data formatting (such as SGML), connectivity (such as TCP/IP and HTTP) and security (such as SSL). Open Financial Exchange defines the request and response messages used by each financial service as well as the common framework and infrastructure to support the communication of those messages. Open Financial Exchange 1.0.2 specifies the following services:
Usage (Market segment and penetration) Further details available from:
|
SETExpanded name Area covered Sponsoring body and standard details Characteristics/description In an SET transaction, the electronic processing of the transaction begins with the cardholder. Cardholders can visit Web pages, selecting items for inclusion on an order. Once the cardholder finishes shopping, the merchant's Web server can send a completed order form for the cardholder to review and approve. Once the cardholder approves the order and chooses to use a bankcard for payment, the SET protocol provides the mechanisms for the cardholder to securely transmit payment instructions as well as for the merchant to obtain authorization and receive payment for the order. In SET, message data will initially be encrypted using a randomly generated symmetric encryption key. This key, in turn, will be encrypted using the message recipient's public key. This is referred to as the "digital envelope" of the message and is sent to the recipient along with the encrypted message itself. After receiving the digital envelope, the recipient decrypts it using his or her private key to obtain the randomly generated symmetric key and then uses the symmetric key to unlock the original message. SET uses a distinct public/private key pair to create a "digital signature". Authentication is further strengthened by the use of certificates issued by a trusted third party "Certificate Authority". Within SET, dual signatures are used to link an order message sent to the merchant with the payment instructions containing purchaser account information sent to the Acquirer. Cardholders must register with a Certificate Authority (CA) before they can send SET messages to merchants. In order to send SET messages to the CA, the cardholder must have a copy of the CA public key-exchange key, which is provided in the CA key-exchange certificate. Usage (Market segment and penetration) Further details available from: An informative overview of the role of SET can be found in the January 1997 issue of The Information Interchange Report.
|
This information set on OII standards is maintained by Martin Bryan of The SGML Centre and Man-Sze Li of IC Focus on behalf of European Commission DGXIII/E. File last updated: January 1998 |
|
|
|