WO2003073389A2 - Authentication arrangement and method for use with financial transactions - Google Patents

Authentication arrangement and method for use with financial transactions Download PDF

Info

Publication number
WO2003073389A2
WO2003073389A2 PCT/BE2003/000036 BE0300036W WO03073389A2 WO 2003073389 A2 WO2003073389 A2 WO 2003073389A2 BE 0300036 W BE0300036 W BE 0300036W WO 03073389 A2 WO03073389 A2 WO 03073389A2
Authority
WO
WIPO (PCT)
Prior art keywords
message
merchant
purchase
cardholder
authentication
Prior art date
Application number
PCT/BE2003/000036
Other languages
French (fr)
Other versions
WO2003073389A3 (en
Inventor
Fikret Ates
Original Assignee
Mastercard Europe Sprl
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mastercard Europe Sprl filed Critical Mastercard Europe Sprl
Priority to US10/506,016 priority Critical patent/US10395462B2/en
Priority to DE60317169T priority patent/DE60317169T2/en
Priority to KR10-2004-7013441A priority patent/KR20040089682A/en
Priority to AU2003209860A priority patent/AU2003209860A1/en
Priority to JP2003572002A priority patent/JP4597529B2/en
Priority to EP03742900A priority patent/EP1479052B1/en
Priority to MXPA04008410A priority patent/MXPA04008410A/en
Priority to BR0308111-7A priority patent/BR0308111A/en
Publication of WO2003073389A2 publication Critical patent/WO2003073389A2/en
Publication of WO2003073389A3 publication Critical patent/WO2003073389A3/en
Priority to US12/584,704 priority patent/US8909557B2/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/388Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409Device specific authentication in transaction processing
    • G06Q20/4097Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1025Identification of user by a PIN code

Definitions

  • the present invention relates generally to a payment system and method using a computer network such as a wide area data network. More specifically, the present invention relates to an authentication arrangement which is part of a payment system and a corresponding method executed over an open network such as the Internet using an Integrated Circuit Card. The present invention also relates to software for implementing the authentication arrangement and method.
  • a client server on a client terminal controls the interaction with a consumer and interfaces to a card reader which accepts the consumer's smart card.
  • a payment server on the Internet includes a computer and terminals that handle the transaction and data store.
  • Also connected over the Internet is a merchant server advertising the goods and/or services offered by a merchant for sale on a web site. The merchant contracts with an acquirer to accept smart card payments for goods and/or services purchased over the Internet.
  • a consumer uses his smart card at the client terminal in order to purchase goods and/or services from the remote merchant server.
  • Fig. 1 is a schematic representation of a user terminal or main access device 1 , e.g. for accessing and browsing the Internet.
  • the terminal 1 includes a central processor unit (CPU) 2 which is connected with memory 4 and input/output (I/O) devices 6 via a bus 3 for two way communication.
  • I/O devices 6 may be a keyboard for entering data and a screen such as a visual display unit, e.g. a liquid crystal (LCD) or light emitting diode (LED) display, a CRT for displaying the progress of the transaction and or for displaying messages or prompts.
  • a visual display unit e.g. a liquid crystal (LCD) or light emitting diode (LED) display
  • CTR for displaying the progress of the transaction and or for displaying messages or prompts.
  • One of the I/O devices 6 may be a card reader 7 with which an Integrated Circuit Card (ICC) 5 may be read when it is introduced into a receiving slot in the reader 7.
  • the card reader 7 may be a standalone device for reading the ICC 5.
  • One of the I/O devices 6 may be also a modem 9 for accessing the Internet via an Internet Service Provider (ISP), e.g. a 56K, an ADSL, a wireless or a cable modem.
  • ISP Internet Service Provider
  • the actual form of the terminal may vary greatly, and may include a processor such as the PentiumTM family of microprocessors supplied by Intel Corp. USA.
  • the terminal 1 is all situated at one location, the various parts of the terminal such as the card reader 7, the I/O devices such as the keyboard and the display, the modem and the processor may located at different positions and connected by cables, wireless transmission or similar or be part of a local area network or interconnected by telecommunications networks.
  • Fig. 2 is a schematic representation of an Integrated Circuit Card (ICC) 5.
  • the ICC 5 includes at least an input/output (I/O) port 10 and some permanent storage, e.g. a non- volatile memory which may be provided, for instance, by a an EEPROM 15 connected to the I/O port 10 via a bus 17 or by battery-backed random access memory (RAM).
  • the I/O port 10 can be used for communication with the terminal 1 via card reader 7.
  • An integrated circuit card is a card into which one or more integrated circuits are inserted to perform at least memory functions.
  • the ICC 5 may be a self-contained portable intelligent card and include a read/writable working memory e.g.
  • card ICC 5 can operate as a microprocessor, e.g. read only memory 13 for storing code, a sequencer 16 and connections with the card reader 7 for receiving the voltage sources Vss and NDD, a reset for the processor 12 and clock CLK to the sequencer 16.
  • the ICC 5 can be used as bank card, credit card, debit card, electronic purse, health card, SIM card or similar. Other features of the microcontroller may be present but are not shown, such as a clock, a random number generator, interrupt control, control logic, a charge pump, power connections, and interface contacts that allow the card to communicate with the outside world.
  • an encryption module (not shown) is an optional hardware module used for performing a variety of encryption algorithms.
  • E-commerce merchants provide a web server with web-site access to commodities or services which can be accessed from user terminals as shown in Fig. 1 usually via web pages and these commodities and services may be purchased using cards such as the ICC 5 of Fig. 2.
  • Many e-commerce merchants currently support cardholder profiling. Cardholder profiling consists of collecting information about the cardholder and using this data to streamline the cardholder's checkout process. The information collected typically includes billing address, shipping address, payment method details (e.g., card number and expiration date), email address and communication preferences. Most merchants also support non-profiled checkout.
  • the non-profiled checkout process requires the cardholder to manually provide full shipping, billing and payment details.
  • E-commerce merchants have implemented a variety of on-line checkout processes in an attempt to make the on-line shopping and purchase experiences more efficient for cardholders.
  • a number of merchants have implemented an express checkout process (Fig. 3) intended to provide the cardholder with a streamlined purchase process by making full use of cardholder data and payment details stored in a profile database managed by the merchant. After browsing and selecting a particular item, or items, the Cardholder selects the express checkout option. The Merchant retrieves the Cardholder's profile, and presents a page at the user terminal combining details of the order and Cardholder's payment details. The Cardholder can review these details and submit/confirm the order.
  • Single-click checkout processes have been implemented by many merchants (see Fig. 4).
  • the single-click checkout process is intended to provide the cardholder with the most efficient on-line purchase process available by making full use of cardholder data and payment details stored in a profile database managed by the merchant.
  • the Cardholder selects the single click order option which is generally available on all pages where an item's details and price are described.
  • the customer can either add the item to their 'shopping basket', or order and pay for it with a 'single click'.
  • the Merchant combines the details of the order and Cardholder's payment details to create an order, which is then acknowledged in a page to the Cardholder.
  • Customers can usually cancel, amend or even combine multiple single click orders after the initial single-click through some form of customer administration/status page.
  • the Cardholder After browsing and selecting a particular item, or items, the Cardholder selects the standard checkout option.
  • the Merchant presents a page showing details of the order and requesting the Cardholder's payment details.
  • the Cardholder can review the order details, supply their payment details and if necessary other pertinent personal information and submit/confirm the order. In some cases this combined order details confirmation/payment details requesting page can be split into two pages, as shown in Fig. 5.
  • the present invention meets the goals of Cardholder authentication in financial transaction environments that traditionally suffer from chargebacks because no evidence could be provided that the Cardholder actually authorised the financial transaction. It offers a mechanism for securing the Internet channel by strongly authenticating the Cardholder at the point-of-interaction (POI) and providing explicit evidence both of card presence and that the Cardholder originated the transaction.
  • POI point-of-interaction
  • the invention has a number of goals including at least one of: • Reducing chargebacks due to reasons of Cardholder non-authorised transactions.
  • the present invention provides a computer-based authentication scheme, in particular the present invention provides a computer implemented method and system for providing financial transactions via the Internet.
  • the present invention in one aspect provides an authentication arrangement for use in a network payment system for transacting a sale of merchandise over a network using an Integrated Circuit Card, said authentication arrangement comprising: a merchant server in communication with said network, said merchant server having at least a first item of merchandise for sale; a client terminal in communication with said network, said client terminal having an output device for reviewing said first item for sale, and an input device for initiating a purchase transaction to purchase said first item for sale, said client terminal being arranged to build a purchase message using information relating to a merchant identifier and financial transaction information obtained from said merchant server; a card reader for communicating with said Integrated Circuit Card, said client terminal having means to generate a challenge message, said challenge message being generated from the information relating to the merchant identifier and an account number, means for receiving the challenge message at the card reader and for generating a value from the challenge message.
  • the value is a preferably a value which is not predictable by the ICC.
  • the ICC has means for generating a cryptographic message from at least a part of said value, and the card reader has means to generate an authentication token from at least a part of the cryptographic message.
  • the client terminal has means for transmitting at least part of the authentication token in a message for transmission via the network.
  • the transmission may be to the merchant server.
  • the network may have a transaction approvals server for approving financial transactions, and the transmission is to said approvals server.
  • Said means to generate a challenge message may be adapted to generate the challenge message from the information relating to the merchant identifier, an account number and at least one of a purchase amount and a purchase currency.
  • the means for transmitting at least part of said authentication token may be adapted to transmit the at least part of said authentication token to the merchant server and the merchant server is adapted to transmit the at least part of said authentication token to the transaction approvals server with purchase information in an authorization request message.
  • the means to generate a challenge message may be adapted to concatenate the merchant identifier and the account number and optionally at least one of a purchase amount and a purchase currency.
  • the means to generate a challenge message may be adapted to compress the concatenation of the merchant identifier, and the account number and optionally at least one of a purchase amount and a purchase currency, whereby the compression may be application of a hash function.
  • the approvals server may rebuild at least part of the authentication token and compare the rebuilt message with the at least part of the authentication token in the authorization request message transmitted from the merchant server.
  • the transaction approvals server may be adapted to send an approval message to the merchant server if the comparison is positive.
  • the Integrated Circuit card may have a memory and a first data object stored in said memory and the means for generating an authentication token from at least a part of the cryptographic message may be adapted to select a part of the part of the cryptographic message in accordance with the first data object.
  • a second data object may stored in said memory and the means to generate a challenge message may includes at least one of a purchase amount and a purchase currency in the generation of the challenge message in accordance with the second data object.
  • the present invention provides a method for authentication as part of transacting a sale of merchandise over a network using an Integrated Circuit Card, the method comprising: establishing a communication between a merchant server with a client terminal over said network, said merchant server having at least a first item of merchandise for sale; reviewing said first item for sale on said client terminal, initiating a purchase transaction to purchase said first item for sale and building a purchase message using information relating to a merchant identifier and financial transaction information obtained from said merchant server; generating a challenge message on the client terminal the information relating to the merchant identifier and an account number, receiving the challenge message at a card reader and for generating a value from the challenge message; establishing a communication between the Integrated Circuit card and the card reader and generating a cryptographic message from at least a part of said value, generating an authentication token on the card reader from at least a part of the cryptographic message, and transmitting at least part of the authentication token in a message from the client terminal for transmission via the network to an approvals server.
  • Generating a challenge message may comprise concatenating the merchant identifier and the account number and optionally at least one of a purchase amount and a purchase currency.
  • Generating a challenge message may comprise compressing the concatenation of the merchant identifier, and the account number and optionally at least one of a purchase amount and a purchase currency, e.g.
  • the method may include rebuilding at least part of the authentication token at the approvals server and comparing the rebuilt message with the at least part of the authentication token in the authorization request message transmitted from the merchant server followed by sending an approval message to the merchant server if the comparison is positive.
  • the Integrated Circuit card may have a memory and a first data object stored in said memory, the method further comprising generating an authentication token from at least a part of the cryptographic message by selecting a part of the part of the cryptographic message in accordance with the first data object.
  • the method may further comprise generating a challenge message from at least one of a purchase amount and a purchase currency in accordance with the second data object.
  • the present invention can address all channels and transaction types for remote transaction by defining four building blocks that should constitute the basis for a guarantee in any environment: a) A CAM function, i.e. evidence that the card/account is genuine, b) A CNM function, i.e. evidence that the cardholder is genuine, c) Proof of transaction authorisation by the Issuer, d) A description of the transaction environment.
  • a first category of transactions suitable for such services is Electronic Commerce payments, both Internet-based "e-commerce” and wireless-based "m-commerce". Since the model is generic, it can be used consistently across multiple channels and can be extended to other environments including Mail Order or Telephone Order. Indirect cardholder benefits are: • Reduction of perceived risk.
  • Fig. 1 shows a main access device which can be used with the present invention.
  • Fig. 2 shows an Integrated Circuit card which may be used with the present invention.
  • Fig. 3 shows a known Express Checkout Page Flow.
  • Fig. 4 shows a known Single-Click process flow.
  • Fig. 5 shows a known standard process flow.
  • Fig. 6 shows how bytes are described.
  • Fig. 7 shows an authentication system in accordance with an embodiment of the present invention.
  • Fig. 8 a more detailed flow of an authentication system in accordance with an embodiment of the present invention.
  • Fig. 9 shows an IIPB Data Structure in accordance with an embodiment of the present invention.
  • Fig. 10 shows a UCAF Structure in accordance with an embodiment of the present invention.
  • Fig. 11 shows encoding of an AAV in an embodiment of the present invention.
  • Fig. 12 shows 'Filler Set to 0' vs. 'Data Set to 0'.
  • Fig. 13 shows a process flow to form a PCR challenge in accordance with an embodiment f the present invention.
  • Fig. 14 shows 8 digits from a Challenge giving up to 27 bits of UN in accordance with an embodiment of the present invention.
  • Fig. 15 shows Bit Extraction and Compression in accordance with an embodiment of the present invention.
  • Fig. 16 shows an example of Conversion of Required Data Bits from Base 2 to a Base
  • FIG. 17 shows an overview of the flow process according to an embodiment of the present invention.
  • Fig. 18 shows a flow process from the completion of the purchase to merchant acceptance according to an embodiment of the present invention.
  • Fig. 19 shows a modified Express Checkout Page Flow according to an embodiment of the present invention.
  • Fig. 20 shows a modified Single-Click process flow according to an embodiment of the present invention.
  • Fig. 21 shows a modified standard process flow according to an embodiment of the present invention.
  • Fig. 22 shows a card activation process flow according to an embodiment of the present invention.
  • Fig. 23 shows a PCR-ICC interchange process flow according to an embodiment of the present invention.
  • Fig. 24 shows a process flow from card activation until token generation according to an embodiment of the present invention.
  • the present invention relates to an ICC Authentication Programme, e.g. for e- commerce applications using a Personal Card-reader (PCR) which generates authentication tokens for transport to the Issuer in a Universal Cardholder
  • PCR Personal Card-reader
  • the present invention includes a functional architecture of a scheme used to achieve ICC based authentication using a personal card-reader, for Internet based e-commerce transactions via the UCAF.
  • the bytes are not numbered in a most/least significant byte style as for values. At times this will result in the most significant byte of a numeric data element, e.g. Application Transaction Counter, being referred to as Byte 1 and the least significant as Byte 2.
  • Bits on the other hand are identified in the reverse manner where the most significant bit is the 'first' bit and is referred to as Bit 8, whilst the least significant bit is the 'last' bit and is referred to as Bit 1. See Fig. 6. Where a number is given/illustrated and its number base is not described it shall be assumed to be decimal (Base 10). Where a number is given/illustrated with a leading 'Ox' it shall be assumed to be hexadecimal (Base 16).
  • AFL Application File Locator identifies what records are available where in the ICC.
  • AID Application Identifier the hex string which identifies a given application in the ICC.
  • AIP Application Interchange Profile indicates the capabilities of the
  • ARQC Application ReQuest Cryptogram ATC Application Transaction Counter BCD Binary Coded Decimal Big-Endian An encoding style where a value is stored with its most significant byte first followed by each successive byte, with the least significant byte stored last.
  • CVM Cardholder Verification Method the method used to verify a cardholder to the card.
  • HTML page supplied by a browser to a plug-in.
  • HHD Hand held device e.g. a card reader
  • IAF Internet Authentication Flags the first byte of the IIPD.
  • ICC Integrated Circuit Card also known as Chipcard or Smartcard.
  • MAC Message Authentication Code A cryptographic signature calculated over data items in a message to both prove the origin of the message and to allow detection of whether those data items have been modified.
  • MCD Main Cardholder Device the device on which the browsing and/or ordering and/or payment is being performed on.
  • Nibble Haifa byte i.e. 4 bits.
  • PI Parameter 1 of an APDU, it effectively customises the command being sent to the ICC.
  • PDA Personal Digital Assistant PDOL Processing Options Data Object List the list of processing options available to/supported by the terminal (i.e. PCR).
  • the Authentication scheme according to the present invention is a use of the Universal Cardholder Authentication Field (UCAF). This scheme will be referred to as Chip- UCAF for convenience only. The term itself does limit the present invention.
  • the present invention provides secure authentication methods that take advantage of the UCAF infrastructure. It comprises the following elements:
  • Chip-UCAF Accountholder Authentication Value (AAV) generation • Chip-UCAF Accountholder Authentication Value (AAV) generation.
  • Cardholder The cardholder initiates the transaction and is responsible for entering data into both the merchant's payment web pages, the Cardholder Interface Application, and the Personal Card-reader.
  • Merchant The merchant supplies, e.g. from a merchant server in communication with the Internet, the data necessary to start the authentication transaction and receives the resultant UCAF data to forward, via their acquirer, to the card issuer for approval.
  • Cardholder Interface Application The Cardholder IA detects the relevant data supplied by the merchant and interacts with the cardholder directly and indirectly, through the cardholder, with the Personal Card-reader. The Cardholder IA creates the AAV and UCAF and populates the merchant's page with the appropriate data. For example, the Cardholder IA can run as part of an Internet browser on the main cardholder device (MCD) being used to access the merchant on the Internet.
  • MCD main cardholder device
  • Personal Card-Reader The PCR interacts with the Cardholder, and the ICC to produce an authentication token that is passed, indirectly, to the Issuer.
  • ICC the chip card authenticates the Cardholder through the use of submitted PIN verification and generates a suitable cryptogram based on data supplied by the PCR.
  • Acquirer An acquirer accepts the formatted UCAF data from a merchant, e.g. at an acquirer server, and forwards it, with an indicator of the use and presence of UCAF data, to the issuing bank via the appropriate telecommunications network. Mastercard is an acquirer.
  • Issuer The card issuer distributes PCRs to those cardholders that are signed up to the Chip-UCAF scheme.
  • the issuer maintains an issuer server platform in communication with the Internet.
  • the Issuer server validates the authentication token encoded into the UCAF, transmitted in the authorisation request by an acquirer, according to the rules of that issuer.
  • the present invention provides authentication for e-commerce payment services.
  • Cardholder presence status is provided for transactions that are online to the Issuer.
  • the classical authorisation route through the existing payment scheme network can be used.
  • a Personal Card-reader is used operating either as a stand-alone device or connected to/integrated with the Cardholder's access device (e.g. Laptop, PC, pocket PC, smart phone, palm pilot, PDA).
  • the reader preferably has a display and keypad for allowing limited Cardholder interaction.
  • the specifications for the Personal Card-reader should preferably allow a maximum possible number of different card implementations whilst at the same time catering for Cardholder convenience.
  • the Personal Card-reader should preferably have the display capability to show the PIN validation result, and for unconnected devices a token which must be entered by hand on the main cardholder device.
  • the Personal Card-reader must be capable of obtaining from the ICC an indication from the Issuer of the data that must be transferred to them in order to allow the ICC signature to be verified.
  • the Personal Card-reader should preferably be capable of obtaining from the ICC an indication from the Issuer as to whether or not to incorporate the amount and currency of the transaction in the generated token. When such an indication is made the reader must be capable of allowing the Cardholder to enter the amount and associated numeric currency code.
  • the transaction amount is to be entered by the Cardholder, it is preferably in a 'natural' format, i.e.
  • the UCAF (Universal Cardholder Authentication Field) data field is a multipurpose data transport area in a digital message to allow communication of authentication data to an Issuer from an Acquirer over any form of telecommunications network.
  • the UCAF can be a 32-character field (24 bytes - 1 control byte and 23 data bytes - that are base-64 encoded to become 32 characters) with a flexible data structure that can be tailored to support the needs of a variety of Issuer security and authentication requirements.
  • ISO 8583 Data Element 48, sub-element 43 may be designated to contain the UCAF.
  • the term UCAF also extends to referring to the interface defined to pass data between the Merchant and the MCD and back again, i.e.
  • the Accountholder Authentication Value is the term given to a part, e.g. the 23 bytes, of UCAF application specific data.
  • AAV Accountholder Authentication Value
  • Each UCAF application is responsible for determining the appropriate structure for its AAV. Every instance of an implementation of a given UCAF application must use that application's AAV structure in a consistent manner, i.e. the AAV format is standardised for a given UCAF application.
  • Chip-UCAF cardholder authentication scheme In order to use the Chip-UCAF cardholder authentication scheme the cardholder needs to have an appropriate ICC payment card and a Personal Card- reader.
  • the PCR will be supplied to the cardholder by their card issuer, who will register that that cardholder has a PCR and is 'enrolled' in the Chip-UCAF cardholder authentication scheme.
  • the UCAF transaction data supplied by the Merchant is used for display purposes and some of it is used in generating a transaction related PCR Challenge. There is no additional processing that Merchants need to perform on the AAV data within the UCAF response. This is indicated to the Merchant through the UCAF Control Byte value being set to the value for Chip-UCAF.
  • the Cardholder Interface Application provides the interaction between the authentication requirer (Merchant), the cardholder and the PCR.
  • the Interface Application presents the secure face of the present UCAF scheme to the cardholder. It is responsible for presenting the transaction data to the cardholder, generating the challenge transferred to the PCR, receiving the PCR Token response, formatting the UCAF and populating the return data for the given channel.
  • the Cardholder IA has a minimum set of requirements it must meet in order to effect a Chip-UCAF transaction. It may also add additional functionality such as intelligent form filling, receipt tracking/logging, integration with personal finance software etc.
  • the Main Cardholder Device is the device on which the browsing/shopping is probably carried out and, for the scope of this specification/scheme, the payment and authentication process is certainly carried out.
  • the present invention will be described with reference to a PC device on some platform in an Internet browser environment.
  • the Cardholder IA must execute in this environment.
  • the Personal Card-reader is a device to enable PIN entry and validation, e.g. off-line and authentication of transaction context data by a cardholder's ICC inserted in the device, for the purposes of e-commerce transactions.
  • An unconnected PCR may be used with the present invention, i.e. a device that has no physical/electrical connection with any outside system and whose interface for data into and out of the device is the cardholder, via the keypad and display. Personal Card- readers with other types of connection may also be used.
  • An unconnected PCR device has no physical/electrical connection with any outside system.
  • the interface for data into and out of the device is a keypad a display for interaction with a person, i.e. the cardholder.
  • the cardholder When using an unconnected device, the cardholder must manually enter, in addition to a PIN, certain data that the PCR will use, in conjunction with the card, in order to generate an authentication value.
  • the authentication value is displayed on the PCR's display for the cardholder to then manually enter into the Cardholder Interface Application. Check digits are used to enable data entry validation.
  • PCR connected devices allow more data to be transferred to the MCD, without the inconvenience to the cardholder of passing the data manually.
  • Connected devices may be devised which can operate in unconnected mode when the connection cable is removed.
  • a PCR one-way connected device is connected to the MCD in the out direction only.
  • the interface for data into the device is the keypad. It has a display for interaction with a cardholder.
  • the cardholder again acts as the data transport mechanism between MCD and the PCR.
  • the cardholder must manually enter, in addition to their PIN, certain data that the PCR will use, in conjunction with the card, in order to generate an authentication value.
  • the authentication value is sent out to the MCD through the one-way connection.
  • a two-way PCR connected device is connected to the MCD in both directions.
  • the device has a keypad for cardholder PIN entry and a display for interaction with the cardholder. The cardholder need only enter their PIN.
  • the MCD can transfer all of the data that the PCR will use, in conjunction with the card, in order to generate an authentication value. The authentication value is sent out to the MCD.
  • An integrated PCR device is an MCD that has a direct connection to a smartcard reader.
  • the terminology is meant to apply to PDAs with built in smartcard readers, but the technology could equally well be a desktop PC with a directly connected smartcard reader.
  • the cardholder need only enter their PIN.
  • the MCD performs all of the PCR functionality and transfers commands directly to the ICC through the connected reader.
  • the response from the ICC is processed by the MCD itself.
  • the software is written in such a way that the Cardholder IA is able to behave in the same way as for a two-way connected device, i.e. when communication is made out to the PCR by the Cardholder IA, the drivers send & receive the data to & from a PCR that 'just happens to be' on the same MCD.
  • a connected and integrated PCR device would be a self-contained PCR, integrated into the MCD. The requirements for such a device are no different to those for a connected device, and may be integrated into a PC
  • the UCAF enabled Acquirer has a relationship with a UCAF enabled merchant.
  • the acquirers enable their merchants to pass the extra
  • UCAF data to the acquiring systems and enable their systems to identify the presence of and pass on supplied UCAF data to the issuing bank.
  • the Issuer Host or some other element acting, to the scheme, as the Issuer Host is responsible for taking the data passed in the authorisation network message, including the data in the UCAF, and enabling the authentication token to be validated.
  • the chip based functions described in the present invention essentially provide means of verifying the Cardholder presence to the Issuing bank, the present invention can also be implemented in remote banking environments ("e-" or "m-banking"). This would provide banks with a consistent Consumer authentication method across products, services and environments.
  • Chip-UCAF uses the UCAF infrastructure to transport authentication and security data between Cardholder, Merchant, Acquirer and Issuer.
  • Fig. 7 illustrates the process flow for a typical Chip-UCAF transaction in accordance with an embodiment of the present invention. This flow assumes that prior to conducting a transaction, the Cardholder has registered with their Issuer for the service, obtained and initialised the Cardholder Interface Application and obtained a Personal Card-reader that is compatible with their ICC card. It is also assumed the Cardholder has identified a product or service offered on the merchant server and has initiated the checkout process and has already been requested by the merchant to provide payment card details. Once the items are selected and the checkout phase begins, the Cardholder provides billing address, shipping address and payment card details to the merchant.
  • Billing and shipping address information can be entered directly or based on information stored at the merchant for the particular Cardholder.
  • the merchant's web server provides a series of hidden fields uniquely describing this transaction. For instance, this information may include one or several of;
  • the Cardholder's Interface Application acquires the merchant identifier information and the transaction data from the UCAF Authentication Page and builds a Challenge that is presented to the Cardholder.
  • the Cardholder inserts the payment card (ICC 5) in the Personal Card-reader.
  • the application implemented on the Personal Card-reader requests the
  • the Personal Card-reader may then extract the sale amount currency and request the Cardholder to enter the sale amount in that currency.
  • the Cardholder is then, as evidence of he/she agreeing to the transaction, invited to enter a personal security code, e.g. a PIN on the Personal Card-reader.
  • a personal security code e.g. a PIN on the Personal Card-reader.
  • Personal Card-reader requests the payment card (ICC) to verify the PIN.
  • ICC payment card
  • the Personal Card-reader requests the payment card (ICC) to sign the transaction-related data (i.e. the challenge) using a suitable encryption routine.
  • the ICC returns a cryptogram (MAC) over the transaction data and other ICC specific data that the Card Issuer will need to validate the cryptogram.
  • MAC cryptogram
  • the Personal Card-reader then builds a data token using part of the cryptogram and the variable data identified by the Card Issuer.
  • the Personal Card-reader formats the data token and presents it to the Cardholder who will enter it at the Cardholder Interface Application either manually or by transmission.
  • the Cardholder Interface Application builds the AAV for inclusion in the UCAF.
  • the Cardholder Interface Application inserts the Chip-UCAF generated for this particular transaction into a hidden authentication data field provided on the Merchant UCAF Authentication Page.
  • the transaction is then submitted for authorisation processing by the Merchant.
  • the Merchant submits an authorisation request to its Acquirer.
  • the authorisation request must include the unaltered Chip-UCAF value that will be verified by the Issuer during authorisations processing.
  • the Acquirer accepts the (local) authorisation request and creates an authorisation request
  • the Authorisation Request Message includes the Chip-UCAF data.
  • the Authorisation Request Message is forwarded via a banking network to the Card Issuer.
  • the Acquirer and the Issuer need to agree on the UCAF specifications for any proprietary message format(s).
  • the banking network forwards the Authorisation Request Message, including the Chip-UCAF, to the Card Issuer.
  • the Card Issuer Upon receipt of the Authorisation Request Message, the Card Issuer will perform the following: a) If the Authorisation Request does not indicate that the Merchant was UCAF- enabled (e.g. Security Level Indicator bit set to '0' indicating "UCAF not supported by merchant", see later), the Authorisation Request will be processed in a business-as-usual manner by the Issuer's authorisation system.
  • the Issuer responds with an approval or declines based on the outcome of the previous step. This response is returned to the Merchant, via the same network systems, who will then respond to their customer as appropriate.
  • Chip-UCAF relies on certain security features. More specifically, Chip-UCAF relies on the generation of cryptograms by the ICC, namely the Application Request Cryptogram (ARQC) or the Application Authentication Cryptogram (AAC), to establish:
  • ARQC Application Request Cryptogram
  • AAC Application Authentication Cryptogram
  • Chip-UCAF offers an adequate level of security to enforce the non-repudiation by the cardholder of Internet transactions.
  • Chip-UCAF The assessment of the level of security offered by Chip-UCAF is based on the following assumptions:
  • the Main Cardholder Device i.e. the platform used by the cardholder for performing the actual payment operation, is considered trusted. This applies to the physical device, e.g. a PC or a mobile phone, to the Interface Application (IA) generating the challenge and to the application communicating with the Personal Card-reader when relevant. Because of the uncontrolled nature of the MCD, this assumption is perceived valid for any similar product. • The security of sensitive payment details, e.g. PAN or expiry date, entered at the MCD and sent to the merchant is outside the scope of this product. The confidentiality of this data should be enforced by encryption of the link between the MCD and the merchant, e.g., by relying on SSL encryption, and by the protection of the card details on the merchant host system.
  • MCD Main Cardholder Device
  • IA Interface Application
  • the ICC establishes the proof of cardholder presence through the use of a validation, e.g. an off-line PIN validation.
  • a validation e.g. an off-line PIN validation.
  • Off-line PIN validation is required prior to the generation of an ARQC.
  • the cardholder presence is required to generate a valid ARQC, and the existence of such a valid cryptogram is sufficient to demonstrate this cardholder presence.
  • CVR Card Verification Results
  • Chip-UCAF uses a digest of the transaction description as input to the ARQC or AAC calculation. This digest is used as the UN field from the input parameters to the ARQC or AAC calculation. A successful validation of the cryptogram by the Issuer, combined with the proof of cardholder presence, provides some assurance on the approval of the transaction by the cardholder.
  • the ARQC or AAC calculation must effectively use the Unpredictable Number (UN).
  • UN Unpredictable Number
  • those ICCs that do not include the UN into the ARQC or AAC calculation input data should preferably not be used in the frame of the Chip-UCAF programme.
  • the ARQC or AAC generated by the ICC must vary as a function of the ATC. This is the case only when the ATC is included into the input data to the ARQC or AAC calculation. However, such behaviour is not mandatory. Therefore, those ICCs that do not include the ATC into the ARQC or AAC calculation input data should preferably not be used in the frame of the Chip-UCAF programme.
  • the main security issue associated with the use of a Personal Card-reader device is the risk of disclosure of the card PIN or of card-stored sensitive information, such as ISO2 track, by the device itself. Fraudulent or tampered Personal Card-readers may endanger the confidentiality of the PINs or ISO2 track.
  • the level of risk depends on the type of device:
  • the ARQC or AAC as returned by the ICC need not transferred completely to the Issuer. They can be truncated as specified by the IIPB and so the IIPB must be defined in such a way that a certain number of bits, e.g. at least 16 bits, from the ARQC or AAC are included into the data token returned by the Personal Card-reader. Because of the reduced size of the truncated cryptograms, fraud detection systems should be in place to detect abnormal numbers of failed cryptogram validations and take any appropriate action.
  • the ARQC or AAC should be validated by the Issuer on the basis of the information provided by the merchant. That is, in the verification process, the issuer should build the challenge from the original input data rather than relying on a challenge provided by the cardholder device. This requires that the input data is sent to the Issuer from the merchant as well as the special authentication token in accordance with the present invention.
  • a card used to calculate the Application Cryptogram must use the CVR as input to the calculation. Cards which do not so must not be used for Chip-UCAF authentication.
  • a card used to calculate the Application Cryptogram must use the UN as input to the calculation. Cards which do not so must not be used for Chip-UCAF authentication.
  • a card used to calculate the Application Cryptogram must use the ATC as input to the calculation. Cards which do not so must not be used for Chip-UCAF authentication. Issuers should ensure that an ATC is not reused.
  • Issuers should ideally employ fraud detection systems to detect and act on abnormal numbers of failed cryptogram submissions.
  • the Issuer should rebuild the challenge data for verification of the cryptogram from the authorisation message, rather than rely on that supplied by the Cardholder's software in the UCAF itself.
  • Fig. 8 shows detailed PCR and Chip-UCAF Flows in accordance with an embodiment of the present invention.
  • This diagram and following text serve as illustrations only of an embodiment of the present invention and of the steps involved in the Chip Authentication Programme, starting from the point where the Merchant supplies the UCAF Merchant Data on a UCAF Authentication Page to the point where the Merchant receives the Authorisation Response from their Acquirer. Further, the particular order of some steps is arbitrary or rather not compulsory, e.g. Card Inserted at step 8. For the purposes of this embodiment it is assumed that the Main Cardholder
  • the UCAF Merchant Data is presented in hidden HTML form fields.
  • This embodiment assumes that an unconnected PCR is used. Where an unconnected or one-way connected device displays a prompt to the Cardholder to enter some data, not including PIN entry, the two-way connected or integrated device must request to the Cardholder IA that the same element of data be passed to it.
  • the precise mechanics of this communication protocol are proprietary to any implementation. Confirmation of the Authorisation from the Merchant to the Cardholder is not excluded from this invention.
  • Fig. 8 it is assumed that the Merchant has already collected the payment details, including PAN, Expiry Date, etc. and is at the stage in the order processing pipeline where the order and payment details can be finalised through a UCAF Authentication Page.
  • the Cardholder has already personalised his/her Cardholder IA with details of the PAN so that when the last 5 digits of the PAN being used for this payment are presented in the UCAF field, the Cardholder IA is able to recognise if it can act on behalf of that PAN.
  • Fig. 8 Referring to the numbering of Fig. 8: 1. Collate Transaction Data - The Merchant collates the transaction-related data required as per the UCAF specification. 2. Send Transaction Data - The Merchant transmits the transaction data through the mechanism defined for the given e-commerce channel, as defined by the UCAF specification for that channel. 3. Detect UCAF Fields - The Interface Application (IA) installed on the Main Cardholder Device (MCD), detects the presence of the UCAF hidden fields, determines that a number, e.g. the last 5 PAN digits supplied by the Merchant relate to a PAN already known to the IA, validates the remaining UCAF data and presents itself. 4. Display Transaction Data - The IA displays the transaction-related data to the
  • the Interface Application may request the Cardholder to confirm that the card details it has selected are correct. This may take the form, for example, of reminding the Cardholder which card to physically use in the PCR, e.g. perhaps through the use of a 'friendly' identifier the Cardholder associated with the particular card when personalising the Cardholder IA with the card details.
  • the Interface Application causes the PCR Challenge to be generated from certain transaction data + PAN.
  • PCR Challenge is transferred to the PCR.
  • the Cardholder does this by entering the challenge into the PCR, in response to the prompt from the Interface Application and the PCR itself. Otherwise it can be transmitted to the PCR.
  • PCR Token The PCR token is transferred from the PCR.
  • the Cardholder does this by entering the PCR Token into the Interface Application, in response to the prompt from the Interface Application and the display on the PCR. Otherwise it can be transferred automatically.
  • UCAF The Interface Application encodes the Chip-UCAF structure, sets the UCAF Control Byte and then Base64 encodes it for transmission in the UCAF. 19.
  • Authorisation Request - The Merchant passes the authorisation data, including the UCAF to their Acquirer, who passes it on to the appropriate Issuer.
  • SLI Security Level Indicator
  • ISO 8583-0100 The Acquirer forwards the Authorisation Request to the Issuer who then performs some initial standard processing on the message.
  • UCAF Processing The Issuer checks for the presence of UCAF.
  • Rebuild Challenge The challenge to the PCR is recreated from the message data to allow the Unpredictable Number to be regenerated.
  • 26. retrieve Card Data - The Issuer must retrieve certain data elements from the ICC database in order to be able to rebuild.
  • Steps 1 to 21 are specific to this scheme.
  • the Merchant collating and presenting the transaction data in a particular, specified format. • The Cardholder's main access device, Cardholder Interface Application, the PCR and the Cardholder themselves causing the PCR Token to be generated and returned to the Merchant.
  • Step 22 shows extra steps an acquirer must take when handling UCAF data
  • the Acquirer is responsible for setting the Security Level Indicator depending on the data supplied by the Merchant.
  • Step 23 is a summary of the existing transmission of payment data to the Acquirer and then on to the Issuer, via the ISO 8583 - 0100 Authorisation Request message;
  • Steps 24 to 28 are specific to this scheme.
  • the Issuer extracts the data from the UCAF and verifies the PCR Authentication Token.
  • Steps 29 and 30 are a summary of the existing ISO 8583 - 0110 Authorisation Request Response message and response to the Merchant;
  • Steps 2 and 19 show a solution that is independent of the e-commerce channel involved.
  • Steps 2 and 19 the link between the Interface Application and the Merchant Systems, are the points at which there is a dependency on the specifications for a given e-commerce channel.
  • different channels can be used and will require different Issuer software, in the form of the Interface Application, and probably different, but necessarily standardised merchant interaction, e.g. HTML forms, XML data exchanges, etc.
  • HTML forms e.g. HTML forms, XML data exchanges, etc.
  • data content, algorithms and flows remain the same across different channels.
  • the Merchant supplies details about themselves and the transaction. In summary these data elements are selected from;
  • the Issuer Internet Proprietary Data is a data object whose presence on a card is optional. It is unrelated to the similarly named Issuer Internet Proprietary Bitmap (IIPB), except for its introduction due to the Chip Authentication Programme. It contains data that the Issuer chooses to use in a proprietary manner, nominally in conjunction with the generation of the cryptogram when used in the Internet environment, although it may also carry other or alternative data. For example, the transfer of a Card Sequence Number (CSN) to the Issuer may be required. This is static for a given card and can be passed to the Issuer by encoding it into the IIPD. This CSN can be passed in the lower nibble of the first IAF 'byte'. This technique saves on cardholder data entry. Its use is literally proprietary to an Issuer.
  • CSN Card Sequence Number
  • the first byte of the IIPD carries a set of generic flags, predominantly for use by the Personal Card-Reader (PCR). Table 1 provides a schematic indication of these.
  • Bit 8 When Bit 8 is set to 1 , it signifies that the Issuer requires that the transaction amount and currency must be used when generating the AC. For the PCR this means it prompts/requests the Cardholder/Main Cardholder Access Device (MCD) to supply the currency and amount and for the Interface Application (IA) that the amount and currency need to be supplied.
  • MCD Cardholder/Main Cardholder Access Device
  • IA Interface Application
  • Bit 8 When Bit 8 is set to 0, default values for the amount (0) and currency (999 - Code used for transactions with no currency involved) will be used when generating the AC.
  • Bit 7 When Bit 7 is set to 1 , it signifies that the Issuer requires that the type of cryptogram to be requested from the card is an ARQC.
  • Bit 7 When Bit 7 is set to 0, it signifies that the Issuer requires that the type of cryptogram to be requested from the card is an AAC. IIPD data beyond the first byte is free for a use which is proprietary to the Issuer.
  • the IIPD is an optional structure, since its contents may not be required by a given chip implementation in order to generate cryptograms for Internet associated use. However since it contains indicators which instruct the PCR on how to proceed with processing, if it is not present then the PCR must rely on a default setting. If the card has no IIPD, then a default byte value of 0x40 can be used, e.g. "No transaction amount and currency, ARQC to be generated". The IIPD must be transmitted to the Issuer in the Accountholder
  • AAV Authentication Value
  • IA Cardholder Interface Application
  • the Cardholder IA must know the IIPD, or use the default value, e.g. 0x40, in order to determine whether or not the currency and amount need to be transferred to the PCR.
  • the currency information can be transferred as part of the PCR Challenge. Due to both the data space limitations imposed by UCAF compliance, and the need, at least for some Issuers, to use an unconnected or one-way connected device, the data that the device must transfer back to the MCD is size-limited. Therefore, only a selected portion of the data required by the Issuer to re-compute the AC, generated in response to the GenerateAC command sent to the ICC, is preferably transferred.
  • the response, by the ICC, to the first GenerateAC command is made up of the following elements;
  • ATC Application Transaction Counter
  • AC Cryptogram computed by the ICC
  • the Issuer Internet Proprietary Bitmap is a data object whose presence on a card is optional.
  • the data consists of transmit flags indicating which bits in the GenerateAC response are required by the Issuer Host system.
  • the flags correspond on a bit for bit basis to the bits that must be sent from the CID (e.g. 1 byte), ATC (e.g. 2 bytes), AC (e.g. 8 bytes) and IAD (e.g. 0 - 32 bytes) (see Fig. 9).
  • An IIPB can vary in length, e.g. from 11 bytes, where no IAD is defined to 43 bytes where an Issuer's application technology uses the full 32 bytes available to the Issuer Application Data (IAD).
  • the IIPB allows the Issuer to be completely selective as to which and how many bits of these values it will use for the purposes of validating the authentication thus removing the need for the PCR itself to be aware of, and thus specific to any particular card technology.
  • the IIPB can be used as a bit-mask which allows the PCR to build up a token which will be inco ⁇ orated into the AAV by the Cardholder I A and passed to the Issuer.
  • An Issuer can define an IIPB that will mark the minimum possible bits that they will require to verify the cryptogram. The number of bits marked as being required determines the potential size of the data token produced by the PCR. For pu ⁇ oses, primarily associated with existing cards not having the new IIPB tag, the IIPB is an optional structure. However since it is used to identify the bits that the PCR must extract and compress, if it is not present then the PCR must rely on a default setting. The default IIPB can be, for example, a 19-byte structure. The result of this is 35 bits of data being sent to the Issuer and requires 11 decimal digits to represent it on the display of the PCR. Adding on the final check digit the default IIPB results in a 12-digit token to be entered by the Cardholder.
  • Issuers can specify an IIPB appropriately for an application technology. This IIPB will then need to be included in the personalization specifications for that application in order that the PCR uses the IIPB stored in the card rather than the default IIPB stored in the PCR.
  • the data which is sent to the Merchant from the Cardholder's browser can consist of just the UCAF Authentication Data Field for each browser channel.
  • the UCAF can contain a 24-byte user authentication token. These 24 bytes are preferably encoded, e.g. Base64 encoded, by the Cardholder IA to give 32 ASCII characters of data that are returned to the Merchant.
  • the Merchant passes the UCAF data, in their proprietary communications with the Acquirer who can then populate the UCAF in the Authorisation Request message sent to the Issuer.
  • the generic structure of the UCAF is illustrated in Fig. 10.
  • the UCAF Control Byte is a 1-byte value, which indicates what type of data the UCAF is being used to transport.
  • the following values can be used for UCAF Control Byte encoding;
  • a first value such as 0x82 - SPA-UCAF, using a wallet server • A first value such as 0x88 - Chip-UCAF, using an ICC.
  • the present invention includes other authentication techniques, such as biometrics, and in such a case the specific technique would be assigned its own Control Byte value and the structure of the Application-Specific Data would be tailored to support a biometrics authentication approach. In this case, all biometrics authentication applications should use a consistent Application-Specific Data structure.
  • AAV Accountholder Authentication Value
  • IIPD Optional, variable in length, but always a multiple of bytes. It may contain a Card Sequence Number, e.g. 4 bits defined by Issuers to be at an Issuer defined position in the IIPD for that card.
  • the length is preferably restricted, e.g. to a first maximum number of bits such as not to be greater than 184, since, ideally, the Issuer should not supply an IIPB, which when combined with the IIPD could result in more than a second maximum number of bits, e.g. 152 bits (Max data area - Length(UN)) needing to be transferred.
  • the Cardholder IA can ensure that any operation resulting in more than the first maximum, i.e. > 184 bits, will result in an error and the data will not be encoded.
  • the encoded inclusion of any IIPD by the Cardholder IA is dependent on whether any IIPD is associated with the payment card used by the Cardholder for the particular transaction.
  • the UN encoded into the AAV for Chip-UCAF can be a full 4-bytes in size, which is the same size as the UN sent to the ICC in the GenerateAC command.
  • the magnitude of the UN can be altered within its full range, e.g. either increased or potentially even decreased without affecting the data transportation format.
  • a UN range-limitation can be a result of limiting the number of digits a Cardholder is required to enter to transfer data to the PCR from the MCD. For compatibility reasons this limitation can be applied to both connected and unconnected devices unless there is another indication of the size of the PCR Challenge presented to the PCR.
  • the Issuer knows the length of both the IIPD and the IIPB Data Token.
  • the Cardholder IA knows the length of the IIPD, however it does not know the length of the IIPB Data Token and so it should preferably right justify the bits, i.e. least significant bit appears in last bit position, using 0 filler, as illustrated in Fig.12.
  • any left justified IIPB Data Token data not passed in the PCR Token because it was set to 0 and therefore did not figure in the numeric token derivation, will be set to the 0 value it represented.
  • the link between the Merchant and Acquirer can be proprietary, however the Merchant should preferably transfer the following additional data to the Acquirer;
  • the Issuer receives the Authentication Request message through the authorisation network from the Acquirer. It will contain the standard authorisation data in addition to a modified Security Level Indicator (SLI) and the UCAF authentication data.
  • SLI Security Level Indicator
  • the Authentication Request message contains the SLI which has been extended for use with UCAF transactions.
  • the algorithm used for the check digit can be any suitable check algorithm such as the "Luhn Formula", also known as "Modulus 10" as used to validate a PAN.
  • the check digit can be applied to the n-digit PCR challenge, e.g. requiring the cardholder to enter a certain number of digits, e.g. 8 digits for a 7-digit challenge.
  • the Personal Card-reader validates the check digit and informs the cardholder when an incorrect value is entered.
  • the check digit shall apply to the complete 'number'. If an incorrect value is entered, the device shall preferably not abandon or restart the process, but can wait/prompt for the PCR challenge to be entered again. If desired a limit or no limit can be placed on the number of invalid PCR challenge entry attempts.
  • the check digit is preferably applied to the displayed n-digit PCR token, e.g. requiring the cardholder to enter onto the MCD, a certain number of digits such as 13 digits for a 12-digit PCR token.
  • the Personal Card-reader shall compute the check digit and apply it at the end of the displayed PCR token.
  • the check digit should also be applied since the one way communication does not allow for handshaking verification of data transmission.
  • the Cardholder IA must verify the check digit for these devices and report an error to the Cardholder if one is detected. This would result in the transaction with the PCR needing to be repeated.
  • the check digit is a transmission-medium error-detection mechanism.
  • the underlying transmission protocol may also correct any errors relating only to the transmission.
  • the PCR Challenge is passed to the Issuer.
  • the PCR Challenge consists of one or more parts, e.g. 2 or 3 parts, for example depending on whether the transaction amount is required in the GenerateAC command:
  • the PCR Challenge is used to create the Unpredictable Number (UN).
  • the PCR will supply the UN to the ICC as part of the GenerateAC command.
  • the UN can be supplied as a full 32-bit structure, containing the value obtained from the Cardholder I A.
  • the range of this value is preferably limited. The magnitude of this range can be determined by the maximum number of digits it is deemed acceptable for the Cardholder to key into an unconnected device.
  • the term 'unpredictable' refers to the fact that the number is unpredictable to the ICC, not that it is unpredictable to an application supplying the value to the ICC, or any other entity outside of the card.
  • the PCR Challenge is preferably a decimal number with a certain number of digits, which must be transferred to the PCR.
  • the UN can also consist of an additional trailing check digit and an optional currency code.
  • the number of digits to enter is an issue of Cardholder convenience, or rather inconvenience.
  • the challenge can be passed directly and therefore the number of digits used is not an issue.
  • all Cardholder IAs preferably use the same maximum number of digits to represent the possible range of the UN.
  • the number of digits can be limited, e.g. up to 8.
  • the PCR can be unaware of this 'restriction' as the UN part of the PCR Challenge is simply a value that must be able to fit into the 32-bit UN structure.
  • the PCR can require that the amount and currency be transferred to it.
  • the code can be inco ⁇ orated onto the end of the UN passed in the challenge.
  • the mechanism used to generate the PCR Challenge must be interoperable since the Issuer will need to reproduce the same actions on the host system where the UN is checked for validity against the source data.
  • the amount, as supplied by the Merchant in the UCAF data fields and as displayed to the Cardholder, is preferably encoded, e.g. BCD encoded, right justified and zero padded into 6 bytes.
  • the currency as supplied by the Merchant in the UCAF data fields and as used in a currency lookup to display the alphabetic code to the Cardholder, is preferably encoded, e.g. BCD encoded, right justified and zero padded into 2 bytes.
  • the transaction amount and currency are preferably always used in the calculation of the Unpredictable Number part of the PCR Challenge, regardless of the IAF setting (bit 8) for using amount and currency. That flag determines whether the amount and currency are additionally and explicitly used in the cryptogram calculation and with regard to the challenge only affects whether the challenge is used as the transfer mechanism for the currency code from the Cardholder IA to an unconnected Personal Card Reader.
  • the Merchant name as supplied by the Merchant in the UCAF data fields and as displayed to the Cardholder, is converted from the 22 Unicode two-byte characters received from the Merchant into 22 one-byte ASCII characters. This can be done by taking away each 'odd' byte - the first byte in each of the 22 two-byte Unicode sequences.
  • the PAN should be encoded, e.g. BCD encoded, into the smallest number of bytes, and where an odd number of PAN digits is supplied, e.g. a 19-digit Maestro PAN, it should be right justified and zero padded.
  • the inclusion of the PAN in the challenge generation requires that the Cardholder IA has knowledge of the full PAN being used by the Cardholder for this transaction.
  • a suitable encryption algorithm is applied, e.g. a SHA-1 hash algorithm, to the concatenated input data of 38 or 40 bytes formed from: Amount, Currency, Name and PAN.
  • the first 4 bytes of the resultant 20-byte hash data structure are 'extracted' and treated as a 32-bit unsigned integer value.
  • a modulus of 100,000,000 is then applied to this value to obtain a value in the range up to 99,999,999. If the currency code must be transmitted it is now appended. Finally a check bit such as a Luhn check-digit is applied across the digits computed so far and appended on the end to create the challenge.
  • the full process flow is shown in Fig. 13.
  • the PCR Challenge will be passed as a number, with optional zero padding up to 8 digits.
  • the zero padding is optional since the PCR does not rely on a fixed number of digits for the PCR Challenge, but rather uses an OK/Enter button to indicate the end of the PCR Challenge entry. To this number can be added the optional currency code and calculated check digit.
  • This transfer format should ideally be used for all types of device in order to keep logical differences between devices as small as possible, ideally only the communications protocol itself being different. This means that the difference between passing challenge data to either type of device lies purely in the communication/transfer mechanism and not in the processing of that data. Since the challenge is passed in the AAV, a possible optimisation for the Issuer
  • AC Application Authentication Cryptogram
  • the Unpredictable Number is a 4-byte/32-bit component of the data passed to the ICC in the GenerateAC command. It is a number/data that is unpredictable to the ICC, as opposed to the application, and is effectively the transaction-related challenge to the card.
  • the PCR Challenge is used to make up the UN. The maximum number of 8 digits of the challenge account for the lower 27 of the 32 bits required for the UN. The remaining 5 bits will therefore, be zero for the pu ⁇ oses of this scheme.
  • the UN part of the PCR Challenge should be thought of as passing a numeric value (see Fig. 14). When this numeric value is treated as an unsigned 32-bit integer, all bits past the highest significant set bit are implicitly set to 0.
  • the raw 'binary' value of the decimal numeric challenge entered by the cardholder is passed in the APDU command. It is not sent as the BCD encoded equivalent of the entered challenge digits.
  • the use of the amount and currency is at the discretion of the Issuer.
  • the Personal Card- reader will have been supplied with amount and currency data.
  • the currency is supplied as part of an extended PCR Challenge and the amount is transferred/entered explicitly/separately.
  • the Issuer has indicated that the amount and currency must not be used, or has not indicated this choice and the default of not using them has been followed, then default values for the amount and currency can be used.
  • the PCR can use the IIPB to perform a data extraction and compression process that results in a string of bit values that the Issuer has determined must be communicated to them - see Fig. 15.
  • a bit setting of 1 can be used to indicate that the corresponding bit position in the data is required and needs to be sent.
  • a bit setting of 0 can be used to indicate that the Issuer either knows, or is able to otherwise derive what the bit setting should be and thus the bit does not need to be sent.
  • the IIPB data token is preferably built up from right to left, with the first bit to be extracted placed into bit 1 of the last byte of output data, the second in bit 2, etc. The IIPB data token is filled in this manner until there are no more bits left to transfer.
  • the IIPB Data Token is the data, which is transferred from the PCR to the Cardholder IA. All connected device types transfer this data directly to the MCD, whereas an unconnected device will use the cardholder to transfer this data manually.
  • an unconnected device With respect to the PCR Token for an Unconnected Device, an unconnected device will compute and display a number that represents the bit pattern of the data to be transferred. The cardholder must then enter this number into the appropriate area made available in the Cardholder IA running on the MCD.
  • An unconnected PCR creates a numeric token, generated purely to transfer data from the PCR to the Cardholder IA running on the MCD, from the IIPB Data Token. It is important that the algorithm used for converting the bits into displayed numeric digits is interoperable and thus reversible on the Cardholder IA, i.e. the same algorithm used to convert from bits to token must be reversed to convert from token to bits. A 'compressed' way to do this is to treat the bit pattern as a binary number and perform a mathematical conversion from Base-2 to Base- 10 (Fig. 16).
  • the PCR Token may be presented using spaces, dashes or commas as separators, and is limited to a maximum possible display length, e.g. of 20 digits, including one or more check digits.
  • the Cardholder IA will not expect any particular sized token as it will use leading zero padding when encoding the IIPB Data Token into the UCAF to fill the remaining data space. Error detection and correction can be provided.
  • the PCR Token can make use of one or more check-digits such as a Luhn check digit, applied across the full token digits.
  • the Cardholder IA will verify the check digit to report any transmission errors. In case of any mis-keying, the Cardholder IA will inform the cardholder who will have to re-enter the PCR Token in the Cardholder IA.
  • the communication mechanism between the PCR and the Cardholder IA on the MCD can be proprietary, and any error detection mechanism can also be proprietary.
  • the Cardholder IA it must be possible for the Cardholder IA to recognise that an error has occurred, particularly in one-way connected devices where it might not be possible to perform any type of hand-shaking protocol, and inform the Cardholder. Since in the uncommon event of a transmission error, the Cardholder IA will not be able to inform the PCR of that error, it is acceptable to ask the cardholder to repeat the authentication process on the PCR again from the beginning, i.e. Inserting card/switching on, entering data and PIN and then allowing the PCR to retransmit. Alternatively the PCR might employ a retransmit function/button.
  • Chip-UCAF - a cardholder's perspective
  • Chip-UCAF Cardholders must subscribe into the scheme.
  • a cardholder will first need to have a suitable ICC. They will then need to have a Personal Card-Reader (PCR, either connected or unconnected) and the necessary thin- client Cardholder Interface Application (IA) software installed on a main accessing device such as a PC.
  • PCR Personal Card-Reader
  • IA thin- client Cardholder Interface Application
  • the Merchant When requesting authorization with a UCAF-enabled merchant, the Merchant will present the UCAF data to the Cardholder. When a UCAF client is available it will interact with the Cardholder. Cardholders will be required to 'know' a first and a second code ?? namely the PAN and the IIPD. The Cardholder must be responsible for keeping details of their PIN secret, so that in the event that an attempt is made to use the card without the Cardholder's permission it will not be possible for a PCR to produce a token without the correct PIN. The cardholder will need to install the local Chip- UCAF client on each PC that will be potentially used for e-commerce based purchases. The cardholder must register the PAN details of each payment card that will be used for UCAF payment authentication with the Cardholder Interface Application, before trying to use that card for payment and associated authentication.
  • the main merchant process flow is shown in Fig. 18.
  • the two main aspects of concern to the Merchant are firstly changes to merchant web pages and secondly the processing required to support UCAF.
  • the Merchant server will have to present additional data via its web-site and process additional data inserted via the Cardholder Interface Application.
  • Profiled For the pu ⁇ oses of describing the UCAF scheme in the context of the effort required by Merchants, two types of relationship that a customer can hold with the Merchant as a Cardholder will be considered: Profiled, Non-Profiled.
  • Express checkout and single- click require cardholders to be profiled whilst standard checkouts can be used by profiled and non-profiled cardholders alike.
  • Single-click generally requires the customer to have allowed the single-click option, as many customers feel uncomfortable with this impulse purchase ability.
  • the Merchant server In order to use UCAF, the Merchant server must have knowledge of certain Cardholder's payment details, e.g. PAN,
  • the order/payment details confirmation page must support the UCAF hidden fields and becomes, in UCAF functionality terms, a UCAF Authentication Page.
  • This provides the opportunity for the Cardholder Interface Application (Cardholder IA) to present itself and request the necessary interaction with the Cardholder to obtain the UCAF authentication data.
  • the Cardholder IA can then populate the UCAF authentication field prior to submission of the order by the cardholder.
  • the merchant server can support a UCAF Transfer Page.
  • the UCAF Transfer Page is not intended for use by the cardholder and its display should indicate that an authentication process is underway. This page acts as the UCAF Authentication Page and presents the hidden UCAF fields.
  • the UCAF Transfer Page must also support the UCAF hidden fields and provides the opportunity for the Cardholder Interface Application to present itself and request the necessary interaction with the Cardholder to obtain the UCAF authentication data.
  • Some merchants that offer single-click also offer the facility to automatically combine a series of single-click purchases, conducted within a certain timeframe, into one single order. I.e.
  • the UCAF Transfer Page is required when a cardholder using UCAF initiates a single-click checkout in order to be able to invoke the authentication process and supply the UCAF data.
  • the merchant must know if UCAF is being used prior to the single-click option being selected by the cardholder.
  • An additional hidden field, the UCAF Enabled field must be supported on each and every page that provides the single-click checkout option.
  • the Cardholder Interface Application will recognize this field and automatically fill the field with a certain value such as "01" to indicate that a UCAF compliant Cardholder IA will facilitate the payment.
  • the UCAF Transfer Page does not need to be displayed when a single-click checkout is initiated without a UCAF compliant Cardholder IA that can perform the UCAF authentication for the particular card used by the Cardholder.
  • the Cardholder IA initiates a click event on a hidden button.
  • the merchant provides the hidden button, the "UCAF Submit” button, on the UCAF Transfer Page. This button allows the Cardholder IA to initiate a click event when the form filling is complete.
  • the click event occurs the 'page' transmits the data that is to be sent in the authorisation request, to the Merchant's web server.
  • the IA detects errors that result in setting specific error indication contents into the UCAF Authentication data field, or if the Cardholder cancels, and there is a UCAF Submit button present, the IA will still action the click event, submitting the form data to the merchant. Merchants that wish only to send 'good' authentication data should therefore be aware of the error indications and consider returning an appropriate error page to the Cardholder.
  • the order/payment details confirmation page must support the UCAF hidden fields and become a UCAF Authentication Page. This provides the opportunity for the Cardholder Interface Application (Cardholder IA) to present itself and request the necessary interaction with the Cardholder to obtain the UCAF authentication data. The Cardholder IA can then populate the UCAF authentication field prior to submission of the order by the cardholder.
  • the Merchant In order to use UCAF, the Merchant must have knowledge of the Cardholder's payment details, PAN, Expiry Date and CVC2, before presenting a UCAF Authentication Page with UCAF hidden data fields, since one of the fields must contain the last 5 digits of the PAN being used for the transaction. Therefore when using UCAF the combined order details confirmation/ payment details requesting page must be split into two pages, as illustrated.
  • the UCAF Authentication or Transfer Pages are web pages that the merchant presents to the cardholder in order to confirm order and payment detail information. For UCAF-enabled merchants these pages are the facility by which UCAF data is presented and captured, prior to attempting an authorisation. Hence, the UCAF Authentication Page and the UCAF Transfer Page are the primary integration points among Merchant, Cardholder and Issuer.
  • the UCAF Authentication Page contains cardholder and transaction specific data that is transmitted via the public Internet. Therefore, the UCAF Authentication Page should preferably be protected using a sufficiently secure encryption method (e.g. 128-bit SSL or equivalent) to prevent the compromise of this data.
  • a sufficiently secure encryption method e.g. 128-bit SSL or equivalent
  • All merchant server interaction with the Cardholder IA in the PC Browser based channel is via hidden HTML form fields. In order to ensure interoperability with all merchants and all UCAF applications, the implementation of these hidden fields has been standardised, including naming conventions, size and allowed content.
  • Incoming data fields i.e. supplied by the Merchant, appear in the HTML page source delivered by the Merchant web server to the Cardholder's browser.
  • Outgoing data fields i.e. returned by the Cardholder, appear in the HTML page source delivered by the Merchant web server to the Cardholder's browser.
  • the Cardholder IA will, by interacting with the browser's Document Object Model (DOM), set the values programmatically as character strings.
  • DOM Document Object Model
  • the Merchant server presents the data values it must supply in the following hidden form fields:
  • Ucaf_Merchant_Name The Merchant's name consists of 88 hexadecimal characters (0-9, A-F) as 22 groups of 4 characters, with each group representing a Unicode character.
  • the name supplied by the merchant in the UCAF field is the name that will be displayed to the cardholder by the Cardholder Interface Application (Cardholder IA). It is also the name that will be used in the generation of the challenge.
  • Ucaf_City Up to 13 characters, the city to which the Merchant is registered with their Acquiring bank.
  • UcafJVlTS An optional field containing the hexadecimal representation of a two- byte merchant reference.
  • Cardholders may opt to use a Single-Click method of payment because of its ease and lack of required interaction.
  • a form submission button is made available. The Cardholder IA initiates a click event to automatically submit the UCAF Transfer page to the Merchant on completion of obtaining and populating the UCAF authentication data.
  • the UCAF Transfer Page needs the following additional hidden form element
  • the merchant server can capture relevant data and store it.
  • the merchant server can capture and retain the UCAF Authentication Data Field supplied by the Cardholder Interface Application.
  • the Authentication Data Field provides the merchant with data that links the cardholder to transactions. This data is required for the submission of subsequent authorisations for split-shipments and may be of value to the merchant during exception processing.
  • UCAF Authentication data need not be sent in 'real-time' to Issuers, just as authorisations need not be sent in real-time.
  • Authorisation requests including UCAF authentication data therefore do not need to be treated any differently to normal authorisation requests in respect of batching data sent to the Merchant's Acquirer.
  • Pre- authorisations are also allowed and are treated as for the initial authorisations.
  • Recurring payment transactions should include AAV data for the initial authorisation only.
  • the initial authorisation for a recurring payment may be eligible for Chip-UCAF processing.
  • Merchants need not provide UCAF data in recurring payment authorisations for recurring transactions.
  • a merchant may generate a second authorisation request for a given Chip-UCAF transaction that has the same AAV value as the original transaction.
  • authorisation requests that are not bit-wise identical to the original request are addressed - for example, the authorisation requests might have different system-trace ID numbers.
  • a merchant might generate second authorisation requests when:
  • Control Byte can be modified by Base64 decoding the UCAF data to get the 24-byte value, changing the value of the first byte and then re-Base64 encoding to create the updated UCAF. Or, simply by changing the first Base64 encoded character by subtracting a constant of 38 from the ASCII character value of the first character to produce a new value for the first character.
  • the Cardholder IA If the Cardholder IA detects errors in the data supplied by the Merchant either through data format/validation problems, or missing required Ucaf_ hidden fields, or has its own internal problems, the Cardholder IA will attempt to inform the Merchant. Since UCAF is an authentication mechanism and not a payment scheme, Merchants are free to make their own judgement on whether to continue the authorisation process with unsupplied or error indicated UCAF data.
  • Ucaf_ hidden field called Ucaf Authentication Data will be set to an empty value and thus appears no different to not having a UCAF client.
  • the merchant server has the ability to detect the presence of UCAF data in a record submitted on their UCAF Authentication Page or UCAF Transfer Page. If UCAF authentication data is present the merchant must submit it unaltered to the acquirer for transmission of initial authorisations. The merchant only modifies the value of the Control Byte for subsequent authorisations. The merchant also flags the transaction as UCAF-enabled so that the acquirer is able to populate the security level indicator with the appropriate value.
  • the merchant must indicate this to his/her Acquirer so that they are able to populate the security level indicator with the appropriate value.
  • some of the data content can be protected against modification en-route through the use of applying a MAC, and in such a case the UCAF data can also be included as input to the MAC.
  • Cardholder IA The Personal Card-reader Interface Application
  • PCR Personal Card-Reader
  • Cardholder in selecting the appropriate payment card.
  • the Cardholder IA must, once invoked, perform the following actions;
  • the Cardholder IA should be automatically activated when the appropriate point in the Merchant ordering process has been reached.
  • the Cardholder IA is able to receive the data from the Merchant, through the delivery channel supported by that Cardholder IA and specified in the appropriate channel specification.
  • the Cardholder IA validates the Merchant input data, and only proceeds with transaction data that is valid.
  • the Cardholder IA also obtains certain input data from the cardholder relating to the payment card that will be used for the transaction.
  • the Cardholder I A displays information to the Cardholder about the transaction, which must include the amount of the transaction in a representation that includes the currency letters, e.g. EUR, USD, etc. with the correct amount formatting.
  • the PCR Challenge is displayed to the Cardholder with a clear instruction that this must be entered into the PCR. It also clearly indicates that the Cardholder will be required to enter their PIN into the PCR and that the resultant PCR Token should be entered into the Cardholder IA.
  • the Cardholder I A generates, or causes to be generated, the PCR Challenge and, on receiving the PCR Token, the IA populates the AAV and Base64 encodes the UCAF.
  • the Cardholder IA is able to send UCAF data to the Merchant server, through the delivery channel supported by that Cardholder IA and specified in the appropriate channel specification.
  • the Cardholder I A may also provide additional "ease of use” facilities such as field auto-fill functionality for payment details, PAN, Expiry Date and additional customer details such as address. It is quite possible that the Cardholder will register more than one payment card with the Cardholder IA, and so the Cardholder IA would then have to offer the Cardholder a choice in any form filling for which card was being used for a particular payment. The details for these requirements are out of the scope of this document.
  • the IA may support ECML (E-Commerce Modelling Language) form filling and "best guess" field name auto filling.
  • the Merchant has to supply the last 5 digits of the payment card number in the Ucaf_Payment_Card_Number field on any page on which it is looking for some interaction with a UCAF Cardholder I A which might be installed on the Cardholder's PC.
  • Cardholder IAs must only activate to authenticate a card that it already has prior knowledge of, i.e. the last 5 digits supplied by the Merchant match the last 5 digits of one of the cards registered with that Cardholder IA.
  • the Cardholder IA When enabled to run, the Cardholder IA integrates into or otherwise attaches itself to the Internet browser process in such a way, as it is able to determine the field names of fields within forms on any given web page, as pages are loaded and display in the browser.
  • the application When any of the defined UCAF form fields are recognised, the application must then start the UCAF processing and extract the necessary data from those fields in order to continue with the authentication process.
  • PCR Personal Card-Reader
  • Fig. 23 is a conceptual diagram of PCR processing flow. 1. Processing begins when the cardholder inserts an ICC 5 into a connected or an unconnected device. In the following an unconnected device will be assumed.
  • the PCR looks for the ICC 5 and relevant programs on the card and confirms the card to the Cardholder by displaying the application label for a brief time;
  • the Personal Card-reader reads the Issuer Internet Proprietary Bitmap (IIPB) from the ICC 5. If the length of the IIPB is wrong or if the number of bits to be transferred, indicated by the IIPB, is too high for the particular Personal Card-reader, the Personal Card-reader displays the message: Fatal Error.
  • IIPB Issuer Internet Proprietary Bitmap
  • the Personal Card-reader prompts the cardholder to enter the challenge.
  • the Challenge includes data which will be used for the Unpredictable Number (UN), the transaction currency code (optional) and a trailing check digit.
  • the cardholder enters the 12-digit number displayed in a prompt on their main access device and the PCR checks for errors.
  • the Personal Card-reader determines that the check-digit is correct and informs the cardholder if the challenge is valid or invalid. If invalid, the PCR again requests the challenge. 6.
  • the Personal Card-reader prompts the cardholder to enter the amount of the transaction. If the authentication transaction did not make use of the transaction amount, this step would be completely skipped. Since the Challenge included the transaction currency code, the display inco ⁇ orates the 3-letter currency symbol at the end of the display line, as a visual confirmation to the Cardholder of the currency.
  • the cardholder enters the amount displayed, in a prompt on their main access device.
  • the Personal Card-reader submits the PIN to the ICC. If the ICC reports back an invalid PIN entry, the Personal Card-reader informs the Cardholder of the number of attempts remaining other wise it reports a valid PIN.
  • the device prepares a GenerateAC command using the transaction data as the Unpredictable Number and the amount and the currency code, all as entered by the cardholder.
  • the command is sent to the ICC. If the authentication transaction did not make use of the transaction amount, default but valid values for the amount (0) and currency code (999) are used.
  • the ICC replies and the PCR uses the IIPB read from the card to determine the bits from the response to the GenerateAC which must be stripped and compressed into a token. If no IIPB is found on the ICC, the default IIPB value stored in the reader is used. If the length of the IIPB is wrong, the Personal Card-reader displays the message: Fatal Error.
  • the device then computes and displays an n-digit (+ 1 check-digit) numeric token.
  • the cardholder reads and enters the token into the application on their main device.
  • the application on the main access device verifies the check digit and informs the cardholder if the token contains an error and requests the token to be re-entered. If the cardholder correctly keys in the token the online-transaction process continues.
  • IIPD Internet Proprietary Data
  • the first byte of the IIPD is an Internet Authentication Flags (IAF) byte. Each bit communicates actions or options from the Issuer that the PCR must take/use. The flag settings indicate whether the amount and currency must be explicitly used in the AC generation and whether an AAC or an ARQC should be requested from the ICC. If the ICC 5 has no IIPD, then a default byte value of 0x40 is used for the IAF.
  • IAF Internet Authentication Flags
  • the Internet Issuer Proprietary Data allows an Issuer to specify proprietary data, generally card specific static data, to be transferred to the Issuer's authentication verification system to assist in the verification of the authentication token. It serves as a general -pu ⁇ ose object to hold Issuer proprietary data for the Internet authentication environment.
  • the data to be conveyed within the IIPD is basically any card static data that is required by the Issuer Host system that will be verifying the Application Cryptogram, but is for one reason or another not able to be or is complicated to obtain from the card database. Examples might include the key derivation index and/or the cryptogram version number. Cards may use a 1 digit Card Sequence Number (CSN). As the UCAF specifications make no provision for this field, the IIPD can be used to transfer the CSN. It will be carried to the Issuer by placing it in the IIPD, needing 4 bits to represent it. The positioning and format of the CSN is Issuer dependent.
  • CSN Card Sequence Number
  • the Cardholder must supply the IIPD, if there is one, directly to the Cardholder IA. This means an Issuer must communicate any card's specific IIPD to the
  • the Issuer will have to supply the IIPD, a variable whole number of bytes, in a decimal triplet form, i.e. each byte's value will be entered as a decimal value, separated from the next byte value by a dash or a space. Leading zero padding will be used to ensure the IIPD is presented as triplets. This requirement is necessary so that MCDs that have no dash or space key will be able to recognise each triplet.
  • the PCR only uses the first byte of the IIPD as the Internet Authentication Flags (IAF) byte, the full IIPD should still be personalised into the ICC. This is so that connected readers that are able to extract data from the ICC will be able to retrieve the IIPD, and thus not require the Cardholder to enter the IIPD manually.
  • IAF Internet Authentication Flags
  • a further data structure is the Issuer Internet Proprietary Bitmap.
  • the Issuer Internet Proprietary Bitmap (IIPB) is an optional 11 -byte to 43-byte structure containing binary data.
  • the bitmap is a mask on the concatenated values of the data items CID, ATC, AC and IAD. It is not necessarily a straight mask on the response data, since both a first untagged and a second tagged GenerateAC response can be handled by the PCR.
  • the second response data includes the tag and lengths as well as the values of, CID, ATC, AC and IAD. If the ICC 5 has no IIPB, then a default byte value of a 19-byte structure is used.
  • an unconnected PCR After using the IIPB to determine the bits to be transferred in the IIPB Data Token, an unconnected PCR must build the PCR Token for display to the Cardholder. Because of the limited data transfer available via not only the AAV data space within the UCAF, but more importantly from the unconnected Personal Card-Reader (PCR), it is the IIPB that defines which bits of information are passed to the Issuer in order to verify the authentication cryptogram. The IIPB is therefore the definition of the Issuer's verification data requirements. The IIPB is a mask of those bits that are required from;
  • the only information required from the CID is whether the AC generated by the card was an ARQC or an AAC. Since the card will generate either an ARQC or an AAC, there is no need to send both cryptogram indicator bits, only the topmost of the two indicator bits being required. The remainder of the CID is set as indicated below and so not sent.
  • the ATC is a 16-bit counter which increments after each transaction.
  • the value of the ATC is included in the cryptogram and provides a uniqueness to the cryptogram. Due to the incrementing nature of the ATC it is possible to reduce the number of bits of the ATC which are transmitted quite substantially.
  • the cryptogram (AC) that is requested to be computed by the ICC for this scheme is an Application Request Cryptogram (ARQC), however some card implementations may opt, or be required by their Issuer, to generate an Application Authentication Cryptogram (AAC) instead. In both cases the AC is an 8-byte Message Authentication Code (MAC), computed over data passed to or otherwise known to the ICC.
  • ARQC Application Request Cryptogram
  • AAC Application Authentication Cryptogram
  • the Issuer Application Data contains fields with a combination of assumed static values, transaction specific values and issuer known values including the Key Derivation Index and the Cryptogram Version Number which are static values stored in the card and which the Issuer is able to retrieve from the ICC database based on the PAN and Expiry Date and so do not need to be transferred. Also included is the Dynamic Authentication Cryptogram (DAC) which is a constant and this does not need to be transferred.
  • IAD Issuer Application Data
  • DAC Dynamic Authentication Cryptogram
  • CVR Card Verification Results
  • Byte-1 is the length of the CVR and is a fixed known constant.
  • Bytes 2, 3 and 4 contain a mixture of assumed and required transaction or card specific bit values. These bits provide valuable information as to whether offline PIN verification was successful, PIN retry number exceeded, previous transaction failures.
  • Fig. 24 shows the steps involved in a standard transaction and will be described below:
  • Card Activation The Card must be inserted in the card reader when making the transaction.
  • the application selection process is the process by which the terminal uses data in the ICC to determine the ICC application to be used to produce an authentication cryptogram.
  • the process consists of two steps: • Create a list of ICC applications that are supported by the terminal. Select the application to be run from the list generated above.
  • Offline Card Authentication Data and Card authentication is performed by the terminal to confirm the legitimacy of critical ICC-resident data and to authenticate the ICC.
  • the Personal Card-reader as used for the Chip-UCAF Authentication service, can be considered an online-only terminal, the terminal application therefore does not need to perform offline Card Authentication as indicated in the settings of the Application Interchange Profile. This means the terminal does not need to verify the card inserted in the terminal is genuine, this can be left to the Card Issuer when validating the cryptogram.
  • the pu ⁇ ose of the processing restrictions function is to determine the degree of compatibility of the application in the terminal with the application in the ICC and to make any necessary adjustments, including possible rejection of the transaction.
  • the terminal application does not need to perform these tests as irrespective of the outcome the terminal will request an ARQC (but also accept an AAC if the ICC 'declined' the request) or an AAC.
  • Terminal Risk Management is that portion of risk management performed by the terminal to protect the acquirer, issuer, and system from fraud. Since the Card Issuer will process the transaction online anyway, Terminal Risk Management is optional.
  • Terminal Action Analysis Once terminal risk management and application functions related to a normal offline transaction have been completed, the terminal makes the first decision as to whether the transaction should be approved offline, declined offline, or transmitted online.
  • An ICC may perform its own risk management to protect the issuer from fraud or excessive credit risk. As a result of the risk management process, an ICC may decide to complete a transaction online or offline or request a referral or reject the transaction. The terminal will ask the card to generate an Application Cryptogram, either an ARQC or an AAC. Bit 7 of the Internet
  • IAF Authentication Flags
  • the terminal builds the data string to be included with the GENERATE AC command.
  • the ICC will generate an application cryptogram (AC) over the data items and other data items held by the card.
  • the response of the terminal to the GENERATE AC command includes the AC and the other data held by the card that was included in the cryptogram generation;
  • ATC Application Transaction Counter
  • IAD Optional Issuer Application Data
  • Terminal Online Processing is normally performed to ensure that the issuer can review and authorise or reject transactions that are outside acceptable limits of risk defined by the issuer, the payment system, or the acquirer.
  • the equivalent to the online processing stage prepares the data token, displayed to the cardholder, from the GENERATE AC response data. However, this in fact does not occur until the transaction with the ICC has been completed and is described below. The terminal does not need to perform any Online Processing.
  • an issuer may provide command scripts to be delivered to the ICC by the terminal to perform functions that are not necessarily relevant to the current transaction but are important for the continued functioning of the application in the ICC.
  • the Personal Card-reader does not have the capability to provide command scripts and so the terminal does not perform this step.
  • Transaction Completion The completion function closes processing of a transaction.
  • the terminal always performs this function unless the transaction is terminated prematurely by error processing.
  • Some card implementations may, according to their internal risk management, generate an AAC rather than an ARQC.
  • Bit 8 of the CID will determine whether the card generated an AAC or an ARQC. If bit 8 is 0, the card generated an AAC. If bit 8 is 1, the card generated an ARQC. If the ICC returned an AAC with the first GENERATE AC, then the transaction was 'declined offline' and no further processing is required. If the ICC returned an ARQC with the first Generate AC command, then the terminal should request the card to generate an AAC. With this request the terminal must include specific data, e.g. from the following data list:
  • the terminal builds the data string to be included with the Generate AC command.
  • the ICC will generate an application cryptogram (AC) over the data items in the CDOL2.
  • AC application cryptogram
  • Token Generation When a successful transaction has been closed with the card, the terminal must generate the token to be presented to the cardholder. The token is generated from the response to the first, or only, GENERATE AC according to the IIPB value. The token must only be displayed to the cardholder if the card is physically present in the terminal. This means that even if the card remains in the reader throughout the period of interaction between the PCR and the ICC, if it is removed whilst the token is being displayed, the terminal must clear its display and switch itself off. In the above scheme, any errors, indicated in return codes from the ICC, by Cardholder action, or detection of errors by the terminal, must result in the processing of the transaction being stopped and an appropriate error message being displayed before the PCR itself is switched off. The PCR must not generate and display a token in such circumstances.

