JSON Web Token (JWT)

Abstract

概要

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

JSON Web Token (JWT) は、二者間で転送されるクレームを表現するための、コンパクトで URL セーフな手段である。JWT 内のクレームは JSON オブジェクトとしてエンコードされ、JSON Web Signature (JWS) 構造のペイロード、または JSON Web Encryption (JWE) 構造の平文として用いられる。これにより、クレームをデジタル署名するか、メッセージ認証コード (MAC) で完全性保護するか、および/または暗号化することができる。

1.Introduction

1.はじめに

JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. JWTs encode claims to be transmitted as a JSON [RFC7159] object that is used as the payload of a JSON Web Signature (JWS) [JWS] structure or as the plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization.

JSON Web Token (JWT) は、HTTP の Authorization ヘッダーや URI のクエリパラメーターのような、スペースに制約のある環境を想定したコンパクトなクレーム表現形式である。JWT は、送信されるクレームを JSON [RFC7159] オブジェクトとしてエンコードし、それを JSON Web Signature (JWS) [JWS] 構造のペイロード、または JSON Web Encryption (JWE) [JWE] 構造の平文として用いる。これにより、クレームをデジタル署名するか、メッセージ認証コード (MAC) で完全性保護するか、および/または暗号化することができる。JWT は常に JWS Compact Serialization または JWE Compact Serialization を用いて表現される。

The suggested pronunciation of JWT is the same as the English word "jot".

JWT の推奨される発音は、英単語の "jot" と同じである。

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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. The interpretation should only be applied when the terms appear in all capital letters.

本書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119] に記述されているとおりに解釈される。この解釈は、これらの語がすべて大文字で現れる場合にのみ適用される。

2.Terminology

2.用語

The terms "JSON Web Signature (JWS)", "Base64url Encoding", "Header Parameter", "JOSE Header", "JWS Compact Serialization", "JWS Payload", "JWS Signature", and "Unsecured JWS" are defined by the JWS specification [JWS].

用語 "JSON Web Signature (JWS)"、"Base64url Encoding"、"Header Parameter"、"JOSE Header"、"JWS Compact Serialization"、"JWS Payload"、"JWS Signature"、および "Unsecured JWS" は、JWS 仕様 [JWS] で定義されている。

The terms "JSON Web Encryption (JWE)", "Content Encryption Key (CEK)", "JWE Compact Serialization", "JWE Encrypted Key", and "JWE Initialization Vector" are defined by the JWE specification [JWE].

用語 "JSON Web Encryption (JWE)"、"Content Encryption Key (CEK)"、"JWE Compact Serialization"、"JWE Encrypted Key"、および "JWE Initialization Vector" は、JWE 仕様 [JWE] で定義されている。

The terms "Ciphertext", "Digital Signature", "Message Authentication Code (MAC)", and "Plaintext" are defined by the "Internet Security Glossary, Version 2" [RFC4949].

用語 "Ciphertext"、"Digital Signature"、"Message Authentication Code (MAC)"、および "Plaintext" は、"Internet Security Glossary, Version 2" [RFC4949] で定義されている。

These terms are defined by this specification:

以下の用語は本仕様で定義する。

JSON Web Token (JWT) A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the claims to be digitally signed or MACed and/or encrypted.

JSON Web Token (JWT): JWS または JWE にエンコードされた JSON オブジェクトとしてクレームの集合を表す文字列。これにより、クレームをデジタル署名または MAC 付与し、および/または暗号化することができる。

JWT Claims Set A JSON object that contains the claims conveyed by the JWT.

JWT Claims Set (JWT クレームセット): JWT によって伝達されるクレームを含む JSON オブジェクト。

Claim A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value.

Claim (クレーム): 主体 (subject) について主張される情報の一片。クレームは、クレーム名 (Claim Name) とクレーム値 (Claim Value) からなる名前/値のペアとして表現される。

Claim Name The name portion of a claim representation. A Claim Name is always a string.

Claim Name (クレーム名): クレーム表現の名前部分。クレーム名は常に文字列である。

Claim Value The value portion of a claim representation. A Claim Value can be any JSON value.

Claim Value (クレーム値): クレーム表現の値部分。クレーム値は任意の JSON 値をとりうる。

Nested JWT A JWT in which nested signing and/or encryption are employed. In Nested JWTs, a JWT is used as the payload or plaintext value of an enclosing JWS or JWE structure, respectively.

Nested JWT (ネストされた JWT): 入れ子の署名および/または暗号化が用いられている JWT。ネストされた JWT では、JWT がそれを包む JWS または JWE 構造のそれぞれペイロードまたは平文の値として用いられる。

Unsecured JWT A JWT whose claims are not integrity protected or encrypted.

Unsecured JWT (非保護 JWT): クレームが完全性保護も暗号化もされていない JWT。

Collision-Resistant Name A name in a namespace that enables names to be allocated in a manner such that they are highly unlikely to collide with other names. Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name.

Collision-Resistant Name (衝突耐性のある名前): 名前空間内の名前であって、他の名前と衝突する可能性が極めて低くなるように名前を割り当てられるもの。衝突耐性のある名前空間の例として、ドメイン名、ITU-T X.660 および X.670 勧告シリーズで定義されるオブジェクト識別子 (OID)、汎用一意識別子 (UUID) [RFC4122] がある。管理上委譲された名前空間を用いる場合、名前の定義者は、名前の定義に用いる名前空間の部分を自身が管理下に置いていることを確実にするために、合理的な予防措置を講じる必要がある。

StringOrURI A JSON string value, with the additional requirement that while arbitrary string values MAY be used, any value containing a ":" character MUST be a URI [RFC3986]. StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied.

StringOrURI: JSON 文字列値であり、任意の文字列値を用いてもよい (MAY) が、":" 文字を含む値は URI [RFC3986] でなければならない (MUST) という追加の要件を持つ。StringOrURI の値は、変換や正規化を一切適用せず、大文字小文字を区別する文字列として比較される。

NumericDate A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the IEEE Std 1003.1, 2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in which each day is accounted for by exactly 86400 seconds, other than that non-integer values can be represented. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.

NumericDate: 1970-01-01T00:00:00Z UTC から指定された UTC 日時までの秒数を、うるう秒を無視して表す JSON 数値。これは IEEE Std 1003.1, 2013 Edition [POSIX.1] の "Seconds Since the Epoch" の定義と等価であり、そこでは各日が正確に 86400 秒として計上される。ただし、非整数値を表現できる点が異なる。日時一般、および特に UTC の詳細については RFC 3339 [RFC3339] を参照のこと。

3.JSON Web Token (JWT) Overview

3.JSON Web Token (JWT) の概観

JWTs represent a set of claims as a JSON object that is encoded in a JWS and/or JWE structure. This JSON object is the JWT Claims Set. As per Section 4 of RFC 7159 [RFC7159], the JSON object consists of zero or more name/value pairs (or members), where the names are strings and the values are arbitrary JSON values. These members are the claims represented by the JWT. This JSON object MAY contain whitespace and/or line breaks before or after any JSON values or structural characters, in accordance with Section 2 of RFC 7159 [RFC7159].

JWT は、JWS および/または JWE 構造にエンコードされた JSON オブジェクトとしてクレームの集合を表す。この JSON オブジェクトが JWT クレームセットである。RFC 7159 [RFC7159] の 4 節に従い、この JSON オブジェクトはゼロ個以上の名前/値のペア (すなわちメンバー) からなり、名前は文字列、値は任意の JSON 値である。これらのメンバーが JWT によって表されるクレームである。この JSON オブジェクトは、RFC 7159 [RFC7159] の 2 節に従い、任意の JSON 値や構造文字の前後に空白および/または改行を含んでもよい (MAY)。

The member names within the JWT Claims Set are referred to as Claim Names. The corresponding values are referred to as Claim Values.

JWT クレームセット内のメンバー名をクレーム名と呼ぶ。対応する値をクレーム値と呼ぶ。

The contents of the JOSE Header describe the cryptographic operations applied to the JWT Claims Set. If the JOSE Header is for a JWS, the JWT is represented as a JWS and the claims are digitally signed or MACed, with the JWT Claims Set being the JWS Payload. If the JOSE Header is for a JWE, the JWT is represented as a JWE and the claims are encrypted, with the JWT Claims Set being the plaintext encrypted by the JWE. A JWT may be enclosed in another JWE or JWS structure to create a Nested JWT, enabling nested signing and encryption to be performed.

JOSE ヘッダーの内容は、JWT クレームセットに適用された暗号操作を記述する。JOSE ヘッダーが JWS 用のものである場合、JWT は JWS として表現され、クレームはデジタル署名または MAC 付与され、JWT クレームセットが JWS ペイロードとなる。JOSE ヘッダーが JWE 用のものである場合、JWT は JWE として表現され、クレームは暗号化され、JWT クレームセットが JWE によって暗号化される平文となる。JWT は別の JWE または JWS 構造に包んでネストされた JWT を作ることができ、これにより入れ子の署名と暗号化を行える。

