Security Event Token (SET)

Abstract

概要

This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.

本仕様は Security Event Token (SET) のデータ構造を定義する。SET は、発行者の観点から見た主体 (subject) についての事実の陳述を記述する。これらの事実の陳述は、セキュリティ上の主体に対して直接起きた、またはその主体に関して起きたイベントを表す。たとえば、ある主体のために発行されたトークンの発行や失効についての陳述である。本仕様は、セキュリティおよびアイデンティティに関連するイベントを表現できるようにすることを意図している。SET は JSON Web Token (JWT) であり、任意で署名および/または暗号化できる。SET は HTTP などのプロトコルを介して配布できる。

1.Introduction and Overview

1.はじめにと概観

This specification defines an extensible Security Event Token (SET) data structure, which can be exchanged using protocols such as HTTP. The specification builds on the JSON Web Token (JWT) format [RFC7519] in order to provide a self-contained token that can be optionally signed using JSON Web Signature (JWS) [RFC7515] and/or encrypted using JSON Web Encryption (JWE) [RFC7516].

本仕様は、HTTP などのプロトコルを用いて交換できる、拡張可能な Security Event Token (SET) のデータ構造を定義する。本仕様は JSON Web Token (JWT) フォーマット [RFC7519] の上に構築されており、JSON Web Signature (JWS) [RFC7515] による署名および/または JSON Web Encryption (JWE) [RFC7516] による暗号化を任意で施せる自己完結型のトークンを提供する。

This specification profiles the use of JWT for the purpose of issuing SETs. This specification defines a base format used by profiling specifications to define actual events and their meanings. This specification uses non-normative example events to demonstrate how events can be constructed.

本仕様は、SET を発行する目的のために JWT の利用をプロファイルする。本仕様は、プロファイル仕様が実際のイベントとその意味を定義するために用いる基本フォーマットを定義する。本仕様は、イベントをどのように構成できるかを示すために、非規範的なイベントの例を用いる。

This specification is scoped to security- and identity-related events. While SETs may be used for other purposes, the specification only considers security and privacy concerns relevant to identity and personal information.

本仕様のスコープは、セキュリティおよびアイデンティティに関連するイベントである。SET は他の目的にも使い得るが、本仕様はアイデンティティおよび個人情報に関連するセキュリティとプライバシーの懸念のみを考慮する。

Security events are not commands issued between parties. A SET describes statements of fact from the perspective of an issuer about a subject (e.g., a web resource, token, IP address, the issuer itself). These statements of fact represent a logical event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. A security subject may be permanent (e.g., a user account) or temporary (e.g., an HTTP session) in nature. A state change could describe a direct change of entity state, an implicit change of state, or other higher-level security statements such as:

セキュリティイベントは、当事者間で発行されるコマンドではない。SET は、発行者の観点から見た主体 (たとえば Web リソース、トークン、IP アドレス、発行者自身) についての事実の陳述を記述する。これらの事実の陳述は、セキュリティ上の主体に対して直接起きた、またはその主体に関して起きた論理的なイベントを表す。たとえば、ある主体のために発行されたトークンの発行や失効についての陳述である。セキュリティ上の主体は、永続的なもの (たとえばユーザーアカウント) である場合も、一時的なもの (たとえば HTTP セッション) である場合もある。状態変化は、エンティティの状態の直接的な変化、暗黙的な状態の変化、あるいは次のようなより高レベルのセキュリティ上の陳述を記述し得る:

o The creation, modification, removal of a resource.

o リソースの作成、変更、削除。

o The resetting or suspension of an account.

o アカウントのリセットまたは停止。

o The revocation of a security token prior to its expiry.

o セキュリティトークンの有効期限前の失効。

o The logout of a user session.

o ユーザーセッションのログアウト。

o An indication that a user has been given control of an email identifier that was previously controlled by another user.

o 以前は別のユーザーが管理していたメール識別子の管理権が、あるユーザーに与えられたことの表示。

While subject state changes are often triggered by a user agent or security subsystem, the issuance and transmission of an event may occur asynchronously and in a back channel to the action that caused the change that generated the security event. Subsequently, a SET recipient, having received a SET, validates and interprets the received SET and takes its own independent actions, if any. For example, having been informed of a personal identifier being associated with a different security subject (e.g., an email address is being used by someone else), the SET recipient may choose to ensure that the new user is not granted access to resources associated with the previous user. Or, the SET recipient may not have any relationship with the subject, and no action is taken.

主体の状態変化はユーザーエージェントやセキュリティサブシステムによって引き起こされることが多いが、イベントの発行と送信は、セキュリティイベントを生じさせた変化の原因となった操作とは非同期に、かつバックチャネルで行われ得る。その後、SET を受け取った SET 受信者は、受け取った SET を検証・解釈し、必要であれば自身の独立した処置をとる。たとえば、ある個人識別子が別のセキュリティ上の主体に関連付けられた (たとえば、あるメールアドレスが別の誰かによって使われている) ことを通知された SET 受信者は、新しいユーザーに以前のユーザーに関連付けられたリソースへのアクセスが許可されないようにすることを選択し得る。あるいは、SET 受信者はその主体と何の関係も持たず、何の処置もとられないこともある。

While SET recipients will often take actions upon receiving SETs, security events cannot be assumed to be commands or requests. The intent of this specification is to define a syntax for statements of fact that SET recipients may interpret for their own purposes.

SET 受信者は SET を受け取ると処置をとることが多いが、セキュリティイベントをコマンドや要求と見なすことはできない。本仕様の意図は、SET 受信者が自身の目的のために解釈し得る、事実の陳述のための構文を定義することである。

1.1.Notational Conventions

1.1.表記規約

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] に記述されたとおりに解釈される。

For purposes of readability, examples are not URL encoded. Implementers MUST percent-encode URLs as described in Section 2.1 of [RFC3986].

可読性のため、例は URL エンコードされていない。実装者は [RFC3986] の 2.1 節に記述されたとおりに URL をパーセントエンコードしなければならない (MUST)。

Throughout this document, all figures may contain spaces and extra line-wrapping for readability and space limitations. Similarly, some URIs contained within examples have been shortened for space and readability reasons.

本文書全体を通じて、図はすべて可読性と紙面の制約のために空白や余分な改行を含むことがある。同様に、例に含まれる一部の URI は、紙面と可読性の理由で短縮されている。

1.2.Definitions

1.2.定義

The following definitions are used with SETs:

SET では次の定義を用いる:

Security Event Token (SET) A SET is a JWT [RFC7519] conforming to this specification.

Security Event Token (SET) SET とは、本仕様に準拠した JWT [RFC7519] である。

SET Issuer A service provider that creates SETs to be sent to other service providers known as SET recipients.

SET 発行者 (SET Issuer) SET 受信者と呼ばれる他のサービスプロバイダーに送るための SET を作成するサービスプロバイダー。

SET Recipient A SET recipient is an entity that receives SETs through some distribution method. A SET recipient is the same entity referred as a "recipient" in [RFC7519] or "receiver" in related specifications.

SET 受信者 (SET Recipient) SET 受信者とは、何らかの配布方法を通じて SET を受け取るエンティティである。SET 受信者は、[RFC7519] で「recipient」、関連仕様で「receiver」と呼ばれているものと同じエンティティである。

Subject A SET describes an event or state change that has occurred to a subject. A subject might, for instance, be a principal (e.g., Section 4.1.2 of [RFC7519]), a web resource, an entity such as an IP address, or the issuer of the SET.

主体 (Subject) SET は、主体に対して起きたイベントまたは状態変化を記述する。主体は、たとえばプリンシパル (たとえば [RFC7519] の 4.1.2 節)、Web リソース、IP アドレスのようなエンティティ、あるいは SET の発行者であり得る。

