요약

  • RFC 3506은 바우처를 논리적으로 관리되는 유효 바우처 집합(VVS) 안의<issuer, promise, holder>로 정의했으며, 발행·양도·제시·소비는 각기 다른 방식으로 그 상태를 바꿨다.
  • XML, 서명, 스마트 카드, API는 시스템을 기술하거나 운영할 수 있었지만, 그 어느 것 하나만으로 현재 소유권, 성공적 교환, 약속된 재화의 인도를 증명하지는 못했다.

콘서트 티켓이 작은 디지털 파일로 존재한다고 상상해 보자. 소유자는 친구에게 사본을 이메일로 보내고 자신도 다른 사본을 보관한다. 두 파일에는 같은 좌석, 시간, 발행자가 들어 있다. 바이트의 보유가 티켓의 보유라면, 예약된 좌석 하나에 두 명의 유효한 청구자가 생긴다. 파일 형식은 그 충돌을 완벽하게 기술할 수 있지만, 해결하는 데는 아무 일도 하지 못할 수 있다.

RFC 3506은 그 어려움에서 출발했다. 2003년 3월 정보성 RFC로 발행된 이 문서는 로열티 포인트, 쿠폰, 상품권, 이벤트 티켓, 전화 카드, 배송 명세서를 아울러 살폈다. 이 객체들은 서로 다른 것을 약속했지만, 모두 가치에 대한 설명과 그것을 청구할 권리를 구별할 방법이 필요했다.

문서의 형식적 전환은 간결했다.I를 발행자,P를 발행자의 약속,H를 보유자라 하자. 바우처는 세 부분의 관계<I,P,H>였다. 약속은 50포인트로 상품 하나를 받을 수 있다거나, 쿠폰이 구매 금액을 절반으로 줄인다거나, 특정 좌석이 예약되었다고 말할 수 있었다. 그것은 일상 언어나 XML 속성으로 표현될 수 있었다. 그러나 약속 텍스트는 튜플의 한 구성원일 뿐이었다. 그것은 소유권의 전체 사실을 담고 있지 않았다.

네 역할이 권한을 나눴다. 발행자는 바우처를 생성하고 약속을 보증했다. 보유자는 그것을 소유하고, 양도하거나 교환했다. 수령자는 그것을 검사하고 약속된 서비스를 수행했다. 바우처 거래 시스템(VTS) 제공자는 한 바우처가 여러 보유자에게 배정되거나 그 유형이 허용한 횟수보다 더 많이 사용되지 않도록 하는 조건을 유지했다. 각 역할은 서로 다른 영수증을 제공했다. 어느 역할도 다른 역할의 권한을 조용히 물려받지 않았다.

시스템의 중심은 유효 바우처 집합(VVS)이었다. RFC 3506은 이를 처음에는 비어 있는 유효한<I,P,H>튜플의 논리적 집합으로 정의했다. “논리적”이라는 말이 중요했다. 그 집합은 중앙 서비스, 여러 발행자 운영 서버, 사용자가 휴대하는 변조 방지 카드에 존재할 수 있었다. RFC는 하나의 물리적 아키텍처가 이미 승리했다고 가장하지 않고 불변 조건을 명시했다.

발행은 발행자의 의도에 따라 새 튜플을 그 집합에 추가했다. 양도는 또 다른 파일을 만들어 기존 보유자가 자기 파일을 잊기를 바라는 방식이 아니었다. 그것은 원래 보유자의 의도를 반영해<I,P,H>를<I,P,H'>로 다시 썼다. 옛 설명과 새 설명은 캐시나 메시지에 여전히 보일 수 있었지만, VTS가 어느 보유자를 현재 보유자로 취급하는지는 오직 상태 전이에 의해 결정되었다.

교환은 두 작업으로 나뉘었다. 제시는 소유권을 보존한 채 튜플을 노출했으며, 반복해서 보여줄 수 있는 면허나 여권에 적합했다. 소비는 튜플을 삭제하거나 무효화하거나 남은 사용 횟수를 줄였으며, 콘서트 티켓이나 전화 카드에 적합했다. 이 구분은 “교환됨”이라는 말이 그 접촉 후에도 권리가 살아남았는지를 숨기지 않게 했다.

보안 요구 사항은 모델에서 따라 나왔다. 오직 발행자만 유효한 바우처를 생성할 수 있었다. 오직 현재 보유자만 양도나 교환을 시작할 수 있었다. 유통은 권한 있는 보유자 재작성 외에는 바우처를 변경할 수 없었다. 소비된 바우처는 다시 교환될 수 없었다. 특정 바우처는 그 자체 조건이 다중 사용을 허용하지 않는 한 어느 순간에도 하나의 유효한 보유자를 가져야 했다.

이는 단지 서명 요구 사항이 아니었다. RFC 3506은 발행자 서명 인증서가 양도 불가능한 바우처에는 작동할 수 있다고 설명했다.I,P,H를 함께 서명하면 된다. 그러나 양도는H를 바꾸어 원래 서명을 깨뜨렸다. 더 중요하게, 중복 교환은 여전히 온라인 상태 확인이나 변조 방지 장치를 필요로 했다. 암호학은 진술을 인증할 수 있었지만 배타성과 현재 상태는 해결되지 않은 채로 남았다.

프라이버시와 신뢰는 추가 긴장을 낳았다. 문서는 나중에 바우처를 얻는 사람으로부터 현재 및 이전 보유자를 숨길 것을 권고했다. 또한 발행자와 바우처 진위를 판단할 방법을 원했다. 따라서 유용한 시스템에는 중복을 거부하기에 충분한 이력과 모든 소지자에게 완전한 소유 추적을 노출하지 않을 만큼 충분한 경계가 모두 필요했다.