Abstract

An authentication arrangement for use in a network payment system for transacting a sale of merchandise over a network using an Integrated Circuit Card is described, the arrangement comprising: a merchant server in communication with said network, said merchant server having at least a first item of merchandise for sale; a client terminal in communication with said network, said client terminal having an output device for reviewing said first item for sale, and an input device for initiating a purchase transaction to purchase said first item for sale, said client terminal being arranged to build a purchase message using information relating to a merchant identifier and financial transaction information obtained from said merchant server; a card reader for communicating with said Integrated Circuit Card, said client terminal having means to generate a challenge message, said challenge message being generated from the information relating to the merchant identifier and an account number, means for receiving the challenge message at the card reader and for generating a value from the challenge message; said Integrated Circuit Card having means for generating a cryptographic message from at least a part of said value, the card reader having means to generate an authentication token from at least a part of the cryptographic message, and said client terminal having means for transmitting at least part of the authentication token in a message for transmission via the network.

Description

AUTHENTICATION ARRANGEMENT AND METHOD FOR USE WITH FINANCIAL TRANSACTIONS
The present invention relates generally to a payment system and method using a computer network such as a wide area data network. More specifically, the present invention relates to an authentication arrangement which is part of a payment system and a corresponding method executed over an open network such as the Internet using an Integrated Circuit Card. The present invention also relates to software for implementing the authentication arrangement and method.
Technical Background
It is known to make purchases on the Internet using a user terminal or main access device such as a personal computer. An architecture and system using a smart card for payment of goods and/or services purchased on-line over the Internet is known from US 6,282,522. A client server on a client terminal controls the interaction with a consumer and interfaces to a card reader which accepts the consumer's smart card. A payment server on the Internet includes a computer and terminals that handle the transaction and data store. Also connected over the Internet is a merchant server advertising the goods and/or services offered by a merchant for sale on a web site. The merchant contracts with an acquirer to accept smart card payments for goods and/or services purchased over the Internet. A consumer uses his smart card at the client terminal in order to purchase goods and/or services from the remote merchant server. The Internet provides the routing functionality between the client terminal, merchant server and payment server. Fig. 1 is a schematic representation of a user terminal or main access device 1 , e.g. for accessing and browsing the Internet. Typically, the terminal 1 includes a central processor unit (CPU) 2 which is connected with memory 4 and input/output (I/O) devices 6 via a bus 3 for two way communication. I/O devices 6 may be a keyboard for entering data and a screen such as a visual display unit, e.g. a liquid crystal (LCD) or light emitting diode (LED) display, a CRT for displaying the progress of the transaction and or for displaying messages or prompts. One of the I/O devices 6 may be a card reader 7 with which an Integrated Circuit Card (ICC) 5 may be read when it is introduced into a receiving slot in the reader 7. Alternatively, the card reader 7 may be a standalone device for reading the ICC 5. One of the I/O devices 6 may be also a modem 9 for accessing the Internet via an Internet Service Provider (ISP), e.g. a 56K, an ADSL, a wireless or a cable modem. The actual form of the terminal may vary greatly, and may include a processor such as the Pentium™ family of microprocessors supplied by Intel Corp. USA. Further, it is not necessary that the terminal 1 is all situated at one location, the various parts of the terminal such as the card reader 7, the I/O devices such as the keyboard and the display, the modem and the processor may located at different positions and connected by cables, wireless transmission or similar or be part of a local area network or interconnected by telecommunications networks.
Fig. 2 is a schematic representation of an Integrated Circuit Card (ICC) 5. The ICC 5 includes at least an input/output (I/O) port 10 and some permanent storage, e.g. a non- volatile memory which may be provided, for instance, by a an EEPROM 15 connected to the I/O port 10 via a bus 17 or by battery-backed random access memory (RAM). The I/O port 10 can be used for communication with the terminal 1 via card reader 7. An integrated circuit card is a card into which one or more integrated circuits are inserted to perform at least memory functions. Optionally, the ICC 5 may be a self-contained portable intelligent card and include a read/writable working memory e.g. volatile memory provided by a RAM 14 and a central processor 12 as well as all necessary circuits so that card ICC 5 can operate as a microprocessor, e.g. read only memory 13 for storing code, a sequencer 16 and connections with the card reader 7 for receiving the voltage sources Vss and NDD, a reset for the processor 12 and clock CLK to the sequencer 16. The ICC 5 can be used as bank card, credit card, debit card, electronic purse, health card, SIM card or similar. Other features of the microcontroller may be present but are not shown, such as a clock, a random number generator, interrupt control, control logic, a charge pump, power connections, and interface contacts that allow the card to communicate with the outside world. For example, an encryption module (not shown) is an optional hardware module used for performing a variety of encryption algorithms. E-commerce merchants provide a web server with web-site access to commodities or services which can be accessed from user terminals as shown in Fig. 1 usually via web pages and these commodities and services may be purchased using cards such as the ICC 5 of Fig. 2. Many e-commerce merchants currently support cardholder profiling. Cardholder profiling consists of collecting information about the cardholder and using this data to streamline the cardholder's checkout process. The information collected typically includes billing address, shipping address, payment method details (e.g., card number and expiration date), email address and communication preferences. Most merchants also support non-profiled checkout. In this case, either the merchant does not support a cardholder profile database or the cardholder has chosen not to create a profile with this merchant. In either case, the non-profiled checkout process requires the cardholder to manually provide full shipping, billing and payment details. E-commerce merchants have implemented a variety of on-line checkout processes in an attempt to make the on-line shopping and purchase experiences more efficient for cardholders. A number of merchants have implemented an express checkout process (Fig. 3) intended to provide the cardholder with a streamlined purchase process by making full use of cardholder data and payment details stored in a profile database managed by the merchant. After browsing and selecting a particular item, or items, the Cardholder selects the express checkout option. The Merchant retrieves the Cardholder's profile, and presents a page at the user terminal combining details of the order and Cardholder's payment details. The Cardholder can review these details and submit/confirm the order.
Single-click checkout processes have been implemented by many merchants (see Fig. 4). The single-click checkout process is intended to provide the cardholder with the most efficient on-line purchase process available by making full use of cardholder data and payment details stored in a profile database managed by the merchant. After browsing and selecting a particular item, the Cardholder selects the single click order option which is generally available on all pages where an item's details and price are described. Usually the customer can either add the item to their 'shopping basket', or order and pay for it with a 'single click'. The Merchant combines the details of the order and Cardholder's payment details to create an order, which is then acknowledged in a page to the Cardholder. Customers can usually cancel, amend or even combine multiple single click orders after the initial single-click through some form of customer administration/status page.
Most merchants support the standard checkout, which is usually a process of confirming the order details and collecting the Cardholder's payment details (see Fig.5). The standard checkout process must be used by non-profiled cardholders since the payment details need to be collected. However even profiled cardholders will often opt to use the standard checkout if, for example, they wish to use different payment/personal details.
After browsing and selecting a particular item, or items, the Cardholder selects the standard checkout option. The Merchant presents a page showing details of the order and requesting the Cardholder's payment details. The Cardholder can review the order details, supply their payment details and if necessary other pertinent personal information and submit/confirm the order. In some cases this combined order details confirmation/payment details requesting page can be split into two pages, as shown in Fig. 5.
Today, remote transactions represent a significant transaction volume of all financial transactions. An explanation of various financial transaction systems can be found in books such as "Secure Electronic Commerce", W. Ford and M. S. Baum, Prentice Hall, 1997; "Digital Cash" by P. Wayner, Academic Press, 2nd edition, 1997; "Designing Systems for Internet Commerce", G. W. Treese and L. C. Stewart, Addison- Wesley, 1998. From a risk perspective these transactions are often not guaranteed and are therefore at the Acquirer/Merchant's risk. Security of such financial transfers on the Internet should be high but also allow convenient shopping without complex procedures. There is a continuing need to improve the ease and security of Internet financial transactions.
Summary of the Invention
The present invention meets the goals of Cardholder authentication in financial transaction environments that traditionally suffer from chargebacks because no evidence could be provided that the Cardholder actually authorised the financial transaction. It offers a mechanism for securing the Internet channel by strongly authenticating the Cardholder at the point-of-interaction (POI) and providing explicit evidence both of card presence and that the Cardholder originated the transaction. The invention has a number of goals including at least one of: • Reducing chargebacks due to reasons of Cardholder non-authorised transactions.
• Supporting both credit and debit transactions
• Minimising acquirer system impacts • Ensuring rapid Merchant adoption
• Supporting authentication for real account numbers, virtual accounts and pseudo account numbers.
In one aspect the present invention provides a computer-based authentication scheme, in particular the present invention provides a computer implemented method and system for providing financial transactions via the Internet.
The present invention in one aspect provides an authentication arrangement for use in a network payment system for transacting a sale of merchandise over a network using an Integrated Circuit Card, said authentication arrangement comprising: a merchant server in communication with said network, said merchant server having at least a first item of merchandise for sale; a client terminal in communication with said network, said client terminal having an output device for reviewing said first item for sale, and an input device for initiating a purchase transaction to purchase said first item for sale, said client terminal being arranged to build a purchase message using information relating to a merchant identifier and financial transaction information obtained from said merchant server; a card reader for communicating with said Integrated Circuit Card, said client terminal having means to generate a challenge message, said challenge message being generated from the information relating to the merchant identifier and an account number, means for receiving the challenge message at the card reader and for generating a value from the challenge message. The value is a preferably a value which is not predictable by the ICC. The ICC has means for generating a cryptographic message from at least a part of said value, and the card reader has means to generate an authentication token from at least a part of the cryptographic message. The client terminal has means for transmitting at least part of the authentication token in a message for transmission via the network. The transmission may be to the merchant server. The network may have a transaction approvals server for approving financial transactions, and the transmission is to said approvals server. Said means to generate a challenge message may be adapted to generate the challenge message from the information relating to the merchant identifier, an account number and at least one of a purchase amount and a purchase currency. The means for transmitting at least part of said authentication token may be adapted to transmit the at least part of said authentication token to the merchant server and the merchant server is adapted to transmit the at least part of said authentication token to the transaction approvals server with purchase information in an authorization request message. The means to generate a challenge message may be adapted to concatenate the merchant identifier and the account number and optionally at least one of a purchase amount and a purchase currency. The means to generate a challenge message may be adapted to compress the concatenation of the merchant identifier, and the account number and optionally at least one of a purchase amount and a purchase currency, whereby the compression may be application of a hash function. The approvals server may rebuild at least part of the authentication token and compare the rebuilt message with the at least part of the authentication token in the authorization request message transmitted from the merchant server. The transaction approvals server may be adapted to send an approval message to the merchant server if the comparison is positive. The Integrated Circuit card may have a memory and a first data object stored in said memory and the means for generating an authentication token from at least a part of the cryptographic message may be adapted to select a part of the part of the cryptographic message in accordance with the first data object. A second data object may stored in said memory and the means to generate a challenge message may includes at least one of a purchase amount and a purchase currency in the generation of the challenge message in accordance with the second data object.
In another aspect the present invention provides a method for authentication as part of transacting a sale of merchandise over a network using an Integrated Circuit Card, the method comprising: establishing a communication between a merchant server with a client terminal over said network, said merchant server having at least a first item of merchandise for sale; reviewing said first item for sale on said client terminal, initiating a purchase transaction to purchase said first item for sale and building a purchase message using information relating to a merchant identifier and financial transaction information obtained from said merchant server; generating a challenge message on the client terminal the information relating to the merchant identifier and an account number, receiving the challenge message at a card reader and for generating a value from the challenge message; establishing a communication between the Integrated Circuit card and the card reader and generating a cryptographic message from at least a part of said value, generating an authentication token on the card reader from at least a part of the cryptographic message, and transmitting at least part of the authentication token in a message from the client terminal for transmission via the network to an approvals server. Generating a challenge message may include generating the challenge message from the information relating to the merchant identifier, an account number and at least one of a purchase amount and a purchase currency. Transmitting at least part of said authentication token may include transmitting the at least part of said authentication token to the merchant server and transmitting the at least part of said authentication token from the merchant server to the transaction approvals server with purchase information in an authorization request message. Generating a challenge message may comprise concatenating the merchant identifier and the account number and optionally at least one of a purchase amount and a purchase currency. Generating a challenge message may comprise compressing the concatenation of the merchant identifier, and the account number and optionally at least one of a purchase amount and a purchase currency, e.g. by applying a hash function. The method may include rebuilding at least part of the authentication token at the approvals server and comparing the rebuilt message with the at least part of the authentication token in the authorization request message transmitted from the merchant server followed by sending an approval message to the merchant server if the comparison is positive. The Integrated Circuit card may have a memory and a first data object stored in said memory, the method further comprising generating an authentication token from at least a part of the cryptographic message by selecting a part of the part of the cryptographic message in accordance with the first data object. The method may further comprise generating a challenge message from at least one of a purchase amount and a purchase currency in accordance with the second data object.
The present invention can address all channels and transaction types for remote transaction by defining four building blocks that should constitute the basis for a guarantee in any environment: a) A CAM function, i.e. evidence that the card/account is genuine, b) A CNM function, i.e. evidence that the cardholder is genuine, c) Proof of transaction authorisation by the Issuer, d) A description of the transaction environment.
The definition and the implementation of an infrastructure in one aspect of the present invention realises guaranteed transactions in an e-commerce environment. A first category of transactions suitable for such services is Electronic Commerce payments, both Internet-based "e-commerce" and wireless-based "m-commerce". Since the model is generic, it can be used consistently across multiple channels and can be extended to other environments including Mail Order or Telephone Order. Indirect cardholder benefits are: • Reduction of perceived risk.
• More merchants prepared to do business over the Internet
• The above leading to a further take of e-commerce with the result of stimulated competition for business.
• Reduction/elimination of disputes over genuine 'not me' transactions with consequently reduced 'hassle'.
The invention will now be described with reference to the following drawings.
Brief Description of the illustrated embodiments
Fig. 1 shows a main access device which can be used with the present invention. Fig. 2 shows an Integrated Circuit card which may be used with the present invention.
Fig. 3 shows a known Express Checkout Page Flow.
Fig. 4 shows a known Single-Click process flow.
Fig. 5 shows a known standard process flow.
Fig. 6 shows how bytes are described. Fig. 7 shows an authentication system in accordance with an embodiment of the present invention.
Fig. 8 a more detailed flow of an authentication system in accordance with an embodiment of the present invention.
Fig. 9 shows an IIPB Data Structure in accordance with an embodiment of the present invention.
Fig. 10 shows a UCAF Structure in accordance with an embodiment of the present invention.
Fig. 11 shows encoding of an AAV in an embodiment of the present invention.
Fig. 12 shows 'Filler Set to 0' vs. 'Data Set to 0'. Fig. 13 shows a process flow to form a PCR challenge in accordance with an embodiment f the present invention.
Fig. 14 shows 8 digits from a Challenge giving up to 27 bits of UN in accordance with an embodiment of the present invention. Fig. 15 shows Bit Extraction and Compression in accordance with an embodiment of the present invention.
Fig. 16 shows an example of Conversion of Required Data Bits from Base 2 to a Base
10 Token. Fig. 17 shows an overview of the flow process according to an embodiment of the present invention.
Fig. 18 shows a flow process from the completion of the purchase to merchant acceptance according to an embodiment of the present invention.
Fig. 19 shows a modified Express Checkout Page Flow according to an embodiment of the present invention.
Fig. 20 shows a modified Single-Click process flow according to an embodiment of the present invention.
Fig. 21 shows a modified standard process flow according to an embodiment of the present invention. Fig. 22 shows a card activation process flow according to an embodiment of the present invention.
Fig. 23 shows a PCR-ICC interchange process flow according to an embodiment of the present invention.
Fig. 24 shows a process flow from card activation until token generation according to an embodiment of the present invention.
Description of the illustrative embodiments
The present invention relates to an ICC Authentication Programme, e.g. for e- commerce applications using a Personal Card-reader (PCR) which generates authentication tokens for transport to the Issuer in a Universal Cardholder
Authentication Field (UCAF). In designing the token generation scheme, cardholder friendliness - through paring down the data requirements to their bare minimum, using check digits, etc. - has been provided. In one aspect the present invention includes a functional architecture of a scheme used to achieve ICC based authentication using a personal card-reader, for Internet based e-commerce transactions via the UCAF.
The terms Customer and Cardholder are, for the purposes of this invention, interchangeable, however for consistency usually the term Cardholder is used. It does not strictly mean the person to whom the card was issued but rather refers to a person in possession of both the card and the authentication mechanism of that card, e.g. a PIN as one example. In the whole of the text and figures reference to Merchant, Acquirer and Issuer refers to respective severs in communication with the Internet when entry of data or passing of messages, web pages etc. is concerned. All tables, diagrams and textual references to numbered bytes, e.g. "Byte 1 is transferred", are in the style of references to bytes within a larger block, counting from the start of the block/sub-block. The bytes are not numbered in a most/least significant byte style as for values. At times this will result in the most significant byte of a numeric data element, e.g. Application Transaction Counter, being referred to as Byte 1 and the least significant as Byte 2. Bits on the other hand are identified in the reverse manner where the most significant bit is the 'first' bit and is referred to as Bit 8, whilst the least significant bit is the 'last' bit and is referred to as Bit 1. See Fig. 6. Where a number is given/illustrated and its number base is not described it shall be assumed to be decimal (Base 10). Where a number is given/illustrated with a leading 'Ox' it shall be assumed to be hexadecimal (Base 16).
If examples are used to help illustrate and clarify the text of the specification, and there are any discrepancies between the specification and what appears in the associated example, the specification should always be considered to be the reference.
Terminology
AAC Application Authentication Cryptogram
AAV Accountholder Authentication Value
AC Authentication Cryptogram
AFL Application File Locator, identifies what records are available where in the ICC. AID Application Identifier, the hex string which identifies a given application in the ICC. AIP Application Interchange Profile, indicates the capabilities of the
ICC to support specific functions. APDU Application Processing Data Unit, the messages sent between
ICC and some external application. ARQC Application ReQuest Cryptogram ATC Application Transaction Counter BCD Binary Coded Decimal Big-Endian An encoding style where a value is stored with its most significant byte first followed by each successive byte, with the least significant byte stored last.
CAP Chip Authentication Programme
CDOL Card risk management Data Object List
CID Cryptogram Information Data
CSN Card Sequence Number
CVC2 Card Verification Code
CVM Cardholder Verification Method, the method used to verify a cardholder to the card.
DAC Dynamic Authentication Cryptogram DOM Document Object Model, the programmatic view of the current
HTML page supplied by a browser to a plug-in.
HHD Hand held device, e.g. a card reader
EMV Europay MasterCard Visa
IA Interface Application
IAD Issuer Application Data
IAF Internet Authentication Flags, the first byte of the IIPD.
ICC Integrated Circuit Card, also known as Chipcard or Smartcard.
IIPB Issuer Internet Proprietary Bitmap, identifies bits required to be sent to the Issuer in order to validate the AC.
IIPD Issuer Internet Proprietary Data, proprietary data used by the
Issuer in relation to computing a cryptogram for the purposes of
Internet related transactions.
ITV Interactive Television
LATC Lower (byte of) Application Transaction Counter
Little-Endian An encoding style where a value is stored with its least significant byte first followed by each successive byte, with the most significant byte stored last.
MAC Message Authentication Code. A cryptographic signature calculated over data items in a message to both prove the origin of the message and to allow detection of whether those data items have been modified.
MCD Main Cardholder Device, the device on which the browsing and/or ordering and/or payment is being performed on.
Nibble Haifa byte i.e. 4 bits. PI Parameter 1, of an APDU, it effectively customises the command being sent to the ICC.
PAN Primary Account Number
PC Personal Computer
PCR Personal Card-reader.
Cardholder IA Cardholder Interface Application, the application running on the
MCD which interfaces between the authentication requester, the
Cardholder and the PCR.
PDA Personal Digital Assistant PDOL Processing Options Data Object List, the list of processing options available to/supported by the terminal (i.e. PCR).
PIN Personal Identification Number SPA Secure Payment Application TLV Tag Length Value
UCAF Universal Cardholder Authentication Field
UN Unpredictable Number
The Authentication scheme according to the present invention is a use of the Universal Cardholder Authentication Field (UCAF). This scheme will be referred to as Chip- UCAF for convenience only. The term itself does limit the present invention. The present invention provides secure authentication methods that take advantage of the UCAF infrastructure. It comprises the following elements:
• Issuer Provided Chip-UCAF-Enabled interface application
• Chip-UCAF Accountholder Authentication Value (AAV) generation.
• Cardholder authentication.
• Merchant presentation, collection and processing of AAV Data in the UCAF Authentication Data Field. • Acquirer acceptance and processing of AAV Data as contained in the UCAF.
• Banking network development to include support of carrying the AAV data in the UCAF Authentication Data Field.
• Authorisation support of AAV data in the UCAF Authentication Data Field. The following entities are involved in the lifetime of a Chip-UCAF authentication transaction:
• Cardholder - The cardholder initiates the transaction and is responsible for entering data into both the merchant's payment web pages, the Cardholder Interface Application, and the Personal Card-reader. • Merchant - The merchant supplies, e.g. from a merchant server in communication with the Internet, the data necessary to start the authentication transaction and receives the resultant UCAF data to forward, via their acquirer, to the card issuer for approval.
• Cardholder Interface Application - The Cardholder IA detects the relevant data supplied by the merchant and interacts with the cardholder directly and indirectly, through the cardholder, with the Personal Card-reader. The Cardholder IA creates the AAV and UCAF and populates the merchant's page with the appropriate data. For example, the Cardholder IA can run as part of an Internet browser on the main cardholder device (MCD) being used to access the merchant on the Internet. • Personal Card-Reader - The PCR interacts with the Cardholder, and the ICC to produce an authentication token that is passed, indirectly, to the Issuer. The
• ICC - the chip card authenticates the Cardholder through the use of submitted PIN verification and generates a suitable cryptogram based on data supplied by the PCR. • Acquirer - An acquirer accepts the formatted UCAF data from a merchant, e.g. at an acquirer server, and forwards it, with an indicator of the use and presence of UCAF data, to the issuing bank via the appropriate telecommunications network. Mastercard is an acquirer.
• Issuer - The card issuer distributes PCRs to those cardholders that are signed up to the Chip-UCAF scheme. The issuer maintains an issuer server platform in communication with the Internet. In accordance with the present invention the Issuer server validates the authentication token encoded into the UCAF, transmitted in the authorisation request by an acquirer, according to the rules of that issuer.
In one aspect the present invention provides authentication for e-commerce payment services. Cardholder presence status is provided for transactions that are online to the Issuer. The classical authorisation route through the existing payment scheme network can be used. A Personal Card-reader is used operating either as a stand-alone device or connected to/integrated with the Cardholder's access device (e.g. Laptop, PC, pocket PC, smart phone, palm pilot, PDA). The reader preferably has a display and keypad for allowing limited Cardholder interaction. The specifications for the Personal Card-reader should preferably allow a maximum possible number of different card implementations whilst at the same time catering for Cardholder convenience. The Personal Card-reader should preferably have the display capability to show the PIN validation result, and for unconnected devices a token which must be entered by hand on the main cardholder device. The Personal Card-reader must be capable of obtaining from the ICC an indication from the Issuer of the data that must be transferred to them in order to allow the ICC signature to be verified. The Personal Card-reader should preferably be capable of obtaining from the ICC an indication from the Issuer as to whether or not to incorporate the amount and currency of the transaction in the generated token. When such an indication is made the reader must be capable of allowing the Cardholder to enter the amount and associated numeric currency code. Where the transaction amount is to be entered by the Cardholder, it is preferably in a 'natural' format, i.e. inclusive of decimal indicator, but converted to ISO 4217 base currency units for inclusion in the card signature. Any such amount entered by the Cardholder, or otherwise communicated to the reader should preferably be displayed along with an associated 3-character currency symbol, e.g. EUR, prior to approval, via PIN, by the cardholder.
The UCAF (Universal Cardholder Authentication Field) data field is a multipurpose data transport area in a digital message to allow communication of authentication data to an Issuer from an Acquirer over any form of telecommunications network. For example, the UCAF can be a 32-character field (24 bytes - 1 control byte and 23 data bytes - that are base-64 encoded to become 32 characters) with a flexible data structure that can be tailored to support the needs of a variety of Issuer security and authentication requirements. For example, ISO 8583 Data Element 48, sub-element 43 may be designated to contain the UCAF. The term UCAF also extends to referring to the interface defined to pass data between the Merchant and the MCD and back again, i.e. the field names in the specification for any given channel. The Accountholder Authentication Value (AAV) is the term given to a part, e.g. the 23 bytes, of UCAF application specific data. Each UCAF application is responsible for determining the appropriate structure for its AAV. Every instance of an implementation of a given UCAF application must use that application's AAV structure in a consistent manner, i.e. the AAV format is standardised for a given UCAF application.
In order to use the Chip-UCAF cardholder authentication scheme the cardholder needs to have an appropriate ICC payment card and a Personal Card- reader. The PCR will be supplied to the cardholder by their card issuer, who will register that that cardholder has a PCR and is 'enrolled' in the Chip-UCAF cardholder authentication scheme. The UCAF transaction data supplied by the Merchant is used for display purposes and some of it is used in generating a transaction related PCR Challenge. There is no additional processing that Merchants need to perform on the AAV data within the UCAF response. This is indicated to the Merchant through the UCAF Control Byte value being set to the value for Chip-UCAF. The Cardholder Interface Application (Cardholder IA) provides the interaction between the authentication requirer (Merchant), the cardholder and the PCR. The Interface Application presents the secure face of the present UCAF scheme to the cardholder. It is responsible for presenting the transaction data to the cardholder, generating the challenge transferred to the PCR, receiving the PCR Token response, formatting the UCAF and populating the return data for the given channel. The Cardholder IA has a minimum set of requirements it must meet in order to effect a Chip-UCAF transaction. It may also add additional functionality such as intelligent form filling, receipt tracking/logging, integration with personal finance software etc.
The Main Cardholder Device (MCD) is the device on which the browsing/shopping is probably carried out and, for the scope of this specification/scheme, the payment and authentication process is certainly carried out. The present invention will be described with reference to a PC device on some platform in an Internet browser environment. The Cardholder IA must execute in this environment.
The Personal Card-reader (PCR), is a device to enable PIN entry and validation, e.g. off-line and authentication of transaction context data by a cardholder's ICC inserted in the device, for the purposes of e-commerce transactions. An unconnected PCR may be used with the present invention, i.e. a device that has no physical/electrical connection with any outside system and whose interface for data into and out of the device is the cardholder, via the keypad and display. Personal Card- readers with other types of connection may also be used.
An unconnected PCR device has no physical/electrical connection with any outside system. The interface for data into and out of the device is a keypad a display for interaction with a person, i.e. the cardholder. When using an unconnected device, the cardholder must manually enter, in addition to a PIN, certain data that the PCR will use, in conjunction with the card, in order to generate an authentication value. The authentication value is displayed on the PCR's display for the cardholder to then manually enter into the Cardholder Interface Application. Check digits are used to enable data entry validation.
PCR connected devices allow more data to be transferred to the MCD, without the inconvenience to the cardholder of passing the data manually. Connected devices may be devised which can operate in unconnected mode when the connection cable is removed.
A PCR one-way connected device is connected to the MCD in the out direction only. The interface for data into the device is the keypad. It has a display for interaction with a cardholder. The cardholder again acts as the data transport mechanism between MCD and the PCR. The cardholder must manually enter, in addition to their PIN, certain data that the PCR will use, in conjunction with the card, in order to generate an authentication value. The authentication value is sent out to the MCD through the one-way connection.
A two-way PCR connected device is connected to the MCD in both directions. The device has a keypad for cardholder PIN entry and a display for interaction with the cardholder. The cardholder need only enter their PIN. The MCD can transfer all of the data that the PCR will use, in conjunction with the card, in order to generate an authentication value. The authentication value is sent out to the MCD.
An integrated PCR device is an MCD that has a direct connection to a smartcard reader. The terminology is meant to apply to PDAs with built in smartcard readers, but the technology could equally well be a desktop PC with a directly connected smartcard reader. The cardholder need only enter their PIN. The MCD performs all of the PCR functionality and transfers commands directly to the ICC through the connected reader. The response from the ICC is processed by the MCD itself. The software is written in such a way that the Cardholder IA is able to behave in the same way as for a two-way connected device, i.e. when communication is made out to the PCR by the Cardholder IA, the drivers send & receive the data to & from a PCR that 'just happens to be' on the same MCD. A connected and integrated PCR device would be a self-contained PCR, integrated into the MCD. The requirements for such a device are no different to those for a connected device, and may be integrated into a PC keyboard other input/output device.
In the context of UCAF, the UCAF enabled Acquirer has a relationship with a UCAF enabled merchant. The acquirers enable their merchants to pass the extra
UCAF data to the acquiring systems and enable their systems to identify the presence of and pass on supplied UCAF data to the issuing bank.
The Issuer Host, or some other element acting, to the scheme, as the Issuer Host is responsible for taking the data passed in the authorisation network message, including the data in the UCAF, and enabling the authentication token to be validated. Given that the chip based functions described in the present invention essentially provide means of verifying the Cardholder presence to the Issuing bank, the present invention can also be implemented in remote banking environments ("e-" or "m-banking"). This would provide banks with a consistent Consumer authentication method across products, services and environments.
Chip-UCAF uses the UCAF infrastructure to transport authentication and security data between Cardholder, Merchant, Acquirer and Issuer. Fig. 7 illustrates the process flow for a typical Chip-UCAF transaction in accordance with an embodiment of the present invention. This flow assumes that prior to conducting a transaction, the Cardholder has registered with their Issuer for the service, obtained and initialised the Cardholder Interface Application and obtained a Personal Card-reader that is compatible with their ICC card. It is also assumed the Cardholder has identified a product or service offered on the merchant server and has initiated the checkout process and has already been requested by the merchant to provide payment card details. Once the items are selected and the checkout phase begins, the Cardholder provides billing address, shipping address and payment card details to the merchant. Billing and shipping address information can be entered directly or based on information stored at the merchant for the particular Cardholder. When the merchant requests confirmation and authentication of the order, the merchant's web server provides a series of hidden fields uniquely describing this transaction. For instance, this information may include one or several of;
Merchant Name • Card Acceptor City
Card Acceptor State / Country Code
Currency Code
Sale Amount
Merchant Transaction Stamp • UCAF Authentication Data Field
Payment Card Number (populated by the merchant with the last 5 digits of the previously supplied card number) • UCAF Brand
Referring now to the numbering of Fig. 7, the following is a description of an embodiment the present invention.
1. The Cardholder's Interface Application acquires the merchant identifier information and the transaction data from the UCAF Authentication Page and builds a Challenge that is presented to the Cardholder.
2. The Cardholder inserts the payment card (ICC 5) in the Personal Card-reader. The application implemented on the Personal Card-reader requests the
Cardholder to enter the Challenge or the challenge is transferred automatically thereto. The Personal Card-reader may then extract the sale amount currency and request the Cardholder to enter the sale amount in that currency.
3. The Cardholder is then, as evidence of he/she agreeing to the transaction, invited to enter a personal security code, e.g. a PIN on the Personal Card-reader. The
Personal Card-reader requests the payment card (ICC) to verify the PIN.
4. The Personal Card-reader requests the payment card (ICC) to sign the transaction-related data (i.e. the challenge) using a suitable encryption routine.
5. The ICC returns a cryptogram (MAC) over the transaction data and other ICC specific data that the Card Issuer will need to validate the cryptogram. Methods of signature and/or encryption are known from books mentioned above as well as "Applied Cryptography", B. Schneier, 1996, ISBN 0-471-11709-9, "Understanding
Public Key Infrastructure", C. Adams, S. Lloyd, New Riders, 1999.
6. The Personal Card-reader then builds a data token using part of the cryptogram and the variable data identified by the Card Issuer.
7. The Personal Card-reader formats the data token and presents it to the Cardholder who will enter it at the Cardholder Interface Application either manually or by transmission.
8. The Cardholder Interface Application builds the AAV for inclusion in the UCAF. The Cardholder Interface Application inserts the Chip-UCAF generated for this particular transaction into a hidden authentication data field provided on the Merchant UCAF Authentication Page. The transaction is then submitted for authorisation processing by the Merchant.
9. The Merchant submits an authorisation request to its Acquirer. The authorisation request must include the unaltered Chip-UCAF value that will be verified by the Issuer during authorisations processing. 10. The Acquirer accepts the (local) authorisation request and creates an
Authorisation Request Message. This message includes the Chip-UCAF data. The Authorisation Request Message is forwarded via a banking network to the Card Issuer. The Acquirer and the Issuer need to agree on the UCAF specifications for any proprietary message format(s). 11. The banking network forwards the Authorisation Request Message, including the Chip-UCAF, to the Card Issuer. 12. Upon receipt of the Authorisation Request Message, the Card Issuer will perform the following: a) If the Authorisation Request does not indicate that the Merchant was UCAF- enabled (e.g. Security Level Indicator bit set to '0' indicating "UCAF not supported by merchant", see later), the Authorisation Request will be processed in a business-as-usual manner by the Issuer's authorisation system. b) If the Authorisation Request indicates that the Merchant was UCAF-enabled and the Cardholder is registered for Chip-UCAF service but no Chip-UCAF authentication data is present (e.g. Security Level Indicator bit set to T indicating " UCAF supported by merchant but not provided by Cardholder", see later), the Issuer must determine whether to approve or decline the authorisation. Such a scenario indicates that the Cardholder did not use the Chip-UCAF-enabled
Cardholder Interface and Personal Card-reader to process the payment transaction, c) If the Authorisation Request contains UCAF authentication data, the Card Issuer validates the AAV.
13. The Issuer responds with an approval or declines based on the outcome of the previous step. This response is returned to the Merchant, via the same network systems, who will then respond to their customer as appropriate.
14. The Merchant's response to their customer can be in any suitable format, e.g. through an HTML page confirmation for online authorisations, and via e-mail for batch authorisations. The security of Chip-UCAF relies on certain security features. More specifically, Chip-UCAF relies on the generation of cryptograms by the ICC, namely the Application Request Cryptogram (ARQC) or the Application Authentication Cryptogram (AAC), to establish:
• A proof of cardholder presence, and • A proof of transaction approval by the cardholder.
In addition, it offers a protection against the replay of genuine transactions and against the generation of fake Chip-UCAF transactions. Therefore, when used in conjunction with suitable security measures, especially related to PIN security, Chip-UCAF offers an adequate level of security to enforce the non-repudiation by the cardholder of Internet transactions.
The assessment of the level of security offered by Chip-UCAF is based on the following assumptions:
• The Main Cardholder Device (MCD), i.e. the platform used by the cardholder for performing the actual payment operation, is considered trusted. This applies to the physical device, e.g. a PC or a mobile phone, to the Interface Application (IA) generating the challenge and to the application communicating with the Personal Card-reader when relevant. Because of the uncontrolled nature of the MCD, this assumption is perceived valid for any similar product. • The security of sensitive payment details, e.g. PAN or expiry date, entered at the MCD and sent to the merchant is outside the scope of this product. The confidentiality of this data should be enforced by encryption of the link between the MCD and the merchant, e.g., by relying on SSL encryption, and by the protection of the card details on the merchant host system.
The ICC establishes the proof of cardholder presence through the use of a validation, e.g. an off-line PIN validation. Off-line PIN validation is required prior to the generation of an ARQC. As a consequence, the cardholder presence is required to generate a valid ARQC, and the existence of such a valid cryptogram is sufficient to demonstrate this cardholder presence.
However, this is not the case for the generation of the AAC, which does not mandate an off-line PIN validation. In order to establish proof of cardholder presence, the issuer relies solely on the CVR transmitted within the challenge response. Card Verification Results (CVR) refers to any information transmitted from the card and allowing the issuer to check whether or not the cardholder PIN has been correctly verified by the card. It is important to protect the integrity of the CVR during transmission.
This property is ensured when the ICC includes the CVR into the AAC calculation input data. However, such behavior is not mandatory. It should be understood that those ICCs that do not include the CVR into the ARQC or AAC calculation input data could be used without PIN for Internet transactions. Consequently, such ICCs should preferably not be used in the frame of the Chip- UCAF programme. Chip-UCAF uses a digest of the transaction description as input to the ARQC or AAC calculation. This digest is used as the UN field from the input parameters to the ARQC or AAC calculation. A successful validation of the cryptogram by the Issuer, combined with the proof of cardholder presence, provides some assurance on the approval of the transaction by the cardholder. In order to ensure that the transaction description is actually taken into account, the ARQC or AAC calculation must effectively use the Unpredictable Number (UN). However, such behavior is not mandatory. Consequently, those ICCs that do not include the UN into the ARQC or AAC calculation input data should preferably not be used in the frame of the Chip-UCAF programme.
In order to ensure protection against replays of genuine transactions, two conditions should be fulfilled:
• The ATC as received from the ICC must be checked against the last received ATC for that particular ICC. Transactions using an already received ATC should be discarded.
• The ARQC or AAC generated by the ICC must vary as a function of the ATC. This is the case only when the ATC is included into the input data to the ARQC or AAC calculation. However, such behaviour is not mandatory. Therefore, those ICCs that do not include the ATC into the ARQC or AAC calculation input data should preferably not be used in the frame of the Chip-UCAF programme.
The main security issue associated with the use of a Personal Card-reader device is the risk of disclosure of the card PIN or of card-stored sensitive information, such as ISO2 track, by the device itself. Fraudulent or tampered Personal Card-readers may endanger the confidentiality of the PINs or ISO2 track. The level of risk depends on the type of device:
• The stand-alone nature of the unconnected Personal Card-readers requires these devices to be physically accessed by malicious parties wanting to gain access to confidential information. Only small-scale attacks are feasible on such devices and therefore the impact of such attacks is expected to be low.
• One-way or two-way connected Personal Card-readers offer more fraud possibilities, due to the presence of a physical connection. Large-scale attacks could be feasible on such devices and therefore, the impact of such attacks is expected to be higher.
• Integrated Personal Card-readers provide even more flexibility in terms of transparent communication with the external world, offering additional potential for fraud.
Also, the ARQC or AAC as returned by the ICC need not transferred completely to the Issuer. They can be truncated as specified by the IIPB and so the IIPB must be defined in such a way that a certain number of bits, e.g. at least 16 bits, from the ARQC or AAC are included into the data token returned by the Personal Card-reader. Because of the reduced size of the truncated cryptograms, fraud detection systems should be in place to detect abnormal numbers of failed cryptogram validations and take any appropriate action.
The ARQC or AAC should be validated by the Issuer on the basis of the information provided by the merchant. That is, in the verification process, the issuer should build the challenge from the original input data rather than relying on a challenge provided by the cardholder device. This requires that the input data is sent to the Issuer from the merchant as well as the special authentication token in accordance with the present invention.
A card used to calculate the Application Cryptogram (ARQC or AAC) must use the CVR as input to the calculation. Cards which do not so must not be used for Chip-UCAF authentication. A card used to calculate the Application Cryptogram (ARQC or AAC) must use the UN as input to the calculation. Cards which do not so must not be used for Chip-UCAF authentication. A card used to calculate the Application Cryptogram (ARQC or AAC) must use the ATC as input to the calculation. Cards which do not so must not be used for Chip-UCAF authentication. Issuers should ensure that an ATC is not reused.
Issuers should ideally employ fraud detection systems to detect and act on abnormal numbers of failed cryptogram submissions.
The Issuer should rebuild the challenge data for verification of the cryptogram from the authorisation message, rather than rely on that supplied by the Cardholder's software in the UCAF itself.
Fig. 8 shows detailed PCR and Chip-UCAF Flows in accordance with an embodiment of the present invention. This diagram and following text serve as illustrations only of an embodiment of the present invention and of the steps involved in the Chip Authentication Programme, starting from the point where the Merchant supplies the UCAF Merchant Data on a UCAF Authentication Page to the point where the Merchant receives the Authorisation Response from their Acquirer. Further, the particular order of some steps is arbitrary or rather not compulsory, e.g. Card Inserted at step 8. For the purposes of this embodiment it is assumed that the Main Cardholder
Device is a PC running a standard browser, and that the UCAF Merchant Data is presented in hidden HTML form fields. This embodiment assumes that an unconnected PCR is used. Where an unconnected or one-way connected device displays a prompt to the Cardholder to enter some data, not including PIN entry, the two-way connected or integrated device must request to the Cardholder IA that the same element of data be passed to it. However the precise mechanics of this communication protocol are proprietary to any implementation. Confirmation of the Authorisation from the Merchant to the Cardholder is not excluded from this invention.
In Fig. 8 it is assumed that the Merchant has already collected the payment details, including PAN, Expiry Date, etc. and is at the stage in the order processing pipeline where the order and payment details can be finalised through a UCAF Authentication Page. The Cardholder has already personalised his/her Cardholder IA with details of the PAN so that when the last 5 digits of the PAN being used for this payment are presented in the UCAF field, the Cardholder IA is able to recognise if it can act on behalf of that PAN.
Referring to the numbering of Fig. 8: 1. Collate Transaction Data - The Merchant collates the transaction-related data required as per the UCAF specification. 2. Send Transaction Data - The Merchant transmits the transaction data through the mechanism defined for the given e-commerce channel, as defined by the UCAF specification for that channel. 3. Detect UCAF Fields - The Interface Application (IA) installed on the Main Cardholder Device (MCD), detects the presence of the UCAF hidden fields, determines that a number, e.g. the last 5 PAN digits supplied by the Merchant relate to a PAN already known to the IA, validates the remaining UCAF data and presents itself. 4. Display Transaction Data - The IA displays the transaction-related data to the
Cardholder through its user interface. The Cardholder may decide at this point to reject the transaction. 5. Confirm Card Details - The Interface Application may request the Cardholder to confirm that the card details it has selected are correct. This may take the form, for example, of reminding the Cardholder which card to physically use in the PCR, e.g. perhaps through the use of a 'friendly' identifier the Cardholder associated with the particular card when personalising the Cardholder IA with the card details. 6. Generate Challenge - The Interface Application causes the PCR Challenge to be generated from certain transaction data + PAN.
7. Display PCR Challenge - For unconnected or one-way connected devices, the Interface Application displays the challenge, which must be entered into the PCR by the Cardholder.
8. Card Inserted - The Cardholder inserts the ICC5 into the PCR.
9. Transfer PCR Challenge - The PCR Challenge is transferred to the PCR. For an unconnected or one-way connected device, the Cardholder does this by entering the challenge into the PCR, in response to the prompt from the Interface Application and the PCR itself. Otherwise it can be transmitted to the PCR.
10. Optional: Transfer Amount - Where the authentication scheme requires an amount and currency, the amount is transferred to the PCR. For an unconnected or oneway connected device, the Cardholder does this by entering the amount of the transaction into the PCR, in response to the prompt from the PCR. Otherwise it can be transmitted to the PCR.
11. Enter PIN - The Cardholder enters a security or validation code such as a PIN at the PCR or the MCD, in response to prompting from the Interface Application and/or the PCR itself.
12. Create UN - The PCR creates the Unpredictable Number. 13. Generate AC - The PCR constructs and sends a Generate AC command to the card.
14. Response, incl. AC - The card returns an AC, amongst other data, as the response to the PCR.
15. Create PCR Token - The PCR 'strips down' the response, based on the Issuer specifications found in the IIPB, to create the PCR Token.
16. Display PCR Token - The PCR displays the decimal numeric token to the Cardholder.
17. Transfer PCR Token - The PCR token is transferred from the PCR. For an unconnected device, the Cardholder does this by entering the PCR Token into the Interface Application, in response to the prompt from the Interface Application and the display on the PCR. Otherwise it can be transferred automatically.
18. Encode UCAF - The Interface Application encodes the Chip-UCAF structure, sets the UCAF Control Byte and then Base64 encodes it for transmission in the UCAF. 19. Return UCAF - The Interface Application codes the various return data items into the Merchant payment request communication.
20. Build Authorisation Request - The Merchant extracts the data supplied by the IA in the hidden fields returned to the Merchant and builds up the proprietary authorisation request to their Acquirer.
21. Authorisation Request - The Merchant passes the authorisation data, including the UCAF to their Acquirer, who passes it on to the appropriate Issuer.
22. Set SLI - The Acquirer sets the Security Level Indicator (SLI) as appropriate for the authorisation transaction. 23. ISO 8583-0100 - The Acquirer forwards the Authorisation Request to the Issuer who then performs some initial standard processing on the message.
24. UCAF Processing - The Issuer checks for the presence of UCAF.
25. Optional: Rebuild Challenge - The challenge to the PCR is recreated from the message data to allow the Unpredictable Number to be regenerated. 26. Retrieve Card Data - The Issuer must retrieve certain data elements from the ICC database in order to be able to rebuild.
27. Rebuilding - The PCR token is generated by the Issuer, based on the knowledge of the algorithm used by the PCR.
28. Compare - The Issuer compares the reduced PCR Token in the Authorisation message with the PCR Token generated from the input data. This may involve changes to a 'security box', where it handles comparison.
29. ISO 8583-0110 - The Issuer sends the Authorisation Request Response to the Acquirer.
30. Authorisation Response - The Issuer returns the authorisation response, via the Acquirer, to the Merchant.
Steps 1 to 21 are specific to this scheme;
• The Merchant collating and presenting the transaction data in a particular, specified format. • The Cardholder's main access device, Cardholder Interface Application, the PCR and the Cardholder themselves causing the PCR Token to be generated and returned to the Merchant.
• The Merchant passing new data into the existing Acquirer communication. Step 22 shows extra steps an acquirer must take when handling UCAF data;
• The Acquirer is responsible for setting the Security Level Indicator depending on the data supplied by the Merchant.
Step 23 is a summary of the existing transmission of payment data to the Acquirer and then on to the Issuer, via the ISO 8583 - 0100 Authorisation Request message;
• On receipt of the 0100 message the Issuer must perform a small step to determine if there is any data in the UCAF and processes it appropriately.
Steps 24 to 28 are specific to this scheme;
• The Issuer extracts the data from the UCAF and verifies the PCR Authentication Token.
Steps 29 and 30 are a summary of the existing ISO 8583 - 0110 Authorisation Request Response message and response to the Merchant;
• The Issuer, satisfied that the PCR Token is valid, returns an 0110 message to the Merchant, via the Acquirer.
This detailed flow diagram and description show a solution that is independent of the e-commerce channel involved. Steps 2 and 19, the link between the Interface Application and the Merchant Systems, are the points at which there is a dependency on the specifications for a given e-commerce channel. In accordance with an aspect of the present invention different channels can be used and will require different Issuer software, in the form of the Interface Application, and probably different, but necessarily standardised merchant interaction, e.g. HTML forms, XML data exchanges, etc. However, data content, algorithms and flows remain the same across different channels. In the above scheme the Merchant supplies details about themselves and the transaction. In summary these data elements are selected from;
• Merchant Name
• Merchant City • Merchant State/Country Code
• Currency Code
• Sale Amount • Merchant Transaction Stamp
• UCAF Brand
• Payment Card Number (Last 5 digits)
One card specific data which may be used in methods according to the present invention is the Issuer Internet Proprietary Data (IIPD). The Issuer Internet Proprietary Data (IIPD) is a data object whose presence on a card is optional. It is unrelated to the similarly named Issuer Internet Proprietary Bitmap (IIPB), except for its introduction due to the Chip Authentication Programme. It contains data that the Issuer chooses to use in a proprietary manner, nominally in conjunction with the generation of the cryptogram when used in the Internet environment, although it may also carry other or alternative data. For example, the transfer of a Card Sequence Number (CSN) to the Issuer may be required. This is static for a given card and can be passed to the Issuer by encoding it into the IIPD. This CSN can be passed in the lower nibble of the first IAF 'byte'. This technique saves on cardholder data entry. Its use is literally proprietary to an Issuer.
The first byte of the IIPD carries a set of generic flags, predominantly for use by the Personal Card-Reader (PCR). Table 1 provides a schematic indication of these.
Table 1 IIPD Flag-Byte Settings
Figure imgf000030_0001
When Bit 8 is set to 1 , it signifies that the Issuer requires that the transaction amount and currency must be used when generating the AC. For the PCR this means it prompts/requests the Cardholder/Main Cardholder Access Device (MCD) to supply the currency and amount and for the Interface Application (IA) that the amount and currency need to be supplied. When Bit 8 is set to 0, default values for the amount (0) and currency (999 - Code used for transactions with no currency involved) will be used when generating the AC. When Bit 7 is set to 1 , it signifies that the Issuer requires that the type of cryptogram to be requested from the card is an ARQC. When Bit 7 is set to 0, it signifies that the Issuer requires that the type of cryptogram to be requested from the card is an AAC. IIPD data beyond the first byte is free for a use which is proprietary to the Issuer.
The IIPD is an optional structure, since its contents may not be required by a given chip implementation in order to generate cryptograms for Internet associated use. However since it contains indicators which instruct the PCR on how to proceed with processing, if it is not present then the PCR must rely on a default setting. If the card has no IIPD, then a default byte value of 0x40 can be used, e.g. "No transaction amount and currency, ARQC to be generated". The IIPD must be transmitted to the Issuer in the Accountholder
Authentication Value (AAV). However it is preferably not transferred to the Cardholder Interface Application (IA) by the PCR since this would place too large a data transfer burden on the Cardholder, for unconnected devices. Since the IIPD is static for a given card, it can be supplied to the Cardholder IA in the same manner as the PAN and other static card data are supplied to the Cardholder IA.
Furthermore, the Cardholder IA must know the IIPD, or use the default value, e.g. 0x40, in order to determine whether or not the currency and amount need to be transferred to the PCR. The currency information can be transferred as part of the PCR Challenge. Due to both the data space limitations imposed by UCAF compliance, and the need, at least for some Issuers, to use an unconnected or one-way connected device, the data that the device must transfer back to the MCD is size-limited. Therefore, only a selected portion of the data required by the Issuer to re-compute the AC, generated in response to the GenerateAC command sent to the ICC, is preferably transferred. The response, by the ICC, to the first GenerateAC command is made up of the following elements;
• Cryptogram Information Data (CID)
• Application Transaction Counter (ATC) • Cryptogram computed by the ICC (AC)
• Issuer Application Data (IAD)
They contain data that is either; • Unique to this transaction and must be transferred from the PCR to the Cardholder device by the Cardholder.
• Assumed to be particular values for this particular scheme and so need not be transferred from the PCR to the Cardholder device by the Cardholder.
• Unique to this transaction or ICC and known or at least deducible by the Issuer Host, via its card database and so need not be transferred from the PCR to the
Cardholder access device by the Cardholder.
The Issuer Internet Proprietary Bitmap (IIPB) is a data object whose presence on a card is optional. The data consists of transmit flags indicating which bits in the GenerateAC response are required by the Issuer Host system. The flags correspond on a bit for bit basis to the bits that must be sent from the CID (e.g. 1 byte), ATC (e.g. 2 bytes), AC (e.g. 8 bytes) and IAD (e.g. 0 - 32 bytes) (see Fig. 9). An IIPB can vary in length, e.g. from 11 bytes, where no IAD is defined to 43 bytes where an Issuer's application technology uses the full 32 bytes available to the Issuer Application Data (IAD).
The IIPB allows the Issuer to be completely selective as to which and how many bits of these values it will use for the purposes of validating the authentication thus removing the need for the PCR itself to be aware of, and thus specific to any particular card technology. The IIPB can be used as a bit-mask which allows the PCR to build up a token which will be incoφorated into the AAV by the Cardholder I A and passed to the Issuer.
An Issuer can define an IIPB that will mark the minimum possible bits that they will require to verify the cryptogram. The number of bits marked as being required determines the potential size of the data token produced by the PCR. For puφoses, primarily associated with existing cards not having the new IIPB tag, the IIPB is an optional structure. However since it is used to identify the bits that the PCR must extract and compress, if it is not present then the PCR must rely on a default setting. The default IIPB can be, for example, a 19-byte structure. The result of this is 35 bits of data being sent to the Issuer and requires 11 decimal digits to represent it on the display of the PCR. Adding on the final check digit the default IIPB results in a 12-digit token to be entered by the Cardholder.
Issuers can specify an IIPB appropriately for an application technology. This IIPB will then need to be included in the personalization specifications for that application in order that the PCR uses the IIPB stored in the card rather than the default IIPB stored in the PCR.
If an Issuer feels comfortable that, or requires that, there will be a one-to-one match between their issued cards and the PCR used to create the token, then they may change the default IIPB in those particular readers. This would mean that an IIPB need not be required to be stored in the card. However, any such cards could not be used on PCRs that use the default IIPB.
The data which is sent to the Merchant from the Cardholder's browser can consist of just the UCAF Authentication Data Field for each browser channel. The UCAF can contain a 24-byte user authentication token. These 24 bytes are preferably encoded, e.g. Base64 encoded, by the Cardholder IA to give 32 ASCII characters of data that are returned to the Merchant. The Merchant passes the UCAF data, in their proprietary communications with the Acquirer who can then populate the UCAF in the Authorisation Request message sent to the Issuer. The generic structure of the UCAF is illustrated in Fig. 10.
The UCAF Control Byte is a 1-byte value, which indicates what type of data the UCAF is being used to transport. The following values can be used for UCAF Control Byte encoding;
• A first value such as 0x82 - SPA-UCAF, using a wallet server • A first value such as 0x88 - Chip-UCAF, using an ICC.
Where the Merchant needs to retransmit an authorisation, either due to a previous decline, or for split shipments, the top bit of the UCAF Control Byte must be cleared, leading to the following values;
• A third value such as 0x02 - Subsequent SPA-UCAF Authorisation, using wallet server
• A fourth value such as 0x08 - Subsequent Chip-UCAF Authorisation, using chip The present invention includes other authentication techniques, such as biometrics, and in such a case the specific technique would be assigned its own Control Byte value and the structure of the Application-Specific Data would be tailored to support a biometrics authentication approach. In this case, all biometrics authentication applications should use a consistent Application-Specific Data structure.
Accountholder Authentication Value (AAV) is shown schematically in Fig. 11. The following data is transferred to the Issuer in the UCAF:
• IIPD - Optional, variable in length, but always a multiple of bytes. It may contain a Card Sequence Number, e.g. 4 bits defined by Issuers to be at an Issuer defined position in the IIPD for that card.
• Unpredictable Number, e.g. 32 bits (4 bytes) in length • IIPB Data Token, as encoded in the PCR Token - Unknown length, number of bits determined by IIPB.
The length is preferably restricted, e.g. to a first maximum number of bits such as not to be greater than 184, since, ideally, the Issuer should not supply an IIPB, which when combined with the IIPD could result in more than a second maximum number of bits, e.g. 152 bits (Max data area - Length(UN)) needing to be transferred. As a precaution, the Cardholder IA can ensure that any operation resulting in more than the first maximum, i.e. > 184 bits, will result in an error and the data will not be encoded. There need not be an indication built into the encoding of the AAV for Chip- UCAF to indicate whether or not there is any IIPD data present. It is up to the Issuer to ensure that their host system knows what to expect in the AAV. The encoded inclusion of any IIPD by the Cardholder IA is dependent on whether any IIPD is associated with the payment card used by the Cardholder for the particular transaction.
The UN encoded into the AAV for Chip-UCAF can be a full 4-bytes in size, which is the same size as the UN sent to the ICC in the GenerateAC command. The magnitude of the UN can be altered within its full range, e.g. either increased or potentially even decreased without affecting the data transportation format.
A UN range-limitation can be a result of limiting the number of digits a Cardholder is required to enter to transfer data to the PCR from the MCD. For compatibility reasons this limitation can be applied to both connected and unconnected devices unless there is another indication of the size of the PCR Challenge presented to the PCR.
The Issuer knows the length of both the IIPD and the IIPB Data Token. The Cardholder IA knows the length of the IIPD, however it does not know the length of the IIPB Data Token and so it should preferably right justify the bits, i.e. least significant bit appears in last bit position, using 0 filler, as illustrated in Fig.12. As a consequence, any left justified IIPB Data Token data not passed in the PCR Token, because it was set to 0 and therefore did not figure in the numeric token derivation, will be set to the 0 value it represented. This is because the Cardholder IA will have first zeroed out the full 23-bytes of the AAV, resulting in all the remaining bits from the leftmost set bit of the transferred PCR Token back up to the UN having the setting of 0. Some of these bits will represent the 0 value they have in the IIPB Data Token whilst the remainder will just be 0 filler.
Although the Cardholder IA will not know which bits represent data set to 0 and which filler also is set to 0, it does not matter since the Issuer will know which bits are data, since it knows the effective length of the IIPB.
The link between the Merchant and Acquirer can be proprietary, however the Merchant should preferably transfer the following additional data to the Acquirer;
• UCAF Authentication Data Field
• Error Status Indicator
The Issuer receives the Authentication Request message through the authorisation network from the Acquirer. It will contain the standard authorisation data in addition to a modified Security Level Indicator (SLI) and the UCAF authentication data. The Authentication Request message contains the SLI which has been extended for use with UCAF transactions.
To improve the accuracy of cardholder data entry a single trailing check digit can be used. The inconvenience of entering an additional digit is outweighed by the value of the validation check this extra digit imparts. The algorithm used for the check digit can be any suitable check algorithm such as the "Luhn Formula", also known as "Modulus 10" as used to validate a PAN. The check digit can be applied to the n-digit PCR challenge, e.g. requiring the cardholder to enter a certain number of digits, e.g. 8 digits for a 7-digit challenge. The Personal Card-reader validates the check digit and informs the cardholder when an incorrect value is entered. If a combined UN/Currency number is used, the check digit shall apply to the complete 'number'. If an incorrect value is entered, the device shall preferably not abandon or restart the process, but can wait/prompt for the PCR challenge to be entered again. If desired a limit or no limit can be placed on the number of invalid PCR challenge entry attempts.
For an unconnected device, the check digit is preferably applied to the displayed n-digit PCR token, e.g. requiring the cardholder to enter onto the MCD, a certain number of digits such as 13 digits for a 12-digit PCR token. The Personal Card-reader shall compute the check digit and apply it at the end of the displayed PCR token.
For a one-way connected device, the check digit should also be applied since the one way communication does not allow for handshaking verification of data transmission. The Cardholder IA must verify the check digit for these devices and report an error to the Cardholder if one is detected. This would result in the transaction with the PCR needing to be repeated.
The check digit is a transmission-medium error-detection mechanism. For communication in either direction between an MCD and a two-way connected/integrated device, the underlying transmission protocol may also correct any errors relating only to the transmission.
The PCR Challenge is passed to the Issuer. The PCR Challenge consists of one or more parts, e.g. 2 or 3 parts, for example depending on whether the transaction amount is required in the GenerateAC command:
• Unpredictable Number (UN) • Optional Currency Code
• One or more check-digits such as the Luhn check digit mentioned above
The PCR Challenge is used to create the Unpredictable Number (UN). The PCR will supply the UN to the ICC as part of the GenerateAC command. The UN can be supplied as a full 32-bit structure, containing the value obtained from the Cardholder I A. The range of this value is preferably limited. The magnitude of this range can be determined by the maximum number of digits it is deemed acceptable for the Cardholder to key into an unconnected device. The term 'unpredictable' refers to the fact that the number is unpredictable to the ICC, not that it is unpredictable to an application supplying the value to the ICC, or any other entity outside of the card.
The PCR Challenge is preferably a decimal number with a certain number of digits, which must be transferred to the PCR. As well as the UN, it can also consist of an additional trailing check digit and an optional currency code. Thus for the unconnected and one-way connected devices, where the Cardholder transfers the challenge manually, the number of digits to enter is an issue of Cardholder convenience, or rather inconvenience. For other types of connected devices the challenge can be passed directly and therefore the number of digits used is not an issue. However, since the Issuer will and should be unaware of the type of device used by the Cardholder for a particular transaction, for reasons of interoperability, all Cardholder IAs preferably use the same maximum number of digits to represent the possible range of the UN.
The number of digits can be limited, e.g. up to 8. The PCR can be unaware of this 'restriction' as the UN part of the PCR Challenge is simply a value that must be able to fit into the 32-bit UN structure.
In a scheme where the Issuer requires that the PCR incoφorate the amount and currency in the GenerateAC command used to generate the AC (e.g. as indicated by the IAF flag setting in Byte 1 of the IIPD), the PCR can require that the amount and currency be transferred to it. In order to reduce the confusion to the cardholder that could arise when transferring a 3 -digit currency code to an unconnected or one-way connected device, the code can be incoφorated onto the end of the UN passed in the challenge. Thus, when the check-digit is accounted for, a cardholder enters a total of a 12-digit challenge when the scheme requires amount entry. In summary the sources of the PCR challenge can be:
• Transaction Amount
• Transaction Currency
• Merchant Name • PAN
The mechanism used to generate the PCR Challenge must be interoperable since the Issuer will need to reproduce the same actions on the host system where the UN is checked for validity against the source data. The amount, as supplied by the Merchant in the UCAF data fields and as displayed to the Cardholder, is preferably encoded, e.g. BCD encoded, right justified and zero padded into 6 bytes.
The currency, as supplied by the Merchant in the UCAF data fields and as used in a currency lookup to display the alphabetic code to the Cardholder, is preferably encoded, e.g. BCD encoded, right justified and zero padded into 2 bytes.
The transaction amount and currency are preferably always used in the calculation of the Unpredictable Number part of the PCR Challenge, regardless of the IAF setting (bit 8) for using amount and currency. That flag determines whether the amount and currency are additionally and explicitly used in the cryptogram calculation and with regard to the challenge only affects whether the challenge is used as the transfer mechanism for the currency code from the Cardholder IA to an unconnected Personal Card Reader. The Merchant name, as supplied by the Merchant in the UCAF data fields and as displayed to the Cardholder, is converted from the 22 Unicode two-byte characters received from the Merchant into 22 one-byte ASCII characters. This can be done by taking away each 'odd' byte - the first byte in each of the 22 two-byte Unicode sequences. The PAN should be encoded, e.g. BCD encoded, into the smallest number of bytes, and where an odd number of PAN digits is supplied, e.g. a 19-digit Maestro PAN, it should be right justified and zero padded. The inclusion of the PAN in the challenge generation requires that the Cardholder IA has knowledge of the full PAN being used by the Cardholder for this transaction. A suitable encryption algorithm is applied, e.g. a SHA-1 hash algorithm, to the concatenated input data of 38 or 40 bytes formed from: Amount, Currency, Name and PAN. The first 4 bytes of the resultant 20-byte hash data structure are 'extracted' and treated as a 32-bit unsigned integer value. A modulus of 100,000,000 is then applied to this value to obtain a value in the range up to 99,999,999. If the currency code must be transmitted it is now appended. Finally a check bit such as a Luhn check-digit is applied across the digits computed so far and appended on the end to create the challenge. The full process flow is shown in Fig. 13.
The PCR Challenge will be passed as a number, with optional zero padding up to 8 digits. The zero padding is optional since the PCR does not rely on a fixed number of digits for the PCR Challenge, but rather uses an OK/Enter button to indicate the end of the PCR Challenge entry. To this number can be added the optional currency code and calculated check digit.
This transfer format should ideally be used for all types of device in order to keep logical differences between devices as small as possible, ideally only the communications protocol itself being different. This means that the difference between passing challenge data to either type of device lies purely in the communication/transfer mechanism and not in the processing of that data. Since the challenge is passed in the AAV, a possible optimisation for the Issuer
Host is to use the last passed challenge in re-computing the PCR Token without needing to first re-compute the PCR Challenge. The drawback of this optimisation is that the Issuer does not check the validity of the challenge, which might later lead to Cardholder dispute and potential chargebacks. The implementation of the scheme described uses an Application Cryptogram
(AC) as the mechanism for authenticating the ICC and the cardholder. The command, GenerateAC, is used to request the ICC to generate either an Application Request Cryptogram (ARQC) or if bit 7 of the IAF is set to 1, an Application Authentication Cryptogram (AAC). The data that can be supplied in this command is: • Unpredictable Number (UN)
• Amount
• Currency
The Unpredictable Number (UN) is a 4-byte/32-bit component of the data passed to the ICC in the GenerateAC command. It is a number/data that is unpredictable to the ICC, as opposed to the application, and is effectively the transaction-related challenge to the card. The PCR Challenge is used to make up the UN. The maximum number of 8 digits of the challenge account for the lower 27 of the 32 bits required for the UN. The remaining 5 bits will therefore, be zero for the puφoses of this scheme. The UN part of the PCR Challenge should be thought of as passing a numeric value (see Fig. 14). When this numeric value is treated as an unsigned 32-bit integer, all bits past the highest significant set bit are implicitly set to 0. When the UN is sent to the card, the raw 'binary' value of the decimal numeric challenge entered by the cardholder is passed in the APDU command. It is not sent as the BCD encoded equivalent of the entered challenge digits. The use of the amount and currency is at the discretion of the Issuer. When the
Issuer has indicated that the amount and currency must be used, the Personal Card- reader will have been supplied with amount and currency data. The currency is supplied as part of an extended PCR Challenge and the amount is transferred/entered explicitly/separately. When the Issuer has indicated that the amount and currency must not be used, or has not indicated this choice and the default of not using them has been followed, then default values for the amount and currency can be used.
As the full response to the GenerateAC command may be too large to be sent to the Issuer, the PCR can use the IIPB to perform a data extraction and compression process that results in a string of bit values that the Issuer has determined must be communicated to them - see Fig. 15. A bit setting of 1 can be used to indicate that the corresponding bit position in the data is required and needs to be sent. A bit setting of 0 can be used to indicate that the Issuer either knows, or is able to otherwise derive what the bit setting should be and thus the bit does not need to be sent. The IIPB data token is preferably built up from right to left, with the first bit to be extracted placed into bit 1 of the last byte of output data, the second in bit 2, etc. The IIPB data token is filled in this manner until there are no more bits left to transfer.
The IIPB Data Token is the data, which is transferred from the PCR to the Cardholder IA. All connected device types transfer this data directly to the MCD, whereas an unconnected device will use the cardholder to transfer this data manually.
With respect to the PCR Token for an Unconnected Device, an unconnected device will compute and display a number that represents the bit pattern of the data to be transferred. The cardholder must then enter this number into the appropriate area made available in the Cardholder IA running on the MCD. An unconnected PCR creates a numeric token, generated purely to transfer data from the PCR to the Cardholder IA running on the MCD, from the IIPB Data Token. It is important that the algorithm used for converting the bits into displayed numeric digits is interoperable and thus reversible on the Cardholder IA, i.e. the same algorithm used to convert from bits to token must be reversed to convert from token to bits. A 'compressed' way to do this is to treat the bit pattern as a binary number and perform a mathematical conversion from Base-2 to Base- 10 (Fig. 16).
The PCR Token may be presented using spaces, dashes or commas as separators, and is limited to a maximum possible display length, e.g. of 20 digits, including one or more check digits.
The Cardholder IA will not expect any particular sized token as it will use leading zero padding when encoding the IIPB Data Token into the UCAF to fill the remaining data space. Error detection and correction can be provided. The PCR Token can make use of one or more check-digits such as a Luhn check digit, applied across the full token digits. The Cardholder IA will verify the check digit to report any transmission errors. In case of any mis-keying, the Cardholder IA will inform the cardholder who will have to re-enter the PCR Token in the Cardholder IA.
For a One- Way Connected Device the communication mechanism between the PCR and the Cardholder IA on the MCD can be proprietary, and any error detection mechanism can also be proprietary. However, it must be possible for the Cardholder IA to recognise that an error has occurred, particularly in one-way connected devices where it might not be possible to perform any type of hand-shaking protocol, and inform the Cardholder. Since in the uncommon event of a transmission error, the Cardholder IA will not be able to inform the PCR of that error, it is acceptable to ask the cardholder to repeat the authentication process on the PCR again from the beginning, i.e. Inserting card/switching on, entering data and PIN and then allowing the PCR to retransmit. Alternatively the PCR might employ a retransmit function/button.
For other connected device types, The communication mechanism between the PCR and the Cardholder IA on the MCD can be again proprietary, along with any error detection mechanism. A summary of the complete process described above is given in Fig. 17.
Using Chip-UCAF - a cardholder's perspective
Cardholders must subscribe into the scheme. In order to use Chip-UCAF, a cardholder will first need to have a suitable ICC. They will then need to have a Personal Card-Reader (PCR, either connected or unconnected) and the necessary thin- client Cardholder Interface Application (IA) software installed on a main accessing device such as a PC. Due to the nature of UCAF being a payment authentication scheme only for payment card details which have already been provided, the Cardholder Interface Application (IA) only responds to authentication requests for payment cards whose PAN it already knows about. Therefore Cardholders pre-register the details of any payment cards they intend to use for payment, with the Cardholder IA before those cards will be able to be used for UCAF authentication. When requesting authorization with a UCAF-enabled merchant, the Merchant will present the UCAF data to the Cardholder. When a UCAF client is available it will interact with the Cardholder. Cardholders will be required to 'know' a first and a second code ?? namely the PAN and the IIPD. The Cardholder must be responsible for keeping details of their PIN secret, so that in the event that an attempt is made to use the card without the Cardholder's permission it will not be possible for a PCR to produce a token without the correct PIN. The cardholder will need to install the local Chip- UCAF client on each PC that will be potentially used for e-commerce based purchases. The cardholder must register the PAN details of each payment card that will be used for UCAF payment authentication with the Cardholder Interface Application, before trying to use that card for payment and associated authentication.
From the Merchant perspective
The main merchant process flow is shown in Fig. 18. The two main aspects of concern to the Merchant are firstly changes to merchant web pages and secondly the processing required to support UCAF. In order for Merchant servers to support Chip- UCAF the Merchant server will have to present additional data via its web-site and process additional data inserted via the Cardholder Interface Application. For the puφoses of describing the UCAF scheme in the context of the effort required by Merchants, two types of relationship that a customer can hold with the Merchant as a Cardholder will be considered: Profiled, Non-Profiled. Express checkout and single- click require cardholders to be profiled whilst standard checkouts can be used by profiled and non-profiled cardholders alike. Single-click generally requires the customer to have allowed the single-click option, as many customers feel uncomfortable with this impulse purchase ability. In order to use UCAF, the Merchant server must have knowledge of certain Cardholder's payment details, e.g. PAN,
Expiry Date and CVC2, before presenting a UCAF Authentication Page containing the UCAF hidden data fields, since one of the fields must contain the last 5 digits of the PAN being used for the transaction.
To support the use of UCAF for the express checkout (Fig. 19), the order/payment details confirmation page must support the UCAF hidden fields and becomes, in UCAF functionality terms, a UCAF Authentication Page. This provides the opportunity for the Cardholder Interface Application (Cardholder IA) to present itself and request the necessary interaction with the Cardholder to obtain the UCAF authentication data. The Cardholder IA can then populate the UCAF authentication field prior to submission of the order by the cardholder.
To support the use of UCAF during the single-click purchase process (Fig. 20), the merchant server can support a UCAF Transfer Page. The UCAF Transfer Page is not intended for use by the cardholder and its display should indicate that an authentication process is underway. This page acts as the UCAF Authentication Page and presents the hidden UCAF fields. The UCAF Transfer Page must also support the UCAF hidden fields and provides the opportunity for the Cardholder Interface Application to present itself and request the necessary interaction with the Cardholder to obtain the UCAF authentication data. Some merchants that offer single-click also offer the facility to automatically combine a series of single-click purchases, conducted within a certain timeframe, into one single order. I.e. "I'll have that - Click - that - Click - oh yes and that - Click". Where multiple adjacent single-click purchases are combined, authorisation will generally only be sought after the order is 'closed' and the combined cost is known. This leaves an issue of how to resolve the amounts used for authentication against the amount used for authorisation as well as the disruption to the single-click process. Merchants may decide to authenticate; • Only the initial purchase of a combined single-click shopping action - by special arrangement, the Acquirer would then need to treat the authorisation as it would for a currency converted authorisation. This means putting the initial amount - the amount used for the authentication process so that verification of the authentication could take place. Each purchase cumulatively - Each Single-Click is accompanied by an authentication request (UCAF Transfer Page) to the Cardholder and each time the amount increases in line with the current accumulated total. Only the last UCAF authentication would then be sent to the Issuer.
The UCAF Transfer Page is required when a cardholder using UCAF initiates a single-click checkout in order to be able to invoke the authentication process and supply the UCAF data. Thus, the merchant must know if UCAF is being used prior to the single-click option being selected by the cardholder. An additional hidden field, the UCAF Enabled field, must be supported on each and every page that provides the single-click checkout option. The Cardholder Interface Application will recognize this field and automatically fill the field with a certain value such as "01" to indicate that a UCAF compliant Cardholder IA will facilitate the payment.
The UCAF Transfer Page does not need to be displayed when a single-click checkout is initiated without a UCAF compliant Cardholder IA that can perform the UCAF authentication for the particular card used by the Cardholder.
To minimise the impact on the single-click concept and complete the form fill process on the UCAF Transfer Page allowing the Merchant to collect the data, the Cardholder IA initiates a click event on a hidden button. The merchant provides the hidden button, the "UCAF Submit" button, on the UCAF Transfer Page. This button allows the Cardholder IA to initiate a click event when the form filling is complete. When the click event occurs the 'page' transmits the data that is to be sent in the authorisation request, to the Merchant's web server.
Since the IA cannot tell whether a page is a Transfer page or not, whenever a UCAF Submit button accompanies the required UCAF data input fields and authentication field on a page, the IA will always action it on completion of the authentication token generation process. Merchants are free to use this ability as they wish, i.e. they may utilise 'auto submit' on conventional UCAF Authentication pages if they wish to do so.
If the IA detects errors that result in setting specific error indication contents into the UCAF Authentication data field, or if the Cardholder cancels, and there is a UCAF Submit button present, the IA will still action the click event, submitting the form data to the merchant. Merchants that wish only to send 'good' authentication data should therefore be aware of the error indications and consider returning an appropriate error page to the Cardholder. To support the use of UCAF for a standard checkout (Fig. 21), the order/payment details confirmation page must support the UCAF hidden fields and become a UCAF Authentication Page. This provides the opportunity for the Cardholder Interface Application (Cardholder IA) to present itself and request the necessary interaction with the Cardholder to obtain the UCAF authentication data. The Cardholder IA can then populate the UCAF authentication field prior to submission of the order by the cardholder.
In order to use UCAF, the Merchant must have knowledge of the Cardholder's payment details, PAN, Expiry Date and CVC2, before presenting a UCAF Authentication Page with UCAF hidden data fields, since one of the fields must contain the last 5 digits of the PAN being used for the transaction. Therefore when using UCAF the combined order details confirmation/ payment details requesting page must be split into two pages, as illustrated. The UCAF Authentication or Transfer Pages are web pages that the merchant presents to the cardholder in order to confirm order and payment detail information. For UCAF-enabled merchants these pages are the facility by which UCAF data is presented and captured, prior to attempting an authorisation. Hence, the UCAF Authentication Page and the UCAF Transfer Page are the primary integration points among Merchant, Cardholder and Issuer.
The UCAF Authentication Page contains cardholder and transaction specific data that is transmitted via the public Internet. Therefore, the UCAF Authentication Page should preferably be protected using a sufficiently secure encryption method (e.g. 128-bit SSL or equivalent) to prevent the compromise of this data. All merchant server interaction with the Cardholder IA in the PC Browser based channel is via hidden HTML form fields. In order to ensure interoperability with all merchants and all UCAF applications, the implementation of these hidden fields has been standardised, including naming conventions, size and allowed content.
• Incoming data fields, i.e. supplied by the Merchant, appear in the HTML page source delivered by the Merchant web server to the Cardholder's browser. The values for these fields are set directly within the page source and are expressed in character string format, e.g. <INPUT type="HIDDEN" name="Ucaf_Currency_Code" value="978">
• Outgoing data fields, i.e. returned by the Cardholder, appear in the HTML page source delivered by the Merchant web server to the Cardholder's browser. The values for these fields are initially set to blank values within the page source, e.g. <INPUT type- 'HIDDEN" name="Ucaf_Authentication_Data" value=""> The Cardholder IA will, by interacting with the browser's Document Object Model (DOM), set the values programmatically as character strings. For incoming Merchant Supplied Data, the Merchant server presents the data values it must supply in the following hidden form fields:
• Ucaf_Merchant_Name - The Merchant's name consists of 88 hexadecimal characters (0-9, A-F) as 22 groups of 4 characters, with each group representing a Unicode character. The name supplied by the merchant in the UCAF field is the name that will be displayed to the cardholder by the Cardholder Interface Application (Cardholder IA). It is also the name that will be used in the generation of the challenge. • Ucaf_City - Up to 13 characters, the city to which the Merchant is registered with their Acquiring bank.
• Ucaf_State_Country - Up to 3 characters to carry the US State code or 3 character ISO 3166 alphabetic country code.
• Ucaf_Currency_Code - The three digit ISO 4217 currency code for the currency of the transaction.
• Ucaf_Sale_Amount - Up to 12 digits for the amount of the transaction expressed in the base currency units reflected by the currency code.
• UcafJVlTS - An optional field containing the hexadecimal representation of a two- byte merchant reference. • Ucaf_Brand - A two digit code representing the brand of the payment card details selected for this transaction by the Cardholder.
• Ucaf_Payment_Card_Number - The last 5 digits of the payment card details selected for this transaction by the Cardholder. This is used by the Cardholder IA(s) to determine if the card being used is one with which they are familiar and can therefore act on behalf of in order to produce a UCAF account holder authentication value.
With respect to outgoing Cardholder Returned Data the Merchant presents the following hidden fields in order to collect authentication information: Ucaf_Authentication_Data - Set to blank, i.e.'='"" by the Merchant and populated by the Cardholder IA with the UCAF Authentication Data. The data is returned to the
Merchant in the usual way for HTML form data. That means that all of the form fields will be 'POST'ed back to the Merchant's web server in a HTTP POST request, in text format. Both incoming and outgoing fields are posted back with the Merchant's web server process distinguishing between which data it is interested in as returned data and which it will not pay attention to as it was originally sent data. i.e. the read-only aspect of incoming fields is effectively enforced by the Merchant's processing just not making use of the data it is sent by the browser. With respect to the additional UCAF Fields to Support Single-Click, in order for the merchant to be able to support UCAF and present the UCAF Transfer Page during a Single-Click payment, the following hidden form elements must be present on any and every page that it is possible to select a Single-Click payment option from; • Ucaf_Payment_Card_Number - The last 5 digits of the payment card details selected for this transaction by the Cardholder. This is used by the Cardholder IA(s) to determine if the card being used is one with which they are familiar and can therefore act on behalf of in order to produce a UCAF account holder authentication value. • Ucaf_Enabled - Set to 0, i.e.'="00"', or blank, i.e. '='"", by the Merchant and set to "01" by the Cardholder IA if there is one and the payment card number matches a payment card known to the Cardholder IA.
Cardholders may opt to use a Single-Click method of payment because of its ease and lack of required interaction. In order to maintain this smooth flow for cardholders when using the extra authentication requirements of UCAF, a form submission button is made available. The Cardholder IA initiates a click event to automatically submit the UCAF Transfer page to the Merchant on completion of obtaining and populating the UCAF authentication data.
To properly implement this click event, the UCAF Transfer Page needs the following additional hidden form element;
• Ucaf_AAV_Submit - The hidden virtual button for the Cardholder IA to initiate a click event on.
The merchant server can capture relevant data and store it. The merchant server can capture and retain the UCAF Authentication Data Field supplied by the Cardholder Interface Application. The Authentication Data Field provides the merchant with data that links the cardholder to transactions. This data is required for the submission of subsequent authorisations for split-shipments and may be of value to the merchant during exception processing.
Merchants are required to request authorisation for all Chip-UCAF e- commerce transactions. Merchants must supply the UCAF on all authorisation attempts. Subsequent authorisation attempts must also include the AAV. However, the merchant needs to adjust the Control Byte for subsequent authorisations. The issuer may decline initial authorisations requests with an AAV older than a certain time such as 30 calendar days.
UCAF Authentication data need not be sent in 'real-time' to Issuers, just as authorisations need not be sent in real-time. Authorisation requests including UCAF authentication data therefore do not need to be treated any differently to normal authorisation requests in respect of batching data sent to the Merchant's Acquirer. Pre- authorisations are also allowed and are treated as for the initial authorisations.
Recurring payment transactions should include AAV data for the initial authorisation only. The initial authorisation for a recurring payment may be eligible for Chip-UCAF processing. Merchants need not provide UCAF data in recurring payment authorisations for recurring transactions.
Merchants are required to obtain authorisation for each part of a split shipment. Merchants must supply the UCAF with each authorisation request both initial and subsequent. Failure to modify the Control Byte on subsequent authorisations may result in Issuer declining at the time of authorisation. Merchants may need to repeat an Authorisation Request, for example they do not receive a response to the original authorisation request within some time-out period, or they receive other indications of an error in transmission of data to the Acquirer. In such circumstances, the UCAF authentication data should be treated as for an initial authorisation. Existing protocols indicate to Acquirers whether an authorisation request is a repeat submission or a re-submission.
Under some circumstances, a merchant may generate a second authorisation request for a given Chip-UCAF transaction that has the same AAV value as the original transaction.
In the following addresses authorisation requests that are not bit-wise identical to the original request are addressed - for example, the authorisation requests might have different system-trace ID numbers. A merchant might generate second authorisation requests when:
• They wish to re-transmit an authorisation request after an initial decline.
• It fully reverses the original authorisation, but later decides to re-instate it. Merchants should treat such authorisations as subsequent authorisations by modifying the value of the Control Byte. This will prevent them from being erroneously rejected at the AAV verification facility as possible replay attacks.
Merchants should not be concerned with the content of the UCAF data, as this is intended for the Issuer, except under two circumstances;
• Modification of the Control Byte when making subsequent authorisations
• Checking for Interface Application detected errors, notified to the Merchant via certain UCAF contents. When processing subsequent authorisations due to a split shipment, for example, merchants must modify the Control Byte in the UCAF contained in the initial authorisation from the value set by the Cardholder Interface Application by clearing the top bit. This reflects that the UCAF authentication is supplied as part of an authorisation subsequent to the initial authorisation. The Control Byte can be modified by Base64 decoding the UCAF data to get the 24-byte value, changing the value of the first byte and then re-Base64 encoding to create the updated UCAF. Or, simply by changing the first Base64 encoded character by subtracting a constant of 38 from the ASCII character value of the first character to produce a new value for the first character. If the Cardholder IA detects errors in the data supplied by the Merchant either through data format/validation problems, or missing required Ucaf_ hidden fields, or has its own internal problems, the Cardholder IA will attempt to inform the Merchant. Since UCAF is an authentication mechanism and not a payment scheme, Merchants are free to make their own judgement on whether to continue the authorisation process with unsupplied or error indicated UCAF data.
If the Cardholder cancelled the authentication process, the Ucaf_ hidden field called Ucaf Authentication Data will be set to an empty value and thus appears no different to not having a UCAF client.
The merchant server has the ability to detect the presence of UCAF data in a record submitted on their UCAF Authentication Page or UCAF Transfer Page. If UCAF authentication data is present the merchant must submit it unaltered to the acquirer for transmission of initial authorisations. The merchant only modifies the value of the Control Byte for subsequent authorisations. The merchant also flags the transaction as UCAF-enabled so that the acquirer is able to populate the security level indicator with the appropriate value.
If no UCAF authentication data has been supplied, the merchant must indicate this to his/her Acquirer so that they are able to populate the security level indicator with the appropriate value. On the link between Merchant and Acquirer some of the data content can be protected against modification en-route through the use of applying a MAC, and in such a case the UCAF data can also be included as input to the MAC.
Cardholder Interface Application Functional Requirements
The Personal Card-reader Interface Application (Cardholder IA) is the component of software that acts as the interface between the Merchant, the Cardholder and through the Cardholder the Personal Card-Reader (PCR). The standard Cardholder IA plays no part in the payment instrument decision process, although vendors are free to add support for greater functionality that might indeed include support for the
Cardholder in selecting the appropriate payment card. The Cardholder IA must, once invoked, perform the following actions;
• Retrieve data from Channel.
• Determine if the PAN being used for the transaction is a PAN known to it. • Validate the Merchant Transaction Data.
• Display the transaction details to the Cardholder.
• Ensure that the selected PAN and any name by which that card is known to the IA is clearly displayed to remind the Cardholder of the physical ICC they need to use to perform the Authentication. • Compute and display the PCR Challenge.
• Ensure that instructions are displayed or available so that the Cardholder is aware of the actions they need to take, including entering their PIN on the Personal Card- reader.
• Wait for the Token to be entered by the Cardholder as an indication of the Cardholder's approval.
• Populate the AAV in the UCAF, and Base64 encode the resultant UCAF data.
• Populate the Channel with the required UCAF data field.
• Instruct the Cardholder to submit the data to the Merchant, or if processing a single-click purchase, in the PC Browser Channel, 'fire' the submit button's click- event.
• Finally perform any optional logging.
The Cardholder IA should be automatically activated when the appropriate point in the Merchant ordering process has been reached. The Cardholder IA is able to receive the data from the Merchant, through the delivery channel supported by that Cardholder IA and specified in the appropriate channel specification. The Cardholder IA validates the Merchant input data, and only proceeds with transaction data that is valid. The Cardholder IA also obtains certain input data from the cardholder relating to the payment card that will be used for the transaction. The Cardholder I A displays information to the Cardholder about the transaction, which must include the amount of the transaction in a representation that includes the currency letters, e.g. EUR, USD, etc. with the correct amount formatting. The PCR Challenge is displayed to the Cardholder with a clear instruction that this must be entered into the PCR. It also clearly indicates that the Cardholder will be required to enter their PIN into the PCR and that the resultant PCR Token should be entered into the Cardholder IA.
The Cardholder I A generates, or causes to be generated, the PCR Challenge and, on receiving the PCR Token, the IA populates the AAV and Base64 encodes the UCAF.
The Cardholder IA is able to send UCAF data to the Merchant server, through the delivery channel supported by that Cardholder IA and specified in the appropriate channel specification.
The Cardholder I A may also provide additional "ease of use" facilities such as field auto-fill functionality for payment details, PAN, Expiry Date and additional customer details such as address. It is quite possible that the Cardholder will register more than one payment card with the Cardholder IA, and so the Cardholder IA would then have to offer the Cardholder a choice in any form filling for which card was being used for a particular payment. The details for these requirements are out of the scope of this document. The IA may support ECML (E-Commerce Modelling Language) form filling and "best guess" field name auto filling.
The Merchant has to supply the last 5 digits of the payment card number in the Ucaf_Payment_Card_Number field on any page on which it is looking for some interaction with a UCAF Cardholder I A which might be installed on the Cardholder's PC. Cardholder IAs must only activate to authenticate a card that it already has prior knowledge of, i.e. the last 5 digits supplied by the Merchant match the last 5 digits of one of the cards registered with that Cardholder IA.
When enabled to run, the Cardholder IA integrates into or otherwise attaches itself to the Internet browser process in such a way, as it is able to determine the field names of fields within forms on any given web page, as pages are loaded and display in the browser.
When any of the defined UCAF form fields are recognised, the application must then start the UCAF processing and extract the necessary data from those fields in order to continue with the authentication process.
The Cardholder IA activation flow is shown in Fig. 22. The Personal Card-Reader (PCR) is a component in the Chip-UCAF scheme. Fig. 23 is a conceptual diagram of PCR processing flow. 1. Processing begins when the cardholder inserts an ICC 5 into a connected or an unconnected device. In the following an unconnected device will be assumed.
2. The PCR looks for the ICC 5 and relevant programs on the card and confirms the card to the Cardholder by displaying the application label for a brief time;
3. The Personal Card-reader reads the Issuer Internet Proprietary Bitmap (IIPB) from the ICC 5. If the length of the IIPB is wrong or if the number of bits to be transferred, indicated by the IIPB, is too high for the particular Personal Card-reader, the Personal Card-reader displays the message: Fatal Error.
4. The Personal Card-reader prompts the cardholder to enter the challenge. The Challenge includes data which will be used for the Unpredictable Number (UN), the transaction currency code (optional) and a trailing check digit.
5. The cardholder enters the 12-digit number displayed in a prompt on their main access device and the PCR checks for errors. The Personal Card-reader determines that the check-digit is correct and informs the cardholder if the challenge is valid or invalid. If invalid, the PCR again requests the challenge. 6. The Personal Card-reader prompts the cardholder to enter the amount of the transaction. If the authentication transaction did not make use of the transaction amount, this step would be completely skipped. Since the Challenge included the transaction currency code, the display incoφorates the 3-letter currency symbol at the end of the display line, as a visual confirmation to the Cardholder of the currency.
7. The cardholder enters the amount displayed, in a prompt on their main access device.
8. The Cardholder must now enter their PIN and so the Personal Card-reader displays a prompt for the cardholder to enter their PIN.
9. The Cardholder enters their PIN digits and hits "enter".
10. The Personal Card-reader submits the PIN to the ICC. If the ICC reports back an invalid PIN entry, the Personal Card-reader informs the Cardholder of the number of attempts remaining other wise it reports a valid PIN.
11. The device prepares a GenerateAC command using the transaction data as the Unpredictable Number and the amount and the currency code, all as entered by the cardholder. The command is sent to the ICC. If the authentication transaction did not make use of the transaction amount, default but valid values for the amount (0) and currency code (999) are used.
12. The ICC replies and the PCR uses the IIPB read from the card to determine the bits from the response to the GenerateAC which must be stripped and compressed into a token. If no IIPB is found on the ICC, the default IIPB value stored in the reader is used. If the length of the IIPB is wrong, the Personal Card-reader displays the message: Fatal Error.
13. The device then computes and displays an n-digit (+ 1 check-digit) numeric token. The cardholder reads and enters the token into the application on their main device. The application on the main access device verifies the check digit and informs the cardholder if the token contains an error and requests the token to be re-entered. If the cardholder correctly keys in the token the online-transaction process continues.
The above scheme requires certain data structures. The Issuer Internet Proprietary Data (IIPD) is an optional 0-byte to 32-byte general puφose structure containing binary data with the following structure; • Byte 1 - IAF.
• Bytes 2 to 31 - Additional Issuer specific content.
The first byte of the IIPD is an Internet Authentication Flags (IAF) byte. Each bit communicates actions or options from the Issuer that the PCR must take/use. The flag settings indicate whether the amount and currency must be explicitly used in the AC generation and whether an AAC or an ARQC should be requested from the ICC. If the ICC 5 has no IIPD, then a default byte value of 0x40 is used for the IAF.
Any data following after the IAF is for the proprietary use by the Issuer. The Internet Issuer Proprietary Data (IIPD) allows an Issuer to specify proprietary data, generally card specific static data, to be transferred to the Issuer's authentication verification system to assist in the verification of the authentication token. It serves as a general -puφose object to hold Issuer proprietary data for the Internet authentication environment. The data to be conveyed within the IIPD is basically any card static data that is required by the Issuer Host system that will be verifying the Application Cryptogram, but is for one reason or another not able to be or is complicated to obtain from the card database. Examples might include the key derivation index and/or the cryptogram version number. Cards may use a 1 digit Card Sequence Number (CSN). As the UCAF specifications make no provision for this field, the IIPD can be used to transfer the CSN. It will be carried to the Issuer by placing it in the IIPD, needing 4 bits to represent it. The positioning and format of the CSN is Issuer dependent.
The Cardholder must supply the IIPD, if there is one, directly to the Cardholder IA. This means an Issuer must communicate any card's specific IIPD to the
Cardholder so that they may supply this data to the Cardholder IA as required. For reasons of interoperability, rather than supply the data in the more concise hexadecimal form, the Issuer will have to supply the IIPD, a variable whole number of bytes, in a decimal triplet form, i.e. each byte's value will be entered as a decimal value, separated from the next byte value by a dash or a space. Leading zero padding will be used to ensure the IIPD is presented as triplets. This requirement is necessary so that MCDs that have no dash or space key will be able to recognise each triplet.
Although the PCR only uses the first byte of the IIPD as the Internet Authentication Flags (IAF) byte, the full IIPD should still be personalised into the ICC. This is so that connected readers that are able to extract data from the ICC will be able to retrieve the IIPD, and thus not require the Cardholder to enter the IIPD manually.
A further data structure is the Issuer Internet Proprietary Bitmap. The Issuer Internet Proprietary Bitmap (IIPB) is an optional 11 -byte to 43-byte structure containing binary data. The bitmap is a mask on the concatenated values of the data items CID, ATC, AC and IAD. It is not necessarily a straight mask on the response data, since both a first untagged and a second tagged GenerateAC response can be handled by the PCR. The second response data includes the tag and lengths as well as the values of, CID, ATC, AC and IAD. If the ICC 5 has no IIPB, then a default byte value of a 19-byte structure is used. After using the IIPB to determine the bits to be transferred in the IIPB Data Token, an unconnected PCR must build the PCR Token for display to the Cardholder. Because of the limited data transfer available via not only the AAV data space within the UCAF, but more importantly from the unconnected Personal Card-Reader (PCR), it is the IIPB that defines which bits of information are passed to the Issuer in order to verify the authentication cryptogram. The IIPB is therefore the definition of the Issuer's verification data requirements. The IIPB is a mask of those bits that are required from;
• Cryptogram Information Data (CID)
• Application Transaction Counter (ATC)
• Application Cryptogram (AC)
• Issuer Application Data (IAD)
The only information required from the CID is whether the AC generated by the card was an ARQC or an AAC. Since the card will generate either an ARQC or an AAC, there is no need to send both cryptogram indicator bits, only the topmost of the two indicator bits being required. The remainder of the CID is set as indicated below and so not sent.
The ATC is a 16-bit counter which increments after each transaction. The value of the ATC is included in the cryptogram and provides a uniqueness to the cryptogram. Due to the incrementing nature of the ATC it is possible to reduce the number of bits of the ATC which are transmitted quite substantially. The cryptogram (AC) that is requested to be computed by the ICC for this scheme is an Application Request Cryptogram (ARQC), however some card implementations may opt, or be required by their Issuer, to generate an Application Authentication Cryptogram (AAC) instead. In both cases the AC is an 8-byte Message Authentication Code (MAC), computed over data passed to or otherwise known to the ICC. Only 2 bytes of the 8-byte AC are transferred in the PCR Token and the Issuer Host processing must take this into account when comparing the received AC with the AC generated by reconstitution. Which 2 bytes are selected is of course determined by the IIPB. The default IIPB is set to take the first 2 bytes. The Issuer Application Data (IAD) contains fields with a combination of assumed static values, transaction specific values and issuer known values including the Key Derivation Index and the Cryptogram Version Number which are static values stored in the card and which the Issuer is able to retrieve from the ICC database based on the PAN and Expiry Date and so do not need to be transferred. Also included is the Dynamic Authentication Cryptogram (DAC) which is a constant and this does not need to be transferred. Also included are Card Verification Results (CVR) which is a 4-byte field of which Byte-1 is the length of the CVR and is a fixed known constant. Bytes 2, 3 and 4 contain a mixture of assumed and required transaction or card specific bit values. These bits provide valuable information as to whether offline PIN verification was successful, PIN retry number exceeded, previous transaction failures.
Fig. 24 shows the steps involved in a standard transaction and will be described below:
1. Card Activation: The Card must be inserted in the card reader when making the transaction.
2. Application Selection: The application selection process is the process by which the terminal uses data in the ICC to determine the ICC application to be used to produce an authentication cryptogram. The process consists of two steps: • Create a list of ICC applications that are supported by the terminal. Select the application to be run from the list generated above.
3. Initiate Application Processing: The terminal initiates transaction processing. 4.Read Application Data: The terminal reads the data indicated by the AFL.
5. Offline Card Authentication: Data and Card authentication is performed by the terminal to confirm the legitimacy of critical ICC-resident data and to authenticate the ICC. The Personal Card-reader, as used for the Chip-UCAF Authentication service, can be considered an online-only terminal, the terminal application therefore does not need to perform offline Card Authentication as indicated in the settings of the Application Interchange Profile. This means the terminal does not need to verify the card inserted in the terminal is genuine, this can be left to the Card Issuer when validating the cryptogram.
6. Process Restrictions: The puφose of the processing restrictions function is to determine the degree of compatibility of the application in the terminal with the application in the ICC and to make any necessary adjustments, including possible rejection of the transaction.
The terminal application does not need to perform these tests as irrespective of the outcome the terminal will request an ARQC (but also accept an AAC if the ICC 'declined' the request) or an AAC.
7. Cardholder Verification: The Chip-UCAF Authentication Scheme requires a valid PIN (Personal Identification Number) to authenticate the Cardholder.
8. Terminal Risk Management: Terminal risk management is that portion of risk management performed by the terminal to protect the acquirer, issuer, and system from fraud. Since the Card Issuer will process the transaction online anyway, Terminal Risk Management is optional.
9. Terminal Action Analysis: Once terminal risk management and application functions related to a normal offline transaction have been completed, the terminal makes the first decision as to whether the transaction should be approved offline, declined offline, or transmitted online.
10. First Action Analysis: An ICC may perform its own risk management to protect the issuer from fraud or excessive credit risk. As a result of the risk management process, an ICC may decide to complete a transaction online or offline or request a referral or reject the transaction. The terminal will ask the card to generate an Application Cryptogram, either an ARQC or an AAC. Bit 7 of the Internet
Authentication Flags (IAF) indicates whether to ask for an ARQC (set to 0) or an AAC (set to 1). If the ICC is asked to generate an ARQC, PI of the APDU is set to 0x80. If the ICC is asked to generate an AAC, PI of the APDU is set to 0x0. With the request the terminal must include specific data; e.g.:
Amount, Authorised. Terminal Country Code. Terminal Verification Results. Transaction Currency Code. Transaction Date. Transaction Type. Unpredictable Number. Terminal Type. • Data Authentication Code.
The terminal builds the data string to be included with the GENERATE AC command. The ICC will generate an application cryptogram (AC) over the data items and other data items held by the card. The response of the terminal to the GENERATE AC command includes the AC and the other data held by the card that was included in the cryptogram generation;
• Cryptogram Information Data (CID)
• Application Transaction Counter (ATC) • Optional Issuer Application Data (IAD)
Other data elements may be returned as well but may be ignored by the terminal application.
11. Terminal Online Processing: Online processing is normally performed to ensure that the issuer can review and authorise or reject transactions that are outside acceptable limits of risk defined by the issuer, the payment system, or the acquirer. For Personal Card reader terminal applications, the equivalent to the online processing stage prepares the data token, displayed to the cardholder, from the GENERATE AC response data. However, this in fact does not occur until the transaction with the ICC has been completed and is described below. The terminal does not need to perform any Online Processing.
12. Issuer to Card Script Processing: an issuer may provide command scripts to be delivered to the ICC by the terminal to perform functions that are not necessarily relevant to the current transaction but are important for the continued functioning of the application in the ICC. The Personal Card-reader does not have the capability to provide command scripts and so the terminal does not perform this step.
13. Transaction Completion: The completion function closes processing of a transaction. The terminal always performs this function unless the transaction is terminated prematurely by error processing. Some card implementations may, according to their internal risk management, generate an AAC rather than an ARQC. Bit 8 of the CID will determine whether the card generated an AAC or an ARQC. If bit 8 is 0, the card generated an AAC. If bit 8 is 1, the card generated an ARQC. If the ICC returned an AAC with the first GENERATE AC, then the transaction was 'declined offline' and no further processing is required. If the ICC returned an ARQC with the first Generate AC command, then the terminal should request the card to generate an AAC. With this request the terminal must include specific data, e.g. from the following data list:
Amount, Authorised.
Terminal Country Code.
Terminal Verification Results.
Transaction Currency Code.
Transaction Date.
Transaction Type. • Unpredictable Number.
Terminal Type.
Data Authentication Code.
The terminal builds the data string to be included with the Generate AC command. The ICC will generate an application cryptogram (AC) over the data items in the CDOL2. The transaction state within the ICC is now, closed and the card may now be powered off.
14. Token Generation: When a successful transaction has been closed with the card, the terminal must generate the token to be presented to the cardholder. The token is generated from the response to the first, or only, GENERATE AC according to the IIPB value. The token must only be displayed to the cardholder if the card is physically present in the terminal. This means that even if the card remains in the reader throughout the period of interaction between the PCR and the ICC, if it is removed whilst the token is being displayed, the terminal must clear its display and switch itself off. In the above scheme, any errors, indicated in return codes from the ICC, by Cardholder action, or detection of errors by the terminal, must result in the processing of the transaction being stopped and an appropriate error message being displayed before the PCR itself is switched off. The PCR must not generate and display a token in such circumstances.