Event Identifier A member name for an element of the JSON object that is the value of the "events" claim in a SET. This member name MUST be a URI.

イベント識別子 (Event Identifier) SET の "events" クレームの値である JSON オブジェクトの要素のメンバー名。このメンバー名は URI でなければならない (MUST)。

Event Payload A member value for an element of the JSON object that is the value of the "events" claim in a SET. This member value MUST be a JSON object.

イベントペイロード (Event Payload) SET の "events" クレームの値である JSON オブジェクトの要素のメンバー値。このメンバー値は JSON オブジェクトでなければならない (MUST)。

Profiling Specification A specification that profiles the SET data structure to define one or more specific event types and their associated claims and processing rules.

プロファイル仕様 (Profiling Specification) SET のデータ構造をプロファイルして、1 つ以上の特定のイベント種別と、それに関連するクレームおよび処理規則を定義する仕様。

2.The Security Event Token (SET)

2.Security Event Token (SET)

A SET is a JWT [RFC7519] data structure that represents one or more related aspects of a security event that occurred to a subject. The JWT Claims Set in a SET has the following structure:

SET は、主体に対して起きたセキュリティイベントの 1 つ以上の関連する側面を表す JWT [RFC7519] のデータ構造である。SET の JWT クレームセットは次の構造を持つ:

o The top-level claims in the JWT Claims Set are called the SET "envelope". Some of these claims are present in every SET; others will be specific to particular SET profiles or profile families. Claims in the envelope SHOULD be registered in the "JSON Web Token Claims" registry [IANA.JWT.Claims] or be Public Claims or Private Claims, as defined in [RFC7519].

o JWT クレームセットのトップレベルのクレームを SET の「エンベロープ」と呼ぶ。これらのクレームの一部はすべての SET に存在し、他のものは特定の SET プロファイルまたはプロファイルファミリーに固有である。エンベロープ内のクレームは、「JSON Web Token Claims」レジストリ [IANA.JWT.Claims] に登録されているか、[RFC7519] で定義される Public Claims または Private Claims であるべきである (SHOULD)。

o Envelope claims that are profiled and defined in this specification are used to validate the SET and provide information about the event data included in the SET. The "events" claim contains the event identifiers and event-specific data expressed about the security subject. The envelope MAY include event- specific or profile-specific data. The "events" claim value MUST be a JSON object that contains at least one member.

o 本仕様でプロファイルされ定義されるエンベロープのクレームは、SET を検証し、SET に含まれるイベントデータについての情報を提供するために用いられる。"events" クレームは、セキュリティ上の主体について表明されるイベント識別子とイベント固有のデータを含む。エンベロープはイベント固有またはプロファイル固有のデータを含んでもよい (MAY)。"events" クレームの値は、少なくとも 1 つのメンバーを含む JSON オブジェクトでなければならない (MUST)。

o Each member of the "events" JSON object is a name/value pair. The JSON member name is a URI string value, which is the event identifier, and the corresponding value is a JSON object known as the event "payload". The payload JSON object contains claims that pertain to that event identifier and need not be registered as JWT claims. These claims are defined by the profiling specification that defines the event. An event with no payload claims SHALL be represented as the empty JSON object ("{}").

o "events" JSON オブジェクトの各メンバーは名前/値のペアである。JSON メンバー名はイベント識別子である URI 文字列値で、対応する値はイベントの「ペイロード」と呼ばれる JSON オブジェクトである。ペイロードの JSON オブジェクトは、そのイベント識別子に関するクレームを含み、JWT クレームとして登録する必要はない。これらのクレームは、そのイベントを定義するプロファイル仕様によって定義される。ペイロードのクレームを持たないイベントは、空の JSON オブジェクト ("{}") として表現するものとする (SHALL)。

o When multiple event identifiers are contained in a SET, they represent multiple aspects of the same state transition that occurred to the security subject. They are not intended to be used to aggregate distinct events about the same subject. Beyond this, the interpretation of SETs containing multiple event identifiers is out of scope for this specification; profiling specifications MAY define their own rules regarding their use of SETs containing multiple event identifiers, as described in Section 3. Possible uses of multiple values include, but are not limited to:

o 1 つの SET に複数のイベント識別子が含まれる場合、それらはセキュリティ上の主体に起きた同一の状態遷移の複数の側面を表す。同じ主体についての別個のイベントを集約するために用いることは意図していない。これ以上の、複数のイベント識別子を含む SET の解釈は本仕様のスコープ外である。プロファイル仕様は、3 節に記述するように、複数のイベント識別子を含む SET の利用について独自の規則を定義してもよい (MAY)。複数の値の用途としては、次のものが挙げられるが、これらに限らない:

* Values to provide classification information (e.g., threat type or level).

* 分類情報 (たとえば脅威の種類やレベル) を提供するための値。

* Additions to existing event representations.

* 既存のイベント表現への追加。

* Values used to link potential series of events.

* 一連のイベントになり得るものを関連付けるために用いる値。

* Specific-purpose event URIs used between particular SET issuers and SET recipients.

* 特定の SET 発行者と SET 受信者の間で用いられる特定目的のイベント URI。

2.1.Illustrative Examples

2.1.説明のための例

This section illustrates several possible uses of SETs through non- normative examples.

本節では、非規範的な例を通じて SET のいくつかの利用法を示す。

2.1.1.SCIM Example

2.1.1.SCIM の例

The following example shows the JWT Claims Set for a hypothetical System for Cross-domain Identity Management (SCIM) [RFC7644] password reset SET. Such a SET might be used by a receiver as a trigger to reset active user-agent sessions related to the identified user.

次の例は、仮想の System for Cross-domain Identity Management (SCIM) [RFC7644] パスワードリセット SET の JWT クレームセットを示す。このような SET は、識別されたユーザーに関連するアクティブなユーザーエージェントのセッションをリセットするトリガーとして受信者に利用され得る。

The JWT Claims Set usage consists of:

この JWT クレームセットの用法は次のとおりである:

o The "events" claim specifying the hypothetical SCIM URN ("urn:ietf:params:scim:event:passwordReset") for a password reset, and a second value, "https://example.com/scim/event/ passwordResetExt", that is used to provide additional event information such as the current count of resets.

o "events" クレームは、パスワードリセットのための仮想の SCIM URN ("urn:ietf:params:scim:event:passwordReset") と、現在のリセット回数などの追加のイベント情報を提供するために用いる 2 つ目の値 "https://example.com/scim/event/passwordResetExt" を指定している。

o The "iss" claim, denoting the SET issuer.

o "iss" クレームは SET 発行者を示す。

o The "sub" claim, specifying the SCIM resource URI that was affected.

o "sub" クレームは、影響を受けた SCIM リソースの URI を指定する。

o The "aud" claim, specifying the intended audiences for the event. (The syntax of the "aud" claim is defined in Section 4.1.3 of [RFC7519].)

o "aud" クレームは、イベントの意図された受信対象 (audience) を指定する。("aud" クレームの構文は [RFC7519] の 4.1.3 節で定義されている。)

The SET contains two event payloads:

この SET は 2 つのイベントペイロードを含む:

o The "id" claim represents SCIM's unique identifier for a subject.

o "id" クレームは、主体に対する SCIM の一意識別子を表す。

o The second payload identified by "https://example.com/scim/event/ passwordResetExt" and the payload claim "resetAttempts" conveys the current count of reset attempts. In this example, while the count is a simple factual statement for the issuer, the meaning of the value (a count) is up to the receiver. As an example, such a value might be used by the receiver to infer increasing risk.

o "https://example.com/scim/event/passwordResetExt" で識別される 2 つ目のペイロードと、そのペイロードクレーム "resetAttempts" は、現在のリセット試行回数を伝える。この例では、この回数は発行者にとっては単純な事実の陳述であるが、その値 (回数) の意味は受信者に委ねられる。一例として、このような値は受信者がリスクの増大を推測するために使われ得る。