A JWT is represented as a sequence of URL-safe parts separated by period ('.') characters. Each part contains a base64url-encoded value. The number of parts in the JWT is dependent upon the representation of the resulting JWS using the JWS Compact Serialization or JWE using the JWE Compact Serialization.

JWT は、ピリオド ('.') 文字で区切られた URL セーフな部分の並びとして表現される。各部分は base64url エンコードされた値を含む。JWT の部分の数は、結果として得られる JWS を JWS Compact Serialization で表現するか、JWE を JWE Compact Serialization で表現するかに依存する。

3.1.Example JWT

3.1.JWT の例

The following example JOSE Header declares that the encoded object is a JWT, and the JWT is a JWS that is MACed using the HMAC SHA-256 algorithm:

以下の JOSE ヘッダーの例は、エンコードされたオブジェクトが JWT であり、その JWT が HMAC SHA-256 アルゴリズムで MAC 付与された JWS であることを宣言している。

To remove potential ambiguities in the representation of the JSON object above, the octet sequence for the actual UTF-8 representation used in this example for the JOSE Header above is also included below. (Note that ambiguities can arise due to differing platform representations of line breaks (CRLF versus LF), differing spacing at the beginning and ends of lines, whether the last line has a terminating line break or not, and other causes. In the representation used in this example, the first line has no leading or trailing spaces, a CRLF line break (13, 10) occurs between the first and second lines, the second line has one leading space (32) and no trailing spaces, and the last line does not have a terminating line break.) The octets representing the UTF-8 representation of the JOSE Header in this example (using JSON array notation) are:

上記 JSON オブジェクトの表現における潜在的な曖昧さを取り除くため、この例で上記 JOSE ヘッダーに実際に用いられる UTF-8 表現のオクテット列も以下に示す。(曖昧さは、改行のプラットフォームごとの表現の違い (CRLF と LF)、行頭・行末の空白の違い、最終行が終端の改行を持つかどうか、その他の原因によって生じうることに注意。この例で用いる表現では、1 行目には行頭・行末の空白がなく、1 行目と 2 行目の間に CRLF 改行 (13, 10) があり、2 行目は行頭に空白 1 つ (32) を持ち行末の空白はなく、最終行は終端の改行を持たない。) この例の JOSE ヘッダーの UTF-8 表現を表すオクテット (JSON 配列記法を使用) は以下のとおりである。

[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32, 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]

[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32, 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]

Base64url encoding the octets of the UTF-8 representation of the JOSE Header yields this encoded JOSE Header value:

JOSE ヘッダーの UTF-8 表現のオクテットを base64url エンコードすると、次のエンコード済み JOSE ヘッダー値が得られる。

The following is an example of a JWT Claims Set:

以下は JWT クレームセットの例である。

The following octet sequence, which is the UTF-8 representation used in this example for the JWT Claims Set above, is the JWS Payload:

この例で上記 JWT クレームセットに用いられる UTF-8 表現である次のオクテット列が、JWS ペイロードである。

[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10, 32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56, 48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97, 109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111, 111, 116, 34, 58, 116, 114, 117, 101, 125] Base64url encoding the JWS Payload yields this encoded JWS Payload (with line breaks for display purposes only):

[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10, 32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56, 48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97, 109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111, 111, 116, 34, 58, 116, 114, 117, 101, 125]JWS ペイロードを base64url エンコードすると、次のエンコード済み JWS ペイロードが得られる (改行は表示のためだけのものである)。

Computing the MAC of the encoded JOSE Header and encoded JWS Payload with the HMAC SHA-256 algorithm and base64url encoding the HMAC value in the manner specified in [JWS] yields this encoded JWS Signature:

エンコード済み JOSE ヘッダーとエンコード済み JWS ペイロードの MAC を HMAC SHA-256 アルゴリズムで計算し、その HMAC 値を [JWS] で規定された方法で base64url エンコードすると、次のエンコード済み JWS 署名が得られる。

Concatenating these encoded parts in this order with period ('.') characters between the parts yields this complete JWT (with line breaks for display purposes only):

これらのエンコード済み部分をこの順に、部分の間にピリオド ('.') 文字を置いて連結すると、次の完全な JWT が得られる (改行は表示のためだけのものである)。

This computation is illustrated in more detail in Appendix A.1 of [JWS]. See Appendix A.1 for an example of an encrypted JWT.

この計算は [JWS] の付録 A.1 でより詳細に図解されている。暗号化された JWT の例については付録 A.1 を参照のこと。

4.JWT Claims

4.JWT クレーム

The JWT Claims Set represents a JSON object whose members are the claims conveyed by the JWT. The Claim Names within a JWT Claims Set MUST be unique; JWT parsers MUST either reject JWTs with duplicate Claim Names or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 ("The JSON Object") of ECMAScript 5.1 [ECMAScript].

JWT クレームセットは、そのメンバーが JWT によって伝達されるクレームである JSON オブジェクトを表す。JWT クレームセット内のクレーム名は一意でなければならない (MUST)。JWT パーサーは、重複するクレーム名を持つ JWT を拒否するか、ECMAScript 5.1 [ECMAScript] の 15.12 節 ("The JSON Object") で規定されているように、字句的に最後の重複メンバー名のみを返す JSON パーサーを用いるかのいずれかでなければならない (MUST)。

The set of claims that a JWT must contain to be considered valid is context dependent and is outside the scope of this specification. Specific applications of JWTs will require implementations to understand and process some claims in particular ways. However, in the absence of such requirements, all claims that are not understood by implementations MUST be ignored.

JWT が有効とみなされるために含んでいなければならないクレームの集合は文脈に依存し、本仕様の範囲外である。JWT の特定のアプリケーションは、実装に対して特定のクレームを特定の方法で理解し処理することを要求するだろう。しかし、そのような要件がない場合、実装が理解しないすべてのクレームは無視されなければならない (MUST)。

There are three classes of JWT Claim Names: Registered Claim Names, Public Claim Names, and Private Claim Names.

JWT のクレーム名には 3 つのクラスがある。登録済みクレーム名 (Registered Claim Names)、公開クレーム名 (Public Claim Names)、および非公開クレーム名 (Private Claim Names) である。

4.1.Registered Claim Names

4.1.登録済みクレーム名

The following Claim Names are registered in the IANA "JSON Web Token Claims" registry established by Section 10.1. None of the claims defined below are intended to be mandatory to use or implement in all cases, but rather they provide a starting point for a set of useful, interoperable claims. Applications using JWTs should define which specific claims they use and when they are required or optional. All the names are short because a core goal of JWTs is for the representation to be compact.

以下のクレーム名は、10.1 節で設立される IANA の "JSON Web Token Claims" レジストリに登録されている。以下に定義するクレームはいずれも、あらゆる場合に使用または実装が必須であることを意図したものではなく、むしろ有用で相互運用可能なクレームの集合の出発点を提供するものである。JWT を用いるアプリケーションは、どの特定のクレームを用いるか、またそれらがいつ必須でいつ任意であるかを定義すべきである。JWT の中心的な目標は表現をコンパクトにすることであるため、名前はすべて短い。

4.1.1."iss" (Issuer) Claim

4.1.1."iss" (発行者) クレーム

The "iss" (issuer) claim identifies the principal that issued the JWT. The processing of this claim is generally application specific. The "iss" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.

"iss" (issuer) クレームは、JWT を発行したプリンシパルを識別する。このクレームの処理は一般にアプリケーション固有である。"iss" の値は、StringOrURI 値を含む大文字小文字を区別する文字列である。このクレームの使用は OPTIONAL である。

4.1.2."sub" (Subject) Claim

4.1.2."sub" (主体) クレーム

The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The "sub" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.

"sub" (subject) クレームは、JWT の主体であるプリンシパルを識別する。JWT 内のクレームは通常、主体についての言明である。主体の値は、発行者の文脈においてローカルに一意となるようスコープされているか、またはグローバルに一意であるかのいずれかでなければならない (MUST)。このクレームの処理は一般にアプリケーション固有である。"sub" の値は、StringOrURI 値を含む大文字小文字を区別する文字列である。このクレームの使用は OPTIONAL である。

4.1.3."aud" (Audience) Claim

4.1.3."aud" (オーディエンス) クレーム

