KR20040089682A - 금융 거래에서 이용하기 위한 인증 장치 및 방법 - Google Patents

금융 거래에서 이용하기 위한 인증 장치 및 방법 Download PDF

Info

Publication number
KR20040089682A
KR20040089682A KR10-2004-7013441A KR20047013441A KR20040089682A KR 20040089682 A KR20040089682 A KR 20040089682A KR 20047013441 A KR20047013441 A KR 20047013441A KR 20040089682 A KR20040089682 A KR 20040089682A
Authority
KR
South Korea
Prior art keywords
authentication
generating
message
purchase
store
Prior art date
Application number
KR10-2004-7013441A
Other languages
English (en)
Inventor
피크레트 아테스
Original Assignee
마스터카드 유럽 에스피알엘
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 마스터카드 유럽 에스피알엘 filed Critical 마스터카드 유럽 에스피알엘
Publication of KR20040089682A publication Critical patent/KR20040089682A/ko

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms 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/10—Mechanisms 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/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment 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/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment 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/3674—Payment 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms 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/10—Mechanisms 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/1025—Identification of user by a PIN code

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Telephone Function (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)
  • Dicing (AREA)
  • Particle Formation And Scattering Control In Inkjet Printers (AREA)
  • Junction Field-Effect Transistors (AREA)

Abstract

집적 회로 카드를 이용하여 네트워크를 통해 상품의 판매를 거래하기 위한 네트워크 지불 시스템에서 이용되는 인증 장치가 개시되어 있다. 이 장치는, 상기 네트워크와 통신하는 상점 서버 - 상기 상점 서버는 적어도 제1 품목의 판매 상품을 구비하고 있음 - 와; 상기 네트워크와 통신하는 고객 단말기 - 상기 고객 단말기는 상기 제1 판매 품목을 검토하기 위한 출력 디바이스, 및 상기 제1 판매 품목을 구매하기 위해 구매 거래를 개시하기 위한 입력 디바이스를 구비하고, 상기 고객 단말기는 상기 상점 서버로부터 획득된 상점 식별자에 관한 정보 및 금융 거래 정보를 이용하여 구매 메시지를 작성하도록 구성되고, 상기 고객 단말기는 상기 상점 식별자에 관한 정보 및 계좌 번호로부터 생성되는 챌린지 메시지(challenge message)를 생성하기 위한 수단을 구비함- 와; 상기 집적 회로 카드와 통신하기 위한 카드 판독기와; 상기 카드 판독기에서 상기 챌린지 메시지를 수신하고 이 챌린지 메시지로부터 하나의 값을 생성하기 위한 수단을 포함하며, 상기 집적 회로 카드는 상기 값의 적어도 일부로부터 암호 메시지를 생성하기 위한 수단을 구비하고, 상기 카드 판독기는 상기 암호 메시지의 적어도 일부로부터 인증 토큰을 생성하기 위한 수단을 구비하고, 상기 고객 단말기는 상기 네트워크를 통하여 송신용 메시지 내의 상기 인증 토큰의 적어도 일부를 송신하기 위한 수단을 구비한다.

Description