Claims

1. A network payment system for transacting a sale of merchandise over a network using an Integrated Circuit Card for authentication, said network payment system comprising: a merchant server in communication with said network, said merchant server having at least a first item of merchandise for sale; a client terminal in communication with said network, said client terminal having an output device for reviewing said first item for sale, and an input device for initiating a purchase transaction to purchase said first item for sale, said client terminal being arranged to build a purchase message using information relating to a merchant identifier and financial transaction information obtained from said merchant server; a card reader for communicating with said Integrated Circuit Card, a transaction approvals server for approving financial transactions, said client terminal having means to generate a challenge message, said challenge message being generated from the information relating to the merchant identifier and an account number, means for receiving the challenge message at the card reader and for generating a value from the challenge message; said Integrated Circuit Card having means for generating a cryptographic message from at least a part of said value, the card reader having means to generate an authentication token from at least a part of the cryptographic message, said client terminal having means for transmitting at least part of the authentication token in a message for transmission via the network to said approvals server.
2. The system according to claim 1, wherein said means to generate a challenge message is adapted to generate the challenge message from the information relating to the merchant identifier, an account number and at least one of a purchase amount and a purchase currency.
3. The system according to claim 1 or 2, wherein the means for transmitting at least part of said authentication token is adapted to transmit the at least part of said authentication token to the merchant server and the merchant server is adapted to transmit the at least part of said authentication token to the transaction approvals server with purchase information in an authorization request message.
4. The system according to claim 2 or 3, wherein the means to generate a challenge message is adapted to concatenate the merchant identifier and the account number and optionally at least one of a purchase amount and a purchase currency.
5. The system according to any previous claims, wherein the means to generate a challenge message is adapted to compress the concatenation of the merchant identifier, and the account number and optionally at least one of a purchase amount and a purchase currency.
6. The system according to claim 5, wherein the compression is a hash function.
7. The system according to any of claims 3 to 6, wherein the approvals server rebuilds at least part of the authentication token and compares the rebuilt message with the at least part of the authentication token in the authorization request message transmitted from the merchant server.
8. The system according to claim 7, wherein the transaction approvals server is adapted to send an authentication approval message to the merchant server if the comparison is positive.
9. The system according to any previous claim, wherein the Integrated Circuit card has a memory and a first data object stored in said memory and the means for generating an authentication token from at least a part of the cryptographic message is adapted to select a part of the part of the cryptographic message in accordance with the first data object.
10. The system according to any of claims 4 to 9, wherein the Integrated Circuit card has a memory and a second data object stored in said memory and the means to generate a challenge message includes at least one of a purchase amount and a purchase currency in the generation of the challenge message in accordance with the second data object.
11. A method for authentication for transacting a sale of merchandise over a network using an Integrated Circuit Card, the method comprising: establishing a communication between a merchant server with a client terminal over said network, said merchant server having at least a first item of merchandise for sale; reviewing said first item for sale on said client terminal, initiating a purchase transaction to purchase said first item for sale and building a purchase message using information relating to a merchant identifier and financial transaction information obtained from said merchant server; generating a challenge message on the client terminal the information relating to the merchant identifier and an account number, receiving the challenge message at a card reader and for generating a value from the challenge message; establishing a communication between the Integrated Circuit card and the card reader and generating a cryptographic message from at least a part of said value, generating an authentication token on the card reader from at least a part of the cryptographic message, transmitting at least part of the authentication token in a message from the client terminal for transmission via the network to an approvals server.
12. The method according to claim 11, wherein generating a challenge message includes generating the challenge message from the information relating to the merchant identifier, an account number and at least one of a purchase amount and a purchase currency.
13. The method according to claim 11 or 12, wherein transmitting at least part of said authentication token includes transmitting the at least part of said authentication token to the merchant server and transmitting the at least part of said authentication token from the merchant server to the transaction approvals server with purchase information in an authorization request message.
14. The method according to claim 12 or 13, wherein generating a challenge message comprises concatenating the merchant identifier and the account number and optionally at least one of a purchase amount and a purchase currency.
15. The method according to any of the claims 11 to 14, wherein generating a challenge message comprises compressing the concatenation of the merchant identifier, and the account number and optionally at least one of a purchase amount and a purchase currency.
16. The method according to claim 15, wherein compressing includes applying a hash function.
17. The method according to any of claims 13 to 16, rebuilding at least part of the authentication token at the approvals server and comparing the rebuilt message with the at least part of the authentication token in the authorization request message transmitted from the merchant server.
18. The method according to claim 17, further comprising sending an authentication approval message to the merchant server if the comparison is positive.
19. The method according to any of claims 11 to 18, wherein the Integrated Circuit card has a memory and a first data object stored in said memory, further comprising generating an authentication token from at least a part of the cryptographic message by selecting a part of the part of the cryptographic message in accordance with the first data object.
20. The method according to any of claims 14 to 19, wherein the Integrated Circuit card has a memory and a second data object stored in said memory, further comprising generating a challenge message from at least one of a purchase amount and a purchase currency in accordance with the second data object.
21. An authentication system for use with a network payment system for transacting a sale of merchandise over a network using an Integrated Circuit Card for authentication, said authentication system comprising: a merchant server in communication with said network, said merchant server having at least a first item of merchandise for sale; a client terminal in communication with said network, said client terminal having an output device for reviewing said first item for sale, and an input device for initiating a purchase transaction to purchase said first item for sale, said client terminal being arranged to build a purchase message using information relating to a merchant identifier and financial transaction information obtained from said merchant server; a card reader for communicating with said Integrated Circuit Card, said client terminal having means to generate a challenge message, said challenge message being generated from the information relating to the merchant identifier and an account number, means for receiving the challenge message at the card reader and for generating a value from the challenge message; said Integrated Circuit Card having means for generating a cryptogram from at least a part of said value, the card reader having means to generate an authentication token from at least a part of the cryptogram, said client terminal having means for transmitting at least part of the authentication token in a message for transmission via the network towards said merchant server.
22. The system according to claim 21, wherein said means to generate a challenge message is adapted to generate the challenge message from the information relating to the merchant identifier, an account number and at least one of a purchase amount and a purchase currency.
23. The system according to claim 21 or 22, wherein the means to generate a challenge message is adapted to concatenate the merchant identifier and the account number and optionally at least one of a purchase amount and a purchase currency.
24. The system according to any of the claims 21 to 23, wherein the means to generate a challenge message is adapted to compress the concatenation of the merchant identifier, and the account number and optionally at least one of a purchase amount and a purchase currency.
25. The system according to claim 24, wherein the compression is a hash function.
26. The system according to any of the claims 21 to 25, wherein the Integrated Circuit card has a memory and a first data object stored in said memory and the means for generating an authentication token from at least a part of the cryptogram is adapted to select a part of the part of the cryptogram in accordance with the first data object.
27. The system according to any of claims 21 to 26, wherein the Integrated Circuit card has a memory and a second data object stored in said memory and the means to generate a challenge message includes at least one of a purchase amount and a purchase currency in the generation of the challenge message in accordance with the second data object.
28. A method for authentication for transacting a sale of merchandise over a network using an Integrated Circuit Card, the method comprising: establishing a communication between a merchant server with a client terminal over said network, said merchant server having at least a first item of merchandise for sale; reviewing said first item for sale on said client terminal, initiating a purchase transaction to purchase said first item for sale and building a purchase message using information relating to a merchant identifier and financial transaction information obtained from said merchant server; generating a challenge message on the client terminal the information relating to the merchant identifier and an account number, receiving the challenge message at a card reader and for generating a value from the challenge message; establishing a communication between the Integrated Circuit card and the card reader and generating a cryptogram from at least a part of said value, generating an authentication token on the card reader from at least a part of the cryptogram, transmitting at least part of the authentication token in a message from the client terminal for transmission via the network to the merchant server.
29. The method according to claim 28, wherein generating a challenge message includes generating the challenge message from the information relating to the merchant identifier, an account number and at least one of a purchase amount and a purchase currency.
30. The method according to claim 28 or 29, wherein generating a challenge message comprises concatenating the merchant identifier and the account number and optionally at least one of a purchase amount and a purchase currency.
31. The method according to any of the claims 28 to 30, wherein generating a challenge message comprises compressing the concatenation of the merchant identifier, and the account number and optionally at least one of a purchase amount and a purchase currency.
32. The method according to claim 31 , wherein compressing includes applying a hash function.
33. The method according to any of claims 28 to 32, wherein the Integrated Circuit card has a memory and a first data object stored in said memory, further comprising generating an authentication token from at least a part of the cryptogram by selecting a part of the part of the cryptogram in accordance with the first data object.
34. The method according to any of claims 28 to 33, wherein the Integrated Circuit card has a memory and a second data object stored in said memory, further comprising generating a challenge message from at least one of a purchase amount and a purchase currency in accordance with the second data object.
35. An authentication system for use with a network payment system for transacting a sale of merchandise over a network, said authentication system comprising: a merchant server in communication with said network, said merchant server having at least a first item of merchandise for sale; a client terminal in communication with said network, said client terminal having an output device for reviewing said first item for sale, and an input device for initiating a purchase transaction to purchase said first item for sale, said client terminal being arranged to build a purchase message using information relating to a merchant identifier and financial transaction information obtained from said merchant server; a hand held device, said client terminal having means to generate a challenge message, said challenge message being generated from the information relating to the merchant identifier and an account number, means for receiving the challenge message at the hand held device and for generating a value from the challenge message, the hand held device having means for generating a cryptogram from at least a part of said value; the hand held device having means to generate an authentication token from at least a part of the cryptogram, said client terminal having means for transmitting at least part of the authentication token in a message for transmission via the network towards said merchant server.
36. A method for authentication for transacting a sale of merchandise over a network using a hand held device, the method comprising: establishing a communication between a merchant server with a client terminal over said network, said merchant server having at least a first item of merchandise for sale; reviewing said first item for sale on said client terminal, initiating a purchase transaction to purchase said first item for sale and building a purchase message using information relating to a merchant identifier and financial transaction information obtained from said merchant server; generating a challenge message on the client terminal the information relating to the merchant identifier and an account number, receiving the challenge message at hand held device and for generating a value from the challenge message, generating a cryptogram in the hand held device from at least a part of said value; generating an authentication token on the hand held device from at least a part of the cryptogram, transmitting at least part of the authentication token in a message from the client terminal for transmission via the network to the merchant server.
PCT/BE2003/000036 2002-02-28 2003-02-28 Authentication arrangement and method for use with financial transactions WO2003073389A2 (en)

