Кратко

  • Индивидуальный Internet-Draft Capability Language Core от 27 сентября предлагает третье решение — allow_unresolved, когда ограничение известно по форме, но ещё не проверено.
  • Все оставшиеся условия обязан разрешить потребитель решения до выполнения команды; три реализации одного автора пока не доказывают независимую совместимость.

Ограничение в доверенности агента может быть записано безупречно: операция допустима лишь из определённой сети и в заданный промежуток времени. Но общий механизм разбора не обязательно видит текущий сетевой маршрут и знает, по каким часам применять правило. Если его ответ «условие распознано, но не оценено» свести к простому разрешению, текст ограничения сохранится, а защита исчезнет. Предложение Jijie Wei формализует именно эту опасную паузу между чтением правила и исполнением.

Версия draft-wei-capability-language-core-00 датирована 27 сентября 2026 года. Это индивидуальный Internet-Draft с предполагаемым статусом Experimental. В Datatracker он находится на стадии I-D Exists, причём страница прямо говорит: индивидуальная подача не означает формального одобрения IETF. Перед нами не RFC и не подтверждение внедрения. Проект задаёт язык идентификаторов возможностей, правило соотнесения выданного права с конкретной операцией, пересечение прав из разных источников и детерминированный ответ с кодом причины.

Раздел 8.4 отделяет третий ответ от обычного «можно». Если ядро v1 распознаёт синтаксис временного или сетевого условия, но не располагает его оценщиком, условие остаётся в списке unresolved. Итогом становится allow_unresolved, а не allow. Получатель такого решения — профиль применения или узел принудительного контроля — должен подтвердить каждое оставшееся условие прежде, чем разрешить действие. Если подтверждение невозможно, он обязан отказать. Несколько условий соединяются через «и»: первое успешное подтверждение не погашает второе.

Механизм Resolve из следующего раздела принимает для каждого условия ответ «выполнено», «нарушено» или «неизвестно» и возвращает обновлённое решение. Однако сама процедура обратной связи не создаёт достоверного наблюдения о сети, не назначает доверенные часы и не устанавливает внешние полномочия. Если переходник к старому интерфейсу трактует любое значение, кроме deny, как сигнал к запуску, он теряет смысл третьего ответа. Это архитектурный риск, выведенный из текста проекта, а не известный инцидент или найденная уязвимость.

CLC сознательно не подменяет остальные звенья. Он не решает, кому доверять как издателю права, как проверить подпись исходного носителя, что произошло после запуска и как должен выглядеть токен или квитанция. RFC 9396 уже определяет параметр authorization_details для подробных запросов OAuth; проект лишь называет такой носитель возможным потребителем своего языка. RFC не утверждал CLC и не переносит на него автоматически правила доверия.

Документ сообщает о 123 тестовых векторах и 1184 проверках свойств авторизационной части. Реализации на Go, Python и TypeScript проходят их, но написаны одним автором. Сам проект признаёт: это регрессионная проверка описания, а не независимое подтверждение; порог двух самостоятельных реализаций пока не достигнут. Базовый класс CLC-A заявлен, класс для стороны доказательств CLC-E — нет. Читателю полезно видеть одновременно точность предлагаемой процедуры и пределы её проверки.

Источники