Аннотация
Этот документ определяет механизм для описания и сигнализации нескольких аспектов транзакции с цифровой идентификацией и ее участников. Эти аспекты используются для определения степени доверия к этой транзакции.
Скачать оригинальный документ на английском языке RFC 8485 PDF
Оглавление
1. Введение
1.1. Требования Языка
1.2. Терминология
1.3. Модель идентичности
1.4. Компонентная архитектура
2. Определения размеров компонентов
2.1. Идентификация личности (P)
2.2. Основное использование учетных данных (C)
2.3. Первичное управление учетными данными (M)
2.4. Презентация утверждения (A)
3. Передача векторных значений в RP
3.1. Представление на проводе
3.2. В OpenID Connect
4. Запрос векторных значений
4.1. В OpenID Connect
5. Знаки доверия
6. Определение новых векторных значений
7. Соображения IANA
7.1. Вектор доверия Компонентов Реестра
7.1.1. Шаблон регистрации
7.1.2. Начальное содержимое реестра
7.2. Добавление в реестр параметров OAuth
7.3. Дополнения к Реестру претензий JWT
7.4. Дополнения к OAuth Token Introspection Response
8. Вопросы безопасности
9. Вопросы конфиденциальности
10. Ссылки
10.1. Нормативные ссылки
10.2. Информационные ссылки
Приложение A. Векторы значений компонента доверия по умолчанию
A.1. Идентификация личности
А.2. Основное использование учетных данных
А.3. Первичное управление учетными данными
А.4. Презентация утверждения
Благодарности
Адреса авторов
Статус этой заметки
Это документ по отслеживанию стандартов Интернета.
Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественную рецензию и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 7841.
Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу https://www.rfc-editor.org/info/rfc8485.
Уведомление об авторских правах
Авторское право (c) Траст IETF 2018 года и лица, указанные в качестве авторов документа. Все права защищены.
На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (https://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны содержать текст Упрощенной лицензии BSD, как описано в Разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в Упрощенной лицензии BSD.
1. Введение
Методы измерения доверия в транзакциях цифровой идентификации исторически делятся на две основные категории: либо все измерения объединяются в одно скалярное значение, либо решения о доверии рассчитываются локально на основе подробного набора метаданных атрибута. Этот документ определяет метод передачи информации о доверии, который является более выразительным, чем одно значение, но менее сложным, чем полные метаданные атрибута.
До третьего издания [SP-800-63-3], опубликованного в 2017 году, в специальной публикации NIST 800-63 [SP-800-63-2] использовалось единственное скалярное измерение доверия, называемое уровнем доверия (LoA). LoA может использоваться для сравнения различных транзакций в системе на грубом уровне. Например, транзакция LoA4 обычно считается более надежной (по всем измеренным категориям), чем транзакция LoA2. LoA для данной транзакции вычисляется поставщиком удостоверений (IdP) и используется проверяющей стороной (RP). Поскольку измерение доверия представляет собой простое числовое значение, для RP достаточно просто обработать и сравнить. Однако, поскольку каждый LoA включает в себя множество различных аспектов транзакции, он не может выразить многие ситуации в реальном мире. Например, учетная запись анонимного пользователя может иметь очень сильные учетные данные, например, обычную для осведомителя или политического диссидента. Несмотря на сильные учетные данные, отсутствие удостоверения личности может привести к тому, что любые транзакции, проводимые учетной записью, попадут в низкий LoA. Кроме того, разные варианты использования и домены требуют слегка разных определений для своих категорий LoA, а LoA2 одной группы не эквивалентен или даже не сопоставим с LoA2 другой группы.
Системам управления доступом на основе атрибутов (ABAC), используемым RP, возможно, потребуется знать подробности об атрибутах пользователя, например, как недавно данные атрибута были проверены и кем. Системы метаданных атрибутов способны выражать чрезвычайно мелкие детали о транзакции. Однако этот подход требует от IdP сбора, хранения и передачи всех данных этого атрибута для потребления RP. RP должен обрабатывать эти данные, которые могут быть запрещающими для тривиальных решений безопасности.
Подход «Векторы доверия» (VoT), предложенный в этом документе, ищет баланс между этими двумя альтернативами, позволяя выражать множество аспектов транзакции идентификации (включая, помимо прочего, проверку личности, проверку учетных данных, управление учетными данными и силу утверждений), без требуется полное описание метаданных атрибута. Этот метод измерения дает более действенные данные и выразительность, чем LoA, но для RP все еще относительно легко обрабатывать. Предполагается, что VoT может использоваться наряду с более подробными системами метаданных атрибутов, такими как система, предложенная NISITIR 8112 [NISTIR-8112]. RP может использовать значение вектора для большинства базовых решений, но при необходимости может запрашивать IdP для дополнительных метаданных атрибута. Кроме того, для RP, которые не нуждаются в более детальной детализации вектора, ожидается, что некоторые доверительные структуры обеспечат простое отображение между определенными наборами векторных значений в LoA. В таких системах RP предоставляется выбор, сколько деталей запрашивать у IdP для обработки данной транзакции.
Этот документ определяет модель данных для этих векторов и формат для передачи их между сторонами. Значения векторов, определенных моделью данных, привязаны к определению доверия. Этот документ также предоставляет руководство по определению значений для использования при передаче этой информации, включая четыре категории компонентов и руководство по определению значений в этих категориях. Кроме того, этот документ определяет универсальный набор значений компонентов в приложении (Приложение A) для случаев использования, которым не требуется что-то более конкретное.
1.1. Требования Языкf
Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].
1.2. Терминология
Федерация идентификации (Identity Federation): протокол, в котором провайдер идентификации (IdP) устанавливает идентификационную информацию пользователя в RP. посредством использования криптографического утверждения или другого проверяемого механизма или системы, реализующей такой протокол. Это также упоминается просто как «федерация».
Поставщик удостоверений (Identity Provider — IdP): система, которая управляет идентификационной информацией и может передавать эту информацию по сети через API идентификации.
Субъект идентификации (Identity Subject): индивидуум (пользователь), участвующий в транзакции идентификации, то есть идентифицируемый провайдером идентификации для RP.
Идентификация личности (Identity Proofing): процесс проверки и подтверждения того, что набор атрибутов идентичности принадлежит реальному субъекту идентичности.
Первичные учетные данные (Primary Credential): средства, используемые субъектом удостоверения для проверки подлинности поставщика удостоверений.
Федеративные учетные данные (Federated Credential): утверждение, представленное IdP в RP по сети для аутентификации пользователя.
Проверяющая сторона (RP — Relying Party): система, которая использует идентификационную информацию от IdP для аутентификации пользователя.
Доверительная структура (Trust Framework): документ, содержащий бизнес-правила и юридические положения, которые определяют, как могут действовать разные стороны в транзакции идентификации.
Метка доверия (Trustmark): URL-адрес, ссылающийся на конкретную структуру доверия и ее определение векторных компонентов и значений векторных компонентов.
Поставщик меток доверия (Trustmark Provider). Определяет структуру доверия, на которую ссылается его знак доверия, и может проверить, что данная система (например, поставщик идентификаторов) способна утверждать и разрешать утверждать значения компонентов вектора, на которые она претендует.
Вектор (Vector): структура данных, состоящая из нескольких частей, которая используется здесь для передачи информации о транзакции аутентификации.
Компонент вектора (Vector Component): одна из нескольких составных частей, составляющих вектор, указывающая категорию информации.
Значение компонента вектора (Vector Component Value): одно из значений, примененных к компоненту вектора внутри вектора.
1.3. Модель идентичности
Этот документ предполагает следующую модель идентификации на основе технологий федерации идентификации:
Субъект идентификации (также известный как пользователь) связан с провайдером идентификации, который действует как доверенная третья сторона от имени пользователя, в отношении RP, делая утверждения идентичности о пользователе в RP.
Реальный индивид, представленный субъектом идентификации, обладает первичными учетными данными, привязанными к субъекту идентификации провайдером идентификации (или его агентом) таким образом, что связь между учетными данными и реальным пользователем является представление процесса проверки личности, выполняемого провайдером идентификации (или его агентом) для проверки личности реального человека. Эта информация передается по сети как часть подтверждения идентичности, представленного RP во время транзакции аутентификации.
1.4. Компонентная архитектура
Термин «Векторы доверия» основан на математической конструкции вектора, которая определяется как элемент, состоящий из нескольких независимых значений.
Важная цель этой работы — сбалансировать потребность в простоте (особенно со стороны RP) и потребность в выразительности. Как таковая, эта векторная конструкция предназначена для компоновки и расширения.
Вектор состоит из ортогональных компонентов, так что ни один аспект компонента не перекрывает аспект другого компонента настолько, насколько это возможно.
2. Определения размеров компонентов
В этой спецификации определяются четыре ортогональных компонента: проверка личности, первичное использование учетных данных, первичное управление учетными данными и представление утверждений.
Эта спецификация также определяет значения для каждого из этих компонентов, которые будут использоваться при отсутствии более конкретной структуры доверия в Приложении А. Ожидается, что структуры доверия предоставят контекст, семантику и сопоставление с правовыми законами и бизнес-правилами для каждого значения в каждый компонент.
Следовательно, конкретное значение вектора можно сравнивать только с векторами, определенными в контексте конкретной структуры доверия. RP ДОЛЖЕН понимать и принимать во внимание контекст структуры доверия, в котором выражается вектор, для правильной обработки вектора.
Каждый компонент идентифицируется демаркатором, состоящим из одной заглавной буквы ASCII в диапазоне «[A-Z]». Демаркатор ДОЛЖЕН отражать категорию, с которой он связан естественным образом. Демаркаторы для компонентов ДОЛЖНЫ быть зарегистрированы, как описано в Разделе 7. Предполагается, что определения структуры доверия будут использовать этот реестр для определения специализированных компонентов, но РЕКОМЕНДУЕТСЯ, чтобы структуры доверия повторно использовали существующие категории компонентов, где это возможно. Один и тот же демаркатор НЕ ДОЛЖЕН использоваться для двух разных измерений, и разные структуры доверия ДОЛЖНЫ использовать один и тот же демаркатор для аналогичной информации. Кроме того, ожидается, что со временем будет относительно мало измерений компонентов, и в данной спецификации в этом разделе определены четыре категории общего назначения. Обратите внимание, что, поскольку обработка для всех векторных значений является контекстуальной для структуры доверия, точная семантика интерпретации компонента будет варьироваться в зависимости от используемой структуры доверия.
Значение для данного компонента в векторе доверия определяется его символом-разделителем, за которым следует одиночная цифра или строчная буква ASCII в диапазоне «[0-9a-z]». Категории с естественным порядком ДОЛЖНЫ предпочитать цифры, причем большие цифры указывают на более сильные утверждения, чем меньшие цифры.
Категории, которые не имеют естественного упорядочения или могут иметь неоднозначное упорядочение, ДОЛЖНЫ предпочитать буквы. Обратите внимание, что, хотя буквы могут также подразумевать порядок, они также могут более естественно использоваться мнемонически. Доверительные структуры МОГУТ использовать любые возможные значения в категории без необходимости быть смежными.
Категории МОГУТ использовать одновременно буквы и цифры. Например, категория может определять «0» как означающее «оператор не сделан» при использовании таких букв, как «a», «b» и «c» для нормальных значений, чтобы указать конкретные параметры. Другая система может иметь упорядоченный базовый набор цифр с дополнительными деталями, представленными буквами.
Каждый компонент МОЖЕТ быть повторен с несколькими различными значениями в пределах одного вектора, представляющего логическое И значений (подробности см. В разделе 3.1). Одна и та же комбинация компонентов и значений НЕ ДОЛЖНА повторяться в пределах одного вектора. Например, вектор может содержать как «P1», так и «Pa», но не два экземпляра «P1». Структура доверия МОЖЕТ определять дополнительные ограничения на комбинации значений.
Независимо от типа значения, RP НЕ ДОЛЖЕН предполагать, что значения, назначенные каждому компоненту вектора, имеют присущие им порядковые или подчиненные свойства по сравнению с теми же или другими компонентами в векторном пространстве без специальных знаний об используемой структуре доверия. Другими словами, «1» всегда отличается от «2», но опасно предполагать, что «2» всегда лучше, чем «1» или что «2» удовлетворяет всем требованиям «1».
2.1. Идентификация личности (P)
Измерение проверки личности в целом определяет, насколько сильно проверен и проверен набор атрибутов идентичности. Другими словами, это измерение описывает, насколько вероятно, что данная транзакция цифрового идентификатора соответствует конкретному (реальному) субъекту идентификации. Например, должен ли пользователь предоставить документацию доверенной стороне, чтобы подтвердить свое юридическое имя и адрес, или он мог самостоятельно утверждать такие ценности?
В этом измерении используется разграничитель «P», такой как «P0», «P1» и т. д. Большинство определений проверки личности будут иметь естественный порядок, так как более или менее строгие проверки могут применяться к человеку, которому предоставляется учетная запись. В таких случаях РЕКОМЕНДУЕТСЯ, чтобы для этого компонента использовалась цифра и чтобы в транзакции было разрешено передавать только одно значение.
2.2. Основное использование учетных данных (C)
Измерение использования первичных учетных данных определяет, насколько сильно IdP может проверять первичные учетные данные. Другими словами, насколько легко это удостоверение может быть подделано или украдено. Например, входил ли пользователь в систему с паролем, биометрическим, криптографическим аппаратным устройством или какой-либо комбинацией вышеперечисленного?
В этом измерении используется демаркатор «C», такой как «Ca», «Cb» и т. д. Большинство определений использования учетных данных не будут иметь общего естественного порядка, поскольку в структуре доверия может быть несколько эквивалентных классов. В таких случаях РЕКОМЕНДУЕТСЯ использовать букву для этого компонента и разрешать одновременную передачу нескольких различных факторов использования учетных данных, например, при использовании многофакторной аутентификации.
2.3. Первичное управление учетными данными (M)
Измерение управления первичными учетными данными передает информацию об ожидаемом жизненном цикле использования основных учетных данных, включая его привязку, ротацию и отзыв. Другими словами, использование и сила политик, практик и средств управления безопасностью, используемых при управлении учетными данными в IdP, и их привязка к предполагаемому лицу. Например, может ли пользователь принести свое криптографическое устройство или оно предоставлено IdP?
В этом измерении используется демаркатор «M», например «Ma», «Mb» и т. Д. Большинство определений управления учетными данными не будут иметь общего естественного порядка, хотя в некоторых обстоятельствах могут быть предпочтения и сравнение между значениями. В таких случаях РЕКОМЕНДУЕТСЯ использовать букву для этого компонента и разрешать одновременное сообщение нескольких различных значений.
2.4. Презентация утверждения (A)
Измерение представления утверждения определяет, насколько хорошо данная цифровая идентификация может быть передана по сети без утечки информации непреднамеренным сторонам и без подмены. Другими словами, это измерение описывает, насколько вероятно, что данный цифровой идентификатор был утвержден данным поставщиком идентификационных данных для субъекта идентификации данной транзакции. Хотя эта информация в значительной степени уже известна RP как побочный эффект обработки подтверждения идентичности в протоколе федерации, это измерение все еще очень полезно, когда RP запрашивает вход в систему (см. Раздел 4) и при описании возможностей IdP. Это значение также позволяет RP определять, когда утверждение представлено способом, для которого оно не предназначалось, как, например, в случае атаки.
В этом измерении используется разграничитель «A», например «Aa», «Ab» и т. д. Большинство определений представления утверждений не будут иметь общего естественного порядка. В таких случаях РЕКОМЕНДУЕТСЯ использовать букву для этого компонента и разрешить одновременное сообщение нескольких значений.
3. Передача векторных значений в RP
Вектор доверия предназначен для использования в контексте транзакции идентификации и аутентификации, предоставляя информацию о контексте федеративных учетных данных. Следовательно, вектор должен иметь возможность сообщаться в контексте федеративных учетных данных таким образом, который строго связан с утверждением, представляющим федеративные учетные данные.
Этот вектор имеет несколько требований для использования.
o Все применимые компоненты вектора и значения должны быть объединены в один вектор.
o Вектор может передаваться по проводам без разрывов и без преобразования.
o Все векторные компоненты должны оставаться индивидуально доступными, а не «сворачиваться» в одно значение.
o Вектор должен быть защищен при транспортировке.
o Вектор должен быть криптографически связан с утверждением, которое он описывает.
o Вектор должен интерпретироваться в контексте определенного определения структуры доверия, идентифицируемого URL-адресом доверия.
Эти требования приводят нас к определению простого представления вектора на основе строк, которое может быть включено в ряд различных местоположений и протоколов без дальнейшего кодирования.
3.1. Представление на проводе
Вектор ДОЛЖЕН быть представлен в виде списка векторных компонентов, разделенных точками (’.’). Тип компонента вектора может встречаться несколько раз в пределах одного вектора, но конкретное значение компонента вектора не может встречаться более одного раза в одном векторе. То есть, хотя «Cc.Cd» является допустимым вектором, «Cc.Cc» — нет. Несколько значений для компонента считаются логическим И значений.
Значения компонентов вектора МОГУТ появляться в любом порядке в пределах вектора, и RP ДОЛЖЕН учитывать различные порядки одного и того же векторного эквивалента во время обработки. Например, «P1.Cc.Cd.Aa», «Aa.Cc.Cd.P1», «Cd.P1.Cc.Aa» и «Aa.P1.Cd.Cc» все считаются эквивалентными друг другу.
Возможные компоненты вектора МОГУТ быть опущены из вектора. Для пропущенного векторного компонента не осталось места для хранения. Если компонент вектора отсутствует, вектор не претендует на этот компонент. Значения по умолчанию для отсутствующей категории компонентов не предполагаются.
Векторные значения ДОЛЖНЫ передаваться вместе с URL-адресом метки доверия (см. Раздел 5), чтобы получить контекст компонентов и значения компонентов. Знак доверия ДОЛЖЕН быть криптографически привязан к значению вектора, например, к двум значениям, переносимым вместе в утверждении со знаком. Значение вектора без контекста не обрабатывается, а векторы, определенные в разных контекстах, не могут напрямую сравниваться как целые значения. Различные структуры доверия МОГУТ повторно использовать определения компонентов (в том числе их значения), но обработка таких межконтекстных значений выходит за рамки данной спецификации.
Например, вектор «P1.Cc.Ab» переводится как «псевдоним, подтверждение общего ключа, подписанное проверенное утверждение, подтвержденное браузером, и не претендует на управление учетными данными» в контексте определений этой спецификации (см. Приложение A). Другой вектор «Cb.Mc.Cd.Ac» переводится как «известное устройство», полное подтверждение, необходимое для выдачи и ротации учетных данных, криптографическое подтверждение владения общим ключом, проверенное утверждение обратного канала с подписью и никаких претензий к проверке личности «в том же контексте. Поскольку здесь не делается никаких претензий для проверки личности, RP не может принимать какое-либо конкретное значение. Обратите внимание, что это вовсе не означает, что пользователь вообще не был проверен: возможно, что пользователь был полностью проверен на самые высокие возможности в рамках структуры доверия, но здесь IdP не делает никаких конкретных заявлений о проверке RP, возможно, для защиты конфиденциальности пользователя.
3.2. В OpenID Connect
В OpenID Connect [OpenID] IdP ДОЛЖЕН отправить вектор в виде строки в заявке «vot» (вектор доверия) в маркере ID. Знак доверия (см. Раздел 5), который применяется к этому вектору, ДОЛЖЕН быть отправлен в виде URL-адреса в утверждении «vtm» (векторный знак доверия), чтобы обеспечить контекст для вектора.
Заявления «vot» и «vtm» интерпретируются RP для применения ко всей транзакции идентификации, а не обязательно к какому-либо конкретному атрибуту.
Например, предположим, что для данной метки доверия тело идентификатора токена, запрашивающего «псевдоним, подтверждение общего ключа, подписанный токен обратного канала и отсутствие претензий в отношении управления учетными данными», может выглядеть как полезная нагрузка объекта JSON [RFC8259] объекта Идентификационный токен
{
«iss»: «https://idp.example.com/»,
«sub»: «jondoe1234»,
«vot»: «P1.Cc.Ac»,
«vtm»: «https://example.org/vot-trust-framework»
}
Тело ID-токена подписано и при желании зашифровано с помощью подписи и шифрования объектов JSON (JOSE) в соответствии со спецификацией OpenID Connect. Помещая значения «vot» и «vtm» в токен ID, вектор и его контекст строго привязываются к федеративным учетным данным, представленным токеном ID.
Векторные значения МОГУТ быть возвращены в ответе самоанализа токена [RFC7662], описывающем идентификатор токена или токен доступа, выданный во время транзакции OpenID Connect с использованием тех же утверждений.
4. Запрос векторных значений
В некоторых протоколах идентификации RP может запрашивать использование конкретных значений вектора для данной транзакции идентификации. RP может описывать конкретные значения компонента вектора, которые он желает утвердить IdP для данной транзакции идентификации, используя тот же синтаксис, который определен в Разделе 3.1. Обработка и выполнение этих запросов входит в компетенцию IdP, а детали выходят за рамки данной спецификации.
Будущие спецификации МОГУТ определять альтернативные способы для RP запрашивать векторные значения у IdP.
4.1. В OpenID Connect
В OpenID Connect [OpenID] клиент МОЖЕТ запросить частичный набор приемлемых значений VoT с запросом заявки «vtr» (вектор доверия) как часть объекта запроса. Значением этого поля является массив строк JSON [RFC8259], каждая строка идентифицирует приемлемый набор векторных компонентов. Значения компонентов в каждом векторе объединяются в AND, а отдельные векторы — в OR. Например, список векторов в форме ‘[«P1.Cb.Cc.Ab», «Ce.Ab»] «указывает, что либо полный набор» P1 И Cb И Cc И Ab «одновременно, либо полный Набор «Ce AND Ab» одновременно приемлем для данного RP для данной транзакции.
Значения запроса вектора МОГУТ пропускать компоненты, указывая, что любое значение является приемлемым для этой категории компонентов, включая пропуск этого компонента в векторе ответов.
Механизм, с помощью которого IdP обрабатывает «vtr» и сопоставляет его с транзакцией аутентификации, выходит за рамки данной спецификации.
5. Знаки доверия
Знак доверия — это URL-адрес HTTPS, который ссылается на определенный набор векторных значений, как это определено в структуре доверия. Этот URL ДОЛЖЕН указывать на читаемый человеком документ, в котором описывается, какие компоненты и значения являются допустимыми, как они используются вместе и какие практики значения компонентов представляют в структуре доверия. Содержание URL-адреса метки доверия ДОЛЖНО быть доступно для операторов или разработчиков RP. URL ДОЛЖЕН быть стабильным во времени для данной структуры доверия, чтобы RP могли обрабатывать входящие векторы согласованным образом. В новых версиях структуры доверия, которые требуют других правил обработки, ДОЛЖНЫ использоваться другие URL-адреса доверия.
Например, <https://www.rfc-editor.org/info/rfc8485> используется в качестве знака доверия для ссылки на значения, определенные в Приложении А.
Процесс поставщика меток доверия, определяющего способность конкретного IdP правильно утверждать значения из данной структуры доверия, выходит за рамки данной спецификации. Определение того, как RP должен применять значения данного вектора к обработке RP, выходит за рамки данной спецификации.
6. Определение новых векторных значений
Векторы доверия призваны стать гибкой и многократно используемой структурой для передачи данных аутентификации между сетевыми сторонами в протоколе федерации идентификации. Однако точный характер необходимой информации зависит от сторон, которым требуется информация, и отношений между ними. Хотя в этом документе определен пригодный для использования набор значений по умолчанию в Приложении A, ожидается, что во многих ситуациях потребуется расширение этой спецификации для их собственного использования.
Категории компонентов, такие как те, которые определены в Разделе 2, должны быть универсальными и многократно использоваться в различных структурах доверия. Спецификации расширения ДОЛЖНЫ повторно использовать существующие определения категорий, где это возможно. Расширения МОГУТ создавать дополнительные категории, где это необходимо, используя реестр, определенный в Разделе 7. Реестр поощряет повторное использование и обнаружение существующих категорий в различных доверительных структурах. Например, категорию «P» в другой структуре СЛЕДУЕТ использовать для проверки личности и связанной информации.
Значения компонентов, таких как те, которые определены в Приложении A, предназначены для того, чтобы соответствовать контексту определяющего доверительного документа. В то время как значения компонентов этой спецификации предназначены для общего назначения, и расширения МОГУТ повторно использовать значения и их определения, доверительные структуры ДОЛЖНЫ определять все допустимые значения. Поскольку эти значения всегда интерпретируются в контексте метки доверия, эти значения не записываются в центральном реестре. Следовательно, значение «P1» из одной структуры и значение «P1» из другой структуры могут иметь очень разные интерпретации в зависимости от их документов контекстной структуры доверия, даже если в обоих случаях компонент «P» используется для проверки личности каким-либо образом.
Доверительным структурам, которые реализуют эту спецификацию, СЛЕДУЕТ выбрать либо числовое упорядочение, либо подход групповой категории к значениям компонентов, как описано в разделе 2, хотя МОЖЕТ использоваться комбинации обоих типов. Доверительные структуры ДОЛЖНЫ указывать, разрешено ли несколько значений для каждой категории, и хотя любой категории компонентов, как правило, разрешено иметь несколько различных значений, конкретное определение набора значений в расширении МОЖЕТ ограничивать данную категорию компонентов одним значением для каждой транзакции. , РЕКОМЕНДУЕТСЯ, чтобы доверительные структуры использовали значение «0» для указания пустого или нулевого условия для данной категории (например, не выполняется проверка или не используется токен аутентификации).
На все структуры доверия, которые расширяют и реализуют эту спецификацию, ДОЛЖНЫ быть ссылки по уникальному URL-адресу метки доверия (см. Раздел 5), чтобы RP могли различать разные структуры доверия.
7. Соображения IANA
Эта спецификация создает один реестр и регистрирует несколько значений в существующих реестрах.
7.1. Вектор Траст Компонентов Реестр
Данная спецификация устанавливает реестр «Векторы доверенных компонентов».
Демаркаторы компонентов регистрируются политикой «Требуется спецификация», описанной в [RFC8126].
Критерии, которые должны применяться назначенными экспертами, включают в себя определение того, достаточно ли отличается предлагаемая регистрация от существующих записей для подтверждения регистрации, может ли она иметь общую применимость, и понятно ли описание регистрации. Поскольку вся обработка векторов является контекстуальной для структуры доверия, разграничители компонентов, которые не соответствуют этим критериям, могут все еще использоваться в структурах доверия. Реестр содержит векторные компоненты, которые, как считается, имеют общую применимость, которая также может использоваться.
В запросах на регистрацию, отправляемых в список рассылки vot@ietf.org для проверки, должна использоваться соответствующая тема (например, «Запрос на регистрацию имени вектора компонента доверия: пример»). Назначенный эксперт (-ы) предоставит проверку в течение двухнедельного периода и утвердит или отклонит запрос на регистрацию, сообщив это решение списку проверки и IANA. Отказы должны включать объяснение и, если применимо, предложения относительно того, как сделать запрос успешным. IANA должна принимать обновления реестра только от назначенного эксперта (-ов) и направлять все запросы на регистрацию в список рассылки vot@ietf.org. Если назначенные эксперты не отвечают в течение установленного периода, IANA должна связаться с IESG для получения рекомендаций.
7.1.1. Шаблон регистрации
Символ демаркатора (Demarcator Symbol): Заглавная буква ASCII в диапазоне [A-Z], представляющая этот компонент (например, «X»).
Описание (Description): Краткое описание компонента (например, «Пример описания»).
Изменить контроллер (Change Controller): Для RFC-потоков IETF укажите «IESG». Для других документов укажите имя ответственного лица.
Спецификационный документ (Specification document): Ссылка на документ (ы), который задает векторный компонент, предпочтительно включающий URL, который может использоваться для извлечения копии документа (ов). Указание соответствующих разделов также может быть включено, но не обязательно.
7.1.2. Начальное содержимое реестра
Реестр «Вектор доверенных компонентов» содержит определения векторных компонентов и связанных с ними разграничителей.
Символ демаркации: P
o Описание: идентификация личности
o Смена контроллера: IESG
o Спецификационный документ (ы): [RFC8485]
o Символ демаркатора: C
o Описание: основное использование учетных данных
o Смена контроллера: IESG
o Спецификационный документ (ы): [RFC8485]
Символ демаркации: M
o Описание: первичное управление учетными данными
o Смена контроллера: IESG
o Спецификационный документ (ы): [RFC8485]
Символ демаркации: A
o Описание: утверждение утверждения
o Смена контроллера: IESG
o Спецификационный документ (ы): [RFC8485]
7.2. Добавление в реестр параметров OAuth
Эта спецификация добавляет следующее значение в реестр «Параметры OAuth», установленный [RFC6749].
o Имя: vtr
o Описание: Вектор запроса доверия
o Местоположение использования параметра: запрос авторизации, запрос токена
o Смена контроллера: IESG
o Ссылка: [RFC8485]
7.3. Дополнения к Реестру претензий JWT
Эта спецификация добавляет следующие значения в реестр «JSON Web Token Claims», созданный [RFC7519].
o Название претензии: Вот
o Описание претензии: вектор значения траста
o Смена контроллера: IESG
o Ссылка: [RFC8485]
o Название претензии: vtm
o Описание претензии: URL-адрес трастовой точки вектора доверия
o Смена контроллера: IESG
o Ссылка: [RFC8485]
7.4. Дополнения к OAuth Token Introspection Response
Эта спецификация добавляет следующие значения в реестр «Ответ-запрос самоанализа OAuth», созданный [RFC7662].
o Имя: Вот
o Описание: вектор значения доверия
o Смена контроллера: IESG
o Ссылка: [RFC8485]
o Имя: vtm
o Описание: URL-адрес вектора доверия
o Смена контроллера: IESG
o Ссылка: [RFC8485]
8. Вопросы безопасности
Вектор значения доверия должен быть криптографически защищен при передаче между сторонами, например, с использованием TLS, как описано в [BCP195]. Вектор значения доверия должен быть связан с знаком доверия с помощью RP, обрабатывающей вектор. Подписанный токен OpenID Connect ID или аналогично подписанное утверждение из другого протокола будет соответствовать этому требованию, если в качестве утверждений будут указаны как векторное значение, так и URL-адрес доверенного знака.
Значение вектора всегда связано с меткой доверия и должно интерпретироваться RP в контексте структуры доверия, определенной этой меткой доверия. Различные структуры доверия могут применять разные интерпретации к одному и тому же значению компонента, так же как и в случае с LoA. Следовательно, RP, интерпретирующий значение компонента в неправильном контексте, может по ошибке принять или отклонить запрос. Чтобы избежать этой ошибки, RP должны отклонять векторы, определенные в структурах доверия, которые они не понимают, как правильно интерпретировать.
Платформа VoT обеспечивает механизм для описания и передачи информации о доверии. Он не определяет каких-либо политик для IdP, определяющих, какие значения векторных компонентов применяются к данной транзакции, а также не определяет никаких политик для применения значений вектора к процессу принятия решений по безопасности RP. Эти политики и связанные с ними практики должны быть согласованы IdP и RP, и они должны быть подробно изложены в соответствующем удобочитаемом документе структуры доверия, доступном по URL-адресу доверенного знака.
9. Вопросы конфиденциальности
По своему дизайну вектор значений доверия содержит информацию об аутентификации пользователя и связях, которые могут быть с ней сделаны. Поэтому все аспекты вектора доверия содержат потенциально конфиденциальную информацию и должны быть защищены как таковые. Даже при отсутствии определенных атрибутов о пользователе знание о том, что пользователь получил высокую степень проверки или выпустил сильный токен, может предоставить больше информации о пользователе, чем предполагалось. Рекомендуется, чтобы IdP отправляли, а RP запрашивали только информацию, необходимую для их случая использования, чтобы предотвратить случайное раскрытие информации.
10. Ссылки
10.1. Нормативные ссылки
[OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, «OpenID Connect Core 1.0», November 2014, <http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC6749] Hardt, D., Ed., «The OAuth 2.0 Authorization Framework», RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, «JSON Web Token (JWT)», RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC7662] Richer, J., Ed., «OAuth 2.0 Token Introspection», RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/info/rfc7662>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., «The JavaScript Object Notation (JSON) Data Interchange Format», STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
10.2. Информационные ссылки
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, «Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)», BCP 195, RFC 7525, May 2015, <https://www.rfc-editor.org/info/bcp195>.
[NISTIR-8112] National Institute of Standards and Technology, «A Proposed Schema for Evaluating Federated Attributes», NIST Internal Report 8112, DOI 10.6028/NIST.IR.8112, January 2018, <https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8112.pdf>.
[SP-800-63-2] National Institute of Standards and Technology, «Electronic Authentication Guideline», NIST Special Publication SP 800-63-2, DOI 10.6028/NIST.SP.800-63-2, August 2013, <https://dx.doi.org/10.6028/NIST.SP.800-63-2>.
[SP-800-63-3] National Institute of Standards and Technology, «Digital Identity Guideline», NIST Special Publication SP 800-63-3, DOI 10.6028/NIST.SP.800-63-3, June 2017, <https://doi.org/10.6028/NIST.SP.800-63-3>.
Приложение A. Векторы значений компонента доверия по умолчанию
Следующие определения компонентов общего назначения МОГУТ использоваться, когда более конкретный набор недоступен. Этот документ определяет структуру доверия для этих значений компонента. URL-адрес метки доверия этой структуры доверия: <https://www.rfc-editor.org/info/rfc8485>. Все нормативные требования, следующие в этом разделе, применяются только к этой структуре доверия.
Другие структуры доверия, которые расширяют и реализуют эту спецификацию, ДОЛЖНЫ определять свои собственные значения компонентов, как описано в Разделе 6. По возможности, расширения МОГУТ повторно использовать конкретные значения и определения, перечисленные здесь, но эти конкретные значения ДОЛЖНЫ быть подтверждены.
A.1. Идентификация личности
Компонент проверки личности в этом определении вектора представляет уровень контроля, применяемый к субъекту идентичности в процессе проверки. Более высокие уровни в значительной степени подчиняются более низким уровням, так что «P2» удовлетворяет требованиям для «P1» и т. Д. Несколько отдельных значений из этой категории НЕ ДОЛЖНЫ использоваться в одной транзакции.
P0: проверка не выполняется, и гарантируется, что данные не будут постоянными между сеансами
P1: Атрибуты самоутверждены, но согласованы во времени, потенциально псевдоним
P2: личность была подтверждена либо лично, либо дистанционно с использованием надежных механизмов (таких как социальная проверка)
P3: Существует обязательная связь между поставщиком удостоверений и идентифицированной стороной (например, подписанные / нотариально заверенные документы и записи о трудоустройстве)
А.2. Основное использование учетных данных
Основной компонент использования учетных данных в этом определении вектора представляет различные категории основных учетных данных, которые МОГУТ использоваться вместе в одной транзакции. Несколько отдельных значений из этой категории МОГУТ использоваться в одной транзакции.
C0: учетные данные не используются / анонимная публичная служба
Ca: Простые сеансовые куки-файлы HTTP (больше ничего)
Cb: Известное устройство, например, указанное через положение устройства или системы управления устройством.
Cc: общий секрет, например комбинация имени пользователя и пароля
Cd: криптографическое подтверждение владения ключом с использованием общего ключа
Ce: Криптографическое подтверждение владения ключом с использованием асимметричного ключа
Cf: запечатанный аппаратный токен / ключи, хранящиеся в модуле доверенной платформы
Cg: локально проверенный биометрический
А.3. Первичное управление учетными данными
Основной компонент управления учетными данными в этом определении вектора представляет отдельные категории управления, которые МОГУТ рассматриваться отдельно или вместе в одной транзакции. Многие развертывания инфраструктуры доверия МОГУТ использовать одно значение для этого компонента в качестве базового уровня для всех транзакций и, следовательно, пропустить его. Несколько отдельных значений из этой категории МОГУТ использоваться в одной транзакции.
Ма: Самоутвержденные первичные учетные данные (пользователь выбирает свои собственные учетные данные и должен повернуть или отозвать их вручную) / нет дополнительной проверки для выдачи или ротации первичных учетных данных
Mb: удаленная выдача и ротация / использование учетных данных для восстановления (например, проверка электронной почты) / удаление по запросу пользователя
Mc: Требуется полная проверка для каждого выпуска и ротации / отзыва по подозрительной деятельности
А.4. Презентация утверждения
Компонент представления утверждений этого векторного определения представляет различные категории утверждений, которые РЕКОМЕНДУЕТСЯ использовать для субсимметричного использования, но МОГУТ использоваться вместе. Несколько отдельных значений из этой категории МОГУТ использоваться в одной транзакции.
Aa: Нет защиты / неподписанного идентификатора канала-носителя (например, файл cookie HTTP-сессии в веб-браузере)
Ab: подписанное и проверяемое утверждение, переданное через пользовательский агент (веб-браузер)
Ac: подписанное и проверяемое утверждение, переданное через обратный канал. Ad: подтверждение, зашифрованное ключом RP
Благодарности
Авторы хотели бы поблагодарить членов списка рассылки «Векторы доверия» в IETF за обсуждение и отзывы о концепции и документе, а также членов группы ISOC Trust и Identity за их поддержку. В частности, авторы хотели бы поблагодарить Пола Грасси, Джима Фентона, Сару Сквайр, Бенджамина Кадука, Джона Брэдли и Карен О’Донохью.
Адреса авторов
Justin Richer (editor)
Bespoke Engineering
Email: ietf@justin.richer.org
Leif Johansson
Swedish University Network
Thulegatan 11
Stockholm
Sweden
Email: leifj@sunet.se
URI: http://www.sunet.se
