RFC 9493 - Subject Identifiers for Security Event Tokens 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9493.html
タイトル : RFC 9493 - セキュリティイベントトークンのサブジェクト識別子
翻訳編集 : 自動生成

[要約] RFC 9493 は、セキュリティイベントトークン内で使用されるサブジェクト識別子を定義し、JSONオブジェクトとしてエンコードするための構造化情報とフォーマットを提供する。また、サブジェクト識別子の名前付けとJWTの"sub_id"クレームのための登録を確立する。

Internet Engineering Task Force (IETF)                   A. Backman, Ed.
Request for Comments: 9493                                        Amazon
Category: Standards Track                                   M. Scurtescu
ISSN: 2070-1721                                                 Coinbase
                                                                 P. Jain
                                                                  Fastly
                                                           December 2023

Subject Identifiers for Security Event Tokens

セキュリティイベントトークンのサブジェクト識別子

Abstract

概要

Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event. This specification formalizes the notion of Subject Identifiers as structured information that describes a subject and named formats that define the syntax and semantics for encoding Subject Identifiers as JSON objects. It also establishes a registry for defining and allocating names for such formats as well as the JSON Web Token (JWT) "sub_id" Claim.

セキュリティイベント内で通信されるセキュリティイベントトークンは、さまざまな識別子をサポートして、イベントに関連する被験者を識別する場合があります。この仕様は、主題識別子の概念を、主題識別子をJSONオブジェクトとしてエンコードする構文とセマンティクスを定義する主題および名前の形式を説明する構造化された情報として形式化します。また、そのような形式の名前を定義および割り当てるためのレジストリと、JSON Webトークン（JWT）「Sub_Id」クレームも確立します。

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/rfc9493.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9493で取得できます。

Copyright Notice

著作権表示

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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。

   1.  Introduction
   2.  Notational Conventions
     2.1.  Definitions
   3.  Subject Identifiers
     3.1.  Identifier Formats versus Principal Types
     3.2.  Identifier Format Definitions
       3.2.1.  Account Identifier Format
       3.2.2.  Email Identifier Format
       3.2.3.  Issuer and Subject Identifier Format
       3.2.4.  Opaque Identifier Format
       3.2.5.  Phone Number Identifier Format
       3.2.6.  Decentralized Identifier (DID) Format
       3.2.7.  Uniform Resource Identifier (URI) Format
       3.2.8.  Aliases Identifier Format
   4.  Subject Identifiers in JWTs
     4.1.  JWT "sub_id" Claim
     4.2.  JWT "sub_id" Claim and "iss_sub" Subject Identifier
   5.  Considerations for Specifications that Define Identifier
           Formats
   6.  Privacy Considerations
     6.1.  Identifier Correlation
   7.  Security Considerations
   8.  IANA Considerations
     8.1.  Security Event Identifier Formats Registry
       8.1.1.  Registration Template
       8.1.2.  Initial Registry Contents
       8.1.3.  Guidance for Expert Reviewers
     8.2.  JSON Web Token Claims Registration
       8.2.1.  Registry Contents
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

As described in Section 1.2 of [RFC8417] ("Security Event Token (SET)"), subjects related to security events may take a variety of forms, including but not limited to a JWT [RFC7519] principal, an IP address, a URL, etc. Different types of subjects may need to be identified in different ways (e.g., a user might be identified by an email address, a phone number, or an account number). Furthermore, even in the case where the type of the subject is known, there may be multiple ways by which a given subject may be identified. For example, an account may be identified by an opaque identifier, an email address, a phone number, a JWT "iss" Claim and "sub" Claim, etc., depending on the nature and needs of the transmitter and receiver. Even within the context of a given transmitter and receiver relationship, it may be appropriate to identify different accounts in different ways, for example, if some accounts only have email addresses associated with them while others only have phone numbers. Therefore, it can be necessary to indicate within a SET the mechanism by which a subject is being identified.

[RFC8417]（「セキュリティイベントトークン（セット）」）のセクション1.2で説明されているように、セキュリティイベントに関連する被験者は、JWT [RFC7519]、IPアドレス、URLを含むがこれらに限定されないさまざまなフォームをとることができます。など。さまざまなタイプの被験者をさまざまな方法で識別する必要がある場合があります（たとえば、ユーザーは、電子メールアドレス、電話番号、またはアカウント番号によって識別される場合があります）。さらに、被験者のタイプがわかっている場合でも、特定の被験者が特定される可能性のある複数の方法がある場合があります。たとえば、アカウントは、トランスミッターとレシーバーの性質とニーズに応じて、不透明な識別子、電子メールアドレス、電話番号、JWT「ISS」クレーム、「サブ」クレームなどによって識別される場合があります。特定の送信機と受信機の関係のコンテキスト内であっても、さまざまな方法で異なるアカウントを識別することが適切かもしれません。たとえば、一部のアカウントには電子メールアドレスのみが関連付けられている場合、他のアカウントは電話番号しか持っていません。したがって、被験者が特定されているメカニズムをセット内で示す必要があります。

To address this problem, this specification defines Subject Identifiers as JSON [RFC8259] objects containing information identifying a subject and defines Identifier Formats as named sets of rules describing how to encode different kinds of subject-identifying information (e.g., an email address or an issuer and subject pair) as a Subject Identifier.

この問題に対処するために、この仕様はサブジェクト識別子をJSON [RFC8259]を含むJSON [RFC8259]を主題の識別する情報を含むオブジェクトとして定義し、識別子形式を異なる種類の主題識別情報（例えば、電子メールアドレスまたは発行者をエンコードする方法を説明するルールの名前が付けられたものとして定義します。被験者のペア）は、被験者識別子として。

Below is a non-normative example of a Subject Identifier that identifies a subject by email address, using the Email Identifier Format.

以下は、電子メール識別子形式を使用して、電子メールアドレスごとにサブジェクトを識別する主題識別子の非規範的な例です。

   {
     "format": "email",
     "email": "user@example.com"
   }

Figure 1: Example: Subject Identifier Using the Email Identifier Format

図1：例：電子メール識別子形式を使用したサブジェクト識別子

Subject Identifiers are intended to be a general-purpose mechanism for identifying subjects within JSON objects, and their usage need not be limited to SETs. Below is a non-normative example of a JWT that uses a Subject Identifier in the JWT "sub_id" Claim (defined in this specification) to identify the JWT Subject.

被験者の識別子は、JSONオブジェクト内の被験者を識別するための汎用メカニズムであることを目的としており、その使用はセットに限定される必要はありません。以下は、JWT "sub_id"クレーム（この仕様で定義）のサブジェクト識別子を使用してJWTの被験者を識別するJWTの非規範的な例です。

   {
     "iss": "issuer.example.com",
     "sub_id": {
       "format": "phone_number",
       "phone_number": "+12065550100"
     }
   }

Figure 2: Example: JWT Using a Subject Identifier with the JWT "sub_id" Claim

図2：例：JWT識別子を使用してJWT "sub_id"クレームを使用しているJWT