In this example, the SCIM event indicates that a password has been updated and the current password reset count is 5. Notice that the value for "resetAttempts" is in the event payload of an event used to convey this information.

この例では、SCIM イベントはパスワードが更新されたこと、および現在のパスワードリセット回数が 5 であることを示している。"resetAttempts" の値は、この情報を伝えるために用いるイベントのイベントペイロード内にあることに注意されたい。

2.1.2.Logout Example

2.1.2.ログアウトの例

Here is another example JWT Claims Set for a security event token, this one for a Logout Token:

セキュリティイベントトークンの JWT クレームセットの別の例として、ログアウトトークンの例を示す:

Note that the above SET has an empty JSON object and uses the JWT claims "sub" and "sid" to identify the subject that was logged out. At the time of this writing, this example corresponds to the logout token defined in the OpenID Connect Back-Channel Logout 1.0 [OpenID.BackChannel] specification.

上記の SET は空の JSON オブジェクトを持ち、ログアウトされた主体を識別するために JWT クレーム "sub" と "sid" を用いていることに注意されたい。本文書の執筆時点で、この例は OpenID Connect Back-Channel Logout 1.0 [OpenID.BackChannel] 仕様で定義されるログアウトトークンに対応する。

2.1.3.Consent Example

2.1.3.同意の例

In the following example JWT Claims Set, a fictional medical service collects consent for medical actions and notifies other parties. The individual for whom consent is identified was originally authenticated via OpenID Connect. In this case, the issuer of the security event is an application rather than the OpenID provider:

次の JWT クレームセットの例では、架空の医療サービスが医療行為に対する同意を収集し、他の当事者に通知する。同意の対象として識別される個人は、元々 OpenID Connect を介して認証されている。この場合、セキュリティイベントの発行者は OpenID プロバイダーではなくアプリケーションである:

In the above example, the attribute "iss" contained within the payload for the event "https://openid.net/heart/specs/consent.html" refers to the issuer of the security subject ("sub") rather than the SET issuer "https://my.med.example.org". They are distinct from the top-level value of "iss", which always refers to the issuer of the event -- a medical consent service that is a relying party to the OpenID Provider.

上記の例では、イベント "https://openid.net/heart/specs/consent.html" のペイロード内に含まれる属性 "iss" は、SET 発行者 "https://my.med.example.org" ではなく、セキュリティ上の主体 ("sub") の発行者を指す。これらは、常にイベントの発行者、すなわち OpenID プロバイダーのリライングパーティである医療同意サービスを指すトップレベルの "iss" の値とは別物である。

2.1.4.RISC Example

2.1.4.RISC の例

The following example JWT Claims Set is for an account disabled event. At the time of this writing, this example corresponds to the account disabled event defined in the OpenID RISC Event Types 1.0 [OpenID.RISC.Events] specification.

次の JWT クレームセットの例は、アカウント無効化イベントのものである。本文書の執筆時点で、この例は OpenID RISC Event Types 1.0 [OpenID.RISC.Events] 仕様で定義されるアカウント無効化イベントに対応する。

Notice that parameters to the event are included in the event payload, in this case, the "reason" and "cause-time" values. The subject of the event is identified using the "subject" payload value, which itself is a JSON object.

イベントのパラメーター、この場合は "reason" と "cause-time" の値がイベントペイロードに含まれていることに注意されたい。イベントの主体は "subject" ペイロード値を用いて識別され、その値自体が JSON オブジェクトである。

2.2.Core SET Claims

2.2.SET のコアクレーム

The following claims from [RFC7519] are profiled for use in SETs:

[RFC7519] の次のクレームが SET での利用のためにプロファイルされる:

"iss" (Issuer) Claim As defined by Section 4.1.1 of [RFC7519], this claim contains a string identifying the service provider publishing the SET (the issuer). In some cases, the issuer of the SET will not be the issuer associated with the security subject of the SET. Therefore, implementers cannot assume that the issuers are the same unless the profiling specification specifies that they are for SETs conforming to that profile. This claim is REQUIRED.

"iss" (Issuer) クレーム [RFC7519] の 4.1.1 節の定義のとおり、このクレームは SET を公開するサービスプロバイダー (発行者) を識別する文字列を含む。場合によっては、SET の発行者は SET のセキュリティ上の主体に関連付けられた発行者とは異なる。したがって実装者は、プロファイル仕様がそのプロファイルに準拠する SET について両者が同一であると規定しない限り、発行者が同一であると仮定することはできない。このクレームは必須である (REQUIRED)。

"iat" (Issued At) Claim As defined by Section 4.1.6 of [RFC7519], this claim contains a value representing when the SET was issued. This claim is REQUIRED.

"iat" (Issued At) クレーム [RFC7519] の 4.1.6 節の定義のとおり、このクレームは SET が発行された時刻を表す値を含む。このクレームは必須である (REQUIRED)。

"jti" (JWT ID) Claim As defined by Section 4.1.7 of [RFC7519], this claim contains a unique identifier for the SET. The identifier MUST be unique within a particular event feed and MAY be used by clients to track whether a particular SET has already been received. This claim is REQUIRED.

"jti" (JWT ID) クレーム [RFC7519] の 4.1.7 節の定義のとおり、このクレームは SET の一意識別子を含む。この識別子は特定のイベントフィード内で一意でなければならず (MUST)、特定の SET をすでに受信済みかどうかを追跡するためにクライアントが用いてもよい (MAY)。このクレームは必須である (REQUIRED)。

"aud" (Audience) Claim As defined by Section 4.1.3 of [RFC7519], this claim contains one or more audience identifiers for the SET. This claim is RECOMMENDED.

"aud" (Audience) クレーム [RFC7519] の 4.1.3 節の定義のとおり、このクレームは SET の 1 つ以上の受信対象 (audience) 識別子を含む。このクレームは推奨である (RECOMMENDED)。

"sub" (Subject) Claim As defined by Section 4.1.2 of [RFC7519], this claim contains a StringOrURI value representing the principal that is the subject of the SET. This is usually the entity whose "state" was changed. For example:

"sub" (Subject) クレーム [RFC7519] の 4.1.2 節の定義のとおり、このクレームは SET の主体であるプリンシパルを表す StringOrURI 値を含む。これは通常、「状態」が変化したエンティティである。たとえば:

* an IP Address was added to a blacklist;

* ブラックリストに追加された IP アドレス。

* a URI representing a user resource that was modified; or,

* 変更されたユーザーリソースを表す URI。あるいは、

* a token identifier (e.g. "jti") for a revoked token.

* 失効したトークンのトークン識別子 (たとえば "jti")。

If used, the profiling specification MUST define the content and format semantics for the value. This claim is OPTIONAL, as the principal for any given profile may already be identified without the inclusion of a subject claim. Note that some SET profiles MAY choose to convey event subject information in the event payload (either using the "sub" member name or another name), particularly if the subject information is relative to issuer information that is also conveyed in the event payload, which may be the case for some identity SET profiles.

用いる場合、プロファイル仕様はその値の内容とフォーマットの意味を定義しなければならない (MUST)。任意のプロファイルにおけるプリンシパルは、subject クレームを含めなくてもすでに識別されている場合があるため、このクレームは任意である (OPTIONAL)。一部の SET プロファイルは、イベント主体の情報を ("sub" というメンバー名または別の名前を用いて) イベントペイロード内で伝えることを選択してもよい (MAY) ことに注意されたい。特に、主体の情報が同じくイベントペイロード内で伝えられる発行者の情報に対して相対的である場合がそうであり、一部のアイデンティティ SET プロファイルではそうなり得る。

