[要約] RFC 8485は、信頼ベクトルの概念とその使用方法について説明している。このRFCの目的は、ネットワークセキュリティにおける信頼モデルの改善と、信頼ベクトルの実装と展開のためのガイドラインを提供することである。
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.
このドキュメントでは、デジタルIDトランザクションとその参加者のいくつかの側面を説明および通知するメカニズムを定義します。これらの側面は、そのトランザクションに置かれる信頼の量を決定するために使用されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
デジタルIDトランザクションの信頼度を測定する方法は、これまで2つの主要なカテゴリに分類されてきました。すべての測定値が単一のスカラー値に結合されるか、信頼度の決定が詳細な属性メタデータセットに基づいてローカルで計算されます。このドキュメントでは、単一の値よりも表現力が高く、包括的な属性メタデータほど複雑ではない信頼情報を伝達する方法を定義しています。
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年に発行された第3版[SP-800-63-3]の前は、NIST Special Publication 800-63 [SP-800-63-2]は、保証レベル（LoA）と呼ばれる信頼の単一スカラー測定を使用していました。 LoAは、システム内のさまざまなトランザクションを大まかなレベルで比較するために使用できます。たとえば、LoA4トランザクションは、LoA2トランザクションよりも（すべての測定されたカテゴリにわたって）一般に信頼されていると見なされます。特定のトランザクションのLoAは、アイデンティティプロバイダー（IdP）によって計算され、証明書利用者（RP）によって消費されます。信頼度の測定値は単純な数値なので、RPが処理して比較するのは簡単です。ただし、各LoAにはトランザクションのさまざまな側面が含まれているため、実際の状況を表すことはできません。たとえば、匿名のユーザーアカウントには、内部告発者や政治的反体制派によく見られるような非常に強力な資格情報がある場合があります。強力な信任状にもかかわらず、IDの証明がないため、アカウントによって実行されるトランザクションはすべて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.
RPが使用する属性ベースのアクセス制御（ABAC）システムは、属性データが検証されたのは最近、誰が行ったかなど、ユーザーの属性に関する詳細を知る必要がある場合があります。属性メタデータシステムは、トランザクションに関する非常に細かい詳細を表現できます。ただし、このアプローチでは、RPの消費に関するすべての属性データをIdPが収集、保存、および送信する必要があります。 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 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.
このドキュメントで提案されている信頼のベクトル（VoT）アプローチは、IDトランザクションの複数の側面（IDの証明、資格の強さ、資格の管理、アサーションの強さを含むがこれらに限定されない）の表現を許可することにより、これら2つの代替案の間のバランスを追求します。完全な属性メタデータの説明が必要です。この測定方法では、LoAよりも実用的なデータと表現力が得られますが、RPの処理は比較的簡単です。 NISITIR 8112 [NISTIR-8112]によって提案されたシステムなど、より詳細な属性メタデータシステムと一緒にVoTを使用できることが予想されます。 RPは、ほとんどの基本的な決定にベクター値を使用できますが、必要に応じてIdPに追加の属性メタデータを照会できます。さらに、ベクトルのより詳細な詳細を必要としないRPの場合、一部の信頼フレームワークは、特定のベクトル値のセットと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.
このドキュメントでは、これらのベクトルのデータモデルと、パーティ間でそれらを伝達するためのネットワーク形式を定義します。データモデルによって定義されたベクトルの値は、信頼定義に固定されています。このドキュメントでは、4つのコンポーネントカテゴリを含む、この情報の伝達に使用する値を定義するためのガイダンスと、それらのカテゴリ内の値を定義するためのガイダンスも提供します。さらに、このドキュメントでは、より具体的なものを必要としない使用例のために、付録（付録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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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".
IDフェデレーション：IDプロバイダー（IdP）がユーザーのID情報をRPにアサートするプロトコル。暗号化アサーションまたはその他の検証可能なメカニズム、またはそのようなプロトコルを実装するシステムを使用する。単に「フェデレーション」とも呼ばれます。
Identity Provider (IdP): A system that manages identity information and is able to assert this information across the network through an identity API.
IDプロバイダー（IdP）：ID情報を管理し、ID APIを介してネットワーク全体でこの情報をアサートできるシステム。
Identity Subject: The individual (user) engaging in the identity transaction, that is, being identified by the identity provider to the RP.
IDサブジェクト：IDトランザクションに従事している、つまりIDプロバイダーによって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.
Federated Credential：IdPがユーザーを認証するためにネットワークを介してRPに提示するアサーション。
Relying Party (RP): A system that consumes identity information from an IdP for the purposes of authenticating the user.
証明書利用者（RP）：ユーザーを認証する目的でIdPからID情報を使用するシステム。
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 Component: One of several constituent parts that make up a vector, indicating a category of information.
ベクトルコンポーネント：ベクトルを構成するいくつかの構成要素の1つで、情報のカテゴリを示します。
Vector Component Value: One of the values applied to a vector component within a vector.
ベクトルコンポーネント値：ベクトル内のベクトルコンポーネントに適用される値の1つ。
This document assumes the following model for identity based on identity federation technologies:
このドキュメントでは、IDフェデレーションテクノロジーに基づくIDの次のモデルを想定しています。
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.
IDサブジェクト（ユーザーとも呼ばれます）は、RPに関して、RPに関してユーザーに関するIDアサーションを作成することにより、ユーザーに代わって信頼できるサードパーティとして機能するIDプロバイダーに関連付けられています。
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に提示されるIDアサーションの一部としてネットワーク全体で伝達されます。
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.
「Vectors of Trust」という用語は、複数の独立した値で構成されるアイテムとして定義されるベクトルの数学的構造に触発されています。
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.
この仕様は、4つの直交コンポーネントを定義します。IDの証明、プライマリクレデンシャルの使用、プライマリクレデンシャルの管理、およびアサーションプレゼンテーションです。
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 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.
各コンポーネントは、「[A-Z]」の範囲の単一の大文字のASCII文字で構成される区切り文字で識別されます。分界器は、自然な方法で関連付けられているカテゴリを反映する必要があります（SHOULD）。コンポーネントの境界は、セクション7の説明に従って登録する必要があります。信頼フレームワークの定義では、このレジストリを使用して特殊なコンポーネントを定義することが予想されますが、信頼フレームワークが既存のコンポーネントカテゴリを可能な限り再利用することをお勧めします。同じ境界を2つの異なる次元に使用してはなりません（MUST NOT）。異なる信頼フレームワークは、同じ情報に同じ境界を使用する必要があります（SHOULD）。時間の経過とともにコンポーネントの寸法が比較的少なくなることがさらに予想され、この仕様では、このセクションで4つの汎用カテゴリを定義しています。すべてのベクトル値の処理は信頼フレームワークに関連しているため、コンポーネントを解釈する正確なセマンティクスは、使用している信頼フレームワークによって異なることに注意してください。
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]」の範囲の1桁の数字または小文字のASCII文字が続きます。自然な順序を持つカテゴリは、数字を優先する必要があります（SHOULD）。数字が大きいほど、小さい数字よりも強いアサーションを示します。自然な順序付けがないカテゴリ、またはあいまいな順序付けが可能なカテゴリでは、文字を優先する必要があります。文字は順序を意味する場合もありますが、より自然にニーモニックに使用することもできます。信頼フレームワークは、連続している必要なく、カテゴリ内のすべての可能な値を使用できます。
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.
カテゴリーは文字と数字の両方を同時に使用してもよい（MAY）。たとえば、特定のオプションを示す通常の値に「a」、「b」、「c」などの文字を使用しながら、カテゴリで「0」を「ステートメントが作成されない」という意味として定義できます。別のシステムでは、追加の詳細が文字で提供される、順序付けられた基本セットの数字を使用できます。
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.
各コンポーネントは、単一のベクトル内の複数の異なる値で繰り返されてもよく、値の論理ANDを表します（詳細については、セクション3.1を参照）。同じコンポーネントと値の組み合わせを単一のベクトル内で繰り返してはなりません。たとえば、ベクターには「P1」と「Pa」の両方を含めることができますが、「P1」の2つのインスタンスを含めることはできません。信頼フレームワークは、値の組み合わせに関する追加の制限を定義してもよい（MAY）。
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は、ベクターの各コンポーネントに割り当てられた値が、使用中の信頼フレームワークの特定の知識なしに、ベクタースペース内の同じコンポーネントまたは他のコンポーネントと比較された場合、固有の順序または推定プロパティを持っていると想定してはなりません（MUST NOT）。つまり、「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.
アイデンティティプルーフディメンションは、全体として、アイデンティティ属性のセットがどれだけ強く検証および検査されたかを定義します。つまり、この次元は、特定のデジタルIDトランザクションが特定の（現実の）IDサブジェクトに対応する可能性を示します。たとえば、ユーザーは、正式な名前と住所を証明するために信頼できる当事者に文書を提供する必要がありましたか、それともそのような値を自己主張できましたか？この次元では、「P0」、「P1」などの「P」の境界を使用します。アカウントを付与されている個人に多少厳格な校正を適用できるため、ID校正のほとんどの定義には自然な順序があります。このような場合は、このコンポーネントに数字を使用し、トランザクションで通信できるのは単一の値のみにすることをお勧めします。
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.
このディメンションでは、「Ca」、「Cb」などの「C」の区切り文字を使用します。信頼フレームワーク内にいくつかの同等のクラスが記述されている可能性があるため、資格情報の使用のほとんどの定義には、全体的な自然な順序はありません。このような場合は、このコンポーネントに文字を使用し、複数要素の認証を使用する場合など、複数の異なる資格情報の使用要素を同時に通信できるようにすることをお勧めします。
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.
この次元では、「Ma」、「Mb」などの「M」の境界を使用します。状況によっては、値の間に優先順位や比較がある場合もありますが、資格情報管理のほとんどの定義には、全体的な自然な順序はありません。そのような場合、このコンポーネントに文字を使用し、複数の異なる値を同時に通信できるようにすることをお勧めします。
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.
アサーションプレゼンテーションディメンションは、意図しない関係者に情報が漏洩することなく、またなりすましなしに、特定のデジタルIDがネットワーク全体でどの程度適切に通信できるかを定義します。言い換えると、このディメンションは、特定のトランザクションのアイデンティティサブジェクトに対して、特定のデジタルアイデンティティが特定のアイデンティティプロバイダーによってアサートされた可能性を示します。この情報は、フェデレーションプロトコルでIDアサーションを処理することの副次効果として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.
この次元では、「Aa」、「Ab」などの「A」の境界を使用します。アサーションプレゼンテーションのほとんどの定義には、全体的な自然な順序はありません。このような場合は、このコンポーネントに文字を使用し、複数の値を同時に通信できるようにすることをお勧めします。
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.
信頼のベクトルは、IDおよび認証トランザクションのコンテキストで使用されるように設計されており、フェデレーション資格情報のコンテキストに関する情報を提供します。したがって、フェデレーテッド信任状を表すアサーションに強く結び付けられた方法で、フェデレーテッド信任状のコンテキストでベクトルを通信できる必要があります。
This vector has several requirements for use.
このベクターには、いくつかの使用要件があります。
o All applicable vector components and values need to be combined into a single vector.
o 該当するすべてのベクトルコンポーネントと値を1つのベクトルに組み合わせる必要があります。
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.
ベクトルは、ベクトルコンポーネントのピリオドで区切られた（ '。'）リストとして表現する必要があります。ベクトルコンポーネントタイプは、1つのベクトル内で複数回発生する可能性がありますが、ベクトルコンポーネントの特定の値は、1つのベクトル内で複数回発生することはできません。つまり、「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を参照）とともに通信する必要があります。トラストマークは、署名されたアサーションで一緒に運ばれる2つの値など、ベクトル値に暗号でバインドされている必要があります。コンテキストのないベクトル値は処理できず、異なるコンテキストで定義されたベクトルは、値全体と直接比較することはできません。異なる信頼フレームワークはコンポーネントの定義（その値を含む）を再利用できますが、そのようなクロスコンテキスト値の処理はこの仕様の範囲外です。
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」は、「既知のデバイス、資格情報の発行とローテーションに必要な完全な証明、共有キーの所有に関する暗号の証明、署名されたバックチャネル検証済みのアサーション、およびIDの証明に対する主張なし」に変換されます。 「同じコンテキストで。ここではIDの証明についての主張は行われていないため、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.
「vot」および「vtm」クレームは、RPによって解釈され、アイデンティティトランザクション全体に適用されるものであり、特定の属性に適用されるとは限りません。
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トークンの本文は、次のJSONオブジェクト[RFC8259]ペイロードのようになると想定します。 IDトークンの。
{
"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仕様に従って、IDトークンの本文は署名され、オプションでJSON Object Signing and Encryption（JOSE）を使用して暗号化されます。 「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.
同じクレームを使用してOpenID Connectトランザクション中に発行されたIDトークンまたはアクセストークンを説明するトークンイントロスペクション[RFC7662]応答でベクトル値が返される場合があります。
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値の部分セットをリクエストできます（MAY）。このフィールドの値は、文字列のJSON配列[RFC8259]であり、各文字列は、許容可能なベクトルコンポーネントのセットを識別します。各ベクトル内のコンポーネント値はANDで結合され、個別のベクトルはORで結合されます。たとえば、「["P1.Cb.Cc.Ab"、 "Ce.Ab"]」という形式のベクターのリストは、「P1 AND Cb AND Cc AND Ab」の完全なセット、または完全なセット「Ce AND Ab」のセットは、このトランザクションのこのRPで同時に受け入れられます。
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.
ベクトル要求値はコンポーネントを省略してもよい（MAY）。これは、応答ベクトルでのそのコンポーネントの省略を含む、そのコンポーネントカテゴリで任意の値が許容されることを示します。
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は、有効なコンポーネントと値、それらの併用方法、およびコンポーネントの値が信頼フレームワーク内でどのように機能するかを説明する、人間が読めるドキュメントを指す必要があります。トラストマークURLのコンテンツは、RPのオペレーターまたは実装者から到達可能でなければなりません（MUST）。 URLは、RPが着信ベクトルを一貫した方法で処理できるようにするために、特定の信頼フレームワークに対して長期にわたって安定している必要があります。異なる処理ルールを必要とする信頼フレームワークの新しいバージョンは、異なるトラストマーク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.
Vectors of Trustは、IDフェデレーションプロトコルでネットワーク接続された当事者間で認証データを通信するための柔軟で再利用可能なフレームワークであることを意図しています。ただし、必要な情報の正確な性質は、情報を必要とする関係者とそれらの間の関係によって異なります。このドキュメントでは、付録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で定義されているようなコンポーネントカテゴリは、汎用であり、さまざまな信頼フレームワークで再利用できることを目的としています。拡張仕様は、可能な場合、既存のカテゴリ定義を再利用する必要があります（SHOULD）。拡張機能は、セクション7で定義されたレジストリを使用して、必要に応じて追加のカテゴリを作成できます（MAY）。レジストリは、さまざまな信頼フレームワーク全体で既存のカテゴリの再利用と発見を促進します。たとえば、別のフレームワークの「P」カテゴリは、身元証明および関連情報に使用する必要があります（SHOULD）。
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で定義されているようなコンポーネントの値は、定義する信頼ドキュメントとの関連を意図しています。この仕様のコンポーネントの値は汎用であることが意図されており、拡張機能は値とその定義を再利用できますが、信頼フレームワークはすべての許容値を定義する必要があります。これらの値は常にトラストマークのコンテキストで解釈されるため、これらの値は中央レジストリに記録されません。その結果、どちらの場合も「P」コンポーネントがIDプルーフに何らかの方法で使用されている場合でも、1つのフレームワークのP1値と別のフレームワークの「P1」値の解釈は、コンテキストの信頼フレームワークドキュメントによって大きく異なる可能性があります。
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で説明されているように、コンポーネントの値に対して数値順またはグループカテゴリアプローチを選択する必要があります（SHOULD）。両方のタイプの組み合わせを使用できます（MAY）。信頼フレームワークは、各カテゴリに複数の値を許可するかどうかを指定する必要があります。通常、コンポーネントカテゴリは複数の異なる値を持つことができますが、拡張機能の一連の値の特定の定義は、特定のコンポーネントカテゴリをトランザクションごとに単一の値に制限できます（MAY）。 。信頼フレームワークが「0」の値を使用して、特定のカテゴリの空またはnull条件を示すことをお勧めします（たとえば、校正が行われていない、または認証トークンが使用されていない）。
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.
この仕様を拡張および実装するすべての信頼フレームワークは、RPが異なる信頼フレームワークを区別できるように、一意のトラストマークURL（セクション5を参照）によって参照される必要があります。
This specification creates one registry and registers several values into existing registries.
この仕様は、1つのレジストリを作成し、いくつかの値を既存のレジストリに登録します。
This specification establishes the "Vectors of Trust Components" registry.
この仕様は、「Vectors of Trust Components」レジストリを確立します。
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メーリングリストに送信された登録リクエストでは、適切な件名を使用する必要があります（「Vector of Trustコンポーネント名の登録リクエスト：例」など）。指定された専門家は2週間以内にレビューを提供し、登録要求を承認または拒否して、この決定をレビューリストと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.
「Vector of Trust Components」レジストリには、ベクターコンポーネントとその関連する境界の定義が含まれています。
o Demarcator Symbol: P o Description: Identity proofing o Change Controller: IESG o Specification document(s): [RFC8485]
o 分界記号：P o説明：識別証明o変更管理者：IESG o仕様書：[RFC8485]
o Demarcator Symbol: C o Description: Primary credential usage o Change Controller: IESG o Specification document(s): [RFC8485]
o 分界記号：C o説明：一次資格情報の使用法o変更管理者：IESG o仕様書：[RFC8485]
o Demarcator Symbol: M o Description: Primary credential management o Change Controller: IESG o Specification document(s): [RFC8485]
o 分界記号：M o説明：一次資格情報管理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 Token Claims」レジストリに次の値を追加します。
o Claim name: vot o Claim Description: Vector of Trust value o Change Controller: IESG o Reference: [RFC8485]
o クレーム名：vot oクレームの説明：信頼値のベクトル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 Token Introspection Response"レジストリに以下の値を追加します。
o Name: vot o Description: Vector of Trust value o Change Controller: IESG o Reference: [RFC8485]
o 名前：vot o説明：信頼値のベクトル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 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.
ベクトル値は常にトラストマークに関連付けられており、そのトラストマークによって定義された信頼フレームワークのコンテキストでRPによって解釈される必要があります。異なる信頼フレームワークは、LoAの場合と同様に、同じコンポーネント値に異なる解釈を適用できます。したがって、RPが間違ったコンテキストでコンポーネント値を解釈すると、誤って要求を受け入れたり拒否したりする可能性があります。この誤りを回避するために、RPは、適切に解釈する方法を理解していない信頼フレームワークで定義されたベクトルを拒否する必要があります。
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によって合意され、トラストマーク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は送信し、RPはユースケースに必要な情報のみを要求することをお勧めします。
[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 Connect Core 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。、編、「The OAuth 2.0 Authorization Framework」、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]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Token（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。、編、「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]コットン、M。、レイバ、B。、およびT.ナルテン、「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。、編、「JavaScript Object Notation（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、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、2015年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 Special Publication 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]米国国立標準技術研究所、「デジタルIDガイドライン」、NIST Special Publication 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で説明されているように、独自のコンポーネント値を定義する必要があります（SHOULD）。拡張は、可能な場合、ここにリストされている特定の値と定義を再利用できますが、それらの特定の値を再リストする必要があります。
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：IDプロバイダーと識別された当事者との間には拘束力のある関係があります（署名/公証された文書や雇用記録など）
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 Cookie（他に何もない）
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
Cc：ユーザー名とパスワードの組み合わせなどの共有シークレット
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：保護なし/署名されていないベアラーID（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
広告：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のVectors of Trustメーリングリストのメンバーに、コンセプトとドキュメントについての議論とフィードバックを提供してくれたこと、およびISOC Trust and Identityチームのメンバーのサポートに感謝したいと思います。特に、著者は、ポールグラッシ、ジムフェントン、サラスクワイア、ベンジャミンカドゥック、ジョンブラッドリー、カレンオドノヒューに感謝します。
Authors' Addresses
著者のアドレス
Justin Richer (editor) Bespoke Engineering
Justin Richer（editor）Bespoke Engineering
Email: ietf@justin.richer.org
Leif Johansson Swedish University Network Thulegatan 11 Stockholm Sweden
Leif Johansson Swedish University Network Thulegatan 11ストックホルムスウェーデン
Email: leifj@sunet.se
URI: http://www.sunet.se