BLUEPRINT

Глава 7. Открытые вопросы

В этой главе перечислены открытые проблемы, которые текущий уровень протокола оставляет нерешёнными, чтобы они были разрешены спецификациями реализации, будущими версиями протокола или отдельными ADR. Каждый пункт соответствует той же записи в Разделе 10 design.md и может быть уточнён далее, когда open-questions.md будет архивирован в предстоящей Task 8.

Эти пункты — не недостатки протокола FayID; это точки расширения, которые были намеренно оставлены открытыми. Их общая черта в том, что преждевременное их решение на уровне протокола либо ограничило бы свободу реализации, либо потребовало бы пересмотра по мере развития экосистемы.

1. Конкретные алгоритмы хэширования / подписи / KDF

Проблема: уровень протокола перечисляет лишь кандидатов (Ed25519 / HKDF-SHA256 / BIP-39); окончательный выбор оставлен спецификации реализации.

Область: совместимость между реализациями, криптографический аудит

Направление: зафиксировать алгоритмы в спецификации реализации вместе с версионированием (например, суффикс v1 в fayid/dyn/v1, fayid/gmc/v1). Будущие обновления алгоритмов могут сосуществовать через новые номера версий.

2. Длительность временного окна Dynamic Code

Проблема: уровень протокола требует только наличия expiresAt у Dynamic Code; конкретная длительность (минуты, часы) — это политическое решение реализации.

Область: пользовательский опыт, стойкость конфиденциальности, частота ротации

Направление: реализации подбирают её под сценарий. Сценарии высокой безопасности используют короткое окно (например, 5 минут); обычные сценарии могут расслабиться до часового масштаба.

3. Пороги ограничения скорости при отказах Verification Code

Проблема: ширина окна, порог числа неудач и стратегия отката для VERIFICATION_RATE_LIMITED — все решения реализации.

Область: устойчивость к перебору, пользовательский опыт

Направление: следовать отраслевым нормам (например, экспоненциальный откат); спецификация реализации определяет значения по умолчанию.

4. TTL по умолчанию и модель продления для Authorization Grant

Проблема: уровень протокола требует только явного expiresAt; конкретные модели, такие как продление, скользящее истечение или короткий TTL плюс refresh-токены, оставлены спецификации реализации.

Область: пользовательский опыт, безопасность, совместимость с источниками унаследованной аутентификации

Направление: спецификации реализации могут вводить тип RefreshGrant или применять дифференцированные TTL по legacySourceKind.

5. Семантика отзыва Human ID

Проблема: на текущем уровне протокола Human ID не входят в состояние REVOKED. Путь восстановления после компрометации Mnemonic (повторный выпуск Human ID, миграция репутации и т. д.) — вне области этой спецификации.

Область: восстановление после катастроф, непрерывность репутации

Направление: может развиваться в сторону:

Механизма «миграции репутации» более высокого уровня (on-chain декларация, отображающая старый opaqueRef → новый opaqueRef)
Или ограниченного отзыва Human ID плюс механизма правопреемника в протоколе v2

6. Спецификация пространства имён resourceRef

Проблема: эта спецификация только предлагает форму <scheme>://<authority>/<path>; формальная грамматика может развиться в отдельную спецификацию или согласоваться с существующим стандартом URI.

Область: совместимость между реализациями

Направление: может образовать отдельную спецификацию «FayID Resource Identifier» или напрямую принять стандарт URI RFC 3986.

7. Совместимость между экземплярами FayID System

Проблема: при сосуществовании нескольких развёртываний FayID System (управляемых разными операторами) глобальная уникальность Human ID / iFay ID / Organization ID требует механизма глобального пространства имён или префиксного разделения.

Область: экосистемы с несколькими операторами, межцепочечная совместимость

Направление: может стать ключевой темой FayID v2. Кандидаты:

Префиксы пространства имён (например, hid_us_xxx против hid_eu_xxx)
Корневой именной авторитет в стиле DNSSEC
On-chain реестр

8. Ротация ключей для opaqueRef GMC

Проблема: ротация gmc_namespace_secret нарушает непрерывность долгосрочной репутации — один и тот же Human ID производит разные opaqueRef под старым и новым ключами.

Область: непрерывность репутации, безопасность ключей

Направление:

Спроектировать окно сосуществования старых и новых секретов пространства имён
Или установить эквивалентность между старыми и новыми ссылками через on-chain «декларацию миграции opaqueRef»
Этот пункт требует отдельного ADR

9. Механизм обеспечения соблюдения Свойства P9

Проблема: уровень протокола задаёт поведение «Human ID никогда не покидают систему и никогда не появляются в журналах»; механизмы обеспечения на стороне реализации (метки системы типов, redact при сериализации, статические сканирования CI) выбираются спецификацией реализации.

Область: качество реализации, аудит безопасности

Направление:

На уровне системы типов: использовать newtypes / branded types для отличия Human ID от других сущностей
На уровне сериализации: redact по умолчанию с явными переключателями белого списка
На уровне CI: статические сканирования путей исходящего содержимого и путей журналирования

10. Классификация уровней доверия источников унаследованной аутентификации

Проблема: должны ли все традиционные учётные данные равно обмениваться на Authorization Grant? Должны ли SMART_CONTRACT и PASSWORD применять разные потолки TTL?

Область: политика безопасности, контроль рисков

Направление:

Ввести отображение legacySourceKind → потолок TTL
Применять более короткие TTL к источникам с меньшим доверием (например, простой PASSWORD)
Ослабить ограничения для источников с большим доверием (например, SMART_CONTRACT)

Архивация и отслеживание

10 пунктов выше будут архивированы в .kiro/specs/fayid-identity-system/open-questions.md в предстоящей Task 8, причём каждая запись будет помечена:

owner: куратор проблемы
scope: затрагиваемые подсистемы
resolution milestone: v1 / v2 / спецификация реализации / ADR

Эта глава служит «индексом открытых вопросов» blueprint и лишь кратко переформулирует проблемы; детальную архивацию и отслеживание см. в предстоящем open-questions.md.