사양

Faying Protocol/1.0 — §11 Open Questions

프로토콜 본문 내비게이션: 장 목차 ｜ 이전 장 §10 오류 처리 ｜ 다음 장 부록 A 용어 정렬 퀵 레퍼런스

§11 Open Questions

이 장은 Phase 1 프로토콜 본문이 반드시 답할 필요는 없으며 프로토콜 위원회가 RFC 단계에서 결의하도록 남긴 과제를 정직하게 나열한다. 각 과제는 현재 프로토콜 경향, 대안, 결의 상태를 제시하여, 이후 RFC 논의가 구조화된 출발점을 갖게 한다. 이미 결의된 항목(예: Q10 프로토콜 명명)은 역사 기록으로 보존한다.

Q1 Rogue 기간 단말의 위치 보고

  • 과제: iFay가 Rogue Fay 상태에 있는 동안 단말이 물리적 위치를 계속 보고하도록 허용할 것인가? "프라이버시 vs 회수 가능성"의 양면 줄다리기와 얽힌다.
  • 현재 프로토콜 경향: RevokeReason에 따라 차등화한다 — human-initiated / task-completed는 보고하지 않고, fay-credential-invalid / regulatory-order / terminal-disconnected 등은 보고할 수 있다.
  • 대안: (a) 일률 금지; (b) 일률 허용; (c) HP가 BOOTSTRAP 시 명시적으로 사전 선택.
  • 결의 상태: 미결; 청사진 제14장도 명시적으로 결론을 내리지 않았다.

Q2 G0 Emergency Override의 거부 불가 경로

  • 과제: IF가 이미 공격자에게 제어된 극단적 상황에서, G0 메시지가 여전히 IF 커널에 의해 실행될 수 있음을 어떻게 보장하는가?
  • 현재 프로토콜 경향: 프로토콜 계층은 G0 메시지가 최상위 우선순위를 갖도록 강제하지만(§7.2 / P12 G0 Override 우선순위 참조), IF 커널이 이미 함락된 경우 순수 프로토콜 계층 수단만으로는 충분하지 않음을 인정한다.
  • 대안: (a) 하드웨어 수준 kill-switch 강제; (b) TPM-quote 이중 서명 확인; (c) 프로토콜 계층 강제를 유지하고 하드웨어 경로는 생태계 구현의 자유 재량으로 남김.
  • 결의 상태: 미결; Phase 2 / Phase 3 단말 인수와 깊이 결합.

Q3 PQC 기본 시간표

  • 과제: Ed25519 + ML-DSA-65 hybrid는 언제 OPTIONAL에서 MUST로 격상되는가?
  • 현재 프로토콜 경향: 1.0은 OPTIONAL만 선언한다(PQC 스위트 협상 비트는 §6.1 참조). NIST 최종 표준이 모두 공표된 후에 시간표를 정한다.
  • 대안: (a) NIST의 모든 PQC 표준 확정 대기; (b) 최초로 표준화된 서명 알고리즘을 따름; (c) grade에 따라 차등화(고민감 시나리오가 먼저 MUST).
  • 결의 상태: 미결; NIST PQC 표준화 진척 대기.

Q4 인류 원형을 달리하는 iFay ↔ iFay 협업(Phase 4/5)

  • 과제: 서로 다른 HP에 속한 두 iFay가 협업할 때, 책임 전달 방식을 어떻게 확정하는가?
  • 현재 프로토콜 경향: 1.0은 커버하지 않는다. Phase 4에서 coFay를 도입할 때 정한다.
  • 대안: (a) 발기 측 책임; (b) 수신 측 책임; (c) 규칙에 따라 분담; (d) 반드시 양측 HP가 공동 입회.
  • 결의 상태: 미결; 법률—프로토콜 이원 트랙 논의 필요.

