Faying Protocol/1.0 — §10 Error Handling
프로토콜 본문 내비게이션: 장 목차 ｜ 이전 장 §9 보안 고려사항 ｜ 다음 장 §11 미해결 과제
§10 Error Handling
이 장은 §5.4의 오류 코드와 구체적인 실패 시나리오, 프로토콜 응답, 상태 전이, 복구 경로, 관측 가능성 제약을 한데 모아 다룬다. 모든 오류는 §5.2 인벨로프 아래의 ERROR 메시지로 회신하며, claims 본체는 { code, message, mandate_id?, recovery_hint? } 형태다. §5.4의 오류 코드 표 외에는 오류 처리에 관해 이 장의 네 절을 정본으로 한다.
EH.1 오류 시나리오와 프로토콜 응답
아래 표는 §5.4에 나열된 모든 오류 코드(1001–1014와 1099)의 전경 뷰를 제시하며, 각 행은 다음을 담는다: 트리거 시나리오, 프로토콜 응답, Revoke 트리거 여부, 강등 트리거 여부, 감사 체인 필수 기입 여부, HP 시야 통로 필수 기입 여부. 이 표는 §5.4 오류 코드 표와 일대일 대응한다.
| Code | 명칭 | 트리거 시나리오 | 프로토콜 응답 | Revoke 트리거 | 강등 트리거 | 감사 기입 | HP 시야 기입 |
|---|---|---|---|---|---|---|---|
| 1001 | E_NO_MANDATE | 업무 요청이 Faying Protocol 헤더 / Mandate를 담지 않음 | RP 즉시 거부; audit 미수립 | ✗ | ✗ | ✗ | ✗ |
| 1002 | E_MANDATE_EXPIRED | now > Mandate.not_after | RP 거부 + MS가 그 Mandate의 Revoke 트리거 | ✓ | ✗ | ✓ | ✗ |
| 1003 | E_SCOPE_VIOLATION | 호출 동작 ∉ Mandate.scope.actions | RP 거부 + 의심 이벤트 기록; 의심 누적 횟수가 강등 트리거 | ✗ | ✓(누적) | ✓ | ✗ |
| 1004 | E_GRADE_INSUFFICIENT | RP가 요구하는 grade가 현재 Mandate.grade보다 강함 | RP 거부 + 승급 안내(승급 경로는 HP human_witness 필요) | ✗ | ✗ | ✓ | ✗ |
| 1005 | E_PRESENCE_STALE | presence.last_freshness가 max_staleness_ms 또는 LivenessDetectionBudget 초과 | RP 거부; IF가 능동적으로 D 차원 중지, PRESENCE 보정 대기; 상태 기계 Active → Degraded | ✗ | ✓ | ✓ | ✗ |
| 1006 | E_REVOKED | RR이 revoked로 표기 | RP 거부; 동일 체인 호출 연쇄 거부; IF 즉시 Rogue Fay로 복귀 | ✓(이미 폐기됨) | ✗ | ✓ | ✓ |
| 1007 | E_ATTESTATION_INVALID | Attestation Chain 노드 서명 검증 실패 / 타임스탬프가 부모 노드 validity window 밖 / endorsement 하위 필드 변조됨 | RP 거부 + MS가 그 Mandate의 Revoke 트리거 | ✓ | ✗ | ✓ | ✓ |
| 1008 | E_RR_UNAVAILABLE | RR 질의 타임아웃 ≥ StaleBudget | RP가 Default-Deny에 따라 거부; IF가 모든 D 차원 일시 정지; 상태 기계 Active → Degraded | ✗ | ✓ | ✓ | ✗ |
| 1009 | E_REPLAY | nonce가 2 × max_message_lifetime 안에서 동일 subject에 대해 이미 관측됨 | RP 거부 + 보안 경보; IF 즉시 세션 키 rotate | ✗ | ✗ | ✓ | ✓ |
| 1010 | E_HUMAN_WITNESS_REQUIRED | grade-up / FAYING_REQUEST 등 HP 입회가 필요한 시나리오에서 누락되거나 human_witness 검증 실패 | RP / MS 거부; HP 입회 후 재발기 대기 | ✗ | ✗ | ✓ | ✗ |
| 1011 | E_ROGUE_DETECTED | D 차원 위반 감지(ego-deviation / 행위 베이스라인 임곗값 초과 등) | RP 거부 + 강제 Revoke; IF 즉시 Rogue Fay로 복귀 | ✓ | ✗ | ✓ | ✓ |
| 1012 | E_BUDGET_EXCEEDED | 호출 누적이 Scope.budget / ResourceBudget 초과 | RP 거부 + 강등 또는 (극단적 상황) Revoke 트리거 | ✓(극단) | ✓ | ✓ | ✗ |
| 1013 | E_ENDORSEMENT_INVALID | endorsed_scope ⊄ scope / endorsed_grade.autonomy > grade.autonomy / endorsed_lifetime 누락 또는 과도하게 김 / endorsement 하위 필드 변조됨 / DELEGATE 자식 endorsement이 부모에 수렴하지 않음 | MS 발급 거부 + 그 Mandate의 Revoke 트리거; IF 즉시 모든 endorsed 행위 중지 | ✓ | ✗ | ✓ | ✓ |
| 1014 | E_FAYING_REQUEST_NOT_CONFIRMED | iFay가 능동 발기한 FAYING_REQUEST가 BootstrapTimeout 안에 HP의 명확한 승인을 얻지 못함 | MS가 FAYING_REQUEST_RESP { status="timeout" }으로 반환; 어떤 Faying 상태 변화도 발생하지 않음; 이벤트는 Attestation Chain에 기입 | ✗ | ✗ | ✓ | ✗ |
| 1099 | E_PROTOCOL | 버전 / 형식 / 필드 누락 / 파싱 불가 / DISCLOSURE mandatory_fields 누락 또는 파싱 불가 / 서명 입력 부적법 / §5.3 메시지 목록에 명시 나열되지 않은 msg_type | RP / MS 거부; DISCLOSURE 경로에서 트리거 시 추가로 HP 시야 push | ✗ | ✗ | ✓ | ✗*(DISCLOSURE 경로 ✓) |
*비고:E_PROTOCOL은 기본적으로 감사 체인에만 기입된다. 다만 §5.3.7 DISCLOSURE의mandatory_fields누락 또는 파싱 불가 경로에서 트리거될 때, MS는 반드시 추가로 HP 시야 통로로 푸시해야 한다(§5.4 비고와 일치).
Trace: R2.1.1–R2.1.4(기본 거부), R3.2.1–R3.2.3(오류 이벤트의 감사·HP 시야 기입), R4.2.1–R4.2.3(폐기 가시성 예산과 도달성), R11.1.4(endorsement 변조가 E_ATTESTATION_INVALID + Revoke 트리거), R11.2.1–R11.2.3(endorsement 수렴 위반이 E_ENDORSEMENT_INVALID 트리거), R1.3.3(FAYING_REQUEST 타임아웃 미승인이 E_FAYING_REQUEST_NOT_CONFIRMED 트리거), R13.3.1(DISCLOSURE mandatory_fields 누락 또는 파싱 불가가 E_PROTOCOL 트리거).
EH.2 복구 경로
"Faying 상태를 다시 수립해야 하는지"에 따라 오류 코드를 세 종류의 복구 경로로 나눈다. 모든 복구 경로는 반드시 EH.4 Default-Deny 수렴 안에서 실행되어야 하며, 낙관적 통과의 중간 창은 존재하지 않는다.
EH.2.1 복구 가능 오류(BOOTSTRAP 재실행 불필요)
| Code | 명칭 | 복구 동작 |
|---|---|---|
| 1004 | E_GRADE_INSUFFICIENT | GRADE_SWITCH-up 트리거(반드시 HP human_witness 휴대, §7.4 참조); 입회를 건너뛴 복구 불허 |
| 1005 | E_PRESENCE_STALE | PRESENCE 메시지 재전송으로 last_freshness 회복; 여전히 실패하면 LivenessDetectionBudget에 따라 Degraded → Suspended로 수렴 |
| 1008 | E_RR_UNAVAILABLE | Default-Deny 창 안에서 retry-with-backoff(StaleBudget 초과 금지); 초과하면 Degraded로 진입하여 RR 회복 후 재연결 대기 |
| 1012 | E_BUDGET_EXCEEDED | GRADE_SWITCH-down 트리거 또는 예산 창 갱신 대기; "예산 무시"를 통한 복구 불허 |
EH.2.2 HP 재입회가 필요한 복구(반드시 BOOTSTRAP 재실행)
| Code | 명칭 | 복구 동작 |
|---|---|---|
| 1002 | E_MANDATE_EXPIRED | BOOTSTRAP 재실행; 새 mandate_id는 반드시 옛 mandate_id와 같지 않음(P10 폐기 불가역과 일치) |
| 1006 | E_REVOKED | 복구 불가; HP가 능동적으로 새로운 한 차례의 BOOTSTRAP을 발기해야만 하며, 새 mandate_id는 반드시 옛 mandate_id와 같지 않음 |
| 1007 | E_ATTESTATION_INVALID | 위와 동일; 그 Mandate의 강제 Revoke를 트리거한 후에야 새 BOOTSTRAP을 허용 |
| 1011 | E_ROGUE_DETECTED | 위와 동일; 보통 HP의 직접 개입과 ego-deviation 감사를 동반 |
| 1013 | E_ENDORSEMENT_INVALID | 위와 동일; 그 Mandate의 Revoke를 트리거한 후 반드시 HP가 새로운 한 차례의 BOOTSTRAP을 발기해야 함(합법적인 endorsement 필드 포함) |
EH.2.3 Faying 상태 변화를 구성하지 않음(복구 수요 없음)
| Code | 명칭 | 처리 |
|---|---|---|
| 1001 | E_NO_MANDATE | 호출 측은 먼저 Mandate를 획득한 후 호출을 발기해야 함; 본 프로토콜 계층에는 "Mandate 없는 임시 통과" 경로가 존재하지 않음 |
| 1003 | E_SCOPE_VIOLATION | 호출 측은 action을 조정하여 Mandate.scope.actions 안에 떨어지게 해야 함; 의심 누적은 강등을 트리거 |
| 1009 | E_REPLAY | 호출 측은 새 nonce를 사용하여 재발기해야 함; 공격 행위인 경우 이미 보안 경보와 HP 시야에 기입됨 |
| 1010 | E_HUMAN_WITNESS_REQUIRED | HP 입회 후 재발기; IF / MS / SA가 입회를 대체하는 것은 불허 |
| 1014 | E_FAYING_REQUEST_NOT_CONFIRMED | iFay는 합법적인 속도 내에서 FAYING_REQUEST를 재발기할 수 있으나, 이를 빌려 확인 홍수를 실시해서는 안 됨(§9.10.7, 부록 B ConfirmationRateLimit 참조) |
| 1099 | E_PROTOCOL | 호출 측은 메시지 구조를 수정한 후 재발기해야 함 |
공통 하드 제약: 복구 경로는 §EH.4 Default-Deny 수렴을 우회해서는 안 된다. "확실하지 않지만 일단 통과시킨다"는 낙관적 복구 경로는 프로토콜 계층에 일절 존재하지 않는다.
EH.3 오류 응답의 관측 가능성 제약
모든 ERROR 메시지는 다음 네 가지 강제약을 만족해야 한다:
- 감사 5요소:
E_NO_MANDATE(Mandate 컨텍스트 없음)를 제외한 모든 오류 코드는 반드시(error_code, mandate_id, ts, RP_id, reason)5요소로 Attestation Chain / audit-log에 기입되어야 한다. 이 5요소는 §3.2, §EH.1 "감사 기입" 열과 일치한다. - HP 시야 통로 필달: 오류 코드 집합
{E_REVOKED (1006), E_ATTESTATION_INVALID (1007), E_REPLAY (1009), E_ROGUE_DETECTED (1011), E_ENDORSEMENT_INVALID (1013)}은 반드시 HP 시야 통로로 push되어야 한다. DISCLOSURE 경로에서 트리거된E_PROTOCOL (1099)도 마찬가지로 필달이다. RP는 조용히 삼켜서는 안 된다. - 민감 정보 누출 금지: 오류 응답에 MS 내부 상태, Mandate 개인키 지문, 다른 HP 식별자, IF 내부 상태 기계 변수 등 민감 정보를 담는 것을 금지한다.
message와recovery_hint필드는 반드시 프로토콜 계층의 공개 의미론이어야 하며 구현 세부를 새어 나가게 해서는 안 된다. - 감사 체인 독립 검증 가능: Attestation Chain에 기입되는 오류 이벤트는 반드시 §3.3 I-AC-1 / I-AC-2가 요구하는 서명 노드를 담아, 제3자가 MS 개인키를 보유하지 않은 전제에서 잎에서 뿌리까지의 체인 검증을 완료할 수 있게 해야 한다(§6.3 참조).
Trace: R3.2.1(오류 코드 5요소를 audit-log에 기입), R3.2.2(오류 응답은 민감 정보를 담아서는 안 됨), R3.2.3(지정 오류 코드는 HP 시야 필달), R3.1.4(감사 체인 추적 가능 필드).
EH.4 Default-Deny의 통일 수렴
명확히 분류할 수 없는 어떤 오류든, 파싱 불가한 어떤 필드든, RR 도달 불가 기간의 어떤 호출이든, 프로토콜 계층은 일률적으로
E_PROTOCOL또는E_RR_UNAVAILABLE로 거부한다. "확실하지 않지만 일단 통과시킨다"는 합법 경로는 존재하지 않으며, "더 느슨한 상태로 처리하는" 낙관적 복구 경로도 존재하지 않는다(실제로 온라인이지만 실연으로 감지된 창 B 포함, §9.9 참조).
수렴 규칙의 네 가지 등가 표현:
- 상태 기계 계층: §4.3 Mandate 상태 기계 / §8.1 Lifecycle 상태 기계에 명시 나열되지 않은 전이는 일률적으로 거부한다.
- 메시지 계층: §5.3 메시지 목록에 명시 나열되지 않은
msg_type, 또는 인벨로프 필드 누락 / 타입 오류는 일률적으로E_PROTOCOL로 거부한다. - 오류 코드 계층: §5.4 / §EH.1에 명시 나열되지 않은 실패 원인은 일률적으로
E_PROTOCOL로 분류하여 거부한다. - 결정 계층: 프로토콜 계층은 오직 Perceived-Disconnected만을 결정 근거로 삼는다. 창 A(실제로 실연되었으나 온라인으로 감지됨) / 창 B(실제로 온라인이지만 실연으로 감지됨)의 낙관적 통과 경로는 프로토콜 계층에 존재하지 않는다(§9.9 비관적 추정 원칙, P17.1 / P17.2 참조).
Trace: R2.1.1–R2.1.4(기본 거부), R12.1.1–R12.1.3(이중 의미론 Perceived-only 결정), R12.2.1–R12.2.3(비관적 추정 / 감지된 실연 기간 거부).