"exp" (Expiration Time) Claim As defined by Section 4.1.4 of [RFC7519], this claim is the time after which the JWT MUST NOT be accepted for processing. In the context of a SET, however, this notion does not typically apply, since a SET represents something that has already occurred and is historical in nature. Therefore, its use is NOT RECOMMENDED. (Also, see Section 4.1 for additional reasons not to use the "exp" claim in some SET use cases.)

"exp" (Expiration Time) クレーム [RFC7519] の 4.1.4 節の定義のとおり、このクレームはその時刻以降は JWT を処理のために受け入れてはならない (MUST NOT) 時刻である。しかし SET の文脈では、SET はすでに起きたことを表しており本質的に過去のものであるため、この概念は通常当てはまらない。したがって、その利用は推奨されない (NOT RECOMMENDED)。(一部の SET のユースケースで "exp" クレームを使わないその他の理由については、4.1 節も参照のこと。)

The following new claims are defined by this specification:

本仕様は次の新しいクレームを定義する:

"events" (Security Events) Claim This claim contains a set of event statements that each provide information describing a single logical event that has occurred about a security subject (e.g., a state change to the subject). Multiple event identifiers with the same value MUST NOT be used. The "events" claim MUST NOT be used to express multiple independent logical events.

"events" (Security Events) クレーム このクレームは、セキュリティ上の主体に関して起きた単一の論理的なイベント (たとえば主体の状態変化) をそれぞれ記述する情報を提供するイベント陳述の集合を含む。同じ値を持つ複数のイベント識別子を用いてはならない (MUST NOT)。"events" クレームを、複数の独立した論理的なイベントを表現するために用いてはならない (MUST NOT)。

The value of the "events" claim is a JSON object whose members are name/value pairs whose names are URIs identifying the event statements being expressed. Event identifiers SHOULD be stable values (e.g., a permanent URL for an event specification). For each name present, the corresponding value MUST be a JSON object. The JSON object MAY be an empty object ("{}"), or it MAY be a JSON object containing data described by the profiling specification.

"events" クレームの値は JSON オブジェクトであり、そのメンバーは、表明されるイベント陳述を識別する URI を名前とする名前/値のペアである。イベント識別子は安定した値 (たとえばイベント仕様の恒久的な URL) であるべきである (SHOULD)。存在する各名前について、対応する値は JSON オブジェクトでなければならない (MUST)。その JSON オブジェクトは空のオブジェクト ("{}") でもよく (MAY)、プロファイル仕様で記述されるデータを含む JSON オブジェクトでもよい (MAY)。

"txn" (Transaction Identifier) Claim An OPTIONAL string value that represents a unique transaction identifier. In cases in which multiple related JWTs are issued, the transaction identifier claim can be used to correlate these related JWTs. Note that this claim can be used in JWTs that are SETs and also in JWTs using non-SET profiles.

"txn" (Transaction Identifier) クレーム 一意なトランザクション識別子を表す、任意の (OPTIONAL) 文字列値。関連する複数の JWT が発行される場合、トランザクション識別子クレームを用いてそれら関連する JWT を関連付けることができる。このクレームは、SET である JWT でも、SET 以外のプロファイルを用いる JWT でも使えることに注意されたい。

"toe" (Time of Event) Claim A value that represents the date and time at which the event occurred. This value is a NumericDate (see Section 2 of [RFC7519]). By omitting this claim, the issuer indicates that they are not sharing an event time with the recipient. (Note that in some use cases, the represented time might be approximate; statements about the accuracy of this field MAY be made by profiling specifications.) This claim is OPTIONAL.

"toe" (Time of Event) クレーム イベントが発生した日時を表す値。この値は NumericDate である ([RFC7519] の 2 節を参照)。このクレームを省略することで、発行者はイベント時刻を受信者と共有しないことを示す。(一部のユースケースでは、表される時刻は概算であることがあり、このフィールドの精度についての陳述はプロファイル仕様が行ってもよい (MAY) ことに注意されたい。) このクレームは任意である (OPTIONAL)。

2.3.Explicit Typing of SETs

2.3.SET の明示的な型付け

This specification registers the "application/secevent+jwt" media type, which can be used to indicate that the content is a SET. SETs MAY include this media type in the "typ" header parameter of the JWT representing the SET to explicitly declare that the JWT is a SET. This MUST be included if the SET could be used in an application context in which it could be confused with other kinds of JWTs.

本仕様は "application/secevent+jwt" メディアタイプを登録する。これは内容が SET であることを示すために使える。SET は、その JWT が SET であることを明示的に宣言するために、SET を表す JWT の "typ" ヘッダーパラメーターにこのメディアタイプを含めてもよい (MAY)。SET が他の種類の JWT と混同され得るアプリケーションの文脈で使われる可能性がある場合、これを含めなければならない (MUST)。

Per the definition of "typ" in Section 4.1.9 of [RFC7515], it is RECOMMENDED that the "application/" prefix be omitted. Therefore, the "typ" value used SHOULD be "secevent+jwt".

[RFC7515] の 4.1.9 節の "typ" の定義に従い、"application/" というプレフィックスは省略することが推奨される (RECOMMENDED)。したがって、用いる "typ" の値は "secevent+jwt" であるべきである (SHOULD)。

2.4.Security Event Token Construction

2.4.Security Event Token の構築

This section describes how to construct a SET.

本節では SET の構築方法を記述する。

The following is an example JWT Claims Set for a hypothetical SCIM SET:

次は、仮想の SCIM SET の JWT クレームセットの例である:

The JSON Claims Set is encoded per [RFC7519].

JSON クレームセットは [RFC7519] に従ってエンコードされる。

In this example, the SCIM SET claims are encoded in an unsecured JWT. The JOSE Header for this example is:

この例では、SCIM SET のクレームはセキュリティ保護されていない JWT (unsecured JWT) にエンコードされている。この例の JOSE ヘッダーは次のとおりである:

Base64url encoding (as defined by Section 2 of [RFC7515], including the omission of all trailing '=' characters) of the octets of the UTF-8 [RFC3629] representation of the JOSE Header yields:

JOSE ヘッダーの UTF-8 [RFC3629] 表現のオクテットを base64url エンコード ([RFC7515] の 2 節の定義のとおり、末尾の '=' 文字をすべて省略することを含む) すると、次が得られる:

The above example JWT Claims Set (with insignificant whitespace removed) is encoded as follows (with line breaks for display purposes only):

上記の JWT クレームセットの例 (意味のない空白を除去したもの) は次のようにエンコードされる (改行は表示上の都合によるものである):

The encoded JWS signature is the empty string.

エンコードされた JWS 署名は空文字列である。

Concatenating the three encoded parts (JOSE Header, JWT Claims Set, and JWS signature) in order with period ('.') characters between the parts yields this complete SET (with line breaks for display purposes only):

エンコードされた 3 つの部分 (JOSE ヘッダー、JWT クレームセット、JWS 署名) をこの順にピリオド ('.') 文字で区切って連結すると、次の完全な SET が得られる (改行は表示上の都合によるものである):

For the purpose of having a simpler example in Figure 6, an unsecured token is shown. When SETs are not signed or encrypted, other mechanisms such as TLS MUST be employed to provide integrity protection, confidentiality, and issuer authenticity, as needed by the application.

図 6 で例を簡潔にするため、セキュリティ保護されていないトークンを示している。SET が署名も暗号化もされていない場合、アプリケーションの必要に応じて、完全性保護、機密性、発行者の真正性を提供するために TLS などの他の仕組みを用いなければならない (MUST)。

When validation (i.e., auditing) or additional transmission security is required, JWS signing and/or JWE encryption MAY be used. To create and or validate a signed and/or encrypted SET, follow the instructions in Section 7 of [RFC7519].