Priority Applications (9)

Application Number Priority Date Filing Date Title
US10/506,016 US10395462B2 (en) 2002-02-28 2003-02-28 Authentication arrangement and method for use with financial transactions
DE60317169T DE60317169T2 (en) 2002-02-28 2003-02-28 AUTHENTICATION ARRANGEMENT AND METHOD FOR USE WITH FINANCIAL TRANSACTIONS
KR10-2004-7013441A KR20040089682A (en) 2002-02-28 2003-02-28 Authentication arrangement and method for use with financial transactions
AU2003209860A AU2003209860A1 (en) 2002-02-28 2003-02-28 Authentication arrangement and method for use with financial transactions
JP2003572002A JP4597529B2 (en) 2002-02-28 2003-02-28 Authentication mechanisms and methods for use in financial transactions
EP03742900A EP1479052B1 (en) 2002-02-28 2003-02-28 Authentication arrangement and method for use with financial transactions
MXPA04008410A MXPA04008410A (en) 2002-02-28 2003-02-28 Authentication arrangement and method for use with financial transactions.
BR0308111-7A BR0308111A (en) 2002-02-28 2003-02-28 Authentication Arrangement and Method for Use with Financial Transactions
US12/584,704 US8909557B2 (en) 2002-02-28 2009-09-09 Authentication arrangement and method for use with financial transaction

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0204620.9 2002-02-28
GBGB0204620.9A GB0204620D0 (en) 2002-02-28 2002-02-28 Chip authentication programme

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US10/506,016 A-371-Of-International US10395462B2 (en) 2002-02-28 2003-02-28 Authentication arrangement and method for use with financial transactions
US12/584,704 Continuation-In-Part US8909557B2 (en) 2002-02-28 2009-09-09 Authentication arrangement and method for use with financial transaction