Usage of Subject Identifiers also need not be limited to identifying JWT Subjects. They are intended as a general-purpose means of expressing identifying information in an unambiguous manner. Below is a non-normative example of a SET containing a hypothetical security event describing the interception of a message, using Subject Identifiers to identify the sender, intended recipient, and interceptor.

被験者の識別子の使用は、JWT被験者の識別に限定される必要はありません。それらは、識別情報を明確な方法で表現する汎用手段として意図されています。以下は、主題識別子を使用して送信者、意図された受信者、およびインターセプターを識別するために、メッセージの傍受を説明する仮説セキュリティイベントを含むセットの非規範的な例です。

   {
     "iss": "issuer.example.com",
     "iat": 1508184845,
     "aud": "aud.example.com",
     "events": {
       "https://secevent.example.com/events/message-interception": {
         "from": {
           "format": "email",
           "email": "alice@example.com"
         },
         "to": {
           "format": "email",
           "email": "bob@example.com"
         },
         "interceptor": {
           "format": "email",
           "email": "eve@example.com"
         }
       }
     }
   }

Figure 3: Example: SET with an Event Payload Containing Multiple Subject Identifiers

図3：例：複数の被験者識別子を含むイベントペイロードで設定

2. Notational Conventions

2. 表記規則

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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

2.1. Definitions

2.1. 定義

This specification utilizes terminology defined in [RFC8259] and [RFC8417].

この仕様は、[RFC8259]および[RFC8417]で定義された用語を使用します。

Within this specification, the terms "Subject" and "subject" refer generically to anything being identified via one or more pieces of information. The term "JWT Subject" refers specifically to the subject of a JWT (i.e., the subject that the JWT asserts claims about).

この仕様内では、「サブジェクト」と「件名」という用語は、1つ以上の情報を介して識別されているものを一般的に指します。「JWT主題」という用語は、特にJWTの主題を指します（つまり、JWTが主張している主題）。

3. Subject Identifiers

3. 主題識別子

A Subject Identifier is a JSON object [RFC8259] whose contents may be used to identify a subject within some context. An Identifier Format is a named definition of a set of information that may be used to identify a subject and the rules for encoding that information as a Subject Identifier; these rules define the syntax and semantics of Subject Identifiers. A Subject Identifier MUST conform to a specific Identifier Format and MUST contain a "format" member whose value is the name of that Identifier Format.

サブジェクト識別子は、コンテンツを使用して、一部のコンテキスト内でサブジェクトを識別するために内容を使用できるJSONオブジェクト[RFC8259]です。識別子形式は、主題を識別するために使用される可能性のある一連の情報の名前付き定義と、その情報を主題識別子としてエンコードするためのルールです。これらのルールは、サブジェクト識別子の構文とセマンティクスを定義します。サブジェクト識別子は、特定の識別子形式に準拠する必要があり、その識別子形式の名前である「フォーマット」メンバーを含める必要があります。

Every Identifier Format MUST have a unique name registered in the IANA "Security Event Identifier Formats" registry established in Section 8.1 or a Collision-Resistant Name as defined in [RFC7519]. Identifier Formats that are expected to be used broadly by a variety of parties SHOULD be registered in the "Security Event Identifier Formats" registry.

すべての識別子形式は、セクション8.1で確立されたIANA「セキュリティイベント識別子形式」レジストリまたは[RFC7519]で定義されている衝突耐性名に登録されている一意の名前を持つ必要があります。さまざまな関係者が広く使用すると予想される識別子形式は、「セキュリティイベント識別子形式」レジストリに登録する必要があります。

An Identifier Format MAY describe more members than are strictly necessary to identify a subject and MAY describe conditions under which those members are required, optional, or prohibited. The "format" member is reserved for use as described in this specification; Identifier Formats MUST NOT declare any rules regarding the "format" member.

識別子形式は、被験者を識別するために厳密に必要であるよりも多くのメンバーを記述し、それらのメンバーが必要な、オプション、または禁止されている条件を記述する場合があります。「フォーマット」メンバーは、この仕様で説明されているように使用するために予約されています。識別子形式は、「フォーマット」メンバーに関するルールを宣言してはなりません。

Every member within a Subject Identifier MUST match the rules specified for that member by this specification or by a Subject Identifier's Identifier Format. A Subject Identifier MUST NOT contain any members prohibited or not described by its Identifier Format and MUST contain all members required by its Identifier Format.

被験者識別子内のすべてのメンバーは、この仕様またはサブジェクト識別子の識別子形式によってそのメンバーに指定されたルールと一致する必要があります。被験者の識別子には、識別子形式で禁止されているか、記述されていないメンバーが含まれていない必要があり、その識別子形式で必要なすべてのメンバーを含める必要があります。

3.1. Identifier Formats versus Principal Types

3.1. 識別子形式と主要なタイプ

Identifier Formats define how to encode identifying information for a subject. Unlike Principal Types, they do not define the type or nature of the subject itself. For example, while the Email Identifier Format declares that the value of the "email" member is an email address, a subject in a security event that is identified by an Email Subject Identifier could be an end user who controls that email address, the mailbox itself, or anything else that the transmitter and receiver both understand to be associated with that email address. Consequently, Subject Identifiers remove ambiguity around how a subject is being identified and how to parse an identifying structure, but they do not remove ambiguity around how to resolve that identifier for a subject. For example, consider a directory management API that allows callers to identify users and groups through both opaque unique identifiers and email addresses. Such an API could use Subject Identifiers to disambiguate between which of these two types of identifiers is in use. However, the API would have to determine whether the subject is a user or group via some other means, such as by querying a database, interpreting other parameters in the request, or inferring the type from the API contract.

識別子形式は、主題の識別情報をエンコードする方法を定義します。主要なタイプとは異なり、被験者自体のタイプまたは性質を定義しません。たとえば、電子メール識別子形式は「電子メール」メンバーの値が電子メールアドレスであると宣言していますが、電子メールの識別子によって識別されるセキュリティイベントのサブジェクトは、その電子メールアドレス、メールボックスを制御するエンドユーザーである可能性があります。それ自体、または送信機と受信機がその電子メールアドレスに関連付けられていることを理解している他のもの。その結果、被験者の識別子は、被験者の識別方法と識別構造を解析する方法についてのあいまいさを削除しますが、被験者のその識別子を解決する方法についてのあいまいさを削除しません。たとえば、発信者が不透明な一意の識別子と電子メールアドレスの両方を介してユーザーとグループを識別できるようにするディレクトリ管理APIを検討してください。このようなAPIは、サブジェクト識別子を使用して、これら2つのタイプの識別子のうち、使用しているものの間で説明することができます。ただし、APIは、被験者がデータベースを照会したり、リクエストの他のパラメーターを解釈したり、API契約からタイプを推測したりするなど、他の手段を介してユーザーまたはグループであるかどうかを判断する必要があります。

3.2. Identifier Format Definitions

3.2. 識別子形式の定義

The following Identifier Formats are registered in the IANA "Security Event Identifier Formats" registry established in Section 8.1.