금융 거래에서 이용하기 위한 인증 장치 및 방법{AUTHENTICATION ARRANGEMENT AND METHOD FOR USE WITH FINANCIAL TRANSACTIONS}
개인용 컴퓨터와 같은 사용자 단말기 또는 메인 액세스 디바이스를 이용하여 인터넷 상에서 구매를 하는 것이 공지되어 있다. 인터넷을 통하여 온라인으로 구매된 상품 및/또는 서비스의 지불을 위해 스마트 카드를 이용하는 아키텍처 및 시스템이 미국특허 제6,282,522호에 공지되어 있다. 고객 단말기 상의 고객 서버가 고객과의 상호작용을 제어하고 고객의 스마트 카드를 수용하는 카드 판독기와 인터페이스된다. 인터넷 상의 지불 서버가 그 거래 및 데이터 저장을 취급하는 컴퓨터 및 단말기들을 포함한다. 또한 웹사이트 상에서의 판매를 위해 상점이 제공한 상품 및/또는 서비스를 광고하는 상점 서버 역시 인터넷을 통하여 접속된다. 상점은 인터넷을 통하여 구매된 상품 및/또는 서비스에 대한 스마트 카드 지불을 수용하기로 취득자와 계약한다. 고객이 원격 상점 서버로부터 상품 및/또는 서비스를 구매하기 위하여 고객 단말기에서 그의 스마트 카드를 이용한다. 인터넷은 고객 단말기, 상점 서버 및 지불 서버 간의 경로 배정 기능(routing functionality)을 제공한다.
도 1은 예를 들면 인터넷에 액세스하여 브라우징하기 위한 사용자 단말기 또는 메인 액세스 디바이스(1)를 나타내는 개략 도면이다. 일반적으로, 단말기(1)는 양방향 통신하도록 버스(3)를 통하여 메모리(4) 및 입출력(I/O) 디바이스들(6)과 접속되는 중앙 프로세서 유닛(CPU)(2)을 포함한다. I/O 디바이스들(6)은 데이터를 입력하기 위한 키보드와, 시각 표시 장치, 예를 들면 액정(LCD) 또는 발광 다이오드(LED) 디스플레이, CRT와 같이 거래의 진행을 표시하고 및/또는 메시지 또는 프롬프트를 표시하기 위한 스크린일 수 있다. I/O 디바이스들(6) 중 하나는 카드 판독기(7)일 수 있고, 이 판독기(7)의 수신 슬롯에 집적 회로 카드(ICC)(5)가 삽입되면 ICC(5)가 판독될 수 있다. 또는, 카드 판독기(7)는 ICC(5)를 판독하기 위한 독립형(standalone) 디바이스일 수도 있다. I/O 디바이스들(6) 중 하나는 인터넷 서비스 제공자(ISP)를 통하여 인터넷에 액세스하기 위한 모뎀(9), 예를 들면, 56K, ADSL, 무선 또는 케이블 모뎀일 수도 있다. 단말기의 실제 형태는 다양하게 변할 수 있고, 미국 인텔사가 공급하는 펜티엄(상표명) 계열의 마이크로프로세서와 같은 프로세서를 포함할 수 있다. 또한, 단말기(1)는 한 장소에 모두 위치할 필요가 없고, 카드 판독기(7)와, 키보드 및 디스플레이와 같은 I/O 디바이스들과, 모뎀 및 프로세서와 같은 단말기의 각종 부분들은 서로 다른 위치들에 위치하여 케이블, 무선 송신 등에 의해 접속되거나 또는 근거리 통신망의 일부일 수도 있고 통신 네트워크에 의해 상호 접속될 수도 있다.
도 2는 집적 회로 카드(ICC)(5)를 나타내는 개략 도면이다. ICC(5)는 적어도 입출력(I/O) 포트(10) 및 몇몇 영구 기억 장치를 포함하고, 영구 기억 장치의 예로는 이를테면 버스(17)를 통하여 I/O 포트(10)에 접속된 EEPROM(15)이나 또는 배터리 전원의 랜덤 액세스 메모리(RAM)에 의해 제공될 수 있는 불휘발성 메모리가 있다. I/O 포트(10)는 카드 판독기(7)를 통하여 단말기(1)와 통신하는데 이용될 수 있다. 집적 회로 카드는 적어도 메모리 기능을 수행하기 위해 하나 이상의 집적 회로들이 삽입되어 있는 카드이다. 선택적으로, ICC(5)는 내장형(self-contained) 휴대 지능 카드로서, RAM(14)에 의해 제공된 휘발성 메모리와 같은 판독/기입가능 작업 메모리와 중앙 프로세서(12)는 물론, 카드 ICC(5)가 마이크로프로세서로 동작할 수 있도록 하는데 필요한 모든 회로들, 예를 들면 코드를 저장하기 위한 판독 전용 메모리(13), 순서기(sequencer)(16) 및 전압원 Vss 및 VDD, 프로세서(12)용 리셋 및 순서기(16)에 대한 클록 CLK을 수신하기 위한 카드 판독기(7)와의 접속부들을 포함할 수 있다. ICC(5)는 은행 카드, 신용 카드, 직불 카드, 전자 지갑, 건강 카드, SIM 카드 등으로 이용될 수 있다. 클록, 난수 발생기, 인터럽트 컨트롤, 컨트롤 로직, 충전 펌프, 전원 접속부, 및 카드가 외부 세계와 통신할 수 있게 하는 인터페이스 콘택트와 같은, 마이크로프로세서의 다른 특징들이 있지만 도시되어 있지 않다. 예를 들면, 암호화 모듈(도시되지 않음)은 각종 암호화 알고리즘을 수행하는데 이용되는 선택적 하드웨어 모듈이다.
전자 상거래(e-commerce) 상점들은 보통 웹 페이지를 통하여 도 1에 도시된 사용자 단말기로부터 액세스될 수 있는 상품 또는 서비스로의 웹사이트 액세스를 웹 서버에 제공하고 이들 상품 및 서비스는 도 2의 ICC(5)와 같은 카드들을 이용하여 구매될 수 있다. 많은 전자 상거래 상점들이 일반적으로 카드 보유자 프로파일링(cardholder profiling)을 지원한다. 카드 보유자 프로파일링은 카드 보유자에 관한 정보를 수집하고 이 데이터를 이용하여 카드 보유자의 체크아웃 처리를 능률화하는 것으로 이루어진다. 전형적으로 수집되는 정보는 요금부과 주소(billing address), 발송 주소, 지불 방법 세부사항(예를 들면, 카드 번호 및 만료일자), 이메일 주소 및 통신 선호도(communication preferences)를 포함한다. 대부분의 상점들은 비프로파일형(non-profiled) 체크아웃도 지원한다. 이 경우, 상점이 카드 보유자 프로파일 데이터베이스를 지원하지 않거나 또는 카드 보유자가 이 상점와 프로파일을 생성하지 않기로 선택한 것이다. 어느 경우이든, 비프로파일형 체크아웃 처리에서는 카드 보유자가 수동으로 완전한 발송, 요금부과 및 지불 세부사항을 제공할 필요가 있다. 전자 상거래 상점들은 카드 보유자들을 위해 온라인 발송 및 구매 경험을 보다 능률화하기 위한 시도로 각종 온라인 체크아웃 처리를 구현하였다. 다수의 상점들이 상점이 관리하는 프로파일 데이터베이스에 저장된 카드 보유자 데이터 및 지불 세부사항을 충분히 이용하여 카드 보유자에게 능률화된 구매 처리를 제공하도록 의도된 익스프레스 체크아웃 처리(도 3)를 구현하였다. 특정 품목 또는 품목들을 브라우징하여 선택한 후에, 카드 보유자는 익스프레스 체크아웃 옵션을 선택한다. 상점은 카드 보유자의 프로파일을 검색하고, 사용자 단말기에주문의 세부사항과 카드 보유자의 지불 세부사항을 결합한 페이지를 제시한다. 카드 보유자는 이들 세부사항을 검토하여 주문을 제시/확인한다.
많은 상점들에 의해 단일 클릭(single-click) 체크아웃 처리들이 구현되었다(도 4 참조). 단일 클릭 체크아웃 처리는 상점이 관리하는 프로파일 데이터베이스에 저장된 카드 보유자 데이터 및 지불 세부사항을 충분히 이용함으로써 이용가능한 가장 효율적인 온라인 구매 처리를 카드 보유자에게 제공하도록 의도되어 있다. 특정 품목을 브라우징하여 선택한 후에, 카드 보유자는 일반적으로 품목의 세부사항 및 가격이 기술되어 있는 모든 페이지에서 이용할 수 있는 단일 클릭 주문 옵션을 선택한다. 통상 고객은 그의 '쇼핑 바구니'에 품목을 추가하거나, 또는 '단일 클릭'으로 그 대금을 지불할 수 있다. 상점은 주문의 세부사항과 카드 보유자의 지불 세부사항을 결합하여 주문을 작성하고, 그것은 카드 보유자에 대한 페이지에서 확인된다. 고객들은 통상 어떤 형태의 고객 관리/상태 페이지를 통하여 최초 단일 클릭 후에 다수의 단일 클릭 주문들을 취소, 정정 또는 결합할 수도 있다.
대부분의 상점들은 통상 주문 세부사항을 확인하고 카드 보유자의 지불 세부사항을 수집하는 처리인 표준 체크아웃을 지원한다(도 5 참조). 표준 체크아웃 처리는 지불 세부사항이 수집될 필요가 있기 때문에 비프로파일형 카드 보유자에 의해 이용되어야 한다. 그러나 프로파일형 카드 보유자도 예를 들어 상이한 지불/개인 세부사항을 이용하고 싶을 경우 종종 표준 체크아웃을 이용하는 쪽을 선택할 것이다.
특정 품목을 브라우징하여 선택한 후에, 카드 보유자는 표준 체크아웃 옵션을 선택한다. 상점은 주문의 세부사항을 보여주고 카드 보유자의 지불 세부사항을 요청하는 페이지를 제시한다. 카드 보유자는 주문 세부사항을 검토하고, 그의 지불 세부사항 및 필요하다면 다른 관련 개인 정보를 제공하고 주문을 제시/확인한다. 어떤 경우, 이 결합된 주문 세부사항 확인/지불 세부사항 요청 페이지는 도 5에 도시된 바와 같이 2 페이지로 분할될 수 있다.
오늘날, 원격 거래는 모든 금융 거래의 상당한 거래량을 나타낸다. 1997년 Prentice Hall 출판, W. Ford 및 M. S. Baum의 "Secure Electronic Commerce"; 1997년 Academic Press 출판, P. Wayner의 "Digital Cash" 제2판; 1998년 Addison-Wesley 출판, G. W. Treese 및 L. C. Stewart의 "Designing Systems for Internet Commerce"와 같은 서적들에서 각종 금융 거래 시스템에 대한 설명을 찾을 수 있다. 위험의 관점에서 이들 거래는 종종 보증되지 않으므로 취득자/상점의 위험 부담이 있다. 인터넷 상에서 그러한 금융 전송의 보안성이 높아야 할뿐만 아니라 복잡한 절차 없이 편리한 발송을 허용해야 한다. 인터넷 금융 거래의 용이성 및 보안성을 향상시킬 필요성이 항시 존재한다.
본 발명은 일반적으로 광역 데이터 네트워크와 같은 컴퓨터 네트워크를 이용한 지불 시스템 및 방법에 관한 것이다. 보다 구체적으로, 본 발명은 집적 회로 카드를 이용하여 인터넷과 같은 공개 네트워크를 통하여 실행되는 지불 시스템의 일부인 인증 장치 및 이와 관련된 방법에 관한 것이다. 본 발명은 또한 상기 인증 장치 및 방법을 구현하기 위한 소프트웨어에 관한 것이다.
도 1은 본 발명에서 이용될 수 있는 메인 액세스 디바이스를 도시한다.
도 2는 본 발명에서 이용될 수 있는 집적 회로 카드를 도시한다.
도 3은 공지의 익스프레스 체크아웃 페이지 흐름을 도시한다.
도 4는 공지의 단일 클릭 처리 흐름을 도시한다.
도 5는 공지의 표준 처리 흐름을 도시한다.
도 6은 바이트들이 어떻게 기술되는지를 도시한다.
도 7은 본 발명의 일 실시예에 따른 인증 시스템을 도시한다.
도 8은 본 발명의 일 실시예에 따른 인증 시스템의 상세 흐름도이다.
도 9는 본 발명의 일 실시예에 따른 IIPB 데이터 구조를 도시한다.
도 10은 본 발명의 일 실시예에 따른 UCAF 구조를 도시한다.
도 11은 본 발명의 일 실시예에서의 AAV의 인코딩을 도시한다.
도 12는 '0으로의 필러(filler) 설정' 대 '0으로의 데이터 설정'을 도시한다.
도 13은 본 발명의 일 실시예에 따른 PCR 챌린지를 형성하기 위한 처리 흐름을 도시한다.
도 14는 본 발명의 일 실시예에 따른 UN의 27 비트까지 제공하는 챌린지로부터 8 비트를 도시한다.
도 15는 본 발명의 일 실시예에 따른 비트 추출 및 압축을 도시한다.
도 16은 기수(base) 2로부터 기수 10 토큰으로의 요구 데이터 비트들의 변환 예를 도시한다.
도 17은 본 발명의 일 실시예에 따른 흐름 처리의 개요를 도시한다.
도 18은 본 발명의 일 실시예에 따른 구매 완료로부터 상점 접수까지의 흐름 처리를 도시한다.
도 19는 본 발명의 일 실시예에 따른 수정된 익스프레스 체크아웃 페이지 흐름을 도시한다.
도 20은 본 발명의 일 실시예에 따른 수정된 단일 클릭 처리 흐름을 도시한다.
도 21은 본 발명의 일 실시예에 따른 수정된 표준 처리 흐름을 도시한다.
도 22는 본 발명의 일 실시예에 따른 카드 활성화 처리 흐름을 도시한다.
도 23은 본 발명의 일 실시예에 따른 PCR-ICC 교환 처리 흐름을 도시한다.
도 24는 본 발명의 일 실시예에 따른 카드 활성화로부터 토큰 생성까지의 처리 흐름을 도시한다.
본 발명은 종래에 카드 보유자가 실제로 금융 거래를 인정하였다는 아무런 증거도 제시할 수 없어서 환불배상(chargebacks)의 손해를 겪게 되는 금융 거래 환경에서의 카드 보유자 인증의 목표를 충족시킨다. 본 발명은 POI(point-of-interaction)에서 카드 보유자를 확실히 인증하고 카드 존재 및 카드 보유자가 거래를 시작했다는 사실 양쪽 모두의 명백한 증거를 제공함으로써 인터넷 채널을 안전하게 하기 위한 메커니즘을 제공한다. 본 발명은 다음 중 적어도 하나를 포함하는 다수의 목표를 갖는다.
카드 보유자 비인증 거래로 인한 환불배상 감소.
신용 및 직불 거래 양쪽 모두 지원.
취득자 시스템 충돌 최소화.
신속한 상점 채택 보증.
실제 계좌 번호(account number), 가상 계좌 및 의사 계좌 번호에 대한 인증 지원.
일 양태에서 본 발명은 컴퓨터 기반 인증 방식(scheme)을 제공하고, 특히 본 발명은 인터넷을 통하여 금융 거래를 제공하기 위한 컴퓨터 구현 방법 및 시스템을 제공한다.
일 양태에서 본 발명은, 집적 회로 카드(ICC)를 이용하여 네트워크를 통해 상품의 판매를 거래하기 위한 네트워크 지불 시스템에서 이용되는 인증 장치를 제공하고, 상기 인증 장치는, 상기 네트워크와 통신하는 상점 서버(merchant server) -상기 상점 서버는 적어도 제1 품목의 판매 상품을 구비하고 있음- 와; 상기 네트워크와 통신하는 고객 단말기 -상기 고객 단말기는 상기 제1 판매 품목을 검토하기 위한 출력 디바이스와, 상기 제1 판매 품목을 구매하기 위한 구매 거래를 개시하기 위한 입력 디바이스를 구비하고, 상기 고객 단말기는 상기 상점 서버로부터 획득된 상점 식별자에 관한 정보 및 금융 거래 정보를 이용하여 구매 메시지를 작성하도록 구성되며, 상기 고객 단말기는 상기 상점 식별자에 관한 정보 및 계좌 번호로부터생성되는 챌린지 메시지(challenge message)를 생성하기 위한 수단을 구비함- 와; 상기 집적 회로 카드와 통신하기 위한 카드 판독기와; 상기 카드 판독기에서 상기 챌린지 메시지를 수신하고 이 챌린지 메시지로부터 하나의 값을 생성하기 위한 수단을 포함한다. 이 값은 바람직하게는 ICC에 의해 예측 불가능한 값이다. ICC는 상기 값의 적어도 일부로부터 암호 메시지를 생성하기 위한 수단을 구비하고, 상기 카드 판독기는 상기 암호 메시지의 적어도 일부로부터 인증 토큰을 생성하기 위한 수단을 구비한다. 고객 단말기는 네트워크를 통하여 송신하기 위한 메시지 내에 인증 토큰의 적어도 일부를 송신하기 위한 수단을 구비한다. 상기 송신의 행선은 상점 서버일 수 있다. 네트워크는 금융 거래를 승인하기 위한 거래 승인 서버를 구비할 수 있고, 상기 송신의 행선은 상기 승인 서버이다. 챌린지 메시지를 생성하기 위한 상기 수단은 상기 상점 식별자에 관한 정보, 계좌 번호 및 구매량과 구매 통화(purchase currency) 중 적어도 하나로부터 상기 챌린지 메시지를 생성하도록 구성될 수 있다. 상기 인증 토큰의 적어도 일부를 송신하기 위한 수단은 상기 인증 토큰의 상기 적어도 일부를 상기 상점 서버에 송신하도록 구성될 수 있고 상기 상점 서버는 상기 인증 토큰의 상기 적어도 일부를 인증 요청 메시지 내의 구매 정보와 함께 상기 거래 승인 서버에 송신하도록 구성된다. 챌린지 메시지를 생성하기 위한 수단은 상기 상점 식별자 및 상기 계좌 번호와, 그리고 구매량과 구매 통화 중 적어도 어느 하나를 연결시키도록 구성될 수 있다. 챌린지 메시지를 생성하기 위한 수단은 상기 상점 식별자 및 계좌 번호와, 그리고 구매량과 구매 통화 중 적어도 어느 하나의 연결을 압축하도록 구성될 수 있고, 상기 압축은 해시 함수의 애플리케이션일 수 있다. 상기 승인 서버는 상기 인증 토큰의 적어도 일부를 재작성하고 이 재작성된 메시지를 상기 상점 서버로부터 송신된 상기 인증 요청 메시지 내의 상기 인증 토큰의 상기 적어도 일부와 비교할 수 있다. 상기 거래 승인 서버는 상기 비교가 긍정적이면 상기 상점 서버에 승인 메시지를 송신하도록 구성될 수 있다. 상기 집적 회로 카드는 메모리 및 상기 메모리에 저장된 제1 데이터 객체를 가질 수 있고 상기 암호 메시지의 적어도 일부로부터 인증 토큰을 생성하기 위한 수단은 상기 제1 데이터 객체에 따라서 상기 암호 메시지의 상기 일부의 일부분을를 선택하도록 구성될 수 있다. 제2 데이터 객체가 상기 메모리에 저장될 수 있고 챌린지 메시지를 생성하기 위한 상기 수단은 상기 제2 데이터 객체에 따라서 상기 챌린지 메시지의 생성 시에 구매량과 구매 통화 중 적어도 하나를 포함할 수 있다.
다른 양태에서 본 발명은 집적 회로 카드를 이용하여 네트워크를 통하여 상품의 판매를 거래하는 것의 일부로서의 인증 방법을 제공하고, 이 방법은, 상기 네트워크를 통해 상점 서버와 고객 단말기 사이의 통신을 설정하는 단계 -상기 상점 서버는 적어도 제1 품목의 판매 상품을 구비하고 있음- 와; 상기 고객 단말기 상에서 상기 제1 판매 품목을 검토하고, 상기 제1 판매 품목을 구매하기 위한 구매 거래를 개시하고, 상기 상점 서버로부터 획득된 상점 식별자에 관한 정보 및 금융 거래 정보를 이용하여 구매 메시지를 작성하는 단계와; 상기 상점 식별자에 관한 정보 및 계좌 번호로부터 상기 고객 단말기 상에서 챌린지 메시지를 생성하고, 상기 챌린지 메시지를 카드 판독기에서 수신하고 상기 챌린지 메시지로부터 하나의 값을생성하는 단계와; 상기 집적 회로 카드와 상기 카드 판독기 사이의 통신을 설정하고 상기 값의 적어도 일부로부터 암호 메시지를 생성하고, 상기 암호 메시지의 적어도 일부로부터 상기 카드 판독기 상에서 인증 토큰을 생성하고, 상기 고객 단말기로부터 상기 네트워크를 통하여 송신용 메시지 내의 상기 인증 토큰의 적어도 일부를 승인 서버로 송신하는 단계를 포함한다.
챌린지 메시지를 생성하는 단계는 상기 상점 식별자에 관한 정보, 계좌 번호 및 구매량과 구매 통화 중 적어도 하나로부터 상기 챌린지 메시지를 생성하는 단계를 포함한다. 상기 인증 토큰의 적어도 일부를 송신하는 단계는 상기 인증 토큰의 상기 적어도 일부를 상기 상점 서버에 송신하고 상기 상점 서버로부터 상기 인증 토큰의 상기 적어도 일부를 인증 요청 메시지 내의 구매 정보와 함께 상기 거래 승인 서버에 송신하는 단계를 포함할 수 있다. 챌린지 메시지를 생성하는 단계는 상기 상점 식별자 및 상기 계좌 번호와, 그리고 구매량과 구매 통화 중 적어도 어느 하나를 연결시키는 단계를 포함할 수 있다. 챌린지 메시지를 생성하는 단계는 상기 상점 식별자 및 상기 계좌 번호와, 그리고 구매량과 구매 통화 중 적어도 어느 하나의 연결을 예를 들어 해시 함수를 적용하여 압축하는 단계를 포함할 수 있다. 상기 방법은 상기 승인 서버에서 상기 인증 토큰의 적어도 일부를 재작성하고 이 재작성된 메시지를 상기 상점 서버로부터 송신된 상기 인증 요청 메시지 내의 상기 인증 토큰의 상기 적어도 일부와 비교하고 이어서 상기 비교가 긍정적이면 상기 상점 서버에 인증 메시지를 송신하는 단계를 포함할 수 있다. 상기 집적 회로 카드는 메모리 및 상기 메모리에 저장된 제1 데이터 객체를 가질 수 있고, 상기 방법은상기 제1 데이터 객체에 따라서 상기 암호 메시지의 상기 일부의 일부분을 선택함으로써 상기 암호 메시지의 적어도 일부로부터 인증 토큰을 생성하는 단계를 더 포함할 수 있다. 상기 방법은 상기 제2 데이터 객체에 따라서 구매량과 구매 통화 중 적어도 하나로부터 챌린지 메시지를 생성하는 단계를 더 포함할 수 있다.
본 발명은 어떠한 환경에서든 보증을 위한 기초를 구성해야 하는 하기의 4개의 구성 블록들(building blocks)을 정의함으로써 원격 거래를 위한 모든 채널들 및 거래 타입들을 다룰 수 있다.
a) CAM 기능, 즉 카드/계정이 진짜라는 증거
b) CVM 기능, 카드 보유자가 진짜라는 증거
c) 발행인에 의한 거래 인증의 증거
d) 거래 환경의 기술
본 발명의 일 양태에서의 기반구조의 정의 및 구현은 전자 상거래 환경에서 보증된 거래를 실현한다. 그러한 서비스에 적합한 제1 카테고리의 거래들은 전자 상거래 지불로서, 인터넷 기반의 "전자 상거래" 및 무선 기반의 "m-commerce" 양쪽 모두이다. 그 모델은 포괄적이기 때문에, 그것은 다수의 채널들에 걸쳐서 일관되게 이용될 수 있고 우편 주문 또는 전화 주문을 포함하는 다른 환경들까지 확장될 수 있다. 간접적인 카드 보유자 이익은 다음과 같다.
인지되는 위험의 감소
더 많은 상점들이 인터넷을 통한 사업을 준비하게 됨
상기에 따라 전자 상거래의 매출액이 늘고 그 결과 사업 경쟁이 고무됨
진짜 '내가 아님'(not me) 거래들에 대한 논쟁이 감소/제거되고 그 결과 '혼전'(hassle)이 감소됨
본 발명은 예를 들어 유니버설 카드 보유자 인증 필드(UCAF : Universal Cardholder Authentication Field) 내의 발행인에게 전송하기 위한 인증 토큰들을 생성하는 개인 카드 판독기(PCR: Personal Card-reader)를 이용하는 전자 상거래 애플리케이션들을 위한 ICC 인증 프로그램에 관한 것이다. 토큰 생성 방식의 설계시에, 카드 보유자 친화성 -검사 숫자(check digits) 등을 이용하여 데이터 요건을 그 최소 한도까지 삭감함으로써- 이 제공되었다. 일 양태에서 본 발명은 UCAF를 통한 인터넷 기반 전자 상거래를 위해 개인 카드 판독기를 이용하여 ICC 기반 인증을 성취하는데 이용되는 방식의 기능 아키텍처를 포함한다.
고객(Customer) 및 카드 보유자(Cardholder)라는 용어들은 본 발명의 목적을 위하여 상호 교체될 수 있지만, 일관성을 위하여 통상 카드 보유자라는 용어가 사용된다. 그것은 엄격히 카드를 발행받은 사람을 의미한다기보다는 카드와 함께 일례로 PIN과 같은 해당 카드의 인증 메커니즘 양쪽 모두를 소유한 사람을 말한다. 본문과 도면 전체에서 상점(Merchant), 취득자(Acquirer) 및 발행인(Issuer)은 데이터의 입력 또는 메시지의 전달, 웹 페이지에 관한 한 인터넷과 통신하는 각각의 서버들을 말한다.
모든 표, 도표 및 본문에서 예를 들어 "바이트 1이 전송됨"과 같이 번호를 매긴 바이트를 언급하는 것은 블록/서브블록의 시작으로부터 카운트하여 보다 큰 블록 내의 바이트들을 언급하는 스타일로 되어 있다. 바이트들은 값들에 관한 한 최상위/최하위 바이트 스타일로 번호가 매겨지지 않는다. 때때로 이 결과로 예를 들어 애플리케이션 거래 카운터(Application Transaction Counter)와 같은 숫자 데이터 요소의 최상위 바이트는 바이트 1로 불리고 최하위 바이트는 바이트 2로 지칭되게 될 것이다. 한편 비트들은 최상위 비트가 "제1" 비트로서 비트 8로 지칭되는 반면 최하위 비트가 "마지막" 비트로서 비트 1로 불리는 역방식으로 식별된다. 도 6을 참조한다. 수(number)가 제공/예시되고 그 수의 기수가 기술되지 않은 경우그것은 십진수(기수 10)인 것으로 가정한다. 수가 선두 '0x'와 함께 제공/예시되는 경우 그것은 16진수(기수 16)인 것으로 가정한다.
명세서의 본문을 설명하고 명백하게 하는 것을 돕기 위해 예들이 이용되고 명세서와 관련 예에 나타난 것과의 사이에 불일치가 있다면, 항상 명세서가 기준인 것으로 간주되어야 한다.
<용어>
AAC : 애플리케이션 인증 암호(Application Authentication Cryptogram)
AAV : 계좌 보유자 인증 값(Accountholder Authentication Value)
AC : 인증 암호
AFL : 애플리케이션 파일 로케이터, ICC 내의 어디에 어떤 기록들(records)이 이용 가능한지를 식별함.
AID : 애플리케ㅣㅇ션 식별자, ICC에 제공된 어플리케이션을 식별하는 6개의 문자열.
AIP : 애플리케이션 교환 프로파일, 특정 기능들을 지원하는 ICC의 능력을 나타냄.
APDU : 애플리케이션 처리 데이터 유닛, ICC와 어떤 외부 애플리케이션 사이에 송신된 메시지들.
ARQC : 애플리케이션 요구 암호(Application ReQuest Cryptogram)
ATC : 애플리케이션 거래 카운터
BCD : 2진 코드화된 십진수
Big-Endian(빅엔디언) : 값의 최상위 바이트가 먼저 저장되고 이어서 각각의 연속하는 바이트가 저장되고 최하위 바이트가 마지막에 저장되는 인코딩 스타일
CAP : 칩 인증 프로그램
CDOL : 카드 위험 관리 데이터 객체 리스트
CID : 암호 정보 데이터
CSN : 카드 일련 번호
CVC2 : 카드 검증 코드(Card Verification Code)
CVM : 카드 보유자 검증 방법, 카드에 대한 카드 보유자를 검증하는데 이용되는 방법
DAC : 다이내믹 인증 암호
DOM : 문서 객체 모델, 브라우저에 의해 플러그 인에 제공된 현재 HTML 페이지의 프로그램 보기(view)
HHD : 핸드 헬드 디바이스, 예를 들면 카드 판독기
EMV : 유로페이 마스터카드 비자(Europay MasterCard Visa)
IA : 인터페이스 애플리케이션
IAD : 발행인 애플리케이션 데이터
IAF : 인터넷 인증 플래그, IIPD의 제1 바이트
ICC : 집적 회로 카드, 칩카드 또는 스마트카드로도 알려져 있음.
IIPB : 발행인 인터넷 소유 비트맵(Issuer Internet Proprietary Bitmap), AC를 검정(validate)하기 위해서 발행인에게 송신될 필요가 있는 비트들을 식별함.
IIPD : 발행인 인터넷 소유 데이터, 인터넷 관련 거래의 목적으로 암호를 계산하는 것과 관련하여 발행인에 의해 사용되는 소유 데이터
ITV : 대화형 텔레비전(Interactive Television)
LATC : 하위 (바이트의) 애플리케이션 거래 카운터
Little-Endian(리틀엔디언) : 값의 최하위 바이트가 먼저 저장되고 이어서 각각의 연속하는 바이트가 저장되고 최상위 바이트가 마지막에 저장되는 인코딩 스타일
MAC : 메시지 인증 코드, 메시지 내의 데이터 항목들에 대해 계산된 암호 서명으로서, 그 메시지의 출처를 입증하고 또한 그 데이터 항목들이 수정되었는지 여부에 대한 검출을 허용하기 위한 것.
MCD : 메인 카드 보유자 디바이스, 브라우징 및/또는 주문 및/또는 지불이 행해지는 디바이스.
Nibble(니블) : 1 바이트의 절반, 즉 4 비트
P1 : APDU의 파라미터 1, ICC에 송신되는 커맨드를 효과적으로 고객화(customize)함.
PAN : 제1 계좌 번호(Primary Account Number)
PC : 개인용 컴퓨터
PCR : 개인 카드 판독기
Cardholder(카드 보유자) IA : 카드 보유자 인터페이스 애플리케이션, 인증 요청자, 카드 보유자 및 PCR 간을 인터페이스하는 MCD 상에서 실행되는 애플리케이션.
PDA : 개인 휴대 정보 단말기(Personal Digital Assistance)
PDOL : 처리 옵션 데이터 객체 리스트(Processing Options Data Object List), 단말기(즉, PCR)에게 이용가능하고 단말기에 의해 지원되는 처리 옵션들의 리스트.
PIN : 개인 식별 번호
SPA : 안전 지불 애플리케이션
TLV : 태그 길이 값
UCAF : 유니버설 카드 보유자 인증 필드
UN : 예측 불가능 수
본 발명에 따른 인증 방식은 유니버설 카드 보유자 인증 필드(UCAF)를 이용하는 것이다. 이 방식은 단지 편의상 칩-UCAF(Chip-UCAF)로 불릴 것이다. 본 발명은 UCAF 기반구조를 이용하는 안전한 인증 방법들을 제공한다. 이 방법은 하기 구성요소들을 포함한다.
발행인 제공 칩-UCAF 인에이블(Issuer Provided Chip-UCAF-Enabled) 인터페이스 애플리케이션
칩-UCAF 계좌 보유자 인증 값(AAV) 생성.
카드 보유자 인증
UCAF 인증 데이터 필드 내의 AAV 데이터의 상점 프리젠테이션, 수집 및 처리.
UCAF에 포함된 대로 AAV 데이터의 취득자 접수 및 처리.
UCAF 인증 데이터 필드 내에 상기 AAV 데이터를 전송하는 것의 지원을 포함하기 위한 뱅킹 네트워크 개발.
UCAF 인증 데이터 필드 내의 AAV 데이터의 인증 지원.
하기의 엔티티들이 칩-UCAF 인증 거래의 수명(lifetime)에 관계된다.
카드 보유자 - 카드 보유자는 거래를 개시하고 상점의 지불 웹 페이지, 카드 보유자 인터페이스 애플리케이션, 및 개인 카드 판독기 모두에 데이터를 입력할 책임이 있다.
상점 - 상점은 예를 들면 인터넷과 통신하는 상점 서버로부터 인증 거래를 시작하는 데 필요한 데이터를 제공하고 결과의 UCAF 데이터를 수신하여 그들의 취득자를 경유하여 승인을 위해 카드 발행인에게 전송한다.
카드 보유자 인터페이스 애플리케이션(Cardholder Interface Application) - 카드 보유자 IA는 상점에 의해 제공된 관련 데이터를 검출하고 개인 카드 판독기에 의해, 카드 보유자를 통하여, 직접 및 간접적으로 카드 보유자와 상호 작용한다. 카드 보유자 IA는 AAV 및 UCAF를 생성하고 상점의 페이지에 적절한 데이터를 채운다. 예를 들면, 카드 보유자 IA는 인터넷 상의 상점에 액세스하기 위해 이용되는 메인 카드 보유자 디바이스(MCD) 상에서 인터넷 브라우저의 일부로서 동작할 수 있다.
개인 카드 판독기 - PCR은 카드 보유자 및 ICC와 상호 작용하여 발행인에게 간접적으로 전달되는 인증 토큰을 생성한다.
ICC - 칩 카드는 제시된 PIN 검증을 이용하여 카드 보유자를 인증하고 PCR에 의해 공급된 데이터에 기초하여 적당한 암호를 생성한다.
취득자 - 취득자는 예를 들면 취득자 서버에서 상점으로부터 서식화된 UCAF 데이터를 접수하고, 그것을 UCAF 데이터의 이용 및 존재의 지시자와 함께 적당한 통신 네트워크를 통하여 발행 은행에 전송한다. 마스터카드가 취득자이다.
발행인 - 카드 발행인은 칩-UCAF 방식에 서명되어 있는 카드 보유자들에게 PCR들을 분배한다. 발행인은 인터넷과 통신하는 발행인 서버 플랫폼을 유지한다. 본 발명에 따르면 발행인 서버는 UCAF로 인코딩되고, 해당 발행인의 룰에 따라서 취득자에 의해 인증 요청 내에 송신된 인증 토큰을 검정한다.
일 양태에서 본 발명은 전자 상거래 지불 서비스를 위한 인증을 제공한다. 카드 보유자 존재 상태가 온라인 상태에 있는 거래를 위하여 발행인에게 제공된다. 기존의 지불 방식 네트워크를 통한 전형적인 인증 루트(route)가 이용될 수 있다. 개인 카드 판독기는 독립형 디바이스로서 동작하거나 또는 카드 보유자의 액세스 디바이스(예를 들면, 랩탑, PC, 포켓 PC, 스마트 폰, 팜 파일럿(palm pilot), PDA)에 접속되거나/그것과 통합되어 사용된다. 판독기는 바람직하게는 제한된 카드 보유자 상호 작용을 허용하기 위해 디스플레이 및 키패드를 구비한다. 개인 카드 판독기에 대한 명세서는 바람직하게는 최대로 가능한 수의 상이한 카드 구현들을 허용해야 하고 그와 동시에 카드 보유자의 편의를 제공해야 한다. 개인 카드 판독기는 바람직하게는 PIN 검정 결과를 나타낼 수 있는 표시 능력과, 비접속 디바이스들을 위하여 메인 카드 보유자 디바이스 상에서 손으로 입력되어야 하는 토큰을 구비해야 한다. 개인 카드 판독기는 ICC 서명이 검증될 수 있도록 하기 위하여 그들에게 전송되어야 하는 데이터에 대한 발행인으로부터의 지시(indication)를 ICC로부터 획득할 수 있어야 한다. 개인 카드 판독기는 바람직하게는 생성된 토큰에 거래량과 거래 통화를 통합할지의 여부에 대한 발행인으로부터의 지시를 ICC로부터 획득할 수 있어야 한다. 그러한 지시가 행해질 경우 판독기는 카드 보유자가 양과 관련 수치 통화 코드를 입력하게 할 수 있어야 한다. 카드 보유자에 의해 거래량이 입력될 경우, 그것은 바람직하게는 '자연' 포맷, 즉 십진 표시자를 포함하는 것이지만, 카드 서명에 포함하기 위해 ISO 4217 베이스 통화 단위로 변환된다. 카드 보유자에 의해 입력되거나, 또는 다르게는 판독기에 전달된 임의의 그러한 양은 바람직하게는, 카드 보유자에 의해 PIN을 통하여 승인되기에 앞서, EUR과 같은 관련 3-문자 통화 심벌과 함께 표시되어야 한다.
UCAF(Universal Cardholder Authentication Field) 데이터 필드는 임의 형태의 통신 네트워크를 통하여 취득자로부터 발행인으로의 인증 데이터의 통신을 허용하기 위한 디지털 메시지 내의 다용도 데이터 전송 영역이다. 예를 들면, UCAF는 각종 발행인 보안 및 인증 요건의 요구들을 지원하도록 맞추어질 수 있는 유연한 데이터 구조를 갖는 32-문자 필드(32 문자가 되도록 기수-64 인코딩되는 24 바이트 - 1 제어 바이트 및 23 데이터 바이트 -)일 수 있다. 예를 들면, ISO 8583 데이터 엘리먼트(48), 서브엘리먼트(43)가 UCAF를 포함하도록 지정될 수 있다. UCAF라는 용어는 또한 상점와 MCD 간에 데이터를 전달하고 돌려 받도록 정의된 인터페이스, 즉 임의의 주어진 채널에 대한 명세서 내의 필드 이름을 가리키는 것으로 확장된다.
계좌 보유자 인증 값(AAV)은 UCAF 애플리케이션 특정 데이터의 일부, 예를 들면 23 바이트에 부여되는 용어이다. 주어진 UCAF 애플리케이션의 모든 구현예가 해당 애플리케이션의 AAV 구조를 이용해야 한다. 즉, AAV 포맷은 주어진 UCAF 애플리케이션에 대해 표준화된다.
칩-UCAF 카드 보유자 인증 방식을 이용하기 위하여 카드 보유자는 적당한 IC 지불 카드 및 개인 카드 판독기를 구비할 필요가 있다. PCR은 그들의 카드 발행인에 의해 카드 보유자에게 공급될 것이고, 카드 발행인은 해당 카드 보유자가 PCR을 갖고 있고 칩-UCAF 카드 보유자 인증 방식에 '기록'(enrolled)되어 있음을 등록(register)할 것이다. 상점에 의해 공급된 UCAF 거래 데이터는 표시 목적으로 이용되고 그것의 일부는 거래 관련 PCR 챌린지를 생성하는데 이용된다. 상점이 UCAF 응답 내의 AAV 데이터에 대해 수행할 필요가 있는 추가의 처리는 없다. 이것은 칩-UCAF에 대한 값으로 설정되는 UCAF 제어 바이트 값을 통하여 상점에게 지시된다. 카드 보유자 인터페이스 애플리케이션(카드 보유자 IA)은 인증 요청자(상점), 카드 보유자 및 PCR 간의 상호 작용을 제공한다. 이 인터페이스 애플리케이션은 현재의 UCAF 방식의 안전한 면을 카드 보유자에게 제시한다. 그것은 거래 데이터를 카드 보유자에게 제시하고, PCR에 전송된 챌린지를 생성하고, PCR 토큰 응답을 수신하고, UCAF를 포맷하여 주어진 채널에 대한 리턴 데이터를 채울 책임이 있다. 카드 보유자 IA는 칩-UCAF 거래를 달성하기 위하여 충족시켜야 하는 최소 세트의 요건들을 갖는다. 그것은 또한 지능적인 서식 채우기(intelligent form filling), 수신추적/기록(tracking/logging), 개인 재무 소프트웨어와의 통합과 같은 부가 기능을 추가할 수도 있다.
메인 카드 보유자 디바이스(MCD)는 아마도 브라우징/발송이 행해지고, 이 명세/방식의 범위에 대해, 지불 및 인증 처리가 확실히 행해지는 디바이스이다. 본 발명은 인터넷 브라우저 환경에서의 어떤 플랫폼 상의 PC 디바이스와 관련하여 기술될 것이다. 카드 보유자 IA는 이 환경에서 실행되어야 한다.
개인 카드 판독기(PCR)는 PIN 입력 및 검정, 예를 들면 전자 상거래를 목적으로 디바이스에 삽입된 카드 보유자의 ICC에 의한 거래 문맥 데이터의 오프라인 및 인증을 가능하게 하는 디바이스이다. 본 발명에서는 비접속 PCR, 즉 어떤 외부 시스템과도 물리적/전기적 접속이 없는 디바이스로서 그 디바이스의 데이터 입출력을 위한 인터페이스가 카드 보유자인 디바이스가 키패드 및 디스플레이를 통해 사용될 수도 있다. 다른 접속 타입을 갖는 개인 카드 판독기도 사용될 수 있다.
비접속 PCR 디바이스는 어떤 외부 시스템과도 물리적/전기적 접속을 갖지 않는다. 그 디바이스의 데이터 입출력을 위한 인터페이스는 사람, 즉 카드 보유자와 상호 작용하는 키패드 및 디스플레이이다. 비접속 디바이스를 이용할 때, 카드 보유자는 PIN 외에, 인증 값을 생성하기 위하여 PCR이 그 카드와 관련하여 사용할 특정 데이터를 수동으로 입력해야 한다. 카드 보유자가 카드 보유자 인터페이스 애플리케이션에 수동으로 입력하게 될 인증 값이 PCR의 디스플레이 상에 표시된다. 데이터 입력 검정을 가능하게 하기 위해 검사 숫자들(check digits)이 이용된다.
PCR 접속 디바이스들은 카드 보유자가 수동으로 데이터를 전달하는 불편함이없이 보다 많은 데이터가 MCD에 전송될 수 있게 한다. 접속 케이블이 제거될 때 비접속 모드로 동작할 수 있는 접속 디바이스들이 고안될 수도 있다.
PCR 단방향(one-way) 접속 디바이스는 출력 방향으로만 MCD에 접속된다. 그 디바이스의 데이터 입력을 위한 인터페이스는 키패드이다. 그것은 카드 보유자와의 상호 작용을 위한 디스플레이를 갖는다. 카드 보유자는 다시 MCD와 PCR 간의 데이터 전송 메커니즘으로서 역할을 한다. 카드 보유자는 그의 PIN 외에, 인증 값을 생성하기 위하여 PCR이 그 카드와 관련하여 사용할 특정 데이터를 수동으로 입력해야 한다. 인증 값은 단방향 접속을 통하여 MCD의 외부로 송신된다.
양방향(two-way) PCR 접속 디바이스는 양쪽 방향으로 MCD에 접속된다. 이 디바이스는 카드 보유자 PIN 입력을 위한 키패드 및 카드 보유자와의 상호 작용을 위한 디스플레이를 갖는다. 카드 보유자는 그의 PIN만 입력하면 된다. MCD는 인증 값을 생성하기 위하여 PCR이 그 카드와 관련하여 사용할 모든 데이터를 전송할 수 있다. 인증 값은 MCD로 출력 송신된다.
통합(integrated) PCR 디바이스는 스마트카드 판독기에 대해 직접 접속을 갖는 MCD이다. 이 용어는 스마트카드 판독기가 내장된 PDA에 적용하기 위한 의도지만, 이 기술용어는 직접 접속된 스마트 카드를 구비한 데스크탑 PC에도 똑같이 적용될 수 있다. 카드 보유자는 그의 PIN만 입력하면 된다. MCD는 모든 PCR 기능을 수행하고 접속된 판독기를 통하여 ICC에 직접 커맨드를 전송한다. ICC로부터의 응답은 MCD 자체에 의해 처리된다. 소프트웨어는 카드 보유자 IA가 양방향 접속 디바이스에서와 동일하게 동작할 수 있도록, 즉 카드 보유자 IA에 의해 PCR로 출력되는 통신이 행해질 때, 동일 MCD 상에 '이제 막 발생되는'(just happens to be) PCR로 및 그 PCR로부터 드라이버들이 데이터를 송수신하도록 기록될 수 있다.
접속 및 통합된 PCR 디바이스는 MCD에 통합된 내장형 PCR일 것이다. 그러한 디바이스에 대한 요건들은 접속 디바이스에 대한 것들과 다르지 않고, PC 키보드 및 다른 입출력 디바이스에 통합될 수도 있다.
UCAF의 문맥에서, UCAF 인에이블된 취득자는 UCAF 인에이블된 상점와 관계를 갖는다. 취득자들은 그들의 상점들로 하여금 여분의 UCAF 데이터를 취득 시스템에 전달할 수 있게 하고 그들의 시스템들로 하여금 공급된 UCAF의 존재를 확인하여 그것을 발행 은행에 전달할 수 있게 한다.
발행인 호스트, 또는 그 방식에 대해 발행인 호스트 역할을 하는 어떤 다른 구성요소는 UCAF 내의 데이터를 포함하여 인증 네트워크 메시지 내에 전달되는 데이터를 취하여, 인증 토큰이 검정될 수 있게 할 책임이 있다.
본 발명에서 기술된 칩 기반 기능들이 본질적으로 발행 은행에게 카드 존재를 검증하는 수단을 제공한다고 가정하면, 본 발명은 또한 원격 뱅킹 환경("e-" 또는 "m-뱅킹")에서 구현될 수 있다. 이것은 은행들에게 여러 상품, 서비스 및 환경에 걸쳐서 일관된 소비자 인증 방법을 제공할 것이다.
칩-UCAF는 UCAF 기반구조를 이용하여 카드 보유자, 상점, 취득자 및 발행인 간에 인증 및 보안 데이터를 전송한다. 도 7은 본 발명의 일 실시예에 따른 전형적인 칩-UCAF 거래에 대한 처리 흐름을 도시한다. 이 흐름은, 거래를 수행하기 전에, 카드 보유자가 그의 발행인에게 그 서비스를 신청하였고, 카드 보유자 인터페이스 애플리케이션을 획득하여 개시하였고 그의 ICC 카드와 호환성 있는 개인 카드 판독기를 획득하였다는 것을 가정한다. 또한 카드 보유자는 상점 서버 상에 제공된 상품 또는 서비스를 확인하였고 체크아웃 처리를 개시하였으며 이미 상점으로부터 지불 카드 세부사항들을 제공하도록 요청 받았다는 것을 가정한다. 일단 품목들이 선택되고 체크아웃 단계가 시작되면, 카드 보유자는 계좌 주소(account address), 발송 주소(shipping address) 및 지불 카드 세부사항들을 상점에게 제공한다. 계좌 및 발송 주소 정보는 직접 또는 그 특정 카드 보유자에 대해 상점에게 저장된 정보에 기초하여 입력될 수 있다. 상점이 주문의 확인 및 인증을 요청하면, 그 상점의 웹 서버는 이 거래를 고유하게 기술하는 일련의 숨은 필드들을 제공한다. 이를테면, 이 정보는 하기 사항 중 하나 또는 몇 개를 포함할 수 있다.
상점 이름
카드 허용 도시(Card Acceptor City)
카드 허용 주/국가 코드
통화 코드
판매량
상점 거래 스탬프
UCAF 인증 데이터 필드
지불 카드 번호(이전에 제공된 카드 번호의 마지막 다섯 숫자가 상점에 의해 채워짐)
UCAF 브랜드
이하 도 7의 번호 매김을 참조하여, 본 발명의 일 실시예에 대해 설명한다.
1. 카드 보유자의 인터페이스 애플리케이션은 UCAF 인증 페이지로부터 상점 식별자 정보 및 거래 데이터를 취득하고 카드 보유자에게 제시되는 챌린지를 작성한다.
2. 카드 보유자는 지불 카드(ICC(5))를 개인 카드 판독기에 삽입한다. 개인 카드 판독기 상에 구현된 애플리케이션은 카드 보유자에게 챌린지를 입력하도록 요청하고 그렇지 않으면 그 챌린지는 자동으로 카드 판독기에 전송된다. 그후에 카드 판독기는 판매량 통화를 추출하고 카드 보유자에게 해당 통화의 판매량을 입력하도록 요청한다.
3. 그후에 카드 보유자는 그가 거래에 동의한다는 증거로서 개인 보안 코드(security code), 예를 들면 PIN을 개인 카드 판독기 상에 입력하도록 요청 받는다. 개인 카드 판독기는 지불 카드(ICC)에게 PIN을 검증하도록 요청한다.
4. 개인 카드 판독기는 지불 카드(ICC)에 대해 적당한 암호화 루틴을 이용하여 거래 관련 데이터(즉, 챌린지)에 서명하도록 요청한다.
5. ICC는 거래 데이터 및 다른 ICC 특정 데이터를 통하여 암호(MAC)를 리턴하고 카드 발행인은 그 암호를 검정할 필요가 있다. 위에서 언급한 서적들뿐만 아니라 1996년 ISBN 0-471-11709-9, B. Schneier의 "Applied Cryptography", 1999년, New Riders 출판, C. Adams, S. Lloyd의 "Understanding Public Key Infrastructure"라는 서적에서 서명 및/또는 암호화의 방법들이 공지되어 있다.
6. 그후 개인 카드 판독기는 카드 발행인에 의해 확인된 가변 데이터 및 암호의 일부를 이용하여 데이터 토큰을 작성한다.
7. 개인 카드 판독기는 그 데이터 토큰을 포맷하여 그것을 카드 보유자에게 제시하고 카드 보유자는 그것을 수동으로 또는 송신으로 카드 보유자 인터페이스 애플리케이션에 입력할 것이다.
8. 카드 보유자 인터페이스 애플리케이션은 UCAF에 포함하기 위한 AAV를 작성한다. 카드 보유자 인터페이스 애플리케이션은 이 특정 거래에 대해 생성된 칩-UCAF를 상점 UCAF 인증 페이지 상에 제공된 숨은 인증 데이터 필드에 삽입한다. 그후 그 거래는 상점에 의한 인증 처리를 위해 제시된다.
9. 상점은 그것의 취득자에게 인증 요청을 제시한다. 인증 요청은 변경되지 않은 칩-UCAF 값을 포함해야 하고, 상기 값은 인증 처리 중에 발행인에 의해 검증될 것이다.
10. 취득자는 (로컬) 인증 요청을 접수하고 인증 요청 메시지를 생성한다. 이 메시지는 칩-UCAF 데이터를 포함한다. 인증 요청 메시지는 뱅킹 네트워크를 통하여 카드 발행인에게 전송된다. 취득자 및 발행인은 임의의 사유 메시지 포맷(들)에 대한 UCAF 명세서에 합의할 필요가 있다.
11. 뱅킹 네트워크는 칩-UCAF를 포함하여 인증 요청 메시지를 카드 발행인에게 전송한다.
12. 인증 요청 메시지를 수신하면, 카드 발행인은 다음을 수행할 것이다.
a) 만일 인증 요청이 상점이 UCAF 인에이블되었음을 나타내지 않는다고 나타내면(예를 들면, 보안 레벨 지시자(Security Level Indicator) 비트가 '0'으로설정되어 "UCAF가 상점에 의해 지원되지 않음"을 나타냄, 후술함), 그 인증 요청은 발행인의 인증 시스템에 의해 평소와 같은 사업 방식(business-as-usual manner)으로 처리될 것이다.
b) 만일 인증 요청이 상점이 UCAF 인에이블되었고 카드 보유자가 칩-UCAF 서비스에 대해 등록되어 있지만 아무런 칩-UCAF 인증 데이터도 존재하지 않는다면(예를 들면, 보안 레벨 지시자 비트가 '1'로 설정되어 "UCAF가 상점에 의해 지원되지만 카드 보유자에 의해 제공되지 않음"을 나타냄, 후술함), 발행인은 그 인증을 승인할지 거절할지에 대해 결정해야 한다. 그러한 시나리오는 카드 보유자가 지불 거래를 처리하기 위해 칩-UCAF 인에이블된 카드 보유자 인터페이스 및 개인 카드 판독기를 이용하지 않았음을 나타낸다.
c) 만일 인증 요청이 UCAF 인증 데이터를 포함한다면, 카드 발행인은 AAV를 검정한다.
13. 발행인은 이전 단계의 결과에 기초하여 승인 또는 거절로 응답한다. 이 응답은 동일한 네트워크 시스템을 통하여 상점에 리턴되고, 상점은 그의 고객에게 적절히 응답할 것이다.
14. 그의 고객에 대한 상점의 응답은 임의의 적당한 포맷으로 될 수 있다. 예를 들면 온라인 인증을 위한 HTML 페이지 확인을 통하거나, 일괄 인증을 위한 이메일을 통할 수 있다.
칩-UCAF의 보안은 특정 보안 특징에 의지한다. 보다 구체적으로, 칩-UCAF는,
카드 보유자 존재의 증거와,
카드 보유자에 의한 거래 승인의 증거
를 확립하기 위하여 ICC에 의한 암호들, 즉 애플리케이션 요구 암호(ARQC) 또는 애플리케이션 인증 암호(AAC)의 생성에 의지한다.
또한, 그것은 진짜 거래의 재연(replay)에 대한 보호 및 위조 칩-UCAF 거래의 발생에 대한 보호를 제공한다. 그러므로, 적당한 보안 조치, 특히 PIN 보안에 관한 보안 조치와 관련하여 이용될 때, 칩-UCAF는 인터넷 거래에 대해 카드 보유자가 부인하지 않도록(non-repudiation) 하기 위하여 적당한 레벨의 보안을 제공한다.
칩-UCAF에 의해 제공된 보안 레벨의 평가는 이하의 가정들에 기초한다.
메인 카드 보유자 디바이스(MCD), 즉 실제 지불 동작을 수행하기 위해 카드 보유자가 사용하는 플랫폼은 신뢰되는 것으로 여겨진다. 이것은 PC 또는 이동 전화와 같은 물리적 디바이스에 적용되고, 챌린지를 생성하는 인터페이스 애플리케이션(IA)에 적용되고, 또한 개인 카드 판독기와 통신하는 애플리케이션에 적용된다. MCD의 비제어 특성 때문에, 이 가정은 임의의 유사 제품에 대해서 유효한 것으로 인지된다.
MCD에서 입력되어 상점에 송신되는 민감한 지불 세부사항, 예를 들면 PAN 또는 만료일자는 이 제품의 범위 밖에 있다. 이 데이터의 기밀성은 MCD와 상점 간의 링크의 암호화에 의해, 예를 들면, SSL 암호화에 의지함으로써, 그리고 상점 호스트 시스템 상에서 카드 세부사항의 보호에 의해 실시되어야 한다.
ICC는 검정, 예를 들면 오프라인 PIN 검정을 이용하여 카드 보유자 존재의 증거를 확립한다. 오프라인 PIN 검정은 ARQC의 생성 전에 요구된다. 그 결과, 유효 ARQC를 생성하기 위하여 카드 보유자 존재가 요구되고, 그러한 유효 암호의 존재는 이 카드 보유자 존재를 증명하기에 충분하다.
그러나, 이것은 오프라인 PIN 검정을 요구하지 않는 AAC의 생성에 해당되는 경우는 아니다. 카드 보유자 존재의 증거를 확립하기 위하여, 발행인은 챌린지 응답 내에 송신된 CVR에만 의지한다. 카드 검증 결과(CVR : Card Verification Results)는 카드로부터 송신되어 발행인이 카드 보유자 PIN이 그 카드에 의해 정확하게 검증되었는지 여부를 체크할 수 있게 하는 임의의 정보를 말한다. 송신 중에 CVR의 무결성(integrity)을 보호하는 것은 중요하다.
이 특성은 ICC가 AAC 계산 입력 데이터에 CVR을 포함시킬 때 보증된다. 그러나, 그러한 동작(behavior)은 준수 사양(mandatory)은 아니다. ARQC 또는 AAC 계산 입력 데이터에 CVR을 포함시키지 않는 ICC들이 PIN 없이 인터넷 거래에 이용될 수 있을 것임은 물론이다. 따라서, 그러한 ICC들은 바람직하게는 칩-UCAF 프로그램의 프레임에서 이용되지 않아야 한다.
칩-UCAF는 ARQC 또는 AAC 계산에 대한 입력으로서 거래 설명의 다이제스트를 이용한다. 이 다이제스트는 ARQC 또는 AAC 계산에 대한 입력 파라미터로부터의 UN 필드로서 이용된다. 발행인에 의한 암호의 성공적인 검정은 카드 보유자 존재의 증거와 결합되어 카드 보유자에 의한 거래의 승인에 대해 얼마간의 보증을 제공한다.
거래 설명이 실제로 고려되도록 보증하기 위하여, ARQC 또는 AAC 계산은 예측 불가능 수(UN)를 효과적으로 이용해야 한다. 그러나, 그러한 동작은 준수 사양은 아니다. 따라서, ARQC 또는 AAC 계산 입력 데이터에 UN을 포함시키지 않는 ICC들은 바람직하게는 칩-UCAF 프로그램의 프레임에서 이용되지 않아야 한다.
진짜 거래의 재연에 대한 보호를 확보하기 위하여, 다음 2개의 조건이 충족되어야 한다.
ICC로부터 수신된 ATC는 해당 특정 ICC에 대해 마지막으로 수신된 ATC와 대조되어야 한다. 이미 수신된 ATC를 이용한 거래는 폐기되어야 한다.
ICC에 의해 생성된 ARQC 또는 AAC는 ATC의 함수로서 변화해야 한다. 이것은 ARQC 또는 AAC 계산에 대한 입력 데이터에 ATC가 포함될 때만 해당되는 경우이다. 그러나, 그러한 동작은 준수 사양은 아니다. 그러므로, ARQC 또는 AAC 계산 입력 데이터에 ATC를 포함시키지 않는 ICC들은 바람직하게는 칩-UCAF 프로그램의 프레임에서 이용되지 않아야 한다.
개인 카드 판독기 디바이스의 사용과 관련된 주요 보안 이슈는 디바이스 자체에 의한, 카드 PIN 또는 ISO2 트랙과 같은 카드 저장 민감 정보의 폭로의 위험이다. 사기 또는 부정한 개인 카드 판독기들은 PIN 또는 ISO2 트랙의 기밀성을 위험에 빠뜨릴 수 있다. 위험의 정도는 디바이스의 타입에 따라 좌우된다.
비접속 개인 카드 판독기의 독립형 특징은 기밀 정보에 접근하기를 원하는 악의적인 일당이 이들 디바이스에 물리적으로 액세스할 것을 요구한다. 그러한 디바이스에서는 소규모의 공격만이 가능하고 따라서 그러한 공격의 충격은 낮을 것으로 기대된다.
단방향 또는 양방향 개인 카드 판독기는 물리적 접속의 존재 때문에 보다 많은 사기 행위 가능성을 제공한다. 그러한 디바이스에서는 대규모의 공격이 가능할 것이고 따라서 그러한 공격의 충격은 높을 것으로 기대된다.
통합 개인 카드 판독기는 외부 세계와의 투명한 통신의 관점에서 더욱 많은 융통성을 제공함으로써, 부가적인 사기(fraud) 가능성을 제공한다.
또한, ICC에 의해 리턴되는 ARQC 또는 AAC는 발행인에게 완전히 전송될 필요는 없다. 그것들은 IIPB에 의해 지정된 대로 절단(truncate)될 수 있고 따라서 IIPB는 ARQC 또는 AAC로부터의 특정 수의 비트, 예를 들면 적어도 16 비트가 개인 카드 판독기에 의해 리턴된 데이터 토큰에 포함되도록 정의되어야 한다. 절단된 암호의 축소된 사이즈 때문에, 사기 검출 시스템은 비정상적인 수의 실패 암호 검정을 검출하고 적절한 조치를 취할 수 있어야 한다.
ARQC 또는 AAC는 상점에 의해 제공된 정보에 기초하여 발행인에 의해 검정되어야 한다. 즉, 검정 처리 시에, 발행인은 카드 보유자 디바이스에 의해 제공된 챌린지에 의지하기보다는 최초 입력 데이터로부터 챌린지를 작성해야 한다. 이에 따라 본 발명에 따르면 특수 인증 토큰뿐만 아니라 상점으로부터 발행인에게 입력 데이터가 송신되어야 한다.
애플리케이션 암호(ARQC 또는 AAC)를 계산하는데 이용되는 카드는 그 계산에 대한 입력으로서 CVR을 이용해야 한다. 그렇게 하지 않는 카드들은 칩-UCAF 인증에 사용되지 않아야 한다. 애플리케이션 암호(ARQC 또는 AAC)를 계산하는데 이용되는 카드는 그 계산에 대한 입력으로서 UN을 이용해야 한다. 그렇게 하지 않는 카드들은 칩-UCAF 인증에 사용되지 않아야 한다. 애플리케이션 암호(ARQC 또는 AAC)를 계산하는데 이용되는 카드는 그 계산에 대한 입력으로서 ATC를 이용해야 한다. 그렇게 하지 않는 카드들은 칩-UCAF 인증에 재사용되지 않는다.
발행인들은 이상적으로는 사기 검출 시스템들을 이용하여 비정상적인 수의 실패 암호 제시를 검출하고 그에 대해 조치를 취한다.
발행인은 UCAF 자체 내의 카드 보유자의 소프트웨어에 의해 공급된 것에 의지하기보다는, 인증 메시지로부터 암호의 검정을 위한 챌린지 데이터를 재작성한다.
도 8은 본 발명의 일 실시예에 따른 상세 PCR 및 칩-UCAF 흐름을 도시한다. 이 도면 및 이하의 본문은 단지 본 발명의 일 실시예에 대해 설명하는 것으로, 상점이 UCAF 인증 페이지 상에 UCAF 상점 데이터를 공급하는 지점으로부터 시작하여 상점이 그들의 취득자로부터 인증 응답을 수신하는 지점까지, 칩 인증 프로그램에 연루된 단계들에 대해 설명하기 위한 것이다. 또한, 어떤 단계들의 특정 순서는 임의적이고 더 정확하게 말하자면 강제적인 것이 아니다. 단계 8에서의 카드 삽입을 예로 들 수 있다.
이 실시예의 목적을 위하여 메인 카드 보유자 디바이스는 표준 브라우저를 실행하는 PC이고 UCAF 상점 데이터는 숨은 HTML 서식 필드에 제시되는 것으로 가정한다. 이 실시예는 비접속 PCR이 사용되는 것을 가정한다. 비접속 또는 단방향 접속 디바이스가 카드 보유자에게 PIN 입력을 제외하고 어떤 데이터를 입력하도록프롬프트를 표시할 경우, 양방향 접속 또는 통합 디바이스는 카드 보유자 IA에게 동일 데이터 요소를 전달할 것을 요청해야 한다. 그러나 이 통신 프로토콜의 정확한 역학(mechanics)은 어느 실시예에 대해서도 독점적이다.
상점으로부터 카드 보유자에게로의 인증의 확인은 본 발명에서 배제되지 않는다.
도 8에서는 상점이 PAN, 만료일자 등을 포함하여 지불 세부사항들을 이미 수집하였고 주문 처리 파이프라인 내의 단계 -여기서 UCAF 인증 페이지를 통하여 주문 및 지불 세부사항들이 완성(finalize)됨- 에 있다고 가정한다. 카드 보유자는 PAN의 세부사항들을 이용해 그의 카드 보유자 IA를 이미 개인화(personalize)하였고, 따라서 이 지불에 이용되는 PAN의 마지막 다섯 숫자가 UCAF 필드 내에 제시되면, 카드 보유자 IA는 그것이 해당 PAN을 위해서 조치를 취할 수 있는지를 인지할 수 있다.
도 8의 번호 매김과 관련하여:
1. 거래 데이터 대조 - 상점은 UCAF 명세에 따라서 요구되는 거래 관련 데이터를 대조하다.
2. 거래 데이터 송신 - 상점은 주어진 전자 상거래 채널에 대해 UCAF 명세에 정의된 대로, 그 채널에 대해 정의된 메커니즘을 통하여 거래 데이터를 송신한다.
3. UCAF 필드 검출 - 메인 카드 보유자 디바이스(MCD) 상에 설치된 인터페이스 애플리케이션(IA)은, UCAF 숨은 필드들의 존재를 검출하고, 상점에 의해 공급된 수, 예를 들면 마지막 5(다섯) PAN 숫자들이 IA에게 이미 알려져 있는 PAN에 관계되는지를 결정하고, 나머지 UCAF 데이터를 검정하여 바로 그것을 제시한다.
4. 거래 데이터 표시 - IA는 그것의 사용자 인터페이스를 통하여 카드 보유자에게 거래 관련 데이터를 표시한다. 카드 보유자는 이 시점에서 거래를 거절하기로 결정할 수 있다.
5. 카드 세부사항 확인 - 인터페이스 애플리케이션은 카드 보유자에게 그가 선택한 카드 세부사항이 정확한지 확인하도록 요청할 수 있다. 이것은, 예를 들면, 카드 보유자에게 PCR에서 어느 카드를 물리적으로 사용할지를 상기시키는 형식을 취할 수 있다(예를 들면 아마도 카드 보유자가 카드 세부사항을 이용하여 카드 보유자 IA를 개인화할 때 그 특정 카드와 관련시킨 '친숙한'(friendly) 식별자를 통하여).
6. 챌린지 생성 - 인터페이스 애플리케이션은 어떤 거래 데이터 + PAN으로부터 PCR 챌린지가 생성되게 한다.
7. PCR 챌린지 표시 - 비접속 또는 단방향 접속 디바이스를 위하여, 인터페이스 애플리케이션은, 카드 보유자에 의해 PCR에 입력되어야 하는, 챌린지를 표시한다.
8. 카드 삽입 - 카드 보유자는 ICC(5)를 PCR에 삽입한다.
9. PCR 챌린지 전송 - PCR 챌린지가 PCR에 전송된다. 비접속 또는 단방향 접속 디바이스를 위하여, 카드 보유자는 인터페이스 애플리케이션 및 PCR 자체로부터의 프롬프트에 응답하여 PCR에 챌린지를 입력함으로써 이것을 행한다. 다르게는그것이 PCR에 송신될 수도 있다.
10. 선택 사양 : 양(Amount) 전송 - 인증 방식이 양 또는 통화를 요구할 경우, 그 양은 PCR에 전송된다. 비접속 또는 단방향 접속 디바이스를 위하여, 카드 보유자는 PCR로부터의 프롬프트에 응답하여 PCR에 거래량을 입력함으로써 전송을 행한다. 다르게는 그것이 PCR에 송신될 수도 있다.
11. PIN 입력 - 카드 보유자는 인터페이스 애플리케이션 및/또는 PCR 자체로부터의 프롬프트에 응답하여 PCR 또는 MCD에서 PIN과 같은 보안 또는 검정 코드를 입력한다.
12. UN 생성 - PCR은 예측 불가능 수를 생성한다.
13. AC 생성 - PCR은 AC 커맨드를 생성하여 그것을 카드에 송신한다.
14. AC를 포함하는 응답 - 카드는 PCR에 대한 응답으로서 다른 데이터 중에서 AC를 리턴한다.
15. PCR 토큰 생성 - PCR은 IIPB에서 확인된 발행인 명세서에 기초하여 응답을 '분해'(strip down)하여 PCR 토큰을 생성한다.
16. PCR 토큰 표시 - PCR은 카드 보유자에게 십진수 토큰을 표시한다.
17. PCR 토큰 전송 - PCR로부터 PCR 토큰이 전송된다. 비접속 디바이스를 위하여, 카드 보유자는 PCR 상의 디스플레이 및 인터페이스 애플리케이션으로부터의 프롬프트에 응답하여 인터페이스 애플리케이션에 PCR 토큰을 입력함으로써 이것을 행한다. 다르게는 그것이 자동으로 송신될 수도 있다.
18. UCAF 인코딩 - 인터페이스 애플리케이션은 칩-UCAF 구조를 인코딩하고,UCAF 제어 바이트를 설정한 다음 UCAF 내에 송신하기 위해 그것을 기수 64 인코딩한다.
19. UCAF 리턴 - 인터페이스 애플리케이션은 각종 리턴 데이터 항목들을 상점 지불 요청 통신 내에 코드화한다.
20. 인증 요청 작성 - 상점은 상점에게 리턴된 숨은 필드들 내에서 IA에 의해 공급된 데이터를 추출하여 그들의 취득자에게로의 독점적 인증 요청을 작성한다.
21. 인증 요청 - 상점은 UCAF를 포함하는 인증 데이터를 그들의 취득자에게 전달하고, 취득자는 그것을 적당한 발행인에게 전달한다.
22. SLI 설정 - 취득자는 그 인증 거래에 적당하게 보안 레벨 지시자(SLI : Security Level Indicator)를 설정한다.
23. ISO 8583-0100 - 취득자는 발행인에게 인증 요청을 전송하고, 발행인은 그 메시지에 대해 어떤 초기의 표준 처리를 수행한다.
24. UCAF 처리 - 발행인은 UCAF의 존재를 체크한다.
25. 선택 사양 : 챌린지 재작성 - 예측 불가능 수가 재생성될 수 있도록 메시지 데이터로부터 PCR에게로의 챌린지가 재작성된다.
26. 카드 데이터 검색 - 발행인은 재작성할 수 있기 위하여 ICC 데이터베이스로부터 특정 데이터 요소들을 검색해야 한다.
27. 재작성 - PCR 토큰은 PCR에 의해 이용되는 알고리즘의 지식에 기초하여 발행인에 의해 생성된다.
28. 비교 - 발행인은 인증 메시지 내의 축소된 PCR 토큰과 입력 데이터로부터 생성된 PCR 토큰을 비교한다. 이것은 '보안 상자'(security box)로의 변화를 수반할 수 있고, 이 보안 상자에서 비교를 행한다.
29. ISO 8583-0110 - 발행인은 취득자에게 인증 요청 응답을 송신한다.
30. 인증 응답 - 발행인은 취득자를 경유하여 상점에게 인증 응답을 리턴한다.
단계 1 내지 21은 이런 방식에 특유하다.
상점은 특정한 포맷(particular, specified format)으로 거래 데이터를 대조 및 제시함.
카드 보유자의 메인 액세스 디바이스, 카드 보유자 인터페이스 애플리케이션, PCR 및 카드 보유자는 자체적으로 PCR 토큰을 생성시켜 상점에 리턴되게 함.
상점 기존의 취득자 통신 내에 새로운 데이터를 전달함.
단계 22는 UCAF 데이터를 처리할 때 취득자가 취해야 하는 별도의 단계들을 나타낸다.
취득자는 상점에 의해 공급된 데이터에 의존하여 보안 레벨 지시자를 설정할 책임이 있다.
단계 23은 ISO 8583-0100 인증 요청 메시지를 통하여, 취득자에게로 그런 다음 발행인에게로의 지불 데이터를 송신하는 기존의 송신에 대한 요약이다.
0100 메시지를 수신하면 발행인은 UCAF 내에 임의의 데이터가 있는지를 결정하는 작은 단계를 수행해야 하고 그것을 적당히 처리한다.
단계 24 내지 28은 이런 방식에 특유하다.
발행인은 UCAF로부터 데이터를 추출하고 PCR 인증 토큰을 검증한다.
단계 29 및 30은 상점에 대한 기존의 ISO 8583-0110 인증 요청 응답 메시지 및 응답의 요약이다.
PCR 토큰이 유효하다는 것을 확신한 발행인은 취득자를 경유하여 상점에게 0110 메시지를 리턴한다.
이 상세 흐름도 및 설명은 관련된 전자 상거래 채널과 무관한 해법을 보여준다. 단계 2 및 19, 인터페이스 애플리케이션과 상점 시스템들 간의 링크는 주어진 전자 상거래 채널에 대한 명세에 대해 의존성이 있는 포인트들이다.
본 발명의 일 양태에 따르면 상이한 채널들이 사용될 수 있고 인터페이스 애플리케이션 형태의 상이한 발행인 소프트웨어를 필요로 하고, 아마도 상이하면서도 반드시 표준화된 상점 상호작용, 예를 들면, HTML 서식, XML 데이터 교환 등을 필요로 할 것이다. 그러나, 데이터 내용, 알고리즘 및 흐름은 상이한 채널들에 대해서 동일하게 유지된다.
상기 방식에서 상점은 그들 자신과 거래에 대한 세부사항들을 공급한다.
요컨대 이들 데이터 요소들은 다음으로부터 선택된다.
상점 이름
상점 도시
상점 주/국가 코드
통화 코드
판매량
상점 거래 스탬프
UCAF 브랜드
지불 카드 번호(마지막 다섯 숫자)
본 발명에 따른 방법들에서 이용될 수 있는 하나의 카드 고유 데이터는 발행인 인터넷 소유 데이터(IIPD : Issuer Internet Proprietary Data)이다. 발행인 인터넷 소유 데이터(IIPD)는 카드 상의 그것의 존재가 선택적(optional)인 데이터 객체이다. 그것은 유사하게 명명된 발행인 인터넷 사유 비트맵(IIPB)과는 칩 인증 프로그램에 기인하여 도입된 것 외에는 관계가 없다. 그것은 명목상 인터넷 환경에서 사용될 때 암호의 생성과 관련하여 발행인이 독점적 방식으로 사용하려고 하는 데이터를 포함하지만, 그것은 다른 또는 대체 데이터를 전송할 수도 있다. 예를 들면, 카드 일련 번호(CSN : Card Sequence Number)를 발행인에게 전송하는 것이 요구될 수 있다. 이것은 주어진 카드에 대해 정적(static)이고 그것을 IIPD에 인코딩함으로써 발행인에게 전달될 수 있다. 이 CSN은 제1 IAF '바이트'의 하위 니블에서 전달될 수 있다. 이 기법은 카드 보유자 데이터 입력 부담을 덜어준다. 그것의 사용은 글자 그대로 발행인에게 독점적이다.
IIPD의 제1 바이트는 개인 카드 판독기(PCR)에 의해 주로 이용되는 일반적 플래그(generic flags)의 세트를 지닌다. 표 1은 이들에 대한 개략적 표시를 제공한다.
IIPD 플래그 바이트 설정
비트 설명 1로 설정 0으로 설정 디폴트
8 양 및 통화 표시자 AC 생성 시에 양 및 통화가 명시적으로 사용됨 AC 생성 시에 양 및 통화가 사용되지 않아서 디폴트 값이 사용됨 0
7 암호 타입 제1 GenerateAC에서 요청된 ARQC 제1 GenerateAC에서 요청된 AAC 1
6 내지 1 미사용 N/A N/A 0
비트 8이 1로 설정되면, 그것은 발행인이 AC를 생성할 때 거래량 및 통화가 이용되어야 함을 요구한다는 것을 의미한다. PCR에게는 이것은 PCR이 카드 보유자/메인 카드 보유자 액세스 디바이스(MCD)에게 통화 및 양을 공급하도록 프롬프트(prompts)/요청하는 것을 의미하고 인터페이스 애플리케이션(IA)에게는 그 양 및 통화가 공급될 필요가 있다는 것을 의미한다. 비트 8이 0으로 설정되면, AC를 생성할 때 양(0) 및 통화(999 - 아무런 통화도 관련되지 않은 거래에 사용되는 코드)에 대한 디폴트 값들이 사용될 것이다. 비트 7이 1로 설정되면, 그것은 발행인이 카드로부터 요청될 암호의 타입이 ARQC일 것을 요구한다는 것을 의미한다. 비트 7이 0으로 설정되면, 그것은 발행인이 카드로부터 요청될 암호의 타입이 AAC일 것을 요구한다는 것을 의미한다. 제1 바이트를 넘어서는 IIPD 데이터는 발행인에게 독점적인 용도를 위하여 자유롭다.
IIPD의 내용은 인터넷 관련 사용을 위한 암호를 생성하기 위하여 주어진 칩 구현에 의해 요구되지 않을 수 있기 때문에 IIPD는 선택적(optional) 구조이다. 그러나, 그것은 PCR에게 어떻게 처리를 진행할지에 대해 지시하는 지시자들을 포함하기 때문에, 만일 그것이 존재하지 않으면 PCR은 디폴트 설정에 의지해야 한다. 만일 카드가 IIPD를 갖지 않으면, 예를 들면, "거래량과 통화가 없고, ARQC가 생성될 것임"이라는 0x40의 디폴트 값이 사용될 수 있다.
IIPD는 계좌 보유자 인증 값(AAV)으로 발행인에게 송신되어야 한다. 그러나 그것은 PCR에 의해 카드 보유자 인터페이스 애플리케이션(IA)에 전송되지 않는 것이 바람직하다. 왜냐하면 그럴 경우 비접속 디바이스들에서는 카드 보유자에게 너무 많은 데이터 전송 부담을 지우게 될 것이기 때문이다. IIPD는 주어진 카드에 대해 정적이기 때문에, 그것은 PAN 및 다른 정적(static) 카드 데이터가 카드 보유자 IA에 공급되는 것과 같은 방식으로 카드 보유자 IA에 공급될 수 있다.
또한, 카드 보유자 IA는 통화 및 양이 PCR에 전송될 필요가 있는지 여부를 결정하기 위하여 IIPD를 알아야 하고, 그렇지 않으면 디폴트 값, 예를 들면 0x40을 사용해야 한다. 통화 정보는 PCR 챌린지의 일부로서 전송될 수 있다.
UCAF 준수(compliance)에 의해 부과되는 데이터 공간 제한과, 또한 적어도 일부 발행인들이 비접속 또는 단방향 접속 디바이스를 사용해야 하는 필요성 때문에, 디바이스가 MCD에 역으로 전송해야 하는 데이터는 사이즈 제한된다. 그러므로, AC를 다시 계산하기 위하여 발행인에 의해 요구되는 데이터의 선택된 부분만 전송되는 것이 바람직하다.
제1 GenerateAC(AC 생성) 커맨드에 대한 ICC에 의한 응답은 다음 요소들로 이루어진다.
암호 정보 데이터(CID)
애플리케이션 거래 카운터(ATC)
ICC(AC)에 의해 계산된 암호
발행인 애플리케이션 데이터(IAD)
그것들은 다음 중 어느 하나인 데이터를 포함한다.
이 거래에 고유하고, 카드 보유자에 의해 PCR로부터 카드 보유자 디바이스로 전송되어야 하는 데이터.
이 특정 방식에 대해 특정 값들인 것으로 가정되어 카드 보유자에 의해 PCR로부터 카드 보유자 디바이스로 전송될 필요가 없는 데이터.
이 거래 또는 ICC에 고유하고, 알려져 있거나 또는 적어도 발행인 호스트가 그것의 카드 데이터베이스를 통하여 추론할 수 있어서 카드 보유자에 의해 PCR로부터 카드 보유자 디바이스로 전송될 필요가 없는 데이터.
발행인 인터넷 사유 비트맵(IIPB)은 카드 상의 그것의 존재가 선택적(optional)인 데이터 객체이다. 이 데이터는 GenerateAC 응답 내의 어느 비트들이 발행인 호스트 시스템에 의해 요구되는지를 나타내는 송신 플래그들로 이루어진다. 이 플래그들은 비트 대 비트를 토대로(on a bit for bit basis) CID(예를 들면, 1 바이트), ATC(예를 들면, 2 바이트), AC(예를 들면, 8 바이트) 및 IAD(예를 들면, 0-32 바이트)(도 9 참조)로부터 송신되어야 하는 비트들에 대응한다. IIPB는 예를 들어 11 바이트(이 경우 아무런 IAD도 정의되지 않음)로부터 43 바이트(이 경우 발행인의 애플리케이션 기술이 발행인 애플리케이션 데이터(IAD)에 대해 이용할 수 있는 최대 32 바이트를 사용함)까지 길이가 변할 수 있다.
IIPB는 발행인이 인증을 검정할 목적으로 이들 값 중 어느 비트 또는 얼마나 많은 비트를 사용할 것인지에 대해 발행인이 전적으로 선택할 수 있게 한다. 따라서 PCR 자체가 어느 특정 카드 기술을 알아야 할, 그래서 그 특정 카드 기술에 특유해야 할 필요성이 제거된다. IIPB는 PCR이 카드 보유자 IA에 의해 AAV에 통합되어 발행인에게 전달될 토큰을 작성할 수 있게 하는 비트 마스크로서 이용될 수 있다.
발행인은 그들이 암호를 검증하기 위해 필요로 할 최소 가능 비트들을 표시(mark)할 IIPB를 정의할 수 있다. 필요한 것으로 표시된 비트 수는 PCR에 의해 생성되는 데이터 토큰의 잠재적 사이즈를 결정한다.
새로운 IIPB를 갖지 않는 기존의 카드들과 주로 관련된 목적을 위하여, IIPB는 선택적(optional) 구조이다. 그러나, 그것은 PCR이 추출하고 압축해야 하는 비트들을 식별하는 데 이용되기 때문에, 만일 그것이 존재하지 않는다면 PCR은 디폴트 설정에 의지해야 한다. 디폴트 IIPB는 예를 들면 19 바이트 구조일 수 있다. 이 결과 35 비트의 데이터가 발행인에게 송신되고 PCR의 디스플레이 상에 그것을 표현하기 위해 11개의 십진 숫자가 필요하다. 최종 검사 숫자 상에 디폴트 IIPB를 부가하면 카드 보유자에 의해 12개의 숫자 토큰이 입력될 것이다.
발행인들은 애플리케이션 기술에 적당하게 IIPB를 특정할 수 있다. 그후 이 IIPB는 PCR이 PCR에 저장된 디폴트 IIPB보다는 카드에 저장된 IIPB를 이용하도록 하기 위하여 해당 애플리케이션에 대한 개인화 명세서(personalization specifications)에 포함될 필요가 있을 것이다.
만일 발행인이 그들의 발행 카드들과 토큰을 생성하는데 이용되는 PCR과의 사이에 일대일 매치가 되는 것을 마음에 들어 하거나 또는 그것을 필요로 한다면, 그들은 그들의 특정 판독기 내의 디폴트 IIPB를 변경할 수 있다. 이것은 IIPB가 카드에 저장되어야 할 필요가 없다는 것을 의미할 것이다. 그러나, 그러한 카드들은 디폴트 IIPB를 사용하는 PCR들에서는 사용될 수 없을 것이다.
카드 보유자의 브라우저로부터 상점에 송신되는 데이터는 각각의 브라우저 채널에 대한 UCAF 인증 데이터 필드만으로 이루어질 수 있다.
UCAF는 24 바이트 사용자 인증 토큰을 포함할 수 있다. 이들 24 바이트는 바람직하게는 카드 보유자 IA에 의해 인코딩되어, 예를 들어 기수 64 인코딩되어 상점에게 리턴되는 32개 ASCII(아스키) 문자의 데이터를 제공한다. 상점은 취득자와의 독점적 통신에서 그 UCAF 데이터를 전달하고 그후 취득자는 그 UCAF를 발행인에게 송신되는 인증 요청 메시지에 넣을 수 있다. UCAF의 일반적 구조가 도 10에 예시되어 있다.
UCAF 제어 바이트는 1 바이트 값으로, UCAF가 무슨 타입의 데이터를 전송하는데 이용되는지를 나타낸다. 다음 값들은 UCAF 제어 바이트 인코딩에 이용될 수 있다.
0x82와 같은 제1 값 - 지갑 서버(wallet server)를 이용하는 SPA-UCAF
0x88과 같은 제1 값 - ICC를 이용하는 칩-UCAF
사전 거절 때문에 또는 분할 발송(split shipments)을 위하여 상점이 인증을 재송신할 필요가 있을 때, UCAF 제어 바이트의 최상위 비트는 클리어되어 다음 값들이 되어야 한다.
0x02와 같은 제3 값 - 지갑 서버를 이용하는 후속 SPA-UCAF 인증
0x08과 같은 제4 값 - 칩을 이용하는 후속 칩-UCAF 인증
본 발명은 생체 인증(biometrics)과 같은 다른 인증 기법들을 포함하고, 그 경우 그 특정 기법은 그 자신의 제어 바이트 값을 할당할 것이고 특정 용도 데이터(Application-Specific Date)의 구조는 생체 인식 인증 접근법을 지원하도록 맞추어질 것이다. 이 경우, 모든 생체 인식 인증 애플리케이션들은 일관된 특정 용도 데이터 구조를 이용해야 한다.
계좌 보유자 인증 값(AAV)이 도 11에 개략적으로 도시되어 있다.
다음 데이터가 UCAF 내의 발행인에게 전송된다.
IIPD - 선택적(optional)이고, 길이가 가변적이지만 항상 다수의 바이트임. 그것은 카드 일련 번호, 예를 들면 해당 카드에 대한 IIPD 내의 발행인 정의 위치에 배치될 발행인에 의해 정의된 4 비트.
예측 불가능 수, 예를 들면 길이가 32 비트(4 바이트).
PCR 토큰 내에 인코딩된 IIPB 데이터 토큰 -IIPB에 의해 정의되는 미지의 길이, 수의 비트들.
길이는 예를 들어 184 이하와 같이 제1 최대수로 제한되는 것이 바람직하다. 왜냐하면 이상적으로 발행인은, IIPD와 결합될 때 전송될 필요가 있는 제2 최대수의 비트들, 예를 들어 152 비트(최대 데이터 영역 - 길이(UN))보다 크게 될 수 있는 IIPB를 공급하지 않아야 한다. 예방 조치로서, 카드 보유자 IA는 결과적으로제1 최대수보다 크게 될, 즉 > 184 비트가 될 어떠한 연산이든 에러로 귀착되어 그 데이터는 인코딩되지 않게 확실히 보증할 수 있다.
임의의 IIPD 데이터가 존재하는지 여부를 표시하기 위해 칩-UCAF에 대한 AAV의 인코딩 내에 작성된 어떤 표시가 있을 필요가 없다. 발행인이 그들의 호스트 시스템이 AAV에서 무엇을 기대할지를 아는 것을 보증하는 것은 발행인의 몫이다. 카드 보유자 IA에 의한 임의의 IIPD의 인코딩 포함은 임의의 IIPD가 특정 거래에 대해 카드 보유자에 의해 사용된 지불 카드와 관련 있는지 여부에 달려 있다.
칩-UCAF에 대한 AAV 내에 인코딩된 UN은 최대 4 바이트 사이즈이고, 이것은 GenerateAC 커맨드에서 ICC에 송신된 UN과 동일한 사이즈이다. UN의 크기는 그 최대 범위 내에서 변경될 수 있다. 예를 들면, 데이터 전송 포맷에 영향을 미치지 않고 증가되거나 또는 감소될 수도 있다.
UN 범위 제한은 MCD로부터 PCR로 데이터를 전송하기 위해 카드 보유자가 입력하도록 요구되는 숫자의 수를 제한한 결과일 수 있다. 호환성 이유 때문에 이 제한은 PCR에게 제시된 PCR 챌린지의 사이즈에 대한 다른 표시가 없는 한은 접속 및 비접속 디바이스들 모두에게 적용될 수 있다.
발행인은 IIPD 및 IIPB 데이터 토큰 양쪽 모두의 길이를 안다. 카드 보유자 IA는 IIPD의 길이를 알지만, IIPB 데이터 토큰의 길이는 모르므로 그것은 바람직하게는 그 비트들을 우측 정렬해야 한다. 즉, 도 12에 도시된 바와 같이 0 필러를 이용하여 최하위 비트가 마지막 비트 위치에 나타난다. 그 결과, 0으로 설정됨에 따라서 수치 토큰 유도에서 나타나지 않았기 때문에 PCR 토큰에서 전달되지 않은임의의 좌측 정렬 IIPB 데이터 토큰 데이터는 그것이 나타낸 0의 값으로 설정될 것이다. 이것은 카드 보유자 IA가 먼저 AAV의 전체 23 바이트를 0으로 함에 따라서 전송된 PCR 토큰의 최좌측 설정 비트로부터 뒤로 UN까지 모든 남아 있는 비트들이 0의 설정을 갖는 결과가 초래될 것이기 때문이다. 이들 비트 중 일부는 IIPB 데이터 토큰에서 그들이 갖는 0의 값을 나타내겠지만 나머지는 단지 0 필러(filler)일 것이다.
카드 보유자 IA는 어느 비트들이 0으로 설정된 데이터를 나타내고 어느 필러가 또한 0으로 설정되는지를 모르겠지만, 그것은 문제가 되지 않는다. 왜냐하면 발행자는 IIPB의 유효 길이를 알기 때문에 어느 비트들이 데이터인지를 알 것이기 때문이다.
상점와 취득자 사이의 링크는 독점적일 수 있지만, 상점은 바람직하게는 다음의 부가적인 데이터를 취득자에게 전송해야 한다.
UCAF 인증 데이터 필드
에러 상태 지시자
발행인은 취득자로부터 인증 네트워크를 통하여 인증 요청 메시지를 수신한다. 그것은 수정된 보안 레벨 지시자(SLI : Security Level Indicator) 및 UCAF 인증 데이터 외에 표준 인증 데이터를 포함할 것이다. 인증 요청 메시지는 UCAF 거래에서 사용하기 위해 확장된 SLI를 포함한다.
카드 보유자 데이터 입력의 정확도를 향상시키기 위하여 단일 후미 검사 숫자(single trailing check digit)가 사용될 수 있다. 부가 숫자를 입력하는 불편함보다는 이 여분의 숫자가 주는 검정 체크(validation check)의 값이 더 중요하다. 이 검사 숫자에 이용되는 알고리즘은 PAN을 검정하는 데 이용된 "모듈러스 10"(Modulus 10)으로도 알려져 있는 "룬 공식"(Luhn Formula)과 같은 임의의 적당한 체크 알고리즘일 수 있다. 이 검사 숫자는 n-숫자 PCR 챌린지에 적용될 수 있다. 예를 들면, 카드 보유자에게 어느 일정한 수의 숫자들, 예를 들면 7-숫자 챌린지에 대해 8개 숫자를 입력하도록 요구하는 것에 적용될 수 있다. 개인 카드 판독기는 이 검사 숫자를 검정하고 카드 보유자에게 언제 부정확한 값이 입력되는지를 알려준다. 만일 결합된 UN/통화(Currency) 수가 사용되면, 검사 숫자는 완전한 '수'(number)에 적용될 것이다. 만일 부정확한 값이 입력되면, 디바이스는 바람직하게는 처리를 포기하거나 재개(restart)하지 않고 PCR 챌린지가 다시 입력되는 것을 기다리거나 다시 입력되도록 프롬프트(prompt)한다. 원한다면 무효 PCR 챌린지 입력 시도의 수에 제한이 가해질 수도 있고 제한이 가해지지 않을 수도 있다.
비접속 디바이스의 경우, 이 검사 숫자는 바람직하게는 표시된 n-숫자 PCR 토큰에 적용된다. 예를 들면, 카드 보유자에게 12-숫자 PCR 토큰에 대해 13개 숫자와 같은 어느 일정한 수의 숫자들을 입력하도록 요구하는 것에 적용된다. 개인 카드 판독기는 이 검사 숫자를 계산하고 그것을 표시된 PCR 토큰의 말미에 적용할 것이다.
단반향 접속 디바이스의 경우에도, 이 검사 숫자는 적용되어야 한다. 왜냐하면 단방향 통신은 데이터 전송의 핸드셰이킹 검증(handshaking verification)을 허용하지 않기 때문이다. 카드 보유자 IA는 이들 디바이스에 대한 검사 숫자를 검증하고 에러가 검출되면 그 에러를 카드 보유자에게 보고해야 한다. 이 결과 PCR에 의한 거래가 반복될 필요가 있을 것이다.
검사 숫자는 송신 매체 에러 검출 메커니즘이다. MCD와 양방향 접속/통합 디바이스 사이의 어느 방향으로의 통신에 대해서든, 하위(underlying) 전송 프로토콜은 전송에 관한 에러들만 정정할 수도 있다.
PCR 챌린지는 발행인에게 전달된다. PCR 챌린지는 예를 들면 GenerateAC 커맨드에서 거래량이 요구되는지 여부에 따라서 하나 또는 그 이상의 부분들, 예를 들면 2개 또는 3개 부분들로 이루어진다.
예측 불가능 수(UN)
선택적 통화 코드
상기 언급한 룬 검사 숫자와 같은 하나 또는 그 이상의 검사 숫자
PCR 챌린지는 예측 불가능 수(UN)를 생성하는 데 이용된다. UN은 카드 보유자 IA로부터 얻어진 값을 포함하여, 전체 32 비트 구조로서 공급될 수 있다. 이 값의 범위는 제한되는 것이 바람직하다. 이 범위의 크기는 카드 보유자가 비접속 디바이스 내로 키 입력(key into)하는 것이 허용될 수 있다고 생각되는 최대 수의 숫자들에 의해 결정될 수 있다. '예측 불가능'(unpredictable)이라는 용어는 그 수가 ICC에게 예측 불가능하다는 사실을 말하는 것이지, ICC에 또는 카드의 외부에 있는 다른 엔티티에 그 값을 공급하는 애플리케이션에게 예측 불가능하다는 것은 아니다.
PCR 챌린지는 바람직하게는 PCR에 전송되어야 하는 어느 일정한 수의 숫자들을 갖는 십진수이다. UN과 마찬가지로, 그것도 부가적인 후미 검사 숫자 및 선택적 통화 코드로 이루어질 수 있다. 따라서 카드 보유자가 수동으로 챌린지를 전송하는 비접속 또는 단방향 접속 디바이스의 경우, 입력할 숫자의 수는 카드 보유자 편의, 아니 더 정확히 말한다면 불편의 문제이다. 다른 타입의 접속 디바이스들의 경우 챌린지는 직접 전달될 수 있으므로 사용되는 숫자의 수는 문제가 아니다. 그러나, 발행자는 특정 거래에 대해 카드 보유자에 의해 사용되는 디바이스의 타입을 알지 못할 것이고 그래야 하기 때문에, 상호 운용성(interoperability)의 이유로, 모든 카드 보유자 IA들은 UN의 가능 범위를 나타내기 위해 동일한 최대수의 숫자들을 사용하는 것이 바람직하다.
숫자들의 수는 예를 들어 8까지 제한될 수 있다. PCR은, PCR 챌린지의 UN 부분이 단순히 32 비트 UN 구조에 맞출 수 있어야 하는 값이기 때문에, 이 '제한'(restriction)을 알지 못할 수 있다.
발행인이 PCR이 (예를 들어 IIPD의 바이트 1에서의 IAF 플래그 설정에 의해 지시되는 바와 같이) AC를 생성하는 데 이용되는 GenerateAC 커맨드에 양 및 통화를 통합할 것을 요구하는 방식에서는, PCR은 양 및 통화가 그것에 전송되는 것을 필요로 할 수 있다. 비접속 또는 단방향 접속 디바이스에 3-숫자 통화 코드를 전송할 때 일어날 수 있는 카드 보유자에 대한 혼란을 줄이기 위하여, 코드는 챌린지 내에 전달된 UN의 말미 상에 통합될 수 있다. 따라서, 검사 숫자를 고려할 때, 카드 보유자는 그 방식이 양 입력을 요구할 때 총 12-숫자 챌린지를 입력한다.
요컨대 PCR 챌린지의 소스들은 다음이 될 수 있다.
거래량
거래 통화
상점 이름
PAN
PCR 챌린지를 생성하는 데 이용되는 메커니즘은 상호 운용 가능해야 한다. 왜냐하면 발행인은 소스 데이터와 대비하여 UN의 유효성이 체크되는 호스트 시스템에 대해 동일한 동작들을 재연할 필요가 있을 것이기 때문이다.
UCAF 데이터 필드들 내에 상점에 의해 공급되고, 카드 보유자에게 표시된 양은 바람직하게는 인코딩(예를 들면, BCD 인코딩)되고, 우측 정렬되고 0이 채워져서 6 바이트로 된다.
UCAF 데이터 필드들 내에 상점에 의해 공급되고, 카드 보유자에게 알파벳 코드를 표시하기 위하여 통화 검색(currency lookup)에서 사용된 통화는 바람직하게는 인코딩(예를 들면, BCD 인코딩)되고, 우측 정렬되고 0이 채워져서 2 바이트로 된다.
거래량 및 통화는 바람직하게는 양 및 통화를 이용하기 위한 IAF 설정(비트 8)에 상관없이 PCR 챌린지의 예측 불가능 수 부분의 계산에 항상 이용된다. 해당 플래그는 양 및 통화가 암호 계산에서 부가적으로 그리고 명시적으로 이용되는지 여부를 결정하고 챌린지와 관련해서는 단지 그 챌린지가 카드 보유자 IA로부터 비접속 개인 카드 판독기로의 통화 코드에 대한 전송 메커니즘으로서 이용되는지 여부에 영향을 미친다.
UCAF 데이터 필드 내에 상점에 의해 공급되고, 카드 보유자에게 표시된 상점 이름은 상점으로부터 수신된 22개의 유니코드 2-바이트 문자들로부터 22개의 1-바이트 ASCII(아스키) 문자들로 변환된다. 이것은 각각의 '홀수' 바이트 - 22개의 2-바이트 유니코드 시퀀스들 각각에서 제1 바이트 - 를 제거함으로써 행해질 수 있다.
PAN은 가장 적은 수의 바이트들로 인코딩(예를 들면, BCD 인코딩)되어야 하고, 홀수 개수의 PAN 숫자들, 예들 들면 19-숫자 마에스트로(Maestro) PAN이 공급되는 경우, 그것은 우측 정렬되고 0이 채워져야 한다. 챌린지 생성 시 PAN을 포함할 경우 카드 보유자 IA는 이 거래에 대해 카드 보유자에 의해 이용되는 전체 PAN을 알아야 한다.
양, 통화, 이름 및 PAN으로부터 형성된 38 또는 40 바이트의 연결된 입력 데이터에 대해 적당한 암호화 알고리즘, 예를 들면 SHA-1 해시 알고리즘이 적용된다. 그 결과로서의 20-바이트 해시 데이터 구조의 처음 4 바이트는 '추출'(extract)되어 32 비트 부호 없는 정수 값으로 취급된다. 그후 이 값에 100,000,000의 모듈러스가 적용되어 99,999,999까지의 범위 내의 값을 얻게 된다. 만일 통화 코드가 송신되어야 한다면 그것은 이때 부가된다. 마지막으로 룬 검사 숫자와 같은 검사 비트가 지금까지 계산된 숫자들에 적용되어 그 말미에 부가되어 챌린지를 생성하게 된다. 전체 처리 흐름은 도 13에 도시되어 있다.
PCR 챌린지는 선택적(optional)으로 8개 숫자까지 0이 채워지는 수(number)로서 전달될 것이다. 이 0 채우기(zero padding)는 선택적(optional)이다. 왜냐하면 PCR은 PCR 챌린지에 대한 고정된 수의 숫자들에 의지하는 것이 아니라, 그보다는 PCR 챌린지 입력의 끝을 표시하기 위해 OK/엔터(Enter) 버튼을 이용하기 때문이다. 이 수에 선택적 통화 코드 및 계산된 검사 숫자가 부가될 수 있다.
이 전송 포맷은 이상적으로는 디바이스들 간의 논리적 차이를 가능한 한 작게(이상적으로는 통신 프로토콜 자체만 다르게) 유지하기 위하여 모든 타입의 디바이스에 대해 사용되어야 한다. 이것은 챌린지 데이터를 어느 한쪽의 타입의 디바이스에 전달하는 것 사이의 차이가 순전히 통신/전송 메커니즘에 있는 것이지 해당 데이터의 처리에 있지 않다는 것을 의미한다.
챌린지는 AAV 내에 전달되기 때문에, 발행인 호스트를 위한 가능한 최적화는 PCR 챌린지를 먼저 재계산할 필요 없이 PCR 토큰을 재계산할 때 마지막 전달된 챌린지를 이용하는 것이다. 이 최적화의 단점은 발행인이 챌린지의 유효성을 검사하지 않아서 나중에 카드 보유자 논쟁이 일어나고 환불배상이 발생할 가능성이 있다는 점이다.
설명된 방식의 실시예는 ICC 및 카드 보유자를 인증하기 위한 메커니즘으로서 인증 암호(AC : Application Cryptogram)를 이용한다. 커맨드, GenerateAC은 ICC에게 애플리케이션 요구 암호(ARQC : Application Request Cryptogram)나 혹은 IAF의 비트 7이 1로 설정될 경우 애플리케이션 인증 암호(AAC)를 생성하도록 요청하기 위해 이용된다. 이 커맨드에서 공급될 수 있는 데이터는 다음과 같다.
예측 불가능 수(UN)
양(Amount)
통화(Currency)
예측 불가능 수(UN)는 GenerateAC 커맨드에서 ICC에게 전달된 데이터의 4-바이트/32-비트 성분이다. 이것은 애플리케이션과는 대조적으로 ICC에게는 예측 불가능한 수/데이터로서, 사실상 카드에 대한 거래 관련 챌린지이다. PCR 챌린지는 UN을 작성하는 데 이용된다. 최대수 8개 숫자의 챌린지는 UN에 필요한 32 비트 중 하위 27 비트에 대해 설명한다. 그러므로 나머지 5 비트는 이 방식의 목적을 위하여 0이 될 것이다. PCR 챌린지의 UN 부분은 수치 값을 전달하는 것으로 생각되어야 한다(도 14 참조). 이 수치 값이 부호 없는 32 비트 정수로 취급될 경우, 가장 상위의 유효 설정 비트를 넘어선 모든 비트들은 암시적으로 0으로 설정된다. UN이 카드에 송신될 때, 카드 보유자에 의해 입력된 십진수 챌린지의 원래(raw) '2진' 값이 APDU 커맨드에서 전달된다. 그것은 입력된 챌린지 숫자들의 BCD 인코딩된 등가 값으로서 송신되지 않는다.
양 및 통화의 사용은 발행인의 재량이다. 발행인이 양 및 통화가 사용되어야 한다고 지시한 경우, 개인 카드 판독기에는 양 및 통화 데이터가 공급될 것이다. 통화는 확장된 PCR 챌린지의 일부로서 공급되고 양은 명시적/개별적으로 전송/입력된다. 발행인이 양 및 통화가 사용되지 않아야 한다고 지시하였거나, 또는 이 선택을 표시하지 않아서 그것들을 사용하지 않는 디폴트를 따른 경우, 양 및 통화에 대한 디폴트 값들이 사용될 수 있다.
GenerateAC 커맨드에 대한 전체 응답이 너무 커서 발행인에게 송신될 수 없을 수 있기 때문에, PCR은 IIPB를 이용하여 데이터 추출 및 압축 처리를 행할 수있고, 이 처리의 결과 발행인이 결정한 비트 값들의 스트링이 그들에게 통신되어야 한다 - 도 15 참조. 1의 비트 설정은 데이터 내의 대응 비트 위치가 요구되고 송신될 필요가 있다는 것을 나타내기 위해 이용될 수 있다. 0의 비트 설정은 발행인이 그 비트 설정이 무엇일지를 알거나 또는 다른 방법으로 그것을 도출할 수 있으므로 그 비트는 송신될 필요가 없다는 것을 나타내기 위해 이용될 수 있다. IIPB 데이터 토큰은 바람직하게는 좌측에서 우측으로 작성되며, 추출될 제1 비트는 출력 데이터의 마지막 바이트의 비트 1에 배치되고, 제2 비트는 비트 2에 배치되는 등으로 작성된다. IIPB 데이터 토큰은 전송할 비트가 더 이상 남아 있지 않을 때까지 이런 식으로 채워진다.
IIPB 데이터 토큰은 PCR로부터 카드 보유자 IA에게 전송되는 데이터이다. 모든 접속 디바이스 타입들은 이 데이터를 직접 MCD에 전송하는 반면, 비접속 디바이스는 카드 보유자를 이용하여 이 데이터를 수동으로 전송할 것이다.
비접속 디바이스에 대한 PCR 토큰과 관련하여, 비접속 디바이스는 전송될 데이터의 비트 패턴을 나타내는 수를 계산하고 표시할 것이다. 그후 카드 보유자는 이 수를 MCD 상에서 실행되는 카드 보유자 IA 내에 이용 가능하게 된 적당한 영역에 입력해야 한다. 비접속 PCR은 순전히 PCR로부터 MCD 상에서 실행되는 카드 보유자 IA에 데이터를 전송하기 위해 IIPB 데이터 토큰으로부터 생성된 수치 토큰을 작성한다. 비트들을 표시된 수치 숫자들로 변환하는 데 사용되는 알고리즘은 카드 보유자 IA 상에서 상호 운용 가능하고 따라서 가역적(reversible)인, 즉 비트들로부터 토큰으로 변환하는데 이용되는 동일한 알고리즘이 토큰으로부터 비트들로 변환하도록 역전(reverse)되어야 한다는 것은 중요하다. 이렇게 하기 위한 '간결한'(compressed) 방법은 비트 패턴을 2진수로 취급하여 기수-2로부터 기수-10으로 수학적 변환을 수행하는 것이다(도 16).
PCR 토큰은 분리자(separator)로서 스페이스, 대시(dash), 또는 콤마를 이용하여 제시될 수 있고, 하나 이상의 검사 숫자를 포함하여 예를 들어 20개 숫자의 최대 가능한 표시 길이로 제한된다.
카드 보유자 IA는 IIPB 데이터 토큰을 UCAF로 인코딩할 때 나머지 데이터 공간을 채우기 위해 선행 0 채우기(leading 0 padding)를 이용할 것이기 때문에 임의의 특정한 사이즈의 토큰도 기대하지 않을 것이다.
에러 검출 및 정정이 제공될 수 있다. PCR 토큰은 전체 토큰 숫자들에 대해 적용되는, 룬 검사 숫자와 같은 하나 이상의 검사 숫자들을 이용할 수 있다. 카드 보유자 IA는 검사 숫자를 검증하여 임의의 전송 에러를 보고할 것이다. 어떤 키 조작 실수(mis-keying)가 있을 경우, 카드 보유자 IA는 카드 보유자에게 통지할 것이고, 카드 보유자는 카드 보유자 IA에 PCR 토큰을 재입력해야 할 것이다.
단반향 접속 디바이스의 경우, PCR과 MCD 상의 카드 보유자 IA 사이의 통신 메커니즘은 독점적일 수 있고, 임의의 에러 검출 메커니즘도 독점적일 수 있다. 그러나, 카드 보유자 IA는 에러가 발행한 것을, 특히 어떤 타입의 핸드셰이킹 프로토콜도 수행하는 것이 가능하지 않을 수도 있는 단방향 접속 디바이스에서 에러가 발생한 것을 인지하고 카드 보유자에게 통지할 수 있어야 한다. 보기 드문 전송 에러의 경우에는, 카드 보유자 IA는 PCR에게 그 에러를 통지할 수 없을 것이기 때문에, 카드 보유자에게 처음부터 다시 PCR 상에서 인증 처리를 반복하도록, 즉 카드 삽입/스위치 온하고, 데이터 및 PIN을 입력한 다음 PCR에게 재송신하게 하는 처리를 반복하도록 요청하는 것은 허용 가능하다. 대안적으로 PCR은 재송신 기능/버튼을 채용할 수도 있다.
다른 접속 디바이스 타입의 경우에도, PCR과 MCD 상의 카드 보유자 IA 사이의 통신 메커니즘은 임의의 에러 검출 메커니즘과 함께 독점적일 수 있다.
상술한 전체 처리의 요약이 도 17에 제시되어 있다.
칩-UCAF 사용 - 카드 보유자의 관점
카드 보유자들은 이 방식에 가입해야 한다. 칩-UCAF를 사용하기 위하여, 카드 보유자는 먼저 적당한 ICC를 갖고 있어야 할 것이다. 그후 그들은 개인 카드 판독기(PCR, 접속형 또는 비접속형) 및 PC와 같은 메인 액세싱 디바이스 상에 설치된 필요한 신 클라이언트(thin-client) 카드 보유자 인터페이스 애플리케이션(IA)을 구비할 필요가 있을 것이다. 이미 제공되어 있는 지불 카드 세부사항들만을 대상으로 하는 지불 인증 방식이라고 하는 UCAF의 특징 때문에, 카드 보유자 인터페이스 애플리케이션(IA)은 그 PAN에 대해 이미 알고 있는 지불 카드들에 대한 인증 요청에 대해서만 응답한다. 그러므로 카드 보유자들은 그들이 지불을 위해 이용하려고 하는 임의의 지불 카드들의 세부사항을 카드 보유자 IA에 사전 등록하고, 그런 다음에야 그들 카드는 UCAF 인증에 이용될 수 있을 것이다. UCAF 인에이블된 상점에게 인증을 요청할 때, 그 상점은 UCAF 데이터를 카드 보유자에게 제시할 것이다. UCAF 클라이언트가 이용 가능할 경우 그것은 카드 보유자와 상호 작용할 것이다. 카드 보유자들은 제1 및 제2 코드 ?? 즉 PAN 및 IIPD를 '알아야' 할 것이다. 카드 보유자의 허가 없이 그 카드를 이용하려는 시도가 행해질 경우 정확한 PIN 없이는 PCR이 토큰을 생성할 수 없도록, 카드 보유자는 그들의 PIN 비밀의 세부사항들을 유지할 책임을 져야 한다. 카드 보유자는 전자 상거래 기반 구매에 사용될 가능성이 있는 각 PC 상에 로컬 칩-UCAF를 설치할 필요가 있을 것이다. 카드 보유자는 UCAF 지불 인증에 이용될 각 지불 카드를 지불 및 관련 인증에 사용하려고 하기 전에, 해당 카드의 PAN 세부사항들을 카드 보유자 인터페이스 애플리케이션에 등록해야 한다.
상점 관점에서
주 상점 처리 흐름이 도 18에 도시되어 있다. 상점에게 중요한 2개의 주요 관점은 첫째로 상점 웹 페이지로의 전환이고 둘째로 UCAF를 지원하기 위해 필요한 처리이다. 상점 서버들이 칩-UCAF를 지원하기 위해서는 상점 서버는 그것의 웹사이트를 통하여 부가적인 데이터를 제시하고 카드 보유자 인터페이스 애플리케이션을 통하여 삽입된 부가적인 데이터를 처리해야 할 것이다. 상점들에 의해 요구되는 노력의 맥락에서 UCAF 방식을 기술하기 위하여, 고객이 카드 보유자로서 상점와 유지할 수 있는 관계의 2가지 타입: 프로파일형(Profiled), 비프로파일형(Non-Profiled)에 대해 고찰해보겠다. 익스프레스 체크아웃 및 단일 클릭은 카드 보유자들이 프로파일링되는 것을 필요로 하는 반면 표준 체크아웃은 프로파일형 및 비프로파일형 카드 보유자들에 의해 똑같이 이용될 수 있다. 단일 클릭은 일반적으로 고객에게 단일 클릭 옵션을 허락할 것을 요청한다. 왜냐하면 많은 고객들이 이러한 충동 구매 능력에 대해 편치 않은 기분을 느끼기 때문이다. UCAF를 이용하기 위하여, 상점 서버는 UCAF 숨은 데이터 필드들을 내포하는 UCAF 인증 페이지를 제시하기 전에, 특정 카드 보유자의 지불 세부사항들, 예를 들면 PAN, 만료일자 및 CVC2를 알고 있어야 한다. 왜냐하면, 상기 필드들 중 하나는 거래에 이용되는 PAN의 마지막 5(다섯) 숫자들을 포함해야 하기 때문이다.
익스프레스 체크아웃을 위한 UCAF의 이용(도 19)을 지원하기 위하여, 주문/지불 세부사항 확인 페이지는 UCAF 숨은 필드들을 지원해야 하고, UCAF 기능의 점에서 UCAF 인증 페이지가 된다. 이것은 카드 보유자 인터페이스 애플리케이션(카드 보유자 IA)이 그 자신을 제시하고 UCAF 인증 데이터를 획득하기 위해 카드 보유자와의 필요한 상호 작용을 요청할 기회를 제공한다. 그러면 카드 보유자 IA는 카드 보유자에 의한 주문의 제시에 앞서서 UCAF 인증 필드를 채울 수 있다.
단일 클릭 구매 처리 중 UCAF의 이용(도 20)을 지원하기 위하여, 상점 서버는 UCAF 전송 페이지를 지원할 수 있다. UCAF 전송 페이지는 카드 보유자가 이용하도록 의도된 것이 아니고 그것의 표시는 인증 처리가 진행중임을 나타내야 한다. 이 페이지는 UCAF 인증 페이지로서 역할을 하고 숨은 UCAF 필드들을 제시한다. UCAF 전송 페이지는 또한 UCAF 숨은 필드들을 지원해야 하고 카드 보유자 인터페이스 애플리케이션이 그 자신을 제시하고 UCAF 인증 데이터를 얻기 위해 카드 보유자와의 필요한 상호 작용을 요청할 기회를 제공한다. 단일 클릭을 지원하는 어떤 상점들은 또한 어떤 시간 프레임 내에서 수행된 일련의 단일 클릭 거래들을 하나의 단일 주문으로 자동으로 결합하기 위한 설비를 제공한다. 즉, "그것을 갖겠어 -클릭 - 그것 - 클릭 - 그래 맞아 그리고 그것 - 클릭"(I'll have that - Click - that - Click - oh yes and that - Click). 다수의 인접한 단일 클릭 구매들이 결합될 경우, 인증은 일반적으로 주문이 '완료'(closed)되고 결합된 비용이 알려진 후에야 시도될 것이다. 이것은 단일 클릭 처리에 대한 혼란(disruption)뿐만 아니라 인증에 사용된 양에 대해 인증에 사용된 양들을 어떻게 해결할지에 대한 문제를 남긴다. 상점들은,
특별한 구성에 의해 - 결합된 단일 클릭 쇼핑 행위의 최초 구매만을 인증하기로 결정할 수 있고, 그러면 취득자는 통화 변환된 인증에 대해서 하는 것처럼 그 인증을 취급할 필요가 있을 것이다. 이것은 최초 양 - 인증의 검증이 일어날 수 있도록 인증 처리에 이용된 양을 넣는 것을 의미하다.
각 구매를 누적하여 - 각 단일 클릭은 카드 보유자에 대한 인증 요청(UCAF 전송 페이지)을 수반하고 그때마다 현재 축적된 합계에 따라서 양이 증가한다. 최후의 UCAF 인증만 발행인에게 송신될 것이다.
UCAF 전송 페이지는 인증 처리를 호출(invoke)하여 UCAF 데이터를 제공할 수 있기 위하여 UCAF를 이용하는 카드 보유자가 단일 클릭 체크아웃을 개시할 때 필요하다. 따라서, 상점은 카드 보유자에 의해 단일 클릭 옵션이 선택되기 전에 UCAF가 이용되고 있는지를 알아야 한다. 부가적인 숨은 필드, UCAF 인에이블된 필드가 다일 클릭 체크아웃 옵션을 제공하는 각각의(each) 및 모든(every) 페이지 상에서 지원되어야 한다.
카드 보유자 인터페이스 애플리케이션은 이 필드를 인식하여 그 필드에 "01"과 같은 특정 값을 자동으로 채워 UCAF 준거(compliant) 카드 보유자 IA가 지불을 용이하게 할 것임을 나타낼 것이다.
카드 보유자에 의해 사용되는 특정 카드에 대한 UCAF 인증을 수행할 수 있는 UCAF 준거 카드 보유자 IA 없이 단일 클릭 체크아웃이 개시될 때 UCAF 전송 페이지는 표시될 필요가 없다.
단일 클릭 개념에 대한 충격을 최소화하고 상점이 데이터를 수집할 수 있게 하는 UCAF 전송 페이지 상에서의 서식 채우기 처리(form fill process)를 완료하기 위하여, 카드 보유자 IA는 숨은 버튼 상의 클릭 이벤트를 개시한다. 상점은 UCAF 전송 페이지 상에 숨은 버튼, "UCAF 제시(Submit)" 버튼을 제공한다. 이 버튼은 서식 채우기가 완료될 때 카드 보유자 IA가 클릭 이벤트를 개시할 수 있게 한다. 클릭 이벤트가 발생하면 그 '페이지'는 인증 요청 내에서 송신될 데이터를 상점의 웹 서버에 송신한다.
IA는 페이지가 전송 페이지인지 아닌지를 알 수 없기 때문에, UCAF 제시 버튼이 페이지 상에 필요한 UCAF 데이터 입력 필드들 및 인증 필드를 수반할 때마다, IA는 인증 토큰 생성 처리의 종료와 동시에 항상 그것을 실행할 것이다. 상점들은 이 능력을 그들이 원하는 대로 자유로이 사용한다. 즉, 그들은 그들이 원하면 종래의 UCAF 인증 페이지들 상에서 '자동 제시'(auto submit)를 사용할 수 있다.
만일 IA가 특정 에러 표시 내용들을 UCAF 인증 데이터 필드 내에 설정하는 결과를 초래하는 에러들을 검출하는 경우, 또는 카드 보유자가 취소하고, UCAF 제시 버튼이 존재하는 경우에, IA는 역시 클릭 이벤트를 실행하여, 서식 데이터를 상점에 제시할 것이다. '양호한' 인증 데이터를 송신하기만을 원하는 상점들은 그 때문에 에러 표시들을 인식하고 적절한 에러 페이지를 카드 보유자에게 리턴하는 것을 고려해야 한다.
표준 체크아웃을 위한 UCAF의 이용(도 21)을 지원하기 위하여, 주문/지불 세부사항 확인 페이지는 UCAF 숨은 필드들을 지원하고 UCAF 인증 페이지가 되어야 한다. 이것은 카드 보유자 인터페이스 애플리케이션(카드 보유자 IA)이 그 자신을 제시하고 UCAF 인증 데이터를 획득하기 위해 카드 보유자와의 필요한 상호 작용을 요청할 기회를 제공한다. 그러면 카드 보유자 IA는 카드 보유자에 의한 주문의 제시에 앞서서 UCAF 인증 필드를 채울 수 있다.
UCAF를 이용하기 위하여, 상점은 UCAF 숨은 데이터 필드들을 갖는 UCAF 인증 페이지를 제시하기 전에 카드 보유자의 지불 세부사항들, 예를 들면 PAN, 만료일자 및 CVC2를 알고 있어야 한다. 왜냐하면, 상기 필드들 중 하나는 거래에 이용되는 PAN의 마지막 5 숫자들을 포함해야 하기 때문이다. 그러므로 UCAF를 이용할 경우 결합된 주문 세부사항 확인/지불 지불사항 요청 페이지는 예시된 바와 같이 2개의 페이지로 분할되어야 한다.
UCAF 인증 또는 전송 페이지들은 상점들이 주문 및 지불 세부사항 정보를 확인하기 위하여 카드 보유자에게 제시하는 웹 페이지들이다. UCAF 인에이블된 상점들의 경우 이들 페이지는 인증을 시도하기 전에 그에 의해 UCAF 데이터가 제시되고 획득되는 설비이다. 그러므로, UCAF 인증 페이지 및 UCAF 전송 페이지는 상점, 카드 보유자 및 발행인 사이에서 주요한 통합 포인트들이다.
UCAF 인증 페이지는 공중 인터넷을 통하여 전송되는 카드 보유자 및 거래 특정 데이터를 내포한다. 그러므로, UCAF 인증 페이지는 바람직하게는 이 데이터의 타협(compromise)을 보호하기 위하여 충분히 안전한 암호화 방법(예를 들면, 128 비트 SSL 또는 그에 상당하는 것)을 이용하여 보호되어야 한다.
PC 브라우저 기반 채널에서 모든 상점 서버가 카드 보유자 IA와 상호 작용하는 것은 숨은 HTML 서식 필드들을 통해서이다. 모든 상점들 및 모든 UCAF 애플리케이션들과의 상호 운용성을 확보하기 위하여, 이들 숨은 필드들의 구현은 명명 규칙(naming conventions), 사이즈 및 허용 내용을 포함하여 표준화되어 있다.
착신되는(incoming) 데이터 필드들, 즉 상점에 의해 공급되는 데이터 필드들은 상점 웹 서버에 의해 카드 보유자의 브라우저에 전달되는 HTML 페이지 소스에서 나타난다. 이들 필드의 값들은 페이지 소스 내에서 직접 설정되고 문자열 포맷으로 표현된다.
예를 들면, <INPUT type="HIDDEN" name="Ucaf_Currency_Code" value="978">
발신되는(outgoing) 데이터 필드들, 즉 카드 보유자에 의해 리턴되는 데이터 필드들은 상점 웹 서버에 의해 카드 보유자의 브라우저에 전달되는 HTML 페이지 소스에서 나타난다. 이들 필드의 값들은 페이지 소스 내에서 공백(blank) 값들로 설정된다.
예를 들면, <INPUT type="HIDDEN" name="Ucaf_Authentication_Data" value="">
카드 보유자 IA는 브라우저의 문서 객체 모델(DOM : Document Object Model)과 상호 작용함으로써 그 값들을 문자열로서 프로그램적으로 설정한다.
착신되는 상점 공급 데이터의 경우, 상점 서버는 그것이 공급해야 하는 데이터 값들을 하기의 숨은 서식 필드들에서 제시한다.
Ucaf_Merchant_Name - 상점의 이름은 4 문자의 22개 그룹으로서 88개 16진 문자들(0-9, A-F)로 이루어지고, 각각의 그룹은 유니코드 문자를 나타낸다. UCAF 필드 내에 상점에 의해 공급된 이름은 카드 보유자 인터페이스 애플리케이션(카드 보유자 IA)에 의해 카드 보유자에게 표시될 이름이다. 그것은 또한 챌린지의 생성 시에 사용될 이름이다.
Ucaf_City - 13 문자까지, 그들의 취득 은행에 의해 상점이 등록되는 도시.
Ucaf_State_Country - US 주 코드 또는 3 문자 ISO 3166 알파벳 국가 코드를 나르기 위한 것으로 3 문자까지.
Ucaf_Currency_Code - 거래의 통화에 대한 3 숫자 ISO 4217 통화 코드.
Ucaf_Sale_Amount - 통화 코드에 의해 반영된 기본 통화 단위로 표현된 거래의 양에 대한 것으로 12 숫자까지.
Ucaf_MTS - 2 바이트 상점 참조의 16진 표현을 내포하는 선택적(optional) 필드.
Ucaf_Brand - 카드 보유자에 의해 이 거래를 위해 선택된 지불 카드 세부사항들의 브랜드를 나타내는 2 숫자 코드.
Ucaf_Payment_Card_Number - 카드 보유자에 의해 이 거래를 위해 선택된지불 카드 세부사항들의 마지막 5 숫자. 이것은 카드 보유자 IA(들)에 의해 이용되는 것으로서 사용되는 카드가 그 카드 보유자 IA(들)가 잘 알고 있는 것이어서 UCAF 계좌 보유자 인증 값을 생성하기 위하여 대신해서 실행할 수 있는 것인지를 결정하기 위한 것이다.
발신되는 카드 보유자 리턴 데이터와 관련하여 상점은 인증 정보를 수집하기 위하여 하기의 숨은 필드들을 제시한다.
Ucaf_Authentication_Data - 상점에 의해 공백, 즉 '=""'으로 설정되고 카드 보유자 IA에 의해 UCAF 인증 데이터로 채워짐. 이 데이터는 HTML 서식 데이터에 대한 통상의 방식으로 상점에게 리턴된다. 그것은 모든 서식 필드들이 HTTP POST 요청 내에서 상점의 웹 서버에게 텍스트 포맷으로 다시 '포스트'('POST'ed back)될 것임을 의미한다. 착신되고 발신되는 필드들 양쪽 모두가 도로 포스트되므로, 상점의 웹 서버 처리는 리턴된 데이터로서 어느 데이터에 관심이 있는지와 최초에 송신된 것이기 때문에 어느 것에 주의를 기울이지 않을지를 구별한다. 즉, 브라우저에 의해 송신되는 데이터를 이용하지 않고 상점의 처리에 의해 착신되는 데이터의 읽기 전용 측면이 효과적으로 실행된다.
단일 클릭을 지원하기 위한 부가적인 UCAF 필드들과 관련하여, 상점이 UCAF를 지원하고 단일 클릭 지불 중에 UCAF 전송 페이지를 제시할 수 있기 위해서는, 하기의 것들로부터 단일 클릭 지불 옵션을 선택하는 것이 가능한 임의의 모든 페이지 상에 하기의 숨은 서식 요소들(hidden form elements)이 제시되어야 한다.
Ucaf_Payment_Card_Number - 카드 보유자에 의해 이 거래에 대해 선택된지불 카드 세부사항들의 마지막 5 숫자. 이것은 카드 보유자 IA(들)에 의해 이용되는 것으로서 사용되는 카드가 그 카드 보유자 IA(들)가 잘 알고 있는 것이어서 UCAF 계좌 보유자 인증 값을 생성하기 위하여 대신해서 실행할 수 있는 것인지를 결정하기 위한 것이다.
Ucaf_Enabled - 상점에 의해 0, 즉 '="00"' 또는 공백, 즉 '=""'으로 설정되며, 만일 그것이 있고 지불 카드 번호가 카드 보유자 IA에게 알려져 있는 지불 카드와 일치할 경우 카드 보유자 IA에 의해 "01"로 설정됨.
카드 보유자들은 그것의 용이성 때문에 그리고 요구되는 상호 작용이 없기 때문에 단일 클릭 지불 방법을 이용하기로 선택할 수 있다. UCAF의 여분의 인증 요건들을 이용할 때 카드 보유자들에 대해 이 원활한 흐름을 유지하기 위해서, 서식 제시 버튼(form submission button)이 이용 가능하게 된다. 카드 보유자 IA는 UCAF 인증 데이터를 획득하고 채우는 것의 완료와 동시에 UCAF 전송 페이지를 상점에게 자동으로 제시하기 위한 클릭 이벤트를 개시한다.
이 클릭 이벤트를 적절히 실행하기 위하여, UCAF 전송 페이지는 하기의 부가적인 숨은 서식 요소를 필요로 한다.
Ucaf_AAV_Submit - 카드 보유자 IA가 클릭 이벤트를 개시하기 위한 숨은 가상 버튼.
상점 서버는 관련 데이터를 획득하여 그것을 저장할 수 있다. 상점 서버는 카드 보유자 인터페이스 애플리케이션에 의해 공급된 UCAF 인증 데이터 필드를 획득하여 유지할 수 있다. 인증 데이터 필드는 카드 보유자와 거래를 연결하는 데이터를 상점에게 제공한다. 이 데이터는 분할 발송을 위한 후속 인증의 제시를 위하여 필요하고 예외 처리 중에 상점에게 중요할 수 있다.
상점들은 모든 칩-UCAF 전자 상거래에 대해 인증을 요청할 필요가 있다. 상점들은 모든 인증 시도들에 대해 UCAF를 공급해야 한다. 후속 인증 시도들도 또한 AAV를 포함해야 한다. 그러나, 상점은 후속 인증들에 대한 제어 바이트를 조정할 필요가 있다. 발행인은 30 달력 날짜와 같은 특정 시간보다 오래된 AAV를 갖는 최초 인증 요청들을 거절할 수도 있다.
UCAF 인증 데이터는, 인증들이 실시간으로 송신될 필요가 없는 것과 마찬가지로, 발행인에게 '실시간'으로 송신될 필요가 없다. 그러므로 UCAF 인증 데이터를 포함하는 인증 요청들은 상점의 취득자에게 송신된 데이터를 일괄처리하는 것과 관련하여 통상의 인증 요청들과 다르게 취급될 필요가 없다. 사전 인증(pre-authorizations)들도 허용되고 최초 인증들에 대해서와 같이 취급된다.
순환 지불 거래들(recurring payment transactions)은 최초 거래에 대한 AAV 데이터만을 포함해야 한다. 순환 지불에 대한 최초 인증은 칩-UCAF 처리에 적합할 수 있다. 상점들은 순환 거래들에 대한 순환 지불 인증 시에 UCAF를 제공할 필요가 없다.
상점들은 분할 발송의 각 부분에 대한 인증을 획득할 필요가 있다. 상점들은 UCAF에 대해 최초 및 후속 모두 각각의 인증 요청을 공급해야 한다. 후속 인증들에서 제어 바이트를 변경하지 않을 경우 발행인이 인증 시에 거절하는 결과가 초래될 수 있다.
상점들은 인증 요청을 반복할 필요가 있을 수 있다. 예를 들면 그들은 어떤 타임아웃 기간 내에 최초 인증 요청에 대한 응답을 수신하지 못하거나, 또는 그들은 취득자에게로 데이터의 전송 시에 다른 에러 표시들을 수신한다. 그러한 상황에서는, UCAF 인증 데이터는 최초 인증에 대해서와 같이 취급되어야 한다. 기존 프로토콜들은 취득자들에게 인증 요청이 반복 제시인지 또는 재제시(re-submission)인지를 나타낸다.
어떤 상황에서는, 상점이 최초 거래와 같은 AAV 값을 갖는 주어진 칩-UCAF 거래에 대한 제2 인증 요청을 생성할 수 있다.
다음 어드레스들에서는 최초 요청과 비트 방식으로(bit-wise) 동일하지 않은 인증 요청들이 어드레싱된다 - 예를 들면, 이 인증 요청들은 상이한 시스템-트레이스 ID 번호들을 가질지도 모른다. 상점은 하기의 경우 제2 인증 요청들을 생성할지도 모른다.
최초 거절 후에 그들이 인증 요청을 재송신하기를 바랄 경우.
최초 인증을 완전히 번복하지만, 나중에 그것을 원상태로 하기로 결정할 경우.
상점들은 제어 바이트의 값을 변경함으로써 그러한 인증들을 후속 인증들로서 취급해야 한다. 이렇게 하면 AAV 검증 설비에서 그것들이 있음직한 재연 공격으로서 잘못 거절되는 것이 예방될 것이다.
상점들은 UCAF 데이터의 내용에 관계하지 않아야 한다. 왜냐 하면 이 데이터는 하기의 두 상황을 제외하고는 발행인에게 의도된 것이기 때문이다.
후속 인증들을 행할 경우 제어 바이트의 변경
특정 UCAF 내용을 통하여 상점에게 통지된, 인터페이스 애플리케이션 검출 에러들의 체크.
예를 들어 분할 발송으로 인한 후속 인증들을 처리할 경우, 상점들은 최초 인증 내에 포함된 UCAF 내의 제어 바이트를 그 상위 비트를 클리어함으로써 카드 보유자 인터페이스 애플리케이션에 의해 설정된 값으로부터 변경해야 한다. 이것은 UCAF 인증이 최초 인증에 후속하는 인증의 일부로서 공급되는 것을 반영한다.
제어 바이트는, UCAF 데이터를 기수 64 디코딩하여 24 바이트 값을 얻고, 제1 바이트의 값을 변경한 다음 다시 기수 64 인코딩하여 업데이트된 UCAF를 생성함으로써 변경될 수 있다. 또는, 단순히 처음 기수 64 인코딩된 문자의 아스키 문자 값으로부터 38의 상수를 감산함으로써 이 처음 문자를 변경하여 이 처음 문자에 대한 새로운 값을 생성할 수도 있다.
만일 카드 보유자 IA가 데이터 포맷/검정 문제, 또는 필요한 Ucaf_숨은 필드들의 누락, 또는 그 자신의 내부 문제 때문에 상점에 의해 공급된 데이터에서 에러를 검출하면, 카드 보유자 IA는 상점에게 통지하려고 할 것이다. UCAF는 인증 메커니즘이지 지불 방식이 아니기 때문에, 상점들은 공급되지 않은 또는 에러 표시된 UCAF 데이터를 이용해 인증 처리를 계속할지 여부에 대해 자유로이 스스로 판단할 수 있다.
만일 카드 보유자가 인증 처리를 취소하면, Ucaf_Authentication_Date라고 하는 Ucaf_숨은 필드는 공백 값으로 설정될 것이고 따라서 UCAF 고객을 갖지 않는것과 차이가 없어 보인다.
상점 서버는 그들의 UCAF 인증 페이지 또는 UCAF 전송 페이지 상에 제시된 기록에서 UCAF 데이터의 존재를 검출할 수 있는 능력을 갖는다. 만일 UCAF 인증 데이터가 존재하면 상점은 최초 인증의 송신을 위해 그것을 변경하지 않고 취득자에게 제시해야 한다. 상점은 단지 후속 인증을 위해 제어 바이트의 값을 변경할 뿐이다. 상점은 또한 그 거래를 UCAF 인에이블된 것으로 플래그(flag)함으로써 취득자가 보안 레벨 지시자에 적당한 값을 채울 수 있게 한다.
아무런 UCAF 인증 데이터도 공급되지 않으면, 상점은 이것을 그의 취득자에게 나타내어 그들이 보안 레벨 지시자에 적당한 값을 채울 수 있게 한다.
상점와 취득자 사이의 링크 상에서 데이터 내용의 일부는 MAC 적용을 이용하여 도중에 변경으로부터 보호될 수 있고, 그 경우 UCAF 데이터도 MAC에 대한 입력으로서 포함될 수 있다.
카드 보유자 인터페이스 애플리케이션 기능 요건들
개인 카드 판독기 인터페이스 애플리케이션(카드 보유자 IA)은 상점와 카드 보유자간의 그리고 카드 보유자와 개인 카드 판독기(PCR)를 통한 인터페이스의 역할을 하는 소프트웨어 구성요소이다. 표준 카드 보유자 IA는 지불 기구 결정 처리에서 아무런 역할도 하지 않지만, 벤더들은 적당한 지불 카드를 선택함에 있어서 카드 보유자에 대한 지원을 실제로 포함할지도 모르는 보다 큰 기능에 대한 지원을 자유로이 부가할 수 있다. 카드 보유자 IA는, 일단 호출되면, 하기의 동작들을 수행해야 한다.
채널로부터 데이터를 검색한다.
거래에 이용되는 PAN이 그것이 알고 있는 PAN인지 여부를 판단한다.
상점 거래 데이터를 검정한다.
거래 세부사항을 카드 보유자에게 표시한다.
물리적 ICC의 카드 보유자에게 그들이 인증을 수행하기 위해 사용할 필요가 있음을 상기시키기 위해 선택된 PAN 및 임의의 이름(그 이름에 의해 해당 카드가 IA에게 알려져 있는 임의의 이름)이 명확히 표시되도록 보증한다.
PCR 챌린지를 계산 및 표시한다.
카드 보유자가 그의 PIN을 개인 카드 판독기에 입력하는 것을 포함하여, 그들이 취할 필요가 있는 조치들을 알아차리도록 명령들이 표시되거나 이용 가능하도록 보증한다.
카드 보유자의 승인의 표시로서 카드 보유자에 의해 토큰이 입력되는 것을 대기한다.
UCAF에 AAV를 채우고, 그 결과로서의 UCAF 데이터를 기수 64 인코딩한다.
채널에 필요한 UCAF 데이터 필드를 채운다.
카드 보유자에게 데이터를 상점에 제시하고, 만일 단일 클릭 구매를 처리할 경우, 제시 버튼의 클릭 이벤트를 '개시'(fire)하도록 지시한다.
마지막으로 임의의 선택적 로깅(optional logging)을 수행한다.
카드 보유자 IA는 상점 주문 처리 중 적당한 시점에 이르렀을 때 자동으로 활성화(activate)되어야 한다. 카드 보유자 IA는 해당 카드 보유자 IA에 의해 지원되고 또한 적당한 채널 명세에 규정된 전달 채널을 통하여 상점으로부터 데이터를 수신할 수 있다. 카드 보유자 IA는 상점 입력 데이터를 검정하고, 유효한 거래 데이터에 대해서만 속행한다. 카드 보유자 IA는 또한 카드 보유자로부터 거래에 사용될 지불 카드에 관한 특정 데이터를 획득한다. 카드 보유자 IA는 정확한 통화 양 포맷팅과 함께 통화 문자, 예를 들면 EUR, USD 등을 포함하는 표현으로 거래량을 포함해야 하는 거래에 관한 정보를 카드 보유자에게 표시한다. PCR 챌린지는 이것이 PCR에 입력되어야 한다는 명확한 지시와 함께 카드 보유자에게 표시된다. 그것은 또한 카드 보유자가 그의 PIN을 PCR에 입력해야 할 것이고 또한 그 결과의 PCR 토큰이 카드 보유자 IA에 입력되어야 한다는 것을 명확히 나타낸다.
카드 보유자 IA는 PCR 챌린지를 생성하거나 또는 생성되게 하고, PCR 토큰을 수신하는 즉시, IA는 UCAF에 AAV를 채우고 기수 64 인코딩한다.
카드 보유자 IA는 또한 해당 카드 보유자 IA에 의해 지원되고 또한 적당한 채널 명세서에 규정된 전달 채널을 통하여 상점 서버에 UCAF 데이터를 송신할 수 있다.
카드 보유자 IA는 또한 지불 세부사항, PAN, 만료일자 및 주소와 같은 소비자 세부사항에 대한 필드 자동 채우기 기능과 같은 부가적인 "이용 편의"(ease of use)를 제공할 수도 있다. 카드 보유자가 하나 이상의 지불 카드를 카드 보유자 IA에 등록하는 것도 가능하고, 따라서 이 경우 카드 보유자 IA는 특정 지불에 어떤 카드가 사용되는지에 대한 임의의 서식 채우기에서 카드 보유자에게 선택 기회를 제공해야 할 것이다. 이들 요건의 세부사항은 이 명세서의 범위 밖에 있다. IA는ECML(E-Commerce Modelling Language) 서식 채우기 및 "최적의 추측"(best guess) 필드 이름 자동 채우기를 지원할 수 있다.
상점은 카드 보유자의 PC 상에 설치되어 있을지도 모르는 UCAF 카드 보유자 IA와의 어떤 상호 작용을 기다리고 있는 임의의 페이지 상의 Ucaf_Payment_Card_Number 필드에 지불 카드 번호의 마지막 5 숫자를 공급해야 한다. 카드 보유자 IA들은 단지 그것이 사전에 이미 알고 있는 카드, 즉 상점에 의해 공급된 마지막 5 숫자가 해당 카드 보유자 IA에 등록된 카드들 중 하나의 마지막 5 숫자와 일치하는 카드를 인증하도록 활성화되기만 하면 된다.
실행이 인에이블되면, 카드 보유자 IA는, 인터넷 브라우저에 임의의 소정의 웹 페이지들이 로드되어 표시될 때 그 페이지 상의 서식들 내의 필드들의 필드 이름들을 결정할 수 있도록, 인터넷 브라우저 처리에 통합되거나 또는 그렇지 않으면 그 자신을 인터넷 브라우저 처리에 부속시킨다.
정의된 UCAF 서식 필드들 중 임의의 것이 인지되면, 애플리케이션은 UCAF 처리를 시작하고 인증 처리를 속행하기 위하여 이들 필드들로부터 필요한 데이터를 추출한다.
카드 보유자 IA 활성화 흐름이 도 22에 도시되어 있다.
개인 카드 판독기(PCR)는 칩-UCAF 방식 내의 구성요소이다.
도 23은 PCR 처리 흐름의 개념도이다.
1. 카드 보유자가 접속형 또는 비접속형 디바이스에 ICC(5)를 삽입하면 처리가 시작된다. 이하에서는 비접속형 디바이스를 가정한다.
2. PCR은 ICC(5) 및 그 카드 상의 관련 프로그램을 찾고 잠깐의 시간 동안 애플리케이션 라벨을 표시함으로써 카드 보유자에게 그 카드를 확인한다.
3. 개인 카드 판독기는 ICC(5)로부터 발행인 인터넷 사유 비트맵(IIPB)을 판독한다. 만일 IIPB의 길이가 틀릴 경우 또는 IIPB에 의해 표시된 전송될 비트 수가 그 특정 개인 카드 판독기에게는 너무 클 경우, 개인 카드 판독기는, 치명적 에러(Fatal Error)라는 메시지를 표시한다.
4. 개인 카드 판독기는 카드 보유자에게 챌린지를 입력하도록 프롬프트(prompt)한다. 챌린지는 예측 불가능 수(UN), 거래 통화 코드(선택적) 및 후미 검사 숫자에 이용될 데이터를 포함한다.
5. 카드 보유자는 그의 메인 액세스 디바이스 상의 프롬프트에 표시된 12 숫자 수를 입력하고 PCR은 에러를 체크한다. 개인 카드 판독기는 검사 숫자가 틀림없는지를 판단하고 챌린지가 유효한지 무효한지를 카드 보유자에게 통지한다. 만일 무효하다면, PCR은 다시 챌린지를 요청한다.
6. 개인 카드 판독기는 카드 보유자에게 거래량을 입력하도록 프롬프트한다. 만일 인증 거래가 거래량을 이용하지 않는다면, 이 단계는 완전히 무시(skip)될 것이다. 챌린지는 거래량 코드를 포함하기 때문에, 디스플레이는 카드 보유자에게 통화에 대한 시각적 확인으로서 디스플레이 라인의 말미에 3 문자 통화 기호를 포함시킨다.
7. 카드 보유자는 그의 메인 액세스 디바이스 상의 프롬프트에 표시된 양을 입력한다.
8. 카드 보유자는 이제 그의 PIN을 입력해야 하고 따라서 개인 카드 판독기는 카드 보유자가 그의 PIN을 입력하도록 하는 프롬프트를 표시한다.
9. 카드 보유자는 그의 PIN 숫자들을 입력하고 "엔터"를 친다.
10. 개인 카드 판독기는 ICC에 PIN을 제시한다. 만일 ICC가 무효 PIN 입력임을 역으로 보고해주면, 개인 카드 판독기는 카드 보유자에게 남아 있는 시도의 횟수를 알려주고 만일 그렇지 않다면 유효 PIN임을 보고한다.
11. 디바이스는 예측 불가능 수와 양 및 통화 코드(모두 카드 보유자에 의해 입력됨)로서의 거래 데이터를 이용하여 GenerateAC 커맨드를 작성한다. 이 커맨드는 ICC에 송신된다. 만일 인증 거래가 거래량을 이용하지 않는다면, 양(0)과 통화 코드(999)에 대한 디폴트이지만 유효한 값이 사용된다.
12. ICC는 응답하고 PCR은 카드로부터 판독된 IIPB를 이용하여 GenerateAC에 대한 응답으로부터 제거(strip)되어 토큰으로 압축되어야 하는 비트들을 결정한다. 만일 ICC 상에 아무런 IIPB도 발견되지 않으면, 판독기에 저장된 디폴트 IIPB 값이 이용된다. 만일 IIPB의 길이가 틀리면, 개인 카드 판독기는 치명적 에러라는 메시지를 표시한다.
13. 그러면 디바이스는 n-숫자 (+ 1 검사 숫자) 수치 토큰을 계산하여 표시한다. 카드 보유자는 이 토큰을 판독하여 그의 메인 디바이스 상의 애플리케이션에 입력한다. 메인 액세스 디바이스 상의 애플리케이션은 검사 숫자를 검증하여 카드 보유자에게 그 토큰이 에러를 포함하고 있는지를 통지하고 토큰이 재입력되도록 요청한다. 만일 카드 보유자가 토큰을 정확하게 키 입력하면, 온라인 거래 처리가 속행된다.
상기 방식은 특정 데이터 구조를 필요로 한다. 발행인 인터넷 사유 데이터(IIPD)는 하기의 구조를 갖는 2진 데이터를 포함하는 선택적(optional) 0 바이트 내지 32 바이트의 범용 구조이다.
바이트 1 - IAF.
바이트 2 내지 31 - 부가적인 발행인 특정 내용(Issuer specific content).
IIPD의 제1 바이트는 인터넷 인증 플래그(IAF) 바이트이다. 각 비트는 PCR이 취해야/이용해야 하는 발행인으로부터의 조치 또는 옵션들을 통신한다. 플래그 설정들은 양 및 통화가 GenerateAC에서 명시적으로 이용되어야 하는지 여부 및 AAC 또는 ARQC가 ICC로부터 요청되어야 하는지 여부를 나타낸다. 만일 ICC(5)가 아무런 IIPD도 갖고 있지 않다면, 0x40의 디폴트 바이트 값이 IAF에 이용된다.
IAF 뒤에 오는 임의의 데이터는 발행인이 독점적으로 사용하기 위한 것이다. 인터넷 발행인 사유 데이터(IIPD)는 인증 토큰의 검증을 돕기 위한 발행인의 인증 검증 시스템에 전송될 사유 데이터, 일반적으로 카드 고유 정적 데이터를 특정할 수 있게 한다. 그것은 인터넷 인증 환경에 대한 발행인 사유 데이터를 유지하기 위한 범용 객체로서 이용된다. IIPD 내에서 전달될 데이터는 기본적으로 임의의 카드 정적 데이터로서, 애플리케이션 암호를 검증할 발행인 호스트 시스템에 의해 요구되지만, 하나의 이유 또는 다른 이유 때문에 카드 데이터베이스로부터 획득할 수 없거나 또는 획득하기가 어려운 데이터이다. 예를 들면 키 도출 인덱스(keyderivation index) 및/또는 암호 버전 번호(cryptogram version number)를 포함할 수 있다.
카드들은 1 숫자 카드 일련 번호(CSN)를 사용할 수 있다. UCAF 명세는 이 필드에 대해 준비하고 있지 않으므로, IIPD는 CSN을 전송하는 데 이용될 수 있다. 그것을 IIPD 내에 위치시킴으로써(그것을 나타내기 위해 4 비트가 필요) 그것은 발행인에게 전달될 것이다. CSN의 위치 및 포맷은 발행인 나름이다.
카드 보유자는 IIPD가 있다면 그것을 카드 보유자 IA에 공급해야 한다. 이것은 발행인이 임의의 카드의 고유 IIPD를 카드 보유자에게 통신함으로써, 카드 보유자가 요구에 따라 이 데이터를 카드 보유자 IA에게 공급할 수 있게 해야 한다는 것을 의미한다. 상호 운용성의 이유 때문에, 이 데이터를 보다 간결한 16진수 형태로 공급하기보다는, 발행인은 IIPD를 가변적인 전체 바이트 수, 십진 3중 값 형태(decimal triplet form)로 공급해야 할 것이다. 즉, 각 바이트의 값은 십진 값으로 입력되고, 다음 바이트 값과는 대시 또는 스페이스로 분리될 것이다. IIPD가 3중 값으로 제시되도록 보증하기 위해 선행 0 채우기가 이용될 것이다. 이 요건은 대시 또는 스페이스 키가 없는 MCD가 각 3중 값을 인식할 수 있도록 하기 위해 필요하다.
PCR은 인터넷 인증 플래그(IAF) 바이트로서 IIPD의 제1 바이트만을 이용하지만, 그래도 전체 IIPD는 ICC로 개인화되어야 한다. 이것은 ICC로부터 데이터를 추출할 수 있는 접속형 판독기들이 IIPD를 검색할 수 있도록, 그래서 카드 보유자가 IIPD를 수동으로 하지 않아도 되도록 하기 위해서이다.
또 다른 데이터 구조는 발행인 인터넷 사유 비트맵이다. 발행인 인터넷 사유 비트맵(IIPB)은 2진 데이터를 포함하는 선택적 11 바이트 내지 43 바이트 구조이다. 이 비트맵은 데이터 항목들 CID, ATC, AC 및 IAD의 연결 값에 대한 마스크이다. 그것은 반드시 응답 데이터에 대한 직접적 마스크(straight mask)는 아니다. 왜냐하면 제1 태그가 없는 그리고 제2 태그가 있는 GenerateAC 응답 모두는 PCR에 의해 핸들링될 수 있기 때문이다 제2 응답 데이터는 CID, ATC, AC 및 IAD의 값들뿐만 아니라 태그 및 길이를 포함한다. 만일 ICC(5)가 아무런 IIPB도 갖지 않으면, 19 바이트 구조의 디폴트 값이 이용된다. IIPB를 이용하여 IIPB 데이터 토큰 내에서 전송될 비트들을 결정한 후에, 비접속형 PCR은 카드 보유자에게 표시하기 위한 PCR 토큰을 작성해야 한다.
UCAF 내의 AAV 데이터 스페이스를 통해서뿐만 아니라 더욱 중요하게는 비접속형 개인 카드 판독기(PCR)로부터 이용가능한 데이터 전송이 제한되기 때문에, 인증 암호를 검증하기 위하여 정보 중의 어느 비트가 발행인에게 전달되는지를 정의하는 것은 IIPB이다. 그러므로 IIPB는 발행인의 검증 데이터 요건의 정의이다. IIPB는 하기로부터 요구되는 비트들의 마스크이다.
암호 정보 데이터(CID)
애플리케이션 거래 카운터(ATC)
애플리케이션 암호(AC)
발행인 애플리케이션 데이터(IAD)
CID로부터 요구되는 유일한 정보는 카드에 의해 생성된 AC가 ARQC이었는지아니면 AAC이었는지이다. 카드는 ARQC 또는 AAC 중 어느 하나를 생성할 것이기 때문에, 양쪽 모두의 암호 지시자 비트들을 송신할 필요가 없고, 두 지시자 비트 중 최상위 비트만이 요구된다. CID의 나머지는 아래 지시된 바와 같이 설정되고 따라서 송신되지 않는다.
ATC는 각 거래 후에 증가(increment)하는 16 비트 카운터이다. ATC의 값은 암호에 포함되고 그 암호에 유일성을 제공한다. ACT의 증가 특성 때문에, 실제로 전송되는 ATC의 비트 수를 감소시킬 수 있다.
이 방식을 위해 ICC에 의해 계산되도록 요구되는 암호(AC)는 애플리케이션 요구 암호(ARQC)이지만, 어떤 카드 구현들은 대신에 애플리케이션 인증 암호(AAC)를 생성하기로 선택하거나 또는 그들의 발행인에 의해 애플리케이션 인증 암호(AAC)를 생성하도록 요구될 수 있다. 양쪽 모두의 경우, AC는 ICC에게 전달되거나 또는 다른 방법으로 알려진 데이터에 대해 계산된 8 바이트 메시지 인증 코드(MAC)이다. 이 8 바이트 AC 중 2 바이트만이 PCR 토큰 내에서 전송되고 발행인 호스트 처리는 수신된 AC와 재구성에 의해 생성된 AC를 비교할 때 이것을 고려해야 한다. 어느 2 바이트가 선택되는지는 물론 IIPB에 의해 결정된다. 디폴트 IIPB는 처음 2 바이트를 취하도록 설정된다.
발행인 애플리케이션 데이터(IAD)는, 카드에 저장된 정적 값들이면서 발행인이 PAN 및 만료일자에 기초하여 ICC 데이터베이스로부터 검색할 수 있으며 따라서 전송될 필요가 없는 키 도출 인덱스 및 암호 버전 번호를 포함하는 발행인 기지의(known) 값들과 가정된 정적 값들 및 거래 특정 값들의 조합을 갖는 필드들을 포함한다. 또한 상수(constant)인 동적 인증 암호(DAC : Dynamic Authentication Cryptogram)가 포함되고 이것은 전송될 필요가 없다. 또한 4 바이트 필드이고 이중 바이트 1이 CVR의 길이이고 고정된 기지의 상수인 카드 검증 결과(CVR)가 포함된다. 바이트 2, 3, 및 4는 가정되고 요구된 거래 또는 카드 특정 비트 값들의 혼합을 포함한다. 이들 비트는 오프라인 PIN 검증이 성공적이었는지, PIN 재시도 수가 초과되었는지, 이전 거래가 실패했는지 여부에 대한 귀중한 정보를 제공한다.
도 24는 표준 거래에서 관련되는 단계들을 도시하고 이에 대해 이하에서 설명한다.
1. 카드 활성화 : 거래를 할 때 카드 판독기에 카드가 삽입되어야 한다.
2. 애플리케이션 선택 : 애플리케이션 선택 처리는 단말기가 ICC 내의 데이터를 이용하여 인증 암호를 생성하는 데 이용될 ICC 애플리케이션을 결정하는 처리이다. 이 처리는 2개의 단계로 이루어진다.
단말기에 의해 지원되는 ICC 애플리케이션들의 리스트를 생성.
상기 생성된 리스트로부터 실행될 애플리케이션을 선택.
3. 애플리케이션 처리 개시 : 단말기는 거래 처리를 개시한다.
4. 애플리케이션 데이터 판독 : 단말기는 AFL에 의해 지시된 데이터를 판독한다.
5. 오프라인 카드 인증 : 중요한 ICC 내재 데이터의 합법성을 확인하고 ICC를 인증하기 위해 단말기에 의해 데이터 및 카드 인증이 수행된다. 칩-UCAF 인증 서비스를 위해 이용되는 개인 카드 판독기는 온라인 전용 단말기로 간주될 수 있고, 그러므로 단말기 애플리케이션은 인증 교환 프로파일의 설정에 표시된 바와 같이 오프라인 카드 인증을 수행할 필요가 없다. 이것은 단말기가 단말기에 삽입된 카드가 진짜인지 검증할 필요가 없고, 이것은 암호를 검정할 때 카드 발행인에게 맡겨질 수 있다는 것을 의미한다.
6. 제한 처리 : 제한 처리 기능의 목적은 단말기 내의 애플리케이션과 ICC 내의 애플리케이션의 호환성 정도를 결정하고 거래의 있음직한 거절을 포함하여 임의의 필요한 조정을 행하기 위한 것이다.
단말기 애플리케이션은 이들 테스트를 수행할 필요가 없다. 왜냐하면 결과에 상관없이 단말기는 ARQC를 요청하거나(그러나 ICC가 그 요청을 '거절'하면 AAC를 접수) 또는 AAC를 요청할 것이기 때문이다.
7. 카드 보유자 검증 : 칩-UCAF 인증 방식은 카드 보유자를 인증하기 위해 유효 PIN(개인 식별 번호)을 필요로 한다.
8. 단말기 위험 관리 : 단말기 위험 관리는 취득자, 발행인, 및 시스템을 사기로부터 보호하기 위해 단말기에 의해 수행되는 위험 관리의 부분이다. 카드 발행인은 어쨌든 온라인으로 거래를 처리할 것이기 때문에, 단말기 위험 관리는 선택적(optional)이다.
9. 단말기 액션 분석 : 통상의 오프라인 거래에 관련된 단말기 위험 관리 및 애플리케이션 기능들이 일단 완료되면, 단말기는 거래가 오프라인으로 승인되어야 하는지, 오프라인으로 거절되어야 하는지, 또는 온라인으로 전송되어야 하는지에 대한 첫 번째 결정을 행한다.
10. 제1 액션 분석 : ICC는 발행인을 사기 또는 과도한 신용 위험으로부터 보호하기 위하여 그 자신의 위험 관리를 수행할 수 있다. 이 위험 관리 처리의 결과, ICC는 온라인 또는 오프라인으로 거래를 완료하거나 또는 참고 상담(referral)을 요청하거나 또는 거래를 거절하기로 결정할 수 있다. 단말기는 애플리케이션 암호, ARQC 또는 AAC를 생성하도록 카드에 요청할 것이다. 인터넷 인증 플래그(IAF)의 비트 7은 ARQC를 요청할지(0으로 설정) 또는 AAC를 요청할지(1로 설정)를 나타낸다. 만일 ICC가 ARQC를 생성하도록 요청을 받으면, APDU의 P1은 0x80으로 설정된다. 만일 ICC가 AAC를 생성하도록 요청을 받으면, APDU의 P1은 0x0으로 설정된다.
이 요청에 있어서 단말기는 예를 들면 하기의 특정 데이터를 포함해야 한다.
인증된 양.
단말기 국가 코드.
단말기 검증 결과.
거래 통화 코드.
거래 일자.
거래 유형.
예측 불가능 수.
단말기 유형.
데이터 인증 코드.
단말기는 GenerateAC 커맨드와 함께 포함될 데이터 열을 작성한다. ICC는그 데이터 항목들 및 카드에 의해 유지된 다른 데이터 항목들에 대해 애플리케이션 암호(AC)를 생성할 것이다. GenerateAC 커맨드에 대한 단말기의 응답은 AC 및 암호 생성 시에 포함된 카드에 의해 유지된 하기의 다른 데이터를 포함한다.
암호 정보 데이터(CID)
애플리케이션 거래 카운터(ATC)
선택적 발행인 애플리케이션 데이터(IAD)
다른 데이터 요소들도 리턴될 수 있지만 단말기 애플리케이션에 의해 무시될 수 있다.
11. 단말기 온라인 처리 : 발행인, 지불 시스템, 또는 취득자에 의해 정의된 위험의 허용 한계 밖에 있는 거래들을 발행인이 확실히 검토하고 인증하거나 또는 거절할 수 있게 하기 위하여 통상 온라인 처리가 수행된다. 개인 카드 판독기 단말기 애플리케이션의 경우, 온라인 처리 단계에 상당하는 것이 GenerateAC 응답 데이터로부터, 카드 보유자에게 표시된 데이터 토큰을 작성한다. 그러나, 이것은 사실상 ICC에 의한 거래가 완료될 때까지 발생하지 않고 이에 대해서는 후술한다. 단말기는 어떠한 온라인 처리도 수행할 필요가 없다.
12. 발행인에서 카드로의 스크립트 처리 : 발행인은 현재 거래에 반드시 관련되지는 않지만 ICC 내의 애플리케이션의 기능 지속을 위해 중요한 기능들을 수행하기 위해 단말기에 의해 ICC에 전달될 커맨드 스크립트를 제공할 수 있다. 개인 카드 판독기는 커맨드 스크립트를 제공할 능력을 갖지 않으므로 단말기는 이 단계를 수행하지 않는다.
13. 거래 완료 : 완료 기능은 거래의 처리를 완료한다. 에러 처리에 의해 거래가 조기 종결되지 않는 한 단말기는 항상 이 기능을 수행한다. 어떤 카드 구현들은 그들의 내부 위험 관리에 따라서 ARQC보다는 AAC를 생성할 수 있다. CID의 비트 8은 카드가 AAC를 생성했는지 아니면 ARQC를 생성했는지를 결정할 것이다. 만일 비트 8이 0이면, 카드는 AAC를 생성했다. 만일 비트 8이 1이면, 카드는 ARQC를 생성했다. 만일 ICC가 제1 GenerateAC와 함께 AAC를 리턴했다면, 거래는 '오프라인으로 거절'되었고 더 이상의 처리는 요구되지 않는다. 만일 ICC가 제1 GenerateAC 커맨드와 함께 ARQC를 리턴했다면, 단말기는 AAC를 생성하도록 카드에 요청해야 한다. 이 요청에 있어서 단말기는 예를 들면 하기의 데이터 리스트로부터 특정 데이터를 포함해야 한다.
인증된 양.
단말기 국가 코드.
단말기 검증 결과.
거래 통화 코드.
거래 일자.
거래 유형.
예측 불가능 수.
단말기 유형.
데이터 인증 코드.
단말기는 GenerateAC 커맨드와 함께 포함될 데이터 열을 작성한다. ICC는CDOL2 내의 데이터 항목들에 대해 애플리케이션 암호(AC)를 생성할 것이다. ICC 내의 거래 상태는 이제 완료되고 카드는 이제 전원 오프될 수 있다.
14. 토큰 생성 : 카드에 의해 성공적인 거래가 완료되면, 단말기는 카드 보유자에게 제시될 토큰을 생성해야 한다. 토큰은 IIPB 값에 따라서 제1 또는 오직 GenerateAC에 대한 응답으로부터 생성된다. 카드가 물리적으로 단말기 내에 존재하면 토큰은 카드 보유자에게만 표시되어야 한다. 이것은 PCR과 ICC 사이의 상호 작용 기간을 통틀어 카드가 판독기 내에 남아 있다고 하더라도, 토큰이 표시되는 동안 그것이 제거되면, 단말기는 그 표시를 클리어해야 하고 자신을 스위치 오프해야 한다는 것을 의미한다. 상기 방식에서, 카드 보유자 동작 또는 단말기에 의한 에러의 검출에 의해 ICC로부터의 리턴 코드들에 표시된 어떠한 에러도 거래의 처리가 중단되고 PCR 자신이 스위치 오프되기 전에 적당한 에러 메시지가 표시되는 결과를 초래해야 한다. PCR은 그러한 상황에서는 토큰을 생성하고 표시하지 않아야 한다.

Claims (36)

  1. 인증을 위해 집적 회로 카드를 이용하여 네트워크를 통하여 상품의 판매를 거래하기 위한 네트워크 지불 시스템에 있어서,
    상기 네트워크와 통신하는 상점 서버(merchant server) -상기 상점 서버는 적어도 제1 품목의 판매 상품을 가짐- ;
    상기 네트워크와 통신하는 고객 단말기 -상기 고객 단말기는 상기 제1 판매 품목을 검토하기 위한 출력 디바이스, 및 상기 제1 판매 품목을 구매하기 위한 구매 거래를 개시하기 위한 입력 디바이스를 갖고, 상기 고객 단말기는 상기 상점 서버로부터 획득된 상점 식별자에 관한 정보 및 금융 거래 정보를 이용하여 구매 메시지를 작성하도록 구성되며, 상기 고객 단말기는 상기 상점 식별자에 관한 정보 및 계좌 번호(account number)로부터 생성되는 챌린지 메시지(challenge message)를 생성하기 위한 수단을 포함함- ;
    상기 집적 회로 카드와 통신하기 위한 카드 판독기;
    금융 거래를 승인하기 위한 거래 승인 서버; 및
    상기 카드 판독기에서 상기 챌린지 메시지를 수신하고 상기 챌린지 메시지로부터 값을 생성하기 위한 수단
    을 포함하며,
    상기 집적 회로 카드는 상기 값의 적어도 일부로부터 암호 메시지를 생성하기 위한 수단을 포함하고,
    상기 카드 판독기는 상기 암호 메시지의 적어도 일부로부터 인증 토큰을 생성하기 위한 수단을 포함하고,
    상기 고객 단말기는 상기 네트워크를 통하여 송신용 메시지 내의 상기 인증 토큰의 적어도 일부를 상기 승인 서버에 송신하기 위한 수단을 포함하는
    네트워크 지불 시스템.
  2. 제1항에 있어서,
    챌린지 메시지를 생성하기 위한 상기 수단은 상기 상점 식별자에 관한 정보, 계좌 번호와, 구매량과 구매 통화(purchase currency) 중 적어도 하나로부터 상기 챌린지 메시지를 생성하도록 구성되는 네트워크 지불 시스템.
  3. 제1항 또는 제2항에 있어서,
    상기 인증 토큰의 적어도 일부를 송신하기 위한 상기 수단은 상기 인증 토큰의 상기 적어도 일부를 상기 상점 서버에 송신하도록 구성되고, 상기 상점 서버는 상기 인증 토큰의 상기 적어도 일부를 인증 요청 메시지 내의 구매 정보와 함께 상기 거래 승인 서버에 송신하도록 구성되는 네트워크 지불 시스템.
  4. 제2항 또는 제3항에 있어서,
    챌린지 메시지를 생성하기 위한 상기 수단은 상기 상점 식별자 및 상기 계좌 번호와, 선택적으로 구매량과 구매 통화 중 적어도 하나를 연결(concatenate)시키도록 구성되는 네트워크 지불 시스템.
  5. 앞선 항들 중 어느 한 항에 있어서,
    챌린지 메시지를 생성하기 위한 상기 수단은 상기 상점 식별자 및 상기 계좌 번호와, 선택적으로 구매량과 구매 통화 중 적어도 하나의 연결을 압축하도록 구성되는 네트워크 지불 시스템.
  6. 제5항에 있어서,
    상기 압축은 해시 함수(hash function)인 네트워크 지불 시스템.
  7. 제3항 내지 제6항 중 어느 한 항에 있어서,
    상기 승인 서버는 상기 인증 토큰의 적어도 일부를 재작성하고 상기 재작성된 메시지를 상기 상점 서버로부터 송신된 상기 인증 요청 메시지 내의 상기 인증 토큰의 상기 적어도 일부와 비교하는 네트워크 지불 시스템.
  8. 제7항에 있어서,
    상기 거래 승인 서버는 상기 비교가 긍정적이면 상기 상점 서버에 인증 승인 메시지를 송신하도록 구성되는 네트워크 지불 시스템.
  9. 앞선 항들 중 어느 한 항에 있어서,
    상기 집적 회로 카드는 메모리 및 상기 메모리에 저장된 제1 데이터 객체를 갖고 상기 암호 메시지의 적어도 일부로부터 인증 토큰을 생성하기 위한 상기 수단은 상기 제1 데이터 객체에 따라서 상기 암호 메시지의 상기 일부의 일부분을 선택하도록 구성되는 네트워크 지불 시스템.
  10. 제4항 내지 제9항 중 어느 한 항에 있어서,
    상기 집적 회로 카드는 메모리 및 상기 메모리에 저장된 제2 데이터 객체를 갖고, 챌린지 메시지를 생성하기 위한 상기 수단은 상기 제2 데이터 객체에 따라서 상기 챌린지 메시지의 생성 시에 구매량과 구매 통화 중 적어도 하나를 포함하는 네트워크 지불 시스템.
  11. 집적 회로 카드를 이용하여 네트워크를 통하여 상품의 판매를 거래하기 위한 인증 방법에 있어서,
    상기 네트워크를 통하여 상점 서버와 고객 단말기 사이의 통신을 설정하는 단계 - 상기 상점 서버는 적어도 제1 품목의 판매 상품을 가짐 - ;
    상기 고객 단말기 상에서 상기 제1 판매 품목을 검토하고, 상기 제1 판매 품목을 구매하기 위한 구매 거래를 개시하고, 상기 상점 서버로부터 획득된 상점 식별자에 관한 정보 및 금융 거래 정보를 이용하여 구매 메시지를 작성하는 단계;
    상기 상점 식별자에 관한 정보 및 계좌 번호로부터 상기 고객 단말기 상에서 챌린지 메시지를 생성하는 단계;
    상기 챌린지 메시지를 카드 판독기에서 수신하고 상기 챌린지 메시지로부터 값을 생성하는 단계;
    상기 집적 회로 카드와 상기 카드 판독기 사이의 통신을 설정하고 상기 값의 적어도 일부로부터 암호 메시지를 생성하는 단계;
    상기 암호 메시지의 적어도 일부로부터 상기 카드 판독기 상에서 인증 토큰을 생성하는 단계; 및
    상기 고객 단말기로부터 상기 네트워크를 통하여 송신용 메시지 내의 상기 인증 토큰의 적어도 일부를 승인 서버로 송신하는 단계
    를 포함하는 인증 방법.
  12. 제11항에 있어서,
    챌린지 메시지를 생성하는 단계는 상기 상점 식별자에 관한 정보, 계좌 번호와, 구매량과 구매 통화 중 적어도 하나로부터 상기 챌린지 메시지를 생성하는 단계를 포함하는 인증 방법.
  13. 제11항 또는 제12항에 있어서,
    상기 인증 토큰의 적어도 일부를 송신하는 단계는 상기 인증 토큰의 상기 적어도 일부를 상기 상점 서버에 송신하고 상기 상점 서버로부터 상기 인증 토큰의 상기 적어도 일부를 인증 요청 메시지 내의 구매 정보와 함께 상기 거래 승인 서버에 송신하는 단계를 포함하는 인증 방법.
  14. 제12항 또는 제13항에 있어서,
    챌린지 메시지를 생성하는 단계는 상기 상점 식별자 및 상기 계좌 번호와, 선택적으로 구매량과 구매 통화 중 적어도 하나를 연결키는 단계를 포함하는 인증 방법.
  15. 제11항 내지 제14항 중 어느 한 항에 있어서,
    챌린지 메시지를 생성하는 단계는 상기 상점 식별자 및 상기 계좌 번호와, 선택적으로 구매량과 구매 통화 중 적어도 하나의 연결을 압축하는 단계를 포함하는 인증 방법.
  16. 제15항에 있어서,
    상기 압축하는 단계는 해시 함수를 적용하는 단계를 포함하는 인증 방법.
  17. 제13항 내지 제16항 중 어느 한 항에 있어서,
    상기 승인 서버에서 상기 인증 토큰의 적어도 일부를 재작성하는 단계, 및 상기 재작성된 메시지를 상기 상점 서버로부터 송신된 상기 인증 요청 메시지 내의 상기 인증 토큰의 상기 적어도 일부와 비교하는 단계를 포함하는 인증 방법.
  18. 제17항에 있어서,
    상기 비교가 긍정적이면 상기 상점 서버에 인증 승인 메시지를 송신하는 단계를 더 포함하는 인증 방법.
  19. 제11항 내지 제18항 중 어느 한 항에 있어서,
    상기 집적 회로 카드는 메모리 및 상기 메모리에 저장된 제1 데이터 객체를 갖고, 상기 제1 데이터 객체에 따라서 상기 암호 메시지의 적어도 일부의 일부분을 선택함으로써 상기 암호 메시지의 상기 적어도 일부로부터 인증 토큰을 생성하는 단계를 더 포함하는 인증 방법.
  20. 제14항 내지 제19항 중 어느 한 항에 있어서,
    상기 집적 회로 카드는 메모리 및 상기 메모리에 저장된 제2 데이터 객체를 갖고, 상기 제2 데이터 객체에 따라서 구매량과 구매 통화 중 적어도 하나로부터 챌린지 메시지를 생성하는 단계를 더 포함하는 인증 방법.
  21. 인증을 위해 집적 회로 카드를 이용하여 네트워크를 통해 상품의 판매를 거래하기 위한 네트워크 지불 시스템에서 이용하기 위한 인증 시스템에 있어서,
    상기 네트워크와 통신하는 상점 서버 - 상기 상점 서버는 적어도 제1 품목의 판매 상품을 포함함 - ;
    상기 네트워크와 통신하는 고객 단말기 -상기 고객 단말기는 상기 제1 판매 품목을 검토하기 위한 출력 디바이스, 및 상기 제1 판매 품목을 구매하기 위해 구매 거래를 개시하기 위한 입력 디바이스를 포함하고, 상기 고객 단말기는 상기 상점 서버로부터 획득된 상점 식별자에 관한 정보 및 금융 거래 정보를 이용하여 구매 메시지를 작성하도록 구성되고, 상기 고객 단말기는 상기 상점 식별자에 관한 정보 및 계좌 번호로부터 생성되는 챌린지 메시지를 생성하기 위한 수단을 포함함 - ;
    상기 집적 회로 카드와 통신하기 위한 카드 판독기 및;
    상기 카드 판독기에서 상기 챌린지 메시지를 수신하고 상기 챌린지 메시지로부터 값을 생성하기 위한 수단
    을 포함하며,
    상기 집적 회로 카드는 상기 값의 적어도 일부로부터 암호문(cryptogram)을 생성하기 위한 수단을 포함하고,
    상기 카드 판독기는 상기 암호문의 적어도 일부로부터 인증 토큰을 생성하기 위한 수단을 포함하고,
    상기 고객 단말기는 상기 네트워크를 통해 송신용 메시지 내의 상기 인증 토큰의 적어도 일부를 상기 상점 서버를 향하여 송신하기 위한 수단을 포함하는 인증 시스템.
  22. 제21항에 있어서,
    챌린지 메시지를 생성하기 위한 상기 수단은 상기 상점 식별자에 관한 정보, 계좌 번호와, 구매량과 구매 통화 중 적어도 하나로부터 상기 챌린지 메시지를 생성하도록 구성되는 인증 시스템.
  23. 제21항 또는 제22항에 있어서,
    챌린지 메시지를 생성하기 위한 상기 수단은 상기 상점 식별자 및 상기 계좌 번호와, 선택적으로 구매량과 구매 통화 중 적어도 하나를 연결시키도록 구성되는 인증 시스템.
  24. 제21항 내지 제23항 중 어느 한 항에 있어서,
    챌린지 메시지를 생성하기 위한 상기 수단은 상기 상점 식별자 및 상기 계좌 번호와, 선택적으로 구매량과 구매 통화 중 적어도 하나의 연결을 압축하도록 구성되는 인증 시스템.
  25. 제24항에 있어서,
    상기 압축은 해시 함수인 인증 시스템.
  26. 제21항 내지 제25항 중 어느 한 항에 있어서,
    상기 집적 회로 카드는 메모리 및 상기 메모리에 저장된 제1 데이터 객체를 갖고 상기 암호문의 적어도 일부로부터 인증 토큰을 생성하기 위한 상기 수단은 상기 제1 데이터 객체에 따라서 상기 암호문의 상기 일부의 일부분을 선택하도록 구성되는 인증 시스템.
  27. 제21항 내지 제26항 중 어느 한 항에 있어서,
    상기 집적 회로 카드는 메모리 및 상기 메모리에 저장된 제2 데이터 객체를 갖고 챌린지 메시지를 생성하기 위한 상기 수단은 상기 제2 데이터 객체에 따라서 상기 챌린지 메시지의 생성 시에 구매량과 구매 통화 중 적어도 하나를 포함하는 인증 시스템.
  28. 집적 회로 카드를 이용하여 네트워크를 통해 상품의 판매를 거래하기 위한 인증 방법에 있어서,
    상기 네트워크를 통해 상점 서버와 고객 단말기 사이의 통신을 설정하는 단계 - 상기 상점 서버는 적어도 제1 품목의 판매 상품을 포함함 - ;
    상기 고객 단말기 상에서 상기 제1 판매 품목을 검토하고, 상기 제1 판매 품목을 구매하기 위해 구매 거래를 개시하고, 상기 상점 서버로부터 획득된 상점 식별자에 관한 정보 및 금융 거래 정보를 이용하여 구매 메시지를 작성하는 단계;
    상기 상점 식별자에 관한 정보 및 계좌 번호로부터 상기 고객 단말기 상에서 챌린지 메시지를 생성하는 단계;
    상기 챌린지 메시지를 카드 판독기에서 수신하고 상기 챌린지 메시지로부터 값을 생성하는 단계;
    상기 집적 회로 카드와 상기 카드 판독기 사이의 통신을 설정하고 상기 값의 적어도 일부로부터 암호문을 생성하는 단계;
    상기 암호문의 적어도 일부로부터 상기 카드 판독기 상에서 인증 토큰을 생성하는 단계; 및
    상기 고객 단말기로부터 상기 네트워크를 통하여 송신용 메시지 내의 상기 인증 토큰의 적어도 일부를 상기 상점 서버로 송신하는 단계
    를 포함하는 인증 방법.
  29. 제28항에 있어서,
    챌린지 메시지를 생성하는 단계는 상기 상점 식별자에 관한 정보, 계좌 번호와, 구매량과 구매 통화 중 적어도 하나로부터 상기 챌린지 메시지를 생성하는 단계를 포함하는 인증 방법.
  30. 제28항 또는 제29항에 있어서,
    챌린지 메시지를 생성하는 단계는 상기 상점 식별자 및 상기 계좌 번호와, 선택적으로 구매량과 구매 통화 중 적어도 하나를 연결시키는 단계를 포함하는 인증 방법.
  31. 제28항 내지 제30항 중 어느 한 항에 있어서,
    챌린지 메시지를 생성하는 단계는 상기 상점 식별자 및 상기 계좌 번호와, 선택적으로 구매량과 구매 통화 중 적어도 하나의 연결을 압축하는 단계를 포함하는 인증 방법.
  32. 제31항에 있어서,
    상기 압축하는 단계는 해시 함수를 적용하는 단계를 포함하는 인증 방법.
  33. 제28항 내지 제32항 중 어느 한 항에 있어서,
    상기 집적 회로 카드는 메모리 및 상기 메모리에 저장된 제1 데이터 객체를 갖고, 상기 제1 데이터 객체에 따라서 상기 암호문의 적어도 일부의 일부분을 선택함으로써 상기 암호문의 상기 적어도 일부로부터 인증 토큰을 생성하는 단계를 더 포함하는 인증 방법.
  34. 제28항 내지 제33항 중 어느 한 항에 있어서,
    상기 집적 회로 카드는 메모리 및 상기 메모리에 저장된 제2 데이터 객체를 갖고, 상기 제2 데이터 객체에 따라서 구매량과 구매 통화 중 적어도 하나로부터 챌린지 메시지를 생성하는 단계를 더 포함하는 인증 방법.
  35. 네트워크를 통해 상품의 판매를 거래하기 위한 네트워크 지불 시스템에서 이용하기 위한 인증 시스템에 있어서,
    상기 네트워크와 통신하는 상점 서버 - 상기 상점 서버는 적어도 제1 품목의 판매 상품을 포함함 - ;
    상기 네트워크와 통신하는 고객 단말기 - 상기 고객 단말기는 상기 제1 판매품목을 검토하기 위한 출력 디바이스, 및 상기 제1 판매 품목을 구매하기 위해 구매 거래를 개시하기 위한 입력 디바이스를 포함하고, 상기 고객 단말기는 상기 상점 서버로부터 획득된 상점 식별자에 관한 정보 및 금융 거래 정보를 이용하여 구매 메시지를 작성하도록 구성되고, 상기 고객 단말기는 상기 상점 식별자에 관한 정보 및 계좌 번호로부터 생성되는 챌린지 메시지를 생성하기 위한 수단을 포함함 - ;
    핸드 헬드 디바이스;
    상기 핸드 헬드 디바이스에서 상기 챌린지 메시지를 수신하고 상기 챌린지 메시지로부터 값을 생성하기 위한 수단
    을 포함하며,
    상기 핸드 헬드 디바이스는 상기 값의 적어도 일부로부터 암호문을 생성하기 위한 수단을 포함하고,
    상기 핸드 헬드 디바이스는 상기 암호문의 적어도 일부로부터 인증 토큰을 생성하기 위한 수단을 포함하고,
    상기 고객 단말기는 상기 네트워크를 통해 송신용 메시지 내의 상기 인증 토큰의 적어도 일부를 상기 상점 서버를 향하여 송신하기 위한 수단을 포함하는 인증 시스템.
  36. 핸드 헬드 디바이스를 이용하여 네트워크를 통해 상품의 판매를 거래하기 위한 인증 방법에 있어서,
    상기 네트워크를 통해 상점 서버와 고객 단말기 사이의 통신을 설정하는 단계 - 상기 상점 서버는 적어도 제1 품목의 판매 상품을 포함함 - ;
    상기 고객 단말기 상에서 상기 제1 판매 품목을 검토하고, 상기 제1 판매 품목을 구매하기 위해 구매 거래를 개시하고, 상기 상점 서버로부터 획득된 상점 식별자에 관한 정보 및 금융 거래 정보를 이용하여 구매 메시지를 작성하는 단계;
    상기 상점 식별자에 관한 정보 및 계좌 번호로부터 상기 고객 단말기 상에서 챌린지 메시지를 생성하는 단계;
    상기 챌린지 메시지를 핸드 헬드 디바이스에서 수신하고 상기 챌린지 메시지로부터 값을 생성하고, 상기 값의 적어도 일부로부터 상기 핸드 헬드 디바이스에서 암호문을 생성하는 단계;
    상기 암호문의 적어도 일부로부터 상기 핸드 헬드 디바이스 상에서 인증 토큰을 생성하는 단계; 및
    상기 고객 단말기로부터 상기 네트워크를 통하여 송신용 메시지 내의 상기 인증 토큰의 적어도 일부를 상기 상점 서버로 송신하는 단계
    를 포함하는 인증 방법.
KR10-2004-7013441A 2002-02-28 2003-02-28 금융 거래에서 이용하기 위한 인증 장치 및 방법 KR20040089682A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GBGB0204620.9A GB0204620D0 (en) 2002-02-28 2002-02-28 Chip authentication programme
GB0204620.9 2002-02-28
PCT/BE2003/000036 WO2003073389A2 (en) 2002-02-28 2003-02-28 Authentication arrangement and method for use with financial transactions

Publications (1)

Publication Number Publication Date
KR20040089682A true KR20040089682A (ko) 2004-10-21

Family

ID=9931909

Family Applications (1)

Application Number Title Priority Date Filing Date
KR10-2004-7013441A KR20040089682A (ko) 2002-02-28 2003-02-28 금융 거래에서 이용하기 위한 인증 장치 및 방법

Country Status (12)

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

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101049072B1 (ko) * 2011-02-17 2011-07-15 (주)케이사인 식별 데이터를 이용하여 맵핑하는 방법
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 (165)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100805341B1 (ko) * 1999-06-18 2008-02-20 이촤지 코포레이션 가상 지불 계정을 이용하여 인터네트워크상에서 상품,서비스 및 콘텐츠를 주문하는 방법 및 장치
US7889052B2 (en) 2001-07-10 2011-02-15 Xatra Fund Mx, Llc Authorizing payment subsequent to RF transactions
US8429041B2 (en) 2003-05-09 2013-04-23 American Express Travel Related Services Company, Inc. Systems and methods for managing account information lifecycles
US8543423B2 (en) 2002-07-16 2013-09-24 American Express Travel Related Services Company, Inc. Method and apparatus for enrolling with multiple transaction environments
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
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
US9031880B2 (en) 2001-07-10 2015-05-12 Iii Holdings 1, Llc Systems and methods for non-traditional payment using biometric data
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
US9024719B1 (en) 2001-07-10 2015-05-05 Xatra Fund Mx, Llc RF transaction system and method for storing user personal data
US7762457B2 (en) 2001-07-10 2010-07-27 American Express Travel Related Services Company, Inc. System and method for dynamic fob synchronization and personalization
US7668750B2 (en) 2001-07-10 2010-02-23 David S Bonalle Securing RF transactions using a transactions counter
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
US7705732B2 (en) 2001-07-10 2010-04-27 Fred Bishop Authenticating an RF transaction using a transaction counter
US9454752B2 (en) 2001-07-10 2016-09-27 Chartoleaux Kg Limited Liability Company Reload protocol at a transaction processing entity
US8960535B2 (en) 2001-07-10 2015-02-24 Iii Holdings 1, Llc Method and system for resource management and evaluation
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
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
US8284025B2 (en) 2001-07-10 2012-10-09 Xatra Fund Mx, Llc Method and system for auditory recognition biometrics on a FOB
US7735725B1 (en) 2001-07-10 2010-06-15 Fred Bishop Processing an RF transaction using a routing number
US8548927B2 (en) 2001-07-10 2013-10-01 Xatra Fund Mx, Llc Biometric registration for facilitating an RF transaction
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
US7587756B2 (en) * 2002-07-09 2009-09-08 American Express Travel Related Services Company, Inc. Methods and apparatus for a secure proximity integrated circuit card transactions
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
KR101048729B1 (ko) * 2004-06-30 2011-07-14 프랑스 텔레콤 다목적 전자 결제 방법 및 시스템
US7318550B2 (en) 2004-07-01 2008-01-15 American Express Travel Related Services Company, Inc. Biometric safeguard method for use with a smartcard
KR101130152B1 (ko) * 2004-07-15 2012-05-09 마스터카드 인터내셔날, 인코포레이티드 비트맵을 이용하여 비접촉식 결제 카드 트랜잭션 변수를 표준화된 데이터 포맷에 통합하는 방법 및 시스템
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
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
US7506812B2 (en) * 2004-09-07 2009-03-24 Semtek Innovative Solutions Corporation Transparently securing data for transmission on financial networks
DE102004049878B4 (de) * 2004-10-13 2006-09-21 Deutscher Sparkassen Verlag Gmbh System und Verfahren zur Überprüfung einer Zugangsberechtigung
US20070288313A1 (en) * 2006-06-09 2007-12-13 Mark Brodson E-Coupon System and Method
US10248951B2 (en) * 2004-12-01 2019-04-02 Metavante Corporation E-coupon settlement and clearing process
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
AU2006294466B2 (en) 2005-09-28 2011-08-18 Visa International Service Association Device, system and method for reducing an interaction time for a contactless transaction
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
US8495380B2 (en) 2006-06-06 2013-07-23 Red Hat, Inc. Methods and systems for server-side key generation
US8364952B2 (en) * 2006-06-06 2013-01-29 Red Hat, Inc. Methods and system for a key recovery plan
US7822209B2 (en) 2006-06-06 2010-10-26 Red Hat, Inc. Methods and systems for key recovery for a token
US8098829B2 (en) 2006-06-06 2012-01-17 Red Hat, Inc. Methods and systems for secure key delivery
US8180741B2 (en) * 2006-06-06 2012-05-15 Red Hat, Inc. Methods and systems for providing data objects on a token
US8332637B2 (en) 2006-06-06 2012-12-11 Red Hat, Inc. Methods and systems for nonce generation in a token
US8589695B2 (en) 2006-06-07 2013-11-19 Red Hat, Inc. Methods and systems for entropy collection for server-side key generation
US8412927B2 (en) 2006-06-07 2013-04-02 Red Hat, Inc. Profile framework for token processing system
US8707024B2 (en) 2006-06-07 2014-04-22 Red Hat, Inc. Methods and systems for managing identity management security domains
US9769158B2 (en) * 2006-06-07 2017-09-19 Red Hat, Inc. Guided enrollment and login for token users
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
US8806219B2 (en) 2006-08-23 2014-08-12 Red Hat, Inc. Time-based function back-off
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
US9038154B2 (en) 2006-08-31 2015-05-19 Red Hat, Inc. Token Registration
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
US8832453B2 (en) 2007-02-28 2014-09-09 Red Hat, Inc. Token recycling
US8639940B2 (en) 2007-02-28 2014-01-28 Red Hat, Inc. Methods and systems for assigning roles on a token
US9081948B2 (en) 2007-03-13 2015-07-14 Red Hat, Inc. Configurable smartcard
FR2914763B1 (fr) * 2007-04-06 2013-02-15 Grp Des Cartes Bancaires Cryptogramme dynamique
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
DE112009000137T5 (de) 2008-01-15 2011-02-17 Visa U.S.A. Inc., San Francisco System und Verfahren zur Datenvervollständigung mit Anschubkennung
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
AU2009311303B2 (en) * 2008-11-06 2015-09-10 Visa International Service Association Online challenge-response
US20100131397A1 (en) * 2008-11-25 2010-05-27 Patrick Killian Providing "on behalf of" services for mobile telephone access to payment card account
US7896247B2 (en) 2008-12-01 2011-03-01 Research In Motion Limited Secure use of externally stored data
EP2192512A1 (en) * 2008-12-01 2010-06-02 Research In Motion Limited Secure use of externally stored data
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
US9715681B2 (en) 2009-04-28 2017-07-25 Visa International Service Association Verification of portable consumer devices
US8401964B2 (en) * 2009-04-28 2013-03-19 Mastercard International Incorporated Apparatus, method, and computer program product for encoding enhanced issuer information in a card
US9038886B2 (en) 2009-05-15 2015-05-26 Visa International Service Association Verification of portable consumer devices
US8534564B2 (en) 2009-05-15 2013-09-17 Ayman Hammad Integration of verification tokens with mobile communication devices
US9105027B2 (en) 2009-05-15 2015-08-11 Visa International Service Association Verification of portable consumer device for secure services
US8893967B2 (en) 2009-05-15 2014-11-25 Visa International Service Association Secure Communication of payment information to merchants using a verification token
ES2338403B1 (es) * 2009-06-02 2011-06-10 Micro Codigos, S.L. Sistema de comunicacion con tarjetas inteligentes que comprende un lector de tarjetaqs inteligentes y un programa intermediartio, y lector de tarjetas adaptado para dicho sistema.
FR2950768A1 (fr) * 2009-09-30 2011-04-01 Xiring Sa Systeme et procede de transaction securisee en ligne
CA2780278A1 (en) * 2009-11-04 2011-05-12 Visa International Service Association Verification of portable consumer devices for 3-d secure services
US9240005B2 (en) * 2009-11-06 2016-01-19 Mastercard International, Incorporated Methods for risk management in payment-enabled mobile device
AU2011207108B2 (en) * 2010-01-19 2014-06-26 Bluechain Pty Ltd Method, device and system for securing payment data for transmission over open communication networks
US9245267B2 (en) 2010-03-03 2016-01-26 Visa International Service Association Portable account number for consumer payment account
JP5589471B2 (ja) * 2010-03-19 2014-09-17 大日本印刷株式会社 ロイヤリティ管理システム，ロイヤリティ管理方法及びトークン
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
US8700895B1 (en) 2010-06-30 2014-04-15 Google Inc. System and method for operating a computing device in a secure mode
US9118666B2 (en) 2010-06-30 2015-08-25 Google Inc. Computing device integrity verification
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
EP2681701A4 (en) 2011-03-04 2014-08-20 Visa Int Service Ass INTEGRATION OF PAYMENT OPTIONS IN SAFE ITEMS OF COMPUTERS
US10534931B2 (en) 2011-03-17 2020-01-14 Attachmate Corporation Systems, devices and methods for automatic detection and masking of private data
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
US8688589B2 (en) 2011-04-15 2014-04-01 Shift4 Corporation Method and system for utilizing authorization factor pools
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
US9607336B1 (en) 2011-06-16 2017-03-28 Consumerinfo.Com, Inc. Providing credit inquiry 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
EP2803022A4 (en) * 2012-01-13 2015-06-24 Ebay Inc 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
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
WO2013166518A1 (en) * 2012-05-04 2013-11-07 Institutional Cash Distributors Technology, Llc Secure transaction object creation, propagation and invocation
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
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
US10664936B2 (en) 2013-03-15 2020-05-26 Csidentity Corporation Authentication systems and methods for on-demand products
US9633322B1 (en) 2013-03-15 2017-04-25 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
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
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
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
US9305149B2 (en) 2014-02-07 2016-04-05 Bank Of America Corporation Sorting mobile banking functions into authentication buckets
US9647999B2 (en) 2014-02-07 2017-05-09 Bank Of America Corporation Authentication level of function bucket based on circumstances
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
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
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
US10049202B1 (en) 2014-03-25 2018-08-14 Amazon Technologies, Inc. Strong authentication using authentication objects
US10050787B1 (en) 2014-03-25 2018-08-14 Amazon Technologies, Inc. Authentication objects with attestation
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
GB2542617B (en) * 2015-09-28 2020-06-24 Touchtech Payments Ltd Transaction authentication platform
SG10201508034PA (en) * 2015-09-28 2017-04-27 Mastercard Asia Pacific Pte Ltd Device For Facilitating Identification Of A Fraudulent Payment Card
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 (zh) * 2016-11-29 2020-05-26 中国银联股份有限公司 一种差错交易的标准化方法及装置
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
US11941065B1 (en) 2019-09-13 2024-03-26 Experian Information Solutions, Inc. Single identifier platform for storing entity data
WO2022250188A1 (ko) * 2021-05-28 2022-12-01 주식회사 유스비 로우레벨 데이터 분석 기반의 이상 금융거래 탐지 시스템 및 그 방법
US20230316275A1 (en) * 2022-04-04 2023-10-05 Capital One Services, Llc Systems and methods for token-based device binding during merchant checkout

Family Cites Families (40)

* 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
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
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 (ja) * 1996-11-19 1998-08-07 Toppan Printing Co Ltd ネットワークを用いた商品販売システム及び電子決済システム
US6247129B1 (en) * 1997-03-12 2001-06-12 Visa International Service Association Secure electronic commerce employing integrated circuit cards
US6868391B1 (en) * 1997-04-15 2005-03-15 Telefonaktiebolaget Lm Ericsson (Publ) Tele/datacommunications payment method and apparatus
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
FR2787273B1 (fr) 1998-12-14 2001-02-16 Sagem Procede de paiement securise
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
AU2202001A (en) * 1999-12-17 2001-06-25 Chantilley Corporation Limited Secure transaction systems
JP2001175737A (ja) * 1999-12-20 2001-06-29 Orient Corp クレジット情報処理システム及び方法並びにクレジット情報処理用ソフトウェアを記録した記録媒体
WO2001059731A1 (en) * 2000-02-09 2001-08-16 Internet Cash.Com Methods and systems for making secure electronic payments
JP3801833B2 (ja) * 2000-02-14 2006-07-26 株式会社東芝 マイクロプロセッサ
JP2001236487A (ja) * 2000-02-21 2001-08-31 Ryutsu Kogaku Kenkyusho:Kk 不正使用防止機能を備えた有価担体ならびに有価担体作成装置および有価担体認証装置
GB0006668D0 (en) * 2000-03-21 2000-05-10 Ericsson Telefon Ab L M Encrypting and decrypting
KR100395296B1 (ko) * 2000-03-21 2003-08-21 권황섭 아이씨 카드를 이용한 복권 서비스 시스템 및 그 방법
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 (ja) * 2000-05-15 2003-04-21 日本電気株式会社 電子商取引システム及び電子商取引方法
WO2002001522A1 (en) * 2000-06-26 2002-01-03 Covadis S.A. Computer keyboard unit for carrying out secure transactions in a communications network
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
GB2374498B (en) * 2001-04-12 2004-02-18 Intercede Ltd Multi-stage authorisation system
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
KR101130152B1 (ko) 2004-07-15 2012-05-09 마스터카드 인터내셔날, 인코포레이티드 비트맵을 이용하여 비접촉식 결제 카드 트랜잭션 변수를 표준화된 데이터 포맷에 통합하는 방법 및 시스템
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
EP3012791A1 (en) 2008-03-10 2016-04-27 Global Blue S.A. Dynamic currency conversion system and method
FR2934910B1 (fr) 2008-08-05 2013-08-16 Inside Contactless Procede de securisation d'une transaction executee au moyen d'un dispositif portable programmable.

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101049072B1 (ko) * 2011-02-17 2011-07-15 (주)케이사인 식별 데이터를 이용하여 맵핑하는 방법
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
EP1865471A2 (en) 2007-12-12
WO2003073389A2 (en) 2003-09-04
ZA200406805B (en) 2005-09-12
EP1479052A2 (en) 2004-11-24
EP1850297B1 (en) 2010-11-17
WO2003073389A3 (en) 2003-12-18
JP4597529B2 (ja) 2010-12-15
EP1479052B1 (en) 2007-10-31
ATE377226T1 (de) 2007-11-15
DE60335049D1 (de) 2010-12-30
DE60317169T2 (de) 2008-08-07
EP2309465B1 (en) 2013-09-04
JP2005519375A (ja) 2005-06-30
EP2309465A1 (en) 2011-04-13
ATE488823T1 (de) 2010-12-15
AU2003209860A1 (en) 2003-09-09
EP1850297A2 (en) 2007-10-31
MXPA04008410A (es) 2005-05-17
EP1850297A3 (en) 2008-03-05
US20050119978A1 (en) 2005-06-02
US10395462B2 (en) 2019-08-27
BR0308111A (pt) 2005-01-04
DE60317169D1 (de) 2007-12-13
GB0204620D0 (en) 2002-04-10
EP1865471A3 (en) 2008-03-05

Similar Documents

Publication Publication Date Title
US10395462B2 (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
US10803692B2 (en) System and method for authorizing financial transactions with online merchants
CN105960776B (zh) 使用有限使用证书进行令牌验证
US20180075452A1 (en) Online payer authentication service
AU2001257280B2 (en) Online payer authentication service
AU2001257280A1 (en) Online payer authentication service
WO2010030362A1 (en) Authentication arrangement and method for use with financial transaction
Pircalab Security of Internet Payments

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid