요약

  • CyberCash 0.8에서 구매자 프로그램은 카드 정보를 서명·암호화하고, 가맹점은 그 메시지를 서버로 전달했다. 매입 은행이 승인 결정을 내렸다.
  • 가맹점에 돌아오는 응답에 카드 번호 일부를 담을지 전체를 담을지는 은행이 정했다. 거래 분쟁에는 별도 암호와 기록을 수반하는 번호 조회 절차가 있었다.

계산대가 본 것은 봉인된 메시지였다

인터넷 상점의 계산대에는 결제 성공 여부가 필요하다. 모든 고객의 카드 번호를 수집할 필요까지 있는 것은 아니다. RFC 1898은 1990년대 중반 CyberCash가 이 경계를 어떻게 그었는지 보여준다. 고객은 등록된 카드를 고르고, 고객 프로그램은 카드 정보와 청구서 해시를 서명하고 암호화했다. 상점은 자신의 승인 정보를 덧붙여 서버에 보냈다. 서버가 양쪽 서명을 확인한 뒤 매입 은행에 승인 요청을 전달했고, 은행의 답이 다시 돌아왔다.

문서가 인터넷 초안으로 처음 공개된 날은 1995년 7월 8일, 정보 제공용 RFC로 나온 때는 1996년 2월이다. 0.8판은 이미 운영 중인 신용카드 결제를 설명했다. 전자 현금은 이후 버전의 계획이었다. 새로운 웹 화면 뒤에서 카드 승인 권한은 여전히 은행에 있었다.

가맹점용 CM6 응답은 그 권한을 숫자로 드러냈다. card-prefix는 앞 두 자리와 뒤 네 자리만 보여준다. 전체 번호인 card-number를 돌려주는 선택지도 있었다. 어느 쪽을 쓸지는 가맹점 은행의 재량이었다. 소금을 섞은 카드 해시는 번호를 알려주지 않고도 같은 카드의 거래를 묶게 했다. 거래를 식별하는 기능과 전체 결제 자격 정보를 쥐는 권한을 분리한 것이다.

분쟁이 생기면 다시 열 수 있는 봉투

가맹점은 이의를 처리할 때 원래 고객 메시지를 보관했다가 CD1 번호 조회를 보낼 수 있었다. 별도 암호를 입력해야 했고, 성공한 CD2 응답은 카드 자료를 돌려줄 수 있었다. 규약은 누가 조회했는지 기록하고 과도한 조회를 표시할 수 있다고 적었다. 실제 조회량과 경고 처리 결과를 보여주는 운영 기록은 이 문서에 없다. 그 기록이 있어야 감시 장치가 현장에서 얼마나 작동했는지 평가할 수 있다.

CyberCash가 만든 것은 영구 봉인이 아니라 두 단계의 열쇠 관리였다. 은행은 평소 응답에 담길 정보량을 정했고, 서버는 예외 요청을 받으며 흔적을 남겼다. 결제 버튼 아래 숨은 실질적 정책은 카드 번호를 언제 누구에게 보여주는가였다.

출처