요약

  • RFC 3505는 전자상거래 필드의 공통 계층 구조에 대한 요구사항을 정의해, 전자지갑·폼·백엔드 시스템이 결제 관련 데이터를 번역 부담을 줄이며 교환할 수 있게 했습니다.
  • 이 문서는 전송 보안, 개체 무결성, 결제 승인, 스마트카드 시스템을 대체하지 않는다고 명시했습니다. 인식된 필드 이름은 의미를 증명할 뿐, 상인 신원·사용자 동의·청구 실행·정산을 증명하지 않습니다.

초기 결제 페이지의 문제는 평범해 보였습니다. 한 상인은 필드를 “surname”이라 부르고, 다른 상인은 “last_name”이라 부르며, 또 다른 상인은 같은 데이터를 자체 계층 구조 안에 감춰두었습니다. 사람은 라벨을 해석해 주소나 카드 정보를 다시 입력할 수 있었지만, 소프트웨어 지갑은 어느 입력란이 무엇을 뜻하는지 신뢰할 수 있게 추론할 수 없었습니다.

2003년 3월 Informational 문서로 공개된 RFC 3505는 이 마찰을 상호운용성 문제로 다뤘습니다. ECML 버전 2는 소비자–상인 및 기업 간 교환을 위한 계층적으로 조직된 Payment Processing 주체를 제공할 예정이었습니다. 이는 기존 HTML 폼 필드 작업을 XML, 추가 결제 수단, 백엔드 시스템으로 확장하는 것이었습니다.

의도된 범위는 넓었습니다. 비용, 영수증, 통화, 카드, 결제, 은행 또는 통신 데이터, 신용카드·전자수표·ACH·휴대폰·PDA 결제 유형, 지갑·마켓플레이스·기업 시스템까지였습니다. 그러나 설계 원칙은 절제이기도 했습니다. 버전 1.1 이상의 필드를 실용적인 범위에서 최소한만 추가하고, 기존 기능을 유지하며, URI·계층화·확장성이라는 더 넓은 웹 아키텍처를 활용하라는 것이었습니다.

이것은 어휘 계약이었습니다. 지갑이 배송지 도시에 대한 구조화된 이름을 인식하면, 사람의 라벨을 추측하지 않고 값을 제안할 수 있었습니다. 백엔드 시스템이 결제 계층 구조를 인식하면 같은 개념을 자체 처리 흐름에 매핑할 수 있었습니다. 공유된 이름은 독립적으로 개발된 소프트웨어 간 번역 비용을 낮췄습니다.

RFC는 이 편의를 보안과 혼동하지 않았습니다. ECML v2가 TLS, SET, EMV, XML, IOTP의 대안이 아니라고 명시했습니다. 이 기술들은 서로 다른 역할을 담당했습니다. 기밀성, 부인 방지 트랜잭션, 결제 방식 선택, 스마트카드 지원, 거래 흐름 등입니다. ECML은 데이터에 이름을 붙였을 뿐, 데이터를 둘러싼 모든 통제를 흡수하지 않았습니다.

이 구분이 특히 중요했던 이유는 제안된 필드 대부분이 민감했기 때문입니다. 이름, 주소, 계정 식별자, 카드 정보, 사용자 자격 증명은 지갑이 자동으로 이해하는 순간 대규모로 노출되기 더 쉬워질 수 있었습니다. 따라서 RFC 3505는 ECML이 전송 인프라와 정보를 저장·제공하는 애플리케이션에 의존한다고 명시했습니다. 어휘 자체가 보안 메커니즘을 발명할 필요는 없었지만, 사양은 구현자에게 경고해야 했습니다.

잘 형성됨(well-formedness) 역시 동일하게 한정됐습니다. 요구사항은 DTD와 가능하면 스키마, 테스트된 XML 예제, 이전 어휘와의 비교를 요구했습니다. 이 검사를 통과한 문서는 이름과 구조가 문법을 따른다는 것만 증명합니다. 카드 번호가 사용자의 것임을, 가격이 정직함을, 상인이 실재함을, 처리기가 결제를 승인했음을 증명하지는 않습니다.

한 상세 요청은 마이그레이션 문제를 드러냈습니다. ECML v2는 표준화된 필드를 기존 상인 필드에 매핑하는 숨겨진 번역 필드를 포함해, 기존 코드를 다시 쓰지 않고도 지원할 수 있게 할 수 있었습니다. 도입 비용은 줄었지만, 사용자가 보지 못하는 계층 사이에서 민감한 데이터를 옮길 수 있는 보이지 않는 매핑을 의미하기도 했습니다. 호환성은 동의가 아닙니다.