次の識別子形式は、セクション8.1で確立されたIANA「セキュリティイベント識別子形式」レジストリに登録されています。

Since the Subject Identifier Format conveys semantic information, applications SHOULD choose the most specific possible format for the identifier in question. For example, an email address can be conveyed using a "mailto:" URI and the URI Identifier Format, but since the value is known to be an email address, the application should prefer to use the Email Identifier Format instead.

サブジェクト識別子形式はセマンティック情報を伝えているため、アプリケーションは問題の識別子に最も特定の可能な形式を選択する必要があります。たとえば、「Mailto：」URIおよびURI識別子形式を使用して電子メールアドレスを伝えることができますが、値は電子メールアドレスであることが知られているため、アプリケーションは代わりに電子メール識別子形式を使用することを好むはずです。

3.2.1. Account Identifier Format

3.2.1. アカウント識別子形式

The Account Identifier Format identifies a subject using an account at a service provider, identified with an "acct" URI as defined in [RFC7565]. An account is an arrangement or agreement through which a user gets access to a service and gets a unique identity with the service provider. Subject Identifiers in this format MUST contain a "uri" member whose value is the "acct" URI for the subject. The "uri" member is REQUIRED and MUST NOT be null or empty. The Account Identifier Format is identified by a value of "account" in the "format" member.

アカウント識別子形式は、[RFC7565]で定義されている「ACCT」URIで識別されたサービスプロバイダーのアカウントを使用して被験者を識別します。アカウントとは、ユーザーがサービスにアクセスし、サービスプロバイダーと一意のIDを取得する取り決めまたは契約です。この形式のサブジェクト識別子には、この価値が被験者の「ACCT」URIである「URI」メンバーを含める必要があります。「uri」メンバーが必要であり、nullまたは空にしてはなりません。アカウント識別子形式は、「フォーマット」メンバーの「アカウント」の値によって識別されます。

Below is a non-normative example Subject Identifier for the Account Identifier Format:

以下は、アカウント識別子形式の非規範的な例の主題識別子です。

   {
     "format": "account",
     "uri": "acct:example.user@service.example.com"
   }

Figure 4: Example: Subject Identifier for the Account Identifier Format

図4：例：アカウント識別子形式の主題識別子

3.2.2. Email Identifier Format

3.2.2. 電子メール識別子形式

The Email Identifier Format identifies a subject using an email address. Subject Identifiers in this format MUST contain an "email" member whose value is a string containing the email address of the subject, formatted as an "addr-spec" as defined in Section 3.4.1 of [RFC5322]. The "email" member is REQUIRED and MUST NOT be null or empty. The value of the "email" member MUST identify a mailbox to which email may be delivered, in accordance with [RFC5321]. The Email Identifier Format is identified by the name "email".

電子メール識別子形式は、電子メールアドレスを使用してサブジェクトを識別します。この形式のサブジェクト識別子には、[RFC5322]のセクション3.4.1で定義されている「addr-spec」としてフォーマットされた、サブジェクトの電子メールアドレスを含む文字列が値である「電子メール」メンバーを含める必要があります。「電子メール」メンバーが必要であり、nullまたは空にしてはなりません。[電子メール]メンバーの値は、[RFC5321]に従って、電子メールが配信されるメールボックスを特定する必要があります。電子メール識別子形式は、「電子メール」という名前で識別されます。

Below is a non-normative example Subject Identifier in the Email Identifier Format:

以下は、電子メール識別子形式の非規範的な例の主題識別子です。

   {
     "format": "email",
     "email": "user@example.com"
   }

Figure 5: Example: Subject Identifier in the Email Identifier Format

図5：例：電子メール識別子形式の主題識別子

3.2.2.1. Email Canonicalization

3.2.2.1. 電子メールの正規化

Many email providers will treat multiple email addresses as equivalent. While the domain portion of an email address [RFC5322] is consistently treated as case-insensitive per [RFC1034], most providers treat the local part of the email address as case-insensitive as well and consider "user@example.com", "User@example.com", and "USER@example.com" as the same email address. Some providers also treat dots (".") as optional; for example, "user.name@example.com", "username@example.com", "u.s.e.r.name@example.com", and "u.s.e.r.n.a.m.e@example.com" might all be treated as equivalent. This has led users to view these strings as equivalent, driving service providers to implement proprietary email canonicalization algorithms to ensure that email addresses entered by users resolve to the same canonical string. Email canonicalization is not standardized, and there is no way for the event recipient to determine the mail provider's canonicalization method. Therefore, the recipient SHOULD apply its own canonicalization algorithm to incoming events in order to reproduce the translation done by the local email system.

多くの電子メールプロバイダーは、複数の電子メールアドレスを同等のものとして扱います。電子メールアドレスのドメイン部分[RFC5322]は一貫してケース非感受性として[RFC1034]として扱われますが、ほとんどのプロバイダーは、電子メールアドレスのローカル部分をケースインスセンシティブとして扱い、「user@example.com」、」と見なします。user@example.com "、および「user@example.com」と同じメールアドレスとして。一部のプロバイダーは、ドット（ "）をオプションとして扱います。たとえば、「user.name@example.com」、「username@example.com」、「U.S.E.R.Name@example.com」、および「U.S.E.R.N.A.M.E@example.com」はすべて同等のものとして扱われる可能性があります。これにより、ユーザーはこれらの文字列を同等のサービスプロバイダーと見なし、独自の電子メールCanOnicalization Algorithmsを実装して、ユーザーが入力した電子メールアドレスが同じ標準文字列に解決できるようにしました。電子メールの標準化は標準化されておらず、イベントの受信者がメールプロバイダーの標準化方法を決定する方法はありません。したがって、受信者は、ローカル電子メールシステムによって行われた翻訳を再現するために、着信イベントに独自の正規化アルゴリズムを適用する必要があります。

3.2.3. Issuer and Subject Identifier Format

3.2.3. 発行者および主題識別子形式

The Issuer and Subject Identifier Format identifies a subject using a pair of "iss" and "sub" members, analogous to how subjects are identified using the JWT "iss" and "sub" Claims in OpenID Connect [OpenID.Core] ID Tokens. These members MUST follow the formats of the "iss" member and "sub" member defined by [RFC7519], respectively. Both the "iss" member and the "sub" member are REQUIRED and MUST NOT be null or empty. The Issuer and Subject Identifier Format is identified by the name "iss_sub".

発行者と被験者の識別子形式は、OpenID Connect [OpenID.Core] IDトークンのJWT「ISS」および「サブ」クレームを使用して被験者が識別される方法に類似した「ISS」と「サブ」メンバーのペアを使用して被験者を識別します。これらのメンバーは、それぞれ[RFC7519]で定義された「ISS」メンバーと「サブ」メンバーの形式に従う必要があります。「ISS」メンバーと「サブ」メンバーの両方が必要であり、nullまたは空にしてはなりません。発行者と被験者の識別子形式は、「ISS_SUB」という名前で識別されます。

Below is a non-normative example Subject Identifier in the Issuer and Subject Identifier Format:

