같은 120파운드 두 번, 장부는 하나를 ‘재시도’라 불렀다

Summary

• 10월 27일 공개된 개별 Internet-Draft 개정판은 decision.operationKey로 하나의 의도된 작업을 식별한다. 같은 작업을 다시 시도하면 키를 유지하고, 별개의 결제라면 새 키를 쓴다.
• 초안의 사례에서는 500파운드 한도에서 300파운드가 지출됐고 120파운드가 예약돼 있다. 원래 작업의 재시도는 총 420파운드지만 새 120파운드 결제는 540파운드가 된다.

자동 결제 담당 에이전트가 답장을 기다리다 지쳤다. 120파운드 지급 요청을 다시 보낸다. 첫 허가는 여전히 장부에 잡혀 있으므로 같은 돈을 또 예약할 이유는 없다. 그런데 의뢰인이 같은 대상에게 같은 120파운드를 한 번 더 보내라고 했다면? 화면에는 똑같은 문장이 찍혀도 예산에는 새로운 부담이 생긴다. 내용만 비교하는 장부는 이 두 번째 부담을 ‘재시도’라는 이름으로 숨길 수 있다.

새 개정판 원문은 작업의 내용과 작업의 의도된 횟수를 분리한다. 에이전트는 하나의 계획된 작업에 decision.operationKey를 붙여 서명된 요청에 담는다. 응답이 없어 재전송할 때는 같은 키를 쓰고, 별도의 지급 지시에는 다른 키를 쓴다. 키는 limitDigest가 가리키는 위임 한도의 범위 안에서 해석된다. 어느 결제가 어느 권한을 썼는지 따라갈 수 있게 하는 장치다.

이전 -01판은 요청 다이제스트로 재시도를 알아봤다. 하지만 다이제스트는 행위, 인수, 대상을 반영한다. 두 번 독립적으로 지시한 결제가 이 세 항목에서 같을 수 있다. 개정 이력은 그 경우 두 번째 지급이 첫 번째의 재시도로 오인돼 누적 사용액에서 빠질 수 있었다고 설명한다.

초안의 숫자 예시를 보면 말장난의 비용이 드러난다. 5만 펜스 한도 중 3만 펜스는 이미 쓰였고, 1만2000펜스 지급 허가는 답변을 잃은 채 예약 상태다. 같은 작업 키를 가진 재시도라면 지출과 예약의 합계는 4만2000펜스다. 새로운 키로 또 1만2000펜스를 지급하면 5만4000펜스가 돼 한도를 넘는다. 요청 다이제스트가 같다는 사실로 이 산수를 바꿀 수는 없다.

새 형식은 미결 허가마다 작업 키, 요청 다이제스트, 금액을 held 목록에 적도록 한다. 목록의 합계는 예약 총액과 맞아야 한다. 검증자는 이미 쓴 돈, 예약된 돈, 새로 청구한 돈으로 withinLimit을 계산한다. 첫 결제의 응답이 없다는 사실만으로 예약을 지우지도 않는다. 같은 작업의 후속 기록이 실제 효과를 확인하면 지출로 옮기고, 효과가 없었다고 확인하면 예약을 해제한다.

기록을 보관한 쪽은 상태의 개정 번호도 비교한다. 뒤의 허가가 앞의 예약을 아직 보지 못한 낡은 잔액을 읽었다면, 한 예산을 두 번 약속한 틈이 보인다. 한도를 넘는 허가도 기록에서 지우지 않고 초과한 결정으로 남긴다.

IETF 문서 페이지는 이를 I-D Exists 상태의 개별 Internet-Draft로 표시한다. 작은 키 하나를 제안하는 문서지만, 묻는 것은 크다. 남의 돈을 쓰도록 허락받은 기계의 두 번째 약속을 누가 셀 것인가?