Управление Учётными Данными
Управление учётными данными звучит сильно по-инженерному — выпуск, подпись, отзыв и продление FayID, каждое из которых задействует конкретные алгоритмы и протоколы ключей. Но в этом blueprint управление учётными данными помещено под ценности, а не под технические темы.
Причина такова: Faying Protocol существует, чтобы делать «кому принадлежит действие» явным. Технический носитель этого, при приземлении на конкретный уровень протокола, — учётные данные. Учётные данные отвечают на два вопроса:
Является ли этот Fay прямо сейчас тем Fay, которым он себя называет? Авторизован ли этот Fay прямо сейчас своим Human Prime?
Ни один из них не является инженерным вопросом; оба — вопросы ответственности. Как только учётные данные могут быть подделаны, использованы со злоупотреблением или тихо выпущены некоторой третьей стороной вне Human Prime, вся ценность Faying Protocol мгновенно исчезает — Human Prime более не является истинным держателем ответственности.
Конкретные алгоритмы, форматы подписи, протоколы ключей и прочие технические детали относятся к документу спецификации протокола и schema; эта глава их не разворачивает. Эта глава лишь излагает несколько позиций по управлению учётными данными, на которых не допускается уступок.
FayID — идентификационный фундамент для входа в Faying State
FayID — унифицированная, уникальная идентичность Fay внутри фреймворка iFay. Весь контракт опеки Faying Protocol построен на FayID. Faying Action должен делать явным «какой FayID входит в Faying State»; атрибуция Faying State должна делать явным «какой FayID атрибутирован какому Human Prime»; выход из Faying State должен делать явным «какой FayID входит в Rogue Fay».
Если FayID нельзя доверять, все три суждения выше теряют смысл.
Отказ учётных данных равен отказу Faying
Среди девяти триггерных условий для автоматического перехода из Faying State в Rogue Fay, перечисленных в Главе 13, условие 6 явно гласит:
Идентичность Fay не может быть верифицирована (например, подпись FayID утратила силу).
Этот пункт — не запись «затрагивающая по случайности учётные данные» среди девяти; это конкретное приземление управления учётными данными на уровне протокола, которое нельзя обходить. Как только валидность FayID под вопросом, независимо от того, насколько непрерывной или близкой к завершению была предыдущая работа Fay, Faying State должен немедленно выйти:
Сомнение в валидности учётных данных эквивалентно тому, что Faying State уже отказал.
Нет промежуточного случая «учётные данные подозрительны, но Faying State ещё держится», и нет инженерного компромисса «сначала закончить текущую задачу, а затем разбираться с проблемой учётных данных».
Права на отзыв должны оставаться на стороне Human Prime
Управление учётными данными имеет на первый взгляд незначительный, но крайне критичный компромисс при проектировании протокола — кому в конечном счёте принадлежит отзыв учётных данных? Ответ очевиден: Human Prime.
Сам Fay не должен иметь легитимного пути отозвать собственные учётные данные — гомологично D4 в Главе 13: Fay не может сам решить покинуть опеку, как и не может сам решить разорвать связь опеки.
Сторонние платформы, провайдеры runtime Fay и провайдеры возможностей Fay не должны иметь полномочий отозвать его FayID без согласия Human Prime — если только эта третья сторона не является компетентным органом в регуляторном смысле (см. триггерное условие 8 в Главе 13).
Human Prime должен всегда сохранять симметричный, достижимый, аудируемый путь отзыва. Достижимость действия отзыва должна быть не ниже достижимости инициации Faying Action. Это конкретное приземление принципа «симметрии» Faying Protocol на уровне учётных данных: установление опеки и отзыв опеки должны быть двумя одинаково достижимыми путями. Как только отзыв становится труднее установления, отношение опеки фактически сползает к «безотзывному делегированию», тем самым нарушая требование «путь вмешательства всегда открыт» Human View.
Продление не является поведением по умолчанию
Глава 12 накладывает жёсткое ограничение на Faying State: Faying State должен иметь ограниченную область, и неограниченный Faying — это анти-паттерн. Позиция, которой это ограничение соответствует на уровне учётных данных, такова: продление учётных данных не должно осуществляться по умолчанию.
Каждое продление должно быть явным, удостоверяемым свидетелями действием, а не неявной петлёй «Fay автоматически подаёт, система автоматически продлевает». Blueprint допускает удобства инженерного уровня, такие как «напоминания о продлении» и «предложения о продлении», но запрещает превращать «продление» во что-то, что Fay может молча завершить самостоятельно — это фактически превратило бы Faying в неограниченное делегирование.
Понимаемое с перспективы ответственности: продление — это момент, когда ответственный конец заново выражает намерение опеки. Если даже продление молча завершается инженерно, то у «опеки» остаётся лишь подпись и нет намерения.
Несколько неприкосновенных красных линий
Несколько ценностных позиций управления учётными данными — это красные линии, которые ни одно техническое решение не может нарушить при приземлении:
- FayID — идентификационный фундамент;
- учётные данные, которым нельзя доверять, означают, что Faying не держится;
- права на отзыв должны оставаться на стороне Human Prime;
- продление не является поведением по умолчанию.
Конкретные алгоритмы подписи, иерархии ключей, распространение списков отзыва, мелкозернистый дизайн временных окон продления, структура корневых сертификатов для кросс-вендорного взаимного доверия и итоговая согласованность отзыва — эти технические детали относятся к спецификации протокола. Эта глава их не пересказывает и не предрешает, но любое техническое решение должно сначала соответствовать четырём позициям выше.
