Selo 초안, 계좌 변경에 사람의 승인 요구

Summary

10월 31일 제출된 Selo 개인 인터넷 초안은 법인에 속한 에이전트가 구조화된 접속 계약을 협상하는 설계를 담았다. IETF가 채택한 표준이나 완성된 프로토콜은 아니다.
소유자가 서명한 권한 범위를 독립적인 결정론적 검사기가 확인한 뒤 양쪽 법인이 서명한다. 양측의 종단 간 시험 확인이 있어야 운영 환경 접근 자격이 나온다.
지급 정보 변경에는 새 서명본, 재무 역할을 가진 사람의 승인, 두 에이전트를 거치지 않는 직접 통지, 취소할 수 있는 대기 기간, 새 계좌로 첫 지급을 하기 전 지급 측 사람의 확인이 필요하다.

계약서의 한 칸이 현금의 행선지를 바꾼다

공급업체가 주문용 API 주소를 바꾸면 다시 연결 시험을 할 수 있다. 입금 계좌를 바꾸면 다음 송금의 수취인이 달라진다. Selo가 제시한 구매자와 공급업체의 예시는 바로 이 차이를 드러낸다. 에이전트가 주문과 청구 조건을 협상하더라도, 계좌 변경은 일반적인 설정 갱신으로 처리하지 않는다.

초안은 지급 정보를 보호되는 상업 조건에 넣는다. 에이전트에게 주어진 권한만으로는 변경을 승인할 수 없다. 재무 역할을 맡은 사람이 새 계약 버전을 승인하고, 지급 측 사람들은 두 에이전트를 모두 우회하는 경로로 통지를 받는다. 대기 중에는 기존 계좌가 유효하며 어느 쪽이든 변경을 취소할 수 있다. 새 계좌로 처음 돈을 보내기 전에는 지급 측 사람이 다시 확인한다. 본문에 나온 72시간은 대기 기간의 예시이지 일률적인 규칙이 아니다.

이 설계에서 계약 당사자는 에이전트가 아니라 회사다. 에이전트는 조건을 제안할 수 있지만, 격리된 검사기가 소유자가 서명한 한도를 통과시켜야 서명 단계로 간다. 서명 뒤에도 양쪽 실행 환경이 실제 데이터 흐름을 시험하고 각각 확인해야 운영용 자격이 생긴다.

이후 공급자 게이트웨이는 호출마다 계약의 활성 버전, 호출자 키에 묶인 단기 토큰, 허용된 작업과 필드 및 한도를 확인한다. 공급자의 플랫폼 자격은 공급자 쪽 금고에 남는다. 이 장치는 API 접근을 제한한다. 계좌 변경으로 생길 손실을 승인할 권한까지 기계에 주지는 않는다.

계좌 변경은 초안의 설명용 사례이며 실제 사기 사건을 보고한 내용이 아니다. Selo 자체가 송금을 처리하지도 않는다. IETF 기록상 개인 초안으로, 표준화 절차에서 공식 지위를 얻은 문서는 아니다. 그래도 설계의 질문은 현실적이다. 기계가 거래를 빠르게 연결할 때 돈의 목적지를 바꿀 마지막 권한은 누구에게 남는가.