Q5 Ego 이탈의 객관적 판정

  • 과제: 프로토콜 계층이 ego-deviation의 최저 판정 신호 집합을 규정해야 하는가?
  • 현재 프로토콜 경향: 프로토콜 계층은 RevokeReason="ego-deviation"의 의미론과 트리거 결과만 정의한다(§EH.1, §3.6 BBS). 구체적 판정 신호 집합은 구현의 자유 재량으로 남긴다.
  • 대안: (a) 프로토콜 계층이 최저 신호 집합을 규정; (b) §3.6 Behavior Baseline Service로 명시 제약; (c) 현재의 여백 유지.
  • 결의 상태: 미결; Q13 행위 베이스라인 표준화와 결합.

Q6 Mandate 갱신 정책

  • 과제: 프로토콜이 "자동 갱신"의 모든 형태를 금지하는가?
  • 현재 프로토콜 경향: 모든 자동 갱신 형태를 금지한다. 매 갱신은 반드시 HP의 명시적 입회를 거쳐야 한다(청사진 제10장 경향).
  • 대안: (a) "HP의 주기적 사전 서명이 필요한 제한적 자동 갱신" 허용; (b) 저위험 grade(G3/G4)의 자동 갱신 허용; (c) 금지 유지.
  • 결의 상태: 미결; 프로토콜 위원회 취사 대기.

Q7 오프라인 / 약한 네트워크 환경

  • 과제: RR 도달 불가의 엣지 시나리오(드론 단절)에서 "시간 제한 자치 + 재연결 후 강제 대사"의 약화 모드를 허용할 것인가?
  • 현재 프로토콜 경향: Endorsed_Mandate(§7.5, §9.8, §4.3 Disconnected)를 통해 "시간 제한 자치 + 재연결 대사"를 명시적으로 모델링한다. 비 Endorsed 경로는 엄격한 Default-Deny(P17.2 비관적 추정 참조).
  • 대안: (a) Endorsed_Mandate에만 의존; (b) "구역 수준 RR 캐시" 도입; (c) 엄격한 Default-Deny로 어떤 예외도 열지 않음.
  • 결의 상태: 부분 결의(Endorsed_Mandate는 §7.5에 이미 구현됨); 오프라인 정책 상한은 Q11 결의 대기.

Q8 자식 에이전트 "보충 등급"

  • 과제: G0 Emergency_Override와 G1 Strict / G2 Moderate / G3 Loose / G4 Autonomous의 5단계 체계로 충분한가?
  • 현재 프로토콜 경향: 1.0은 5단계를 유지한다(§7.1). G2.5 등 중간 단계는 도입하지 않는다.
  • 대안: (a) "반자율 + 개입 가능" 중간 단계 도입; (b) 구현이 사용자 정의 하위 등급을 두되 5단계 중 하나로 매핑하도록 허용; (c) 직교하는 Endorsement Grades 하위 등급 도입(§7.5에 이미 구현됨).
  • 결의 상태: 부분 결의(Endorsement Grades는 G1–G4 위에 직교 중첩되어 이미 구현됨); 중간 단계는 Open 유지.

Q9 폐기 연쇄의 경계

  • 과제: DELEGATE의 연쇄 폐기 기본값(cascade=true)이 다층 파생 시의 가시성을 어떻게 보장하는가?
  • 현재 프로토콜 경향: 기본 cascade=true(§5.3.5). 가시성은 RevocationVisibilityBudget이 제약한다(§9.7, P14 파생 간 연쇄 폐기 참조).
  • 대안: (a) 파생 트리 깊이에 따라 예산 차등화; (b) 단일 예산 + push / pull 이원 트랙 유지.
  • 결의 상태: 미결; conformance 테스트가 깊은 파생 트리의 실측 가시성을 가늠하기 대기.

Q10 프로토콜 명명(결의 완료)

  • 과제: 프로토콜 정식 명명.
  • 결의 결론: 프로토콜은 정식으로 Faying Protocol(독립 약어 없음)로 명명하며, 버전 번호는 Faying Protocol/1.0이다.
  • 결의 상태: 결의 완료; 이 과제는 역사 기록으로 남기며 더 이상 열린 논의 대상이 아니다.

