요약

  • RFC 3504는 IOTP v1을 세 곳의 실행 가능한 지점에서 수리했습니다: DTD 문법, 인증 이후 트랜잭션의 연속성, 그리고 IOTP 서명이 식별할 수 있는 콘텐츠 유형 목록입니다.
  • 정정 사항을 적용하는 것은 구현을 수정된 사양에 맞춘 것입니다. 이는 인증 성공, 서명자 권한, 결제 승인, 정산, 전달, 배포 또는 채택을 증명하지 않습니다.

일부 프로토콜 정정은 문장부호 수정처럼 보입니다. RFC 3504는 한 단어를 '재시작(restarted)'에서 '계속(continued)'으로 바꾸었습니다. 일반 산문에서는 이 차이가 편집적 사안처럼 보일 수 있습니다. 그러나 트랜잭션 상태 머신 안에서는, 소프트웨어가 인증 게이트에 도달한 상업적 맥락을 이어받는지, 아니면 교환이 처음부터 다시 시작된 것처럼 동작하는지를 결정합니다.

이 문서는 2003년 3월에 Internet Standard가 아닌 Informational로 발행되었습니다. IOTP 버전 1 사양들, 특히 방대한 RFC 2801이 공개된 뒤 발견된 오류들을 모은 것이었습니다. IOTP는 인터넷 상거래를 위한 결제 시스템에 독립적인 프레임워크였습니다. 쇼핑, 결제 처리, 전달, 고객 지원은 서로 다른 조직이 수행할 수 있었고, 프레임워크는 소비자와 기업 간 사전 관계를 요구하지 않았습니다.

바로 이 역할 분산 때문에 정확한 프로토콜 의미가 중요해졌습니다. 쇼핑 사이트는 결제 작업을 결제 처리자에게, 전달을 다른 주체에게 맡길 수 있었습니다. 메시지, 컴포넌트, 서명은 독립적으로 운영되는 소프트웨어가 어떤 트랜잭션과 어떤 행위를 다루고 있는지 합의할 수 있을 만큼의 구조를 유지해야 했습니다. 공유 문법이나 상태 언어의 실수는 조직 경계를 넘어 번질 수 있었습니다.

RFC 3504의 첫 번째 정정은PackagedContent에 관한 것이었습니다. 원래 DTD에서Name과Content속성의 유형이 서로 바뀌어 있었습니다. 정정은Name을NMTOKEN으로,Content를CDATA로 바로잡았습니다. 이는 미관상의 메타데이터가 아니었습니다.PackagedContent는 IOTP의 확장 봉투로서, 인증 챌린지와 응답, 주문 설명, 브랜드 데이터, 결제 방식 자료, 영수증, 전달 정보에 등장했습니다.

구 선언으로 생성된 구현은 값에 잘못된 어휘 제약을 부과할 수 있었습니다. 한 파서는 다른 파서가 받아들이는 콘텐츠를 거부할 수 있었습니다. 한 생성기는 자신의 로컬 스키마에는 맞지만 다른 곳에서는 실패하는 값을 내보낼 수 있었습니다. 그렇다면 'RFC 2801 지원'이라는 표현은 버전 질문을 숨기게 됩니다: 인쇄된 DTD에 대한 지원인가, 아니면 정정된 DTD에 대한 지원인가?

두 번째 문법 수정은 표면상 더 작았습니다.Attribute라는 요소가 잘못된 콘텐츠 모델 형식인(ANY)로 선언되어 있었고, 정정된 선언은 단순히ANY였습니다. 유효성 검사기는 무효한 문법이 의도적으로 관대한 것이라고 추론할 수 없습니다. 소프트웨어가 선언을 컴파일하지 못하면 구현자들은 각기 다르게 패치하거나, 검증을 비활성화하거나, 특수 사례를 작성할 수 있었습니다. 정정은 그런 분기된 선택들을 좁혔습니다.

문법 통과는 여전히 제한된 영수증이었습니다. 정정된 DTD를 통과한 문서는 요소 이름, 속성 클래스, 콘텐츠 구조가 수리된 계약과 일치함을 보여줍니다. 그러나 내장된 주장이 참이거나, 상대방이 권한을 가졌거나, 외부 결제 시스템이 돈을 이동시켰음을 보여주지는 않습니다.

세 번째 정정은 상태 경계를 드러냈습니다. RFC 2801은 인증 트랜잭션을 다른 IOTP 트랜잭션과 결합하는 것을 설명했습니다. 원래 문장은 인증이 성공한 후 원래의 IOTP 트랜잭션이 '재시작'된다고 말했습니다. RFC 3504는 그 단어를 '계속'으로 바꾸었습니다.

이 정정은 게이트를 가로질러 정체성을 보존했습니다. 인증은 더 큰 교환 안에서 마주치는 조건이었습니다. 조건이 충족되면 처리는 원래 트랜잭션 맥락에서 앞으로 진행되며, 두 번째 구매를 만들어내거나 이전의 모든 결정을 초기화하지 않습니다. 이 구분은 트랜잭션 식별자, 누적된 컴포넌트, 멱등성 기록, 승인 범위, 그리고 중복 상업 행위의 방지에 중요합니다.

