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

Faying Protocol/1.0 — §11 Открытые вопросы

Навигация по тексту протокола: Оглавление | предыдущая §10 Обработка ошибок | следующая Приложение A Выравнивание терминологии

§11 Открытые вопросы

Эта глава честно перечисляет темы, не обязательно требующие ответа в тексте протокола фазы 1, но оставленные Protocol Committee для разрешения на стадии 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) сохранить протокольное принуждение и оставить аппаратный путь на свободу реализации экосистемы.
  • Статус разрешения: открыт; глубоко связан с перехватом терминала в фазах 2 / 3.

Q3 График PQC по умолчанию

  • Тема: когда гибрид Ed25519 + ML-DSA-65 повышается с OPTIONAL до MUST?
  • Текущая склонность протокола: 1.0 объявляет лишь OPTIONAL (слоты согласования PQC в §6.1); график будет задан после публикации всех финальных стандартов NIST.
  • Альтернативы: (a) дождаться финализации всех стандартов NIST PQC; (b) следовать первому стандартизированному алгоритму подписи; (c) дифференцировать по уровню (высокочувствительные сценарии MUST сначала).
  • Статус разрешения: открыт; ожидает прогресса стандартизации NIST PQC.

Q4 Кросс-Human-Prime сотрудничество iFay ↔ iFay (фазы 4/5)

  • Тема: когда две iFay, принадлежащие разным HP, сотрудничают, как определяется передача ответственности?
  • Текущая склонность протокола: 1.0 не покрывает; будет задано в фазе 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) разрешить автоматическое продление на низкорисковых уровнях (G3/G4); (c) сохранить запрет.
  • Статус разрешения: открыт; ожидает решения Protocol Committee.

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?
  • Текущая склонность протокола: 1.0 сохраняет пять ярусов (§7.1); не вводит промежуточные ярусы вроде G2.5.
  • Альтернативы: (a) ввести промежуточный ярус «полуавтономный + прерываемый»; (b) разрешить реализациям определять кастомные подуровни, но отображать обратно на один из пяти; (c) ввести ортогональные подуровни Endorsement Grades (уже приземлены в §7.5).
  • Статус разрешения: частично разрешён (Endorsement Grades ортогонально накладываются на G1–G4); промежуточные ярусы остаются открытыми.

Q9 Граница каскада отзыва

  • Тема: как гарантируется видимость каскадного отзыва DELEGATE по умолчанию (cascade=true) при многоуровневом выводе?
  • Текущая склонность протокола: по умолчанию cascade=true (§5.3.5); видимость ограничена RevocationVisibilityBudget (§9.7, P14 кросс-производный каскадный отзыв).
  • Альтернативы: (a) дифференцировать бюджет по глубине дерева вывода; (b) сохранить единый бюджет + двухтрековый push / pull.
  • Статус разрешения: открыт; ожидает тестов соответствия для измерения видимости глубокого дерева вывода.

Q10 Наименование протокола (разрешён)

  • Тема: официальное наименование протокола.
  • Заключение разрешения: протокол официально назван Faying Protocol (без отдельной аббревиатуры), версия Faying Protocol/1.0.
  • Статус разрешения: разрешён; эта тема остаётся как историческая запись и более не открыта для обсуждения.

Q11 Верхняя граница максимального срока жизни Endorsement

  • Тема: должен ли уровень протокола специфицировать жёсткую верхнюю границу endorsement.endorsed_lifetime (например, ≤12 ч)? Должна ли она дополнительно ужесточаться по уровню?
  • Текущая склонность протокола: Приложение B даёт рекомендуемое значение (по умолчанию 4 ч, мягкая верхняя граница 12 ч, и не должна превышать Mandate.not_after − Mandate.not_before; см. P16.3 / P16.4); жёсткая верхняя граница ожидает разрешения RFC.
  • Альтернативы: (a) жёстко закодировать верхнюю границу 12 ч на уровне протокола; (b) дифференцировать по уровню (например, G1 ≤ 1 ч, G4 ≤ 24 ч); (c) сохранить рекомендуемое значение необязательным.
  • Статус разрешения: открыт; связан с Q7 офлайн-политикой.

Q12 Защита от злоупотребления двунаправленным Faying

  • Тема: должен ли инициированный iFay FAYING_REQUEST подлежать обязательному ограничению частоты на уровне протокола (не более N раз в минуту на пару (HP, IF))? Должно ли это ограничение частоты быть включено в тот же бюджет ConfirmationRateLimit?
  • Текущая склонность протокола: частота FAYING_REQUEST включена в тот же бюджет ConfirmationRateLimit (см. §5.3.6, §9.10.7, P18.6); превышение лимита запускает автопонижение / приостановку по §9.10.7.
  • Альтернативы: (a) независимый бюджет FayingRequestRateLimit; (b) дифференцировать бюджеты по уровню; (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) ввести «реестр схем базовых линий» для унификации калибровки.
  • Статус разрешения: открыт; связан с Q5 определением ego-deviation.

Q14 Объективные критерии минимальной гранулярности Atomic_Action

  • Тема: каково объективное определение «минимального неделимого действия» на уровне протокола? Должна ли быть введена «решётка действий», чтобы scope.actions и набор действий со стороны RP имели формализуемую редукцию минимальной гранулярности?
  • Текущая склонность протокола: уровень протокола предписывает лишь «ровно 1 Atomic_Action на вызов / scope.actions не допускает подстановочных знаков» (P18.2 Atomic_Action_Strict); объективное определение минимальной гранулярности оставлено RP и Protocol Committee по конвенциям отрасли.
  • Альтернативы: (a) ввести кросс-RP общую решётку действий; (b) ввести отдельные решётки по отрасли RP (финансы / здравоохранение / IoT); (c) сохранить текущую открытость.
  • Статус разрешения: открыт; обсуждается в связке со слотом расширения §9.10.8 T7.