以下は、発行者およびサブジェクト識別子形式の非規範的な例の主題識別子です。

   {
     "format": "iss_sub",
     "iss": "https://issuer.example.com/",
     "sub": "145234573"
   }

Figure 6: Example: Subject Identifier in the Issuer and Subject Identifier Format

図6：例：発行者および主題識別子形式のサブジェクト識別子

3.2.4. Opaque Identifier Format

3.2.4. 不透明な識別子形式

The Opaque Identifier Format describes a subject that is identified with a string with no semantics asserted beyond its usage as an identifier for the subject, such as a Universally Unique Identifier (UUID) or hash used as a surrogate identifier for a record in a database. Subject Identifiers in this format MUST contain an "id" member whose value is a JSON string containing the opaque string identifier for the subject. The "id" member is REQUIRED and MUST NOT be null or empty. The Opaque Identifier Format is identified by the name "opaque".

不透明識別子形式は、データベース内のレコードの代理識別子として使用される、普遍的に一意の識別子（UUID）またはハッシュなど、サブジェクトの識別子として使用されているセマンティクスのない文字列で識別される被験者を説明します。この形式のサブジェクト識別子には、被験者の不透明な文字列識別子を含むJSON文字列である「ID」メンバーが含まれている必要があります。「ID」メンバーが必要であり、nullまたは空にしてはなりません。不透明な識別子形式は、「不透明」という名前で識別されます。

Below is a non-normative example Subject Identifier in the Opaque Identifier Format:

以下は、不透明な識別子形式の非規範的な例の主題識別子です。

   {
     "format": "opaque",
     "id": "11112222333344445555"
   }

Figure 7: Example: Subject Identifier in the Opaque Identifier Format

図7：例：不透明な識別子形式の主題識別子

3.2.5. Phone Number Identifier Format

3.2.5. 電話番号識別子形式

The Phone Number Identifier Format identifies a subject using a telephone number. Subject Identifiers in this format MUST contain a "phone_number" member whose value is a string containing the full telephone number of the subject, including an international dialing prefix, formatted according to E.164 [E164]. The "phone_number" member is REQUIRED and MUST NOT be null or empty. The Phone Number Identifier Format is identified by the name "phone_number".

電話番号識別子形式は、電話番号を使用して被験者を識別します。この形式の被験者識別子には、e.164 [e164]に従ってフォーマットされた国際ダイヤルプレフィックスを含む、被験者の完全な電話番号を含む文字列が値である「携帯電話」メンバーが含まれている必要があります。「Phone_Number」メンバーが必要であり、nullまたは空にしてはなりません。電話番号識別子形式は、「Phone_Number」という名前で識別されます。

Below is a non-normative example Subject Identifier in the Phone Number Identifier Format:

以下は、電話番号識別子形式の非規範的な例の主題識別子です。

   {
     "format": "phone_number",
     "phone_number": "+12065550100"
   }

Figure 8: Example: Subject Identifier in the Phone Number Identifier Format

図8：例：電話番号識別子形式の主題識別子

3.2.6. Decentralized Identifier (DID) Format

3.2.6. 分散型識別子（DID）形式

The Decentralized Identifier (DID) Format identifies a subject using a DID URL as defined in [DID]. Subject Identifiers in this format MUST contain a "url" member whose value is a DID URL for the DID Subject being identified. The value of the "url" member MUST be a valid DID URL and MAY be a bare DID. The "url" member is REQUIRED and MUST NOT be null or empty. The Decentralized Identifier Format is identified by the name "did".

分散型識別子（DID）形式は、[DID]で定義されているDID URLを使用して被験者を識別します。この形式のサブジェクト識別子には、識別されているDEDのDID URLの値がDID URLである「URL」メンバーを含める必要があります。「URL」メンバーの値は、有効なdid URLでなければならず、むき出しのものである可能性があります。「URL」メンバーが必要であり、nullまたは空にしてはなりません。分散型識別子形式は、「DID」という名前で識別されます。

Below are non-normative example Subject Identifiers for the Decentralized Identifier Format:

以下は、分散型識別子形式の非規範的な例の主題識別子です。

   {
     "format": "did",
     "url": "did:example:123456"
   }

Figure 9: Example: Subject Identifier for the Decentralized Identifier Format, Identifying a Subject with a Bare DID

図9：例：分散型識別子形式のサブジェクト識別子、裸の被験者を識別した

   {
     "format": "did",
     "url": "did:example:123456/did/url/path?versionId=1"
   }

Figure 10: Example: Subject Identifier for the Decentralized Identifier Format, Identifying a Subject with a DID URL with Non-empty Path and Query Components

図10：例：分散型識別子形式のサブジェクト識別子。

3.2.7. Uniform Resource Identifier (URI) Format

3.2.7. 均一なリソース識別子（URI）形式

The Uniform Resource Identifier (URI) Format identifies a subject using a URI as defined in [RFC3986]. This Identifier Format makes no assumptions or guarantees with regard to the content, scheme, or reachability of the URI within the field. Subject Identifiers in this format MUST contain a "uri" member whose value is a URI for the subject being identified. The "uri" member is REQUIRED and MUST NOT be null or empty. The URI Format is identified by the name "uri".

均一なリソース識別子（URI）形式は、[RFC3986]で定義されているURIを使用して被験者を識別します。この識別子形式は、フィールド内のURIのコンテンツ、スキーム、または到達可能性に関して仮定または保証を行いません。この形式の被験者識別子には、識別されている被験者の価値がURIである「URI」メンバーを含める必要があります。「uri」メンバーが必要であり、nullまたは空にしてはなりません。URI形式は、「URI」という名前で識別されます。

Below are non-normative example Subject Identifiers for the URI Format:

以下は、URI形式の非規範的な例の主題識別子です。

   {
     "format": "uri",
     "uri": "https://user.example.com/"
   }

Figure 11: Example: Subject Identifier for the URI Format, Identifying a Subject with a Website URI

図11：例：URI形式のサブジェクト識別子、WebサイトURIを使用したサブジェクトの識別

   {
     "format": "uri",
     "uri": "urn:uuid:4e851e98-83c4-4743-a5da-150ecb53042f"
   }

Figure 12: Example: Subject Identifier for the URI Format, Identifying a Subject with a Random URN

図12：例：URI形式の主題識別子、ランダムなurnで被験者を識別する

3.2.8. Aliases Identifier Format

3.2.8. エイリアス識別子形式

The Aliases Identifier Format describes a subject that is identified with a list of different Subject Identifiers. It is intended for use when a variety of identifiers have been shared with the party that will be interpreting the Subject Identifier, and it is unknown which of those identifiers they will recognize or support. Subject Identifiers in this format MUST contain an "identifiers" member whose value is a JSON array containing one or more Subject Identifiers. Each Subject Identifier in the array MUST identify the same entity. The "identifiers" member is REQUIRED and MUST NOT be null or empty. It MAY contain multiple instances of the same Identifier Format (e.g., multiple Email Subject Identifiers) but SHOULD NOT contain exact duplicates. This format is identified by the name "aliases".