検証 (すなわち監査) または追加の伝送セキュリティが必要な場合、JWS 署名および/または JWE 暗号化を用いてもよい (MAY)。署名および/または暗号化された SET を作成または検証するには、[RFC7519] の 7 節の手順に従う。

3.Requirements for SET Profiles

3.SET プロファイルの要件

Profiling specifications of this specification define actual SETs to be used in particular use cases. These profiling specifications define the syntax and semantics of SETs conforming to that SET profile and rules for validating those SETs. Profiling specifications SHOULD define syntax, semantics, subject identification, and validation.

本仕様のプロファイル仕様は、特定のユースケースで用いる実際の SET を定義する。これらのプロファイル仕様は、その SET プロファイルに準拠する SET の構文と意味、およびそれらの SET を検証する規則を定義する。プロファイル仕様は、構文、意味、主体の識別、検証を定義すべきである (SHOULD)。

Syntax The syntax of the SETs defined, including:

構文 定義される SET の構文。以下を含む:

Top-Level Claims Claims and values in the JWT Claims Set. Examples are claims defined by the JWT specification [RFC7519], this specification, and by the profiling specification.

トップレベルのクレーム JWT クレームセット内のクレームと値。例としては、JWT 仕様 [RFC7519]、本仕様、およびプロファイル仕様で定義されるクレームがある。

Event Payload The JSON data structure contents and format, containing event- specific information, if any (see Section 1.2).

イベントペイロード イベント固有の情報があれば、それを含む JSON データ構造の内容とフォーマット (1.2 節を参照)。

Semantics Defining the semantics of the SET contents for SETs utilizing the profile is equally important. Possibly most important is defining the procedures used to validate the SET issuer and to obtain the keys controlled by the issuer that were used for cryptographic operations used in the JWT representing the SET. For instance, some profiles may define an algorithm for retrieving the SET issuer's keys that uses the "iss" claim value as its input. Likewise, if the profile allows (or requires) that the JWT be unsecured, the means by which the integrity of the JWT is ensured MUST be specified.

意味 そのプロファイルを用いる SET について、SET の内容の意味を定義することも同様に重要である。おそらく最も重要なのは、SET 発行者を検証し、SET を表す JWT で用いられた暗号操作に使われた、発行者が管理する鍵を取得するための手順を定義することである。たとえば、一部のプロファイルは "iss" クレームの値を入力として SET 発行者の鍵を取得するアルゴリズムを定義し得る。同様に、プロファイルが JWT をセキュリティ保護なしとすることを許す (または要求する) 場合、JWT の完全性を保証する手段を規定しなければならない (MUST)。

Subject Identification Profiling specifications MUST define how the event subject is identified in the SET, as well as how to differentiate between the event subject's issuer and the SET issuer, if applicable. It is NOT RECOMMENDED for profiling specifications to use the "sub" claim in cases in which the subject is not globally unique and has a different issuer from the SET itself.

主体の識別 プロファイル仕様は、SET 内でイベントの主体をどのように識別するか、および該当する場合はイベント主体の発行者と SET 発行者をどのように区別するかを定義しなければならない (MUST)。主体がグローバルに一意でなく、かつ SET 自体とは異なる発行者を持つ場合に、プロファイル仕様が "sub" クレームを用いることは推奨されない (NOT RECOMMENDED)。

Validation Profiling specifications MUST clearly specify the steps that a recipient of a SET utilizing that profile MUST perform to validate that the SET is both syntactically and semantically valid.

検証 プロファイル仕様は、そのプロファイルを用いる SET の受信者が、その SET が構文的にも意味的にも有効であることを検証するために実行しなければならない (MUST) 手順を明確に規定しなければならない (MUST)。

Among the syntax and semantics of SETs that a profiling specification may define is whether the value of the "events" claim may contain multiple members, and what processing instructions are employed in the single- and multiple-valued cases for SETs conforming to that profile. Many valid choices are possible. For instance, some profiles might allow multiple event identifiers to be present and specify that any that are not understood by recipients be ignored, thus enabling extensibility. Other profiles might allow multiple event identifiers to be present but require that all be understood if the SET is to be accepted. Some profiles might require that only a single value be present. All such choices are within the scope of profiling specifications to define.

プロファイル仕様が定義し得る SET の構文と意味には、"events" クレームの値が複数のメンバーを含んでよいかどうか、およびそのプロファイルに準拠する SET について単一値の場合と複数値の場合にどのような処理手順を用いるかが含まれる。多くの有効な選択肢があり得る。たとえば、一部のプロファイルは複数のイベント識別子の存在を許し、受信者が理解できないものは無視すると規定することで、拡張性を実現するかもしれない。他のプロファイルは複数のイベント識別子の存在を許しつつ、SET を受け入れるにはすべてを理解できることを要求するかもしれない。単一の値のみの存在を要求するプロファイルもあり得る。こうした選択はすべて、プロファイル仕様が定義するスコープ内にある。

4.Preventing Confusion between SETs and Other JWTs

4.SET と他の JWT との混同の防止

Because [RFC7519] states that "all claims that are not understood by implementations MUST be ignored", there is a consideration that a SET might be confused with another kind of JWT from the same issuer. Unless this confusion is prevented, this might enable an attacker who possesses a SET to use it in a context in which another kind of JWT is expected, or vice versa. This section presents concrete techniques for preventing confusion between SETs and several other specific kinds of JWTs, as well as generic techniques for preventing possible confusion between SETs and other kinds of JWTs.

[RFC7519] は「実装が理解できないクレームはすべて無視しなければならない (MUST)」と述べているため、SET が同じ発行者による別の種類の JWT と混同され得るという考慮事項がある。この混同を防がない限り、SET を所持する攻撃者が、別の種類の JWT が期待される文脈でその SET を用いる、あるいはその逆が可能になるかもしれない。本節では、SET と他のいくつかの特定の種類の JWT との混同を防ぐ具体的な技法と、SET と他の種類の JWT との間で起こり得る混同を防ぐ汎用的な技法を示す。

4.1.Distinguishing SETs from ID Tokens

4.1.SET と ID トークンの区別

A SET might be confused with an ID Token [OpenID.Core] if a SET is mistakenly or maliciously used in a context requiring an ID Token. If a SET could otherwise be interpreted as a valid ID Token (because it includes the required claims for an ID Token and valid issuer and audience claim values for an ID Token), then that SET profile MUST require that the "exp" claim not be present in the SET. Because "exp" is a required claim in ID Tokens, valid ID Token implementations will reject such a SET if presented as if it were an ID Token.

SET が誤って、あるいは悪意をもって ID トークンを要する文脈で使われた場合、SET は ID トークン [OpenID.Core] と混同され得る。SET がそれ以外の点では有効な ID トークンとして解釈され得る (ID トークンに必須のクレームと、ID トークンとして有効な発行者および受信対象のクレーム値を含んでいる) 場合、その SET プロファイルは SET に "exp" クレームが存在しないことを要求しなければならない (MUST)。"exp" は ID トークンの必須クレームであるため、有効な ID トークン実装は、そのような SET が ID トークンとして提示されても拒否する。

Excluding "exp" from SETs that could otherwise be confused with ID Tokens is actually defense in depth. In any OpenID Connect contexts in which an attacker could attempt to substitute a SET for an ID Token, the SET would actually already be rejected as an ID Token because it would not contain the correct "nonce" claim value for the ID Token to be accepted in contexts for which substitution is possible.

ID トークンと混同され得る SET から "exp" を除外するのは、実際には多層防御である。攻撃者が ID トークンの代わりに SET を差し込もうと試み得る OpenID Connect のあらゆる文脈において、差し替えが可能な文脈で ID トークンが受け入れられるために必要な正しい "nonce" クレーム値を SET は含まないため、SET は実際にはすでに ID トークンとして拒否されるはずである。