Publications (2)

Publication Number Publication Date
WO2003073389A2 true WO2003073389A2 (en) 2003-09-04
WO2003073389A3 WO2003073389A3 (en) 2003-12-18

Family

ID=9931909

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/BE2003/000036 WO2003073389A2 (en) 2002-02-28 2003-02-28 Authentication arrangement and method for use with financial transactions

Country Status (12)

Country Link
US (1) US10395462B2 (en)
EP (4) EP1479052B1 (en)
JP (1) JP4597529B2 (en)
KR (1) KR20040089682A (en)
AT (2) ATE377226T1 (en)
AU (1) AU2003209860A1 (en)
BR (1) BR0308111A (en)
DE (2) DE60317169T2 (en)
GB (1) GB0204620D0 (en)
MX (1) MXPA04008410A (en)
WO (1) WO2003073389A2 (en)
ZA (1) ZA200406805B (en)

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006040250A1 (en) * 2004-10-13 2006-04-20 Deutscher Sparkassenverlag Gmbh System and method for checking access authorisation
EP1789903A2 (en) * 2004-07-15 2007-05-30 Mastercard International, Inc. Method and system using a bitmap for passing contactless payment card transaction variables in standardized data formats
EP1828971A2 (en) * 2004-07-23 2007-09-05 American Express Travel Related Services Company, Inc. Methods and apparatus for a secure promixity integrated circuit card transactions
EP1934935A2 (en) * 2005-09-28 2008-06-25 Visa International Service Association Device, system and method for reducing an interaction time for a contactless transaction
EP1978479A1 (en) * 2007-04-06 2008-10-08 Groupement Des Cartes Bancaires "Cb" Dynamic cryptogram
US7958030B2 (en) 2004-09-01 2011-06-07 Visa U.S.A. Inc. System and method for issuer originated payments for on-line banking bill payments
EP2439705A1 (en) * 2009-06-02 2012-04-11 Micro Códigos, S. L. System for communicating with smart cards provided with storage and/or processing functions and card reader for said system
US8249957B2 (en) 2008-01-15 2012-08-21 Visa U.S.A. System and method for data completion including push identifier
US8439271B2 (en) 2004-07-15 2013-05-14 Mastercard International Incorporated Method and system using a bitmap for passing contactless payment card transaction variables in standardized data formats
US8448875B2 (en) 2008-12-01 2013-05-28 Research In Motion Limited Secure use of externally stored data
EP2581851A3 (en) * 2008-12-01 2013-06-26 Research In Motion Limited Secure use of externally stored data
WO2013140196A1 (en) * 2012-03-23 2013-09-26 Jetchev Dimitar A system for electronic payments with privacy enhancement via trusted third parties
CN104054098A (en) * 2012-01-13 2014-09-17 电子湾有限公司 Systems, methods, and computer program products providing payment in cooperation with EMV card readers
AU2010315111B2 (en) * 2009-11-04 2015-03-19 Visa International Service Association Verification of portable consumer devices for 3-D secure services
US9038886B2 (en) 2009-05-15 2015-05-26 Visa International Service Association Verification of portable consumer devices
US9105027B2 (en) 2009-05-15 2015-08-11 Visa International Service Association Verification of portable consumer device for secure services
US10009177B2 (en) 2009-05-15 2018-06-26 Visa International Service Association Integration of verification tokens with mobile communication devices
US10049360B2 (en) 2009-05-15 2018-08-14 Visa International Service Association Secure communication of payment information to merchants using a verification token
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
US10572864B2 (en) 2009-04-28 2020-02-25 Visa International Service Association Verification of portable consumer devices
US10657528B2 (en) 2010-02-24 2020-05-19 Visa International Service Association Integration of payment capability into secure elements of computers
US11501360B2 (en) 2017-03-17 2022-11-15 Team Labs, Inc. System and method of purchase request management using plain text messages