エイリアス識別子形式は、異なる主題識別子のリストで識別される主題を記述します。さまざまな識別子が被験者の識別子を解釈する当事者と共有されている場合に使用することを目的としており、どの識別子が認識またはサポートするかは不明です。この形式のサブジェクト識別子には、値が1つ以上の被験者識別子を含むJSONアレイである「識別子」メンバーを含める必要があります。配列内の各被験者識別子は、同じエンティティを識別する必要があります。「識別子」メンバーが必要であり、nullまたは空にしてはなりません。同じ識別子形式の複数のインスタンス（たとえば、複数の電子メールサブジェクト識別子など）を含む場合がありますが、正確な複製を含めるべきではありません。この形式は、「エイリアス」という名前で識別されます。

"aliases" Subject Identifiers MUST NOT be nested, i.e., the "identifiers" member of an "aliases" Subject Identifier MUST NOT contain a Subject Identifier in the Aliases Identifier Format.

「エイリアス」サブジェクト識別子をネストする必要はありません。つまり、「エイリアス」サブジェクト識別子の「識別子」メンバーは、エイリアス識別子形式にサブジェクト識別子を含めてはなりません。

Below is a non-normative example Subject Identifier in the Aliases Identifier Format:

以下は、エイリアス識別子形式の非規範的な例の主題識別子です。

   {
     "format": "aliases",
     "identifiers": [
       {
         "format": "email",
         "email": "user@example.com"
       },
       {
         "format": "phone_number",
         "phone_number": "+12065550100"
       },
       {
         "format": "email",
         "email": "user+qualifier@example.com"
       }
     ]
   }

Figure 13: Example: Subject Identifier in the Aliases Identifier Format

図13：例：エイリアス識別子形式の主題識別子

4. Subject Identifiers in JWTs

4. JWTSの主題識別子

4.1. JWT "sub_id" Claim

4.1. jwt "sub_id"クレーム

The JWT "sub" Claim is defined in Section 4.1.2 of [RFC7519] as containing a string value; therefore, it cannot contain a Subject Identifier (which is a JSON object) as its value. This document defines the JWT "sub_id" Claim, in accordance with Section 4.2 of [RFC7519], as a common claim that identifies the JWT Subject using a Subject Identifier. When present, the value of this claim MUST be a Subject Identifier that identifies the subject of the JWT. The JWT "sub_id" Claim MAY be included in a JWT, whether or not the JWT "sub" Claim is present. When both the JWT "sub" and "sub_id" Claims are present in a JWT, they MUST identify the same subject, as a JWT has one and only one JWT Subject.

JWT「サブ」クレームは、[RFC7519]のセクション4.1.2で文字列値を含むと定義されています。したがって、値としてサブジェクト識別子（JSONオブジェクト）を含めることはできません。このドキュメントでは、[RFC7519]のセクション4.2に従って、JWT「Sub_ID」クレームを、被験者識別子を使用してJWT被験者を識別する一般的な主張として定義します。存在する場合、この請求の価値は、JWTの主題を識別する主題識別子でなければなりません。JWT「Sub_id」クレームは、JWT「サブ」請求が存在するかどうかにかかわらず、JWTに含まれる場合があります。JWTと「sub_id」クレームの両方がJWTに存在する場合、JWTには1つのJWTの主題が1つだけあるため、同じ主題を特定する必要があります。

When processing a JWT with both JWT "sub" and "sub_id" Claims, implementations MUST NOT rely on both claims to determine the JWT Subject. An implementation MAY attempt to determine the JWT Subject from one claim and fall back to using the other if it determines it does not understand the format of the first claim. For example, an implementation may attempt to use "sub_id" and fall back to using "sub" upon finding that "sub_id" contains a Subject Identifier with a format that is not recognized by the implementation.

JWTの「sub」と「sub_id」クレームの両方でJWTを処理する場合、実装はJWTの主題を決定するために両方のクレームに依存してはなりません。実装は、1つのクレームからJWTの被験者を決定し、最初のクレームの形式を理解していないと判断した場合、他の請求の使用に戻ることができます。たとえば、実装は「sub_id」を使用しようとし、「sub」を使用して「sub」を使用して、「sub_id」には、実装によって認識されない形式のサブジェクト識別子が含まれていることがわかります。

Below are non-normative examples of JWTs containing the JWT "sub_id" Claim:

以下は、JWT「sub_id」クレームを含むJWTの非規範的な例です。

   {
     "iss": "issuer.example.com",
     "sub_id": {
       "format": "email",
       "email": "user@example.com"
     }
   }

Figure 14: Example: JWT Containing a JWT "sub_id" Claim and No "sub" Claim

図14：例：jwt "sub_id"クレームを含むJWTおよび「サブ」請求なし

   {
     "iss": "issuer.example.com",
     "sub": "user@example.com",
     "sub_id": {
       "format": "email",
       "email": "user@example.com"
     }
   }

Figure 15: Example: JWT Where the JWT "sub" and "sub_id" Claims Identify the JWT Subject Using the Same Identifier

図15：例：JWTの「Sub」および「Sub_id」クレームが同じ識別子を使用してJWTの被験者を識別するJWT

   {
     "iss": "issuer.example.com",
     "sub": "liz@example.com",
     "sub_id": {
       "format": "email",
       "email": "elizabeth@example.com"
     }
   }

Figure 16: Example: JWT Where the JWT "sub" and "sub_id" Claims Identify the JWT Subject Using Different Values of the Same Identifier Type

図16：例：JWTの「Sub」および「Sub_id」クレームは、同じ識別子タイプの異なる値を使用してJWT被験者を識別します

   {
     "iss": "issuer.example.com",
     "sub": "user@example.com",
     "sub_id": {
       "format": "account",
       "uri": "acct:example.user@service.example.com"
     }
   }

Figure 17: Example: JWT Where the JWT "sub" and "sub_id" Claims Identify the JWT Subject via Different Types of Identifiers

図17：例：JWTがJWT「sub」および「sub_id」クレームが異なるタイプの識別子を介してJWTの主題を識別する場所

4.2. JWT "sub_id" Claim and "iss_sub" Subject Identifier

4.2. jwt "sub_id"クレームと「ins_sub "件名識別子

The JWT "sub_id" Claim MAY contain an "iss_sub" Subject Identifier. In this case, the JWT's "iss" Claim and the Subject Identifier's "iss" member MAY be different. For example, an OpenID Connect [OpenID.Core] client may construct such a JWT when sending JWTs back to its OpenID Connect Identity Provider in order to identify the JWT Subject using an identifier known to be understood by both parties. Similarly, the JWT's "sub" Claim and the Subject Identifier's "sub" member MAY be different. For example, this may be used by an OpenID Connect client to communicate the JWT Subject's local identifier at the client back to its Identity Provider.