Note that the use of explicit typing, as described in Section 2.3, will not achieve disambiguation between ID Tokens and SETs, as the ID Token validation rules do not use the "typ" header parameter value.

2.3 節で記述する明示的な型付けを用いても、ID トークンの検証規則は "typ" ヘッダーパラメーターの値を用いないため、ID トークンと SET の曖昧さは解消されないことに注意されたい。

4.2.Distinguishing SETs from Access Tokens

4.2.SET とアクセストークンの区別

OAuth 2.0 [RFC6749] defines access tokens as being opaque. Nonetheless, some implementations implement access tokens as JWTs. Because the structure of these JWTs is implementation specific, ensuring that a SET cannot be confused with such an access token is, therefore, also implementation specific, generally. Nonetheless, it is recommended that SET profiles employ the following strategies to prevent possible substitutions of SETs for access tokens in contexts in which that might be possible:

OAuth 2.0 [RFC6749] はアクセストークンを不透明なものと定義している。それにもかかわらず、一部の実装はアクセストークンを JWT として実装している。これらの JWT の構造は実装固有であるため、SET がそのようなアクセストークンと混同されないことを保証することも、したがって一般に実装固有である。それでもなお、差し替えが可能な文脈でアクセストークンの代わりに SET が差し込まれることを防ぐために、SET プロファイルは次の戦略を採用することが推奨される:

o Prohibit use of the "exp" claim, as is done to prevent ID Token confusion.

o ID トークンとの混同を防ぐために行うのと同様に、"exp" クレームの使用を禁止する。

o Where possible, use a separate "aud" claim value to distinguish between the SET recipient and the protected resource that is the audience of an access token.

o 可能であれば、SET 受信者と、アクセストークンの受信対象である保護リソースを区別するために、別の "aud" クレーム値を用いる。

o Modify access token validation systems to check for the presence of the "events" claim as a means to detect security event tokens. This is particularly useful if the same endpoint may receive both types of tokens.

o セキュリティイベントトークンを検出する手段として、"events" クレームの存在をチェックするようにアクセストークンの検証システムを変更する。これは、同じエンドポイントが両方の種類のトークンを受け取り得る場合に特に有用である。

o Employ explicit typing, as described in Section 2.3, and modify access token validation systems to use the "typ" header parameter value.

o 2.3 節で記述する明示的な型付けを採用し、"typ" ヘッダーパラメーターの値を用いるようにアクセストークンの検証システムを変更する。

4.3.Distinguishing SETs from Other Kinds of JWTs

4.3.SET と他の種類の JWT の区別

JWTs are now being used in application areas beyond the identity applications in which they first appeared. For instance, the "Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm" [RFC8055] and "PASSporT: Personal Assertion Token" [RFC8225] specifications both define JWT profiles that use mostly or completely different sets of claims than are used by ID Tokens. If it would otherwise be possible for an attacker to substitute a SET for one of these (or other) kinds of JWTs, then the SET profile must be defined in such a way that any substituted SET will result in its rejection when validated as the intended kind of JWT.

JWT は現在、それが最初に登場したアイデンティティ用途を超えたアプリケーション領域で使われている。たとえば、「Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm」[RFC8055] と「PASSporT: Personal Assertion Token」[RFC8225] の両仕様は、ID トークンで用いられるものとは大部分または完全に異なるクレームの集合を用いる JWT プロファイルを定義している。攻撃者がこれら (または他) の種類の JWT の代わりに SET を差し込むことがそれ以外の方法で可能であるなら、差し込まれたいかなる SET も、意図された種類の JWT として検証された際に拒否されるように SET プロファイルを定義しなければならない。

The most direct way to prevent confusion is to employ explicit typing, as described in Section 2.3, and modify applicable token validation systems to use the "typ" header parameter value. This approach can be employed for new systems but may not be applicable to existing systems.

混同を防ぐ最も直接的な方法は、2.3 節で記述する明示的な型付けを採用し、該当するトークン検証システムを "typ" ヘッダーパラメーターの値を用いるように変更することである。この手法は新しいシステムには採用できるが、既存のシステムには適用できないことがある。

Another way to ensure that a SET is not confused with another kind of JWT is to have the JWT validation logic reject JWTs containing an "events" claim unless the JWT is intended to be a SET. This approach can be employed for new systems but may not be applicable to existing systems. Validating that the JWT has an "events" claim will be effective in preventing attackers from passing other kinds of JWTs off as SETs.

SET が他の種類の JWT と混同されないことを保証する別の方法は、JWT が SET であることを意図されていない限り、"events" クレームを含む JWT を JWT の検証ロジックが拒否するようにすることである。この手法は新しいシステムには採用できるが、既存のシステムには適用できないことがある。JWT が "events" クレームを持つことを検証することは、攻撃者が他の種類の JWT を SET として通そうとするのを防ぐのに効果的である。

For many use cases, the simplest way to prevent substitution is requiring that the SET not include claims that are required for the kind of JWT that might be the target of an attack. For example, for [RFC8055], the "sip_callid" claim could be omitted and for [RFC8225], the "orig" claim could be omitted.

多くのユースケースにおいて、差し替えを防ぐ最も単純な方法は、攻撃の標的となり得る種類の JWT に必須のクレームを SET が含まないことを要求することである。たとえば、[RFC8055] については "sip_callid" クレームを省略でき、[RFC8225] については "orig" クレームを省略できる。

In many contexts, simple measures such as these will accomplish the task, should confusion otherwise even be possible. Note that this topic is being explored in a more general fashion in "JSON Web Token Best Current Practices" [JWT-BCP]. The proposed best practices in that document may also be applicable for particular SET profiles and use cases.

多くの文脈では、そもそも混同が起こり得るとしても、こうした単純な対策で目的を達成できる。この話題は「JSON Web Token Best Current Practices」[JWT-BCP] でより一般的な形で検討されていることに注意されたい。同文書で提案されるベストプラクティスは、特定の SET プロファイルやユースケースにも適用できるかもしれない。

5.Security Considerations

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

5.1.Confidentiality and Integrity

5.1.機密性と完全性

SETs may contain sensitive information. Therefore, methods for distribution of events SHOULD require the use of a transport-layer security mechanism when distributing events. Parties MUST support TLS 1.2 [RFC5246] or a higher version and MAY support additional transport-layer mechanisms meeting its security requirements. When using TLS, the client MUST perform a TLS server certificate check, per [RFC6125]. Implementation security considerations for TLS can be found in "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [RFC7525].

SET は機微な情報を含み得る。したがって、イベントの配布方法は、イベントを配布する際にトランスポート層のセキュリティ機構の利用を要求すべきである (SHOULD)。当事者は TLS 1.2 [RFC5246] 以上のバージョンをサポートしなければならず (MUST)、そのセキュリティ要件を満たす追加のトランスポート層機構をサポートしてもよい (MAY)。TLS を用いる場合、クライアントは [RFC6125] に従って TLS サーバー証明書のチェックを実行しなければならない (MUST)。TLS の実装上のセキュリティに関する考慮事項は「Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)」[RFC7525] にある。

Security events distributed through third parties or that carry personally identifiable information MUST be encrypted using JWE [RFC7516] or secured for confidentiality by other means.

第三者を介して配布されるセキュリティイベント、または個人を識別できる情報を運ぶセキュリティイベントは、JWE [RFC7516] を用いて暗号化するか、他の手段で機密性を保護しなければならない (MUST)。

Unless integrity of the JWT is ensured by other means, it MUST be signed using JWS [RFC7515] by an issuer that is trusted to do so for the use case so that the SET can be authenticated and validated by the SET recipient.

JWT の完全性が他の手段で保証されない限り、SET 受信者が SET を認証・検証できるように、そのユースケースにおいて署名を行うことを信頼された発行者が JWS [RFC7515] を用いて署名しなければならない (MUST)。