탈중앙화에 대한 언어는 유난히 직접적이었다. RFC 3506은 하나의 중앙 조직이 지나치게 취약할 것이므로 보편적 브로커나 인증자를 가정해서는 안 된다고 말했다. 그러나 그렇다고 해서 하나의 탈중앙화 기법을 요구하는 것으로 응답하지도 않았다. 오프라인 스마트 카드와 온라인 서비스는 서로 다른 상충 관계에 직면했다. 저자들은 그 시점에 보편적 양도 프로토콜을 표준화하지 않기로 했다.

그 절제는 우유부단이 아니라 아키텍처적이었다. 작업은 세 가지 가능한 계층을 분리했다. 바우처 양도 프로토콜, 공통 애플리케이션 인터페이스, 일반 바우처 언어다. 공통 의미론은 진전할 수 있었고, 구현은 가장 어려운 신뢰와 성능 문제를 근거를 통해 해결할 자유를 유지했다.

RFC 4153은 2005년 설명 계층을 제공했다. 그 XML 바우처 컴포넌트는 약속, 가치, 제한을 정의하고 관련 발행자 및 제공자 정보를 식별했다. 그리고 결정적 경계를 명시했다. 바우처 컴포넌트는 바우처가 아니었다. 많은 바우처 인스턴스가 하나의 컴포넌트를 공유할 수 있었다. 컴포넌트를 복사하면 유효한 권리가 아니라 설명이 늘어날 뿐이었다.

RFC 4153은 컴포넌트를 신뢰의 뿌리로 취급하고, 이를 변경하면 위조 바우처가 유효해 보이게 될 수 있다고 경고했다. 안전한 전달이나 객체 서명이 그 설명을 보호할 수 있었다. 그러나 인스턴스별 통제, 즉 소유권, 복제, 중복 교환은 보통 그 바깥에 남았다. 유효한 컴포넌트는 “어떤 제한 아래 무엇이 약속되는가?”에 답했다. “누가 현재 사용되지 않은 인스턴스를 소유하는가?”에는 답하지 않았다.

RFC 4154는 애플리케이션 인터페이스를 제공했다. 지갑은 서로 다른 VTS 구현 전반에서 발행, 양도, 소비, 제시를 위해 균일한 메서드를 호출할 수 있었다. 이후 API는 RFC 3506의 상태 논리를 보존했다. 발행은 인스턴스를 추가하고, 양도는 한 보유자로부터 제거해 다른 보유자를 위해 저장하며, 소비는 제거하고, 제시는 그대로 둔다.

RFC 4154에 대한 IESG 주석은 또 다른 경계를 가시화했다. 인터페이스는 VTS 플러그인이 사용자에 의해 신뢰된다고 가정했지만, 애플리케이션 인증을 명시하지 않았다. API는 추가 인증 메커니즘 없이는 안전하지 않았다. 따라서 올바른 형태의 호출은 호출자의 권한, 플러그인의 신원, 커밋된 전이, 수령자의 이후 수행을 증명하지 못했다.

근거의 사다리는 바우처 파일보다 길다. 먼저 약속 설명이 온다. 다음은 지명된 발행자와 제공자에 대한 신뢰다. 그다음 VVS 안의 살아 있는 바우처 인스턴스다. 그다음 현재 보유자가 어떤 작업을 승인했음을 입증하는 것이다. 그다음 수용되고 커밋된 상태 전이다. 그 후에야 수령자가 재화나 서비스를 인도할 수 있고, 인도 후에야 사용자나 기업이 결과를 관찰할 수 있다.

“바우처”라는 이름은 나중에 BRSKI를 포함한 장치 온보딩 프로토콜에도 등장했다. 그 어휘 충돌은 연속성을 만들지 않는다. RFC 3506은 쿠폰, 티켓, 포인트 같은 양도 가능한 상업적 권리에 관한 것이었다. 장치 바우처는 다른 프로토콜 계열에서 온보딩 주장을 묶는다. 공유된 단어는 공유된 상태 기계가 아니다.

RFC 자체도 채택을 증명하지 않는다. 정보성 발행은 모델과 그 요구 사항을 기록한다. 상인들이 그것을 배포했는지, 독립 제공자들이 상호운용했는지, 사용자들이 그 신뢰 모델을 받아들였는지, 수령자들이 약속한 것을 인도했는지는 보여주지 않는다. 그런 주장에는 구현, 운영, 결과 근거가 필요하다.

오래 남는 기여는 더 좁고 더 유용하다. RFC 3506은 표현이 현실을 삼키도록 두지 않았다. XML은 약속을 기술할 수 있었다. 서명은 진술을 보호할 수 있었다. API는 전이를 요청할 수 있었다. 카드나 서버는 상태를 보관할 수 있었다. 교환 가능한 권리는 시스템의 경계 지어진 행위자들이 유효한 관계를 유지하고 그것을 존중할 때에만 존재했다.

복사된 파일은 완벽하게 진본이면서 경제적으로는 비어 있을 수 있다. 유효한 권리는 독자에게 가장 가까이 있는 바이트가 아니다. 그것은 배타성을 보존하는 전이를 가진 상태 시스템 안의 현재적이고 권한 있는 위치다. 그것이 RFC 3506이 “바우처”라는 명랑한 단어 아래에 깔아 둔 규율이었다.

출처