The "aud" (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim when this claim is present, then the JWT MUST be rejected. In the general case, the "aud" value is an array of case- sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case-sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL.

"aud" (audience) クレームは、JWT の意図された受信者を識別する。JWT を処理することを意図された各プリンシパルは、オーディエンスクレーム内の値によって自身を識別しなければならない (MUST)。このクレームが存在するときに、クレームを処理するプリンシパルが "aud" クレーム内の値によって自身を識別できない場合、JWT は拒否されなければならない (MUST)。一般的な場合、"aud" の値は、それぞれが StringOrURI 値を含む、大文字小文字を区別する文字列の配列である。JWT のオーディエンスが 1 つである特別な場合には、"aud" の値は StringOrURI 値を含む単一の大文字小文字を区別する文字列であってもよい (MAY)。オーディエンス値の解釈は一般にアプリケーション固有である。このクレームの使用は OPTIONAL である。

4.1.4."exp" (Expiration Time) Claim

4.1.4."exp" (有効期限) クレーム

The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim.

"exp" (expiration time) クレームは、その時刻以降は JWT を処理のために受け入れてはならない (MUST NOT) 有効期限を識別する。"exp" クレームの処理では、現在の日時が "exp" クレームに記載された有効期限の日時より前でなければならない (MUST)。

Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

実装者は、クロックのずれを考慮して、通常は数分を超えない程度の小さな猶予を設けてもよい (MAY)。その値は NumericDate 値を含む数値でなければならない (MUST)。このクレームの使用は OPTIONAL である。

4.1.5."nbf" (Not Before) Claim

4.1.5."nbf" (有効開始) クレーム

The "nbf" (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing. The processing of the "nbf" claim requires that the current date/time MUST be after or equal to the not-before date/time listed in the "nbf" claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

"nbf" (not before) クレームは、その時刻より前には JWT を処理のために受け入れてはならない (MUST NOT) 時刻を識別する。"nbf" クレームの処理では、現在の日時が "nbf" クレームに記載された有効開始日時以降でなければならない (MUST)。実装者は、クロックのずれを考慮して、通常は数分を超えない程度の小さな猶予を設けてもよい (MAY)。その値は NumericDate 値を含む数値でなければならない (MUST)。このクレームの使用は OPTIONAL である。

4.1.6."iat" (Issued At) Claim

4.1.6."iat" (発行時刻) クレーム

The "iat" (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.

"iat" (issued at) クレームは、JWT が発行された時刻を識別する。このクレームは JWT の経過時間を判定するために用いることができる。その値は NumericDate 値を含む数値でなければならない (MUST)。このクレームの使用は OPTIONAL である。

4.1.7."jti" (JWT ID) Claim

4.1.7."jti" (JWT ID) クレーム

The "jti" (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well. The "jti" claim can be used to prevent the JWT from being replayed. The "jti" value is a case- sensitive string. Use of this claim is OPTIONAL.

"jti" (JWT ID) クレームは、JWT の一意な識別子を提供する。識別子の値は、同じ値が誤って別のデータオブジェクトに割り当てられる確率が無視できるほど小さいことを保証する方法で割り当てられなければならない (MUST)。アプリケーションが複数の発行者を用いる場合、異なる発行者が生成する値の間でも衝突が防がれなければならない (MUST)。"jti" クレームは JWT のリプレイを防ぐために用いることができる。"jti" の値は大文字小文字を区別する文字列である。このクレームの使用は OPTIONAL である。

4.2.Public Claim Names

4.2.公開クレーム名

Claim Names can be defined at will by those using JWTs. However, in order to prevent collisions, any new Claim Name should either be registered in the IANA "JSON Web Token Claims" registry established by Section 10.1 or be a Public Name: a value that contains a Collision-Resistant Name. In each case, the definer of the name or value needs to take reasonable precautions to make sure they are in control of the part of the namespace they use to define the Claim Name.

クレーム名は、JWT を用いる者が自由に定義できる。しかし、衝突を防ぐため、新しいクレーム名は、10.1 節で設立される IANA の "JSON Web Token Claims" レジストリに登録されるか、または公開名 (Public Name)、すなわち衝突耐性のある名前を含む値であるかのいずれかであるべきである。いずれの場合も、名前または値の定義者は、クレーム名の定義に用いる名前空間の部分を自身が管理下に置いていることを確実にするために、合理的な予防措置を講じる必要がある。

4.3.Private Claim Names

4.3.非公開クレーム名

A producer and consumer of a JWT MAY agree to use Claim Names that are Private Names: names that are not Registered Claim Names (Section 4.1) or Public Claim Names (Section 4.2). Unlike Public Claim Names, Private Claim Names are subject to collision and should be used with caution.

JWT の生成者と消費者は、非公開名 (Private Name)、すなわち登録済みクレーム名 (4.1 節) でも公開クレーム名 (4.2 節) でもない名前をクレーム名として用いることに合意してもよい (MAY)。公開クレーム名とは異なり、非公開クレーム名は衝突の可能性があり、注意して用いるべきである。

5.JOSE Header

5.JOSE ヘッダー

For a JWT object, the members of the JSON object represented by the JOSE Header describe the cryptographic operations applied to the JWT and optionally, additional properties of the JWT. Depending upon whether the JWT is a JWS or JWE, the corresponding rules for the JOSE Header values apply.

JWT オブジェクトでは、JOSE ヘッダーが表す JSON オブジェクトのメンバーは、JWT に適用された暗号操作と、任意で JWT の追加の属性を記述する。JWT が JWS であるか JWE であるかに応じて、JOSE ヘッダー値に対する対応する規則が適用される。

This specification further specifies the use of the following Header Parameters in both the cases where the JWT is a JWS and where it is a JWE.

本仕様はさらに、JWT が JWS である場合と JWE である場合の両方において、以下のヘッダーパラメーターの使用を規定する。

5.1."typ" (Type) Header Parameter

5.1."typ" (タイプ) ヘッダーパラメーター

The "typ" (type) Header Parameter defined by [JWS] and [JWE] is used by JWT applications to declare the media type [IANA.MediaTypes] of this complete JWT. This is intended for use by the JWT application when values that are not JWTs could also be present in an application data structure that can contain a JWT object; the application can use this value to disambiguate among the different kinds of objects that might be present. It will typically not be used by applications when it is already known that the object is a JWT. This parameter is ignored by JWT implementations; any processing of this parameter is performed by the JWT application. If present, it is RECOMMENDED that its value be "JWT" to indicate that this object is a JWT. While media type names are not case sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations. Use of this Header Parameter is OPTIONAL.

[JWS] および [JWE] で定義される "typ" (type) ヘッダーパラメーターは、JWT アプリケーションがこの完全な JWT のメディアタイプ [IANA.MediaTypes] を宣言するために用いる。これは、JWT オブジェクトを含みうるアプリケーションのデータ構造の中に JWT でない値も存在しうる場合に JWT アプリケーションが用いることを意図しており、アプリケーションはこの値を用いて、存在しうる異なる種類のオブジェクトを区別できる。オブジェクトが JWT であることが既知である場合には、通常アプリケーションはこれを用いない。このパラメーターは JWT 実装には無視され、このパラメーターの処理はすべて JWT アプリケーションが行う。存在する場合、その値は、このオブジェクトが JWT であることを示すために "JWT" とすることが推奨される (RECOMMENDED)。メディアタイプ名は大文字小文字を区別しないが、レガシーな実装との互換性のため、"JWT" は常に大文字で綴ることが推奨される (RECOMMENDED)。このヘッダーパラメーターの使用は OPTIONAL である。

5.2."cty" (Content Type) Header Parameter

5.2."cty" (コンテンツタイプ) ヘッダーパラメーター

The "cty" (content type) Header Parameter defined by [JWS] and [JWE] is used by this specification to convey structural information about the JWT.

[JWS] および [JWE] で定義される "cty" (content type) ヘッダーパラメーターは、本仕様では JWT の構造に関する情報を伝えるために用いる。

In the normal case in which nested signing or encryption operations are not employed, the use of this Header Parameter is NOT RECOMMENDED. In the case that nested signing or encryption is employed, this Header Parameter MUST be present; in this case, the value MUST be "JWT", to indicate that a Nested JWT is carried in this JWT. While media type names are not case sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations. See Appendix A.2 for an example of a Nested JWT.

入れ子の署名または暗号化操作を用いない通常の場合、このヘッダーパラメーターの使用は推奨されない (NOT RECOMMENDED)。入れ子の署名または暗号化を用いる場合、このヘッダーパラメーターは存在しなければならず (MUST)、その場合、この JWT の中にネストされた JWT が運ばれていることを示すために、値は "JWT" でなければならない (MUST)。メディアタイプ名は大文字小文字を区別しないが、レガシーな実装との互換性のため、"JWT" は常に大文字で綴ることが推奨される (RECOMMENDED)。ネストされた JWT の例については付録 A.2 を参照のこと。

5.3.Replicating Claims as Header Parameters

5.3.ヘッダーパラメーターとしてのクレームの複製

In some applications using encrypted JWTs, it is useful to have an unencrypted representation of some claims. This might be used, for instance, in application processing rules to determine whether and how to process the JWT before it is decrypted.

暗号化された JWT を用いる一部のアプリケーションでは、一部のクレームの暗号化されていない表現を持つことが有用である。これはたとえば、JWT を復号する前にその JWT を処理するかどうか、またどのように処理するかを判断するアプリケーションの処理規則において用いられうる。

This specification allows claims present in the JWT Claims Set to be replicated as Header Parameters in a JWT that is a JWE, as needed by the application. If such replicated claims are present, the application receiving them SHOULD verify that their values are identical, unless the application defines other specific processing rules for these claims. It is the responsibility of the application to ensure that only claims that are safe to be transmitted in an unencrypted manner are replicated as Header Parameter values in the JWT.

本仕様は、JWE である JWT において、アプリケーションの必要に応じて、JWT クレームセットに存在するクレームをヘッダーパラメーターとして複製することを許容する。そのような複製されたクレームが存在する場合、それを受け取るアプリケーションは、これらのクレームについて他の特定の処理規則を定義していない限り、それらの値が同一であることを検証すべきである (SHOULD)。暗号化されずに送信しても安全なクレームのみが JWT 内のヘッダーパラメーター値として複製されることを確実にするのは、アプリケーションの責任である。

Section 10.4.1 of this specification registers the "iss" (issuer), "sub" (subject), and "aud" (audience) Header Parameter names for the purpose of providing unencrypted replicas of these claims in encrypted JWTs for applications that need them. Other specifications MAY similarly register other names that are registered Claim Names as Header Parameter names, as needed.

本仕様の 10.4.1 節は、暗号化された JWT においてこれらのクレームの暗号化されていない複製を必要とするアプリケーションのために、"iss" (issuer)、"sub" (subject)、および "aud" (audience) のヘッダーパラメーター名を登録する。他の仕様も同様に、必要に応じて、登録済みクレーム名である他の名前をヘッダーパラメーター名として登録してもよい (MAY)。

6.Unsecured JWTs

6.非保護 JWT

To support use cases in which the JWT content is secured by a means other than a signature and/or encryption contained within the JWT (such as a signature on a data structure containing the JWT), JWTs MAY also be created without a signature or encryption. An Unsecured JWT is a JWS using the "alg" Header Parameter value "none" and with the empty string for its JWS Signature value, as defined in the JWA specification [JWA]; it is an Unsecured JWS with the JWT Claims Set as its JWS Payload.

JWT の内容が JWT 内に含まれる署名および/または暗号化以外の手段 (JWT を含むデータ構造に対する署名など) で保護されるユースケースを支えるため、JWT は署名も暗号化もなしに作成されてもよい (MAY)。非保護 JWT は、JWA 仕様 [JWA] で定義されるように、"alg" ヘッダーパラメーター値 "none" を用い、JWS 署名値として空文字列を持つ JWS である。すなわち、JWT クレームセットを JWS ペイロードとする非保護 JWS である。

6.1.Example Unsecured JWT

6.1.非保護 JWT の例

The following example JOSE Header declares that the encoded object is an Unsecured JWT:

以下の JOSE ヘッダーの例は、エンコードされたオブジェクトが非保護 JWT であることを宣言している。

Base64url encoding the octets of the UTF-8 representation of the JOSE Header yields this encoded JOSE Header value:

JOSE ヘッダーの UTF-8 表現のオクテットを base64url エンコードすると、次のエンコード済み JOSE ヘッダー値が得られる。

The following is an example of a JWT Claims Set:

以下は JWT クレームセットの例である。

Base64url encoding the octets of the UTF-8 representation of the JWT Claims Set yields this encoded JWS Payload (with line breaks for display purposes only):

JWT クレームセットの UTF-8 表現のオクテットを base64url エンコードすると、次のエンコード済み JWS ペイロードが得られる (改行は表示のためだけのものである)。

The encoded JWS Signature is the empty string.

エンコード済み JWS 署名は空文字列である。

Concatenating these encoded parts in this order with period ('.') characters between the parts yields this complete JWT (with line breaks for display purposes only):

これらのエンコード済み部分をこの順に、部分の間にピリオド ('.') 文字を置いて連結すると、次の完全な JWT が得られる (改行は表示のためだけのものである)。

7.Creating and Validating JWTs

7.JWT の作成と検証

7.1.Creating a JWT

7.1.JWT の作成

To create a JWT, the following steps are performed. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.

JWT を作成するには、以下の手順を実行する。各手順の入力と出力の間に依存関係がない場合、手順の順序は重要ではない。

1. Create a JWT Claims Set containing the desired claims. Note that whitespace is explicitly allowed in the representation and no canonicalization need be performed before encoding.

1. 所望のクレームを含む JWT クレームセットを作成する。表現中の空白は明示的に許容されており、エンコード前に正規化を行う必要はないことに注意。

2. Let the Message be the octets of the UTF-8 representation of the JWT Claims Set.

2. JWT クレームセットの UTF-8 表現のオクテットをメッセージとする。

3. Create a JOSE Header containing the desired set of Header Parameters. The JWT MUST conform to either the [JWS] or [JWE] specification. Note that whitespace is explicitly allowed in the representation and no canonicalization need be performed before encoding.

3. 所望のヘッダーパラメーターの集合を含む JOSE ヘッダーを作成する。JWT は [JWS] または [JWE] 仕様のいずれかに適合しなければならない (MUST)。表現中の空白は明示的に許容されており、エンコード前に正規化を行う必要はないことに注意。

4. Depending upon whether the JWT is a JWS or JWE, there are two cases:

4. JWT が JWS であるか JWE であるかに応じて、2 つの場合がある。

* If the JWT is a JWS, create a JWS using the Message as the JWS Payload; all steps specified in [JWS] for creating a JWS MUST be followed.

* JWT が JWS である場合、メッセージを JWS ペイロードとして JWS を作成する。JWS の作成について [JWS] で規定されたすべての手順に従わなければならない (MUST)。

* Else, if the JWT is a JWE, create a JWE using the Message as the plaintext for the JWE; all steps specified in [JWE] for creating a JWE MUST be followed.

* そうでなく、JWT が JWE である場合、メッセージを JWE の平文として JWE を作成する。JWE の作成について [JWE] で規定されたすべての手順に従わなければならない (MUST)。

5. If a nested signing or encryption operation will be performed, let the Message be the JWS or JWE, and return to Step 3, using a "cty" (content type) value of "JWT" in the new JOSE Header created in that step.

5. 入れ子の署名または暗号化操作を行う場合は、その JWS または JWE をメッセージとし、手順 3 に戻って、その手順で新たに作成する JOSE ヘッダーに "cty" (content type) 値 "JWT" を用いる。

6. Otherwise, let the resulting JWT be the JWS or JWE.

6. そうでなければ、その JWS または JWE を結果の JWT とする。

7.2.Validating a JWT

7.2.JWT の検証

When validating a JWT, the following steps are performed. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. If any of the listed steps fail, then the JWT MUST be rejected -- that is, treated by the application as an invalid input.

JWT を検証する際には、以下の手順を実行する。各手順の入力と出力の間に依存関係がない場合、手順の順序は重要ではない。列挙された手順のいずれかが失敗した場合、JWT は拒否されなければならない (MUST)。すなわち、アプリケーションによって無効な入力として扱われなければならない。

1. Verify that the JWT contains at least one period ('.') character.

1. JWT が少なくとも 1 つのピリオド ('.') 文字を含むことを検証する。

2. Let the Encoded JOSE Header be the portion of the JWT before the first period ('.') character.

2. JWT の最初のピリオド ('.') 文字より前の部分をエンコード済み JOSE ヘッダーとする。

3. Base64url decode the Encoded JOSE Header following the restriction that no line breaks, whitespace, or other additional characters have been used.

3. 改行、空白、その他の追加文字が使われていないという制約に従って、エンコード済み JOSE ヘッダーを base64url デコードする。

4. Verify that the resulting octet sequence is a UTF-8-encoded representation of a completely valid JSON object conforming to RFC 7159 [RFC7159]; let the JOSE Header be this JSON object.

4. 結果のオクテット列が、RFC 7159 [RFC7159] に適合する完全に有効な JSON オブジェクトの UTF-8 エンコード表現であることを検証する。この JSON オブジェクトを JOSE ヘッダーとする。

5. Verify that the resulting JOSE Header includes only parameters and values whose syntax and semantics are both understood and supported or that are specified as being ignored when not understood.

5. 結果の JOSE ヘッダーが、構文と意味の両方が理解されサポートされているパラメーターと値、または理解されない場合には無視されると規定されているパラメーターと値のみを含むことを検証する。

6. Determine whether the JWT is a JWS or a JWE using any of the methods described in Section 9 of [JWE].

6. [JWE] の 9 節に記述されたいずれかの方法を用いて、JWT が JWS であるか JWE であるかを判定する。

7. Depending upon whether the JWT is a JWS or JWE, there are two cases:

7. JWT が JWS であるか JWE であるかに応じて、2 つの場合がある。

* If the JWT is a JWS, follow the steps specified in [JWS] for validating a JWS. Let the Message be the result of base64url decoding the JWS Payload.

* JWT が JWS である場合、JWS の検証について [JWS] で規定された手順に従う。JWS ペイロードを base64url デコードした結果をメッセージとする。

* Else, if the JWT is a JWE, follow the steps specified in [JWE] for validating a JWE. Let the Message be the resulting plaintext.

* そうでなく、JWT が JWE である場合、JWE の検証について [JWE] で規定された手順に従う。結果の平文をメッセージとする。

8. If the JOSE Header contains a "cty" (content type) value of "JWT", then the Message is a JWT that was the subject of nested signing or encryption operations. In this case, return to Step 1, using the Message as the JWT.

8. JOSE ヘッダーが "cty" (content type) 値 "JWT" を含む場合、メッセージは入れ子の署名または暗号化操作の対象となった JWT である。この場合、メッセージを JWT として手順 1 に戻る。

9. Otherwise, base64url decode the Message following the restriction that no line breaks, whitespace, or other additional characters have been used.

9. そうでなければ、改行、空白、その他の追加文字が使われていないという制約に従って、メッセージを base64url デコードする。

10. Verify that the resulting octet sequence is a UTF-8-encoded representation of a completely valid JSON object conforming to RFC 7159 [RFC7159]; let the JWT Claims Set be this JSON object.

10. 結果のオクテット列が、RFC 7159 [RFC7159] に適合する完全に有効な JSON オブジェクトの UTF-8 エンコード表現であることを検証する。この JSON オブジェクトを JWT クレームセットとする。

Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWT can be successfully validated, unless the algorithms used in the JWT are acceptable to the application, it SHOULD reject the JWT.

最後に、ある文脈においてどのアルゴリズムを用いてよいかはアプリケーションの決定事項であることに注意。JWT の検証に成功したとしても、JWT で用いられているアルゴリズムがアプリケーションにとって受け入れ可能でない限り、アプリケーションはその JWT を拒否すべきである (SHOULD)。

7.3.String Comparison Rules

7.3.文字列比較規則

Processing a JWT inevitably requires comparing known strings to members and values in JSON objects. For example, in checking what the algorithm is, the Unicode [UNICODE] string encoding "alg" will be checked against the member names in the JOSE Header to see if there is a matching Header Parameter name.

JWT の処理では、既知の文字列を JSON オブジェクト内のメンバーおよび値と比較することが必然的に必要になる。たとえば、アルゴリズムが何であるかを確認する際には、Unicode [UNICODE] 文字列エンコーディングの "alg" が、一致するヘッダーパラメーター名があるかどうかを調べるために JOSE ヘッダー内のメンバー名と照合される。

The JSON rules for doing member name comparison are described in Section 8.3 of RFC 7159 [RFC7159]. Since the only string comparison operations that are performed are equality and inequality, the same rules can be used for comparing both member names and member values against known strings.

メンバー名の比較を行うための JSON の規則は、RFC 7159 [RFC7159] の 8.3 節に記述されている。行われる文字列比較操作は等値と非等値のみであるため、メンバー名とメンバー値の両方を既知の文字列と比較するのに同じ規則を用いることができる。

These comparison rules MUST be used for all JSON string comparisons except in cases where the definition of the member explicitly calls out that a different comparison rule is to be used for that member value. In this specification, only the "typ" and "cty" member values do not use these comparison rules.

これらの比較規則は、メンバーの定義がそのメンバー値に対して異なる比較規則を用いることを明示的に指定している場合を除き、すべての JSON 文字列比較に用いられなければならない (MUST)。本仕様では、"typ" および "cty" のメンバー値のみがこれらの比較規則を用いない。

Some applications may include case-insensitive information in a case- sensitive value, such as including a DNS name as part of the "iss" (issuer) claim value. In those cases, the application may need to define a convention for the canonical case to use for representing the case-insensitive portions, such as lowercasing them, if more than one party might need to produce the same value so that they can be compared. (However, if all other parties consume whatever value the producing party emitted verbatim without attempting to compare it to an independently produced value, then the case used by the producer will not matter.)

一部のアプリケーションは、"iss" (issuer) クレーム値の一部として DNS 名を含める場合のように、大文字小文字を区別する値の中に大文字小文字を区別しない情報を含めることがある。そのような場合、複数の当事者が比較のために同じ値を生成する必要がありうるならば、アプリケーションは、大文字小文字を区別しない部分を表現する際に用いる正規の大文字小文字の規約 (たとえば小文字化する) を定義する必要があるかもしれない。(ただし、他のすべての当事者が、生成側の当事者が出力した値をそのまま消費し、独立に生成した値と比較しようとしないのであれば、生成者が用いる大文字小文字は問題にならない。)

8.Implementation Requirements

8.実装要件

This section defines which algorithms and features of this specification are mandatory to implement. Applications using this specification can impose additional requirements upon implementations that they use. For instance, one application might require support for encrypted JWTs and Nested JWTs, while another might require support for signing JWTs with the Elliptic Curve Digital Signature Algorithm (ECDSA) using the P-256 curve and the SHA-256 hash algorithm ("ES256").

本節は、本仕様のどのアルゴリズムと機能が実装必須であるかを定義する。本仕様を用いるアプリケーションは、自身が用いる実装に対して追加の要件を課すことができる。たとえば、あるアプリケーションは暗号化された JWT とネストされた JWT のサポートを要求するかもしれず、別のアプリケーションは P-256 曲線と SHA-256 ハッシュアルゴリズムを用いる楕円曲線デジタル署名アルゴリズム (ECDSA) ("ES256") による JWT の署名のサポートを要求するかもしれない。

Of the signature and MAC algorithms specified in JSON Web Algorithms [JWA], only HMAC SHA-256 ("HS256") and "none" MUST be implemented by conforming JWT implementations. It is RECOMMENDED that implementations also support RSASSA-PKCS1-v1_5 with the SHA-256 hash algorithm ("RS256") and ECDSA using the P-256 curve and the SHA-256 hash algorithm ("ES256"). Support for other algorithms and key sizes is OPTIONAL.

JSON Web Algorithms [JWA] で規定される署名および MAC アルゴリズムのうち、適合する JWT 実装が実装しなければならない (MUST) のは HMAC SHA-256 ("HS256") と "none" のみである。実装は、SHA-256 ハッシュアルゴリズムを用いる RSASSA-PKCS1-v1_5 ("RS256") と、P-256 曲線と SHA-256 ハッシュアルゴリズムを用いる ECDSA ("ES256") もサポートすることが推奨される (RECOMMENDED)。その他のアルゴリズムと鍵サイズのサポートは OPTIONAL である。

Support for encrypted JWTs is OPTIONAL. If an implementation provides encryption capabilities, of the encryption algorithms specified in [JWA], only RSAES-PKCS1-v1_5 with 2048-bit keys ("RSA1_5"), AES Key Wrap with 128- and 256-bit keys ("A128KW" and "A256KW"), and the composite authenticated encryption algorithm using AES-CBC and HMAC SHA-2 ("A128CBC-HS256" and "A256CBC-HS512") MUST be implemented by conforming implementations. It is RECOMMENDED that implementations also support using Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES) to agree upon a key used to wrap the Content Encryption Key ("ECDH-ES+A128KW" and "ECDH-ES+A256KW") and AES in Galois/Counter Mode (GCM) with 128- and 256-bit keys ("A128GCM" and "A256GCM"). Support for other algorithms and key sizes is OPTIONAL.

暗号化された JWT のサポートは OPTIONAL である。実装が暗号化機能を提供する場合、[JWA] で規定される暗号化アルゴリズムのうち、適合する実装が実装しなければならない (MUST) のは、2048 ビット鍵を用いる RSAES-PKCS1-v1_5 ("RSA1_5")、128 ビットおよび 256 ビット鍵を用いる AES Key Wrap ("A128KW" および "A256KW")、ならびに AES-CBC と HMAC SHA-2 を用いる複合認証付き暗号化アルゴリズム ("A128CBC-HS256" および "A256CBC-HS512") のみである。実装は、コンテンツ暗号化鍵をラップするために用いる鍵を合意するための Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES) の使用 ("ECDH-ES+A128KW" および "ECDH-ES+A256KW") と、128 ビットおよび 256 ビット鍵を用いる Galois/Counter Mode (GCM) の AES ("A128GCM" および "A256GCM") もサポートすることが推奨される (RECOMMENDED)。その他のアルゴリズムと鍵サイズのサポートは OPTIONAL である。

Support for Nested JWTs is OPTIONAL.

ネストされた JWT のサポートは OPTIONAL である。

9.URI for Declaring that Content is a JWT

9.コンテンツが JWT であることを宣言するための URI

This specification registers the URN "urn:ietf:params:oauth:token-type:jwt" for use by applications that declare content types using URIs (rather than, for instance, media types) to indicate that the content referred to is a JWT.

本仕様は、(メディアタイプなどではなく) URI を用いてコンテンツタイプを宣言するアプリケーションが、参照先のコンテンツが JWT であることを示すために用いる URN "urn:ietf:params:oauth:token-type:jwt" を登録する。

10.IANA Considerations

10.IANA に関する考慮事項

10.1.JSON Web Token Claims Registry

10.1.JSON Web Token クレームレジストリ

This section establishes the IANA "JSON Web Token Claims" registry for JWT Claim Names. The registry records the Claim Name and a reference to the specification that defines it. This section registers the Claim Names defined in Section 4.1.

本節は、JWT クレーム名のための IANA の "JSON Web Token Claims" レジストリを設立する。このレジストリは、クレーム名と、それを定義する仕様への参照を記録する。本節は 4.1 節で定義したクレーム名を登録する。

Values are registered on a Specification Required [RFC5226] basis after a three-week review period on the jwt-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.

値は、jwt-reg-review@ietf.org メーリングリストでの 3 週間のレビュー期間の後、1 名以上の指名専門家 (Designated Expert) の助言に基づいて、Specification Required [RFC5226] の方針で登録される。ただし、公開前に値を割り当てられるようにするため、指名専門家は、そのような仕様が公開されると確信した時点で登録を承認してもよい。

Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register claim: example").

レビューのためにメーリングリストに送られる登録要求は、適切な件名 (例: "Request to register claim: example") を用いるべきである。

Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.

レビュー期間内に、指名専門家は登録要求を承認または却下し、その決定をレビューリストと IANA に伝える。却下には説明を含め、該当する場合は要求を成功させるための提案も含めるべきである。21 日を超えて未決定のままの登録要求は、解決のために (iesg@ietf.org メーリングリストを用いて) IESG の注意を喚起することができる。

Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration description is clear.

指名専門家が適用すべき基準には、提案された登録が既存の機能と重複していないか、一般的な適用可能性が見込めるか、それとも単一のアプリケーションにのみ有用か、および登録の説明が明確かどうかの判断が含まれる。

IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.

IANA は指名専門家からのレジストリ更新のみを受け入れなければならず、登録のすべての要求をレビュー用メーリングリストへ誘導すべきである。

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. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts.

登録の決定について広く情報に基づいたレビューを可能にするため、本仕様を用いる異なるアプリケーションの観点を代表できる複数の指名専門家を任命することが提案される。登録の決定が特定の専門家にとって利益相反を生むと受け取られうる場合、その専門家は他の専門家の判断に委ねるべきである。

10.1.1.Registration Template

10.1.1.登録テンプレート

Claim Name: The name requested (e.g., "iss"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- that is, not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.

Claim Name: 要求する名前 (例: "iss")。本仕様の中心的な目標は結果の表現をコンパクトにすることであるため、名前は短く、すなわち、やむを得ない理由がない限り 8 文字を超えないことが推奨される (RECOMMENDED)。この名前は大文字小文字を区別する。指名専門家が例外を認めるやむを得ない理由があると表明しない限り、名前は他の登録済みの名前と大文字小文字を区別しない比較で一致してはならない。

Claim Description: Brief description of the claim (e.g., "Issuer").

Claim Description: クレームの簡潔な説明 (例: "Issuer")。

Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

Change Controller: Standards Track の RFC の場合は "IESG" と記載する。それ以外の場合は責任を負う当事者の名前を記載する。その他の詳細 (例: 郵送先住所、メールアドレス、ホームページ URI) を含めてもよい。

Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.

Specification Document(s): パラメーターを規定する 1 つまたは複数の文書への参照。文書の複製を取得するために使える URI を含めることが望ましい。関連する節の指示を含めてもよいが、必須ではない。

10.1.2.Initial Registry Contents

10.1.2.レジストリの初期内容

o Claim Name: "iss"

o Claim Name: "iss"

o Claim Description: Issuer

o Claim Description: Issuer (発行者)

o Change Controller: IESG

o Change Controller: IESG

o Specification Document(s): Section 4.1.1 of RFC 7519

o Specification Document(s): RFC 7519 の 4.1.1 節

o Claim Name: "sub"

o Claim Name: "sub"

o Claim Description: Subject

o Claim Description: Subject (主体)

o Change Controller: IESG

o Change Controller: IESG

o Specification Document(s): Section 4.1.2 of RFC 7519

o Specification Document(s): RFC 7519 の 4.1.2 節

o Claim Name: "aud"

o Claim Name: "aud"

o Claim Description: Audience

o Claim Description: Audience (オーディエンス)

o Change Controller: IESG

o Change Controller: IESG

o Specification Document(s): Section 4.1.3 of RFC 7519

o Specification Document(s): RFC 7519 の 4.1.3 節

o Claim Name: "exp"

o Claim Name: "exp"

o Claim Description: Expiration Time

o Claim Description: Expiration Time (有効期限)

o Change Controller: IESG

o Change Controller: IESG

o Specification Document(s): Section 4.1.4 of RFC 7519

o Specification Document(s): RFC 7519 の 4.1.4 節

o Claim Name: "nbf"

o Claim Name: "nbf"

o Claim Description: Not Before

o Claim Description: Not Before (有効開始)

o Change Controller: IESG

o Change Controller: IESG

o Specification Document(s): Section 4.1.5 of RFC 7519

o Specification Document(s): RFC 7519 の 4.1.5 節

o Claim Name: "iat"

o Claim Name: "iat"

o Claim Description: Issued At

o Claim Description: Issued At (発行時刻)

o Change Controller: IESG

o Change Controller: IESG

o Specification Document(s): Section 4.1.6 of RFC 7519

o Specification Document(s): RFC 7519 の 4.1.6 節

o Claim Name: "jti"

o Claim Name: "jti"

o Claim Description: JWT ID

o Claim Description: JWT ID

o Change Controller: IESG

o Change Controller: IESG

o Specification Document(s): Section 4.1.7 of RFC 7519

o Specification Document(s): RFC 7519 の 4.1.7 節

10.2.Sub-Namespace Registration of urn:ietf:params:oauth:token-type:jwt

10.2.urn:ietf:params:oauth:token-type:jwt のサブ名前空間登録

10.2.1.Registry Contents

10.2.1.レジストリの内容

This section registers the value "token-type:jwt" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" [RFC6755], which can be used to indicate that the content is a JWT.

本節は、"An IETF URN Sub-Namespace for OAuth" [RFC6755] で設立された IANA の "OAuth URI" レジストリに値 "token-type:jwt" を登録する。これはコンテンツが JWT であることを示すために用いることができる。

o URN: urn:ietf:params:oauth:token-type:jwt

o URN: urn:ietf:params:oauth:token-type:jwt

o Common Name: JSON Web Token (JWT) Token Type

o Common Name: JSON Web Token (JWT) Token Type

o Change Controller: IESG

o Change Controller: IESG

o Specification Document(s): RFC 7519

o Specification Document(s): RFC 7519

10.3.Media Type Registration

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

10.3.1.Registry Contents

10.3.1.レジストリの内容

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

本節は、RFC 6838 [RFC6838] に記述された方法で、"Media Types" レジストリ [IANA.MediaTypes] に "application/jwt" メディアタイプ [RFC2046] を登録する。これはコンテンツが JWT であることを示すために用いることができる。

o Type name: application

o Type name: application

o Subtype name: jwt

o Subtype name: jwt

o Required parameters: n/a

o Required parameters: n/a

o Optional parameters: n/a

o Optional parameters: n/a

o Encoding considerations: 8bit; JWT values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters.

o Encoding considerations: 8bit。JWT の値は、ピリオド ('.') 文字で区切られた一連の base64url エンコード値 (一部は空文字列でもよい) としてエンコードされる。

o Security considerations: See the Security Considerations section of RFC 7519

o Security considerations: RFC 7519 のセキュリティに関する考慮事項の節を参照

o Interoperability considerations: n/a

o Interoperability considerations: n/a

o Published specification: RFC 7519

o Published specification: RFC 7519

o Applications that use this media type: OpenID Connect, Mozilla Persona, Salesforce, Google, Android, Windows Azure, Amazon Web Services, and numerous others

o Applications that use this media type: OpenID Connect、Mozilla Persona、Salesforce、Google、Android、Windows Azure、Amazon Web Services、その他多数

o Fragment identifier considerations: n/a

o Fragment identifier considerations: n/a

o Additional information:

o Additional information:

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

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

o Intended usage: COMMON

o Intended usage: COMMON

o Restrictions on usage: none

o Restrictions on usage: none

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

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

o Change controller: IESG

o Change controller: IESG

o Provisional registration? No

o Provisional registration? No

10.4.Header Parameter Names Registration

10.4.ヘッダーパラメーター名の登録

This section registers specific Claim Names defined in Section 4.1 in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by [JWS] for use by claims replicated as Header Parameters in JWEs, per Section 5.3.

本節は、5.3 節に従って JWE 内でヘッダーパラメーターとして複製されるクレームが用いるために、4.1 節で定義した特定のクレーム名を、[JWS] で設立された IANA の "JSON Web Signature and Encryption Header Parameters" レジストリに登録する。

10.4.1.Registry Contents

10.4.1.レジストリの内容

o Header Parameter Name: "iss"

o Header Parameter Name: "iss"

o Header Parameter Description: Issuer

o Header Parameter Description: Issuer (発行者)

o Header Parameter Usage Location(s): JWE

o Header Parameter Usage Location(s): JWE

o Change Controller: IESG

o Change Controller: IESG

o Specification Document(s): Section 4.1.1 of RFC 7519

o Specification Document(s): RFC 7519 の 4.1.1 節

o Header Parameter Name: "sub"

o Header Parameter Name: "sub"

o Header Parameter Description: Subject

o Header Parameter Description: Subject (主体)

o Header Parameter Usage Location(s): JWE

o Header Parameter Usage Location(s): JWE

o Change Controller: IESG

o Change Controller: IESG

o Specification Document(s): Section 4.1.2 of RFC 7519

o Specification Document(s): RFC 7519 の 4.1.2 節

o Header Parameter Name: "aud"

o Header Parameter Name: "aud"

o Header Parameter Description: Audience

o Header Parameter Description: Audience (オーディエンス)

o Header Parameter Usage Location(s): JWE

o Header Parameter Usage Location(s): JWE

o Change Controller: IESG

o Change Controller: IESG

o Specification Document(s): Section 4.1.3 of RFC 7519

o Specification Document(s): RFC 7519 の 4.1.3 節

11.Security Considerations

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

All of the security issues that are pertinent to any cryptographic application must be addressed by JWT/JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys and employing countermeasures to various attacks.

あらゆる暗号アプリケーションに関係するセキュリティ上の問題はすべて、JWT/JWS/JWE/JWK エージェントによって対処されなければならない。これらの問題には、ユーザーの非対称秘密鍵および対称秘密鍵の保護や、さまざまな攻撃への対策の採用が含まれる。

All the security considerations in the JWS specification also apply to JWT, as do the JWE security considerations when encryption is employed. In particular, Sections 10.12 ("JSON Security Considerations") and 10.13 ("Unicode Comparison Security Considerations") of [JWS] apply equally to the JWT Claims Set in the same manner that they do to the JOSE Header.

JWS 仕様のセキュリティに関する考慮事項はすべて JWT にも適用され、暗号化を用いる場合は JWE のセキュリティに関する考慮事項も同様に適用される。特に、[JWS] の 10.12 節 ("JSON Security Considerations") および 10.13 節 ("Unicode Comparison Security Considerations") は、JOSE ヘッダーに対するのと同じ方法で JWT クレームセットにも等しく適用される。

11.1.Trust Decisions

11.1.信頼の判断

The contents of a JWT cannot be relied upon in a trust decision unless its contents have been cryptographically secured and bound to the context necessary for the trust decision. In particular, the key(s) used to sign and/or encrypt the JWT will typically need to verifiably be under the control of the party identified as the issuer of the JWT.

JWT の内容は、その内容が暗号学的に保護され、信頼の判断に必要な文脈に束縛されていない限り、信頼の判断において依拠することはできない。特に、JWT の署名および/または暗号化に用いられる鍵は、通常、JWT の発行者として識別される当事者の管理下にあることが検証可能である必要がある。

11.2.Signing and Encryption Order

11.2.署名と暗号化の順序

While syntactically the signing and encryption operations for Nested JWTs may be applied in any order, if both signing and encryption are necessary, normally producers should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions.

構文上は、ネストされた JWT の署名と暗号化の操作は任意の順序で適用できるが、署名と暗号化の両方が必要な場合、通常、生成者はメッセージに署名してからその結果を暗号化すべきである (こうして署名を暗号化する)。これにより、署名が剥がされて暗号化されたメッセージだけが残る攻撃を防ぐとともに、署名者のプライバシーを確保できる。さらに、暗号化されたテキストに対する署名は、多くの法域で有効とみなされない。

Note that potential concerns about security issues related to the order of signing and encryption operations are already addressed by the underlying JWS and JWE specifications; in particular, because JWE only supports the use of authenticated encryption algorithms, cryptographic concerns about the potential need to sign after encryption that apply in many contexts do not apply to this specification.

署名と暗号化の操作の順序に関するセキュリティ上の潜在的な懸念は、基盤となる JWS および JWE 仕様によって既に対処されていることに注意。特に、JWE は認証付き暗号化アルゴリズムの使用のみをサポートするため、多くの文脈で当てはまる、暗号化の後に署名する必要がありうるという暗号学的な懸念は本仕様には当てはまらない。

12.Privacy Considerations

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

A JWT may contain privacy-sensitive information. When this is the case, measures MUST be taken to prevent disclosure of this information to unintended parties. One way to achieve this is to use an encrypted JWT and authenticate the recipient. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted using protocols utilizing encryption that support endpoint authentication, such as Transport Layer Security (TLS). Omitting privacy-sensitive information from a JWT is the simplest way of minimizing privacy issues.

JWT はプライバシーに敏感な情報を含むことがある。その場合、この情報が意図しない当事者に開示されるのを防ぐための措置が講じられなければならない (MUST)。これを達成する方法の 1 つは、暗号化された JWT を用い、受信者を認証することである。もう 1 つの方法は、暗号化されていないプライバシーに敏感な情報を含む JWT が、Transport Layer Security (TLS) のようなエンドポイント認証をサポートする暗号化を利用するプロトコルでのみ送信されるようにすることである。プライバシーに敏感な情報を JWT から省くことが、プライバシー上の問題を最小化する最も単純な方法である。

13.References

13.参考資料

13.1.Normative References

13.1.引用規格

13.2.Informative References

13.2.参考文献

A.JWT Examples

A.JWT の例

This section contains examples of JWTs. For other example JWTs, see Section 6.1 of this document and Appendices A.1 - A.3 of [JWS].

本節には JWT の例を含める。その他の JWT の例については、本書の 6.1 節および [JWS] の付録 A.1 - A.3 を参照のこと。

A.1.Example Encrypted JWT

A.1.暗号化された JWT の例

This example encrypts the same claims as used in Section 3.1 to the recipient using RSAES-PKCS1-v1_5 and AES_128_CBC_HMAC_SHA_256.

この例は、3.1 節で用いたのと同じクレームを、RSAES-PKCS1-v1_5 と AES_128_CBC_HMAC_SHA_256 を用いて受信者宛てに暗号化する。

The following example JOSE Header declares that:

以下の JOSE ヘッダーの例は、次のことを宣言している。

o The Content Encryption Key is encrypted to the recipient using the RSAES-PKCS1-v1_5 algorithm to produce the JWE Encrypted Key.

o コンテンツ暗号化鍵は、RSAES-PKCS1-v1_5 アルゴリズムを用いて受信者宛てに暗号化され、JWE Encrypted Key を生成する。

o Authenticated encryption is performed on the plaintext using the AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext and the JWE Authentication Tag.

o 平文に対して AES_128_CBC_HMAC_SHA_256 アルゴリズムを用いて認証付き暗号化を行い、JWE Ciphertext と JWE Authentication Tag を生成する。

Other than using the octets of the UTF-8 representation of the JWT Claims Set from Section 3.1 as the plaintext value, the computation of this JWT is identical to the computation of the JWE in Appendix A.2 of [JWE], including the keys used.

3.1 節の JWT クレームセットの UTF-8 表現のオクテットを平文の値として用いる点を除き、この JWT の計算は、用いる鍵も含めて [JWE] の付録 A.2 の JWE の計算と同一である。

The final result in this example (with line breaks for display purposes only) is:

この例の最終結果 (改行は表示のためだけのものである) は次のとおりである。

A.2.Example Nested JWT

A.2.ネストされた JWT の例

This example shows how a JWT can be used as the payload of a JWE or JWS to create a Nested JWT. In this case, the JWT Claims Set is first signed, and then encrypted.

この例は、JWT を JWE または JWS のペイロードとして用いてネストされた JWT を作る方法を示す。この場合、JWT クレームセットはまず署名され、次に暗号化される。

The inner signed JWT is identical to the example in Appendix A.2 of [JWS]. Therefore, its computation is not repeated here. This example then encrypts this inner JWT to the recipient using RSAES-PKCS1-v1_5 and AES_128_CBC_HMAC_SHA_256.

内側の署名付き JWT は、[JWS] の付録 A.2 の例と同一である。したがって、その計算はここでは繰り返さない。この例では次に、この内側の JWT を RSAES-PKCS1-v1_5 と AES_128_CBC_HMAC_SHA_256 を用いて受信者宛てに暗号化する。

The following example JOSE Header declares that:

以下の JOSE ヘッダーの例は、次のことを宣言している。

o The Content Encryption Key is encrypted to the recipient using the RSAES-PKCS1-v1_5 algorithm to produce the JWE Encrypted Key.

o コンテンツ暗号化鍵は、RSAES-PKCS1-v1_5 アルゴリズムを用いて受信者宛てに暗号化され、JWE Encrypted Key を生成する。

o Authenticated encryption is performed on the plaintext using the AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext and the JWE Authentication Tag.

o 平文に対して AES_128_CBC_HMAC_SHA_256 アルゴリズムを用いて認証付き暗号化を行い、JWE Ciphertext と JWE Authentication Tag を生成する。

o The plaintext is itself a JWT.

o 平文自体が JWT である。

Base64url encoding the octets of the UTF-8 representation of the JOSE Header yields this encoded JOSE Header value:

JOSE ヘッダーの UTF-8 表現のオクテットを base64url エンコードすると、次のエンコード済み JOSE ヘッダー値が得られる。

The computation of this JWT is identical to the computation of the JWE in Appendix A.2 of [JWE], other than that different JOSE Header, plaintext, JWE Initialization Vector, and Content Encryption Key values are used. (The RSA key used is the same.)

この JWT の計算は、異なる JOSE ヘッダー、平文、JWE Initialization Vector、およびコンテンツ暗号化鍵の値を用いる点を除き、[JWE] の付録 A.2 の JWE の計算と同一である。(用いる RSA 鍵は同じである。)

The plaintext used is the octets of the ASCII [RFC20] representation of the JWT at the end of Appendix A.2.1 of [JWS] (with all whitespace and line breaks removed), which is a sequence of 458 octets.

用いる平文は、[JWS] の付録 A.2.1 末尾の JWT (すべての空白と改行を除いたもの) の ASCII [RFC20] 表現のオクテットであり、458 オクテットの列である。

The JWE Initialization Vector value used (using JSON array notation) is:

用いる JWE Initialization Vector の値 (JSON 配列記法を使用) は次のとおりである。

[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53, 50]

[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53, 50]

This example uses the Content Encryption Key represented by the base64url-encoded value below:

この例では、以下の base64url エンコード値で表されるコンテンツ暗号化鍵を用いる。

The final result for this Nested JWT (with line breaks for display purposes only) is:

このネストされた JWT の最終結果 (改行は表示のためだけのものである) は次のとおりである。

B.Relationship of JWTs to SAML Assertions

B.JWT と SAML アサーションの関係

Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] provides a standard for creating security tokens with greater expressivity and more security options than supported by JWTs. However, the cost of this flexibility and expressiveness is both size and complexity. SAML's use of XML [W3C.CR-xml11-20060816] and XML Digital Signature (DSIG) [RFC3275] contributes to the size of SAML Assertions; its use of XML and especially XML Canonicalization [W3C.REC-xml-c14n-20010315] contributes to their complexity.

Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] は、JWT がサポートするよりも高い表現力と多くのセキュリティオプションを持つセキュリティトークンを作成するための標準を提供する。しかし、この柔軟性と表現力の代償は、サイズと複雑さの両方である。SAML が XML [W3C.CR-xml11-20060816] と XML デジタル署名 (DSIG) [RFC3275] を用いることは SAML アサーションのサイズの一因であり、XML、とりわけ XML 正規化 [W3C.REC-xml-c14n-20010315] を用いることはその複雑さの一因である。

JWTs are intended to provide a simple security token format that is small enough to fit into HTTP headers and query arguments in URIs. It does this by supporting a much simpler token model than SAML and using the JSON [RFC7159] object encoding syntax. It also supports securing tokens using Message Authentication Codes (MACs) and digital signatures using a smaller (and less flexible) format than XML DSIG.

JWT は、HTTP ヘッダーや URI のクエリ引数に収まるほど小さい、単純なセキュリティトークン形式を提供することを意図している。これは、SAML よりはるかに単純なトークンモデルをサポートし、JSON [RFC7159] オブジェクトのエンコード構文を用いることで実現している。また、XML DSIG より小さい (そして柔軟性の低い) 形式を用いて、メッセージ認証コード (MAC) とデジタル署名によるトークンの保護もサポートする。

Therefore, while JWTs can do some of the things SAML Assertions do, JWTs are not intended as a full replacement for SAML Assertions, but rather as a token format to be used when ease of implementation or compactness are considerations.

したがって、JWT は SAML アサーションができることの一部を行えるが、JWT は SAML アサーションの完全な代替を意図したものではなく、実装の容易さやコンパクトさが考慮事項となる場合に用いるトークン形式として意図されている。

SAML Assertions are always statements made by an entity about a subject. JWTs are often used in the same manner, with the entity making the statements being represented by the "iss" (issuer) claim, and the subject being represented by the "sub" (subject) claim. However, with these claims being optional, other uses of the JWT format are also permitted.

SAML アサーションは常に、あるエンティティが主体について行う言明である。JWT もしばしば同じ方法で用いられ、言明を行うエンティティは "iss" (issuer) クレームで、主体は "sub" (subject) クレームで表される。しかし、これらのクレームは任意であるため、JWT 形式の他の用途も許容される。

C.Relationship of JWTs to Simple Web Tokens (SWTs)

C.JWT と Simple Web Token (SWT) の関係

Both JWTs and SWTs [SWT], at their core, enable sets of claims to be communicated between applications. For SWTs, both the claim names and claim values are strings. For JWTs, while claim names are strings, claim values can be any JSON type. Both token types offer cryptographic protection of their content: SWTs with HMAC SHA-256 and JWTs with a choice of algorithms, including signature, MAC, and encryption algorithms.

JWT と SWT [SWT] はどちらも、その核心において、アプリケーション間でクレームの集合を伝達できるようにするものである。SWT では、クレーム名とクレーム値の両方が文字列である。JWT では、クレーム名は文字列であるが、クレーム値は任意の JSON 型をとりうる。どちらのトークン型も内容の暗号学的保護を提供する。SWT は HMAC SHA-256 により、JWT は署名、MAC、暗号化アルゴリズムを含むアルゴリズムの選択により保護される。

Acknowledgements

謝辞

The authors acknowledge that the design of JWTs was intentionally influenced by the design and simplicity of SWTs [SWT] and ideas for JSON tokens that Dick Hardt discussed within the OpenID community.

著者らは、JWT の設計が SWT [SWT] の設計と簡潔さ、および Dick Hardt が OpenID コミュニティ内で議論した JSON トークンのアイデアから意図的に影響を受けたことを認める。

Solutions for signing JSON content were previously explored by Magic Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas Applications [CanvasApp], all of which influenced this document.

JSON コンテンツに署名するための解決策は、以前に Magic Signatures [MagicSignatures]、JSON Simple Sign [JSS]、および Canvas Applications [CanvasApp] によって探求されており、これらすべてが本書に影響を与えた。

This specification is the work of the OAuth working group, which includes dozens of active and dedicated participants. In particular, the following individuals contributed ideas, feedback, and wording that influenced this specification:

本仕様は、数十名の活発で献身的な参加者を擁する OAuth ワーキンググループの成果である。特に、以下の個人が本仕様に影響を与えたアイデア、フィードバック、および文言を提供した。

Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de Medeiros, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Warren Kumari, Ben Laurie, Barry Leiba, Ted Lemon, James Manger, Prateek Mishra, Kathleen Moriarty, Tony Nadalin, Axel Nennker, John Panzer, Emmanuel Raviart, David Recordon, Eric Rescorla, Jim Schaad, Paul Tarjan, Hannes Tschofenig, Sean Turner, and Tom Yu.

Dirk Balfanz、Richard Barnes、Brian Campbell、Alissa Cooper、Breno de Medeiros、Stephen Farrell、Yaron Y. Goland、Dick Hardt、Joe Hildebrand、Jeff Hodges、Edmund Jay、Warren Kumari、Ben Laurie、Barry Leiba、Ted Lemon、James Manger、Prateek Mishra、Kathleen Moriarty、Tony Nadalin、Axel Nennker、John Panzer、Emmanuel Raviart、David Recordon、Eric Rescorla、Jim Schaad、Paul Tarjan、Hannes Tschofenig、Sean Turner、および Tom Yu。

Hannes Tschofenig and Derek Atkins chaired the OAuth working group and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Security Area Directors during the creation of this specification.

本仕様の作成期間中、Hannes Tschofenig と Derek Atkins が OAuth ワーキンググループの議長を務め、Sean Turner、Stephen Farrell、および Kathleen Moriarty がセキュリティエリアディレクターを務めた。