Families Citing this family (144)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100805341B1 (en) * 1999-06-18 2008-02-20 이촤지 코포레이션 Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account
US7889052B2 (en) 2001-07-10 2011-02-15 Xatra Fund Mx, Llc Authorizing payment subsequent to RF transactions
US8543423B2 (en) 2002-07-16 2013-09-24 American Express Travel Related Services Company, Inc. Method and apparatus for enrolling with multiple transaction environments
US8429041B2 (en) 2003-05-09 2013-04-23 American Express Travel Related Services Company, Inc. Systems and methods for managing account information lifecycles
US7627531B2 (en) 2000-03-07 2009-12-01 American Express Travel Related Services Company, Inc. System for facilitating a transaction
US7725427B2 (en) 2001-05-25 2010-05-25 Fred Bishop Recurrent billing maintenance with radio frequency payment devices
US7762457B2 (en) 2001-07-10 2010-07-27 American Express Travel Related Services Company, Inc. System and method for dynamic fob synchronization and personalization
US8548927B2 (en) 2001-07-10 2013-10-01 Xatra Fund Mx, Llc Biometric registration for facilitating an RF transaction
US20040236699A1 (en) 2001-07-10 2004-11-25 American Express Travel Related Services Company, Inc. Method and system for hand geometry recognition biometrics on a fob
US9031880B2 (en) 2001-07-10 2015-05-12 Iii Holdings 1, Llc Systems and methods for non-traditional payment using biometric data
US7925535B2 (en) 2001-07-10 2011-04-12 American Express Travel Related Services Company, Inc. System and method for securing RF transactions using a radio frequency identification device including a random number generator
US7996324B2 (en) * 2001-07-10 2011-08-09 American Express Travel Related Services Company, Inc. Systems and methods for managing multiple accounts on a RF transaction device using secondary identification indicia
US7668750B2 (en) 2001-07-10 2010-02-23 David S Bonalle Securing RF transactions using a transactions counter
US9024719B1 (en) 2001-07-10 2015-05-05 Xatra Fund Mx, Llc RF transaction system and method for storing user personal data
US7735725B1 (en) 2001-07-10 2010-06-15 Fred Bishop Processing an RF transaction using a routing number
US7705732B2 (en) 2001-07-10 2010-04-27 Fred Bishop Authenticating an RF transaction using a transaction counter
US20050160003A1 (en) * 2001-07-10 2005-07-21 American Express Travel Related Services Company, Inc. System and method for incenting rfid transaction device usage at a merchant location
US8001054B1 (en) 2001-07-10 2011-08-16 American Express Travel Related Services Company, Inc. System and method for generating an unpredictable number using a seeded algorithm
US8960535B2 (en) 2001-07-10 2015-02-24 Iii Holdings 1, Llc Method and system for resource management and evaluation
US9454752B2 (en) 2001-07-10 2016-09-27 Chartoleaux Kg Limited Liability Company Reload protocol at a transaction processing entity
US7805378B2 (en) 2001-07-10 2010-09-28 American Express Travel Related Servicex Company, Inc. System and method for encoding information in magnetic stripe format for use in radio frequency identification transactions
US8284025B2 (en) 2001-07-10 2012-10-09 Xatra Fund Mx, Llc Method and system for auditory recognition biometrics on a FOB
US8635131B1 (en) 2001-07-10 2014-01-21 American Express Travel Related Services Company, Inc. System and method for managing a transaction protocol
US7503480B2 (en) 2001-07-10 2009-03-17 American Express Travel Related Services Company, Inc. Method and system for tracking user performance
US7792759B2 (en) * 2002-07-29 2010-09-07 Emv Co. Llc Methods for performing transactions in a wireless environment
US6805287B2 (en) 2002-09-12 2004-10-19 American Express Travel Related Services Company, Inc. System and method for converting a stored value card to a credit card
US7740168B2 (en) 2003-08-18 2010-06-22 Visa U.S.A. Inc. Method and system for generating a dynamic verification value
US7761374B2 (en) 2003-08-18 2010-07-20 Visa International Service Association Method and system for generating a dynamic verification value
US20050177510A1 (en) * 2004-02-09 2005-08-11 Visa International Service Association, A Delaware Corporation Buyer initiated payment
US20050242176A1 (en) * 2004-04-28 2005-11-03 Dexit Inc. RFID-based system and method of conducting financial transactions
US8341088B2 (en) * 2004-06-30 2012-12-25 France Telecom Multipurpose electronic payment method and system
US7318550B2 (en) 2004-07-01 2008-01-15 American Express Travel Related Services Company, Inc. Biometric safeguard method for use with a smartcard
US7506812B2 (en) * 2004-09-07 2009-03-24 Semtek Innovative Solutions Corporation Transparently securing data for transmission on financial networks
US10248951B2 (en) * 2004-12-01 2019-04-02 Metavante Corporation E-coupon settlement and clearing process
US20070288313A1 (en) * 2006-06-09 2007-12-13 Mark Brodson E-Coupon System and Method
US7694341B2 (en) * 2005-06-03 2010-04-06 Apple Inc. Run-time code injection to perform checks
US8762263B2 (en) 2005-09-06 2014-06-24 Visa U.S.A. Inc. System and method for secured account numbers in proximity devices
US8874477B2 (en) * 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US7992203B2 (en) 2006-05-24 2011-08-02 Red Hat, Inc. Methods and systems for secure shared smartcard access
US8332637B2 (en) 2006-06-06 2012-12-11 Red Hat, Inc. Methods and systems for nonce generation in a token
US8180741B2 (en) * 2006-06-06 2012-05-15 Red Hat, Inc. Methods and systems for providing data objects on a token
US8495380B2 (en) 2006-06-06 2013-07-23 Red Hat, Inc. Methods and systems for server-side key generation
US7822209B2 (en) 2006-06-06 2010-10-26 Red Hat, Inc. Methods and systems for key recovery for a token
US8364952B2 (en) * 2006-06-06 2013-01-29 Red Hat, Inc. Methods and system for a key recovery plan
US8098829B2 (en) 2006-06-06 2012-01-17 Red Hat, Inc. Methods and systems for secure key delivery
US8412927B2 (en) 2006-06-07 2013-04-02 Red Hat, Inc. Profile framework for token processing system
US8589695B2 (en) 2006-06-07 2013-11-19 Red Hat, Inc. Methods and systems for entropy collection for server-side key generation
US8099765B2 (en) 2006-06-07 2012-01-17 Red Hat, Inc. Methods and systems for remote password reset using an authentication credential managed by a third party
US9769158B2 (en) * 2006-06-07 2017-09-19 Red Hat, Inc. Guided enrollment and login for token users
US8707024B2 (en) 2006-06-07 2014-04-22 Red Hat, Inc. Methods and systems for managing identity management security domains
US8806219B2 (en) 2006-08-23 2014-08-12 Red Hat, Inc. Time-based function back-off
US9038154B2 (en) 2006-08-31 2015-05-19 Red Hat, Inc. Token Registration
US8356342B2 (en) 2006-08-31 2013-01-15 Red Hat, Inc. Method and system for issuing a kill sequence for a token
US8074265B2 (en) 2006-08-31 2011-12-06 Red Hat, Inc. Methods and systems for verifying a location factor associated with a token
US8977844B2 (en) 2006-08-31 2015-03-10 Red Hat, Inc. Smartcard formation with authentication keys
US8693690B2 (en) 2006-12-04 2014-04-08 Red Hat, Inc. Organizing an extensible table for storing cryptographic objects
US8041030B2 (en) * 2007-01-09 2011-10-18 Mastercard International Incorporated Techniques for evaluating live payment terminals in a payment system
US8813243B2 (en) 2007-02-02 2014-08-19 Red Hat, Inc. Reducing a size of a security-related data object stored on a token
GB2442249B (en) * 2007-02-20 2008-09-10 Cryptomathic As Authentication device and method
US9846866B2 (en) * 2007-02-22 2017-12-19 First Data Corporation Processing of financial transactions using debit networks
US8639940B2 (en) 2007-02-28 2014-01-28 Red Hat, Inc. Methods and systems for assigning roles on a token
US8832453B2 (en) 2007-02-28 2014-09-09 Red Hat, Inc. Token recycling
US9081948B2 (en) 2007-03-13 2015-07-14 Red Hat, Inc. Configurable smartcard
TW200845690A (en) * 2007-05-14 2008-11-16 David Chiu Business protection system in internet
US8121942B2 (en) 2007-06-25 2012-02-21 Visa U.S.A. Inc. Systems and methods for secure and transparent cardless transactions
US20090089211A1 (en) * 2007-10-02 2009-04-02 Patricia Morse System and method for person to person fund transfer
US8214291B2 (en) 2007-10-19 2012-07-03 Ebay Inc. Unified identity verification
US8255688B2 (en) * 2008-01-23 2012-08-28 Mastercard International Incorporated Systems and methods for mutual authentication using one time codes
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US20100005028A1 (en) * 2008-07-07 2010-01-07 International Business Machines Corporation Method and apparatus for interconnecting a plurality of virtual world environments
BRPI0921124A2 (en) 2008-11-06 2016-09-13 Visa Int Service Ass system for authenticating a consumer, computer implemented method, computer readable medium, and server computer.
US20100131397A1 (en) * 2008-11-25 2010-05-27 Patrick Killian Providing "on behalf of" services for mobile telephone access to payment card account
US8838503B2 (en) * 2008-12-08 2014-09-16 Ebay Inc. Unified identity verification
US20100180329A1 (en) * 2009-01-09 2010-07-15 International Business Machines Corporation Authenticated Identity Propagation and Translation within a Multiple Computing Unit Environment
WO2010126994A1 (en) * 2009-04-28 2010-11-04 Mastercard International Incorporated Apparatus, method, and computer program product for recovering torn smart payment device transactions
FR2950768A1 (en) 2009-09-30 2011-04-01 Xiring Sa SYSTEM AND METHOD FOR SECURE ONLINE TRANSACTION
US9240005B2 (en) * 2009-11-06 2016-01-19 Mastercard International, Incorporated Methods for risk management in payment-enabled mobile device
NO2526514T3 (en) * 2010-01-19 2018-08-11
US9245267B2 (en) 2010-03-03 2016-01-26 Visa International Service Association Portable account number for consumer payment account
JP5589471B2 (en) * 2010-03-19 2014-09-17 大日本印刷株式会社 Royalty management system, royalty management method and token
US9189786B2 (en) * 2010-03-31 2015-11-17 Mastercard International Incorporated Systems and methods for operating transaction terminals
US8473414B2 (en) * 2010-04-09 2013-06-25 Visa International Service Association System and method including chip-based device processing for transaction
US9118666B2 (en) 2010-06-30 2015-08-25 Google Inc. Computing device integrity verification
US8700895B1 (en) 2010-06-30 2014-04-15 Google Inc. System and method for operating a computing device in a secure mode
US10217109B2 (en) * 2010-07-09 2019-02-26 Mastercard International Incorporated Apparatus and method for combining cryptograms for card payments
US8746553B2 (en) 2010-09-27 2014-06-10 Mastercard International Incorporated Purchase Payment device updates using an authentication process
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
KR101049072B1 (en) * 2011-02-17 2011-07-15 (주)케이사인 The method of mapping using identification data
US10534931B2 (en) 2011-03-17 2020-01-14 Attachmate Corporation Systems, devices and methods for automatic detection and masking of private data
US8688589B2 (en) 2011-04-15 2014-04-01 Shift4 Corporation Method and system for utilizing authorization factor pools
US9818111B2 (en) 2011-04-15 2017-11-14 Shift4 Corporation Merchant-based token sharing
US9256874B2 (en) 2011-04-15 2016-02-09 Shift4 Corporation Method and system for enabling merchants to share tokens
WO2012162351A1 (en) * 2011-05-23 2012-11-29 Mastercard International, Inc. Combicard transaction method and system having an application parameter update mechanism
US10325265B2 (en) * 2011-05-26 2019-06-18 Facebook, Inc. Methods and systems for facilitating E-commerce payments
US9665854B1 (en) 2011-06-16 2017-05-30 Consumerinfo.Com, Inc. Authentication alerts
US10242368B1 (en) * 2011-10-17 2019-03-26 Capital One Services, Llc System and method for providing software-based contactless payment
US20130103574A1 (en) * 2011-10-19 2013-04-25 First Data Corporation Payment Delegation Transaction Processing
US20130282588A1 (en) * 2012-04-22 2013-10-24 John Hruska Consumer, Merchant and Mobile Device Specific, Real-Time Dynamic Tokenization Activation within a Secure Mobile-Wallet Financial Transaction System
US11250423B2 (en) * 2012-05-04 2022-02-15 Institutional Cash Distributors Technology, Llc Encapsulated security tokens for electronic transactions
US10423952B2 (en) * 2013-05-06 2019-09-24 Institutional Cash Distributors Technology, Llc Encapsulated security tokens for electronic transactions
US10410213B2 (en) * 2012-05-04 2019-09-10 Institutional Cash Distributors Technology, Llc Encapsulated security tokens for electronic transactions
US20140156535A1 (en) * 2012-06-01 2014-06-05 Nameh Jabbour System and method for requesting and processing pin data using a digit subset for subsequent pin authentication
US9667668B2 (en) * 2012-10-17 2017-05-30 Nvidia Corporation Managing SIM indications
US10572873B2 (en) * 2013-02-15 2020-02-25 Mastercard International Incorporated Method and system for the transmission of authenticated authorization requests
US20140279379A1 (en) * 2013-03-14 2014-09-18 Rami Mahdi First party fraud detection system
US9633322B1 (en) 2013-03-15 2017-04-25 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
US10664936B2 (en) 2013-03-15 2020-05-26 Csidentity Corporation Authentication systems and methods for on-demand products
US9721147B1 (en) 2013-05-23 2017-08-01 Consumerinfo.Com, Inc. Digital identity
US20150006382A1 (en) * 2013-06-27 2015-01-01 German Scipioni Systems and methods for implementing money orders
US10489852B2 (en) * 2013-07-02 2019-11-26 Yodlee, Inc. Financial account authentication
EP2838060A1 (en) 2013-08-14 2015-02-18 Facebook, Inc. Methods and systems for facilitating e-commerce payments
US9965606B2 (en) 2014-02-07 2018-05-08 Bank Of America Corporation Determining user authentication based on user/device interaction
US9286450B2 (en) 2014-02-07 2016-03-15 Bank Of America Corporation Self-selected user access based on specific authentication types
US9647999B2 (en) 2014-02-07 2017-05-09 Bank Of America Corporation Authentication level of function bucket based on circumstances
US9390242B2 (en) 2014-02-07 2016-07-12 Bank Of America Corporation Determining user authentication requirements based on the current location of the user being within a predetermined area requiring altered authentication requirements
US9208301B2 (en) 2014-02-07 2015-12-08 Bank Of America Corporation Determining user authentication requirements based on the current location of the user in comparison to the users's normal boundary of location
US9213974B2 (en) 2014-02-07 2015-12-15 Bank Of America Corporation Remote revocation of application access based on non-co-location of a transaction vehicle and a mobile device
US9305149B2 (en) 2014-02-07 2016-04-05 Bank Of America Corporation Sorting mobile banking functions into authentication buckets
US20150254646A1 (en) * 2014-03-04 2015-09-10 Bank Of America Corporation Restoring or reissuing of a token based on user authentication
US9721268B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation Providing offers associated with payment credentials authenticated in a specific digital wallet
US10050787B1 (en) 2014-03-25 2018-08-14 Amazon Technologies, Inc. Authentication objects with attestation
US10049202B1 (en) 2014-03-25 2018-08-14 Amazon Technologies, Inc. Strong authentication using authentication objects
WO2015163771A1 (en) * 2014-04-23 2015-10-29 Julien Truesdale Payment systems
US10373240B1 (en) 2014-04-25 2019-08-06 Csidentity Corporation Systems, methods and computer-program products for eligibility verification
US20150317630A1 (en) * 2014-04-30 2015-11-05 MasterCard Incorporated International Method and system for authentication token generation
US9264419B1 (en) 2014-06-26 2016-02-16 Amazon Technologies, Inc. Two factor authentication with authentication objects
US10891622B2 (en) 2014-11-13 2021-01-12 Mastercard International Incorporated Providing online cardholder authentication services on-behalf-of issuers
SG10201500276VA (en) * 2015-01-14 2016-08-30 Mastercard Asia Pacific Pte Ltd Method and system for making a secure payment transaction
US9881166B2 (en) 2015-04-16 2018-01-30 International Business Machines Corporation Multi-focused fine-grained security framework
SG10201508034PA (en) * 2015-09-28 2017-04-27 Mastercard Asia Pacific Pte Ltd Device For Facilitating Identification Of A Fraudulent Payment Card
GB2542617B (en) * 2015-09-28 2020-06-24 Touchtech Payments Ltd Transaction authentication platform
US9729536B2 (en) 2015-10-30 2017-08-08 Bank Of America Corporation Tiered identification federated authentication network system
US11107071B2 (en) * 2016-02-01 2021-08-31 Apple Inc. Validating online access to secure device functionality
US10861042B2 (en) * 2016-04-19 2020-12-08 Mastercard International Incorporated Method and system for platform attribution using digitized tokens
CN106603636B (en) * 2016-11-29 2020-05-26 中国银联股份有限公司 Error transaction standardization method and device
US11308107B1 (en) * 2017-12-15 2022-04-19 Groupon, Inc. Method, apparatus, and computer program product for network data linking and transmission thereof
AU2018202320A1 (en) * 2018-04-03 2019-10-17 Currency Select Pty Ltd Transaction security
US10911234B2 (en) 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment
US10949520B2 (en) * 2018-10-02 2021-03-16 Capital One Services, Llc Systems and methods for cross coupling risk analytics and one-time-passcodes
US20200118122A1 (en) * 2018-10-15 2020-04-16 Vatbox, Ltd. Techniques for completing missing and obscured transaction data items
US20200167780A1 (en) * 2018-11-28 2020-05-28 Mastercard International Incorporated System and method for linking authentication and authorization processes in payment card-based financial transactions
WO2022250188A1 (en) * 2021-05-28 2022-12-01 주식회사 유스비 Fraud detection system based on low-level data analysis, and method therefor
US20230316275A1 (en) * 2022-04-04 2023-10-05 Capital One Services, Llc Systems and methods for token-based device binding during merchant checkout

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6038551A (en) * 1996-03-11 2000-03-14 Microsoft Corporation System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer
EP1014317A1 (en) * 1998-12-14 2000-06-28 Sagem Sa Secure payment method
US6173400B1 (en) * 1998-07-31 2001-01-09 Sun Microsystems, Inc. Methods and systems for establishing a shared secret using an authentication token
US6247129B1 (en) * 1997-03-12 2001-06-12 Visa International Service Association Secure electronic commerce employing integrated circuit cards
US6282522B1 (en) * 1997-04-30 2001-08-28 Visa International Service Association Internet payment system using smart card
WO2002001520A1 (en) * 2000-06-26 2002-01-03 Covadis S.A. Device for carrying out secure transactions in a communications network
GB2374498A (en) * 2001-04-12 2002-10-16 Intercede Ltd Multi-stage authorisation system

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4736094A (en) * 1984-04-03 1988-04-05 Omron Tateisi Electronics Co. Financial transaction processing system using an integrated circuit card device
US5768390A (en) 1995-10-25 1998-06-16 International Business Machines Corporation Cryptographic system with masking
US6016484A (en) 1996-04-26 2000-01-18 Verifone, Inc. System, method and article of manufacture for network electronic payment instrument and certification of payment and credit collection utilizing a payment
JPH10207962A (en) * 1996-11-19 1998-08-07 Toppan Printing Co Ltd Commodity sales system using network and electronic settlement system
US6868391B1 (en) * 1997-04-15 2005-03-15 Telefonaktiebolaget Lm Ericsson (Publ) Tele/datacommunications payment method and apparatus
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
CA2259089C (en) * 1999-01-15 2013-03-12 Robert J. Lambert Method and apparatus for masking cryptographic operations
US6480935B1 (en) 1999-01-15 2002-11-12 Todd Carper Smart card memory management system and method
US7343351B1 (en) * 1999-08-31 2008-03-11 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions
US6289455B1 (en) * 1999-09-02 2001-09-11 Crypotography Research, Inc. Method and apparatus for preventing piracy of digital content
US7249093B1 (en) * 1999-09-07 2007-07-24 Rysix Holdings, Llc Method of and system for making purchases over a computer network
US6834271B1 (en) * 1999-09-24 2004-12-21 Kryptosima Apparatus for and method of secure ATM debit card and credit card payment transactions via the internet
JP2003519420A (en) * 1999-12-17 2003-06-17 チャンタレイ・コーポレイション・リミテッド Trading system with security
JP2001175737A (en) * 1999-12-20 2001-06-29 Orient Corp System and method for processing credit information and recording medium stored with software for credit information processing
US20010032878A1 (en) * 2000-02-09 2001-10-25 Tsiounis Yiannis S. Method and system for making anonymous electronic payments on the world wide web
JP3801833B2 (en) * 2000-02-14 2006-07-26 株式会社東芝 Microprocessor
JP2001236487A (en) * 2000-02-21 2001-08-31 Ryutsu Kogaku Kenkyusho:Kk Valuable carrier with illegal use preventing function, valuable carrier generating device, and valuable carrier authenticating device
GB0006668D0 (en) 2000-03-21 2000-05-10 Ericsson Telefon Ab L M Encrypting and decrypting
KR100395296B1 (en) * 2000-03-21 2003-08-21 권황섭 Lottery ticket service system for using integrated circuit card and method for it
EP1139200A3 (en) * 2000-03-23 2002-10-16 Tradecard Inc. Access code generating system including smart card and smart card reader
US6856975B1 (en) * 2000-03-30 2005-02-15 Verify & Protect Inc. System, method, and article of manufacture for secure transactions utilizing a computer network
US7177848B2 (en) * 2000-04-11 2007-02-13 Mastercard International Incorporated Method and system for conducting secure payments over a computer network without a pseudo or proxy account number
JP3399442B2 (en) * 2000-05-15 2003-04-21 日本電気株式会社 Electronic commerce system and electronic commerce method
US6931382B2 (en) * 2001-01-24 2005-08-16 Cdck Corporation Payment instrument authorization technique
US7292999B2 (en) * 2001-03-15 2007-11-06 American Express Travel Related Services Company, Inc. Online card present transaction
US7499888B1 (en) * 2001-03-16 2009-03-03 Fusionone, Inc. Transaction authentication system and method
US7225156B2 (en) * 2001-07-11 2007-05-29 Fisher Douglas C Persistent dynamic payment service
US8909557B2 (en) 2002-02-28 2014-12-09 Mastercard International Incorporated Authentication arrangement and method for use with financial transaction
EP1789903A4 (en) 2004-07-15 2011-02-09 Mastercard International Inc Method and system using a bitmap for passing contactless payment card transaction variables in standardized data formats
WO2007038896A2 (en) 2005-10-05 2007-04-12 Privasphere Ag Method and devices for user authentication
GB2442249B (en) 2007-02-20 2008-09-10 Cryptomathic As Authentication device and method
JP2011513869A (en) 2008-03-10 2011-04-28 グローバル ブルー カレンシー チョイス ホールディングス ビー.ヴイ. Dynamic currency conversion system and method
FR2934910B1 (en) 2008-08-05 2013-08-16 Inside Contactless METHOD OF SECURING AN EXECUTED TRANSACTION USING A PROGRAMMABLE PORTABLE DEVICE

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6038551A (en) * 1996-03-11 2000-03-14 Microsoft Corporation System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer
US6247129B1 (en) * 1997-03-12 2001-06-12 Visa International Service Association Secure electronic commerce employing integrated circuit cards
US6282522B1 (en) * 1997-04-30 2001-08-28 Visa International Service Association Internet payment system using smart card
US6173400B1 (en) * 1998-07-31 2001-01-09 Sun Microsystems, Inc. Methods and systems for establishing a shared secret using an authentication token
EP1014317A1 (en) * 1998-12-14 2000-06-28 Sagem Sa Secure payment method
WO2002001520A1 (en) * 2000-06-26 2002-01-03 Covadis S.A. Device for carrying out secure transactions in a communications network
GB2374498A (en) * 2001-04-12 2002-10-16 Intercede Ltd Multi-stage authorisation system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1479052A2 *

