СПЕЦИФИКАЦИЯ

Faying Protocol/1.0 — §10 Обработка ошибок

Навигация по тексту протокола: Оглавление | предыдущая §9 Вопросы безопасности | следующая §11 Открытые вопросы

§10 Обработка ошибок

Эта глава консолидирует все коды ошибок из §5.4 с конкретными сценариями отказов, ответами протокола, переходами состояний, путями восстановления и ограничениями наблюдаемости. Все ошибки возвращаются как сообщения ERROR под конвертом §5.2, с телом claims формы { code, message, mandate_id?, recovery_hint? }; четыре раздела этой главы составляют «единственную авторитетность уровня протокола по обработке ошибок» помимо §5.4.

EH.1 Сценарии ошибок и ответы протокола

Таблица ниже даёт панорамный взгляд на все коды ошибок, перечисленные в §5.4 (1001–1014 и 1099); каждая строка содержит: сценарий триггера, ответ протокола, запускается ли Revoke, запускается ли понижение, обязательна ли запись в цепочку аудита и обязателен ли push в канал представления HP. Эта таблица соответствует один к одному таблице кодов ошибок §5.4.

Код	Имя	Сценарий триггера	Ответ протокола	Запускает Revoke	Запускает понижение	Входит в аудит	Входит в представление HP
1001	`E_NO_MANDATE`	Бизнес-запрос не несёт заголовок Faying Protocol / Mandate	RP немедленно отклоняет; аудит не устанавливается	✗	✗	✗	✗
1002	`E_MANDATE_EXPIRED`	`now > Mandate.not_after`	RP отклоняет + MS запускает Revoke этого Mandate	✓	✗	✓	✗
1003	`E_SCOPE_VIOLATION`	Действие вызова ∉ `Mandate.scope.actions`	RP отклоняет + записывает подозрительное событие; накопленное подозрение запускает понижение	✗	✓ (накопительно)	✓	✗
1004	`E_GRADE_INSUFFICIENT`	RP требует уровень строже текущего `Mandate.grade`	RP отклоняет + предлагает повышение (путь повышения требует `human_witness` HP)	✗	✗	✓	✗
1005	`E_PRESENCE_STALE`	`presence.last_freshness` превышает `max_staleness_ms` или `LivenessDetectionBudget`	RP отклоняет; IF проактивно останавливает измерение D, ожидает калибровки PRESENCE; конечный автомат Active → Degraded	✗	✓	✓	✗
1006	`E_REVOKED`	RR помечает отозванным	RP отклоняет; каскадно отклоняет вызовы той же цепочки; IF немедленно откатывается к Rogue Fay	✓ (уже отозван)	✗	✓	✓
1007	`E_ATTESTATION_INVALID`	Проверка подписи узла Attestation Chain провалена / временная метка не в окне валидности родительского узла / подполе endorsement подделано	RP отклоняет + MS запускает Revoke этого Mandate	✓	✗	✓	✓
1008	`E_RR_UNAVAILABLE`	Тайм-аут запроса RR ≥ `StaleBudget`	RP отклоняет по Default-Deny; IF приостанавливает всё измерение D; конечный автомат Active → Degraded	✗	✓	✓	✗
1009	`E_REPLAY`	В пределах `2 × max_message_lifetime` nonce уже виден для того же subject	RP отклоняет + оповещение безопасности; IF немедленно ротирует сессионные ключи	✗	✗	✓	✓
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 подделано / дочерний endorsement DELEGATE не сходится в пределах родительского	MS отклоняет выпуск + запускает Revoke этого Mandate; IF немедленно останавливает все эндорсированные действия	✓	✗	✓	✓
1014	`E_FAYING_REQUEST_NOT_CONFIRMED`	Инициированный IF FAYING_REQUEST не подтверждён явно HP в течение `BootstrapTimeout`	MS возвращает `FAYING_REQUEST_RESP { status="timeout" }`; не производит изменения состояния Faying; событие записывается в Attestation Chain	✗	✗	✓	✗
1099	`E_PROTOCOL`	Версия / формат / отсутствующее поле / неразбираемое / отсутствие или неразбираемость `mandatory_fields` в DISCLOSURE / нелегальный вход подписи / `msg_type` явно не перечислен в §5.3	RP / MS отклоняет; дополнительно проталкивает в представление HP при запуске с пути DISCLOSURE	✗	✗	✓	✗* (путь DISCLOSURE ✓)

Примечание *: по умолчанию E_PROTOCOL входит только в цепочку аудита; когда запущен с пути отсутствия или неразбираемости mandatory_fields в DISCLOSURE из §5.3.7, MS должен дополнительно протолкнуть в канал представления HP (согласовано с примечанием §5.4).

Trace: R2.1.1–R2.1.4 (Default-Deny), 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 (отсутствие или неразбираемость mandatory_fields в DISCLOSURE запускает E_PROTOCOL).

EH.2 Пути восстановления

Коды ошибок сгруппированы в три класса путей восстановления по признаку «нужно ли повторное установление состояния Faying». Все пути восстановления должны выполняться в пределах конвергенции Default-Deny из EH.4; промежуточного окна оптимистичного пропуска не существует.

EH.2.1 Восстановимые ошибки (BOOTSTRAP не нужен)

