JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.
JSON Web Signature (JWS) は、JSON ベースのデータ構造を使用して、デジタル署名またはメッセージ認証コード (MAC) で保護されたコンテンツを表します。この仕様で使用する暗号アルゴリズムと識別子については、別個の JSON Web Algorithms (JWA) 仕様およびその仕様で定義された IANA レジストリに記載されています。関連する暗号化機能については、別個の JSON Web Encryption (JWE) 仕様で説明されています。
This is an Internet Standards Track document.
これはインターネット標準トラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティの合意を表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）によって公開承認されました。インターネット標準に関する詳細は、RFC 5741のセクション2に記載されています。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7515.
この文書の現在の状態、正誤表、およびフィードバック方法に関する情報については、http://www.rfc-editor.org/info/rfc7515を参照してください。
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETFドキュメントに関するIETFトラストの法的規定 https://trustee.ietf.org/license-info にしたがう必要があります。これらの文書をよく確認し、この文書に関するあなたの権利と制限を説明しています。この文書から抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based [RFC7159] data structures. The JWS cryptographic mechanisms provide integrity protection for an arbitrary sequence of octets. See Section 10.5 for a discussion on the differences between digital signatures and MACs.
JSON Web Signature (JWS) は、JSON ベースのデータ構造を使用して、デジタル署名またはメッセージ認証コード (MAC) で保護されたコンテンツを表します。JWS 暗号メカニズムは、任意のオクテットのシーケンスの整合性保護を提供します。デジタル署名と MAC の違いについては、セクション 10.5 を参照してください。
Two closely related serializations for JWSs are defined. The JWS Compact Serialization is a compact, URL-safe representation intended for space-constrained environments such as HTTP Authorization headers and URI query parameters. The JWS JSON Serialization represents JWSs as JSON objects and enables multiple signatures and/or MACs to be applied to the same content. Both share the same cryptographic underpinnings.
JWS の 2 つの関連するシリアル化形式が定義されています。JWS コンパクトシリアル化は、HTTP 認証ヘッダーや URI クエリパラメーターなどのスペースが制限された環境向けに設計されたコンパクトで URL セーフな表現です。JWS JSON シリアル化は、JWS を JSON オブジェクトとして表現し、同じコンテンツに複数の署名と/または MAC を適用できるようにします。両方とも、同じ暗号基盤を共有しています。
Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) [JWA] specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) [JWE] specification.
この仕様で使用する暗号アルゴリズムと識別子については、別個の JSON Web Algorithms (JWA) 仕様およびその仕様で定義された IANA レジストリに記載されています。関連する暗号化機能については、別個の JSON Web Encryption (JWE) 仕様で説明されています。
Names defined by this specification are short because a core goal is for the resulting representations to be compact.
この仕様で定義された名前は短くなっています。なぜなら、結果として得られる表現がコンパクトであることが主な目的だからです。
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）」は、 [RFC2119]に記載されているとおりに解釈されるものとします。 これらのキーワードは、大文字で表記されている場合にのみ適用されると解釈すべきです
BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 2.
BASE64URL（OCTETS）は、セクション2に従ってOCTETSのbase64urlエンコーディングを示します。
ASCII(STRING) denotes the octets of the ASCII [RFC20] representation of STRING, where STRING is a sequence of zero or more ASCII characters.
ASCII（STRING）は、STRINGがゼロ個以上のASCII文字のシーケンスである場合、STRINGのASCII[RFC20]表現のオクテットを示します。
The concatenation of two values A and B is denoted as A || B.
2つの値AとBの連結は、A || Bと表されます。
These terms are defined by this specification:
この仕様で定義される用語は以下の通りです:
JSON Web Signature (JWS) A data structure representing a digitally signed or MACed message.
JSON Web Signature (JWS) デジタル署名またはMACで保護されたメッセージを表すデータ構造。
JOSE Header JSON object containing the parameters describing the cryptographic operations and parameters employed. The JOSE (JSON Object Signing and Encryption) Header is comprised of a set of Header Parameters.
JOSEヘッダー 暗号操作とパラメーターを記述するパラメーターを含むJSONオブジェクト。JOSE（JSON Object Signing and Encryption）ヘッダーは、ヘッダーパラメーターのセットで構成されています。
JWS Payload The sequence of octets to be secured -- a.k.a. the message. The payload can contain an arbitrary sequence of octets.
JWS Payload 保護されるオクテットのシーケンス、つまりメッセージ。ペイロードには任意のオクテットのシーケンスを含めることができます。
JWS Signature Digital signature or MAC over the JWS Protected Header and the JWS Payload.
JWS Signature JWS Protected HeaderとJWS Payloadのデジタル署名またはMAC。
Header Parameter A name/value pair that is member of the JOSE Header.
ヘッダーパラメーター JOSE Headerのメンバーである名前/値のペア。
JWS Protected Header JSON object that contains the Header Parameters that are integrity protected by the JWS Signature digital signature or MAC operation. For the JWS Compact Serialization, this comprises the entire JOSE Header. For the JWS JSON Serialization, this is one component of the JOSE Header.
JWS Protected Header JWS Signatureデジタル署名またはMAC操作によって整合性が保護されるヘッダーパラメーターを含むJSONオブジェクト。JWS Compact Serializationの場合、これはJOSE Header全体を構成します。JWS JSON Serializationの場合、これはJOSE Headerの1つのコンポーネントです。
JWS Unprotected Header JSON object that contains the Header Parameters that are not integrity protected. This can only be present when using the JWS JSON Serialization.
JWS Unprotected Header 整合性が保護されていないヘッダーパラメーターを含むJSONオブジェクト。これはJWS JSON Serializationを使用している場合にのみ存在できます。
Base64url Encoding Base64 encoding using the URL- and filename-safe character set defined in Section 5 of RFC 4648 [RFC4648], with all trailing '=' characters omitted (as permitted by Section 3.2) and without the inclusion of any line breaks, whitespace, or other additional characters. Note that the base64url encoding of the empty octet sequence is the empty string. (See Appendix C for notes on implementing base64url encoding without padding.)
Base64url Encoding RFC 4648のセクション5で定義されたURLとファイル名に適した文字セットを使用したBase64エンコーディングで、すべての末尾の「=」文字が省略されています（セクション3.2で許可されています）。また、改行、空白、またはその他の追加文字を含めることはできません。空のオクテットシーケンスのbase64urlエンコーディングは空の文字列です（パディングなしでbase64urlエンコーディングを実装するためのノートについては、付録Cを参照してください）。
JWS Signing Input The input to the digital signature or MAC computation. Its value is ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)).
JWS Signing Input デジタル署名またはMAC計算の入力。その値はASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload))です。
JWS Compact Serialization A representation of the JWS as a compact, URL-safe string.
JWS Compact Serialization JWSをコンパクトでURLセーフな文字列として表現します。
JWS JSON Serialization A representation of the JWS as a JSON object. Unlike the JWS Compact Serialization, the JWS JSON Serialization enables multiple digital signatures and/or MACs to be applied to the same content. This representation is neither optimized for compactness nor URL- safe.
JWS JSON Serialization JWSをJSONオブジェクトとして表現します。JWS Compact Serializationとは異なり、JWS JSON Serializationでは同じコンテンツに複数のデジタル署名と/またはMACを適用できます。この表現は、コンパクト性やURLセーフ性に最適化されていません。
Unsecured JWS A JWS that provides no integrity protection. Unsecured JWSs use the "alg" value "none".
Unsecured JWS 整合性保護を提供しないJWS。Unsecured JWSは、「alg」値「none」を使用します。
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）、およびUniversally Unique IDentifiers（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 追加の要件として、任意の文字列値を使用できますが、「：」文字を含む値はURIである必要があるという条件があります。StringOrURI値は、変換や正準化が適用されずに大文字と小文字を区別する文字列として比較されます。
JWS represents digitally signed or MACed content using JSON data structures and base64url encoding. These JSON data structures 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]. A JWS represents these logical values (each of which is defined in Section 2):
JWSは、JSONデータ構造とbase64urlエンコーディングを使用して、デジタルに署名されたまたはMACされたコンテンツを表します。これらのJSONデータ構造には、RFC 7159のセクション2に従って、JSON値または構造上の文字の前後にホワイトスペースと/または改行が含まれる場合があります。MAY。 JWSは、これらの論理値を表します（それぞれはセクション2で定義されています）：[RFC7159]。
For a JWS, the JOSE Header members are the union of the members of these values (each of which is defined in Section 2):
JWSの場合、JOSEヘッダーメンバーは、これらの値のメンバーの和集合です（それぞれはセクション2で定義されています）：
This document defines two serializations for JWSs: a compact, URL- safe serialization called the JWS Compact Serialization and a JSON serialization called the JWS JSON Serialization. In both serializations, the JWS Protected Header, JWS Payload, and JWS Signature are base64url encoded, since JSON lacks a way to directly represent arbitrary octet sequences.
このドキュメントでは、JWSに対して2つのシリアル化方法が定義されています。1つはJWSコンパクトシリアル化と呼ばれるコンパクトでURLセーフなシリアル化で、もう1つはJWS JSONシリアル化と呼ばれるJSONシリアル化です。両方のシリアル化において、JWS保護ヘッダー、JWSペイロード、およびJWSシグネチャは、JSONが任意のオクテットシーケンスを直接表現する方法を持たないため、base64urlエンコードされます。
In the JWS Compact Serialization, no JWS Unprotected Header is used. In this case, the JOSE Header and the JWS Protected Header are the same.
JWS Compact Serializationでは、JWS Unprotected Headerは使用されません。 この場合、JOSE HeaderとJWS Protected Headerは同じです。
In the JWS Compact Serialization, a JWS is represented as the concatenation:
JWS Compact Serializationでは、JWSは以下の連結として表されます：
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)
See Section 7.1 for more information about the JWS Compact Serialization.
See Section 7.1 for more information about the JWS Compact Serialization.
In the JWS JSON Serialization, one or both of the JWS Protected Header and JWS Unprotected Header MUST be present. In this case, the members of the JOSE Header are the union of the members of the JWS Protected Header and the JWS Unprotected Header values that are present.
JWS JSONシリアル化では、JWS保護ヘッダーとJWS保護されていないヘッダーのいずれか1つまたは両方が存在するMUSTです。この場合、JOSEヘッダーのメンバーは、JWS保護ヘッダーとJWS保護されていないヘッダーの値の和集合です。
In the JWS JSON Serialization, a JWS is represented as a JSON object containing some or all of these four members:
JWS JSONシリアル化では、JWSは、次の4つのメンバーのいずれかまたはすべてを含むJSONオブジェクトとして表されます。
The three base64url-encoded result strings and the JWS Unprotected Header value are represented as members within a JSON object. The inclusion of some of these values is OPTIONAL. The JWS JSON Serialization can also represent multiple signature and/or MAC values, rather than just one. See Section 7.2 for more information about the JWS JSON Serialization.
3つのbase64urlエンコードされた結果文字列とJWS保護されていないヘッダーの値は、JSONオブジェクト内のメンバーとして表されます。これらの値の一部を含めることはオプションです。JWS JSONシリアル化では、1つではなく複数の署名および/またはMAC値を表すこともできます。JWS JSONシリアル化に関する詳細については、セクション7.2を参照してください。
This section provides an example of a JWS. Its computation is described in more detail in Appendix A.1, including specifying the exact octet sequences representing the JSON values used and the key value used.
このセクションでは、JWSの例を示します。詳細については、付録A.1で、使用されるJSON値の正確なオクテットシーケンスと使用されるキー値を指定することが説明されています。
{"typ":"JWT",
"alg":"HS256"}
{"typ":"JWT",
"alg":"HS256"}
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
このJWS Protected HeaderをBASE64URL(UTF8(JWS Protected Header))としてエンコードすると、次の値が得られます。
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
The UTF-8 representation of the following JSON object is used as the JWS Payload. (Note that the payload can be any content and need not be a representation of a JSON object.)
次のJSONオブジェクトのUTF-8表現がJWSペイロードとして使用されます。 （ペイロードは任意のコンテンツであり、JSONオブジェクトの表現である必要はありません。）
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Encoding this JWS Payload as BASE64URL(JWS Payload) gives this value (with line breaks for display purposes only):
このJWSペイロードをBASE64URL(JWS Payload)としてエンコードすると、次の値が得られます（表示目的の改行を含む）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Computing the HMAC of the JWS Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)) with the HMAC SHA-256 algorithm using the key specified in Appendix A.1 and base64url-encoding the result yields this BASE64URL(JWS Signature) value:
JWS署名入力のASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload))のHMAC SHA-256アルゴリズムを使用して、付録A.1で指定されたキーを使用して計算し、結果をbase64urlエンコードすると、次のBASE64URL(JWS Signature)値が得られます。
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):
これらの値をHeader.Payload.Signatureの順序で連結し、部分間にピリオド（'.'）文字を使用すると、JWS Compact Serializationを使用した完全なJWS表現が得られます（表示目的の改行を含む）：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
See Appendix A for additional examples, including examples using the JWS JSON Serialization in Sections A.6 and A.7.
セクションA.6およびA.7のJWS JSON Serializationを使用した例を含む、追加の例については、付録Aを参照してください。
For a JWS, the members of the JSON object(s) representing the JOSE Header describe the digital signature or MAC applied to the JWS Protected Header and the JWS Payload and optionally additional properties of the JWS. The Header Parameter names within the JOSE Header MUST be unique; JWS parsers MUST either reject JWSs with duplicate Header Parameter 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].
JWSの場合、JOSEヘッダーを表すJSONオブジェクトのメンバーは、JWS保護ヘッダーとJWSペイロードに適用されるデジタル署名またはMAC、およびJWSのオプションの追加プロパティを説明します。JOSEヘッダー内のヘッダーパラメーター名は、一意である必要があります。JWSパーサーは、重複するヘッダーパラメーター名を持つJWSを拒否するか、ECMAScript 5.1のセクション15.12（「JSONオブジェクト」）で指定されているように、レキシカルに最後の重複メンバー名のみを返すJSONパーサーを使用しなければなりません（MUST）
Implementations are required to understand the specific Header Parameters defined by this specification that are designated as "MUST be understood" and process them in the manner defined in this specification. All other Header Parameters defined by this specification that are not so designated MUST be ignored when not understood. Unless listed as a critical Header Parameter, per Section 4.1.11, all Header Parameters not defined by this specification MUST be ignored when not understood.
実装は、この仕様で「理解する必要がある」と指定された特定のヘッダーパラメーターを理解し、この仕様で定義された方法で処理する必要があります。この仕様で定義されたその他のヘッダーパラメーターは、理解されない場合は無視する必要があります。セクション4.1.11に記載されていない限り、この仕様で定義されていないすべてのヘッダーパラメーターは、理解されない場合は無視しなければなりません（MUST）
There are three classes of Header Parameter names: Registered Header Parameter names, Public Header Parameter names, and Private Header Parameter names.
ヘッダーパラメーター名には、登録済みヘッダーパラメーター名、パブリックヘッダーパラメーター名、およびプライベートヘッダーパラメーター名の3つのクラスがあります。
The following Header Parameter names for use in JWSs are registered in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by Section 9.1, with meanings as defined in the subsections below.
JWSで使用するために登録されたHeader Parameter名は、セクション9.1で設立されたIANA「JSON Web Signature and Encryption Header Parameters」レジストリに登録されており、以下のサブセクションで定義される意味を持ちます。
As indicated by the common registry, JWSs and JWEs share a common Header Parameter space; when a parameter is used by both specifications, its usage must be compatible between the specifications.
共通のレジストリによって示されるように、JWSとJWEは共通のHeader Parameterスペースを共有しています。両方の仕様でパラメーターが使用される場合、その使用法は仕様間で互換性がある必要があります。
The "alg" (algorithm) Header Parameter identifies the cryptographic algorithm used to secure the JWS. The JWS Signature value is not valid if the "alg" value does not represent a supported algorithm or if there is not a key for use with that algorithm associated with the party that digitally signed or MACed the content. "alg" values should either be registered in the IANA "JSON Web Signature and Encryption Algorithms" registry established by [JWA] or be a value that contains a Collision-Resistant Name. The "alg" value is a case- sensitive ASCII string containing a StringOrURI value. This Header Parameter MUST be present and MUST be understood and processed by implementations.
"alg"（アルゴリズム）ヘッダーパラメーターは、JWSを保護するために使用される暗号アルゴリズムを識別します。 "alg"値がサポートされていないアルゴリズムを表している場合、またはデジタルに署名またはMACされたコンテンツを処理するためのキーが関連付けられていない場合、JWS署名値は無効です。 "alg"値は、IANAによって設立された「JSON Web Signature and Encryption Algorithms」レジストリに登録されているか、衝突耐性のある名前を含む値である必要があります。 "alg"値は、StringOrURI値を含む大文字と小文字を区別するASCII文字列です。このヘッダーパラメーターは存在しなければなりません（MUST）。実装によって理解され、処理される必要があります（MUST）。
The "jku" (JWK Set URL) Header Parameter is a URI [RFC3986] that refers to a resource for a set of JSON-encoded public keys, one of which corresponds to the key used to digitally sign the JWS. The keys MUST be encoded as a JWK Set [JWK]. The protocol used to acquire the resource MUST provide integrity protection; an HTTP GET request to retrieve the JWK Set MUST use Transport Layer Security (TLS) [RFC2818] [RFC5246]; and the identity of the server MUST be validated, as per Section 6 of RFC 6125 [RFC6125]. Also, see Section 8 on TLS requirements. Use of this Header Parameter is OPTIONAL.
"jku" (JWK Set URL)ヘッダーパラメーターは、JSONエンコードされた公開鍵のセットのリソースを参照するURI [RFC3986]であり、そのうち1つがJWSのデジタル署名に使用されるキーに対応します。キーはJWK Set [JWK]としてエンコードしなければなりません（MUST）。リソースを取得するために使用されるプロトコルは、整合性保護を提供する必要があります。JWK Setを取得するためのHTTP GETリクエストは、Transport Layer Security (TLS) [RFC2818] [RFC5246]を使用しなければなりません（MUST）。サーバーの識別情報はRFC 6125 [RFC6125]のセクション6にたがって検証しなければなりません（MUST）。また、TLS要件に関するセクション8も参照してください。このヘッダーパラメーターの使用は選択できます（OPTIONAL）
The "jwk" (JSON Web Key) Header Parameter is the public key that corresponds to the key used to digitally sign the JWS. This key is represented as a JSON Web Key [JWK]. Use of this Header Parameter is OPTIONAL.
"jwk"（JSON Web Key）ヘッダーパラメーターは、JWSをデジタル署名するために使用されるキーに対応する公開鍵を表します。このキーはJSON Web Key [JWK]として表されます。このヘッダーパラメーターの使用は選択できます（OPTIONAL）。
The "kid" (key ID) Header Parameter is a hint indicating which key was used to secure the JWS. This parameter allows originators to explicitly signal a change of key to recipients. The structure of the "kid" value is unspecified. Its value MUST be a case-sensitive string. Use of this Header Parameter is OPTIONAL.
"kid"（キーID）ヘッダーパラメーターは、JWSを保護するために使用されたキーを示すヒントです。このパラメーターにより、送信者は受信者に対してキーの変更を明示的に通知できます。 "kid"値の構造は未指定です。その値は大文字と小文字を区別する文字列である必要があります（MUST）。このヘッダーパラメーターの使用は選択できます（OPTIONAL）。
When used with a JWK, the "kid" value is used to match a JWK "kid" parameter value.
JWKと一緒に使用する場合、"kid"値はJWKの"kid"パラメーター値と一致するように使用されます。
The "x5u" (X.509 URL) Header Parameter is a URI [RFC3986] that refers to a resource for the X.509 public key certificate or certificate chain [RFC5280] corresponding to the key used to digitally sign the JWS. The identified resource MUST provide a representation of the certificate or certificate chain that conforms to RFC 5280 [RFC5280] in PEM-encoded form, with each certificate delimited as specified in Section 6.1 of RFC 4945 [RFC4945]. The certificate containing the public key corresponding to the key used to digitally sign the JWS MUST be the first certificate. This MAY be followed by additional certificates, with each subsequent certificate being the one used to certify the previous one. The protocol used to acquire the resource MUST provide integrity protection; an HTTP GET request to retrieve the certificate MUST use TLS [RFC2818] [RFC5246]; and the identity of the server MUST be validated, as per Section 6 of RFC 6125 [RFC6125]. Also, see Section 8 on TLS requirements. Use of this Header Parameter is OPTIONAL.
"x5u"（X.509 URL）ヘッダーパラメーターは、JWSをデジタル署名するために使用されるキーに対応するX.509公開鍵証明書または証明書チェーンのリソースを参照するURI [RFC3986]です。識別されたリソースはRFC 5280 [RFC5280]に準拠したPEMエンコード形式で表された証明書または証明書チェーンの表現を提供しなければなりません（MUST）。各証明書はRFC 4945 [RFC4945]のセクション6.1で指定されたように区切られている必要があります（MUST）。JWSをデジタル署名するために使用される公開鍵を含む証明書は、最初の証明書である必要があります（MUST）。これに続いて、前の証明書を認証するために使用される証明書が続く場合があります（MAY）。リソースを取得するために使用されるプロトコルは整合性保護を提供しなければなりません（MUST）。証明書を取得するためのHTTP GETリクエストは、Transport Layer Security（TLS）[RFC2818] [RFC5246]を使用しなければなりません（MUST）。サーバーの識別子はRFC 6125のセクション6にしたがって検証しなければなりません（MUST）。TLS要件については、セクション8を参照してください。このヘッダーパラメーターの使用は選択できます（OPTIONAL）。
The "x5c" (X.509 certificate chain) Header Parameter contains the X.509 public key certificate or certificate chain [RFC5280] corresponding to the key used to digitally sign the JWS. The certificate or certificate chain is represented as a JSON array of certificate value strings. Each string in the array is a base64-encoded (Section 4 of [RFC4648] -- not base64url-encoded) DER [ITU.X690.2008] PKIX certificate value. The certificate containing the public key corresponding to the key used to digitally sign the JWS MUST be the first certificate. This MAY be followed by additional certificates, with each subsequent certificate being the one used to certify the previous one. The recipient MUST validate the certificate chain according to RFC 5280 [RFC5280] and consider the certificate or certificate chain to be invalid if any validation failure occurs. Use of this Header Parameter is OPTIONAL.
「x5c」（X.509証明書チェーン）ヘッダーパラメーターには、JWSにデジタル署名するために使用されるキーに対応するX.509公開鍵証明書または証明書チェーンが含まれます。証明書または証明書チェーンは、証明書値文字列のJSON配列として表されます。配列内の各文字列は、base64エンコードされた（[RFC4648]のSection 4 - base64urlエンコードされていない）DER [ITU.X690.2008] PKIX証明書値です。JWSにデジタル署名するために使用される公開鍵を含む証明書は、最初の証明書である必要があります（MUST）。これに続いて、追加の証明書が続く場合があります。各証明書は、前の証明書を認証するために使用されます。受信者は、RFC 5280 [RFC5280]にしたがって証明書チェーンを検証し、検証に失敗した場合は証明書または証明書チェーンを無効とする必要があります（MUST）。このヘッダーパラメーターの使用は選択できます（OPTIONAL）。
See Appendix B for an example "x5c" value.
「x5c」値の例については、付録Bを参照してください。
The "x5t" (X.509 certificate SHA-1 thumbprint) Header Parameter is a base64url-encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of the X.509 certificate [RFC5280] corresponding to the key used to digitally sign the JWS. Note that certificate thumbprints are also sometimes known as certificate fingerprints. Use of this Header Parameter is OPTIONAL.
"x5t"（X.509証明書SHA-1サムプリント）ヘッダーパラメーターは、JWSをデジタル署名するために使用されるキーに対応するX.509証明書のDERエンコードのSHA-1サムプリント（別名ダイジェスト）のbase64urlエンコードです。証明書のサムプリントは、証明書フィンガープリントとしても知られています。このヘッダーパラメーターの使用は選択できます（OPTIONAL）。
Parameter
Parameter
The "x5t#S256" (X.509 certificate SHA-256 thumbprint) Header Parameter is a base64url-encoded SHA-256 thumbprint (a.k.a. digest) of the DER encoding of the X.509 certificate [RFC5280] corresponding to the key used to digitally sign the JWS. Note that certificate thumbprints are also sometimes known as certificate fingerprints. Use of this Header Parameter is OPTIONAL.
"x5t#S256"（X.509証明書SHA-256サムプリント）ヘッダーパラメーターは、JWSをデジタル署名するために使用されるキーに対応するX.509証明書のDERエンコードのSHA-256サムプリント（別名ダイジェスト）のbase64urlエンコードです。証明書のサムプリントは、証明書フィンガープリントとしても知られています。このヘッダーパラメーターの使用は選択できます（OPTIONAL）。
The "typ" (type) Header Parameter is used by JWS applications to declare the media type [IANA.MediaTypes] of this complete JWS. This is intended for use by the application when more than one kind of object could be present in an application data structure that can contain a JWS; 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 the kind of object is already known. This parameter is ignored by JWS implementations; any processing of this parameter is performed by the JWS application. Use of this Header Parameter is OPTIONAL.
"typ"（タイプ）ヘッダーパラメーターは、JWSアプリケーションがこの完全なJWSのメディアタイプ[IANA.MediaTypes]を宣言するために使用されます。これは、JWSを含むアプリケーションデータ構造に複数の種類のオブジェクトが存在する場合に、アプリケーションが異なる種類のオブジェクトを区別するためにこの値を使用できるようにするためです。オブジェクトの種類が既にわかっている場合、通常はアプリケーションによって使用されません。このパラメーターは、JWS実装によって無視されます。このパラメーターの処理は、JWSアプリケーションによって実行されます。このヘッダーパラメーターの使用は選択できます（OPTIONAL）。
Per RFC 2045 [RFC2045], all media type values, subtype values, and parameter names are case insensitive. However, parameter values are case sensitive unless otherwise specified for the specific parameter.
RFC 2045 [RFC2045]によると、すべてのメディアタイプ値、サブタイプ値、およびパラメーター名は大文字と小文字を区別しません。ただし、特定のパラメーターに対して別に指定されていない限り、パラメーター値は大文字と小文字を区別します。
To keep messages compact in common situations, it is RECOMMENDED that producers omit an "application/" prefix of a media type value in a "typ" Header Parameter when no other '/' appears in the media type value. A recipient using the media type value MUST treat it as if "application/" were prepended to any "typ" value not containing a '/'. For instance, a "typ" value of "example" SHOULD be used to represent the "application/example" media type, whereas the media type "application/example;part="1/2"" cannot be shortened to "example;part="1/2"".
一般的な状況でメッセージをコンパクトに保つために、プロデューサーは、メディアタイプ値に他の「/」が含まれていない場合、ヘッダーパラメーターの「typ」に「application/」接頭辞を省略することが推奨されます（RECOMMENDED）。メディアタイプ値を使用する受信者は、'/ 'を含まない'typ'値に'application/'が前置されたものとして扱う必要があります（MUST）。たとえば、「application/example」メディアタイプを表す場合、「typ」値は「example」であるべきです（SHOULD）。一方、「application/example;part="1/2"」メディアタイプは、「example;part="1/2"」に短縮できません。
The "typ" value "JOSE" can be used by applications to indicate that this object is a JWS or JWE using the JWS Compact Serialization or the JWE Compact Serialization. The "typ" value "JOSE+JSON" can be used by applications to indicate that this object is a JWS or JWE using the JWS JSON Serialization or the JWE JSON Serialization. Other type values can also be used by applications.
"typ"値「JOSE」は、このオブジェクトがJWS Compact SerializationまたはJWE Compact Serializationを使用してJWSまたはJWEであることを示すためにアプリケーションによって使用できます。「typ」値「JOSE+JSON」は、このオブジェクトがJWS JSON SerializationまたはJWE JSON Serializationを使用してJWSまたはJWEであることを示すためにアプリケーションによって使用できます。他のタイプの値もアプリケーションによって使用できます。
The "cty" (content type) Header Parameter is used by JWS applications to declare the media type [IANA.MediaTypes] of the secured content (the payload). This is intended for use by the application when more than one kind of object could be present in the JWS Payload; 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 the kind of object is already known. This parameter is ignored by JWS implementations; any processing of this parameter is performed by the JWS application. Use of this Header Parameter is OPTIONAL.
"cty"（コンテンツタイプ）ヘッダーパラメーターは、JWSアプリケーションが保護されたコンテンツ（ペイロード）のメディアタイプ[IANA.MediaTypes]を宣言するために使用されます。これは、JWSペイロードに複数の種類のオブジェクトが存在する場合、アプリケーションが異なる種類のオブジェクトを区別するためにこの値を使用できるようにするためです。オブジェクトの種類が既にわかっている場合、通常はアプリケーションによって使用されません。このパラメーターは、JWS実装によって無視されます。このパラメーターの処理は、JWSアプリケーションによって実行されます。このヘッダーパラメーターの使用はオプションです。
Per RFC 2045 [RFC2045], all media type values, subtype values, and parameter names are case insensitive. However, parameter values are case sensitive unless otherwise specified for the specific parameter.
RFC 2045 [RFC2045]によると、すべてのメディアタイプ値、サブタイプ値、およびパラメーター名は大文字と小文字を区別しません。ただし、特定のパラメーターに対して別に指定されていない限り、パラメーター値は大文字と小文字を区別します。
To keep messages compact in common situations, it is RECOMMENDED that producers omit an "application/" prefix of a media type value in a "cty" Header Parameter when no other '/' appears in the media type value. A recipient using the media type value MUST treat it as if "application/" were prepended to any "cty" value not containing a '/'. For instance, a "cty" value of "example" SHOULD be used to represent the "application/example" media type, whereas the media type "application/example;part="1/2"" cannot be shortened to "example;part="1/2"".
一般的な状況でメッセージをコンパクトに保つために、プロデューサーは、メディアタイプ値に他の「/」が含まれていない場合、ヘッダーパラメーターの「cty」に「application/」接頭辞を省略することが推奨されます（RECOMMENDED）。メディアタイプ値を使用する受信者は、'/ 'を含まない'cty'値に'application/'が前置されたものとして扱う必要があります（MUST）。たとえば、「application/example」メディアタイプを表す場合、「cty」値は「example」であるべきです（SHOULD）。一方、「application/example;part="1/2"」メディアタイプは、「example;part="1/2"」に短縮できません。
The "crit" (critical) Header Parameter indicates that extensions to this specification and/or [JWA] are being used that MUST be understood and processed. Its value is an array listing the Header Parameter names present in the JOSE Header that use those extensions. If any of the listed extension Header Parameters are not understood and supported by the recipient, then the JWS is invalid. Producers MUST NOT include Header Parameter names defined by this specification or [JWA] for use with JWS, duplicate names, or names that do not occur as Header Parameter names within the JOSE Header in the "crit" list. Producers MUST NOT use the empty list "[]" as the "crit" value. Recipients MAY consider the JWS to be invalid if the critical list contains any Header Parameter names defined by this specification or [JWA] for use with JWS or if any other constraints on its use are violated. When used, this Header Parameter MUST be integrity protected; therefore, it MUST occur only within the JWS Protected Header. Use of this Header Parameter is OPTIONAL. This Header Parameter MUST be understood and processed by implementations.
"crit"（クリティカル）ヘッダーパラメーターは、この仕様および[JWA]の拡張機能が使用されていることを示し、理解および処理しなければならない（MUST）ことを示します。その値は、これらの拡張機能を使用するJOSEヘッダーに存在するヘッダーパラメーター名のリストを示す配列です。リストされた拡張ヘッダーパラメーターのいずれかが受信者によって理解されず、サポートされていない場合、JWSは無効です。プロデューサーは、この仕様で定義されたヘッダーパラメーター名、またはJWSで使用するために[JWA]で定義された名前、重複した名前、または「crit」リスト内のJOSEヘッダー内のヘッダーパラメーター名として存在しない名前を使用してはなりません（MUST NOT）。プロデューサーは、空のリスト「[]」を「crit」値として使用してはなりません（MUST NOT）。受信者は、この仕様で定義されたヘッダーパラメーター名、またはJWSで使用するために[JWA]で定義された名前がクリティカルリストに含まれている場合、またはその使用に関するその他の制約が違反されている場合、JWSを無効と見なしてもよいです（MAY）。使用する場合、このヘッダーパラメーターは完全性保護されるため、JWS Protected Header内にのみ存在しなければなりません（MUST）。このヘッダーパラメーターの使用は選択できます（OPTIONAL）。このヘッダーパラメーターは、実装によって理解および処理しなければなりません（MUST）。
An example use, along with a hypothetical "exp" (expiration time) field is:
仮想の「exp」（有効期限）フィールドとともに使用する例は次のとおりです。
{"alg":"ES256",
"crit":["exp"],
"exp":1363284000
}
{"alg":"ES256",
"crit":["exp"],
"exp":1363284000
}
Additional Header Parameter names can be defined by those using JWSs. However, in order to prevent collisions, any new Header Parameter name should either be registered in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by Section 9.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 Header Parameter name.
JWSを使用する者は、追加のヘッダーパラメーター名を定義できます。ただし、衝突を防ぐために、新しいヘッダーパラメーター名は、セクション9.1で確立されたIANA「JSON Web Signature and Encryption Header Parameters」レジストリに登録されるか、衝突耐性のある名前を含む値であるパブリックネームである必要があります。いずれの場合も、名前または値の定義者は、ヘッダーパラメーター名を定義するために使用する名前空間の部分を制御していることを確認するために、合理的な注意を払う必要があります。
New Header Parameters should be introduced sparingly, as they can result in non-interoperable JWSs.
新しいヘッダーパラメーターは、相互運用性のないJWSを引き起こす可能性があるため、控えめに導入する必要があります。
A producer and consumer of a JWS may agree to use Header Parameter names that are Private Names (names that are not Registered Header Parameter names (Section 4.1)) or Public Header Parameter names (Section 4.2). Unlike Public Header Parameter names, Private Header Parameter names are subject to collision and should be used with caution.
JWSの生成者と検証者は、ヘッダーパラメーター名として、登録されたヘッダーパラメーター名（セクション4.1）でないプライベート名またはパブリックヘッダーパラメーター名（セクション4.2）を使用することに同意する場合があります。パブリックヘッダーパラメーター名とは異なり、プライベートヘッダーパラメーター名は衝突の可能性があり、注意して使用する必要があります。
To create a JWS, 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.
JWSを作成するには、次の手順を実行します。入力と出力の間に依存関係がない場合、手順の順序は重要ではありません。
1. Create the content to be used as the JWS Payload.
1. JWSペイロードとして使用するコンテンツを作成します。
2. Compute the encoded payload value BASE64URL(JWS Payload).
2. エンコードされたペイロード値BASE64URL(JWS Payload)を計算します。
3. Create the JSON object(s) containing the desired set of Header Parameters, which together comprise the JOSE Header (the JWS Protected Header and/or the JWS Unprotected Header).
3. JOSEヘッダー（JWS Protected Headerおよび/またはJWS Unprotected Header）を構成する所望のヘッダーパラメーターセットを含むJSONオブジェクトを作成します。
4. Compute the encoded header value BASE64URL(UTF8(JWS Protected Header)). If the JWS Protected Header is not present (which can only happen when using the JWS JSON Serialization and no "protected" member is present), let this value be the empty string.
4. エンコードされたヘッダー値BASE64URL(UTF8(JWS Protected Header))を計算します。JWS Protected Headerが存在しない場合（JWS JSON Serializationを使用していて、"protected"メンバーが存在しない場合にのみ発生する）、この値は空の文字列とします。
5. Compute the JWS Signature in the manner defined for the particular algorithm being used over the JWS Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)). The "alg" (algorithm) Header Parameter MUST be present in the JOSE Header, with the algorithm value accurately representing the algorithm used to construct the JWS Signature.
5. JWS Signatureを、JWS Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload))上で使用される特定のアルゴリズムで計算します。JOSEヘッダーには、アルゴリズム値が正確にJWS Signatureを構築するために使用されるアルゴリズムを表すように、"alg"（アルゴリズム）ヘッダーパラメーターが必ず含まれている必要があります。
6. Compute the encoded signature value BASE64URL(JWS Signature).
6. エンコードされたシグネチャ値BASE64URL(JWS Signature)を計算します。
7. If the JWS JSON Serialization is being used, repeat this process (steps 3-6) for each digital signature or MAC operation being performed.
7. JWS JSON Serializationを使用している場合、実行される各デジタル署名またはMAC操作について、このプロセス（手順3〜6）を繰り返します。
8. Create the desired serialized output. The JWS Compact Serialization of this result is BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature). The JWS JSON Serialization is described in Section 7.2.
8. 必要なシリアル化された出力を作成します。この結果のJWS Compact Serializationは、BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)です。JWS JSON Serializationについては、セクション7.2で説明されています。
When validating a JWS, 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 fails, then the signature or MAC cannot be validated.
JWSを検証する場合、以下の手順が実行されます。ステップの入力と出力に依存関係がない場合は、ステップの順序は重要ではありません。リストされたステップのいずれかが失敗した場合、署名またはMACを検証できません。
When there are multiple JWS Signature values, it is an application decision which of the JWS Signature values must successfully validate for the JWS to be accepted. In some cases, all must successfully validate, or the JWS will be considered invalid. In other cases, only a specific JWS Signature value needs to be successfully validated. However, in all cases, at least one JWS Signature value MUST successfully validate, or the JWS MUST be considered invalid.
複数のJWS Signature値がある場合、JWSが受け入れられるためには、どのJWS Signature値が正常に検証される必要があるかはアプリケーションの決定によるものです。場合によっては、すべてが正常に検証されなければJWSは無効と見なされます。他の場合では、特定のJWS Signature値のみが正常に検証される必要があります。ただし、すべての場合において、少なくとも1つのJWS Signature値が正常に検証されなければならず、そうでなければJWSは無効と見なされなければなりません。
1. Parse the JWS representation to extract the serialized values for the components of the JWS. When using the JWS Compact Serialization, these components are the base64url-encoded representations of the JWS Protected Header, the JWS Payload, and the JWS Signature, and when using the JWS JSON Serialization, these components also include the unencoded JWS Unprotected Header value. When using the JWS Compact Serialization, the JWS Protected Header, the JWS Payload, and the JWS Signature are represented as base64url-encoded values in that order, with each value being separated from the next by a single period ('.') character, resulting in exactly two delimiting period characters being used. The JWS JSON Serialization is described in Section 7.2.
1. JWS表現を解析して、JWSの各コンポーネントのシリアル化された値を抽出します。JWS Compact Serializationを使用する場合、これらのコンポーネントは、JWS Protected Header、JWS Payload、およびJWS Signatureのbase64urlエンコードされた表現です。JWS JSON Serializationを使用する場合、これらのコンポーネントには、未エンコードのJWS Unprotected Header値も含まれます。JWS Compact Serializationを使用する場合、JWS Protected Header、JWS Payload、およびJWS Signatureは、その順序でbase64urlエンコードされた値として表され、各値は単一のピリオド（'.'）文字で区切られ、正確に2つの区切りピリオド文字が使用されます。JWS JSON Serializationについては、セクション7.2を参照してください。
2. Base64url-decode the encoded representation of the JWS Protected Header, following the restriction that no line breaks, whitespace, or other additional characters have been used.
2. JWS Protected Headerのエンコードされた表現をbase64urlデコードし、改行、空白、またはその他の追加文字が使用されていない制限に従います。
3. 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 JWS Protected Header be this JSON object.
3. 結果のオクテットシーケンスが、RFC 7159 [RFC7159]に準拠した完全に有効なJSONオブジェクトのUTF-8エンコードされた表現であることを検証します。このJSONオブジェクトがJWS Protected Headerです。
4. If using the JWS Compact Serialization, let the JOSE Header be the JWS Protected Header. Otherwise, when using the JWS JSON Serialization, let the JOSE Header be the union of the members of the corresponding JWS Protected Header and JWS Unprotected Header, all of which must be completely valid JSON objects. During this step, verify that the resulting JOSE Header does not contain duplicate Header Parameter names. When using the JWS JSON Serialization, this restriction includes that the same Header Parameter name also MUST NOT occur in distinct JSON object values that together comprise the JOSE Header.
4. JWS Compact Serializationを使用する場合、JOSEヘッダーはJWS Protected Headerとなります。JWS JSON Serializationを使用する場合、JOSEヘッダーは、対応するJWS Protected HeaderとJWS Unprotected Headerのメンバーの和集合とします。これらすべてが完全に有効なJSONオブジェクトである必要があります。このステップでは、JOSEヘッダーが重複するヘッダーパラメーター名を含まないことを確認します。JWS JSON Serializationを使用する場合、この制限には、同じヘッダーパラメーター名がJOSEヘッダーを構成する別のJSONオブジェクト値にも現れてはならないという制限も含まれます。
5. Verify that the implementation understands and can process all fields that it is required to support, whether required by this specification, by the algorithm being used, or by the "crit" Header Parameter value, and that the values of those parameters are also understood and supported.
5. 実装がサポートする必要があるすべてのフィールドを理解し、処理できることを確認します。これらは、この仕様、使用されるアルゴリズム、または「crit」ヘッダーパラメーター値によって必要とされるものです。また、これらのパラメーターの値が理解され、サポートされていることも確認します。
6. Base64url-decode the encoded representation of the JWS Payload, following the restriction that no line breaks, whitespace, or other additional characters have been used.
6. JWSペイロードのエンコードされた表現をbase64urlデコードし、改行、空白、またはその他の追加文字が使用されていない制限に従います。
7. Base64url-decode the encoded representation of the JWS Signature, following the restriction that no line breaks, whitespace, or other additional characters have been used.
7. JWS Signatureのエンコードされた表現をbase64urlデコードし、改行、空白、またはその他の追加文字が使用されていない制限に従います。
8. Validate the JWS Signature against the JWS Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)) in the manner defined for the algorithm being used, which MUST be accurately represented by the value of the "alg" (algorithm) Header Parameter, which MUST be present. See Section 10.6 for security considerations on algorithm validation. Record whether the validation succeeded or not.
8. 使用されているアルゴリズムに応じて、JWS SignatureをJWS署名入力ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload))に対して検証し、その方法を定義された方法で行います。アルゴリズムは、"alg"（アルゴリズム）ヘッダーパラメーターの値で正確に表され、必ず存在する必要があります（MUST）。アルゴリズムの検証に関するセキュリティー上の考慮事項については、セクション10.6を参照してください。検証が成功したかどうかを記録します。
9. If the JWS JSON Serialization is being used, repeat this process (steps 4-8) for each digital signature or MAC value contained in the representation.
9. JWS JSON Serializationを使用している場合、このプロセス（ステップ4〜8）を、表現に含まれる各デジタル署名またはMAC値に対して繰り返します。
10. If none of the validations in step 9 succeeded, then the JWS MUST be considered invalid. Otherwise, in the JWS JSON Serialization case, return a result to the application indicating which of the validations succeeded and failed. In the JWS Compact Serialization case, the result can simply indicate whether or not the JWS was successfully validated.
10. ステップ9での検証がすべて失敗した場合、JWSは無効と見なされなければなりません。それ以外の場合、JWS JSON Serializationの場合、アプリケーションに、どの検証が成功し、どの検証が失敗したかを示す結果を返します。JWS Compact Serializationの場合、結果は、JWSが正常に検証されたかどうかを単に示すことができます。
Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD consider the JWS to be invalid.
最後に、特定のコンテキストで使用できるアルゴリズムは、アプリケーションの決定によるものです。JWSが正常に検証されたとしても、JWSで使用されるアルゴリズムがアプリケーションにとって許容可能でない場合、JWSは無効と見なすべきです。
Processing a JWS inevitably requires comparing known strings to members and values in JSON objects. For example, in checking what the algorithm is, the Unicode string "alg" will be checked against the member names in the JOSE Header to see if there is a matching Header Parameter name. The same process is then used to determine if the value of the "alg" Header Parameter represents a supported algorithm.
JWSの処理には、既知の文字列をJSONオブジェクトのメンバーや値と比較する必要があります。たとえば、アルゴリズムが何であるかを確認する場合、Unicode文字列「alg」は、JOSEヘッダーのメンバー名と照合され、一致するヘッダーパラメーター名があるかどうかを確認します。その後、同じプロセスが使用され、algヘッダーパラメーターの値がサポートされているアルゴリズムを表しているかどうかを判断します。
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のセクション8.3で説明されています[RFC7159]。比較演算には等価性と非等価性のみが行われるため、既知の文字列とメンバー名およびメンバー値を比較するために同じルールが使用できます。
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. Only the "typ" and "cty" member values defined in this specification 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 a "kid" (key ID) 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.)
一部のアプリケーションでは、DNS名を「kid」（キーID）値の一部として含めるなど、大文字小文字を区別する値に大文字小文字を含める場合があります。その場合、複数のパーティが同じ値を生成する必要がある場合は、大文字小文字を小文字に変換するなど、大文字小文字を区別しない部分を表すための正準的なケースの定義が必要になる場合があります。ただし、他のすべてのパーティが、独立して生成された値と比較することなく、生成パーティが出力した値をそのまま消費する場合は、生成者が使用したケースは問題ありません。
Also, see the JSON security considerations in Section 10.12 and the Unicode security considerations in Section 10.13.
また、セクション10.12のJSONセキュリティーに関する考慮事項およびセクション10.13のUnicodeセキュリティーに関する考慮事項も参照してください。
It is necessary for the recipient of a JWS to be able to determine the key that was employed for the digital signature or MAC operation. The key employed can be identified using the Header Parameter methods described in Section 4.1 or can be identified using methods that are outside the scope of this specification. Specifically, the Header Parameters "jku", "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256" can be used to identify the key used. These Header Parameters MUST be integrity protected if the information that they convey is to be utilized in a trust decision; however, if the only information used in the trust decision is a key, these parameters need not be integrity protected, since changing them in a way that causes a different key to be used will cause the validation to fail.
JWSの受信者は、デジタル署名またはMAC操作に使用された鍵を特定できる必要があります。使用されたキーは、セクション4.1で説明されているヘッダーパラメーターの方法を使用して識別できます。または、この仕様の範囲外の方法を使用して識別できます。具体的には、ヘッダーパラメーター「jku」、「jwk」、「kid」、「x5u」、「x5c」、「x5t」、および「x5t#S256」を使用して、使用されたキーを識別できます。これらのヘッダーパラメーターは、信頼判断に使用される情報を伝達する場合、整合性が保護される必要があります（MUST）。ただし、信頼判断に使用される情報がキーのみである場合、これらのパラメーターは整合性が保護される必要はありません。これらのパラメーターを変更して異なるキーが使用されるようにすると、検証が失敗するためです。
The producer SHOULD include sufficient information in the Header Parameters to identify the key used, unless the application uses another means or convention to determine the key used. Validation of the signature or MAC fails when the algorithm used requires a key (which is true of all algorithms except for "none") and the key used cannot be determined.
生成者は、キーを特定するための十分な情報をヘッダーパラメーターに含めるべきです（SHOULD）。ただし、アプリケーションがキーを特定するために別の手段または規約を使用する場合は、これらのパラメーターを使用する必要はありません。使用されたアルゴリズムがキーを必要とする場合（「none」を除くすべてのアルゴリズムが該当）、使用されたキーが特定できない場合、署名またはMACの検証が失敗します。
The means of exchanging any shared symmetric keys used is outside the scope of this specification.
共有対称鍵の交換手段は、この仕様の範囲外です。
Also, see Appendix D for notes on possible key selection algorithms.
また、キー選択アルゴリズムに関する注意事項については、付録Dを参照してください。
JWSs use one of two serializations: the JWS Compact Serialization or the JWS JSON Serialization. Applications using this specification need to specify what serialization and serialization features are used for that application. For instance, applications might specify that only the JWS JSON Serialization is used, that only JWS JSON Serialization support for a single signature or MAC value is used, or that support for multiple signatures and/or MAC values is used. JWS implementations only need to implement the features needed for the applications they are designed to support.
JWSは、JWS Compact SerializationまたはJWS JSON Serializationのいずれかのシリアル化を使用します。この仕様を使用するアプリケーションは、そのアプリケーションで使用されるシリアル化およびシリアル化機能を指定する必要があります。たとえば、アプリケーションは、JWS JSON Serializationのみが使用されること、単一の署名またはMAC値のJWS JSON Serializationサポートのみが使用されること、または複数の署名および/またはMAC値のサポートが使用されることを指定できます。JWSの実装は、サポートするアプリケーションに必要な機能のみを実装する必要があります。ただし、この仕様で定義されている機能を実装する必要があります。
The JWS Compact Serialization represents digitally signed or MACed content as a compact, URL-safe string. This string is:
JWSコンパクトシリアル化は、デジタル署名またはMAC操作されたコンテンツをコンパクトでURLセーフな文字列として表します。この文字列は次のとおりです。
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)
Only one signature/MAC is supported by the JWS Compact Serialization and it provides no syntax to represent a JWS Unprotected Header value.
JWSコンパクトシリアル化では、1つの署名/MACのみがサポートされ、JWS非保護ヘッダーの値を表す構文は提供されていません。
The JWS JSON Serialization represents digitally signed or MACed content as a JSON object. This representation is neither optimized for compactness nor URL-safe.
JWS JSONシリアル化は、デジタル署名またはMAC操作されたコンテンツをJSONオブジェクトとして表します。この表現は、コンパクトさやURLセーフさを最適化するわけではありません。
Two closely related syntaxes are defined for the JWS JSON Serialization: a fully general syntax, with which content can be secured with more than one digital signature and/or MAC operation, and a flattened syntax, which is optimized for the single digital signature or MAC case.
JWS JSONシリアル化には、2つの関連する構文が定義されています。1つは完全な一般的な構文であり、この構文では、コンテンツを1つ以上のデジタル署名および/またはMAC操作で保護できます。もう1つはフラット化された構文であり、単一のデジタル署名またはMAC操作の場合に最適化されています。
The following members are defined for use in top-level JSON objects used for the fully general JWS JSON Serialization syntax:
完全な一般的なJWS JSONシリアル化構文に使用されるトップレベルJSONオブジェクトには、次のメンバーが定義されています。
payload The "payload" member MUST be present and contain the value BASE64URL(JWS Payload).
payload 「payload」メンバーはMUST存在し、値にはBASE64URL(JWS Payload)が含まれている必要があります。
signatures The "signatures" member value MUST be an array of JSON objects. Each object represents a signature or MAC over the JWS Payload and the JWS Protected Header.
signatures 「signatures」メンバーの値は、JSONオブジェクトの配列である必要があります。MUST各オブジェクトは、JWSペイロードとJWS保護ヘッダーに対する署名またはMACを表します。
The following members are defined for use in the JSON objects that are elements of the "signatures" array:
「signatures」配列の要素であるJSONオブジェクトで使用するために、次のメンバーが定義されています。
protected The "protected" member MUST be present and contain the value BASE64URL(UTF8(JWS Protected Header)) when the JWS Protected Header value is non-empty; otherwise, it MUST be absent. These Header Parameter values are integrity protected.
protected 「protected」メンバーは、JWS保護ヘッダーの値が空でない場合はBASE64URL(UTF8(JWS Protected Header))の値を含まなければなりません。MUST一方、JWS保護ヘッダーの値が空の場合は、省略する必要があります。これらのヘッダーパラメーターの値は、整合性が保護されます。
header The "header" member MUST be present and contain the value JWS Unprotected Header when the JWS Unprotected Header value is non- empty; otherwise, it MUST be absent. This value is represented as an unencoded JSON object, rather than as a string. These Header Parameter values are not integrity protected.
header 「header」メンバーはMUST存在し、JWS Unprotected Header値が空でない場合は値にJWS Unprotected Headerを含め、それ以外の場合は省略する必要があります。この値は、文字列ではなくエンコードされていないJSONオブジェクトとして表されます。これらのヘッダーパラメーターの値は、整合性が保護されません。
signature The "signature" member MUST be present and contain the value BASE64URL(JWS Signature).
signature 「signature」メンバーはMUST存在し、値にはBASE64URL(JWS Signature)が含まれている必要があります。
At least one of the "protected" and "header" members MUST be present for each signature/MAC computation so that an "alg" Header Parameter value is conveyed.
「protected」と「header」の少なくとも1つのメンバーは、各署名/MAC計算に対してMUST存在する必要があります。これにより、「alg」ヘッダーパラメーターの値が伝達されます。
Additional members can be present in both the JSON objects defined above; if not understood by implementations encountering them, they MUST be ignored.
上記で定義されたJSONオブジェクトの両方には、追加のメンバーが存在する場合があります。実装がこれらのメンバーを理解できない場合、これらはMUST無視される必要があります。
The Header Parameter values used when creating or validating individual signature or MAC values are the union of the two sets of Header Parameter values that may be present: (1) the JWS Protected Header represented in the "protected" member of the signature/MAC's array element, and (2) the JWS Unprotected Header in the "header" member of the signature/MAC's array element. The union of these sets of Header Parameters comprises the JOSE Header. The Header Parameter names in the two locations MUST be disjoint.
個々の署名またはMAC値を作成または検証する際に使用されるヘッダーパラメーター値は、2つのヘッダーパラメーター値の和集合である必要があります。1つ目は、署名/MACの配列要素の「protected」メンバーに表されるJWS保護ヘッダーであり、2つ目は、署名/MACの配列要素の「header」メンバーにあるJWS非保護ヘッダーです。これらのヘッダーパラメーターの和集合は、JOSEヘッダーを構成します。2つの場所のヘッダーパラメーター名は、MUST互いに素である必要があります。
Each JWS Signature value is computed using the parameters of the corresponding JOSE Header value in the same manner as for the JWS Compact Serialization. This has the desirable property that each JWS Signature value represented in the "signatures" array is identical to the value that would have been computed for the same parameter in the JWS Compact Serialization, provided that the JWS Protected Header value for that signature/MAC computation (which represents the integrity-protected Header Parameter values) matches that used in the JWS Compact Serialization.
各JWS Signature値は、JWS Compact Serializationと同じ方法で、同じJOSEヘッダー値のパラメーターを使用して計算されます。これにより、「signatures」配列に表される各JWS Signature値は、その署名/MAC計算のために使用されたJWS保護ヘッダー値（整合性保護されたヘッダーパラメーター値を表す）がJWS Compact Serializationで使用されたものと一致する場合、同じパラメーターで計算された値と同じになるという望ましい特性があります。
In summary, the syntax of a JWS using the general JWS JSON Serialization is as follows:
要約すると、一般的なJWS JSONシリアル化を使用したJWSの構文は次のようになります。
{
"payload":"<payload contents>",
"signatures":[
{"protected":"<integrity-protected header 1 contents>",
"header":<non-integrity-protected header 1 contents>,
"signature":"<signature 1 contents>"},
...
{"protected":"<integrity-protected header N contents>",
"header":<non-integrity-protected header N contents>,
"signature":"<signature N contents>"}]
}
{
"payload":"<payload contents>",
"signatures":[
{"protected":"<integrity-protected header 1 contents>",
"header":<non-integrity-protected header 1 contents>,
"signature":"<signature 1 contents>"},
...
{"protected":"<integrity-protected header N contents>",
"header":<non-integrity-protected header N contents>,
"signature":"<signature N contents>"}]
}
See Appendix A.6 for an example JWS using the general JWS JSON Serialization syntax.
一般的なJWS JSONシリアル化構文を使用したJWSの例については、付録A.6を参照してください。
The flattened JWS JSON Serialization syntax is based upon the general syntax but flattens it, optimizing it for the single digital signature/MAC case. It flattens it by removing the "signatures" member and instead placing those members defined for use in the "signatures" array (the "protected", "header", and "signature" members) in the top-level JSON object (at the same level as the "payload" member).
フラット化されたJWS JSONシリアル化構文は、一般的な構文に基づいていますが、単一のデジタル署名/MACの場合に最適化するためにフラット化します。これは、「signatures」メンバーを削除し、代わりに「signatures」配列で使用されるメンバー（「protected」、「header」、および「signature」メンバー）をトップレベルのJSONオブジェクト（「payload」メンバーと同じレベル）に配置することによってフラット化されます。
The "signatures" member MUST NOT be present when using this syntax. Other than this syntax difference, JWS JSON Serialization objects using the flattened syntax are processed identically to those using the general syntax.
この構文を使用する場合、「signatures」メンバーはMUST NOT存在してはなりません。 この構文の違い以外は、フラット化された構文を使用するJWS JSONシリアル化オブジェクトは、一般的な構文を使用するものと同じように処理されます。
In summary, the syntax of a JWS using the flattened JWS JSON Serialization is as follows:
フラット化されたJWS JSONシリアル化を使用したJWSの構文は、次のようになります。
{
"payload":"<payload contents>",
"protected":"<integrity-protected header contents>",
"header":<non-integrity-protected header contents>,
"signature":"<signature contents>"
}
{
"payload":"<payload contents>",
"protected":"<integrity-protected header contents>",
"header":<non-integrity-protected header contents>,
"signature":"<signature contents>"
}
See Appendix A.7 for an example JWS using the flattened JWS JSON Serialization syntax.
フラット化されたJWS JSONシリアル化構文を使用したJWSの例については、付録A.7を参照してください。
Implementations supporting the "jku" and/or "x5u" Header Parameters MUST support TLS. Which TLS version(s) ought to be implemented will vary over time and depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version.
"jku"および/または"x5u"ヘッダーパラメーターをサポートする実装は、TLSをサポートするMUSTです。実装されるTLSバージョンは、時間の経過とともに変化し、実装時の広範な展開と既知のセキュリティー脆弱性に依存します。この記述時点では、TLSバージョン1.2 [RFC5246]が最新のバージョンです。
To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection. See current publications by the IETF TLS working group, including RFC 6176 [RFC6176], for guidance on the ciphersuites currently considered to be appropriate for use. Also, see "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [RFC7525] for recommendations on improving the security of software and services using TLS.
情報漏洩と改ざんから保護するために、機密性保護には、機密性と整合性保護を提供する暗号スイートを使用したTLSが適用されるMUSTです。現在、使用するのに適切と考えられる暗号スイートに関するガイダンスについては、RFC 6176 [RFC6176]を含む、IETF TLSワーキンググループによる現在の出版物を参照してください。また、TLSを使用するソフトウェアおよびサービスのセキュリティーを向上させるための推奨事項については、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用の推奨事項」[RFC7525]を参照してください。
Whenever TLS is used, the identity of the service provider encoded in the TLS server certificate MUST be verified using the procedures described in Section 6 of RFC 6125 [RFC6125].
TLSを使用する場合、TLSサーバー証明書にエンコードされたサービスプロバイダーの識別子は、RFC 6125のセクション6で説明されている手順を使用して検証する必要があります。MUSTです。
The following registration procedure is used for all the registries established by this specification.
この仕様で設立されたすべての登録には、以下の登録手順が使用されます。
Values are registered on a Specification Required [RFC5226] basis after a three-week review period on the jose-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.
値は、1つまたは複数の指定専門家のアドバイスに基づいて、jose-reg-review@ietf.orgメーリングリストでの3週間のレビュー期間の後、仕様に必要な値として登録されます。[RFC5226]ただし、公開前に値を割り当てるために、指定専門家は、そのような仕様が公開されることを確信した場合に、登録を承認することができます。
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register header parameter: example").
レビュー用のメーリングリストに送信される登録リクエストは、適切な件名（例：「ヘッダーパラメーターの登録リクエスト：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に通知されることがあります（iesg@ietf.orgメーリングリストを使用）。
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 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.
この仕様を使用するさまざまなアプリケーションの視点を代表できる複数の指定専門家を任命し、登録決定の広範な情報提供を可能にすることが提案されています。登録決定が特定の専門家にとって利益相反を引き起こす可能性がある場合は、その専門家は他の専門家の判断に従う必要があります。
This specification establishes the IANA "JSON Web Signature and Encryption Header Parameters" registry for Header Parameter names. The registry records the Header Parameter name and a reference to the specification that defines it. The same Header Parameter name can be registered multiple times, provided that the parameter usage is compatible between the specifications. Different registrations of the same Header Parameter name will typically use different Header Parameter Usage Locations values.
この仕様では、ヘッダーパラメーター名のためのIANA「JSON Web Signature and Encryption Header Parameters」レジストリが設立されます。レジストリには、ヘッダーパラメーター名と、それを定義する仕様への参照が記録されます。同じヘッダーパラメーター名は、パラメーターの使用法が仕様間で互換性がある場合に限り、複数回登録できます。同じヘッダーパラメーター名の異なる登録は、通常、異なるヘッダーパラメーター使用場所値を使用します。
Header Parameter Name: The name requested (e.g., "kid"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- 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.
ヘッダーパラメーター名： 要求された名前（例："kid"）。この仕様の主要な目標の1つは、生成された表現がコンパクトであることですので、名前は短くすることが推奨されます。特別な理由がない限り、8文字を超えないようにしてください。この名前は大文字と小文字を区別します。登録された他の名前と大文字と小文字を区別しない場合は、指定専門家が例外を許可する理由があると判断した場合を除き、使用できません。
Header Parameter Description: Brief description of the Header Parameter (e.g., "Key ID").
ヘッダーパラメーターの説明： ヘッダーパラメーターの簡単な説明（例：「キーID」）。
Header Parameter Usage Location(s): The Header Parameter usage locations, which should be one or more of the values "JWS" or "JWE".
ヘッダーパラメーターの使用場所： ヘッダーパラメーターの使用場所。値は「JWS」または「JWE」のいずれか1つ以上である必要があります。
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.
変更管理者： 標準トラック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.
仕様書： パラメーターを指定するドキュメントへの参照。できれば、ドキュメントのコピーを取得するために使用できるURIも含めることが望ましいです。関連するセクションの指示も含めることができますが、必須ではありません。
This section registers the Header Parameter names defined in Section 4.1 in this registry.
このセクションでは、このレジストリに定義されたヘッダーパラメーター名を、セクション4.1で登録します。
This section registers the "application/jose" 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 JWS or JWE using the JWS Compact Serialization or the JWE Compact Serialization. This section also registers the "application/ jose+json" media type in the "Media Types" registry, which can be used to indicate that the content is a JWS or JWE using the JWS JSON Serialization or the JWE JSON Serialization.
このセクションでは、JWS Compact SerializationまたはJWE Compact Serializationを使用してJWSまたはJWEであることを示すために使用できる、RFC 6838で説明されている方法で、「Media Types」レジストリ[IANA.MediaTypes]に「application/jose」メディアタイプ[RFC2046]を登録します。このセクションでは、「Media Types」レジストリに「application/jose+json」メディアタイプも登録され、JWS JSON SerializationまたはJWE JSON Serializationを使用してJWSまたはJWEであることを示すために使用できます。
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
マジックナンバー：なし
ファイル拡張子：なし
Macintoshファイルタイプコード：なし
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
マジックナンバー：なし
ファイル拡張子：なし
Macintoshファイルタイプコード：なし
All of the security issues that are pertinent to any cryptographic application must be addressed by JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys and employing countermeasures to various attacks.
JWS/JWE/JWKエージェントは、暗号化アプリケーションに関連するすべてのセキュリティー上の問題に対処する必要があります。これらの問題の中には、ユーザーの非対称秘密鍵と対称秘密鍵を保護すること、およびさまざまな攻撃に対する対策を講じることが含まれます。
All the security considerations in "XML Signature Syntax and Processing Version 2.0" [W3C.NOTE-xmldsig-core2-20130411], also apply to this specification, other than those that are XML specific. Likewise, many of the best practices documented in "XML Signature Best Practices" [W3C.NOTE-xmldsig-bestpractices-20130411] also apply to this specification, other than those that are XML specific.
"XML Signature Syntax and Processing Version 2.0" [W3C.NOTE-xmldsig-core2-20130411]に記載されているすべてのセキュリティー上の考慮事項は、XML固有のものを除いて、この仕様にも適用されます。同様に、「XML Signature Best Practices」[W3C.NOTE-xmldsig-bestpractices-20130411]に記載されている多くのベストプラクティスも、XML固有のものを除いて、この仕様にも適用されます。
Keys are only as strong as the amount of entropy used to generate them. A minimum of 128 bits of entropy should be used for all keys, and depending upon the application context, more may be required.
鍵の強度は、生成に使用されるエントロピーの量によって決まります。すべての鍵には、少なくとも128ビットのエントロピーを使用する必要があり、アプリケーションの文脈に応じて、それ以上が必要になる場合があります。
Implementations must randomly generate public/private key pairs, MAC keys, and padding values. The use of inadequate pseudorandom number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities rather than brute-force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RFC4086] offers important guidance in this area.
実装は、公開/秘密鍵ペア、MAC鍵、およびパディング値をランダムに生成する必要があります。暗号鍵を生成するために不適切な疑似乱数生成器（PRNG）を使用すると、ほとんどまたはまったくセキュリティーが確保されません。攻撃者は、鍵を生成したPRNG環境を再現することがはるかに容易であるため、全鍵空間を総当たりするよりも、その結果得られる少数の可能性を探索することができます。質の高いランダム数値の生成は困難です。RFC 4086 [RFC4086]は、この分野で重要な指針を提供しています。
Implementations must protect the signer's private key. Compromise of the signer's private key permits an attacker to masquerade as the signer.
実装は署名者の秘密鍵を保護する必要があります。署名者の秘密鍵が漏洩すると、攻撃者は署名者として偽装することができます。
Implementations must protect the MAC key. Compromise of the MAC key may result in undetectable modification of the authenticated content.
実装はMAC鍵を保護する必要があります。MAC鍵が漏洩すると、認証されたコンテンツの検出不能な変更が発生する可能性があります。
The key management technique employed to obtain public keys must authenticate the origin of the key; otherwise, it is unknown what party signed the message.
公開鍵を取得するために使用される鍵管理技術は、鍵の起源を認証する必要があります。そうでない場合、メッセージに署名した当事者が不明です。
Likewise, the key management technique employed to distribute MAC keys must provide data origin authentication; otherwise, the contents are delivered with integrity from an unknown source.
同様に、MAC鍵を配布するために使用される鍵管理技術は、データの起源認証を提供する必要があります。そうでない場合、コンテンツは未知のソースからの整合性が保証されたものとして配信されます。
While MACs and digital signatures can both be used for integrity checking, there are some significant differences between the security properties that each of them provides. These need to be taken into consideration when designing protocols and selecting the algorithms to be used in protocols.
MACとデジタル署名は、両方とも整合性チェックに使用できますが、それぞれが提供するセキュリティープロパティにはいくつかの重要な違いがあります。プロトコルの設計やプロトコルで使用するアルゴリズムの選択に際しては、これらを考慮する必要があります。
Both signatures and MACs provide for integrity checking -- verifying that the message has not been modified since the integrity value was computed. However, MACs provide for origination identification only under specific circumstances. It can normally be assumed that a private key used for a signature is only in the hands of a single entity (although perhaps a distributed entity, in the case of replicated servers); however, a MAC key needs to be in the hands of all the entities that use it for integrity computation and checking. Validation of a MAC only provides corroboration that the message was generated by one of the parties that knows the symmetric MAC key. This means that origination can only be determined if a MAC key is known only to two entities and the recipient knows that it did not create the message. MAC validation cannot be used to prove origination to a third party.
署名とMACは、両方とも整合性チェックに使用できますが、それぞれが提供するセキュリティープロパティにはいくつかの重要な違いがあります。署名に使用される秘密鍵は、通常、単一のエンティティ（複製されたサーバーの場合を除く）の手にしかないと想定できます。一方、MAC鍵は、整合性計算とチェックに使用するすべてのエンティティの手にある必要があります。MACの検証は、対称MAC鍵を知っている当事者のうちの1つによってメッセージが生成されたことを確認するだけであり、起源の特定は特定の状況下でのみ可能です。MAC鍵が2つのエンティティにしか知られておらず、受信者がメッセージを作成していないことを知っている場合にのみ、起源を特定できます。MACの検証は、第三者に起源を証明するために使用できません。
The digital signature representations for some algorithms include information about the algorithm used inside the signature value. For instance, signatures produced with RSASSA-PKCS1-v1_5 [RFC3447] encode the hash function used, and many libraries actually use the hash algorithm specified inside the signature when validating the signature. When using such libraries, as part of the algorithm validation performed, implementations MUST ensure that the algorithm information encoded in the signature corresponds to that specified with the "alg" Header Parameter. If this is not done, an attacker could claim to have used a strong hash algorithm while actually using a weak one represented in the signature value.
一部のアルゴリズムに対するデジタル署名表現には、署名値内で使用されたアルゴリズムに関する情報が含まれています。たとえば、RSASSA-PKCS1-v1_5 [RFC3447]で生成された署名は、使用されたハッシュ関数をエンコードしています。多くのライブラリは、実際には署名内で指定されたハッシュアルゴリズムを使用して署名を検証します。このようなライブラリを使用する場合、実装はアルゴリズムの検証の一環として、署名にエンコードされたアルゴリズム情報が「alg」ヘッダーパラメーターで指定されたものと一致することを必ず確認しなければなりません。そうしないと、攻撃者は、署名値に表された弱いハッシュアルゴリズムを使用しているにもかかわらず、強いハッシュアルゴリズムを使用したと主張することができます。
In some usages of JWS, there is a risk of algorithm substitution attacks, in which an attacker can use an existing digital signature value with a different signature algorithm to make it appear that a signer has signed something that it has not. These attacks have been discussed in detail in the context of Cryptographic Message Syntax (CMS) [RFC6211]. This risk arises when all of the following are true:
JWSの一部の用途では、アルゴリズムの代替攻撃のリスクがあります。この攻撃では、攻撃者は既存のデジタル署名値を別の署名アルゴリズムで使用して、署名者が署名していないものに署名したように見せかけることができます。この攻撃については、暗号メッセージ構文（CMS）[RFC6211]の文脈で詳しく説明されています。このリスクは、次のすべてが真である場合に発生します。
There are several ways for an application to mitigate algorithm substitution attacks:
アプリケーションがアルゴリズムの代替攻撃を緩和するためのいくつかの方法があります。
Creators of JWSs should not allow third parties to insert arbitrary content into the message without adding entropy not controlled by the third party.
JWSの作成者は、第三者が制御していないエントロピーを追加しない限り、メッセージに任意のコンテンツを挿入することを許可すべきではありません。
When cryptographic algorithms are implemented in such a way that successful operations take a different amount of time than unsuccessful operations, attackers may be able to use the time difference to obtain information about the keys employed. Therefore, such timing differences must be avoided.
暗号アルゴリズムが、成功した操作と失敗した操作で異なる時間を要するように実装されている場合、攻撃者は時間差を利用して使用される鍵に関する情報を取得できる可能性があります。したがって、このようなタイミングの違いは避ける必要があります。
While not directly in scope for this specification, note that applications using JWS (or JWE) objects can thwart replay attacks by including a unique message identifier as integrity-protected content in the JWS (or JWE) message and having the recipient verify that the message has not been previously received or acted upon.
この仕様の直接の範囲外であるが、JWS（またはJWE）オブジェクトを使用するアプリケーションは、JWS（またはJWE）メッセージに一意のメッセージ識別子を含め、受信者がメッセージが以前に受信または処理されていないことを確認することで、再生攻撃を防止できます。
A SHA-1 hash is used when computing "x5t" (X.509 certificate SHA-1 thumbprint) values, for compatibility reasons. Should an effective means of producing SHA-1 hash collisions be developed and should an attacker wish to interfere with the use of a known certificate on a given system, this could be accomplished by creating another certificate whose SHA-1 hash value is the same and adding it to the certificate store used by the intended victim. A prerequisite to this attack succeeding is the attacker having write access to the intended victim's certificate store.
互換性のために、"x5t"（X.509証明書SHA-1サムプリント）値を計算するときに、SHA-1ハッシュが使用されます。SHA-1ハッシュの衝突を効果的に生成する手段が開発され、攻撃者が特定のシステム上で既知の証明書の使用に干渉したい場合、攻撃者は、SHA-1ハッシュ値が同じである別の証明書を作成し、意図した被害者が使用する証明書ストアに追加することで、これを達成できます。この攻撃が成功するための前提条件は、攻撃者が意図した被害者の証明書ストアに書き込みアクセス権を持っていることです。
Alternatively, the "x5t#S256" (X.509 certificate SHA-256 thumbprint) Header Parameter could be used instead of "x5t". However, at the time of this writing, no development platform is known to support SHA-256 certificate thumbprints.
"x5t"の代わりに、"x5t#S256"（X.509証明書SHA-256サムプリント）ヘッダーパラメーターを使用することもできます。ただし、この執筆時点では、SHA-256証明書サムプリントをサポートする開発プラットフォームは知られていません。
Strict JSON [RFC7159] validation is a security requirement. If malformed JSON is received, then the intent of the producer is impossible to reliably discern. Ambiguous and potentially exploitable situations could arise if the JSON parser used does not reject malformed JSON syntax. In particular, any JSON inputs not conforming to the JSON-text syntax defined in RFC 7159 MUST be rejected in their entirety by JSON parsers.
厳密なJSON [RFC7159]の検証は、セキュリティー上の要件です。不正なJSONが受信された場合、生産者の意図を確実に把握するのは不可能です。JSONパーサーが不正なJSON構文を拒否しない場合、曖昧で潜在的に悪用される状況が発生する可能性があります。とくに、RFC 7159で定義されたJSONテキスト構文に準拠していないJSON入力は、JSONパーサーによって完全に拒否される必要があります（MUST）。
Section 4 of "The JavaScript Object Notation (JSON) Data Interchange Format" [RFC7159] states, "The names within an object SHOULD be unique", whereas this specification states that
「JavaScript Object Notation（JSON）データ交換形式」[RFC7159]のセクション4には、「オブジェクト内の名前は一意である必要があります」と記載されていますが、この仕様では、
The Header Parameter names within the JOSE Header MUST be unique;
JWS parsers MUST either reject JWSs with duplicate Header
Parameter 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].
JOSEヘッダー内のヘッダーパラメーター名は一意でなければならず、 JWSパーサーは、重複するヘッダーパラメーター名を持つJWSを拒否するか、 ECMAScript 5.1 [ECMAScript]のセクション15.12（「JSONオブジェクト」）で指定されているように、 字句的に最後の重複メンバー名のみを返すJSONパーサーを使用する必要があります。
Thus, this specification requires that the "SHOULD" in Section 4 of [RFC7159] be treated as a "MUST" by producers and that it be either treated as a "MUST" or treated in the manner specified in ECMAScript 5.1 by consumers. Ambiguous and potentially exploitable situations could arise if the JSON parser used does not enforce the uniqueness of member names or returns an unpredictable value for duplicate member names.
Some JSON parsers might not reject input that contains extra significant characters after a valid input. For instance, the input "{"tag":"value"}ABCD" contains a valid JSON-text object followed by the extra characters "ABCD". Implementations MUST consider JWSs containing such input to be invalid.
一部のJSONパーサーは、有効な入力の後に余分な有意義な文字を含む入力を拒否しない場合があります。たとえば、「{ "tag": "value"} ABCD」という入力は、有効なJSONテキストオブジェクトに続いて余分な文字「ABCD」が含まれています。実装は、このような入力を含むJWSを無効とする必要がありますMUST。
Header Parameter names and algorithm names are Unicode strings. For security reasons, the representations of these names must be compared verbatim after performing any escape processing (as per Section 8.3 of RFC 7159 [RFC7159]). This means, for instance, that these JSON strings must compare as being equal ("sig", "\u0073ig"), whereas these must all compare as being not equal to the first set or to each other ("SIG", "Sig", "si\u0047").
ヘッダーパラメーター名とアルゴリズム名はUnicode文字列です。セキュリティー上の理由から、これらの名前の表現は、エスケープ処理（RFC 7159のセクション8.3に従って）を実行した後に、そのまま比較する必要があります。つまり、これらのJSON文字列は等しいとして比較される必要があります（「sig」、「\u0073ig」）。一方、これらはすべて、最初のセットまたはお互いに等しくないとして比較される必要があります（「SIG」、「Sig」、「si\u0047」）。
JSON strings can contain characters outside the Unicode Basic Multilingual Plane. For instance, the G clef character (U+1D11E) may be represented in a JSON string as "\uD834\uDD1E". Ideally, JWS implementations SHOULD ensure that characters outside the Basic Multilingual Plane are preserved and compared correctly; alternatively, if this is not possible due to these characters exercising limitations present in the underlying JSON implementation, then input containing them MUST be rejected.
JSON文字列には、Unicode基本多言語面の外の文字が含まれる場合があります。たとえば、Gクレフ文字（U+1D11E）はJSON文字列で「\uD834\uDD1E」として表現されることがあります。理想的には、JWS実装は、基本多言語面の外の文字が正しく保存および比較されるようにSHOULDを確実にする必要があります。また、基礎となるJSON実装に存在する制限により、これが不可能な場合は、これらの文字を含む入力はMUSTに拒否される必要があります。
This section provides several examples of JWSs. While the first three examples all represent JSON Web Tokens (JWTs) [JWT], the payload can be any octet sequence, as shown in Appendix A.4.
このセクションでは、いくつかのJWSの例を提供します。最初の3つの例はすべてJSON Web Token（JWT）[JWT]を表していますが、ペイロードは付録A.4に示されているように、任意のオクテットシーケンスであることができます。
The following example JWS Protected Header declares that the data structure is a JWT [JWT] and the JWS Signing Input is secured using the HMAC SHA-256 algorithm.
次の例のJWS保護ヘッダーは、データ構造がJWT[JWT]であることを宣言し、JWS署名入力がHMAC SHA-256アルゴリズムを使用して保護されていることを示しています。
{"typ":"JWT",
"alg":"HS256"}
{"typ":"JWT",
"alg":"HS256"}
To remove potential ambiguities in the representation of the JSON object above, the actual octet sequence representing UTF8(JWS Protected Header) used in this example 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 UTF8(JWS Protected Header) in this example (using JSON array notation) are:
JSONオブジェクトの表現における曖昧さを回避するために、この例で使用されるUTF8（JWS Protected Header）を表すオクテットシーケンスも以下に含まれています。 （異なるプラットフォーム表現による行区切り（CRLF対LF）、行の先頭と末尾のスペースの違い、最後の行に行区切りがあるかどうかなど、曖昧さが生じる可能性があります。この例で使用される表現では、最初の行には先頭または末尾のスペースがなく、CRLF行区切り（13、10）が最初の行と2番目の行の間に発生し、2番目の行には先頭スペース（32）が1つあり、末尾スペースはありません。最後の行には行区切りがありません。）この例でUTF8（JWS Protected Header）を表すオクテットは、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]
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
このJWS保護ヘッダーをBASE64URL（UTF8（JWS保護ヘッダー））としてエンコードすると、次の値が得られます：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
The JWS Payload used in this example is the octets of the UTF-8 representation of the JSON object below. (Note that the payload can be any base64url-encoded octet sequence and need not be a base64url- encoded JSON object.)
この例で使用されるJWSペイロードは、以下のJSONオブジェクトのUTF-8表現のオクテットです。（ペイロードは、base64urlエンコードされたオクテットシーケンスである必要があり、base64urlエンコードされたJSONオブジェクトである必要はありません。）
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
The following octet sequence, which is the UTF-8 representation used in this example for the JSON object above, is the JWS Payload:
上記のJSONオブジェクトに使用される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]
[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]
Encoding this JWS Payload as BASE64URL(UTF8(JWS Payload)) gives this value (with line breaks for display purposes only):
このJWSペイロードをBASE64URL(UTF8(JWSペイロード))でエンコードすると、次の値が得られます（表示目的の改行を含む）:
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only):
これらをBASE64URL(UTF8(JWS保護ヘッダー)) || '.' || BASE64URL(JWSペイロード)と結合すると、次の文字列が得られます（表示目的の改行を含む）:
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The resulting JWS Signing Input value, which is the ASCII representation of above string, is the following octet sequence (using JSON array notation):
上記の文字列のASCII表現であるJWS署名入力値は、次のオクテットシーケンスです（JSON配列表記を使用）:
[101, 121, 74, 48, 101, 88, 65, 105, 79, 105, 74, 75, 86, 49, 81, 105, 76, 65, 48, 75, 73, 67, 74, 104, 98, 71, 99, 105, 79, 105, 74, 73, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]
[101, 121, 74, 48, 101, 88, 65, 105, 79, 105, 74, 75, 86, 49, 81, 105, 76, 65, 48, 75, 73, 67, 74, 104, 98, 71, 99, 105, 79, 105, 74, 73, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]
HMACs are generated using keys. This example uses the symmetric key represented in JSON Web Key [JWK] format below (with line breaks within values for display purposes only):
HMACは鍵を使用して生成されます。この例では、以下のJSON Web Key [JWK]形式で表される対称鍵を使用します（表示目的の改行を含む）:
{"kty":"oct",
"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
}
{"kty":"oct",
"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
}
Running the HMAC SHA-256 algorithm on the JWS Signing Input with this key yields this JWS Signature octet sequence:
この鍵を使用してJWS署名入力に対してHMAC SHA-256アルゴリズムを実行すると、次のJWS署名オクテットシーケンスが得られます:
[116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173, 187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83, 132, 141, 121]
[116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173, 187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83, 132, 141, 121]
Encoding this JWS Signature as BASE64URL(JWS Signature) gives this value:
このJWS署名をBASE64URL(JWS署名)でエンコードすると、次の値が得られます:
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):
これらの値をHeader.Payload.Signatureの順序で連結し、部分の間にピリオド（'.'）文字を挿入すると、JWS Compact Serializationを使用した完全なJWS表現が得られます（表示目的の改行を含む）。
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Since the "alg" Header Parameter is "HS256", we validate the HMAC SHA-256 value contained in the JWS Signature.
"alg"ヘッダーパラメーターが"HS256"であるため、JWS署名に含まれるHMAC SHA-256値を検証します。
To validate the HMAC value, we repeat the previous process of using the correct key and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) as input to the HMAC SHA-256 function and then taking the output and determining if it matches the JWS Signature (which is base64url decoded from the value encoded in the JWS representation). If it matches exactly, the HMAC has been validated.
HMAC値を検証するには、正しいキーとJWS署名入力（JWS Compact Serialization表現の最初のピリオド文字までの初期サブストリング）をHMAC SHA-256関数の入力として使用し、出力を取得して、JWS署名（JWS表現でエンコードされた値からbase64urlデコードされたもの）と一致するかどうかを確認します。完全に一致する場合、HMACは検証されます。
The JWS Protected Header in this example is different from the previous example in two ways. First, because a different algorithm is being used, the "alg" value is different. Second, for illustration purposes only, the optional "typ" (type) Header Parameter is not used. (This difference is not related to the algorithm employed.) The JWS Protected Header used is:
この例のJWS保護ヘッダーは、前の例とは異なる2つの方法で異なります。 まず、異なるアルゴリズムが使用されているため、「alg」値が異なります。 2番目に、説明のために、オプションの「typ」（タイプ）ヘッダーパラメーターは使用されていません。 （この違いは使用されるアルゴリズムとは関係ありません。）使用されるJWS保護ヘッダーは次のとおりです：
{"alg":"RS256"}
{"alg":"RS256"}
The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are:
この例でUTF8（JWS保護ヘッダー）を表すオクテットは、JSON配列表記を使用して以下のようになります：
[123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 50, 53, 54, 34, 125]
[123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 50, 53, 54, 34, 125]
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
このJWS保護ヘッダーをBASE64URL（UTF8（JWS保護ヘッダー））としてエンコードすると、次の値が得られます：
eyJhbGciOiJSUzI1NiJ9
eyJhbGciOiJSUzI1NiJ9
The JWS Payload used in this example, which follows, is the same as in the previous example. Since the BASE64URL(JWS Payload) value will therefore be the same, its computation is not repeated here.
この例で使用されるJWSペイロードは、前の例と同じです。したがって、BASE64URL（JWSペイロード）の値は同じであるため、ここではその計算を繰り返しません。
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only):
これらをBASE64URL（UTF8（JWS保護ヘッダー））|| '.' || BASE64URL（JWSペイロード）として結合すると、次の文字列が得られます（表示目的の改行を含む）：
eyJhbGciOiJSUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
eyJhbGciOiJSUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The resulting JWS Signing Input value, which is the ASCII representation of above string, is the following octet sequence:
上記の文字列のASCII表現であるJWS署名入力値は、以下のオクテットシーケンスです：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81] This example uses the RSA key represented in JSON Web Key [JWK] format below (with line breaks within values for display purposes only):
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81] この例では、以下のJSON Web Key[JWK]形式で表されるRSAキーが使用されます（表示目的の改行を含む）：
{"kty":"RSA",
"n":"ofgWCuLjybRlzo0tZWJjNiuSfb4p4fAkd_wWJcyQoTbji9k0l8W26mPddx
HmfHQp-Vaw-4qPCJrcS2mJPMEzP1Pt0Bm4d4QlL-yRT-SFd2lZS-pCgNMs
D1W_YpRPEwOWvG6b32690r2jZ47soMZo9wGzjb_7OMg0LOL-bSf63kpaSH
SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV
MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8
NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ",
"e":"AQAB",
"d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I
jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0
BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn
439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT
CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh
BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ",
"p":"4BzEEOtIpmVdVEZNCqS7baC4crd0pqnRH_5IB3jw3bcxGn6QLvnEtfdUdi
YrqBdss1l58BQ3KhooKeQTa9AB0Hw_Py5PJdTJNPY8cQn7ouZ2KKDcmnPG
BY5t7yLc1QlQ5xHdwW1VhvKn-nXqhJTBgIPgtldC-KDV5z-y2XDwGUc",
"q":"uQPEfgmVtjL0Uyyx88GZFF1fOunH3-7cepKmtH4pxhtCoHqpWmT8YAmZxa
ewHgHAjLYsp1ZSe7zFYHj7C6ul7TjeLQeZD_YwD66t62wDmpe_HlB-TnBA
-njbglfIsRLtXlnDzQkv5dTltRJ11BKBBypeeF6689rjcJIDEz9RWdc",
"dp":"BwKfV3Akq5_MFZDFZCnW-wzl-CCo83WoZvnLQwCTeDv8uzluRSnm71I3Q
CLdhrqE2e9YkxvuxdBfpT_PI7Yz-FOKnu1R6HsJeDCjn12Sk3vmAktV2zb
34MCdy7cpdTh_YVr7tss2u6vneTwrA86rZtu5Mbr1C1XsmvkxHQAdYo0",
"dq":"h_96-mK1R_7glhsum81dZxjTnYynPbZpHziZjeeHcXYsXaaMwkOlODsWa
7I9xXDoRwbKgB719rrmI2oKr6N3Do9U0ajaHF-NKJnwgjMd2w9cjz3_-ky
NlxAr2v4IKhGNpmM5iIgOS1VZnOZ68m6_pbLBSp3nssTdlqvd0tIiTHU",
"qi":"IYd7DHOhrWvxkwPQsRM2tOgrjbcrfvtQJipd-DlcxyVuuM9sQLdgjVk2o
y26F0EmpScGLq2MowX7fhd_QJQ3ydy5cY7YIBi87w93IKLEdfnbJtoOPLU
W0ITrJReOgo1cq9SbsxYawBgfp_gh6A5603k2-ZQwVK0JKSHuLFkuQ3U"
}
{"kty":"RSA",
"n":"ofgWCuLjybRlzo0tZWJjNiuSfb4p4fAkd_wWJcyQoTbji9k0l8W26mPddx
HmfHQp-Vaw-4qPCJrcS2mJPMEzP1Pt0Bm4d4QlL-yRT-SFd2lZS-pCgNMs
D1W_YpRPEwOWvG6b32690r2jZ47soMZo9wGzjb_7OMg0LOL-bSf63kpaSH
SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV
MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8
NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ",
"e":"AQAB",
"d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I
jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0
BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn
439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT
CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh
BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ",
"p":"4BzEEOtIpmVdVEZNCqS7baC4crd0pqnRH_5IB3jw3bcxGn6QLvnEtfdUdi
YrqBdss1l58BQ3KhooKeQTa9AB0Hw_Py5PJdTJNPY8cQn7ouZ2KKDcmnPG
BY5t7yLc1QlQ5xHdwW1VhvKn-nXqhJTBgIPgtldC-KDV5z-y2XDwGUc",
"q":"uQPEfgmVtjL0Uyyx88GZFF1fOunH3-7cepKmtH4pxhtCoHqpWmT8YAmZxa
ewHgHAjLYsp1ZSe7zFYHj7C6ul7TjeLQeZD_YwD66t62wDmpe_HlB-TnBA
-njbglfIsRLtXlnDzQkv5dTltRJ11BKBBypeeF6689rjcJIDEz9RWdc",
"dp":"BwKfV3Akq5_MFZDFZCnW-wzl-CCo83WoZvnLQwCTeDv8uzluRSnm71I3Q
CLdhrqE2e9YkxvuxdBfpT_PI7Yz-FOKnu1R6HsJeDCjn12Sk3vmAktV2zb
34MCdy7cpdTh_YVr7tss2u6vneTwrA86rZtu5Mbr1C1XsmvkxHQAdYo0",
"dq":"h_96-mK1R_7glhsum81dZxjTnYynPbZpHziZjeeHcXYsXaaMwkOlODsWa
7I9xXDoRwbKgB719rrmI2oKr6N3Do9U0ajaHF-NKJnwgjMd2w9cjz3_-ky
NlxAr2v4IKhGNpmM5iIgOS1VZnOZ68m6_pbLBSp3nssTdlqvd0tIiTHU",
"qi":"IYd7DHOhrWvxkwPQsRM2tOgrjbcrfvtQJipd-DlcxyVuuM9sQLdgjVk2o
y26F0EmpScGLq2MowX7fhd_QJQ3ydy5cY7YIBi87w93IKLEdfnbJtoOPLU
W0ITrJReOgo1cq9SbsxYawBgfp_gh6A5603k2-ZQwVK0JKSHuLFkuQ3U"
}
The RSA private key is then passed to the RSA signing function, which also takes the hash type, SHA-256, and the JWS Signing Input as inputs. The result of the digital signature is an octet sequence, which represents a big-endian integer. In this example, it is:
RSAの秘密鍵は、SHA-256のハッシュタイプとJWS署名入力を入力として受け取るRSA署名関数に渡されます。デジタル署名の結果は、ビッグエンディアンの整数を表すオクテットシーケンスです。この例では、次の値です:
[112, 46, 33, 137, 67, 232, 143, 209, 30, 181, 216, 45, 191, 120, 69, 243, 65, 6, 174, 27, 129, 255, 247, 115, 17, 22, 173, 209, 113, 125, 131, 101, 109, 66, 10, 253, 60, 150, 238, 221, 115, 162, 102, 62, 81, 102, 104, 123, 0, 11, 135, 34, 110, 1, 135, 237, 16, 115, 249, 69, 229, 130, 173, 252, 239, 22, 216, 90, 121, 142, 232, 198, 109, 219, 61, 184, 151, 91, 23, 208, 148, 2, 190, 237, 213, 217, 217, 112, 7, 16, 141, 178, 129, 96, 213, 248, 4, 12, 167, 68, 87, 98, 184, 31, 190, 127, 249, 217, 46, 10, 231, 111, 36, 242, 91, 51, 187, 230, 244, 74, 230, 30, 177, 4, 10, 203, 32, 4, 77, 62, 249, 18, 142, 212, 1, 48, 121, 91, 212, 189, 59, 65, 238, 202, 208, 102, 171, 101, 25, 129, 253, 228, 141, 247, 127, 55, 45, 195, 139, 159, 175, 221, 59, 239, 177, 139, 93, 163, 204, 60, 46, 176, 47, 158, 58, 65, 214, 18, 202, 173, 21, 145, 18, 115, 160, 95, 35, 185, 232, 56, 250, 175, 132, 157, 105, 132, 41, 239, 90, 30, 136, 121, 130, 54, 195, 212, 14, 96, 69, 34, 165, 68, 200, 242, 122, 122, 45, 184, 6, 99, 209, 108, 247, 202, 234, 86, 222, 64, 92, 178, 33, 90, 69, 178, 194, 85, 102, 181, 90, 193, 167, 72, 160, 112, 223, 200, 163, 42, 70, 149, 67, 208, 25, 238, 251, 71]
[112, 46, 33, 137, 67, 232, 143, 209, 30, 181, 216, 45, 191, 120, 69, 243, 65, 6, 174, 27, 129, 255, 247, 115, 17, 22, 173, 209, 113, 125, 131, 101, 109, 66, 10, 253, 60, 150, 238, 221, 115, 162, 102, 62, 81, 102, 104, 123, 0, 11, 135, 34, 110, 1, 135, 237, 16, 115, 249, 69, 229, 130, 173, 252, 239, 22, 216, 90, 121, 142, 232, 198, 109, 219, 61, 184, 151, 91, 23, 208, 148, 2, 190, 237, 213, 217, 217, 112, 7, 16, 141, 178, 129, 96, 213, 248, 4, 12, 167, 68, 87, 98, 184, 31, 190, 127, 249, 217, 46, 10, 231, 111, 36, 242, 91, 51, 187, 230, 244, 74, 230, 30, 177, 4, 10, 203, 32, 4, 77, 62, 249, 18, 142, 212, 1, 48, 121, 91, 212, 189, 59, 65, 238, 202, 208, 102, 171, 101, 25, 129, 253, 228, 141, 247, 127, 55, 45, 195, 139, 159, 175, 221, 59, 239, 177, 139, 93, 163, 204, 60, 46, 176, 47, 158, 58, 65, 214, 18, 202, 173, 21, 145, 18, 115, 160, 95, 35, 185, 232, 56, 250, 175, 132, 157, 105, 132, 41, 239, 90, 30, 136, 121, 130, 54, 195, 212, 14, 96, 69, 34, 165, 68, 200, 242, 122, 122, 45, 184, 6, 99, 209, 108, 247, 202, 234, 86, 222, 64, 92, 178, 33, 90, 69, 178, 194, 85, 102, 181, 90, 193, 167, 72, 160, 112, 223, 200, 163, 42, 70, 149, 67, 208, 25, 238, 251, 71]
Encoding the signature as BASE64URL(JWS Signature) produces this value (with line breaks for display purposes only):
署名をBASE64URL(JWS Signature)でエンコードすると、次の値が得られます（表示目的の改行を含む）:
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7 AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4 BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K 0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB p0igcN_IoypGlUPQGe77Rw
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7 AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4 BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K 0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB p0igcN_IoypGlUPQGe77Rw
Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):
これらの値をHeader.Payload.Signatureの順序で連結し、部分の間にピリオド（'.'）文字を挿入すると、JWS Compact Serializationを使用した完全なJWS表現が得られます（表示目的の改行を含む）。
eyJhbGciOiJSUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7 AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4 BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K 0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB p0igcN_IoypGlUPQGe77Rw
eyJhbGciOiJSUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7 AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4 BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K 0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB p0igcN_IoypGlUPQGe77Rw
Since the "alg" Header Parameter is "RS256", we validate the RSASSA- PKCS1-v1_5 SHA-256 digital signature contained in the JWS Signature.
"alg"ヘッダーパラメーターが"RS256"であるため、JWS署名に含まれるRSASSA-PKCS1-v1_5 SHA-256デジタル署名を検証します。
Validating the JWS Signature is a bit different from the previous example. We pass the public key (n, e), the JWS Signature (which is base64url decoded from the value encoded in the JWS representation), and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) to an RSASSA-PKCS1-v1_5 signature verifier that has been configured to use the SHA-256 hash function.
JWS署名の検証は、前の例とは少し異なります。公開鍵（n、e）、JWS署名（JWS表現でエンコードされた値からbase64urlデコードされたもの）、およびJWS署名入力（JWS Compact Serialization表現の最初のピリオド文字までの初期サブストリング）を、SHA-256ハッシュ関数を使用するように構成されたRSASSA-PKCS1-v1_5署名検証器に渡します。
The JWS Protected Header for this example differs from the previous example because a different algorithm is being used. The JWS Protected Header used is:
この例のJWS保護ヘッダーは、前の例とは異なるアルゴリズムが使用されているため異なります。使用されるJWS保護ヘッダーは次のとおりです：
{"alg":"ES256"}
{"alg":"ES256"}
The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are:
この例でUTF8(JWS Protected Header)を表すオクテットは、次のJSON配列表記です:
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 50, 53, 54, 34, 125] Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 50, 53, 54, 34, 125] このJWS保護ヘッダーをBASE64URL（UTF8（JWS保護ヘッダー））としてエンコードすると、次の値が得られます：
eyJhbGciOiJFUzI1NiJ9
eyJhbGciOiJFUzI1NiJ9
The JWS Payload used in this example, which follows, is the same as in the previous examples. Since the BASE64URL(JWS Payload) value will therefore be the same, its computation is not repeated here.
この例で使用されるJWSペイロードは、前の例と同じです。したがって、BASE64URL(JWSペイロード)の値は同じであるため、ここでは再計算されません。
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only):
これらをBASE64URL（UTF8（JWS保護ヘッダー））|| '.' || BASE64URL（JWSペイロード）として結合すると、次の文字列が得られます（表示目的の改行を含む）：
eyJhbGciOiJFUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
eyJhbGciOiJFUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The resulting JWS Signing Input value, which is the ASCII representation of above string, is the following octet sequence:
上記の文字列のASCII表現であるJWS署名入力値は、以下のオクテットシーケンスです：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]
This example uses the Elliptic Curve key represented in JSON Web Key [JWK] format below:
この例では、以下のJSON Web Key[JWK]形式で表される楕円曲線キーが使用されます：
{"kty":"EC",
"crv":"P-256",
"x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
"y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
"d":"jpsQnnGQmL-YBIffH1136cspYG6-0iY7X1fCE9-E9LI"
}
{"kty":"EC",
"crv":"P-256",
"x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
"y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
"d":"jpsQnnGQmL-YBIffH1136cspYG6-0iY7X1fCE9-E9LI"
}
The Elliptic Curve Digital Signature Algorithm (ECDSA) private part d is then passed to an ECDSA signing function, which also takes the curve type, P-256, the hash type, SHA-256, and the JWS Signing Input as inputs. The result of the digital signature is the Elliptic Curve (EC) point (R, S), where R and S are unsigned integers. In this example, the R and S values, given as octet sequences representing big-endian integers are:
楕円曲線デジタル署名アルゴリズム（ECDSA）の秘密部分dは、曲線タイプP-256、ハッシュタイプSHA-256、およびJWS署名入力を入力として受け取るECDSA署名関数に渡されます。デジタル署名の結果は、楕円曲線（EC）の点（R、S）であり、RとSは符号なし整数です。この例では、ビッグエンディアンの整数を表すオクテットシーケンスとして与えられたRとSの値は次のとおりです:
| Result Name | Value |
| R | [14, 209, 33, 83, 121, 99, 108, 72, 60, 47, 127, 21, 88, 7, 212, 2, 163, 178, 40, 3, 58, 249, 124, 126, 23, 129, 154, 195, 22, 158, 166, 101] |
| S | [197, 10, 7, 211, 140, 60, 112, 229, 216, 241, 45, 175, 8, 74, 84, 128, 166, 101, 144, 197, 242, 147, 80, 154, 143, 63, 127, 138, 131, 163, 84, 213] |
| Result Name | Value |
| R | [14, 209, 33, 83, 121, 99, 108, 72, 60, 47, 127, 21, 88, 7, 212, 2, 163, 178, 40, 3, 58, 249, 124, 126, 23, 129, 154, 195, 22, 158, 166, 101] |
| S | [197, 10, 7, 211, 140, 60, 112, 229, 216, 241, 45, 175, 8, 74, 84, 128, 166, 101, 144, 197, 242, 147, 80, 154, 143, 63, 127, 138, 131, 163, 84, 213] |
The JWS Signature is the value R || S. Encoding the signature as BASE64URL(JWS Signature) produces this value (with line breaks for display purposes only):
JWS署名は、値R || Sです。署名をBASE64URL(JWS署名)でエンコードすると、次の値が得られます（表示目的の改行を含む）:
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA pmWQxfKTUJqPP3-Kg6NU1Q
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA pmWQxfKTUJqPP3-Kg6NU1Q
Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):
これらの値をHeader.Payload.Signatureの順序で連結し、部分の間にピリオド（'.'）文字を挿入すると、JWS Compact Serializationを使用した完全なJWS表現が得られます（表示目的の改行を含む）。
eyJhbGciOiJFUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA pmWQxfKTUJqPP3-Kg6NU1Q
eyJhbGciOiJFUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA pmWQxfKTUJqPP3-Kg6NU1Q
Since the "alg" Header Parameter is "ES256", we validate the ECDSA P-256 SHA-256 digital signature contained in the JWS Signature.
"alg"ヘッダーパラメーターが"ES256"であるため、JWS署名に含まれるECDSA P-256 SHA-256デジタル署名を検証します。
Validating the JWS Signature is a bit different from the previous examples. We need to split the 64 member octet sequence of the JWS Signature (which is base64url decoded from the value encoded in the JWS representation) into two 32 octet sequences, the first representing R and the second S. We then pass the public key (x, y), the signature (R, S), and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) to an ECDSA signature verifier that has been configured to use the P-256 curve with the SHA-256 hash function.
JWS署名の検証は、前の例とは少し異なります。JWS署名の64バイトのオクテットシーケンス（JWS表現でエンコードされた値からbase64urlデコードされたもの）を、RとSを表す2つの32バイトのオクテットシーケンスに分割する必要があります。次に、公開鍵（x、y）、署名（R、S）、およびJWS署名入力（JWS Compact Serialization表現の最初のピリオド文字までの初期サブストリング）を、SHA-256ハッシュ関数を使用するように構成されたP-256曲線を使用するECDSA署名検証器に渡します。
The JWS Protected Header for this example differs from the previous example because different ECDSA curves and hash functions are used. The JWS Protected Header used is:
この例のJWS保護ヘッダーは、前の例とは異なるECDSA曲線とハッシュ関数が使用されているため異なります。使用されるJWS保護ヘッダーは次のとおりです：
{"alg":"ES512"}
{"alg":"ES512"}
The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are:
この例でUTF8（JWS保護ヘッダー）を表すオクテットは、JSON配列表記を使用して以下のようになります：
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125]
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125]
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
このJWS保護ヘッダーをBASE64URL（UTF8（JWS保護ヘッダー））としてエンコードすると、次の値が得られます：
eyJhbGciOiJFUzUxMiJ9
eyJhbGciOiJFUzUxMiJ9
The JWS Payload used in this example is the ASCII string "Payload". The representation of this string is the following octet sequence:
この例で使用されるJWSペイロードは、ASCII文字列「Payload」です。 この文字列の表現は、次のオクテットシーケンスです：
[80, 97, 121, 108, 111, 97, 100]
[80, 97, 121, 108, 111, 97, 100]
Encoding this JWS Payload as BASE64URL(JWS Payload) gives this value:
このJWSペイロードをBASE64URL（JWSペイロード）としてエンコードすると、次の値が得られます：
UGF5bG9hZA
UGF5bG9hZA
Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string:
これらをBASE64URL(UTF8(JWS保護ヘッダー)) || '.' || BASE64URL(JWSペイロード)と結合すると、次の文字列が得られます（表示目的の改行を含む）:
eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA
eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA
The resulting JWS Signing Input value, which is the ASCII representation of above string, is the following octet sequence:
上記の文字列のASCII表現であるJWS署名入力値は、次のオクテットシーケンスです:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 85, 120, 77, 105, 74, 57, 46, 85, 71, 70, 53, 98, 71, 57, 104, 90, 65] This example uses the Elliptic Curve key represented in JSON Web Key [JWK] format below (with line breaks within values for display purposes only):
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 85, 120, 77, 105, 74, 57, 46, 85, 71, 70, 53, 98, 71, 57, 104, 90, 65] この例では、以下のJSON Web Key [JWK]形式で表される楕円曲線鍵を使用します（表示目的の改行を含む）:
{"kty":"EC",
"crv":"P-521",
"x":"AekpBQ8ST8a8VcfVOTNl353vSrDCLLJXmPk06wTjxrrjcBpXp5EOnYG_
NjFZ6OvLFV1jSfS9tsz4qUxcWceqwQGk",
"y":"ADSmRA43Z1DSNx_RvcLI87cdL07l6jQyyBXMoxVg_l2Th-x3S1WDhjDl
y79ajL4Kkd0AZMaZmh9ubmf63e3kyMj2",
"d":"AY5pb7A0UFiB3RELSD64fTLOSV_jazdF7fLYyuTw8lOfRhWg6Y6rUrPA
xerEzgdRhajnu0ferB0d53vM9mE15j2C"
}
{"kty":"EC",
"crv":"P-521",
"x":"AekpBQ8ST8a8VcfVOTNl353vSrDCLLJXmPk06wTjxrrjcBpXp5EOnYG_
NjFZ6OvLFV1jSfS9tsz4qUxcWceqwQGk",
"y":"ADSmRA43Z1DSNx_RvcLI87cdL07l6jQyyBXMoxVg_l2Th-x3S1WDhjDl
y79ajL4Kkd0AZMaZmh9ubmf63e3kyMj2",
"d":"AY5pb7A0UFiB3RELSD64fTLOSV_jazdF7fLYyuTw8lOfRhWg6Y6rUrPA
xerEzgdRhajnu0ferB0d53vM9mE15j2C"
}
The ECDSA private part d is then passed to an ECDSA signing function, which also takes the curve type, P-521, the hash type, SHA-512, and the JWS Signing Input as inputs. The result of the digital signature is the EC point (R, S), where R and S are unsigned integers. In this example, the R and S values, given as octet sequences representing big-endian integers are:
ECDSAの秘密部分dは、曲線タイプP-521、ハッシュタイプSHA-512、およびJWS署名入力を入力として取るECDSA署名関数に渡されます。デジタル署名の結果は、ECポイント（R、S）であり、RとSは符号なし整数です。この例では、big-endian整数を表すオクテットシーケンスとして与えられたRおよびSの値は次のとおりです。
| Result Name | Value |
| R | [1, 220, 12, 129, 231, 171, 194, 209, 232, 135, 233, 117, 247, 105, 122, 210, 26, 125, 192, 1, 217, 21, 82, 91, 45, 240, 255, 83, 19, 34, 239, 71, 48, 157, 147, 152, 105, 18, 53, 108, 163, 214, 68, 231, 62, 153, 150, 106, 194, 164, 246, 72, 143, 138, 24, 50, 129, 223, 133, 206, 209, 172, 63, 237, 119, 109] |
| S | [0, 111, 6, 105, 44, 5, 41, 208, 128, 61, 152, 40, 92, 61, 152, 4, 150, 66, 60, 69, 247, 196, 170, 81, 193, 199, 78, 59, 194, 169, 16, 124, 9, 143, 42, 142, 131, 48, 206, 238, 34, 175, 83, 203, 220, 159, 3, 107, 155, 22, 27, 73, 111, 68, 68, 21, 238, 144, 229, 232, 148, 188, 222, 59, 242, 103] |
| Result Name | Value |
| R | [1, 220, 12, 129, 231, 171, 194, 209, 232, 135, 233, 117, 247, 105, 122, 210, 26, 125, 192, 1, 217, 21, 82, 91, 45, 240, 255, 83, 19, 34, 239, 71, 48, 157, 147, 152, 105, 18, 53, 108, 163, 214, 68, 231, 62, 153, 150, 106, 194, 164, 246, 72, 143, 138, 24, 50, 129, 223, 133, 206, 209, 172, 63, 237, 119, 109] |
| S | [0, 111, 6, 105, 44, 5, 41, 208, 128, 61, 152, 40, 92, 61, 152, 4, 150, 66, 60, 69, 247, 196, 170, 81, 193, 199, 78, 59, 194, 169, 16, 124, 9, 143, 42, 142, 131, 48, 206, 238, 34, 175, 83, 203, 220, 159, 3, 107, 155, 22, 27, 73, 111, 68, 68, 21, 238, 144, 229, 232, 148, 188, 222, 59, 242, 103] |
The JWS Signature is the value R || S. Encoding the signature as BASE64URL(JWS Signature) produces this value (with line breaks for display purposes only):
JWS署名は、値R || Sです。署名をBASE64URL（JWS署名）としてエンコードすると、次の値が生成されます（表示目的の改行を含む）:
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):
これらの値をHeader.Payload.Signatureの順序で連結し、部分の間にピリオド（'.'）文字を挿入すると、JWS Compact Serializationを使用した完全なJWS表現が得られます（表示目的の改行を含む）。
eyJhbGciOiJFUzUxMiJ9 . UGF5bG9hZA . AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
eyJhbGciOiJFUzUxMiJ9 . UGF5bG9hZA . AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
Since the "alg" Header Parameter is "ES512", we validate the ECDSA P-521 SHA-512 digital signature contained in the JWS Signature.
"alg"ヘッダーパラメーターが"ES512"であるため、JWSシグネチャに含まれるECDSA P-521 SHA-512デジタル署名を検証します。
Validating this JWS Signature is very similar to the previous example. We need to split the 132-member octet sequence of the JWS Signature into two 66-octet sequences, the first representing R and the second S. We then pass the public key (x, y), the signature (R, S), and the JWS Signing Input to an ECDSA signature verifier that has been configured to use the P-521 curve with the SHA-512 hash function.
このJWSシグネチャの検証は、前の例と非常に似ています。JWSシグネチャの132バイトのオクテットシーケンスを2つの66バイトのシーケンスに分割する必要があります。最初のシーケンスはRを表し、2番目のシーケンスはSを表します。次に、公開鍵（x、y）、署名（R、S）、およびJWS署名入力を使用して、P-521曲線とSHA-512ハッシュ関数を使用するように構成されたECDSA署名検証器に渡します。
The following example JWS Protected Header declares that the encoded object is an Unsecured JWS:
次の例のJWS保護ヘッダーは、エンコードされたオブジェクトがUnsecured JWSであることを宣言しています:
{"alg":"none"}
{"alg":"none"}
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
このJWS保護ヘッダーをBASE64URL（UTF8（JWS保護ヘッダー））としてエンコードすると、次の値が生成されます:
eyJhbGciOiJub25lIn0
eyJhbGciOiJub25lIn0
The JWS Payload used in this example, which follows, is the same as in the previous examples. Since the BASE64URL(JWS Payload) value will therefore be the same, its computation is not repeated here.
この例で使用されるJWSペイロードは、前の例と同じです。したがって、BASE64URL（JWSペイロード）の値は同じであるため、ここではその計算を繰り返しません。
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
The JWS Signature is the empty octet string and BASE64URL(JWS Signature) is the empty string.
JWSシグネチャは空のオクテット文字列であり、BASE64URL（JWSシグネチャ）は空の文字列です。
Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):
これらの値をHeader.Payload.Signatureの順序で連結し、各部分の間にピリオド（'.'）文字を挿入すると、JWS Compact Serializationを使用した完全なJWS表現が生成されます（表示目的の改行を含む）:
eyJhbGciOiJub25lIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ .
eyJhbGciOiJub25lIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ .
This section contains an example using the general JWS JSON Serialization syntax. This example demonstrates the capability for conveying multiple digital signatures and/or MACs for the same payload.
このセクションには、一般的なJWS JSONシリアル化構文を使用した例が含まれています。この例は、同じペイロードに対して複数のデジタル署名および/またはMACを伝達する機能を示しています。
The JWS Payload used in this example is the same as that used in the examples in Appendix A.2 and Appendix A.3 (with line breaks for display purposes only):
この例で使用されるJWSペイロードは、付録A.2および付録A.3の例で使用されるものと同じです（表示目的の改行を含む）:
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Two digital signatures are used in this example: the first using RSASSA-PKCS1-v1_5 SHA-256 and the second using ECDSA P-256 SHA-256. For the first, the JWS Protected Header and key are the same as in Appendix A.2, resulting in the same JWS Signature value; therefore, its computation is not repeated here. For the second, the JWS Protected Header and key are the same as in Appendix A.3, resulting in the same JWS Signature value; therefore, its computation is not repeated here.
この例では、2つのデジタル署名が使用されています。1つ目はRSASSA-PKCS1-v1_5 SHA-256を使用し、2つ目はECDSA P-256 SHA-256を使用します。1つ目の場合、JWS保護ヘッダーと鍵は付録A.2と同じであり、同じJWSシグネチャ値が生成されます。したがって、ここではその計算を繰り返しません。2つ目の場合、JWS保護ヘッダーと鍵は付録A.3と同じであり、同じJWSシグネチャ値が生成されます。したがって、ここではその計算を繰り返しません。
The JWS Protected Header value used for the first signature is:
最初の署名に使用されるJWS保護ヘッダーの値は次のとおりです:
{"alg":"RS256"}
{"alg":"RS256"}
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
このJWS保護ヘッダーをBASE64URL（UTF8（JWS保護ヘッダー））としてエンコードすると、次の値が生成されます:
eyJhbGciOiJSUzI1NiJ9
eyJhbGciOiJSUzI1NiJ9
The JWS Protected Header value used for the second signature is:
2番目の署名に使用されるJWS保護ヘッダーの値は次のとおりです:
{"alg":"ES256"}
{"alg":"ES256"}
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
このJWS保護ヘッダーをBASE64URL(UTF8(JWS保護ヘッダー))でエンコードすると、次の値が得られます:
eyJhbGciOiJFUzI1NiJ9
eyJhbGciOiJFUzI1NiJ9
Key ID values are supplied for both keys using per-signature Header Parameters. The two JWS Unprotected Header values used to represent these key IDs are:
キーID値は、署名ごとにHeaderパラメーターを使用して提供されます。これらのキーIDを表すために使用される2つのJWS Unprotected Header値は次のとおりです:
{"kid":"2010-12-29"}
{"kid":"2010-12-29"}
and
および
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
Combining the JWS Protected Header and JWS Unprotected Header values supplied, the JOSE Header values used for the first and second signatures, respectively, are:
提供されたJWS保護ヘッダーとJWS未保護ヘッダー値を組み合わせると、最初の署名に使用されるJOSEヘッダー値と2番目の署名に使用されるJOSEヘッダー値が次のようになります:
{"alg":"RS256",
"kid":"2010-12-29"}
{"alg":"RS256",
"kid":"2010-12-29"}
and
および
{"alg":"ES256",
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
{"alg":"ES256",
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
The complete JWS JSON Serialization for these values is as follows (with line breaks within values for display purposes only):
これらの値に対する完全なJWS JSONシリアル化は、次のとおりです（表示目的の改行を含む）:
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"signatures":[
{"protected":"eyJhbGciOiJSUzI1NiJ9",
"header":
{"kid":"2010-12-29"},
"signature":
"cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ
mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb
KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl
b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES
c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX
LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"},
{"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"}]
}
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"signatures":[
{"protected":"eyJhbGciOiJSUzI1NiJ9",
"header":
{"kid":"2010-12-29"},
"signature":
"cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ
mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb
KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl
b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES
c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX
LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"},
{"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"}]
}
This section contains an example using the flattened JWS JSON Serialization syntax. This example demonstrates the capability for conveying a single digital signature or MAC in a flattened JSON structure.
このセクションには、フラット化されたJWS JSONシリアル化構文を使用した例が含まれています。この例は、フラット化されたJSON構造で単一のデジタル署名またはMACを伝達する機能を示しています。
The values in this example are the same as those in the second signature of the previous example in Appendix A.6.
この例で使用される値は、付録A.6の前の例の2番目の署名と同じです。
The complete JWS JSON Serialization for these values is as follows (with line breaks within values for display purposes only):
これらの値に対する完全なJWS JSONシリアル化は、次のとおりです（表示目的の改行を含む）:
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"
}
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"
}
The JSON array below is an example of a certificate chain that could be used as the value of an "x5c" (X.509 certificate chain) Header Parameter, per Section 4.1.6 (with line breaks within values for display purposes only):
以下のJSON配列は、セクション4.1.6に従って「x5c」（X.509証明書チェーン）ヘッダーパラメーターの値として使用できる証明書チェーンの例です（表示目的の改行を含む）:
["MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVM
xITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR2
8gRGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExM
TYwMTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UE
CBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWR
keS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYW
RkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlc
nRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTt
wY6vj3D3HKrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqV
Tr9vcyOdQmVZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aL
GbqGmu75RpRSgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo
7RJlbmr2EkRTcDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgW
JCJjPOq8lh8BJ6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAw
EAAaOCATIwggEuMB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVH
SMEGDAWgBTSxLDSkdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEA
MDMGCCsGAQUFBwEBBCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWR
keS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2
RhZGR5LmNvbS9yZXBvc2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVH
SAAMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j
b20vcmVwb3NpdG9yeTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggE
BANKGwOy9+aG2Z+5mC6IGOgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPI
UyIXvJxwqoJKSQ3kbTJSMUA2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL
5CkKSkB2XIsKd83ASe8T+5o0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9
p0iRFEUOOjZv2kWzRaJBydTXRE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsx
uxN89txJx9OjxUUAiKEngHUuHqDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZ
EjYx8WnM25sgVjOuH0aBsXBTWVU+4=",
"MIIE+zCCBGSgAwIBAgICAQ0wDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1Z
hbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIE
luYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb
24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8x
IDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTA0MDYyOTE3MDY
yMFoXDTI0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRoZS
BHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3MgM
iBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN
ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XC
APVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux
6wwdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLO
tXiEqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWo
riMYavx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZ
Eewo+YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjggHhMIIB3TAdBgNVHQ
4EFgQU0sSw0pHUTBFxs2HLPaH+3ahq1OMwgdIGA1UdIwSByjCBx6GBwaSBvjCBu
zEkMCIGA1UEBxMbVmFsaUNlcnQgVmFsaWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQK
Ew5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2x
pY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0dHA6Ly93d3cudm
FsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5jb22CA
QEwDwYDVR0TAQH/BAUwAwEB/zAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGG
F2h0dHA6Ly9vY3NwLmdvZGFkZHkuY29tMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA
6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9yb290LmNybD
BLBgNVHSAERDBCMEAGBFUdIAAwODA2BggrBgEFBQcCARYqaHR0cDovL2NlcnRpZ
mljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MA4GA1UdDwEB/wQEAwIBBjAN
BgkqhkiG9w0BAQUFAAOBgQC1QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PrxeNYiY+
Sn1eocSxI0YGyeR+sBjUZsE4OWBsUs5iB0QQeyAfJg594RAoYC5jcdnplDQ1tgM
QLARzLrUc+cb53S8wGd9D0VmsfSxOaFIqII6hR8INMqzW/Rn453HWkrugp++85j
09VZw==",
"MIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ
0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNT
AzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0a
G9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkq
hkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE
5MDYyNjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTm
V0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZ
XJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQD
ExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9
AdmFsaWNlcnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOOnHK5a
vIWZJV16vYdA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SVCCSRrCl6zf
N1SLUzm1NZ9WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwb
P7RfZHM047QSv4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQU
AA4GBADt/UG9vUJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQ
C1u+mNr0HZDzTuIYEZoDJJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMM
j4QssxsodyamEwCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd"]
["MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVM
xITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR2
8gRGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExM
TYwMTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UE
CBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWR
keS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYW
RkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlc
nRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTt
wY6vj3D3HKrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqV
Tr9vcyOdQmVZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aL
GbqGmu75RpRSgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo
7RJlbmr2EkRTcDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgW
JCJjPOq8lh8BJ6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAw
EAAaOCATIwggEuMB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVH
SMEGDAWgBTSxLDSkdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEA
MDMGCCsGAQUFBwEBBCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWR
keS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2
RhZGR5LmNvbS9yZXBvc2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVH
SAAMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j
b20vcmVwb3NpdG9yeTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggE
BANKGwOy9+aG2Z+5mC6IGOgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPI
UyIXvJxwqoJKSQ3kbTJSMUA2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL
5CkKSkB2XIsKd83ASe8T+5o0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9
p0iRFEUOOjZv2kWzRaJBydTXRE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsx
uxN89txJx9OjxUUAiKEngHUuHqDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZ
EjYx8WnM25sgVjOuH0aBsXBTWVU+4=",
"MIIE+zCCBGSgAwIBAgICAQ0wDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1Z
hbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIE
luYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb
24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8x
IDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTA0MDYyOTE3MDY
yMFoXDTI0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRoZS
BHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3MgM
iBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN
ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XC
APVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux
6wwdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLO
tXiEqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWo
riMYavx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZ
Eewo+YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjggHhMIIB3TAdBgNVHQ
4EFgQU0sSw0pHUTBFxs2HLPaH+3ahq1OMwgdIGA1UdIwSByjCBx6GBwaSBvjCBu
zEkMCIGA1UEBxMbVmFsaUNlcnQgVmFsaWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQK
Ew5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2x
pY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0dHA6Ly93d3cudm
FsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5jb22CA
QEwDwYDVR0TAQH/BAUwAwEB/zAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGG
F2h0dHA6Ly9vY3NwLmdvZGFkZHkuY29tMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA
6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9yb290LmNybD
BLBgNVHSAERDBCMEAGBFUdIAAwODA2BggrBgEFBQcCARYqaHR0cDovL2NlcnRpZ
mljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MA4GA1UdDwEB/wQEAwIBBjAN
BgkqhkiG9w0BAQUFAAOBgQC1QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PrxeNYiY+
Sn1eocSxI0YGyeR+sBjUZsE4OWBsUs5iB0QQeyAfJg594RAoYC5jcdnplDQ1tgM
QLARzLrUc+cb53S8wGd9D0VmsfSxOaFIqII6hR8INMqzW/Rn453HWkrugp++85j
09VZw==",
"MIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ
0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNT
AzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0a
G9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkq
hkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE
5MDYyNjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTm
V0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZ
XJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQD
ExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9
AdmFsaWNlcnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOOnHK5a
vIWZJV16vYdA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SVCCSRrCl6zf
N1SLUzm1NZ9WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwb
P7RfZHM047QSv4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQU
AA4GBADt/UG9vUJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQ
C1u+mNr0HZDzTuIYEZoDJJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMM
j4QssxsodyamEwCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd"]
This appendix describes how to implement base64url encoding and decoding functions without padding based upon standard base64 encoding and decoding functions that do use padding.
この付録では、パディングを使用しないbase64urlエンコードおよびデコード関数を実装する方法について説明します。これは、パディングを使用する標準的なbase64エンコードおよびデコード関数に基づいています。
To be concrete, example C# code implementing these functions is shown below. Similar code could be used in other languages.
具体的には、これらの関数を実装するC#の例を以下に示します。他の言語でも同様のコードが使用できます。
static string base64urlencode(byte [] arg)
{
string s = Convert.ToBase64String(arg); // Regular base64 encoder
s = s.Split('=')[0]; // Remove any trailing '='s
s = s.Replace('+', '-'); // 62nd char of encoding
s = s.Replace('/', '_'); // 63rd char of encoding
return s;
}
static string base64urlencode(byte [] arg)
{
string s = Convert.ToBase64String(arg); // 通常のbase64エンコーダ
s = s.Split('=')[0]; // 末尾の '=' を削除
s = s.Replace('+', '-'); // エンコーディングの62番目の文字
s = s.Replace('/', '_'); // エンコーディングの63番目の文字
return s;
}
static byte [] base64urldecode(string arg)
{
string s = arg;
s = s.Replace('-', '+'); // 62nd char of encoding
s = s.Replace('_', '/'); // 63rd char of encoding
switch (s.Length % 4) // Pad with trailing '='s
{
case 0: break; // No pad chars in this case
case 2: s += "=="; break; // Two pad chars
case 3: s += "="; break; // One pad char
default: throw new System.Exception(
"Illegal base64url string!");
}
return Convert.FromBase64String(s); // Standard base64 decoder
}
static byte [] base64urldecode(string arg)
{
string s = arg;
s = s.Replace('-', '+'); // エンコーディングの62番目の文字
s = s.Replace('_', '/'); // エンコーディングの63番目の文字
switch (s.Length % 4) // 末尾の '=' を補完
{
case 0: break; // この場合はパディング文字なし
case 2: s += "=="; break; // パディング文字が2つ
case 3: s += "="; break; // パディング文字が1つ
default: throw new System.Exception(
"不正なbase64url文字列です！");
}
return Convert.FromBase64String(s); // 通常のbase64デコーダ
}
As per the example code above, the number of '=' padding characters that needs to be added to the end of a base64url-encoded string without padding to turn it into one with padding is a deterministic function of the length of the encoded string. Specifically, if the length mod 4 is 0, no padding is added; if the length mod 4 is 2, two '=' padding characters are added; if the length mod 4 is 3, one '=' padding character is added; if the length mod 4 is 1, the input is malformed.
上記の例のコードに従い、パディングのないbase64urlエンコードされた文字列をパディングのある文字列に変換するために必要な '=' パディング文字の数は、エンコードされた文字列の長さの決定論的関数です。具体的には、長さ mod 4 が0の場合、パディングは追加されません。長さ mod 4 が2の場合、2つの '=' パディング文字が追加されます。長さ mod 4 が3の場合、1つの '=' パディング文字が追加されます。長さ mod 4 が1の場合、入力は不正形式です。
An example correspondence between unencoded and encoded values follows. The octet sequence below encodes into the string below, which when decoded, reproduces the octet sequence.
未エンコード値とエンコード値の対応例を以下に示します。以下のオクテットシーケンスは、以下の文字列にエンコードされ、デコードするとオクテットシーケンスが再現されます。
3 236 255 224 193 A-z_4ME
3 236 255 224 193 A-z_4ME
This appendix describes a set of possible algorithms for selecting the key to be used to validate the digital signature or MAC of a JWS or for selecting the key to be used to decrypt a JWE. This guidance describes a family of possible algorithms rather than a single algorithm, because in different contexts, not all the sources of keys will be used, they can be tried in different orders, and sometimes not all the collected keys will be tried; hence, different algorithms will be used in different application contexts.
この付録では、JWSのデジタル署名またはMACを検証するために使用するキーを選択するための一連の可能なアルゴリズムについて説明します。また、JWEを復号化するために使用するキーを選択するためのアルゴリズムについても説明します。このガイダンスは、単一のアルゴリズムではなく、可能なアルゴリズムのファミリーを説明しています。これは、異なるコンテキストでは、すべてのキーのソースが使用されない場合があるため、異なる順序で試行される場合があるため、収集されたすべてのキーが試行されない場合があるためです。したがって、異なるアプリケーションコンテキストで異なるアルゴリズムが使用されます。
The steps below are described for illustration purposes only; specific applications can and are likely to use different algorithms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the keys to use, as there may be one or two key selection methods that are profiled for the application's use. This appendix supplements the normative information on key location in Section 6.
以下の手順は、説明目的のために記載されています。特定のアプリケーションでは、異なるアルゴリズムを使用するか、手順のいくつかを異なる順序で実行することがあります。特定のアプリケーションでは、アプリケーションの使用にプロファイルされた1つまたは2つのキー選択方法があるため、はるかに簡単なキー選択方法が頻繁に使用されます。この付録は、キーの場所に関する規範的情報を補足するものです（セクション6）。
These algorithms include the following steps. Note that the steps can be performed in any order and do not need to be treated as distinct. For example, keys can be tried as soon as they are found, rather than collecting all the keys before trying any.
これらのアルゴリズムには、以下の手順が含まれます。手順は任意の順序で実行でき、区別する必要はありません。たとえば、キーは見つかるたびにすぐに試行できます。すべてのキーを収集する前に試行する必要はありません。
1. Collect the set of potentially applicable keys. Sources of keys may include:
1. 適用可能なキーのセットを収集します。キーのソースには、以下が含まれます。
* Keys supplied by the application protocol being used.
* 使用されているアプリケーションプロトコルによって提供されるキー。
* Keys referenced by the "jku" (JWK Set URL) Header Parameter.
* "jku" (JWK Set URL)ヘッダーパラメーターで参照されるキー。
* The key provided by the "jwk" (JSON Web Key) Header Parameter.
* "jwk" (JSON Web Key)ヘッダーパラメーターで提供されるキー。
* The key referenced by the "x5u" (X.509 URL) Header Parameter.
* "x5u" (X.509 URL)ヘッダーパラメーターで参照されるキー。
* The key provided by the "x5c" (X.509 certificate chain) Header
Parameter.
* "x5c" (X.509証明書チェーン)ヘッダーパラメーターで提供されるキー。
* Other applicable keys available to the application.
* アプリケーションで利用可能なその他の適用可能なキー。
The order for collecting and trying keys from different key
sources is typically application dependent. For example,
frequently, all keys from a one set of locations, such as local
caches, will be tried before collecting and trying keys from
other locations.
異なるキーソースからキーを収集し、試行する順序は、通常、アプリケーションに依存します。 たとえば、ローカルキャッシュなどの1つの場所からすべてのキーが試行され、 その後他の場所からキーが収集され、試行される場合がよくあります。
2. Filter the set of collected keys. For instance, some applications will use only keys referenced by "kid" (key ID) or "x5t" (X.509 certificate SHA-1 thumbprint) parameters. If the application uses the JWK "alg" (algorithm), "use" (public key use), or "key_ops" (key operations) parameters, keys with inappropriate values of those parameters would be excluded. Additionally, keys might be filtered to include or exclude keys with certain other member values in an application-specific manner. For some applications, no filtering will be applied.
2. 収集されたキーのセットをフィルターリングします。たとえば、一部のアプリケーションでは、"kid"（キーID）または "x5t"（X.509証明書SHA-1サムプリント）パラメーターで参照されるキーのみを使用します。アプリケーションがJWKの "alg"（アルゴリズム）、"use"（公開鍵の使用）、または "key_ops"（キー操作）パラメーターを使用する場合、これらのパラメーターの不適切な値を持つキーは除外されます。さらに、アプリケーション固有の方法で、特定の他のメンバー値を持つキーを含めたり除外したりすることがあります。一部のアプリケーションでは、フィルターリングは適用されません。
3. Order the set of collected keys. For instance, keys referenced by "kid" (key ID) or "x5t" (X.509 certificate SHA-1 thumbprint) parameters might be tried before keys with neither of these values. Likewise, keys with certain member values might be ordered before keys with other member values. For some applications, no ordering will be applied.
3. 収集されたキーのセットを順序付けます。たとえば、"kid"（キーID）または "x5t"（X.509証明書SHA-1サムプリント）パラメーターで参照されるキーは、これらの値を持たないキーよりも先に試行される場合があります。同様に、特定のメンバー値を持つキーは、他のメンバー値を持つキーよりも先に順序付けられる場合があります。一部のアプリケーションでは、順序付けが適用されません。
4. Make trust decisions about the keys. Signatures made with keys not meeting the application's trust criteria would not be accepted. Such criteria might include, but is not limited to, the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application.
4. キーに関する信頼判断を行います。アプリケーションの信頼基準を満たさないキーで作成された署名は受け入れられません。このような基準には、キーのソース、URLから取得されたキーのTLS証明書が検証されるかどうか、X.509証明書のキーが有効な証明書チェーンでバックアップされているかどうか、およびアプリケーションが知っているその他の情報が含まれる場合があります。
5. Attempt signature or MAC validation for a JWS or decryption of a JWE with some or all of the collected and possibly filtered and/ or ordered keys. A limit on the number of keys to be tried might be applied. This process will normally terminate following a successful validation or decryption.
5. 収集された、おそらくフィルターリングされ、順序付けされたキーの一部またはすべてを使用して、JWSの署名またはMACの検証、またはJWEの復号化を試行します。試行するキーの数に制限が適用される場合があります。このプロセスは、通常、検証または復号化が成功した場合に終了します。
Note that it is reasonable for some applications to perform signature or MAC validation prior to making a trust decision about a key, since keys for which the validation fails need no trust decision.
一部のアプリケーションでは、キーに関する信頼判断を行う前に署名またはMACの検証を実行することが合理的です。なぜなら、検証に失敗したキーについては、信頼判断が必要ないからです。
Conforming implementations must reject input containing critical extensions that are not understood or cannot be processed. The following JWS must be rejected by all implementations, because it uses an extension Header Parameter name "http://example.invalid/ UNDEFINED" that they do not understand. Any other similar input, in which the use of the value "http://example.invalid/UNDEFINED" is substituted for any other Header Parameter name not understood by the implementation, must also be rejected.
準拠する実装は、理解できないまたは処理できない重要な拡張機能を含む入力を拒否する必要があります。次のJWSは、実装が理解しない「http://example.invalid/UNDEFINED」という拡張ヘッダーパラメーター名を使用しているため、すべての実装によって拒否される必要があります。実装が理解しない他のヘッダーパラメーター名に「http://example.invalid/UNDEFINED」の値を使用した類似の入力も拒否する必要があります。
The JWS Protected Header value for this JWS is:
このJWSの保護されたヘッダー値は次のとおりです:
{"alg":"none",
"crit":["http://example.invalid/UNDEFINED"],
"http://example.invalid/UNDEFINED":true
}
{"alg":"none",
"crit":["http://example.invalid/UNDEFINED"],
"http://example.invalid/UNDEFINED":true
}
The complete JWS that must be rejected is as follows (with line breaks for display purposes only):
拒否される必要がある完全なJWSは、次のとおりです（表示目的の改行を含む）:
eyJhbGciOiJub25lIiwNCiAiY3JpdCI6WyJodHRwOi8vZXhhbXBsZS5jb20vVU5ERU ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbS9VTkRFRklORUQiOnRydWUNCn0. RkFJTA.
eyJhbGciOiJub25lIiwNCiAiY3JpdCI6WyJodHRwOi8vZXhhbXBsZS5jb20vVU5ERU ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbS9VTkRFRklORUQiOnRydWUNCn0. RkFJTA.
In some contexts, it is useful to integrity-protect content that is not itself contained in a JWS. One way to do this is to create a JWS in the normal fashion using a representation of the content as the payload but then delete the payload representation from the JWS and send this modified object to the recipient rather than the JWS. When using the JWS Compact Serialization, the deletion is accomplished by replacing the second field (which contains BASE64URL(JWS Payload)) value with the empty string; when using the JWS JSON Serialization, the deletion is accomplished by deleting the "payload" member. This method assumes that the recipient can reconstruct the exact payload used in the JWS. To use the modified object, the recipient reconstructs the JWS by re-inserting the payload representation into the modified object and uses the resulting JWS in the usual manner. Note that this method needs no support from JWS libraries, as applications can use this method by modifying the inputs and outputs of standard JWS libraries.
JWSに含まれていないコンテンツを整合性保護する場合、いくつかの文脈では、有用です。これを行う方法の1つは、コンテンツの表現をペイロードとして使用して通常の方法でJWSを作成した後、ペイロード表現をJWSから削除し、この変更されたオブジェクトをJWSではなく受信者に送信することです。JWSコンパクトシリアル化を使用する場合、削除は、2番目のフィールド（BASE64URL（JWSペイロード）を含む）の値を空の文字列に置き換えることによって実行されます。JWS JSONシリアル化を使用する場合、削除は、「ペイロード」メンバーを削除することによって実行されます。この方法は、受信者がJWSで使用された正確なペイロードを再構築できることを前提としています。変更されたオブジェクトを使用するには、受信者は、ペイロード表現を変更されたオブジェクトに再挿入して、通常の方法で結果のJWSを使用します。この方法は、アプリケーションが標準のJWSライブラリの入出力を変更することによって、JWSライブラリからのサポートを必要としません。
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]で探索され、これらのすべてがこのドキュメントに影響を与えました。
Thanks to Axel Nennker for his early implementation and feedback on the JWS and JWE specifications.
JWSおよびJWE仕様に対する初期の実装とフィードバックについて、Axel Nennkerに感謝します。
This specification is the work of the JOSE working group, which includes dozens of active and dedicated participants. In particular, the following individuals contributed ideas, feedback, and wording that influenced this specification:
この仕様は、数十人のアクティブで献身的な参加者を含むJOSEワーキンググループの作業です。とくに、次の個人が、この仕様に影響を与えるアイデア、フィードバック、および用語を提供しました:
Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de Medeiros, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe Hildebrand, Jeff Hodges, Russ Housley, Edmund Jay, Tero Kivinen, Ben Laurie, Ted Lemon, James Manger, Matt Miller, Kathleen Moriarty, Tony Nadalin, Hideki Nara, Axel Nennker, John Panzer, Ray Polk, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Jim Schaad, Paul Tarjan, Hannes Tschofenig, and Sean Turner.
Dirk Balfanz、Richard Barnes、Brian Campbell、Alissa Cooper、Breno de Medeiros、Stephen Farrell、Yaron Y. Goland、Dick Hardt、Joe Hildebrand、Jeff Hodges、Russ Housley、Edmund Jay、Tero Kivinen、Ben Laurie、Ted Lemon、James Manger、Matt Miller、Kathleen Moriarty、Tony Nadalin、Hideki Nara、Axel Nennker、John Panzer、Ray Polk、Emmanuel Raviart、Eric Rescorla、Pete Resnick、Jim Schaad、Paul Tarjan、Hannes Tschofenig、およびSean Turner。
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Security Area Directors during the creation of this specification.
Jim SchaadとKaren O'DonoghueがJOSEワーキンググループを議長し、Sean Turner、Stephen Farrell、およびKathleen Moriartyがこの仕様の作成中にセキュリティーエリアディレクターを務めました。