Cited By (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1789903A4 (en) * 2004-07-15 2011-02-09 Mastercard International Inc Method and system using a bitmap for passing contactless payment card transaction variables in standardized data formats
EP1789903A2 (en) * 2004-07-15 2007-05-30 Mastercard International, Inc. Method and system using a bitmap for passing contactless payment card transaction variables in standardized data formats
US8439271B2 (en) 2004-07-15 2013-05-14 Mastercard International Incorporated Method and system using a bitmap for passing contactless payment card transaction variables in standardized data formats
EP1828971A4 (en) * 2004-07-23 2011-12-07 American Express Travel Relate Methods and apparatus for a secure promixity integrated circuit card transactions
EP1828971A2 (en) * 2004-07-23 2007-09-05 American Express Travel Related Services Company, Inc. Methods and apparatus for a secure promixity integrated circuit card transactions
AU2005266964B2 (en) * 2004-07-23 2011-02-03 American Express Travel Related Services Co., Inc. Methods and apparatus for a secure promixity integrated circuit card transactions
US7958030B2 (en) 2004-09-01 2011-06-07 Visa U.S.A. Inc. System and method for issuer originated payments for on-line banking bill payments
US8255327B2 (en) 2004-09-01 2012-08-28 Lynn Kemper System and method for issuer originated payments for on-line banking bill payments
WO2006040250A1 (en) * 2004-10-13 2006-04-20 Deutscher Sparkassenverlag Gmbh System and method for checking access authorisation
EP1934935A2 (en) * 2005-09-28 2008-06-25 Visa International Service Association Device, system and method for reducing an interaction time for a contactless transaction
US9330386B2 (en) 2005-09-28 2016-05-03 Visa International Service Association Device, system and method for reducing an interaction time for a contactless transaction
US9613354B2 (en) 2005-09-28 2017-04-04 Visa International Service Association Device, system and method for reducing an interaction time for a contactless transaction
EP1934935A4 (en) * 2005-09-28 2011-03-02 Visa Int Service Ass Device, system and method for reducing an interaction time for a contactless transaction
US10043177B2 (en) 2005-09-28 2018-08-07 Visa International Service Association Device, system and method for reducing an interaction time for a contactless transaction
US8770476B2 (en) 2005-09-28 2014-07-08 Visa International Service Association Device, system and method for reducing an interaction time for a contactless transaction
EP2711889A3 (en) * 2005-09-28 2014-04-30 Visa International Service Association Device, system and method for reducing an interaction time for a contactless transaction
EP1978479A1 (en) * 2007-04-06 2008-10-08 Groupement Des Cartes Bancaires "Cb" Dynamic cryptogram
FR2914763A1 (en) * 2007-04-06 2008-10-10 Grp Des Cartes Bancaires DYNAMIC CRYPTOGRAM
US8249957B2 (en) 2008-01-15 2012-08-21 Visa U.S.A. System and method for data completion including push identifier
EP2581851A3 (en) * 2008-12-01 2013-06-26 Research In Motion Limited Secure use of externally stored data
US8448875B2 (en) 2008-12-01 2013-05-28 Research In Motion Limited Secure use of externally stored data
US10572864B2 (en) 2009-04-28 2020-02-25 Visa International Service Association Verification of portable consumer devices
US10997573B2 (en) 2009-04-28 2021-05-04 Visa International Service Association Verification of portable consumer devices
US9792611B2 (en) 2009-05-15 2017-10-17 Visa International Service Association Secure authentication system and method
US9038886B2 (en) 2009-05-15 2015-05-26 Visa International Service Association Verification of portable consumer devices
US9904919B2 (en) 2009-05-15 2018-02-27 Visa International Service Association Verification of portable consumer devices
US10009177B2 (en) 2009-05-15 2018-06-26 Visa International Service Association Integration of verification tokens with mobile communication devices
US10043186B2 (en) 2009-05-15 2018-08-07 Visa International Service Association Secure authentication system and method
US10049360B2 (en) 2009-05-15 2018-08-14 Visa International Service Association Secure communication of payment information to merchants using a verification token
US9105027B2 (en) 2009-05-15 2015-08-11 Visa International Service Association Verification of portable consumer device for secure services
US10387871B2 (en) 2009-05-15 2019-08-20 Visa International Service Association Integration of verification tokens with mobile communication devices
EP2439705A1 (en) * 2009-06-02 2012-04-11 Micro Códigos, S. L. System for communicating with smart cards provided with storage and/or processing functions and card reader for said system
EP2439705A4 (en) * 2009-06-02 2013-03-13 Micro Codigos S L System for communicating with smart cards provided with storage and/or processing functions and card reader for said system
AU2010315111B2 (en) * 2009-11-04 2015-03-19 Visa International Service Association Verification of portable consumer devices for 3-D secure services
US10657528B2 (en) 2010-02-24 2020-05-19 Visa International Service Association Integration of payment capability into secure elements of computers
CN104054098A (en) * 2012-01-13 2014-09-17 电子湾有限公司 Systems, methods, and computer program products providing payment in cooperation with EMV card readers
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
WO2013140196A1 (en) * 2012-03-23 2013-09-26 Jetchev Dimitar A system for electronic payments with privacy enhancement via trusted third parties
US11501360B2 (en) 2017-03-17 2022-11-15 Team Labs, Inc. System and method of purchase request management using plain text messages

Also Published As

Publication number Publication date
US20050119978A1 (en) 2005-06-02
WO2003073389A3 (en) 2003-12-18
EP1865471A3 (en) 2008-03-05
EP1850297A3 (en) 2008-03-05
JP2005519375A (en) 2005-06-30
ATE377226T1 (en) 2007-11-15
DE60335049D1 (en) 2010-12-30
EP1479052A2 (en) 2004-11-24
EP1850297B1 (en) 2010-11-17
ATE488823T1 (en) 2010-12-15
EP2309465A1 (en) 2011-04-13
US10395462B2 (en) 2019-08-27
JP4597529B2 (en) 2010-12-15
AU2003209860A1 (en) 2003-09-09
DE60317169D1 (en) 2007-12-13
EP2309465B1 (en) 2013-09-04
DE60317169T2 (en) 2008-08-07
EP1865471A2 (en) 2007-12-12
EP1479052B1 (en) 2007-10-31
KR20040089682A (en) 2004-10-21
GB0204620D0 (en) 2002-04-10
EP1850297A2 (en) 2007-10-31
BR0308111A (en) 2005-01-04
ZA200406805B (en) 2005-09-12
MXPA04008410A (en) 2005-05-17

Similar Documents

Publication Publication Date Title
EP1479052B1 (en) Authentication arrangement and method for use with financial transactions
US8909557B2 (en) Authentication arrangement and method for use with financial transaction
US9514458B2 (en) Customer authentication in E-commerce transactions
AU2001257280C1 (en) Online payer authentication service
AU2001257280B2 (en) Online payer authentication service
US20100223186A1 (en) Method and System for Conducting Secure Payments
US20090313168A1 (en) System and Method for Authorizing Financial Transactions with Online Merchants
AU2001257280A1 (en) Online payer authentication service
WO2010030362A1 (en) Authentication arrangement and method for use with financial transaction

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2449/DELNP/2004

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2004/06805

Country of ref document: ZA

Ref document number: 2003209860

Country of ref document: AU

Ref document number: 2003572002

Country of ref document: JP

Ref document number: 200406805

Country of ref document: ZA

Ref document number: 2003742900

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10506016

Country of ref document: US

Ref document number: 1020047013441

Country of ref document: KR

Ref document number: PA/A/2004/008410

Country of ref document: MX

WWP Wipo information: published in national office

Ref document number: 1020047013441

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2003742900

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 2003742900

Country of ref document: EP