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

Faying Protocol/1.0 — Приложение C Журнал изменений

Навигация по тексту протокола: Оглавление | предыдущая Приложение B Бюджеты параметров по умолчанию

Приложение C Журнал изменений

Этот журнал фиксирует, какие изменения произошли в тексте спецификации и сопутствующих поставках черновика Faying Protocol/1.0 от первых набросков до финализации. По формату следует группировке Keep a Changelog (Added / Changed / Deprecated / Removed / Security) и сначала поясняет, как определяется номер версии.

Честное примечание об источнике: черновик 1.0 этого протокола был произведён за один проход по spec-управляемому процессу (требования → проектирование → список задач → реализация) и ещё не прошёл несколько раундов независимых собраний Protocol Committee. Поэтому этот журнал не фабрикует построчные решения собраний и точные даты, а лишь честно фиксирует «что сделано, почему, какой задаче соответствует». Цитируемые ниже номера задач (например, 1.6, 3.8, 5.6) соответствуют реальным пунктам плана задач реализации, и по ним можно проследить место производства каждого изменения. Если в дальнейшем процесс перейдёт в официальный обзор Committee, сюда будут добавлены записи с датами и номерами решений.

Как определяется номер версии

Авторитетные правила нумерации версий протокола см. в тексте §1.7 Управление версиями и совместимость (три ортогональные оси: версия протокола MAJOR.MINOR / статус документа / редакционная версия; правила согласования и совместимости; место приземления номера версии и примечания для исполнителей). Это приложение не дублирует определение, а лишь дополняет двумя моментами, связанными с журналом изменений:

  • Этот журнал классифицирует каждое изменение по критерию MAJOR / MINOR из §1.7.2: ломающее совместимость идёт в MAJOR, обратносовместимое добавление — в MINOR, чисто текстовые errata по §1.7.4 относятся к Editorial и не трогают номер протокола.
  • Текущая версия — Faying Protocol/1.0, первая базовая линия, статус Final (опубликовано 2025-10-25).

По наименованию: проза и номер версии единообразно используют Faying Protocol/1.0, ранняя аббревиатура FAP упразднена. Но имена файлов схем fap-1.0.cddl / fap-1.0.proto сохранили старый префикс — чисто ради стабильности имён файлов и неразрушения существующих ссылок; это сделано намеренно, а не из-за метаний в наименовании (согласовано с §1.7.5 «имя файла схемы не меняется между редакционными версиями»).

[Faying Protocol/1.0] — Final (2025-10-25)

Это первый официальный релиз 1.0, целиком мигрировавший 2025-10-25 из рабочего пространства черновика в официальный каталог выпуска и финализированный. Ниже изменения классифицированы по типу, каждый пункт помечен номером задачи, которая его произвела.

Added

Текст (§1–§11 + приложения A/B):

  • §1 Overview: наименование протокола, позиционирование, восемь целей проектирования G1–G8, соответствие целей и Requirement один к одному; §1.5.1 устанавливает основное утверждение «любой двунаправленный Faying вступает в силу только при явном подтверждении HP». (задача 1.2)
  • §2 Architecture: четыре диаграммы Mermaid (стек протокола, отношения сущностей, иерархия уровней, временная диаграмма Bootstrap+Heartbeat+Action, включая путь Phase A0, инициированный IF) и шесть принципов проектирования. (задача 1.3)
  • §3 Components and Interfaces: интерфейсы и инварианты шести компонентов (MS / PC / AC / RR / LC / BBS). (задача 1.4)
  • §4 Data Models: авторитетное определение CDDL, человекочитаемое представление TypeScript, конечный автомат Mandate с состоянием Disconnected и сверкой при переподключении, подструктура endorsement. (задача 1.5)
  • §5 Protocol Messages: семь классов сообщений (BOOTSTRAP / PRESENCE / GRADE_SWITCH / DELEGATE / REVOKE / FAYING_REQUEST / DISCLOSURE), единый конверт, 14 кодов ошибок — среди которых добавлены 1010 E_HUMAN_WITNESS_REQUIRED, 1013 E_ENDORSEMENT_INVALID, 1014 E_FAYING_REQUEST_NOT_CONFIRMED. (задача 1.6)
  • §6 Cryptography: согласование набора алгоритмов (включая слот согласования PQC), вывод ключей, формат подписи; поле endorsement включено во вход подписи. (задача 1.7)
  • §7 Authorization Grades: семантика пяти уровней G0–G4, матрица триггеров, монотонность понижения, а также подуровни §7.5 Endorsement Grades, наслаиваемые поверх G1–G4. (задача 1.8)
  • §8 Lifecycle: жизненный цикл из семи состояний (включая Disconnected), временная диаграмма атрибуции ответственности, транзакция сверки при переподключении §8.4. (задача 1.9)
  • §9 Security Considerations: STRIDE, защита от replay / перехвата / фишинга, выявление обрыва связи, матрица обработки обрыва, а также каталог враждебных угроз эпохи ИИ T1–T7 из §9.10. (задача 1.10)
  • §10 Error Handling, §11 Open Questions, приложения A/B: сценарии ошибок и пути восстановления, открытые вопросы Q1–Q14, глоссарий, бюджеты параметров по умолчанию. (задача 1.11)
  • Полный перевод английской спецификации. (задача 1.12)