JWT "sub_id"クレームには、「ISS_SUB」サブジェクト識別子が含まれる場合があります。この場合、JWTの「ISS」クレームと被験者の識別子の「ISS」メンバーが異なる場合があります。たとえば、OpenID Connect [OpenID.Core]クライアントは、JWTSをOpenID Connect Identityプロバイダーに送信するときにそのようなJWTを構築して、両当事者が理解することが知られている識別子を使用してJWTの被験者を識別することができます。同様に、JWTの「サブ」クレームと被験者の識別子の「サブ」メンバーが異なる場合があります。たとえば、これはOpenID Connectクライアントによって使用されて、JWT被験者のローカル識別子をクライアントのローカル識別子とIDプロバイダーに伝えます。

Below are non-normative examples of a JWT where the JWT "iss" Claim and "iss" member within the JWT "sub_id" Claim are the same and a JWT where they are different.

以下は、JWT「ISS」クレームとJWT "sub_id"請求内の「ISS」メンバーが同じであり、JWTが異なるJWTの非規範的な例です。

   {
     "iss": "issuer.example.com",
     "sub_id": {
       "format": "iss_sub",
       "iss": "issuer.example.com",
       "sub": "example_user"
     }
   }

Figure 18: Example: JWT with an "iss_sub" Subject Identifier Where the JWT Issuer and JWT Subject Issuer Are the Same

図18：例：JWT発行者とJWTの主題発行者が同じである「ISS_SUB」サブジェクト識別子を備えたJWT

   {
     "iss": "client.example.com",
     "sub_id": {
       "format": "iss_sub",
       "iss": "issuer.example.com",
       "sub": "example_user"
     }
   }

Figure 19: Example: JWT with an "iss_sub" Subject Identifier Where the JWT Issuer and JWT Subject Issuer Are Different

図19：例：JWT発行者とJWTの主題発行者が異なる「ISS_SUB」サブジェクト識別子を備えたJWT

   {
     "iss": "client.example.com",
     "sub": "client_user",
     "sub_id": {
       "format": "iss_sub",
       "iss": "issuer.example.com",
       "sub": "example_user"
     }
   }

Figure 20: Example: JWT with an "iss_sub" Subject Identifier Where the JWT "iss" and "sub" Claims Differ from the JWT Subject's "iss" and "sub" Members

図20：例：JWT「ISS」および「サブ」クレームがJWTの件名の「ISS」および「サブ」メンバーとは異なる「ISS_SUB」サブジェクト識別子を備えたJWT

5. Considerations for Specifications that Define Identifier Formats

5. 識別子形式を定義する仕様の考慮事項

Identifier Format definitions MUST NOT make assertions or declarations regarding the subject being identified by the Subject Identifier (e.g., an Identifier Format cannot be defined as specifically identifying human end users). Such statements are outside the scope of Identifier Formats and Subject Identifiers. Expanding that scope for some Identifier Formats but not others would harm interoperability because applications that depend on this expanded scope to disambiguate the subject type would be unable to use Identifier Formats that do not provide such rules.

識別子形式の定義は、被験者の識別子によって識別されている被験者に関する主張または宣言を行うべきではありません（たとえば、識別子形式は、人間のエンドユーザーを具体的に識別すると定義できません）。このようなステートメントは、識別子形式の範囲外とサブジェクト識別子の範囲外です。一部の識別子形式ではその範囲を拡張するが、他の識別子形式ではないことは相互運用性に害を及ぼすでしょう。なぜなら、この拡張された範囲に依存するアプリケーションは、サブジェクトタイプを明確にしても、そのようなルールを提供しない識別子形式を使用できないからです。

6. Privacy Considerations

6. プライバシーに関する考慮事項

6.1. Identifier Correlation

6.1. 識別子相関

The act of presenting two or more identifiers for a single subject together (e.g., within an "aliases" Subject Identifier or via the JWT "sub" and "sub_id" Claims) may communicate more information about the subject than was intended. For example, the entity to which the identifiers are presented now knows that both identifiers relate to the same subject and may be able to correlate additional data based on that. When transmitting Subject Identifiers, the transmitter SHOULD take care that they are only transmitting multiple identifiers together when it is known that the recipient already knows that the identifiers are related (e.g., because they were previously sent to the recipient as claims in an OpenID Connect ID Token) or when correlation is essential to the use case. Implementers must consider such risks, and specifications that use Subject Identifiers must provide appropriate privacy considerations of their own.

単一の被験者の2つ以上の識別子を一緒に提示する行為（たとえば、「エイリアス」サブジェクト識別子内またはJWT「サブ」および「sub_id」クレームを介して）は、意図したものよりも多くの情報を主題に関する情報を伝えることができます。たとえば、識別子が提示されるエンティティは、両方の識別子が同じ主題に関連しており、それに基づいて追加のデータを相関させることができることを知っています。被験者の識別子を送信する場合、送信機は、受信者が識別子が関連していることをすでに知っていることがわかっている場合に、複数の識別子を一緒に送信していることに注意する必要があります（例えば、OpenID Connect IDのクレームとして以前に受信者に送信されたためトークン）またはユースケースに相関が不可欠な場合。実装者はそのようなリスクを考慮する必要があり、サブジェクト識別子を使用する仕様は、独自の適切なプライバシーに関する考慮事項を提供する必要があります。

The considerations described in Section 6 of [RFC8417] also apply when Subject Identifiers are used within SETs. The considerations described in Section 12 of [RFC7519] also apply when Subject Identifiers are used within JWTs.

[RFC8417]のセクション6で説明されている考慮事項は、被験者の識別子がセット内で使用される場合にも適用されます。[RFC7519]のセクション12で説明されている考慮事項は、JWTS内で被験者の識別子が使用される場合にも適用されます。

7. Security Considerations

7. セキュリティに関する考慮事項

This specification does not define any mechanism for ensuring the confidentiality or integrity of a Subject Identifier. Where such properties are required, implementations MUST use mechanisms provided by the containing format (e.g., integrity protecting SETs or JWTs using JSON Web Signature (JWS) [RFC7515]) or at the transport layer or other layer in the application stack (e.g., using TLS [RFC8446]).

この仕様は、被験者識別子の機密性または完全性を確保するためのメカニズムを定義しません。そのようなプロパティが必要な場合、実装は、含有形式（たとえば、JSON Web署名（JWS）[RFC7515]を使用してセットまたはJWTを保護する整合性）またはアプリケーションスタックの輸送層またはその他の層（例えば、JWTを保護する」（例えば、JWTを保護するメカニズムを使用する必要があります（例：TLS [RFC8446]）。

Further considerations regarding confidentiality and integrity of SETs can be found in Section 5.1 of [RFC8417].

セットの機密性と完全性に関するさらなる考慮事項は、[RFC8417]のセクション5.1に記載されています。

8. IANA Considerations

8. IANAの考慮事項

8.1. Security Event Identifier Formats Registry

8.1. セキュリティイベント識別子フォーマットレジストリ

This document defines Identifier Formats, for which IANA has created and maintains a new registry titled "Security Event Identifier Formats". Initial values for the "Security Event Identifier Formats" registry are given in Section 3. Future assignments are to be made through the Specification Required registration policy [BCP26] and shall follow the template presented in Section 8.1.1.

