Модель аккаунта#

Контракт#

  • Реализация core ДОЛЖНА включать Account как доменную сущность первого класса.
  • Один аккаунт ДОЛЖЕН владеть нулем или более библиотек; каждая библиотека ДОЛЖНА принадлежать ровно одному аккаунту.
  • Одна активная сессия ДОЛЖНА быть привязана ровно к одному аккаунту.
  • Операции в контексте библиотеки в одной активной сессии ДОЛЖНЫ работать ровно с одной активной библиотекой.

Атрибуты аккаунта#

  • id ДОЛЖЕН существовать и ДОЛЖЕН быть неизменяемым.
  • status ДОЛЖЕН существовать и задавать границу блокировки (locked/unlocked или эквивалент).
  • security_policy_ref ДОЛЖЕН существовать и НЕ ДОЛЖЕН содержать секреты в открытом виде.
  • default_library_id МОЖЕТ присутствовать; если задан, он ДОЛЖЕН ссылаться на библиотеку того же аккаунта.
  • Дополнительные метаданные МОГУТ присутствовать и являются implementation-defined.

Жизненный цикл#

  • init ДОЛЖЕН создавать ровно один локальный аккаунт в новом vault.
  • Повторный init для инициализированного vault ДОЛЖЕН отклоняться, если не запущен явный reset/force flow.
  • Runtime-состояния ДОЛЖНЫ быть эквивалентны uninitialized -> locked -> unlocked -> locked.

Правила сессии и доступа#

  • После unlock сессия ДОЛЖНА быть привязана к одному account_id.
  • Операции уровня Raw МОГУТ выполняться без выбора активной библиотеки.
  • Cross-account операции в одной активной сессии ДОЛЖНЫ отклоняться.
  • Операции записи в доменные сущности ДОЛЖНЫ отклоняться, пока сессия заблокирована.
  • Операции export/import ДОЛЖНЫ выполняться в контексте активного аккаунта.

Что не входит в модель аккаунта#

  • Нет требований по email/username/avatar.
  • Нет требований по OAuth или social identity.
  • Нет client/device UI-настроек в core-схеме аккаунта.