Q11 Endorsement 최대 수명 상한

  • 과제: 프로토콜 계층이 endorsement.endorsed_lifetime의 하드 상한(예: ≤12h)을 규정하는가? grade에 따라 추가로 더 조이는가?
  • 현재 프로토콜 경향: 부록 B가 권장값을 제시한다(기본 4h, 소프트 상한 12h, 그리고 Mandate.not_after − Mandate.not_before를 초과할 수 없음, P16.3 / P16.4 참조). 하드 상한은 RFC 결의에 남긴다.
  • 대안: (a) 프로토콜 계층이 12h 상한을 하드코딩; (b) grade에 따라 차등화(예: G1 ≤ 1h, G4 ≤ 24h); (c) 권장값 유지하되 강제하지 않음.
  • 결의 상태: 미결; Q7 오프라인 정책과 결합.

Q12 양방향 Faying 남용 방어

  • 과제: iFay가 능동 발기한 FAYING_REQUEST에 프로토콜 계층에서 강제 속도 제한(각 (HP, IF) 쌍당 분당 최대 N회)이 필요한가? 속도 제한을 ConfirmationRateLimit 동일 예산에 편입하는가?
  • 현재 프로토콜 경향: FAYING_REQUEST 빈도를 ConfirmationRateLimit 동일 예산에 편입한다(§5.3.6, §9.10.7, P18.6 참조). 초과 시 §9.10.7에 따라 자동 강등 / 일시 정지한다.
  • 대안: (a) 독립 예산 FayingRequestRateLimit; (b) grade에 따라 예산 차등화; (c) 현재의 ConfirmationRateLimit 공유 유지.
  • 결의 상태: 부분 결의(기본 공유 예산은 §9.10.7에 이미 구현됨); 임곗값 상한과 독립 예산 여부는 RFC 결의 대기.

Q13 Behavior_Baseline 표준화

  • 과제: 행위 베이스라인의 계산 기준 입도(action / scope_used / risk_level / affected_resources 또는 다차원 결합 기준)를 프로토콜 계층에서 통일 규정하는가? 아니면 구현의 자유 재량을 허용하되 베이스라인 계산 기준 자체를 Attestation Chain에 기입하도록 요구하는가?
  • 현재 프로토콜 경향: 구현 자유 재량 + 베이스라인 계산 기준 자체를 Attestation Chain에 기입하고, 기준 변경을 감사 이벤트로 간주한다(§3.6 I-BBS-3 / P18.5).
  • 대안: (a) 프로토콜 계층 강제(action / scope_used / risk_level / affected_resources 다차원 결합); (b) 자유 재량 + 감사 유지; (c) "베이스라인 schema 레지스트리"를 도입하여 기준 통일.
  • 결의 상태: 미결; Q5 ego-deviation 판정과 결합.

Q14 Atomic_Action 최소 입도의 객관적 판정 기준

  • 과제: "최소 분리 불가 action"의 프로토콜 계층 객관적 판정이란 무엇인가? scope.actions와 RP 측 동작 집합 사이에 형식화 정렬 가능한 최소 입도 규약을 두도록 "action lattice"를 도입할 것인가?
  • 현재 프로토콜 경향: 프로토콜 계층은 "한 차례 호출은 정확히 1개의 Atomic_Action / scope.actions는 와일드카드 불허"만 강제한다(P18.2 Atomic_Action_Strict). 최소 입도의 객관적 판정은 RP와 프로토콜 위원회가 산업 영역에 따라 규약하도록 남긴다.
  • 대안: (a) RP 횡단의 범용 action lattice 도입; (b) RP 산업(금융 / 의료 / IoT)별로 각각 lattice; (c) 현재의 여백 유지.
  • 결의 상태: 미결; §9.10.8 T7 확장 슬롯과 함께 논의.