このドキュメントは、IANAが「セキュリティイベント識別子形式」というタイトルの新しいレジストリを作成および維持している識別子形式を定義しています。「セキュリティイベント識別子フォーマット」レジストリの初期値は、セクション3に記載されています。将来の割り当ては、仕様が必要な登録ポリシー[BCP26]を通じて行われ、セクション8.1.1で提示されたテンプレートに従うものとします。

It is suggested that multiple designated experts be appointed who are able to represent the perspectives of different applications using this specification in order to enable broadly informed review of registration decisions.

登録決定の広く情報に基づいたレビューを可能にするために、この仕様を使用してさまざまなアプリケーションの視点を表現できる複数の指定された専門家が任命されることが提案されています。

8.1.1. Registration Template

8.1.1. 登録テンプレート

Format Name:

フォーマット名：

The name of the Identifier Format, as described in Section 3. The name MUST be an ASCII string consisting only of lowercase characters ("a" - "z"), digits ("0" - "9"), underscores ("_"), and hyphens ("-") and SHOULD NOT exceed 20 characters in length.

セクション3で説明されているように、識別子形式の名前は、小文字（ "a" - "z"）、桁（ "0" - "9"）のみで構成されるASCII文字列でなければなりません。"）、およびHyphens（" - "）、長さ20文字を超えてはなりません。

Format Description:

形式の説明：

A brief description of the Identifier Format.

識別子形式の簡単な説明。

Change Controller:

Change Controller：

For formats defined in documents published by the IETF or its working groups, list "IETF". For all other formats, list the name of the party responsible for the registration. Contact information, such as mailing address, email address, or phone number, must also be provided.

IETFまたはそのワーキンググループによって公開されたドキュメントで定義された形式については、「IETF」をリストします。他のすべての形式については、登録を担当する当事者の名前をリストします。郵送先住所、メールアドレス、電話番号などの連絡先情報も提供する必要があります。

Reference:

参照：

A reference to the document or documents that define the Identifier Format. The reference document(s) MUST specify the name, format, and meaning of each member that may occur within a Subject Identifier of the defined format as well as whether each member is optional, required, or conditional and the circumstances under which these optional or conditional fields would be used. URIs that can be used to retrieve copies of each document SHOULD be included.

識別子形式を定義するドキュメントまたはドキュメントへの参照。参照ドキュメントは、定義された形式のサブジェクト識別子内で発生する可能性のある各メンバーの名前、形式、および意味を指定する必要があります。条件付きフィールドが使用されます。各ドキュメントのコピーを取得するために使用できるURIを含める必要があります。

8.1.2. Initial Registry Contents

8.1.2. 初期レジストリコンテンツ

8.1.2.1. Account Identifier Format

8.1.2.1. アカウント識別子形式

Format Name:

フォーマット名：

account

アカウント口座会計記事付け出し付出し占むみなす記録勘定書き直話

Format Description:

形式の説明：

Subject Identifier based on "acct" URI

「ACCT」URIに基づくサブジェクト識別子

Change Controller:

Change Controller：

IETF

Reference:

参照：

Section 3 of RFC 9493

RFC 9493のセクション3

8.1.2.2. Email Identifier Format

8.1.2.2. 電子メール識別子形式

Format Name:

フォーマット名：

Eメール

Format Description:

形式の説明：

Subject Identifier based on an email address

メールアドレスに基づくサブジェクト識別子

Change Controller:

Change Controller：

IETF

Reference:

参照：

Section 3 of RFC 9493

RFC 9493のセクション3

8.1.2.3. Issuer and Subject Identifier Format

8.1.2.3. 発行者および主題識別子形式

Format Name:

フォーマット名：

iss_sub

ISS_SUB

Format Description:

形式の説明：

Subject Identifier based on an issuer and subject

発行者と被験者に基づくサブジェクト識別子

Change Controller:

Change Controller：

IETF

Reference:

参照：

Section 3 of RFC 9493

RFC 9493のセクション3

8.1.2.4. Opaque Identifier Format

8.1.2.4. 不透明な識別子形式

Format Name:

フォーマット名：

opaque

不透明オペーク暗黒闇

Format Description:

形式の説明：

Subject Identifier based on an opaque string

不透明な文字列に基づくサブジェクト識別子

Change Controller:

Change Controller：

IETF

Reference:

参照：

Section 3 of RFC 9493

RFC 9493のセクション3

8.1.2.5. Phone Number Identifier Format

8.1.2.5. 電話番号識別子形式

Format Name:

フォーマット名：

phone_number

電話番号

Format Description:

形式の説明：

Subject Identifier based on a phone number

電話番号に基づくサブジェクト識別子

Change Controller:

Change Controller：

IETF

Reference:

参照：

Section 3 of RFC 9493

RFC 9493のセクション3

8.1.2.6. Decentralized Identifier Format

8.1.2.6. 分散型識別子形式

Format Name:

フォーマット名：

did

した

Format Description:

形式の説明：

Subject Identifier based on a decentralized identifier (DID)

分散型識別子に基づくサブジェクト識別子（DID）

Change Controller:

Change Controller：

IETF

Reference:

参照：

Section 3 of RFC 9493

RFC 9493のセクション3

8.1.2.7. Uniform Resource Identifier Format

8.1.2.7. 均一なリソース識別子形式

Format Name:

フォーマット名：

uri

Format Description:

形式の説明：

Subject Identifier based on a Uniform Resource Identifier (URI)

均一なリソース識別子（URI）に基づくサブジェクト識別子

Change Controller:

Change Controller：

IETF

Reference:

参照：

Section 3 of RFC 9493

RFC 9493のセクション3

8.1.2.8. Aliases Identifier Format

8.1.2.8. エイリアス識別子形式

Format Name:

フォーマット名：

aliases

エイリアス

Format Description:

形式の説明：

Subject Identifier that groups together multiple different Subject Identifiers for the same subject

同じ主題の複数の異なる被験者識別子をグループ化する被験者識別子

Change Controller:

Change Controller：

IETF

Reference:

参照：

Section 3 of RFC 9493

RFC 9493のセクション3

8.1.3. Guidance for Expert Reviewers

8.1.3. 専門家のレビュアーのガイダンス

The Expert Reviewer is expected to review the documentation referenced in a registration request to verify its completeness. The Expert Reviewer must base their decision to accept or reject the request on a fair and impartial assessment of the request. If the Expert Reviewer has a conflict of interest, such as being an author of a defining document referenced by the request, they must recuse themselves from the approval process for that request.

専門家のレビュアーは、登録要求で参照されているドキュメントを確認して、その完全性を確認することが期待されています。専門家のレビュアーは、リクエストの公正かつ公平な評価に関する要求を受け入れるか拒否する決定を下す必要があります。専門家のレビュアーが、リクエストによって参照される定義文書の著者であるなど、利益相反がある場合、そのリクエストの承認プロセスから自分自身を拒否しなければなりません。

Identifier Formats need not be generally applicable and may be highly specific to a particular domain; it is expected that formats may be registered for niche or industry-specific use cases. The Expert Reviewer should focus on whether the format is thoroughly documented and whether its registration will promote or harm interoperability. In most cases, the Expert Reviewer should not approve a request if the registration would contribute to confusion or amount to a synonym for an existing format.