5.2.Delivery

5.2.配送

This specification does not define a delivery mechanism for SETs. In addition to confidentiality and integrity (discussed above), implementers and profiling specifications must consider the consequences of delivery mechanisms that are not secure and/or not assured. For example, while a SET may be end-to-end secured using JWE encrypted SETs, without (mutual) TLS, there is no assurance that the correct endpoint received the SET and that it could be successfully processed.

本仕様は SET の配送機構を定義しない。機密性と完全性 (上述) に加えて、実装者とプロファイル仕様は、安全でない、および/または保証のない配送機構の帰結を考慮しなければならない。たとえば、SET は JWE で暗号化された SET を用いてエンドツーエンドで保護できるが、(相互) TLS がなければ、正しいエンドポイントが SET を受け取り、それを正常に処理できたという保証はない。

5.3.Sequencing

5.3.順序付け

This specification defines no means of ordering multiple SETs in a sequence. Depending on the type and nature of the events represented by SETs, order may or may not matter. For example, in provisioning, event order is critical -- an object cannot be modified before it is created. In other SET types, such as a token revocation, the order of SETs for revoked tokens does not matter. If, however, the event conveys a logged in or logged out status for a user subject, then order becomes important.

本仕様は、複数の SET を順序付ける手段を定義しない。SET が表すイベントの種類と性質によって、順序が重要な場合もそうでない場合もある。たとえばプロビジョニングではイベントの順序は極めて重要であり、オブジェクトは作成される前に変更することはできない。トークン失効のような他の SET 種別では、失効したトークンについての SET の順序は重要ではない。しかし、イベントがユーザー主体のログイン済みまたはログアウト済みの状態を伝えるなら、順序は重要になる。

Profiling specifications and implementers SHOULD take caution when using timestamps such as "iat" to define order. Distributed systems will have some amount of clock skew. Thus, time by itself will not guarantee order.

プロファイル仕様と実装者は、順序を定めるために "iat" などのタイムスタンプを用いる際には注意すべきである (SHOULD)。分散システムにはある程度のクロックのずれがある。したがって、時刻だけでは順序は保証されない。

Specifications profiling SET SHOULD define a mechanism for detecting order or sequence of events when the order matters. For example, the "txn" claim could contain an ordered value (e.g., a counter) that the issuer includes, although just as for timestamps, ensuring such ordering can be difficult in distributed systems.

SET をプロファイルする仕様は、順序が重要な場合にイベントの順序やシーケンスを検出する機構を定義すべきである (SHOULD)。たとえば、"txn" クレームに発行者が含める順序付きの値 (たとえばカウンター) を入れることができる。ただし、タイムスタンプの場合と同様に、分散システムでそのような順序付けを保証するのは難しい場合がある。

5.4.Timing Issues

5.4.タイミングの問題

When SETs are delivered asynchronously and/or out-of-band with respect to the original action that incurred the security event, it is important to consider that a SET might be delivered to a SET recipient in advance of or behind the process that caused the event. For example, a user having been required to log out and then log back in again, may cause a "token revoked" SET to be issued, typically causing the receiver to reset all active sessions at the receiver that are related to that user. If a revocation SET arrives at the same time as the user agent re-logs in, timing could cause problems by erroneously treating the new user session as logged out. Profiling specifications SHOULD be careful to consider both SET expression and timing issues. For example, it might be more appropriate to revoke a specific session or ID Token rather than a general logout statement about a "user". Alternatively, profiling specifications could use timestamps that allow new sessions to be started immediately after a stated logout event time.

セキュリティイベントを生じさせた元の操作に対して SET が非同期および/または帯域外で配送される場合、イベントを引き起こしたプロセスより先に、あるいは後に SET が SET 受信者に配送され得ることを考慮することが重要である。たとえば、ユーザーがログアウトしてから再度ログインすることを要求された場合、「トークン失効」SET が発行され、通常は受信者がそのユーザーに関連する受信者側のすべてのアクティブセッションをリセットすることになる。失効 SET がユーザーエージェントの再ログインと同時に到着した場合、タイミングによっては、新しいユーザーセッションを誤ってログアウト済みとして扱うという問題が生じ得る。プロファイル仕様は、SET の表現とタイミングの問題の両方を慎重に考慮すべきである (SHOULD)。たとえば、「ユーザー」についての一般的なログアウトの陳述ではなく、特定のセッションや ID トークンを失効させる方が適切かもしれない。あるいは、プロファイル仕様は、陳述されたログアウトイベントの時刻の直後に新しいセッションを開始できるようにするタイムスタンプを用いることもできる。

5.5.Preventing Confusion

5.5.混同の防止

Also, see Section 4 above for both additional security considerations and normative text on preventing SETs from being confused with other kinds of JWTs.

また、SET が他の種類の JWT と混同されることを防ぐための追加のセキュリティに関する考慮事項と規範的な文章については、上記の 4 節を参照のこと。

6.Privacy Considerations

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

If a SET needs to be retained for audit purposes, the signature can be used to provide verification of its authenticity.

監査目的で SET を保持する必要がある場合、署名をその真正性の検証に用いることができる。

SET issuers SHOULD attempt to specialize SETs so that their content is targeted to the specific business and protocol needs of the intended SET recipients.

SET 発行者は、SET の内容が意図された SET 受信者の特定の業務上およびプロトコル上の必要に合わせて絞り込まれるよう、SET を特化させるよう努めるべきである (SHOULD)。

When sharing personally identifiable information or information that is otherwise considered confidential to affected users, SET issuers and recipients should have the appropriate legal agreements and user consent and/or terms of service in place.

個人を識別できる情報、または影響を受けるユーザーにとって機密と見なされるその他の情報を共有する場合、SET 発行者と受信者は、適切な法的合意、ユーザーの同意、および/または利用規約を整えておくべきである。

The propagation of subject identifiers can be perceived as personally identifiable information. Where possible, SET issuers and recipients SHOULD devise approaches that prevent propagation -- for example, the passing of a salted hash value that requires the SET recipient to know the subject.

主体識別子の伝播は、個人を識別できる情報と見なされ得る。可能であれば、SET 発行者と受信者は伝播を防ぐ手法を考案すべきである (SHOULD)。たとえば、SET 受信者が主体を知っていることを要する、ソルト付きハッシュ値を渡す方法である。

In some cases, it may be possible for a SET recipient to correlate different events and thereby gain information about a subject that the SET issuer did not intend to share. For example, a SET recipient might be able to use "iat" values or highly precise "toe" values to determine that two otherwise un-relatable events actually relate to the same real-world event. The union of information from both events could allow a SET recipient to de-anonymize data or recognize that unrelated identifiers relate to the same individual. SET issuers SHOULD take steps to minimize the chance of event correlation, when such correlation would constitute a privacy violation. For instance, they could use approximate values for the "toe" claim or arbitrarily delay SET issuance, where such delay can be tolerated.

場合によっては、SET 受信者が異なるイベントを関連付け、それによって SET 発行者が共有を意図していなかった主体についての情報を得ることが可能かもしれない。たとえば、SET 受信者は "iat" の値や非常に精度の高い "toe" の値を用いて、それ以外の方法では関連付けられない 2 つのイベントが実際には同一の現実世界のイベントに関係することを突き止められるかもしれない。両イベントからの情報を合わせることで、SET 受信者はデータを非匿名化したり、無関係な識別子が同一の個人に関係することを認識したりできてしまう可能性がある。SET 発行者は、イベントの関連付けがプライバシー侵害となる場合、関連付けの可能性を最小化する措置をとるべきである (SHOULD)。たとえば、"toe" クレームに概算値を用いる、あるいは遅延が許容できる場合には SET の発行を任意に遅らせることができる。

7.IANA Considerations

7.IANA に関する考慮事項