RFC 4112는 2005년 ECML v2 사양을 제공했습니다. 계층적 필드 이름을 정의하고 XML을 예시 문법으로 제시하면서도 다른 인코딩과 프로토콜을 허용했습니다. 적합성(conformance)은 사람이 보는 라벨이 아니라 전송되는 이름과 구조를 규율했습니다. 상인은 공통 기계 의미를 유지하면서 현지 언어로 표시할 수 있었습니다.

필드 표의 최소 크기는 유효성 검사가 아니라 수용 능력 의무였습니다. 폼은 최소한 주어진 길이를 받아야 했지만, 더 짧거나 긴 값도 여전히 합법적일 수 있었습니다.MIN을 유효한 이름·전화번호·주소의 증거로 다루는 것은 상호운용성 하한을 거짓 신원 규칙으로 바꾸는 일입니다.

RFC 4112는 질의(query)와 단언(assertion) 모드도 정의했습니다. 질의는 값을 요구할 수 있고, 단언은 값을 제공할 수 있습니다. 이 모드는 메시지의 의도를 서술할 뿐, 질문자를 인증하거나 단언된 값을 참으로 만들지 않습니다. 자동 지갑이 응답하기 전에 별도의 정책이 이 상대방·목적·시점이 정보 제공을 정당화하는지 여전히 판단해야 했습니다.

웹 사용에서Ecom_SchemaVersion은 어떤 필드 어휘가 존재하는지 식별했습니다. 이 표식은 소프트웨어가 올바른 해석을 선택하도록 돕고 모든 ECML 웹 트랜잭션에서 요구됐습니다. 그러나 상인을 식별하거나, 페이지를 검증하거나, 채널을 보호하지는 않았습니다. 버전 인식은 엔드포인트 인증이 아닙니다.

여러 페이지에 걸친 폼은 또 다른 위험을 만들었습니다. 상거래 상호작용이 사실상 끝난 뒤에도 자동화가 개인 데이터 채우기를 계속할 수 있었습니다. RFC 4112는 추가 승인이 있을 때까지 자동 로직에 멈추라는 힌트로Ecom_TransactionComplete를 도입했습니다. 이 필드는 공개 범위를 한정했습니다. 그 이름이 결제가 승인·캡처·정산·이행되고 고객이 수락했음을 인증하지는 않습니다.

보안 절은 외부 의존성을 명시적으로 유지했습니다. 민감한 정보는 기밀성과 무단 수정으로부터의 보호가 필요했습니다. 진위성은 XML 서명이나 CMS 같은 개체 보안, 또는 TLS나 IPsec 같은 채널 보안을 요구할 수 있었습니다. 사양은 가능성을 열거했지만 단일 보편 보호 메커니즘을 정의하지는 않았습니다.

제공에 대한 사용자 통제도 여전히 필요했습니다. 공용 단말의 소프트웨어는 개인 정보 기억을 비활성화할 수 있어야 했습니다. 저장된 데이터에는 보호 옵션이 필요했습니다. 숨김 값과 기본값은 다른 상대에게 반환되기 전에 악의적으로 변경될 수 있었습니다. 표준 구조는 처리를 예측 가능하게 만들었지만, 주변 애플리케이션을 선량하게 만들지는 않았습니다.

따라서 정직한 영수증 사다리는 필드 이름 인식에서 시작합니다. 다음은 구조적 유효성, 인증된 상대방, 사용자가 승인한 제공, 보호된 전송, 애플리케이션 수락, 결제 승인, 정산(클리어링), 전달입니다. 앞의 두 단계에서 곧바로 “결제 완료”로 뛰는 대시보드는 기계 가독성을 상업적 주장으로 바꾸는 것입니다.

공개가 배포를 증명하지도 않습니다. RFC 3505는 요구사항을 기록했고, RFC 4112가 이후 Standards Track 사양을 공개했습니다. 그러나 어느 사실도 브라우저 채택, 지갑 사용, 상인 간 상호운용성, 프라이버시 결과, 성공적인 트랜잭션을 입증하지 않습니다. 그 주장에는 구현과 운영 증거가 필요합니다.

ECML의 좁은 기여는 여전히 의미가 있었습니다. 모든 계층을 해결한다고 주장하지 않으면서 한 종류의 마찰을 줄였습니다. 교훈은 이것입니다. 의미 조율은 좋은 시스템을 더 쉽게 연결하게 할 수 있고, 동시에 안전하지 않은 시스템이 데이터를 더 빨리 노출하게 만들 수 있습니다. 공통 이름은 하나의 역량입니다. 그 역량이 승인되고, 보호되고, 경제적으로 완결되는지는 별개의 결정입니다.

출처