識別子形式は一般に適用できる必要はなく、特定のドメインに非常に固有の場合があります。フォーマットは、ニッチまたは業界固有のユースケースに登録される可能性があります。専門家のレビュアーは、フォーマットが徹底的に文書化されているかどうか、およびその登録が相互運用性を促進または損害するかどうかに焦点を当てる必要があります。ほとんどの場合、登録が混乱に貢献したり、既存の形式の同義語に貢献したりする場合、専門家のレビュアーはリクエストを承認してはなりません。

8.2. JSON Web Token Claims Registration

8.2. JSON Webトークンは登録を主張します

This document defines the JWT "sub_id" Claim, which IANA has registered in the "JSON Web Token Claims" registry [IANA.JWT.Claims] established by [RFC7519].

このドキュメントでは、IANAが[RFC7519]によって確立された「JSON Webトークンクレーム」レジストリ[IANA.JWT.CLAIMS]に登録したJWT "Sub_id"クレームを定義します。

8.2.1. Registry Contents

8.2.1. レジストリコンテンツ

Claim Name:

クレーム名：

sub_id

Claim Description:

クレームの説明：

Subject Identifier

サブジェクト識別子

Change Controller:

Change Controller：

IETF

Reference:

参照：

Section 4.1 of RFC 9493

RFC 9493のセクション4.1

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

   [BCP26]    Best Current Practice 26,
              <https://www.rfc-editor.org/info/bcp26>.
              At the time of writing, this BCP comprises the following:

              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>.

   [DID]      Sporny, M., Ed., Guy, A., Ed., Sabadello, M., Ed., Reed,
              D., Ed., Longley, D., Steele, O., and C. Allen,
              "Decentralized Identifiers (DIDs) v1.0", July 2022,
              <https://www.w3.org/TR/did-core/>.

   [E164]     ITU-T, "E.164: The international public telecommunication
              numbering plan", ITU-T Recommendation E.164, November
              2010, <https://www.itu.int/rec/T-REC-E.164-201011-I/en>.

   [IANA.JWT.Claims]
              IANA, "JSON Web Token Claims",
              <https://www.iana.org/assignments/jwt>.

   [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>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/info/rfc5321>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [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>.

   [RFC7565]  Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565,
              DOI 10.17487/RFC7565, May 2015,
              <https://www.rfc-editor.org/info/rfc7565>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC8417]  Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari,
              "Security Event Token (SET)", RFC 8417,
              DOI 10.17487/RFC8417, July 2018,
              <https://www.rfc-editor.org/info/rfc8417>.

9.2. Informative References

9.2. 参考引用

   [OpenID.Core]
              Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0 incorporating
              errata set 1", November 2014,
              <https://openid.net/specs/openid-connect-core-1_0.html>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Acknowledgements

謝辞

The authors would like to thank the members of the IETF Security Events Working Group, as well as those of the OpenID Shared Signals and Events Working Group, whose work provided the original basis for this document. We would also like to acknowledge Aaron Parecki, Denis Pinkas, Justin Richer, Mike Jones, and other members of the working group for reviewing this document.

著者は、IETFセキュリティイベントワーキンググループのメンバーと、OpenID共有シグナルおよびイベントワーキンググループのメンバーに感謝したいと思います。また、このドキュメントをレビューするために、アーロン・パレッキ、デニス・ピンカス、ジャスティン・リッチャー、マイク・ジョーンズ、およびワーキンググループの他のメンバーに感謝します。

Authors' Addresses

著者のアドレス

   Annabelle Backman (editor)
   Amazon
   Email: richanna@amazon.com

   Marius Scurtescu
   Coinbase
   Email: marius.scurtescu@coinbase.com

   Prachi Jain
   Fastly
   Email: prachi.jain1288@gmail.com

RFC 9493 - Subject Identifiers for Security Event Tokens 日本語訳

Subject Identifiers for Security Event Tokens

セキュリティイベントトークンのサブジェクト識別子

Abstract

概要

Status of This Memo

本文書の位置付け

Copyright Notice

著作権表示

Table of Contents

目次

1. Introduction

1. はじめに

2. Notational Conventions

2. 表記規則

2.1. Definitions

2.1. 定義

3. Subject Identifiers

3. 主題識別子

3.1. Identifier Formats versus Principal Types

3.1. 識別子形式と主要なタイプ

3.2. Identifier Format Definitions

3.2. 識別子形式の定義

3.2.1. Account Identifier Format

3.2.1. アカウント識別子形式

3.2.2. Email Identifier Format

3.2.2. 電子メール識別子形式

3.2.2.1. Email Canonicalization

3.2.2.1. 電子メールの正規化

3.2.3. Issuer and Subject Identifier Format

3.2.3. 発行者および主題識別子形式

3.2.4. Opaque Identifier Format

3.2.4. 不透明な識別子形式

3.2.5. Phone Number Identifier Format

3.2.5. 電話番号識別子形式

3.2.6. Decentralized Identifier (DID) Format

3.2.6. 分散型識別子（DID）形式

3.2.7. Uniform Resource Identifier (URI) Format

3.2.7. 均一なリソース識別子（URI）形式

3.2.8. Aliases Identifier Format

3.2.8. エイリアス識別子形式

4. Subject Identifiers in JWTs

4. JWTSの主題識別子

4.1. JWT "sub_id" Claim

4.1. jwt "sub_id"クレーム

4.2. JWT "sub_id" Claim and "iss_sub" Subject Identifier

4.2. jwt "sub_id"クレームと「ins_sub "件名識別子

5. Considerations for Specifications that Define Identifier Formats

5. 識別子形式を定義する仕様の考慮事項

6. Privacy Considerations

6. プライバシーに関する考慮事項

6.1. Identifier Correlation

6.1. 識別子相関

7. Security Considerations

7. セキュリティに関する考慮事項

8. IANA Considerations

8. IANAの考慮事項

8.1. Security Event Identifier Formats Registry

8.1. セキュリティイベント識別子フォーマットレジストリ

8.1.1. Registration Template

8.1.1. 登録テンプレート

8.1.2. Initial Registry Contents

8.1.2. 初期レジストリコンテンツ

8.1.2.1. Account Identifier Format

8.1.2.1. アカウント識別子形式

8.1.2.2. Email Identifier Format

8.1.2.2. 電子メール識別子形式

8.1.2.3. Issuer and Subject Identifier Format

8.1.2.3. 発行者および主題識別子形式

8.1.2.4. Opaque Identifier Format

8.1.2.4. 不透明な識別子形式

8.1.2.5. Phone Number Identifier Format

8.1.2.5. 電話番号識別子形式

8.1.2.6. Decentralized Identifier Format

8.1.2.6. 分散型識別子形式

8.1.2.7. Uniform Resource Identifier Format

8.1.2.7. 均一なリソース識別子形式

8.1.2.8. Aliases Identifier Format

8.1.2.8. エイリアス識別子形式

8.1.3. Guidance for Expert Reviewers