Код	Имя	Действие восстановления
1004	`E_GRADE_INSUFFICIENT`	Запустить GRADE_SWITCH-up (должен нести `human_witness` HP; см. §7.4); восстановление с пропуском свидетельства не допускается
1005	`E_PRESENCE_STALE`	Переслать сообщение PRESENCE для обновления `last_freshness`; если всё ещё провал, сходиться по `LivenessDetectionBudget` к Degraded → Suspended
1008	`E_RR_UNAVAILABLE`	В пределах окна Default-Deny — повтор с backoff (не дольше `StaleBudget`); превышено → войти в Degraded, дождаться восстановления RR перед переподключением
1012	`E_BUDGET_EXCEEDED`	Запустить GRADE_SWITCH-down или дождаться обновления окна бюджета; восстановление «игнорировать бюджет» не допускается

EH.2.2 Восстановление, требующее повторного свидетельства HP (нужно повторно выполнить BOOTSTRAP)

Код	Имя	Действие восстановления
1002	`E_MANDATE_EXPIRED`	Повторно выполнить BOOTSTRAP; новый `mandate_id` не должен равняться старому `mandate_id` (согласовано с P10 необратимостью отзыва)
1006	`E_REVOKED`	Не восстановимо; только HP может инициировать свежий BOOTSTRAP; новый `mandate_id` не должен равняться старому `mandate_id`
1007	`E_ATTESTATION_INVALID`	То же, что выше; новый BOOTSTRAP разрешён только после того, как запущен принудительный Revoke этого Mandate
1011	`E_ROGUE_DETECTED`	То же, что выше; обычно сопровождается прямым вмешательством HP и аудитом ego-deviation
1013	`E_ENDORSEMENT_INVALID`	То же, что выше; после запуска Revoke Mandate HP должен инициировать свежий BOOTSTRAP (содержащий легитимное поле `endorsement`)

EH.2.3 Не составляет изменения состояния Faying (восстановление не нужно)

Код	Имя	Обработка
1001	`E_NO_MANDATE`	Вызывающий должен сначала получить Mandate, затем инициировать вызов; на уровне протокола нет пути «временный пропуск без Mandate»
1003	`E_SCOPE_VIOLATION`	Вызывающий должен скорректировать действие так, чтобы оно попадало в `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`	Вызывающий должен исправить структуру сообщения, затем переинициировать

Общее жёсткое ограничение: пути восстановления не должны обходить конвергенцию Default-Deny из §EH.4; любого пути оптимистичного восстановления «я не уверен, но сначала пропущу» на уровне протокола не существует.

EH.3 Ограничения наблюдаемости ответов-ошибок

Все сообщения ERROR должны удовлетворять следующим четырём жёстким ограничениям:

Пятёрка аудита: за исключением E_NO_MANDATE (нет контекста Mandate), каждый код ошибки должен записываться в Attestation Chain / журнал аудита как пятёрка (error_code, mandate_id, ts, RP_id, reason); эта пятёрка согласована с §3.2 и столбцом «Входит в аудит» из §EH.1.
Канал представления HP обязан проталкивать: множество кодов ошибок {E_REVOKED (1006), E_ATTESTATION_INVALID (1007), E_REPLAY (1009), E_ROGUE_DETECTED (1011), E_ENDORSEMENT_INVALID (1013)} должно проталкиваться в канал представления HP; E_PROTOCOL (1099), запущенный с пути DISCLOSURE, должен столь же проталкиваться. RP не должна тихо их проглатывать.
Нет утечки чувствительной информации: ответам-ошибкам запрещено нести внутреннее состояние MS, отпечатки закрытых ключей Mandate, идентификаторы других HP, внутренние переменные конечного автомата IF или иную чувствительную информацию; поля message и recovery_hint должны быть публичной семантикой уровня протокола, без утечки деталей реализации.
Цепочка аудита независимо проверяема: события ошибок, записанные в Attestation Chain, должны нести узлы подписи, требуемые §3.3 I-AC-1 / I-AC-2, чтобы третья сторона могла завершить проверку цепочки от листа до корня, не удерживая закрытый ключ MS (см. §6.3).

Trace: R3.2.1 (пятёрка кода ошибки записывается в журнал аудита), R3.2.2 (ответы-ошибки не должны нести чувствительную информацию), R3.2.3 (указанные коды ошибок должны входить в представление HP), R3.1.4 (прослеживаемые поля цепочки аудита).

EH.4 Единая конвергенция Default-Deny

Любая ошибка, которую невозможно однозначно классифицировать, любое неразбираемое поле и любой вызов во время недостижимости RR единообразно отклоняются уровнем протокола с E_PROTOCOL или E_RR_UNAVAILABLE; не существует легитимного пути «я не уверен, но сначала пропущу», как и какого-либо пути оптимистичного восстановления «обработать по более снисходительному состоянию» (включая Окно B, где фактически в сети, но воспринимается отключённым; см. §9.9).

Четыре эквивалентных выражения правила конвергенции:

Уровень конечного автомата: любой переход, явно не перечисленный в конечном автомате Mandate из §4.3 / конечном автомате жизненного цикла из §8.1, единообразно отклоняется.
Уровень сообщений: любой msg_type, явно не перечисленный в перечне сообщений §5.3, или любое отсутствующее поле конверта / несовпадение типа единообразно отклоняется с 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 (Default-Deny), R12.1.1–R12.1.3 (двойная семантика, решение только по Perceived), R12.2.1–R12.2.3 (пессимистическое допущение / отклонение во время воспринимаемого отключения).