'계속'이라는 말은 여전히 인증이 실제로 성공했다고 주장하지 않습니다. 그 문장은 성공한 경우의 결과를 서술한 것입니다. 실제 시스템은 행위자, 방법, 챌린지, 응답, 트랜잭션에 연결된 별도의 인증 결정을 필요로 했습니다. 또한 인증 성공이 이후 모든 행위를 승인하는 것도 아니었습니다. 결제와 전달은 여전히 자체적인 교환, 역할, 영수증을 가졌습니다.

네 번째 정정은 IOTP 서명에 관한 것이었습니다. RFC 2801은 서명Attribute가 어떤 IOTP 서명 유형을 나타내는지 명시하도록 요구했습니다. 원래 목록은 오퍼, 결제, 전달, 인증 요청과 응답, 그리고 ping 요청과 응답을 다루었습니다. 이 목록에는AuthenticationStatus,InquiryRequest,InquiryResponse가 빠져 있었습니다.

RFC 3504는 세 항목을 모두 추가하고 역할 표를 확장하여 어떤 역할이든 이를 사용할 수 있게 했습니다. 구 목록을 완전한 것으로 취급한 검증자는 정정된 사양이 허용하는 서명 유형을 거부할 수 있었습니다. 더 관대한 검증자는 명확한 분기 규칙 없이 이를 받아들일 수 있었습니다. 정정은 유형 표시자와 서명 대상 IOTP 콘텐츠 클래스 간의 공유 매핑을 복원했습니다.

유형 인식은 서명 검증이 아니었고, 서명 검증은 서명자가 상업적 권한을 가졌다는 증명이 아니었습니다. 진짜 inquiry 응답조차 어떤 출처로부터의 프로토콜 상태를 보고하는 것일 뿐, 그것만으로 은행이 자금을 정산했거나, 전달 처리자가 물품을 이송했거나, 고객이 결과를 수용했다는 증명이 되지 않습니다. 영수증 사다리에는 더 많은 단계가 있었습니다.

RFC 3504는 나열된 오류들이 특별히 보안 관련이 아니라고 서술한 뒤, 곧바로 정정되지 않은 사양 오류로 인한 잘못된 구현이 보안을 저해할 수 있다고 경고했습니다. 이 겉보기 긴장은 시사적입니다. 이 실수들은 새로운 암호 알고리즘을 도입하거나 이름 붙은 취약점을 발표하지 않았습니다. 대신 보안 민감 처리가 의존하는 문법, 상태 전이, 분기 표를 변경했습니다.

이것이 바로 정정이 실행 가능한 의존성이 될 수 있는 이유입니다. 운영자는 'RFC 2801 구현'이라고 충분히 기록할 수 없습니다. 빌드에는 사양 번들이 필요합니다: 기초 문서, 적용된 정정 집합, 파서 또는 스키마 산출물, 그리고 변경된 동작에 대한 테스트. 그러한 근거 없이는 두 개의 '준수' 주장이 서로 다른 기계를 가리킬 수 있습니다.

메타데이터의 역사는 또 다른 층위를 더합니다. RFC 3504의 헤더는 RFC 2801을 업데이트한다고 선언하지 않습니다. RFC Editor의 현재 정정 2947번, 향후 문서 업데이트를 위해 보류 중인 것은, 규범적 변경을 만들기 때문에Updates: 2801로 표시되어야 한다고 말합니다. 정정 본문은 관계 메타데이터가 그 힘을 완전히 표현하지 못하는 상태에서도 존재했습니다.

그렇다고 모든 정정이 은밀하게 규범적인 것은 아닙니다. 소비자가 정정 링크를 무해한 주석이나 자동 법칙으로 취급하기보다 상태, 출처, 범위를 검토해야 한다는 뜻입니다. 실행 가능한 문법과 상태 언어에 대한 정정은 명시적 채택과 추적 가능한 구현 근거를 필요로 합니다.

따라서 정직한 근거 사슬은 정확한 출처 판과 정정 집합에서 시작합니다. 재현 가능한 파서 또는 스키마 빌드, 특정 문서의 수용, 트랜잭션 정체성의 보존, 기록된 인증 결정, 선언된 서명 유형의 인식, 암호학적 검증, 상업 행위의 승인, 외부 결제 또는 전달 영수증으로 이어집니다.

각 단계는 서로 다른 질문에 답합니다. 올바른 문법은 메시지가 해석될 수 있음을 말합니다. 계속은 어떤 트랜잭션 맥락이 살아남는지를 말합니다. 유형 표시자는 서명이 어떤 콘텐츠 클래스를 다룬다고 주장하는지를 말합니다. 그 중 어느 것도, 단독으로든 합쳐서든, 구매가 결제되고 이행되었음을 말하지 않습니다.

RFC 3504의 역사적 중요성은 바로 그 겸손함에 있습니다. 여섯 페이지의 정정이 자신이 조율하는 상거래의 결과가 되지 않으면서도 훨씬 큰 프로토콜의 동작을 어떻게 결정하는지 보여줍니다. 정정은 구현이 하도록 되어 있던 것을 수리했습니다. 현실은 여전히 자체 영수증을 요구했습니다.

출처