Сопутствующие поставки:

  • schema: schemas/fap-1.0.cddl (авторитетная), schemas/types.ts (человекочитаемое представление TypeScript, Not Normative), schemas/fap-1.0.proto (альтернативная привязка gRPC, Not Normative). (задачи 2.1–2.3)
  • Тестовые векторы vectors/: покрывают BOOTSTRAP / PRESENCE / GRADE_SWITCH / DELEGATE / REVOKE, коды ошибок, эквивалентность кодирования, Endorsement, FAYING_REQUEST, DISCLOSURE, Disconnection — всего 11 классов. (задачи 3.1–3.11)
  • Тесты на основе свойств pbt/: покрывают основные свойства P1–P15, плюс три семейства P16 (Endorsed_Mandate), P17 (Disconnection), P18 (AI-Era). (задачи 4.1–4.34)
  • Набор соответствия совместимости conformance/: пятимерная матрица кодирование × алгоритм подписи × хеш × канал × язык реализации, с двумя референсными реализациями на TypeScript и Rust. (задачи 5.1–5.6)
  • Симуляция атак безопасности conformance/attacks/: replay, перехват, фишинг, выявление обрыва связи, а также симуляции T1/T3/T4/T5/T6. (задачи 6.1–6.10)

Changed

  • Наименование протокола изменено с «Faying Auth Protocol (FAP)» ранних черновиков на Faying Protocol, номер версии записывается как Faying Protocol/1.0. (соответствует §11 Q10, разрешён)
  • Инициирование Faying расширено с одностороннего (только HP может инициировать) до двунаправленного (инициирование HP + инициирование IF), но условие вступления в силу единообразно сведено к одному — «явное подтверждение HP». (задачи 1.6, 3.9)
  • Обрыв связи разделён на две семантики «фактический обрыв» и «воспринимаемый обрыв», решение протокола смотрит только на воспринимаемый обрыв и делает пессимистическое допущение для окна несогласованности. (задачи 1.10, 3.11)
  • Вход подписи унифицирован как H(Deterministic-CBOR(Envelope_without_signature)), основной формат CBOR и резервный JSON эквивалентно совместимы при этом подходе. (задачи 3.7, 5.2)

Deprecated

  • Старые наименования FAP / FAP/1.0 / Faying Auth Protocol, а также старые формы конечных точек application/fap+json, POST /fap/v1/... единообразно упразднены. Новые написания используют application/faying-protocol+json и POST /faying-protocol/v1/{verb}. Имена файлов схем — единственное исключение, сохранившее старый префикс (см. выше «Как определяется номер версии»).

Removed

  • Нет. 1.0 — первая базовая линия, нет существующих полей или сообщений, требующих удаления.

Security

  • Добавлены ограничения уровня протокола против враждебных угроз эпохи ИИ: T1 социальная инженерия, T2 операции чёрного ящика, T3 избегание главного, T4 дрейф внимания, T5 культивирование стереотипного доверия, T6 потоп аудита, T7 расширяемый слот, каждая соответствует Property P18.1–P18.7 и Requirement 13.1–13.7. (задачи 1.10, 4.28–4.34, 6.6–6.10)
  • Ограничение неподделываемости эндорсированной авторизации: endorsement входит во вход подписи, изменение любого подполя ломает проверку подписи Mandate (E_ATTESTATION_INVALID / E_ENDORSEMENT_INVALID). (задачи 1.5, 3.8, 4.17–4.21)
  • Симметричный отзыв и необратимость отзыва: достижимость пути отзыва не ниже достижимости пути установления, Revoked — поглощающее состояние, каскадный отзыв включён по умолчанию. (задачи 3.5, 4.5, 4.11, 4.15)

Как сопровождать дальше

  • После перехода в официальный обзор каждое решение Committee добавляется сюда строкой с указанием даты, затронутых разделов и инициированных номеров задач, а в соответствующей группе Keep a Changelog выше дописывается одна человекочитаемая запись.
  • Номер версии: по §1.7 — обратносовместимое добавление идёт через MINOR, ломающее изменение — через MAJOR с обнулением MINOR, чисто текстовые errata — через редакционную версию (§1.7.4) без изменения номера протокола.
  • Последующие errata и миграция редакций выполняются по §1.7.4 / §1.7.5; этот журнал мигрирует вместе с текстом протокола и обновляется вместе с соответствующей редакцией.
  • Однотипные изменения на разных языках синхронизируются в одном цикле; при неоднозначностях преимущественную силу имеет эталонная версия.