7.1.JSON Web Token Claims Registration

7.1.JSON Web Token クレームの登録

IANA has registered the "events", "toe", and "txn" claims in the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims] established by [RFC7519].

IANA は、[RFC7519] によって設立された IANA の「JSON Web Token Claims」レジストリ [IANA.JWT.Claims] に "events"、"toe"、"txn" クレームを登録した。

7.1.1.Registry Contents

7.1.1.レジストリの内容

o Claim Name: "events"

o クレーム名: "events"

o Claim Description: Security Events

o クレームの説明: Security Events

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2.2 of [RFC8417]

o 仕様文書: [RFC8417] の 2.2 節

o Claim Name: "toe"

o クレーム名: "toe"

o Claim Description: Time of Event

o クレームの説明: Time of Event

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2.2 of [RFC8417]

o 仕様文書: [RFC8417] の 2.2 節

o Claim Name: "txn"

o クレーム名: "txn"

o Claim Description: Transaction Identifier

o クレームの説明: Transaction Identifier

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2.2 of [RFC8417]

o 仕様文書: [RFC8417] の 2.2 節

7.2.Structured Syntax Suffix Registration

7.2.構造化構文サフィックスの登録

IANA has registered the "+jwt" structured syntax suffix [RFC6838] in the "Structured Syntax Suffix" registry [IANA.StructuredSuffix] in the manner described in [RFC6838], which can be used to indicate that the media type is encoded as a JWT.

IANA は、[RFC6838] に記述された方法で「Structured Syntax Suffix」レジストリ [IANA.StructuredSuffix] に "+jwt" 構造化構文サフィックス [RFC6838] を登録した。これはメディアタイプが JWT としてエンコードされていることを示すために使える。

7.2.1.Registry Contents

7.2.1.レジストリの内容

o Name: JSON Web Token (JWT)

o 名前: JSON Web Token (JWT)

o +suffix: +jwt

o +suffix: +jwt

o References: Section 3 of [RFC7519], Section 7.2 of [RFC8417]

o 参照: [RFC7519] の 3 節、[RFC8417] の 7.2 節

o Encoding Considerations: binary; JWT values are encoded as a series of base64url-encoded values (with trailing '=' characters removed), some of which may be the empty string, separated by period ('.') characters.

o エンコーディングに関する考慮事項: binary。JWT の値は、ピリオド ('.') 文字で区切られた一連の base64url エンコード値 (末尾の '=' 文字は除去される) としてエンコードされ、その一部は空文字列であることがある。

o Interoperability Considerations: N/A

o 相互運用性に関する考慮事項: N/A

o Fragment Identifier Considerations: The syntax and semantics of fragment identifiers specified for +jwt SHOULD be as specified for "application/jwt". (At publication of this document, there is no fragment identification syntax defined for "application/jwt".)

o フラグメント識別子に関する考慮事項: +jwt に対して規定されるフラグメント識別子の構文と意味は、"application/jwt" に対して規定されるものと同じであるべきである (SHOULD)。(本文書の公開時点で、"application/jwt" に対するフラグメント識別の構文は定義されていない。)

The syntax and semantics for fragment identifiers for a specific "xxx/yyy+jwt" SHOULD be processed as follows:

特定の "xxx/yyy+jwt" に対するフラグメント識別子の構文と意味は、次のように処理すべきである (SHOULD):

For cases defined in +jwt where the fragment identifier resolves per the +jwt rules, process as specified in +jwt.

+jwt で定義されているケースで、フラグメント識別子が +jwt の規則に従って解決される場合は、+jwt で規定されるとおりに処理する。

For cases defined in +jwt where the fragment identifier does not resolve per the +jwt rules, process as specified in "xxx/yyy+jwt".

+jwt で定義されているケースで、フラグメント識別子が +jwt の規則に従って解決されない場合は、"xxx/yyy+jwt" で規定されるとおりに処理する。

7.3.Media Type Registration

7.3.メディアタイプの登録

7.3.1.Registry Contents

7.3.1.レジストリの内容

This section registers the "application/secevent+jwt" media type [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in [RFC6838], which can be used to indicate that the content is a SET.

本節は、[RFC6838] に記述された方法で「Media Types」レジストリ [IANA.MediaTypes] に "application/secevent+jwt" メディアタイプ [RFC2046] を登録する。これは内容が SET であることを示すために使える。

o Type name: application

o タイプ名: application

o Subtype name: secevent+jwt

o サブタイプ名: secevent+jwt

o Required parameters: N/A

o 必須パラメーター: N/A

o Optional parameters: N/A

o 任意パラメーター: N/A

o Encoding considerations: binary; A SET is a JWT; JWT values are encoded as a series of base64url-encoded values (with trailing '=' characters removed), some of which may be the empty string, separated by period ('.') characters.

o エンコーディングに関する考慮事項: binary。SET は JWT である。JWT の値は、ピリオド ('.') 文字で区切られた一連の base64url エンコード値 (末尾の '=' 文字は除去される) としてエンコードされ、その一部は空文字列であることがある。

o Security considerations: See Section 5 of [RFC8417]

o セキュリティに関する考慮事項: [RFC8417] の 5 節を参照

o Interoperability considerations: N/A

o 相互運用性に関する考慮事項: N/A

o Published specification: Section 2.3 of [RFC8417]

o 公開された仕様: [RFC8417] の 2.3 節

o Applications that use this media type: Applications that exchange SETs

o このメディアタイプを用いるアプリケーション: SET を交換するアプリケーション

o Fragment identifier considerations: N/A

o フラグメント識別子に関する考慮事項: N/A

o Additional information:

o 追加情報:

o Person & email address to contact for further information: Michael B. Jones, mbj@microsoft.com

o 詳細情報の連絡先となる人物とメールアドレス: Michael B. Jones, mbj@microsoft.com

o Intended usage: COMMON

o 意図される用途: COMMON

o Restrictions on usage: none

o 用途の制限: なし

o Author: Michael B. Jones, mbj@microsoft.com

o 著者: Michael B. Jones, mbj@microsoft.com

o Change controller: IESG

o 変更管理者: IESG

o Provisional registration? No

o 暫定登録か? いいえ

8.References

8.参考文献

8.1.Normative References

8.1.引用規格

8.2.Informative References

8.2.参考文献

Acknowledgments

謝辞

The editors would like to thank the members of the IETF SCIM working group, which began discussions of provisioning events starting with draft-hunt-scim-notify-00 in 2015. The editors would like to thank the participants in the IETF id-event mailing list, the Security Events working group, and related working groups for their contributions to this specification. The specification incorporates suggestions made by many people, including Annabelle Backman, John Bradley, Alissa Cooper, Ned Freed, Dick Hardt, Russ Housley, Benjamin Kaduk, Mirja Kuehlewind, Mark Lizar, Alexey Melnikov, Andrew Nash, Eric Rescorla, Adam Roach, Justin Richer, Nat Sakimura, Marius Scurtescu, Yaron Sheffer, and Martin Vigoureux.

編者は、2015 年の draft-hunt-scim-notify-00 を起点にプロビジョニングイベントの議論を始めた IETF SCIM ワーキンググループのメンバーに感謝する。編者は、IETF id-event メーリングリスト、Security Events ワーキンググループ、および関連ワーキンググループの参加者に、本仕様への貢献について感謝する。本仕様は、Annabelle Backman、John Bradley、Alissa Cooper、Ned Freed、Dick Hardt、Russ Housley、Benjamin Kaduk、Mirja Kuehlewind、Mark Lizar、Alexey Melnikov、Andrew Nash、Eric Rescorla、Adam Roach、Justin Richer、Nat Sakimura、Marius Scurtescu、Yaron Sheffer、Martin Vigoureux を含む多くの人々の提案を取り入れている。