Internet Engineering Task Force (IETF) J. Richer, Ed.
Request for Comments: 8485 Bespoke Engineering
Category: Standards Track L. Johansson
ISSN: 2070-1721 Swedish University Network
October 2018
Internet Engineering Task Force (IETF) J. Richer, Ed.
Request for Comments: 8485 Bespoke Engineering
Category: Standards Track L. Johansson
ISSN: 2070-1721 Swedish University Network
October 2018
Vectors of Trust
信任向量
Abstract
摘要
This document defines a mechanism for describing and signaling several aspects of a digital identity transaction and its participants. These aspects are used to determine the amount of trust to be placed in that transaction.
本文档定义了一种机制，用于描述数字身份交易及其参与者的几个方面并向其发送信号。这些方面用于确定要在该交易中放置的信任量。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8485.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8485.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Identity Model . . . . . . . . . . . . . . . . . . . . . 5
1.4. Component Architecture . . . . . . . . . . . . . . . . . 6
2. Component Dimension Definitions . . . . . . . . . . . . . . . 6
2.1. Identity Proofing (P) . . . . . . . . . . . . . . . . . . 7
2.2. Primary Credential Usage (C) . . . . . . . . . . . . . . 8
2.3. Primary Credential Management (M) . . . . . . . . . . . . 8
2.4. Assertion Presentation (A) . . . . . . . . . . . . . . . 8
3. Communicating Vector Values to RPs . . . . . . . . . . . . . 9
3.1. On-the-Wire Representation . . . . . . . . . . . . . . . 10
3.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 11
4. Requesting Vector Values . . . . . . . . . . . . . . . . . . 11
4.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 12
5. Trustmarks . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Defining New Vector Values . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Vector of Trust Components Registry . . . . . . . . . . . 14
7.1.1. Registration Template . . . . . . . . . . . . . . . . 14
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 15
7.2. Addition to the OAuth Parameters Registry . . . . . . . . 15
7.3. Additions to JWT Claims Registry . . . . . . . . . . . . 16
7.4. Additions to OAuth Token Introspection Response . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Vectors of Trust Default Component Value Definitions 19
A.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 19
A.2. Primary Credential Usage . . . . . . . . . . . . . . . . 20
A.3. Primary Credential Management . . . . . . . . . . . . . . 20
A.4. Assertion Presentation . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Identity Model . . . . . . . . . . . . . . . . . . . . . 5
1.4. Component Architecture . . . . . . . . . . . . . . . . . 6
2. Component Dimension Definitions . . . . . . . . . . . . . . . 6
2.1. Identity Proofing (P) . . . . . . . . . . . . . . . . . . 7
2.2. Primary Credential Usage (C) . . . . . . . . . . . . . . 8
2.3. Primary Credential Management (M) . . . . . . . . . . . . 8
2.4. Assertion Presentation (A) . . . . . . . . . . . . . . . 8
3. Communicating Vector Values to RPs . . . . . . . . . . . . . 9
3.1. On-the-Wire Representation . . . . . . . . . . . . . . . 10
3.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 11
4. Requesting Vector Values . . . . . . . . . . . . . . . . . . 11
4.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 12
5. Trustmarks . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Defining New Vector Values . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Vector of Trust Components Registry . . . . . . . . . . . 14
7.1.1. Registration Template . . . . . . . . . . . . . . . . 14
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 15
7.2. Addition to the OAuth Parameters Registry . . . . . . . . 15
7.3. Additions to JWT Claims Registry . . . . . . . . . . . . 16
7.4. Additions to OAuth Token Introspection Response . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Vectors of Trust Default Component Value Definitions 19
A.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 19
A.2. Primary Credential Usage . . . . . . . . . . . . . . . . 20
A.3. Primary Credential Management . . . . . . . . . . . . . . 20
A.4. Assertion Presentation . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Methods for measuring trust in digital identity transactions have historically fallen into two main categories: either all measurements are combined into a single scalar value or trust decisions are calculated locally based on a detailed set of attribute metadata. This document defines a method of conveying trust information that is more expressive than a single value but less complex than comprehensive attribute metadata.
数字身份交易中的信任度量方法历史上分为两大类：要么将所有度量合并为单个标量值，要么根据一组详细的属性元数据在本地计算信任决策。本文档定义了一种传递信任信息的方法，该方法比单个值更具表现力，但比综合属性元数据更不复杂。
Prior to the third edition [SP-800-63-3] published in 2017, NIST Special Publication 800-63 [SP-800-63-2] used a single scalar measurement of trust called a Level of Assurance (LoA). An LoA can be used to compare different transactions within a system at a coarse level. For instance, an LoA4 transaction is generally considered more trusted (across all measured categories) than an LoA2 transaction. The LoA for a given transaction is computed by the Identity Provider (IdP) and is consumed by a Relying Party (RP). Since the trust measurement is a simple numeric value, it's trivial for RPs to process and compare. However, since each LoA encompasses many different aspects of a transaction, it can't express many real-world situations. For instance, an anonymous user account might have a very strong credential, such as would be common of a whistle-blower or political dissident. Despite the strong credential, the lack of identity proofing would make any transactions conducted by the account to fall into a low LoA. Furthermore, different use cases and domains require subtly different definitions for their LoA categories, and one group's LoA2 is not equivalent or even comparable to another group's LoA2.
在2017年发布第三版[SP-800-63-3]之前，NIST特别出版物800-63[SP-800-63-2]使用了一种称为保证水平（LoA）的单一数量信任度量。LoA可用于粗略比较系统内的不同交易。例如，通常认为LoA4事务比LoA2事务更可信（在所有测量的类别中）。给定交易的LoA由身份提供者（IdP）计算，并由依赖方（RP）使用。由于信任度量值是一个简单的数值，因此RPs处理和比较非常简单。然而，由于每个LoA包含交易的许多不同方面，因此它无法表达许多真实情况。例如，匿名用户帐户可能具有非常强的凭据，例如告密者或持不同政见者的常见凭据。尽管有很强的凭证，但缺乏身份证明将使该账户进行的任何交易都属于低LoA。此外，不同的用例和领域需要对其LoA类别进行细微不同的定义，并且一个组的LoA2与另一个组的LoA2不相等，甚至不可比较。
Attribute-Based Access Control (ABAC) systems used by RPs may need to know details about a user's attributes, such as how recently the attribute data was verified and by whom. Attribute metadata systems are capable of expressing extremely fine-grained detail about the transaction. However, this approach requires the IdP to collect, store, and transmit all of this attribute data for the RP's consumption. The RP must process this data, which may be prohibitive for trivial security decisions.
RPs使用的基于属性的访问控制（ABAC）系统可能需要了解有关用户属性的详细信息，例如属性数据最近被验证的时间以及验证人。属性元数据系统能够表达关于事务的极细粒度细节。然而，这种方法要求IdP收集、存储和传输所有这些属性数据，以供RP使用。RP必须处理这些数据，这对于琐碎的安全决策可能是禁止的。
The Vectors of Trust (VoT) approach proposed in this document seeks a balance between these two alternatives by allowing expression of multiple aspects of an identity transaction (including but not limited to identity proofing, credential strength, credential management, and assertion strength), without requiring full attribute metadata descriptions. This method of measurement gives more actionable data and expressiveness than an LoA, but it is still relatively easy for the RP to process. It is anticipated that VoT can be used alongside more detailed attribute metadata systems, such
本文件中提出的信任向量（VoT）方法通过允许表达身份事务的多个方面（包括但不限于身份验证、凭证强度、凭证管理和断言强度），寻求这两个备选方案之间的平衡，不需要完整的属性元数据描述。这种测量方法比LoA提供了更多可操作的数据和表达能力，但RP处理起来仍然相对容易。预计VoT可以与更详细的属性元数据系统一起使用，例如
as the one proposed by NISITIR 8112 [NISTIR-8112]. The RP can use the vector value for most basic decisions but be able to query the IdP for additional attribute metadata where needed. Furthermore, for RPs that do not have a need for the vector's more fine-grained detail, it is anticipated that some trust frameworks will provide a simple mapping between certain sets of vector values to LoAs. In such systems, an RP is given a choice of how much detail to request from the IdP in order to process a given transaction.
正如NISTIR 8112[NISTIR-8112]提出的建议。RP可以将向量值用于最基本的决策，但可以在需要时查询IdP以获取额外的属性元数据。此外，对于不需要向量更细粒度细节的RPs，预计一些信任框架将提供特定向量值集到LOA之间的简单映射。在这样的系统中，RP可以选择从IdP请求多少细节来处理给定的事务。
This document defines a data model for these vectors and an on-the-wire format for conveying them between parties. The values of the vectors defined by the data model are anchored in a trust definition. This document also provides guidance for defining values for use in conveying this information, including four component categories and guidance on defining values within those categories. Additionally, this document defines a general-purpose set of component values in an appendix (Appendix A) for use cases that do not need something more specific.
本文档定义了这些向量的数据模型以及用于在各方之间传输这些向量的在线格式。数据模型定义的向量值锚定在信任定义中。本文件还提供了用于传达此信息的定义值的指南，包括四个组件类别以及在这些类别中定义值的指南。此外，本文档在附录（附录a）中为不需要更具体内容的用例定义了一组通用组件值。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Identity Federation: A protocol in which an Identity Provider (IdP) asserts a user's identity information to an RP. through the use of a cryptographic assertion or other verifiable mechanism, or a system implementing such a protocol. It is also referred to simply as "federation".
身份联合：一种协议，其中身份提供者（IdP）通过使用加密断言或其他可验证机制或实现此类协议的系统，向RP断言用户的身份信息。它也被简称为“联邦”。
Identity Provider (IdP): A system that manages identity information and is able to assert this information across the network through an identity API.
身份提供者（IdP）：管理身份信息的系统，能够通过身份API在网络上断言此信息。
Identity Subject: The individual (user) engaging in the identity transaction, that is, being identified by the identity provider to the RP.
身份主体：参与身份交易的个人（用户），即身份提供者向RP提供的身份。
Identity Proofing: The process of verifying and validating that a set of identity attributes belongs to a real-world identity subject.
身份验证：验证和确认一组身份属性是否属于真实身份主体的过程。
Primary Credential: The means used by the identity subject to authenticate to the identity provider.
主要凭证：身份主体向身份提供者进行身份验证所使用的手段。
Federated Credential: The assertion presented by the IdP to the RP across the network to authenticate the user.
联合凭证：IdP通过网络向RP提供的断言，用于验证用户。
Relying Party (RP): A system that consumes identity information from an IdP for the purposes of authenticating the user.
依赖方（RP）：为验证用户身份而使用IdP身份信息的系统。
Trust Framework: A document containing business rules and legal clauses that defines how different parties in an identity transaction may act.
信任框架：一份包含业务规则和法律条款的文件，定义身份交易中不同各方的行为方式。
Trustmark: A URL referencing a specific trust framework and its definition of vector components and vector component values.
信任标记：引用特定信任框架及其向量组件和向量组件值定义的URL。
Trustmark Provider: Defines the trust framework referenced by its trustmark and can verify that a given system (such as an identity provider) is both capable of asserting and allowed to assert the vector component values it is claiming.
信任标记提供程序：定义由其信任标记引用的信任框架，并可验证给定系统（如身份提供程序）是否能够断言并允许断言其声明的向量组件值。
Vector: A multi-part data structure, which is used here for conveying information about an authentication transaction.
Vector：一种由多个部分组成的数据结构，在这里用于传递有关身份验证事务的信息。
Vector Component: One of several constituent parts that make up a vector, indicating a category of information.
向量分量：构成向量的几个组成部分之一，表示一类信息。
Vector Component Value: One of the values applied to a vector component within a vector.
向量分量值：应用于向量中向量分量的值之一。
This document assumes the following model for identity based on identity federation technologies:
本文档采用以下基于身份联合技术的身份模型：
The identity subject (also known as the user) is associated with an identity provider that acts as a trusted third party on behalf of the user, with regard to an RP by making identity assertions about the user to the RP.
身份主体（也称为用户）与身份提供者相关联，该身份提供者通过向RP作出关于用户的身份断言，代表用户充当关于RP的可信第三方。
The real-world individual represented by the identity subject is in possession of a primary credential bound to the identity subject by the identity provider (or an agent thereof) in such a way that the binding between the credential and the real-world user is a representation of the identity proofing process performed by the identity provider (or an agent thereof) to verify the identity of the
由身份主体表示的真实世界个人拥有由身份提供者（或其代理）绑定到身份主体的主凭证，其方式使得凭证和真实世界用户之间的绑定是由身份提供者执行的身份验证过程的表示（或其代理人）核实
real-world individual. This information is carried across the network as part of an identity assertion presented to the RP during the authentication transaction.
现实世界中的个人。该信息作为身份验证事务期间提交给RP的身份断言的一部分在网络上传输。
The term "Vectors of Trust" is inspired by the mathematical construct of a vector, which is defined as an item composed of multiple independent values.
术语“信任向量”的灵感来源于向量的数学构造，该向量定义为由多个独立值组成的项目。
An important goal for this work is to balance the need for simplicity (particularly on the part of the RP) with the need for expressiveness. As such, this vector construct is designed to be composable and extensible.
这项工作的一个重要目标是平衡对简单性的需求（特别是在RP方面）和对表达性的需求。因此，该向量构造被设计为可组合和可扩展的。
The vector is constructed of orthogonal components, such that no aspect of a component overlaps an aspect of another component, as much as is possible.
向量由正交分量构成，使得一个分量的任何方面尽可能不与另一个分量的任何方面重叠。
This specification defines four orthogonal components: identity proofing, primary credential usage, primary credential management, and assertion presentation.
本规范定义了四个正交组件：身份验证、主凭据使用、主凭据管理和断言表示。
This specification also defines values for each of these components to be used in the absence of a more specific trust framework in Appendix A. It is expected that trust frameworks will provide context, semantics, and mapping to legal statutes and business rules for each value in each component.
本规范还定义了在附录a中没有更具体的信任框架的情况下使用的每个组件的值。预计信任框架将为每个组件中的每个值提供上下文、语义以及到法律法规和业务规则的映射。
Consequently, a particular vector value can only be compared with vectors defined in the context of a specific trust framework. The RP MUST understand and take into account the trust framework context in which a vector is being expressed in order to process a vector correctly.
因此，特定向量值只能与特定信任框架上下文中定义的向量进行比较。RP必须理解并考虑表示向量的信任框架上下文，以便正确处理向量。
Each component is identified by a demarcator consisting of a single uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD reflect the category with which it is associated in a natural manner. Demarcators for components MUST be registered as described in Section 7. It is anticipated that trust framework definitions will use this registry to define specialized components, but it is RECOMMENDED that trust frameworks reuse existing components categories wherever possible. The same demarcator MUST NOT be used for two different dimensions, and different trust frameworks SHOULD use the same demarcator for similar information. It is further anticipated that there will be relatively few component dimensions
每个组件由标界器标识，标界器由单个大写ASCII字母组成，范围为“[a-Z]”。标定器应以自然方式反映与其相关的类别。部件的标定器必须按照第7节所述进行注册。预计信任框架定义将使用此注册表定义专用组件，但建议信任框架尽可能重用现有组件类别。同一标界器不得用于两个不同的维度，不同的信任框架应使用相同的标界器用于类似的信息。进一步预计，部件尺寸相对较少
over time, and this specification defines four general-purpose categories in this section. Note that since the processing for all vector values is contextual to a trust framework, the exact semantics of interpreting a component will vary based on the trust framework in use.
随着时间的推移，本规范在本节中定义了四个通用类别。请注意，由于所有向量值的处理都与信任框架相关，因此解释组件的确切语义将根据所使用的信任框架而有所不同。
The value for a given component within a vector of trust is defined by its demarcator character followed by a single digit or lowercase ASCII letter in the range "[0-9a-z]". Categories that have a natural ordering SHOULD prefer digits, with larger digits indicating stronger assertions than smaller digits. Categories that do not have a natural ordering, or that can have an ambiguous ordering, SHOULD prefer letters. Note that while letters could also imply order, they can also more naturally be used mnemonically. Trust frameworks MAY use any possible values within a category without the need for them to be contiguous.
信任向量中给定组件的值由其标界符字符后跟范围为“[0-9a-z]”的单个数字或小写ASCII字母定义。具有自然顺序的类别应该更喜欢数字，与较小的数字相比，较大的数字表示更强的断言。没有自然排序或排序不明确的类别应首选字母。注意，虽然字母也可以暗示顺序，但它们也可以更自然地用于记忆。信任框架可以在一个类别中使用任何可能的值，而不需要它们是连续的。
Categories MAY use both letters and digits simultaneously. For example, a category could define "0" as meaning "no statement is made" while using letters such as "a", "b", and "c" for normal values to indicate specific options. Another system could have an ordered base set of digits with additional details provided by letters.
类别可以同时使用字母和数字。例如，一个类别可以将“0”定义为“未做任何声明”，同时使用“a”、“b”和“c”等字母表示正常值以指示特定选项。另一个系统可以有一个有序的数字基组，并通过字母提供额外的细节。
Each component MAY be repeated with multiple different values within a single vector, representing the logical AND of the values (see Section 3.1 for details). The same component and value combination MUST NOT be repeated within a single vector. For example, a vector could contain both "P1" and "Pa" but not two instances of "P1". A trust framework MAY define additional restrictions on combinations of values.
每个组件可以在一个向量中用多个不同的值重复，表示值的逻辑和（详见第3.1节）。同一分量和值组合不得在单个向量内重复。例如，向量可以同时包含“P1”和“Pa”，但不能包含“P1”的两个实例。信任框架可以定义对值组合的附加限制。
Regardless of the type of value, the RP MUST NOT assume that the values assigned to each component of a vector have inherent ordinal or subsumptive properties when compared to the same or other components in the vector space without specific knowledge of the trust framework in use. In other words, "1" is always different from "2", but it is dangerous to assume that "2" is always better than "1" or that "2" satisfies all the requirements of "1".
无论值的类型如何，RP不得假设分配给向量的每个分量的值与向量空间中的相同或其他分量相比具有固有的顺序或包容特性，而无需特定的信任框架知识。换句话说，“1”始终不同于“2”，但假设“2”始终优于“1”或“2”满足“1”的所有要求是危险的。
The identity proofing dimension defines, overall, how strongly the set of identity attributes have been verified and vetted. In other words, this dimension describes how likely it is that a given digital identity transaction corresponds to a particular (real-world) identity subject. For example, did the user have to provide documentation to a trusted party to prove their legal name and address, or were they able to self-assert such values?
身份验证维度总体上定义了身份属性集的验证和审查力度。换句话说，这个维度描述了给定的数字身份交易对应于特定（真实世界）身份主体的可能性。例如，用户是否必须向受信任方提供文档以证明其合法名称和地址，或者他们是否能够自行声明这些值？
This dimension uses the "P" demarcator, such as "P0", "P1", etc. Most definitions of identity proofing will have a natural ordering, as more or less stringent proofing can be applied to an individual being granted an account. In such cases, it is RECOMMENDED that a digit be used for this component and that only a single value be allowed to be communicated in a transaction.
此维度使用“P”标界符，如“P0”、“P1”等。身份验证的大多数定义都具有自然顺序，因为可以对被授予帐户的个人应用或多或少严格的验证。在这种情况下，建议此组件使用一个数字，并且在事务中只允许传递单个值。
The primary credential usage dimension defines how strongly the primary credential can be verified by the IdP. In other words, how easily that credential could be spoofed or stolen. For example, did the user log in with a password, a biometric, a cryptographic hardware device, or some combination of the above?
主凭据使用维度定义IdP可以验证主凭据的强度。换句话说，凭证是多么容易被欺骗或窃取。例如，用户是否使用密码、生物特征、加密硬件设备或上述组合登录？
This dimension uses the "C" demarcator, such as "Ca", "Cb", etc. Most definitions of credential usage will not have an overall natural ordering, as there may be several equivalent classes described within a trust framework. In such cases, it is RECOMMENDED that a letter be used for this component and that multiple distinct credential usage factors be allowed to be communicated simultaneously, such as when multi-factor authentication is used.
此维度使用“C”标界符，如“Ca”、“Cb”等。大多数凭证使用的定义不会有一个整体的自然顺序，因为在信任框架中可能会描述几个等效类。在这种情况下，建议为该组件使用一封信，并允许同时传递多个不同的凭证使用因素，例如在使用多因素身份验证时。
The primary credential management dimension conveys information about the expected lifecycle of the primary credential in use, including its binding, rotation, and revocation. In other words, the use and strength of policies, practices, and security controls used in managing the credential at the IdP and its binding to the intended individual. For example, can the user bring their own cryptographic device or is one provided by the IdP?
主凭据管理维度传递有关正在使用的主凭据的预期生命周期的信息，包括其绑定、轮换和吊销。换句话说，在IdP管理凭证及其与预期个人的绑定时使用的策略、实践和安全控制的使用和强度。例如，用户可以携带自己的加密设备，还是由IdP提供？
This dimension uses the "M" demarcator, such as "Ma", "Mb", etc. Most definitions of credential management will not have an overall natural ordering, though there can be preference and comparison between values in some circumstances. In such cases, it is RECOMMENDED that a letter be used for this component and that multiple distinct values be allowed to be communicated simultaneously.
此维度使用“M”标界符，如“Ma”、“Mb”等。凭证管理的大多数定义不会具有总体自然顺序，尽管在某些情况下，值之间可能存在偏好和比较。在这种情况下，建议该组件使用一个字母，并允许同时传递多个不同的值。
The assertion presentation dimension defines how well the given digital identity can be communicated across the network without information leaking to unintended parties and without spoofing. In other words, this dimension describes how likely it is that a given digital identity was asserted by a given identity provider for the
断言表示维度定义了给定数字身份在网络上的通信程度，而不会将信息泄漏给非预期方，也不会进行欺骗。换句话说，这个维度描述了给定的数字身份被给定的身份提供者为用户断言的可能性
identity subject of a given transaction. While this information is largely already known by the RP as a side effect of processing an identity assertion in a federation protocol, this dimension is still very useful when the RP requests a login (see Section 4) and when describing the capabilities of an IdP. This value also allows the RP to detect when an assertion is presented in a manner it was not intended for, as may be the case with an attack.
给定交易的身份主体。虽然RP基本上已经知道该信息是在联合协议中处理身份断言的副作用，但当RP请求登录（参见第4节）和描述IdP的能力时，该维度仍然非常有用。该值还允许RP检测何时以非预期的方式呈现断言，例如攻击。
This dimension uses the "A" demarcator, such as "Aa", "Ab", etc. Most definitions of assertion presentation will not have an overall natural ordering. In such cases, it is RECOMMENDED that a letter be used for this component and that multiple values be allowed to be communicated simultaneously.
这个维度使用“A”标界符，如“Aa”、“Ab”等。断言表示的大多数定义不会有一个整体的自然顺序。在这种情况下，建议该组件使用一个字母，并允许同时传递多个值。
A vector of trust is designed to be used in the context of an identity and authentication transaction, providing information about the context of a federated credential. The vector therefore needs to be able to be communicated in the context of the federated credential in a way that is strongly bound to the assertion representing the federated credential.
信任向量设计用于身份和身份验证事务的上下文中，提供有关联邦凭证上下文的信息。因此，向量需要能够在联邦凭证的上下文中以与表示联邦凭证的断言紧密绑定的方式进行通信。
This vector has several requirements for use.
该向量有几个使用要求。
o All applicable vector components and values need to be combined into a single vector.
o 所有适用的向量组件和值都需要合并到一个向量中。
o The vector can be communicated across the wire unbroken and untransformed.
o 该矢量可以在未中断和未转换的情况下通过导线进行通信。
o All vector components need to remain individually available, not "collapsed" into a single value.
o 所有向量组件都需要保持单独可用，而不是“折叠”为单个值。
o The vector needs to be protected in transit.
o 在运输过程中需要对病媒进行保护。
o The vector needs to be cryptographically bound to the assertion that it is describing.
o 向量需要以加密方式绑定到它所描述的断言。
o The vector needs to be interpreted in the context of a specific trust framework definition identified by a trustmark URL.
o 该向量需要在由信任标记URL标识的特定信任框架定义的上下文中进行解释。
These requirements lead us to defining a simple string-based representation of the vector that can be incorporated within a number of different locations and protocols without further encoding.
这些要求使我们能够定义一种简单的基于字符串的向量表示法，该表示法可以合并到许多不同的位置和协议中，而无需进一步编码。
The vector MUST be represented as a period-separated ('.') list of vector components. A vector component type can occur multiple times within a single vector, but a specific value of a vector component cannot occur more than once in a single vector. That is, while "Cc.Cd" is a valid vector, "Cc.Cc" is not. Multiple values for a component are considered a logical AND of the values.
向量必须表示为以句点分隔的（'.'）向量组件列表。向量分量类型可以在单个向量中出现多次，但向量分量的特定值不能在单个向量中出现多次。也就是说，虽然“Cc.Cd”是有效的向量，但“Cc.Cc”不是。组件的多个值被视为值的逻辑AND。
Vector component values MAY appear in any order within a vector, and the RP MUST consider different orderings of the same vector equivalent during processing. For example, "P1.Cc.Cd.Aa", "Aa.Cc.Cd.P1", "Cd.P1.Cc.Aa", and "Aa.P1.Cd.Cc" are all considered equivalent to each other.
向量分量值可以以矢量内的任意顺序出现，并且RP必须考虑在处理过程中相同向量等价的不同排序。例如，“P1.Cc.Cd.Aa”、“Aa.Cc.Cd.P1”、“Cd.P1.Cc.Aa”和“Aa.P1.Cd.Cc”都被认为是等价的。
Possible vector components MAY be omitted from a vector. No holding space is left for an omitted vector component. If a vector component is omitted, the vector is making no claim for that component. No default values are assumed for a missing component category.
可以从向量中省略可能的向量分量。没有为省略的向量分量留下保留空间。如果省略了一个向量分量，则该向量不对该分量提出索赔。对于缺少的零部件类别，不假定默认值。
Vector values MUST be communicated along with a trustmark URL (see Section 5) to give the components and component values context. The trustmark MUST be cryptographically bound to the vector value, such as the two values being carried together in a signed assertion. A vector value without context is unprocessable, and vectors defined in different contexts are not directly comparable as whole values. Different trust frameworks MAY reuse component definitions (including their values), but processing of such cross-context values is outside the scope of this specification.
向量值必须与信任标记URL（见第5节）一起通信，以提供组件和组件值上下文。信任标记必须以加密方式绑定到向量值，例如在有符号断言中两个值一起携带。没有上下文的向量值是不可处理的，在不同上下文中定义的向量不能作为整体值直接进行比较。不同的信任框架可能会重用组件定义（包括它们的值），但这种跨上下文值的处理超出了本规范的范围。
For example, the vector "P1.Cc.Ab" translates to "pseudonymous, proof of shared key, signed browser-passed verified assertion, and no claim made toward credential management" in the context of this specification's definitions (see Appendix A). A different vector "Cb.Mc.Cd.Ac" translates to "known device, full proofing required for credential issuance and rotation, cryptographic proof of possession of a shared key, signed back-channel verified assertion, and no claim made toward identity proofing" in the same context. Since no claim is made here for identity proofing, no specific value can be assumed by the RP. Note that this doesn't mean the user wasn't proofed at all: it's possible that the user was fully proofed to the highest capabilities within the trust framework, but here the IdP is not making any specific claim about proofing to the RP, perhaps to protect the user's privacy.
例如，在本规范定义的上下文中，向量“P1.Cc.Ab”转换为“假名、共享密钥证明、签名的浏览器通过验证的断言，并且没有对凭证管理提出声明”（参见附录A）。另一个向量“Cb.Mc.Cd.Ac”在同一上下文中翻译为“已知设备、凭证颁发和轮换所需的完整证明、共享密钥拥有的加密证明、签名后通道验证断言，以及对身份证明的无声明”。由于此处没有针对身份验证提出任何声明，RP无法假设任何特定值。请注意，这并不意味着用户根本没有经过验证：用户有可能在信任框架内被充分证明具有最高的能力，但在此，IdP没有针对RP的验证提出任何特定声明，也许是为了保护用户的隐私。
In OpenID Connect [OpenID], the IdP MUST send the vector as a string within the "vot" (vector of trust) claim in the ID token. The trustmark (see Section 5) that applies to this vector MUST be sent as a URL in the "vtm" (vector trust mark) claim to provide context to the vector.
在OpenID Connect[OpenID]中，IdP必须在ID令牌中的“vot”（信任向量）声明中以字符串形式发送向量。应用于此向量的信任标记（见第5节）必须作为“vtm”（向量信任标记）声明中的URL发送，以向向量提供上下文。
The "vot" and "vtm" claims are interpreted by the RP to apply to the entire identity transaction and not necessarily to any one attribute specifically.
RP将“vot”和“vtm”声明解释为适用于整个身份事务，而不一定适用于任何一个特定属性。
For example, assume that for the given trustmark, the body of an ID token claiming "pseudonymous, proof of shared key, signed back-channel verified token, and no claim made toward credential management" could look like this JSON object [RFC8259] payload of the ID token.
例如，假设对于给定的信任标记，声明“假名、共享密钥证明、已签名回信道验证令牌、未对凭据管理作出声明”的ID令牌的主体可能看起来像ID令牌的JSON对象[RFC8259]有效负载。
{
"iss": "https://idp.example.com/",
"sub": "jondoe1234",
"vot": "P1.Cc.Ac",
"vtm": "https://example.org/vot-trust-framework"
}
{
"iss": "https://idp.example.com/",
"sub": "jondoe1234",
"vot": "P1.Cc.Ac",
"vtm": "https://example.org/vot-trust-framework"
}
The body of the ID token is signed and optionally encrypted using JSON Object Signing and Encryption (JOSE), as per the OpenID Connect specification. By putting the "vot" and "vtm" values inside the ID token, the vector and its context are strongly bound to the federated credential represented by the ID token.
根据OpenID Connect规范，使用JSON对象签名和加密（JOSE）对ID令牌的主体进行签名和可选加密。通过将“vot”和“vtm”值放在ID令牌内，向量及其上下文被强绑定到由ID令牌表示的联邦凭证。
Vector values MAY be returned in a token introspection [RFC7662] response describing the ID token or access token issued during an OpenID Connect transaction using the same claims.
向量值可以在令牌内省[RFC7662]响应中返回，该响应描述在使用相同声明的OpenID Connect事务期间发出的ID令牌或访问令牌。
In some identity protocols, the RP can request that particular vector values be used for a given identity transaction. An RP can describe the particular vector component values it desires the IdP assert for a given identity transaction by using the same syntax as defined in Section 3.1. Processing and fulfillment of these requests are in the purview of the IdP, and details are outside the scope of this specification.
在某些身份协议中，RP可以请求为给定的身份事务使用特定的向量值。RP可以使用第3.1节中定义的相同语法描述其希望IdP断言用于给定身份事务的特定向量分量值。这些请求的处理和实现属于IdP的权限，详细信息不在本规范的范围内。
Future specifications MAY define alternative ways for an RP to request vector values from an IdP.
未来的规范可能会定义RP向IdP请求向量值的替代方法。
In OpenID Connect [OpenID], the client MAY request a partial set of acceptable VoT values with the "vtr" (vector of trust) claim request as part of the request object. The value of this field is a JSON array of strings [RFC8259], each string identifying an acceptable set of vector components. The component values within each vector are ANDed together while the separate vectors are ORed together. For example, a list of vectors in the form '["P1.Cb.Cc.Ab", "Ce.Ab"]' is stating that either the full set of "P1 AND Cb AND Cc AND Ab" simultaneously OR the full set of "Ce AND Ab" simultaneously are acceptable to this RP for this transaction.
在OpenID Connect[OpenID]中，客户机可以使用“vtr”（信任向量）声明请求作为请求对象的一部分来请求部分可接受的VoT值。此字段的值是字符串[RFC8259]的JSON数组，每个字符串标识一组可接受的向量组件。每个向量中的分量值一起进行AND运算，而单独的向量一起进行OR运算。例如，格式为“[”P1.Cb.Cc.Ab“，”Ce.Ab“]”的向量列表表明，对于该交易，RP可同时接受整套“P1和Cb以及Cc和Ab”或整套“Ce和Ab”。
Vector request values MAY omit components, indicating that any value is acceptable for that component category, including omission of that component in the response vector.
向量请求值可以省略组件，表示该组件类别可以接受任何值，包括在响应向量中省略该组件。
The mechanism by which the IdP processes the "vtr" and maps that to the authentication transaction are out of scope of this specification.
IdP处理“vtr”并将其映射到认证事务的机制不在本规范的范围内。
A trustmark is an HTTPS URL that references a specific set of vector values as defined by a trust framework. This URL MUST point to a human-readable document that describes what components and values are valid, how they are used together, and what practices the component values represent within the trust framework. The contents of the trustmark URL MUST be reachable by the operators or implementors of the RP. The URL MUST be stable over time for a given trust framework to allow RPs to process incoming vectors in a consistent fashion. New versions of a trust framework that require different processing rules MUST use a different trustmark URL.
信任标记是一个HTTPS URL，它引用信任框架定义的一组特定向量值。此URL必须指向一个人类可读的文档，该文档描述了哪些组件和值是有效的，它们是如何一起使用的，以及组件值在信任框架中代表了什么实践。RP的操作员或实现者必须能够访问trustmark URL的内容。对于给定的信任框架，URL必须随时间保持稳定，以允许RPs以一致的方式处理传入向量。需要不同处理规则的信任框架的新版本必须使用不同的信任标记URL。
For example, <https://www.rfc-editor.org/info/rfc8485> is used as the trustmark to reference the values defined in Appendix A.
比如说,<https://www.rfc-editor.org/info/rfc8485>用作参考附录A中定义的值的信任标记。
The process of a trustmark provider determining the ability of a particular IdP to correctly assert values from a given trust framework is outside the scope of this specification. Determining how an RP should apply the values of a given vector to the RP's processing is outside the scope of this specification.
信任标记提供程序确定特定IdP正确断言给定信任框架中的值的能力的过程不在本规范的范围内。确定RP应如何将给定向量的值应用于RP的处理不在本规范的范围内。
Vectors of Trust is meant to be a flexible and reusable framework for communicating authentication data between networked parties in an identity federation protocol. However, the exact nature of the information needed depends on the parties requiring the information and the relationship between them. While this document does define a usable default set of values in Appendix A, it is anticipated that many situations will require an extension of this specification for their own use.
信任向量是一种灵活的、可重用的框架，用于在身份联合协议中的联网各方之间通信身份验证数据。然而，所需信息的确切性质取决于需要信息的各方及其之间的关系。虽然本文件在附录a中定义了一组可用的默认值，但预计许多情况下需要扩展本规范以供其自身使用。
Component categories such as those defined in Section 2 are intended to be general-purpose and reusable in a variety of trust frameworks. Extension specifications SHOULD reuse existing category definitions where possible. Extensions MAY create additional categories where needed by using the registry defined in Section 7. The registry encourages reuse and discovery of existing categories across different trust frameworks. For example, the "P" category in another framework SHOULD be used for identity proofing and related information.
第2节中定义的组件类别是通用的，可在各种信任框架中重用。扩展规范应尽可能重用现有的类别定义。扩展可以通过使用第7节中定义的注册表在需要时创建其他类别。注册表鼓励跨不同信任框架重用和发现现有类别。例如，另一个框架中的“P”类应用于身份验证和相关信息。
The values of components such as those defined in Appendix A are intended to be contextual to the defining trust document. While this specification's component values are intended to be general-purpose and extensions MAY reuse the values and their definitions, trust frameworks MUST define all allowable values. As these values are always interpreted in the context of a trustmark, these values are not recorded in a central registry. Consequently, a P1" value from one framework and a "P1" value from another framework could have very different interpretations depending on their contextual trust framework documents, even though in both cases the "P" component is used for identity proofing in some fashion.
附录A中定义的组件值旨在与定义信托文件相关。虽然本规范的组件值是通用的，扩展可以重用这些值及其定义，但信任框架必须定义所有允许的值。由于这些值总是在信任标记的上下文中进行解释，因此这些值不会记录在中央注册表中。因此，一个框架中的“P1”值和另一个框架中的“P1”值可能有非常不同的解释，这取决于它们的上下文信任框架文档，即使在这两种情况下，“P”部分都以某种方式用于身份验证。
Trust frameworks that implement this specification SHOULD choose either a numerical ordering or a group category approach to component values as described in Section 2, though combinations of both types MAY be used. Trust frameworks MUST specify whether multiple values are allowed for each category, and while any component category is generally allowed to have multiple distinct values, a specific definition of a set of values in an extension MAY limit a given component category to a single value per transaction. It is RECOMMENDED that trust frameworks use a "0" value to indicate an empty or null condition for a given category (for example, no proofing being done or no authentication token being used).
实现本规范的信任框架应选择第2节中描述的组件值的数字排序或组类别方法，尽管可以使用这两种类型的组合。信任框架必须指定是否允许每个类别有多个值，虽然任何组件类别通常允许有多个不同的值，但扩展中一组值的特定定义可能会将给定组件类别限制为每个事务的单个值。建议信任框架使用“0”值来表示给定类别的空或空条件（例如，未进行校对或未使用身份验证令牌）。
All trust frameworks that extend and implement this specification MUST be referenced by a unique trustmark URL (see Section 5) to allow RPs to differentiate between different trust frameworks.
所有扩展和实现本规范的信任框架必须由唯一的trustmark URL引用（参见第5节），以允许RPs区分不同的信任框架。
This specification creates one registry and registers several values into existing registries.
此规范创建一个注册表，并将多个值注册到现有注册表中。
This specification establishes the "Vectors of Trust Components" registry.
本规范建立了“信任组件向量”注册表。
Component demarcators are registered by the Specification Required policy documented in [RFC8126].
组件标定器根据[RFC8126]中记录的规范要求政策进行注册。
Criteria that should be applied by the designated experts includes determining whether the proposed registration is distinct enough from existing entries to warrant registration, whether it is likely to be of general applicability, and whether the registration description is clear. Since all vector processing is contextual to a trust framework, component demarcators that do not meet these criteria can still be used in trust frameworks. The registry contains vector components that are believed to have general applicability that can be used as well.
指定专家应适用的标准包括确定拟议登记是否与现有登记有足够的区别，是否有必要进行登记，是否可能具有普遍适用性，以及登记说明是否明确。由于所有向量处理都与信任框架相关，因此不满足这些标准的组件标界符仍然可以在信任框架中使用。注册表包含向量组件，这些组件被认为具有通用性，也可以使用。
Registration requests sent to the vot@ietf.org mailing list for review should use an appropriate subject (e.g., "Request to register Vector of Trust Component name: example"). The designated expert(s) will provide review within a two-week period and either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the designated expert(s) and should direct all requests for registration to the vot@ietf.org mailing list. If the designated experts do not respond within the designated period, IANA should contact the IESG for guidance.
已将注册请求发送到vot@ietf.org供审查的邮件列表应使用适当的主题（例如，“请求注册信任组件名称向量：示例”）。指定专家将在两周内提供审查，批准或拒绝注册请求，并将此决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。IANA必须只接受指定专家的注册表更新，并应将所有注册请求提交给vot@ietf.org邮件列表。如果指定专家未在指定期限内做出回应，IANA应联系IESG寻求指导。
Demarcator Symbol: An uppercase ASCII letter in the range [A-Z] representing this component (e.g., "X").
标界符号：在[A-Z]范围内表示该组件的大写ASCII字母（例如，“X”）。
Description: Brief description of the component (e.g., "Example description").
说明：组件的简要说明（例如，“示例说明”）。
Change Controller: For IETF-stream RFCs, state "IESG". For other documents, give the name of the responsible party.
更改控制器：对于IETF流RFC，状态为“IESG”。对于其他文件，请提供责任方的名称。
Specification document(s): Reference to the document(s) that specifies the vector component, preferably including a URL that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
规范文档：对指定向量组件的文档的引用，最好包括可用于检索文档副本的URL。也可以包括相关章节的指示，但不需要。
The "Vector of Trust Components" registry contains the definitions of vector components and their associated demarcators.
“信任组件向量”注册表包含向量组件及其相关标界的定义。
o Demarcator Symbol: P o Description: Identity proofing o Change Controller: IESG o Specification document(s): [RFC8485]
o 标定器符号：PO说明：身份验证o变更控制器：IESG o规范文件：[RFC8485]
o Demarcator Symbol: C o Description: Primary credential usage o Change Controller: IESG o Specification document(s): [RFC8485]
o 标定器符号：CO说明：主要凭证使用o更改控制器：IESG o规范文件：[RFC8485]
o Demarcator Symbol: M o Description: Primary credential management o Change Controller: IESG o Specification document(s): [RFC8485]
o 标定器符号：MO说明：主要凭证管理o变更控制器：IESG o规范文件：[RFC8485]
o Demarcator Symbol: A o Description: Assertion presentation o Change Controller: IESG o Specification document(s): [RFC8485]
o 标界符号：A o描述：断言表示o变更控制器：IESG o规范文档：[RFC8485]
This specification adds the following value to the "OAuth Parameters" registry established by [RFC6749].
本规范向[RFC6749]建立的“OAuth参数”注册表添加以下值。
o Name: vtr o Description: Vector of Trust request o Parameter usage location: authorization request, token request o Change Controller: IESG o Reference: [RFC8485]
o 名称：vtr o说明：信任请求向量o参数使用位置：授权请求、令牌请求o更改控制器：IESG o参考：[RFC8485]
This specification adds the following values to the "JSON Web Token Claims" registry established by [RFC7519].
本规范将以下值添加到[RFC7519]建立的“JSON Web令牌声明”注册表中。
o Claim name: vot o Claim Description: Vector of Trust value o Change Controller: IESG o Reference: [RFC8485]
o 索赔名称：vot o索赔描述：变更控制器信任值向量：IESG o参考：[RFC8485]
o Claim name: vtm o Claim Description: Vector of Trust trustmark URL o Change Controller: IESG o Reference: [RFC8485]
o 索赔名称：vtm o索赔描述：信任向量信任标记URL o变更控制器：IESG o参考：[RFC8485]
This specification adds the following values to the "OAuth Token Introspection Response" registry established by [RFC7662].
本规范将以下值添加到由[RFC7662]建立的“OAuth令牌内省响应”注册表中。
o Name: vot o Description: Vector of Trust value o Change Controller: IESG o Reference: [RFC8485]
o 名称：vot o描述：更改控制器的信任值向量：IESG o参考：[RFC8485]
o Name: vtm o Description: Vector of Trust trustmark URL o Change Controller: IESG o Reference: [RFC8485]
o 名称：vtm o说明：信任向量信任标记URL o更改控制器：IESG o参考：[RFC8485]
The vector of trust value needs to be cryptographically protected in transit between parties, such as by using TLS as described in [BCP195]. The vector of trust value must be associated with a trustmark by the RP processing the vector. A signed OpenID Connect ID Token or a similarly signed assertion from another protocol would fulfill this requirement by carrying both the vector value and the trustmark URL as claims.
信任值向量需要在各方之间传输时进行加密保护，如使用[BCP195]中所述的TLS。信任值向量必须通过RP处理向量与信任标记相关联。签名的OpenID Connect ID令牌或来自另一个协议的类似签名断言将通过携带向量值和信任标记URL来满足这一要求。
The vector value is always associated with a trustmark and needs to be interpreted by the RP in the context of the trust framework defined by that trustmark. Different trust frameworks can apply different interpretations to the same component value, much as was the case with LoA. Therefore, an RP interpreting a component value in the wrong context could mistakenly accept or reject a request. In
向量值始终与信任标记关联，并且需要由RP在该信任标记定义的信任框架的上下文中进行解释。不同的信任框架可以对相同的组成部分价值应用不同的解释，就像LoA一样。因此，RP在错误的上下文中解释组件值可能会错误地接受或拒绝请求。在里面
order to avoid this mistake, RPs need to reject vectors that are defined in trust frameworks that they do not understand how to interpret properly.
为了避免这个错误，RPs需要拒绝在信任框架中定义的向量，因为他们不知道如何正确解释这些向量。
The VoT framework provides a mechanism for describing and conveying trust information. It does not define any policies for an IdP determining which vector component values apply to a given transaction, nor does it define any policies for applying the values of a vector to an RP's security decision process. These policies and associated practices are to be agreed upon by the IdP and RP, and they should be expressed in detail in an associated human-readable trust framework document available at the trustmark URL.
VoT框架提供了一种描述和传递信任信息的机制。它没有为IdP定义任何策略，以确定哪些向量分量值应用于给定事务，也没有为RP的安全决策过程定义任何策略，以应用向量值。这些政策和相关实践将由IdP和RP商定，并应在trustmark URL上提供的相关人类可读的信任框架文件中详细说明。
By design, vector of trust values contain information about the user's authentication and associations that can be made thereto. Therefore, all aspects of a vector of trust contain potentially privacy-sensitive information and must be guarded as such. Even in the absence of specific attributes about a user, knowledge that the user has been highly proofed or issued a strong token could provide more information about the user than was intended. It is recommended that IdPs send and RPs request only the information necessary for their use case in order to prevent inadvertent information disclosure.
通过设计，信任值向量包含关于用户身份验证的信息以及可以与之关联的信息。因此，信任向量的所有方面都包含潜在的隐私敏感信息，因此必须加以保护。即使在没有关于用户的特定属性的情况下，知道用户已经被高度证明或颁发了强令牌也可以提供比预期更多的关于用户的信息。建议IDP发送和RPs仅请求其用例所需的信息，以防止意外信息泄露。
[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>.
[OpenID]Sakimura，N.，Bradley，J.，Jones，M.，de Medeiros，B.，和C.Mortimore，“OpenID连接核心1.0”，2014年11月<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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<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>.
[RFC7519]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络令牌（JWT）”，RFC 7519，DOI 10.17487/RFC7519，2015年5月<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>.
[RFC7662]Richer，J.，Ed.“OAuth 2.0令牌内省”，RFC 7662，DOI 10.17487/RFC7662，2015年10月<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>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<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>.
[RFC8259]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，STD 90，RFC 8259，DOI 10.17487/RFC8259，2017年12月<https://www.rfc-editor.org/info/rfc8259>.
[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>.
[BCP195]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 75252015年5月<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>.
[NISTIR-8112]国家标准与技术研究所，“评估联邦属性的拟议方案”，NIST内部报告8112，DOI 10.6028/NIST.IR.8112，2018年1月<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-2]国家标准与技术研究所，“电子认证指南”，NIST特别出版物SP 800-63-2，DOI 10.6028/NIST.SP.800-63-2，2013年8月<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>.
[SP-800-63-3]国家标准与技术研究所，“数字身份指南”，NIST特别出版物SP 800-63-3，DOI 10.6028/NIST.SP.800-63-3，2017年6月<https://doi.org/10.6028/NIST.SP.800-63-3>.
The following general-purpose component definitions MAY be used when a more specific set is unavailable. This document defines a trust framework for these component values. The trustmark URL of this trust framework is <https://www.rfc-editor.org/info/rfc8485>. All normative requirements following in this section apply to this trust framework alone.
当更具体的组件集不可用时，可以使用以下通用组件定义。本文档定义了这些组件值的信任框架。此信任框架的信任标记URL为<https://www.rfc-editor.org/info/rfc8485>. 本节中的所有规范性要求仅适用于本信托框架。
Other trust frameworks that extend and implement this specification SHOULD define their own component values as described in Section 6. Where possible, extensions MAY reuse specific values and definitions as listed here, but those specific values MUST be relisted.
扩展和实现本规范的其他信任框架应定义自己的组件值，如第6节所述。在可能的情况下，扩展可以重用此处列出的特定值和定义，但必须重新列出这些特定值。
The identity proofing component of this vector definition represents the level of scrutiny applied to the identity subject during the proofing process. Higher levels are largely subsumptive of lower levels, such that "P2" fulfills requirements for "P1", etc. Multiple distinct values from this category MUST NOT be used in a single transaction.
此向量定义的身份验证组件表示在验证过程中应用于身份主体的审查级别。较高级别在很大程度上包含较低级别，因此“P2”满足“P1”等的要求。不得在单个事务中使用此类别的多个不同值。
P0: No proofing is done, and data is not guaranteed to be persistent across sessions
P0：没有进行校对，数据也不能保证跨会话持久
P1: Attributes are self-asserted but consistent over time, potentially pseudonymous
P1：属性是自断言的，但随着时间的推移是一致的，可能是假名
P2: Identity has been proofed either in person or remotely using trusted mechanisms (such as social proofing)
P2：身份已通过个人或远程使用可信机制（如社交验证）进行验证
P3: There is a binding relationship between the identity provider and the identified party (such as signed/notarized documents and employment records)
P3：身份提供者与被识别方之间存在约束关系（如签名/公证文件和雇佣记录）
The primary credential usage component of this vector definition represents distinct categories of primary credential that MAY be used together in a single transaction. Multiple distinct values from this category MAY be used in a single transaction.
此向量定义的主凭证使用组件表示可在单个事务中一起使用的不同类别的主凭证。单个事务中可以使用此类别中的多个不同值。
C0: No credential is used / anonymous public service
C0：未使用凭证/匿名公共服务
Ca: Simple session HTTP cookies (with nothing else)
Ca：简单会话HTTP cookies（不含其他内容）
Cb: Known device, such as those indicated through device posture or device management systems
Cb：已知设备，如通过设备姿态或设备管理系统指示的设备
Cc: Shared secret, such as a username and password combination
抄送：共享秘密，如用户名和密码的组合
Cd: Cryptographic proof of key possession using shared key
Cd：使用共享密钥的密钥拥有的加密证明
Ce: Cryptographic proof of key possession using asymmetric key
Ce：使用非对称密钥的密钥拥有的加密证明
Cf: Sealed hardware token / keys stored in a trusted platform module
Cf：存储在可信平台模块中的密封硬件令牌/密钥
Cg: Locally verified biometric
Cg：本地验证的生物特征
The primary credential management component of this vector definition represents distinct categories of management that MAY be considered separately or together in a single transaction. Many trust framework deployments MAY use a single value for this component as a baseline for all transactions and thereby omit it. Multiple distinct values from this category MAY be used in a single transaction.
此向量定义的主要凭证管理组件表示可以在单个事务中单独或一起考虑的不同管理类别。许多信任框架部署可能会使用此组件的单个值作为所有事务的基线，从而忽略它。单个事务中可以使用此类别中的多个不同值。
Ma: Self-asserted primary credentials (user chooses their own credentials and must rotate or revoke them manually) / no additional verification for primary credential issuance or rotation
Ma：自断言的主凭据（用户选择自己的凭据，并且必须手动旋转或撤销它们）/无需对主凭据的颁发或旋转进行额外验证
Mb: Remote issuance and rotation / use of backup recover credentials (such as email verification) / deletion on user request
Mb：远程发布和轮换/使用备份恢复凭据（如电子邮件验证）/根据用户请求删除
Mc: Full proofing required for each issuance and rotation / revocation on suspicious activity
Mc：可疑活动的每次发布和轮换/撤销都需要完整的证明
The assertion presentation component of this vector definition represents distinct categories of assertion that are RECOMMENDED to be used in a subsumptive manner but MAY be used together. Multiple distinct values from this category MAY be used in a single transaction.
此向量定义的断言表示组件表示不同类别的断言，建议以包容方式使用，但可以一起使用。单个事务中可以使用此类别中的多个不同值。
Aa: No protection / unsigned bearer identifier (such as an HTTP session cookie in a web browser)
Aa：无保护/未签名承载标识符（如web浏览器中的HTTP会话cookie）
Ab: Signed and verifiable assertion, passed through the user agent (web browser)
Ab：已签名且可验证的断言，通过用户代理（web浏览器）传递
Ac: Signed and verifiable assertion, passed through a back channel
Ac：经过签名和可验证的断言，通过后通道传递
Ad: Assertion encrypted to the RP's key
Ad：加密到RP密钥的断言
Acknowledgements
致谢
The authors would like to thank the members of the Vectors of Trust mailing list in the IETF for discussion and feedback on the concept and document, as well as the members of the ISOC Trust and Identity team for their support. In particular, the authors would like to thank Paul Grassi, Jim Fenton, Sarah Squire, Benjamin Kaduk, John Bradley, and Karen O'Donoghue.
作者要感谢IETF中信任向量邮件列表的成员对该概念和文件的讨论和反馈，以及ISOC信任和身份团队的成员的支持。作者特别要感谢保罗·格拉西、吉姆·芬顿、莎拉·斯奎尔、本杰明·卡杜克、约翰·布拉德利和卡伦·奥多诺霍。
Authors' Addresses
作者地址
Justin Richer (editor) Bespoke Engineering
Justin Richer（编辑）定制工程
Email: ietf@justin.richer.org
Email: ietf@justin.richer.org
Leif Johansson Swedish University Network Thulegatan 11 Stockholm Sweden
Leif Johansson瑞典大学网络Thulegatan 11瑞典斯德哥尔摩
Email: leifj@sunet.se
URI: http://www.sunet.se
Email: leifj@sunet.se
URI: http://www.sunet.se