자격증명 관리
자격증명 관리는 매우 엔지니어링적으로 들립니다——FayID 의 발급、서명、철회、갱신, 각 항목 모두 구체적인 알고리즘과 키 프로토콜에 관여합니다. 그러나 본 청사진에서는 자격증명 관리가 가치관 안에 놓이며, 기술적 의제가 아닙니다.
이유는 이러합니다: Faying Protocol 이 존재하는 까닭은 "행동이 누구의 책임인가"라는 일을 명시적으로 표현하기 위함입니다. 이 일의 모든 기술적 담지를, 구체적 프로토콜 차원에 떨어뜨리면、곧 자격증명입니다. 자격증명은 두 가지 질문에 답합니다:
이 순간 이 Fay 는 그것이 자칭한 그 Fay 인가? 이 순간 이 Fay 는 여전히 그의 Human Prime 의 인가를 받고 있는가?
두 질문 모두 엔지니어링 문제가 아니라、책임 문제입니다. 일단 자격증명이 위조될 수 있거나、남용될 수 있거나、Human Prime 외의 어떤 제3자가 몰래 발급할 수 있게 되면, Faying Protocol 의 모든 가치는 한순간에 영이 됩니다——Human Prime 은 더 이상 책임의 진정한 보유자가 아닙니다.
구체적인 알고리즘、서명 형식、키 프로토콜 등 기술 디테일은 프로토콜 규범 문서와 schema 의 범주에 속하며, 본 장에서는 펼치지 않습니다. 본 장은 자격증명 관리에서 양보될 수 없는 몇 가지 입장만을 선언합니다.
FayID 는 Fay 가 Faying State 에 진입하는 신원 기초
FayID 는 Fay 의 iFay 프레임워크 안에서의 통일된 유일 신원 식별자입니다. Faying Protocol 의 모든 감호 계약은 FayID 위에 세워집니다. Faying Action 은 "어느 FayID 가 Faying State 에 진입하는지"를 명확히 해야 합니다; Faying State 의 귀책은 "어느 FayID 가 어느 Human Prime 에 귀속되는지"를 명확히 해야 합니다; Faying State 의 퇴출은 "어느 FayID 가 Rogue Fay 로 전환되는지"를 명확히 해야 합니다.
FayID 가 신뢰될 수 없다면, 위의 세 곳의 모든 판단은 의미를 잃습니다.
자격증명 실효는 곧 Faying 실효
제 13 장에 열거된 Faying State → Rogue Fay 자동 전이의 9개 트리거 조건 중, 6번째 항목에는 다음과 같이 명확히 적혀 있습니다:
Fay 신원을 검증할 수 없음（예: FayID 서명 실효）.
이 항목은 9개 중 "마침" 자격증명에 관련된 것이 아니라, 자격증명 관리가 프로토콜 차원에서 우회될 수 없는 구체적 착지점입니다. FayID 의 유효성에 문제가 발생하면, Fay 의 이전 작업이 얼마나 연속적이었든、얼마나 완성에 가까웠든, Faying State 는 즉시 퇴출되어야 합니다:
자격증명 유효성에 대한 의심은 Faying State 가 이미 실효된 것과 동등합니다.
"자격증명이 의심스럽지만 Faying State 는 여전히 성립한다"는 중간 상황은 존재하지 않으며, "현재 작업을 먼저 끝낸 후 자격증명 문제를 처리한다"는 엔지니어링 타협도 존재하지 않습니다.
철회권은 반드시 Human Prime 측에 보유되어야 합니다
자격증명 관리에는 프로토콜 설계상 디테일처럼 보이지만 극히 핵심적인 선택이 하나 있습니다——자격증명의 철회권은 결국 누구에게 귀속되는가? 답은 자명합니다: Human Prime 입니다.
Fay 자신은 자신의 자격증명을 철회할 합법적 경로를 가져서는 안 됩니다——이는 제 13 장 D4 와 동근원이며, Fay 는 자기 결정으로 감호를 이탈할 수 없고, 자기 결정으로 감호 경로를 끊을 수도 없습니다.
제3자 플랫폼、Fay 의 Runtime 공급자、Fay 의 능력 제공자 모두 Human Prime 의 동의 없이 그 FayID 를 철회할 권한을 가져서는 안 됩니다——해당 제3자가 컴플라이언스 의미에서의 권위 기관일 경우는 예외입니다（제 13 장 트리거 조건 8번 참조）.
Human Prime 은 항상 대칭적이고、도달 가능하며、감사 가능한 철회 통로를 보유해야 합니다. 철회 동작의 도달성은 Faying Action 을 발기하는 도달성보다 낮아서는 안 됩니다. 이는 Faying Protocol 의 "대칭성" 원칙이 자격증명 차원에서 구체적으로 착지된 것입니다: 감호의 구축과 감호의 철회는 동등하게 도달 가능한 두 경로여야 합니다. 일단 철회가 구축보다 더 어려워지면, 감호 관계는 사실상 "철회 불가능한 위임"으로 미끄러져 들어가, Human View 의 "개입 통로 상시 개방" 요구를 위반하게 됩니다.
갱신은 기본 행위가 아닙니다
제 12 장은 Faying State 에 한 가지 강제 약속을 부과했습니다: Faying State 는 반드시 유한 범위여야 하며、무기한 Faying 은 안티 패턴입니다. 이 약속에 자격증명 차원에서 대응하는 구체적 입장은——자격증명의 갱신은 기본적으로 완료되어서는 안 됩니다.
매번의 갱신은 명시적이고、증인이 가능한 동작이어야 하며, "Fay 가 자동으로 제출하고、시스템이 자동으로 갱신 서명한다"는 암묵적 순환이 되어서는 안 됩니다. 청사진은 엔지니어링 차원에서 "갱신 알림"、"갱신 제안" 등 편의 메커니즘을 제공하는 것은 허용하지만, "갱신"을 Fay 자신이 조용히 완수할 수 있는 일로 만드는 것을 금지합니다——이는 Faying 을 사실상 무기한 위임으로 만들게 됩니다.
책임의 시각으로 이해하면: 갱신은 책임 측이 감호 의도를 다시 표현하는 순간입니다. 갱신마저 엔지니어링이 조용히 완료해 버리면, "감호"는 서명만 남고 의도는 없게 됩니다.
위반될 수 없는 몇 가지 레드라인
자격증명 관리의 몇 가지 가치관 입장은, 어떤 기술 방안이 착지할 때도 위반될 수 없는 레드라인입니다:
- FayID 는 신원 기초이다;
- 자격증명이 신뢰 불가능하면 Faying 은 성립하지 않는다;
- 철회권은 반드시 Human Prime 측에 보유되어야 한다;
- 갱신은 기본 행위가 아니다.
구체적인 서명 알고리즘、키 계층、철회 목록 전파、갱신 시간 창의 정밀화 설계、제조사 횡단 상호신뢰의 루트 인증서 구조、철회의 최종 일관성 등 기술 디테일은——프로토콜 규범의 범주에 속합니다. 본 장은 다시 서술하지도、미리 결정하지도 않으나, 어떤 기술 방안이든 먼저 위의 네 가지 입장을 따라야 합니다.
