[要約] RFC 7515はJSON Web Signature (JWS)に関する仕様で、デジタル署名やメッセージ認証コード（MAC）をJSON形式で安全に表現する方法を定義しています。この仕様の目的は、Webアプリケーション間で情報を安全に交換するための手段を提供することにあります。JWSは、トークン認証、情報交換の完全性保証、メッセージの署名など、セキュリティが重要な場面で広く利用されています。関連するRFCには、RFC 7519 (JSON Web Token, JWT)、RFC 7520 (Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE))、RFC 7518 (JSON Web Algorithms (JWA))があり、これらはJWSと共にJSONベースのセキュリティトークンや暗号化技術の標準を形成しています。
Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7515 Microsoft
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
N. Sakimura
NRI
May 2015
JSON Web Signature (JWS)
JSON Web Signature（JWS）
Abstract
概要
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）仕様で説明されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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 Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Notational Conventions .....................................4
2. Terminology .....................................................5
3. JSON Web Signature (JWS) Overview ...............................7
3.1. JWS Compact Serialization Overview .........................7
3.2. JWS JSON Serialization Overview ............................8
3.3. Example JWS ................................................8
4. JOSE Header .....................................................9
4.1. Registered Header Parameter Names .........................10
4.1.1. "alg" (Algorithm) Header Parameter .................10
4.1.2. "jku" (JWK Set URL) Header Parameter ...............10
4.1.3. "jwk" (JSON Web Key) Header Parameter ..............11
4.1.4. "kid" (Key ID) Header Parameter ....................11
4.1.5. "x5u" (X.509 URL) Header Parameter .................11
4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter ...11
4.1.7. "x5t" (X.509 Certificate SHA-1 Thumbprint)
Header Parameter ...................................12
4.1.8. "x5t#S256" (X.509 Certificate SHA-256
Thumbprint) Header Parameter .......................12
4.1.9. "typ" (Type) Header Parameter ......................12
4.1.10. "cty" (Content Type) Header Parameter .............13
4.1.11. "crit" (Critical) Header Parameter ................14
4.2. Public Header Parameter Names .............................14
4.3. Private Header Parameter Names ............................14
5. Producing and Consuming JWSs ...................................15
5.1. Message Signature or MAC Computation ......................15
5.2. Message Signature or MAC Validation .......................16
5.3. String Comparison Rules ...................................17
6. Key Identification .............................................18
7. Serializations .................................................19
7.1. JWS Compact Serialization .................................19
7.2. JWS JSON Serialization ....................................19
7.2.1. General JWS JSON Serialization Syntax ..............20
7.2.2. Flattened JWS JSON Serialization Syntax ............21
8. TLS Requirements ...............................................22
9. IANA Considerations ............................................22
9.1. JSON Web Signature and Encryption Header
Parameters Registry .......................................23
9.1.1. Registration Template ..............................23
9.1.2. Initial Registry Contents ..........................24
9.2. Media Type Registration ...................................26
9.2.1. Registry Contents ..................................26
10. Security Considerations .......................................27
10.1. Key Entropy and Random Values ............................27
10.2. Key Protection ...........................................28
10.3. Key Origin Authentication ................................28
10.4. Cryptographic Agility ....................................28
10.5. Differences between Digital Signatures and MACs ..........28
10.6. Algorithm Validation .....................................29
10.7. Algorithm Protection .....................................29
10.8. Chosen Plaintext Attacks .................................30
10.9. Timing Attacks ...........................................30
10.10. Replay Protection .......................................30
10.11. SHA-1 Certificate Thumbprints ...........................30
10.12. JSON Security Considerations ............................31
10.13. Unicode Comparison Security Considerations ..............31
11. References ....................................................32
11.1. Normative References .....................................32
11.2. Informative References ...................................34
Appendix A. JWS Examples .........................................36
A.1. Example JWS Using HMAC SHA-256 ............................36
A.1.1. Encoding ..............................................36
A.1.2. Validating ............................................38
A.2. Example JWS Using RSASSA-PKCS1-v1_5 SHA-256 ...............38
A.2.1. Encoding ..............................................38
A.2.2. Validating ............................................42
A.3. Example JWS Using ECDSA P-256 SHA-256 .....................42
A.3.1. Encoding ..............................................42
A.3.2. Validating ............................................44
A.4. Example JWS Using ECDSA P-521 SHA-512 .....................45
A.4.1. Encoding ..............................................45
A.4.2. Validating ............................................47
A.5. Example Unsecured JWS .....................................47
A.6. Example JWS Using General JWS JSON Serialization ..........48
A.6.1. JWS Per-Signature Protected Headers ...................48
A.6.2. JWS Per-Signature Unprotected Headers .................49
A.6.3. Complete JOSE Header Values ...........................49
A.6.4. Complete JWS JSON Serialization Representation ........50
A.7. Example JWS Using Flattened JWS JSON Serialization ........51
Appendix B. "x5c" (X.509 Certificate Chain) Example ..............52
Appendix C. Notes on Implementing base64url Encoding without
Padding ..............................................54
Appendix D. Notes on Key Selection ...............................55
Appendix E. Negative Test Case for "crit" Header Parameter .......57
Appendix F. Detached Content .....................................57
Acknowledgements ..................................................58
Authors' Addresses ................................................58
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ベースの[RFC7159]データ構造を使用してデジタル署名またはメッセージ認証コード（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 Authorizationヘッダーや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）[JWA]仕様と、その仕様で定義されているIANAレジストリで説明されています。関連する暗号化機能は、別のJSON Web Encryption（JWE）[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このドキュメントの「は、「RFCで使用して要件レベルを示すためのキーワード」[RFC2119]で説明されているように解釈されます。解釈が適用されるのは、用語がすべて大文字である場合のみです。
BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 2.
BASE64URL（OCTETS）は、セクション2に従って、OCTETSのbase64urlエンコーディングを示します。
UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation of STRING, where STRING is a sequence of zero or more Unicode [UNICODE] characters.
UTF8（STRING）は、STRINGのUTF-8 [RFC3629]表現のオクテットを示します。STRINGは、ゼロ個以上のUnicode [UNICODE]文字のシーケンスです。
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 [RFC20]表現のオクテットを示します。STRINGは、0個以上のASCII文字のシーケンスです。
The concatenation of two values A and B is denoted as A || B.
2つの値AとBの連結は、A ||として示されます。 Ｂ．
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）デジタル署名またはMACedメッセージを表すデータ構造。
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オブジェクト署名および暗号化）ヘッダーは、一連のヘッダーパラメーターで構成されます。
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署名デジタル署名またはJWS保護ヘッダーとJWSペイロード上のMAC。
Header Parameter A name/value pair that is member of the JOSE Header.
ヘッダーパラメータJOSEヘッダーのメンバーである名前と値のペア。
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保護ヘッダーJSONオブジェクトは、JWS署名デジタル署名またはMAC操作によって保全性が保護されたヘッダーパラメーターを含みます。 JWS Compact Serializationの場合、これはJOSEヘッダー全体で構成されます。 JWS JSONシリアライゼーションの場合、これはJOSEヘッダーのコンポーネントの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保護されていないヘッダー整合性が保護されていないヘッダーパラメーターを含むJSONオブジェクト。これは、JWS JSONシリアル化を使用する場合にのみ存在できます。
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エンコーディングRFC 4648 [RFC4648]のセクション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署名入力デジタル署名または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コンパクトシリアライゼーションコンパクトでURLセーフな文字列としてのJWSの表現。
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シリアライゼーションJSONオブジェクトとしてのJWSの表現。 JWSコンパクトシリアライゼーションとは異なり、JWS JSONシリアライゼーションでは、複数のデジタル署名やMACを同じコンテンツに適用できます。この表現は、コンパクト化にもURLセーフにも最適化されていません。
Unsecured JWS A JWS that provides no integrity protection. Unsecured JWSs use the "alg" value "none".
非セキュアJWS整合性保護を提供しないJWS。保護されていない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.
衝突に強い名前他の名前と衝突する可能性が非常に低い方法で名前を割り当てることができる名前空間内の名前。衝突耐性のある名前空間の例には、ドメイン名、ITU-T X.660およびX.670推奨シリーズで定義されているオブジェクト識別子（OID）、およびユニバーサルユニーク識別子（UUID）[RFC4122]が含まれます。管理者に委任された名前空間を使用する場合、名前の定義者は、名前の定義に使用する名前空間の部分を制御できるように、適切な予防策を講じる必要があります。
StringOrURI A JSON string value, with the additional requirement that while arbitrary string values MAY be used, any value containing a ":" character MUST be a URI [RFC3986]. StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied.
StringOrURI JSON文字列値。任意の文字列値が使用される可能性がある一方で、「：」文字を含む値はすべてURI [RFC3986]である必要があります。 StringOrURI値は、変換または正規化が適用されていない、大文字と小文字を区別する文字列として比較されます。
The terms "JSON Web Encryption (JWE)", "JWE Compact Serialization", and "JWE JSON Serialization" are defined by the JWE specification [JWE].
「JSON Web Encryption（JWE）」、「JWE Compact Serialization」、および「JWE JSON Serialization」という用語は、JWE仕様[JWE]によって定義されています。
The terms "Digital Signature" and "Message Authentication Code (MAC)" are defined by the "Internet Security Glossary, Version 2" [RFC4949].
「デジタル署名」と「メッセージ認証コード（MAC）」という用語は、「インターネットセキュリティ用語集、バージョン2」[RFC4949]で定義されています。
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処理されたコンテンツを表します。 RFC 7159 [RFC7159]のセクション2に従い、これらのJSONデータ構造には、JSON値または構造文字の前後に空白や改行が含まれる場合があります。 JWSはこれらの論理値を表します（それぞれはセクション2で定義されています）。
o JOSE Header o JWS Payload o JWS Signature
o JOSEヘッダーo JWSペイロードo JWS署名
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で定義されています）。
o JWS Protected Header o JWS Unprotected Header
o JWS保護ヘッダーo JWS非保護ヘッダー
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つのシリアル化を定義します。JWSコンパクトシリアル化と呼ばれるコンパクトでURLセーフなシリアル化とJWS JSONシリアル化と呼ばれるJSONシリアル化です。どちらのシリアライゼーションでも、JSONには任意のオクテットシーケンスを直接表す方法がないため、JWS保護ヘッダー、JWSペイロード、およびJWS署名は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コンパクトシリアライゼーションでは、JWS非保護ヘッダーは使用されません。この場合、JOSEヘッダーとJWS保護ヘッダーは同じです。
In the JWS Compact Serialization, a JWS is represented as the concatenation:
JWSコンパクトシリアライゼーションでは、JWSは連結として表されます。
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)
BASE64URL（UTF8（JWS保護ヘッダー））|| 「。」 || BASE64URL（JWSペイロード）|| 「。」 || BASE64URL（JWS署名）
See Section 7.1 for more information about the JWS Compact Serialization.
JWSコンパクトシリアライゼーションの詳細については、セクション7.1を参照してください。
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非保護ヘッダーの一方または両方が存在する必要があります。この場合、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オブジェクトとして表されます。
o "protected", with the value BASE64URL(UTF8(JWS Protected Header))
o "header", with the value JWS Unprotected Header
o "payload", with the value BASE64URL(JWS Payload)
o "signature", with the value BASE64URL(JWS Signature)
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 Unprotected Header値は、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値と使用されるキー値を表す正確なオクテットシーケンスの指定が含まれます。
The following example JWS Protected Header declares that the encoded object is a JSON Web Token [JWT] and the JWS Protected Header and the JWS Payload are secured using the HMAC SHA-256 [RFC2104] [SHS] algorithm:
次の例のJWS保護ヘッダーは、エンコードされたオブジェクトがJSON Webトークン[JWT]であり、JWS保護ヘッダーとJWSペイロードがHMAC SHA-256 [RFC2104] [SHS]アルゴリズムを使用して保護されることを宣言しています。
{"typ":"JWT",
"alg":"HS256"}
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
このJWS保護ヘッダーをBASE64URL（UTF8（JWS保護ヘッダー））としてエンコードすると、次の値が得られます。
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}
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:
付録A.1およびbase64urlで指定されたキーを使用したHMAC SHA-256アルゴリズムを使用したJWS署名入力ASCII（BASE64URL（UTF8（JWS Protected Header））|| '。' || BASE64URL（JWS Payload））のHMACの計算結果をエンコードすると、次の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コンパクトシリアライゼーションを使用して、この完全な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シリアライゼーションを使用した例を含む追加の例については、付録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ヘッダー内のヘッダーパラメータ名は一意である必要があります。 ECWSScript 5.1 [ECMAScript]のセクション15.12（「JSONオブジェクト」）で指定されているように、JWSパーサーは重複するヘッダーパラメーター名を持つJWSを拒否するか、字句的に最後の重複メンバー名のみを返すJSONパーサーを使用する必要があります。
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項に従って重要なヘッダーパラメータとしてリストされていない限り、この仕様で定義されていないすべてのヘッダーパラメータは、理解できない場合は無視する必要があります。
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で使用する次のヘッダーパラメータ名は、セクション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は共通のヘッダーパラメータスペースを共有しています。パラメータが両方の仕様で使用される場合、その使用法は仕様間で互換性がなければなりません。
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」の値は、[JWA]によって確立されたIANAの「JSON Web署名および暗号化アルゴリズム」レジストリに登録するか、衝突防止名を含む値にする必要があります。 「alg」値は、StringOrURI値を含む、大文字と小文字が区別されるASCII文字列です。このヘッダーパラメータは存在しなければならず、実装によって理解および処理される必要があります。
A list of defined "alg" values for this use can be found in the IANA "JSON Web Signature and Encryption Algorithms" registry established by [JWA]; the initial contents of this registry are the values defined in Section 3.1 of [JWA].
この用途に定義された「alg」値のリストは、[JWA]によって確立されたIANAの「JSON Web署名および暗号化アルゴリズム」レジストリにあります。このレジストリの初期コンテンツは、[JWA]のセクション3.1で定義されている値です。
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セット[JWK]としてエンコードする必要があります。リソースの取得に使用されるプロトコルは、整合性保護を提供する必要があります。 JWKセットを取得するHTTP GET要求は、トランスポート層セキュリティ（TLS）を使用する必要があります[RFC2818] [RFC5246]。 RFC 6125 [RFC6125]のセクション6に従って、サーバーのIDを検証する必要があります。また、TLS要件についてはセクション8を参照してください。このヘッダーパラメータの使用はオプションです。
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キー）ヘッダーパラメータは、JWSのデジタル署名に使用されるキーに対応する公開キーです。このキーは、JSON Webキー[JWK]として表されます。このヘッダーパラメータの使用はオプションです。
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.
「子供」（キーID）ヘッダーパラメータは、JWSを保護するために使用されたキーを示すヒントです。このパラメーターを使用すると、発信者はキーの変更を受信者に明示的に通知できます。 「kid」値の構造は指定されていません。その値は大文字小文字を区別する文字列でなければなりません。このヘッダーパラメータの使用はオプションです。
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公開キー証明書または証明書チェーン[RFC5280]のリソースを参照するURI [RFC3986]です。識別されたリソースは、RFC 5945 [RFC5280]に準拠する証明書または証明書チェーンの表現をPEMエンコード形式で提供する必要があり、各証明書はRFC 4945 [RFC4945]のセクション6.1で指定されているように区切られます。 JWSのデジタル署名に使用されるキーに対応する公開キーを含む証明書は、最初の証明書でなければなりません。この後には、追加の証明書が続く場合があります。後続の各証明書は、前の証明書を認証するために使用されるものです。リソースの取得に使用されるプロトコルは、整合性保護を提供する必要があります。証明書を取得するためのHTTP GET要求は、TLS [RFC2818] [RFC5246]を使用する必要があります。 RFC 6125 [RFC6125]のセクション6に従って、サーバーのIDを検証する必要があります。また、TLS要件についてはセクション8を参照してください。このヘッダーパラメータの使用はオプションです。
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公開キー証明書または証明書チェーン[RFC5280]が含まれています。証明書または証明書チェーンは、証明書の値の文字列のJSON配列として表されます。配列内の各文字列は、base64でエンコードされています（[RFC4648]のセクション4-base64urlでエンコードされていません）DER [ITU.X690.2008] PKIX証明書の値。 JWSのデジタル署名に使用されるキーに対応する公開キーを含む証明書は、最初の証明書でなければなりません。この後には、追加の証明書が続く場合があります。後続の各証明書は、前の証明書を認証するために使用されるものです。受信者は、RFC 5280 [RFC5280]に従って証明書チェーンを検証し、検証エラーが発生した場合は証明書または証明書チェーンが無効であると見なす必要があります。このヘッダーパラメータの使用はオプションです。
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サムプリント）ヘッダーパラメーターは、デジタル署名に使用されるキーに対応するX.509証明書[RFC5280]のDERエンコードのbase64urlエンコードSHA-1サムプリント（別名ダイジェスト）です。 JWS。証明書の拇印は、証明書の指紋とも呼ばれます。このヘッダーパラメータの使用はオプションです。
4.1.8. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) Header Parameter
4.1.8. "x5t＃S256"（X.509 Certificate SHA-256 Thumbprint）ヘッダーパラメーター
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サムプリント）ヘッダーパラメータは、使用されるキーに対応するX.509証明書[RFC5280]のDERエンコーディングのbase64urlエンコードSHA-256サムプリント（別名ダイジェスト）です。 JWSにデジタル署名します。証明書の拇印は、証明書の指紋とも呼ばれます。このヘッダーパラメータの使用はオプションです。
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アプリケーションによって実行されます。このヘッダーパラメータの使用はオプションです。
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 /"プレフィックスを省略することをお勧めします。メディアタイプ値を使用する受信者は、「/」を含まない「typ」値の前に「application /」が付加されているかのように扱う必要があります。たとえば、「example」の「typ」値を使用して「application / example」メディアタイプを表す必要がありますが、メディアタイプ「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コンパクトシリアライゼーションまたはJWEコンパクトシリアライゼーションを使用するJWSまたはJWEであることを示すことができます。 「標準」値「JOSE + JSON」をアプリケーションで使用して、このオブジェクトがJWS JSONシリアライゼーションまたはJWE JSONシリアライゼーションを使用する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」（コンテンツタイプ）ヘッダーパラメータは、保護されたコンテンツ（ペイロード）のメディアタイプ[IANA.MediaTypes]を宣言するためにJWSアプリケーションによって使用されます。これは、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 /"プレフィックスを省略することをお勧めします。メディアタイプの値を使用する受信者は、「/」を含まない「cty」値の前に「application /」が付加されているかのように扱う必要があります。たとえば、「example」の「cty」値は「application / example」メディアタイプを表すために使用する必要がありますが、メディアタイプ「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.
「クリティカル」（クリティカル）ヘッダーパラメータは、この仕様および[JWA]の拡張機能が使用されていることを示しており、これらを理解して処理する必要があります。その値は、これらの拡張機能を使用するJOSEヘッダーに存在するヘッダーパラメーター名をリストする配列です。リストされた拡張ヘッダーパラメータのいずれかが受信者によって理解およびサポートされていない場合、JWSは無効です。プロデューサーは、JWSで使用するためにこの仕様または[JWA]で定義されたヘッダーパラメーター名、重複した名前、または「クリティカル」リストのJOSEヘッダー内のヘッダーパラメーター名として発生しない名前を含めてはなりません（MUST NOT）。プロデューサーは、空のリスト「[]」を「クリティカル」値として使用してはなりません。クリティカルリストに、JWSで使用するためにこの仕様または[JWA]で定義されたヘッダーパラメータ名が含まれている場合、またはその使用に関する他の制約に違反している場合、受信者はJWSが無効であると見なす場合があります。使用する場合、このヘッダーパラメーターは整合性を保護する必要があります。したがって、JWS保護ヘッダー内でのみ発生する必要があります。このヘッダーパラメータの使用はオプションです。このヘッダーパラメータは、実装によって理解および処理される必要があります。
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
JWSのプロデューサーとコンシューマーは、プライベート名であるヘッダーパラメーター名（登録済みヘッダーパラメーター名（セクション4.1）ではない名前）またはパブリックヘッダーパラメーター名を使用することに同意する場合があります。
(Section 4.2). Unlike Public Header Parameter names, Private Header Parameter names are subject to collision and should be used with caution.
（セクション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保護ヘッダーまたはJWS非保護ヘッダー、あるいはその両方）を構成する必要なヘッダーパラメーターのセットを含む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保護ヘッダーが存在しない場合（これは、JWS JSONシリアル化を使用していて、「保護された」メンバーが存在しない場合にのみ発生します）、この値を空の文字列にします。
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署名入力ASCII（BASE64URL（UTF8（JWS Protected Header））|| '。' || BASE64URL（JWS Payload））で使用されている特定のアルゴリズムに対して定義された方法でJWS署名を計算します。 "alg"（アルゴリズム）ヘッダーパラメーターは、JWSEヘッダーに存在する必要があり、アルゴリズム値はJWS署名の構築に使用されるアルゴリズムを正確に表します。
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シリアライゼーションが使用されている場合は、デジタル署名または実行されている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コンパクトシリアル化はBASE64URL（UTF8（JWS Protected Header））です。 「。」 || BASE64URL（JWSペイロード）|| 「。」 || BASE64URL（JWS署名）。 JWS JSONシリアライゼーションについては、セクション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シグネチャ値がある場合、JWSが受け入れられるためには、どのJWSシグネチャ値が正常に検証される必要があるかはアプリケーションの決定です。場合によっては、すべてを正常に検証する必要があります。そうしないと、JWSは無効と見なされます。他の場合では、特定のJWS署名値のみを正常に検証する必要があります。ただし、すべての場合において、少なくとも1つのJWSシグネチャ値が正常に検証されるか、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コンパクトシリアル化を使用する場合、これらのコンポーネントは、JWS保護ヘッダー、JWSペイロード、およびJWS署名のbase64urlエンコード表現であり、JWS JSONシリアル化を使用する場合、これらのコンポーネントには、エンコードされていないJWS非保護ヘッダー値も含まれます。 JWSコンパクトシリアライゼーションを使用する場合、JWS保護ヘッダー、JWSペイロード、およびJWS署名は、順番にbase64urlでエンコードされた値として表され、各値は単一のピリオド（ '。'）文字によって次の値と区切られます。その結果、2つの区切りピリオド文字が使用されます。 JWS JSONシリアライゼーションについては、セクション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保護ヘッダーのエンコードされた表現を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エンコード表現であることを確認します。 JWS保護ヘッダーをこのJSONオブジェクトにします。
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保護ヘッダーにします。それ以外の場合、JWS JSONシリアライゼーションを使用するときは、JOSEヘッダーを対応するJWS保護ヘッダーとJWS非保護ヘッダーのメンバーの結合にします。これらはすべて完全に有効なJSONオブジェクトでなければなりません。この手順では、結果のJOSEヘッダーに重複するヘッダーパラメーター名が含まれていないことを確認します。 JWS JSONシリアライゼーションを使用する場合、この制限には、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署名のエンコードされた表現を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署名をJWS署名入力に対して検証するASCII（BASE64URL（UTF8（JWS Protected Header））|| '。' || BASE64URL（JWS Payload））は、使用されるアルゴリズムに定義された方法で検証します。 「alg」（アルゴリズム）ヘッダーパラメータの値。存在する必要があります。アルゴリズムの検証に関するセキュリティの考慮事項については、セクション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シリアライゼーションが使用されている場合は、表現に含まれているデジタル署名またはMAC値ごとにこのプロセス（手順4〜8）を繰り返します。
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シリアライゼーションの場合、成功した検証と失敗した検証のいずれかを示す結果をアプリケーションに返します。 JWSコンパクトシリアライゼーションの場合、結果は単に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オブジェクトのメンバーおよび値と比較する必要があります。たとえば、アルゴリズムが何であるかをチェックする際、JOSEヘッダーのメンバー名に対してUnicode文字列「alg」がチェックされ、一致するヘッダーパラメーター名があるかどうかが確認されます。次に、同じプロセスを使用して、「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 [RFC7159]のセクション8.3で説明されています。実行される文字列比較演算は等値と不等式だけなので、同じ規則を使用して、メンバー名とメンバー値の両方を既知の文字列と比較できます。
These comparison rules MUST be used for all JSON string comparisons except in cases where the definition of the member explicitly calls out that a different comparison rule is to be used for that member value. Only the "typ" and "cty" member values defined in this specification do not use these comparison rules.
これらの比較規則は、メンバーの定義がそのメンバー値に異なる比較規則を使用することを明示的に要求する場合を除いて、すべてのJSON文字列比較に使用する必要があります。この仕様で定義されている「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名を「キッド」（キー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」を使用して、使用されるキーを識別できます。これらのヘッダーパラメータは、伝達する情報が信頼の決定に利用される場合、完全性が保護されている必要があります。ただし、信頼の決定に使用される唯一の情報がキーである場合、これらのパラメーターを整合性で保護する必要はありません。異なるキーが使用されるようにパラメーターを変更すると、検証が失敗するためです。
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.
プロデューサは、アプリケーションが使用されるキーを決定するために別の手段または規則を使用しない限り、使用されるキーを識別するためにヘッダパラメータに十分な情報を含める必要があります。使用されるアルゴリズムがキーを必要とし（「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コンパクトシリアライゼーションまたはJWS JSONシリアライゼーションの2つのシリアライゼーションのいずれかを使用します。この仕様を使用するアプリケーションは、そのアプリケーションに使用されるシリアル化およびシリアル化機能を指定する必要があります。たとえば、アプリケーションは、JWS JSONシリアル化のみが使用されること、単一の署名またはMAC値に対するJWS JSONシリアル化サポートのみが使用されること、または複数の署名および/またはMAC値に対するサポートが使用されることを指定する場合があります。 JWS実装は、サポートするように設計されたアプリケーションに必要な機能を実装するだけで済みます。
The JWS Compact Serialization represents digitally signed or MACed content as a compact, URL-safe string. This string is:
JWSコンパクトシリアライゼーションは、デジタル署名またはMACedコンテンツをコンパクトなURLセーフ文字列として表します。この文字列は次のとおりです。
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)
BASE64URL（UTF8（JWS保護ヘッダー））|| 「。」 || BASE64URL（JWSペイロード）|| 「。」 || BASE64URL（JWS署名）
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シリアライゼーションは、デジタル署名またはMACedコンテンツを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つの密接に関連する構文が定義されています。複数のデジタル署名やMAC操作でコンテンツを保護できる完全に一般的な構文と、単一のデジタル署名または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"メンバーが存在し、値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」メンバーの値は、JSONオブジェクトの配列である必要があります。各オブジェクトは、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.
JWS保護ヘッダー値が空でない場合、「保護」メンバーが存在し、値BASE64URL（UTF8（JWS Protected Header））を含んでいる必要があります。それ以外の場合は、存在しない必要があります。これらのヘッダーパラメータ値は整合性が保護されています。
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」メンバーが存在しなければならず、JWS Unprotected Header値が空でない場合は値JWS Unprotected Headerが含まれている必要があります。それ以外の場合は、存在しない必要があります。この値は、文字列としてではなく、エンコードされていないJSONオブジェクトとして表されます。これらのヘッダーパラメータ値は整合性が保護されていません。
signature The "signature" member MUST be present and contain the value BASE64URL(JWS Signature).
signature「signature」メンバーが存在し、値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.
「alg」ヘッダーパラメータ値が伝達されるように、「保護された」メンバーと「ヘッダー」メンバーの少なくとも1つが各署名/ MAC計算に存在する必要があります。
Additional members can be present in both the JSON objects defined above; if not understood by implementations encountering them, they MUST be ignored.
上記で定義した両方のJSONオブジェクトに追加のメンバーを含めることができます。それらに遭遇する実装によって理解されない場合、それらは無視されなければなりません。
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つのヘッダーパラメーター値のセットの和集合です。要素、および（2）シグネチャ/ MACの配列要素の「ヘッダー」メンバー内のJWS非保護ヘッダー。これらのヘッダーパラメータのセットの和集合がJOSEヘッダーを構成します。 2つの場所のヘッダーパラメータ名はばらばらである必要があります。
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署名値は、JWSコンパクトシリアライゼーションと同じ方法で、対応するJOSEヘッダー値のパラメーターを使用して計算されます。これには、「signatures」配列で表される各JWS署名の値が、その署名/ MAC計算のJWS保護ヘッダーの値である場合に、JWSコンパクトシリアライゼーションの同じパラメーターに対して計算される値と同じであるという望ましい特性があります。 （整合性保護されたヘッダーパラメータ値を表す）は、JWSコンパクトシリアライゼーションで使用されるものと一致します。
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>"}]
}
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」メンバーを削除してフラット化し、代わりに、トップレベルのJSONオブジェクトの「signatures」配列（「protected」、「header」、および「signature」メンバー）で使用するために定義されたメンバーを（ 「ペイロード」メンバーと同じレベル）。
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>"
}
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をサポートする必要があります。実装する必要がある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を使用して機密性保護を適用する必要があります。現在使用に適していると考えられている暗号スイートのガイダンスについては、RFC 6176 [RFC6176]を含む、IETF TLSワーキンググループによる現在の出版物を参照してください。また、TLSを使用するソフトウェアとサービスのセキュリティを向上させるための推奨事項については、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（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サーバー証明書にエンコードされたサービスプロバイダーのIDを、RFC 6125 [RFC6125]のセクション6に記載されている手順を使用して検証する必要があります。
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.
値は、jose-reg-review @ ietf.orgメーリングリストで3週間のレビュー期間を経て、1人以上のDesignated Expertsの助言を得て、Specification Required [RFC5226]ベースで登録されます。ただし、公開前の値の割り当てを可能にするために、指定された専門家は、そのような仕様が公開されることに納得したら、登録を承認することができます。
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register header parameter: 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.
レビュー期間内に、Designated Expertsは登録リクエストを承認または拒否し、この決定をレビューリストとIANAに通知します。拒否には、要求を成功させる方法についての説明と、該当する場合は提案を含める必要があります。 21日よりも長い期間未確定の登録要求は、解決のために（iesg@ietf.orgメーリングリストを使用して）IESGに通知することができます。
Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or useful only for a single application, and whether the registration description is clear.
Designated Expertsが適用する必要がある基準には、提案された登録が既存の機能と重複しているかどうか、一般的に適用できる可能性が高いか、または単一のアプリケーションに対してのみ有用であるかどうか、および登録の説明が明確かどうかが含まれます。
IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.
IANAは、Designated Expertsからのレジストリの更新のみを受け入れ、登録のすべてのリクエストをレビューメーリングリストに転送する必要があります。
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」など）。この仕様の中心的な目標は、結果の表現をコンパクトにすることです。そのため、やむを得ない理由がない限り、名前は短く、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.
変更管理者：Standards Track RFCsについては、「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.
仕様ドキュメント：パラメータを指定する1つまたは複数のドキュメントへの参照。できれば、ドキュメントのコピーを取得するために使用できるURIを含む。関連セクションの表示も含まれる場合がありますが、必須ではありません。
This section registers the Header Parameter names defined in Section 4.1 in this registry.
このセクションでは、セクション4.1で定義されたヘッダーパラメータ名をこのレジストリに登録します。
o Header Parameter Name: "alg" o Header Parameter Description: Algorithm o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.1 of RFC 7515
o ヘッダーパラメーター名：「alg」oヘッダーパラメーターの説明：アルゴリズムoヘッダーパラメーターの使用場所：JWS o変更コントローラー：IESG o仕様書：RFC 7515のセクション4.1.1
o Header Parameter Name: "jku" o Header Parameter Description: JWK Set URL o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.2 of RFC 7515
o ヘッダーパラメータ名：「jku」oヘッダーパラメータの説明：JWKセットURL oヘッダーパラメータの使用場所：JWS o変更コントローラ：IESG o仕様書：RFC 7515のセクション4.1.2
o Header Parameter Name: "jwk"
o Header Parameter Description: JSON Web Key
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.3 of RFC 7515
o Header Parameter Name: "kid"
o Header Parameter Description: Key ID
o Header Parameter Usage Location(s): JWS
o Change Controller: IESG
o Specification Document(s): Section 4.1.4 of RFC 7515
o Header Parameter Name: "x5u" o Header Parameter Description: X.509 URL o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.5 of RFC 7515
o ヘッダーパラメーター名：「x5u」oヘッダーパラメーターの説明：X.509 URL oヘッダーパラメーターの使用場所：JWS o変更コントローラー：IESG o仕様書：RFC 7515のセクション4.1.5
o Header Parameter Name: "x5c" o Header Parameter Description: X.509 Certificate Chain o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.6 of RFC 7515
o ヘッダーパラメーター名：「x5c」oヘッダーパラメーターの説明：X.509証明書チェーンoヘッダーパラメーターの使用場所：JWS o変更コントローラー：IESG o仕様書：RFC 7515のセクション4.1.6
o Header Parameter Name: "x5t" o Header Parameter Description: X.509 Certificate SHA-1 Thumbprint o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.7 of RFC 7515
o ヘッダーパラメーター名： "x5t" oヘッダーパラメーターの説明：X.509証明書のSHA-1サムプリントoヘッダーパラメーターの使用場所：JWS o変更コントローラー：IESG o仕様書：RFC 7515のセクション4.1.7
o Header Parameter Name: "x5t#S256" o Header Parameter Description: X.509 Certificate SHA-256 Thumbprint o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.8 of RFC 7515
o ヘッダーパラメーター名：「x5t＃S256」oヘッダーパラメーターの説明：X.509証明書のSHA-256サムプリントoヘッダーパラメーターの使用場所：JWS o変更コントローラー：IESG o仕様書：RFCのセクション4.1.8 7515
o Header Parameter Name: "typ" o Header Parameter Description: Type o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.9 of RFC 7515
o ヘッダーパラメーター名：「typ」oヘッダーパラメーターの説明：タイプoヘッダーパラメーターの使用場所：JWS o変更コントローラー：IESG o仕様書：RFC 7515のセクション4.1.9
o Header Parameter Name: "cty" o Header Parameter Description: Content Type o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.10 of RFC 7515
o ヘッダーパラメーター名：「cty」oヘッダーパラメーターの説明：コンテンツタイプoヘッダーパラメーターの使用場所：JWS o変更コントローラー：IESG o仕様書：RFC 7515のセクション4.1.10
o Header Parameter Name: "crit" o Header Parameter Description: Critical o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.11 of RFC 7515
o ヘッダーパラメーター名：「crit」oヘッダーパラメーターの説明：クリティカルoヘッダーパラメーターの使用場所：JWS o変更コントローラー：IESG o仕様書：RFC 7515のセクション4.1.11
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.
このセクションでは、「application / jose」メディアタイプ[RFC2046]を、RFC 6838 [RFC6838]で説明されている方法で[Media Types]レジストリ[IANA.MediaTypes]に登録します。これは、コンテンツがJWSまたはJWS Compact SerializationまたはJWE Compact Serializationを使用するJWE。このセクションでは、「アプリケーション/ jose + json」メディアタイプを「メディアタイプ」レジストリに登録します。これは、コンテンツがJWS JSONシリアル化またはJWE JSONシリアル化を使用するJWSまたはJWEであることを示すために使用できます。
o Type name: application o Subtype name: jose o Required parameters: n/a o Optional parameters: n/a o Encoding considerations: 8bit; application/jose values are encoded as a series of base64url-encoded values (some of which may be the empty string), each separated from the next by a single period ('.') character. o Security considerations: See the Security Considerations section of RFC 7515. o Interoperability considerations: n/a o Published specification: RFC 7515 o Applications that use this media type: OpenID Connect, Mozilla Persona, Salesforce, Google, Android, Windows Azure, Xbox One, Amazon Web Services, and numerous others that use JWTs o Fragment identifier considerations: n/a o Additional information:
o タイプ名：アプリケーションoサブタイプ名：jose o必須パラメーター：n / a oオプションパラメーター：n / a oエンコーディングに関する考慮事項：8ビット。 application / jose値は、base64urlでエンコードされた一連の値（一部は空の文字列である場合があります）としてエンコードされ、それぞれが単一のピリオド（ '。'）文字で次の値と区切られます。 oセキュリティに関する考慮事項：RFC 7515のセキュリティに関する考慮事項のセクションを参照してください。o相互運用性に関する考慮事項：n / ao公開仕様：RFC 7515 oこのメディアタイプを使用するアプリケーション：OpenID Connect、Mozilla Persona、Salesforce、Google、Android、Windows Azure、Xbox One 、アマゾンウェブサービス、およびJWTを使用する他の多数のoフラグメント識別子の考慮事項：n / ao追加情報：
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
o Person & email address to contact for further information:
Michael B. Jones, mbj@microsoft.com
o Intended usage: COMMON
o Restrictions on usage: none
o Author: Michael B. Jones, mbj@microsoft.com
o Change Controller: IESG
o Provisional registration? No
o Type name: application
o Subtype name: jose+json
o Required parameters: n/a
o Optional parameters: n/a
o Encoding considerations: 8bit; application/jose+json values are
represented as a JSON Object; UTF-8 encoding SHOULD be employed
for the JSON object.
o Security considerations: See the Security Considerations section
of RFC 7515
o Interoperability considerations: n/a
o Published specification: RFC 7515
o Applications that use this media type: Nimbus JOSE + JWT library
o Fragment identifier considerations: n/a
o Additional information:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
o Person & email address to contact for further information: Michael B. Jones, mbj@microsoft.com o Intended usage: COMMON o Restrictions on usage: none o Author: Michael B. Jones, mbj@microsoft.com o Change Controller: IESG o Provisional registration? No
o 詳細について連絡する人とメールアドレス：Michael B. Jones、mbj @ microsoft.com o使用目的：COMMON o使用制限：なしo作者：Michael B. Jones、mbj @ microsoft.com o変更管理者：IESG o仮登録？番号
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署名の構文と処理バージョン2.0」[W3C.NOTE-xmldsig-core2-20130411]のセキュリティに関するすべての考慮事項は、XML固有のもの以外のこの仕様にも適用されます。同様に、「XML署名のベストプラクティス」[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キーを配布するために使用されるキー管理技術は、データ発信元認証を提供する必要があります。それ以外の場合、コンテンツは不明なソースから完全に配信されます。
See Section 8.1 of [JWA] for security considerations on cryptographic agility.
暗号化の俊敏性に関するセキュリティの考慮事項については、[JWA]のセクション8.1を参照してください。
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の検証は、対称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]のコンテキストで詳細に説明されています。このリスクは、次のすべてが当てはまる場合に発生します。
o Verifiers of a signature support multiple algorithms.
o 署名の検証者は、複数のアルゴリズムをサポートしています。
o Given an existing signature, an attacker can find another payload that produces the same signature value with a different algorithm.
o 攻撃者は、既存のシグネチャを指定すると、異なるアルゴリズムで同じシグネチャ値を生成する別のペイロードを見つけることができます。
o The payload crafted by the attacker is valid in the application context.
o 攻撃者が作成したペイロードは、アプリケーションコンテキストで有効です。
There are several ways for an application to mitigate algorithm substitution attacks:
アプリケーションがアルゴリズム置換攻撃を軽減する方法はいくつかあります。
o Use only digital signature algorithms that are not vulnerable to substitution attacks. Substitution attacks are only feasible if an attacker can compute pre-images for a hash function accepted by the recipient. All JWA-defined signature algorithms use SHA-2 hashes, for which there are no known pre-image attacks, as of the time of this writing.
o代替攻撃に対して脆弱ではないデジタル署名アルゴリズムのみを使用します。置換攻撃は、攻撃者が受信者が受け入れたハッシュ関数の事前画像を計算できる場合にのみ実行可能です。すべてのJWA定義の署名アルゴリズムはSHA-2ハッシュを使用します。この記事の執筆時点では、既知のプリイメージ攻撃はありません。
o Require that the "alg" Header Parameter be carried in the JWS Protected Header. (This is always the case when using the JWS Compact Serialization and is the approach taken by CMS [RFC6211].)
o 「alg」ヘッダーパラメータがJWS保護ヘッダーに含まれている必要があります。 （これは、JWSコンパクトシリアライゼーションを使用する場合は常に当てはまり、CMS [RFC6211]が採用するアプローチです。）
o Include a field containing the algorithm in the application payload, and require that it be matched with the "alg" Header Parameter during verification. (This is the approach taken by PKIX [RFC5280].)
o アルゴリズムを含むフィールドをアプリケーションのペイロードに含め、検証中に「alg」ヘッダーパラメータと照合することを要求します。 （これは、PKIX [RFC5280]が採用したアプローチです。）
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パーサーによって完全に拒否される必要があります。
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）Data Interchange Format」[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ヘッダー内のヘッダーパラメータ名は一意である必要があります。 ECWSScript 5.1 [ECMAScript]のセクション15.12（「JSONオブジェクト」）で指定されているように、JWSパーサーは重複するヘッダーパラメーター名を持つJWSを拒否するか、字句的に最後の重複メンバー名のみを返す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.
したがって、この仕様では、[RFC7159]のセクション4の「SHOULD」がプロデューサーによって「MUST」として扱われ、「MUST」として扱われるか、またはコンシューマによってECMAScript 5.1で指定された方法で扱われることが必要です。使用されるJSONパーサーがメンバー名の一意性を強制しないか、重複するメンバー名に対して予測できない値を返す場合、あいまいで潜在的に悪用可能な状況が発生する可能性があります。
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は無効であると見なす必要があります。
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 [RFC7159]のセクション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 Basic Multilingual Plane以外の文字を含めることができます。たとえば、G音部記号文字（U + 1D11E）は、JSON文字列で "\ uD834 \ uDD1E"として表すことができます。理想的には、JWS実装は、基本多言語面外の文字が確実に保持され、正しく比較されるようにする必要があります。あるいは、これらの文字が基礎となるJSON実装に存在する制限を行使するためにこれが不可能な場合は、それらを含む入力を拒否する必要があります。
[ECMAScript] Ecma International, "ECMAScript Language Specification, 5.1 Edition", ECMA 262, June 2011, <http://www.ecma-international.org/ecma-262/5.1/ ECMA-262.pdf>.
[ECMAScript] Ecma International、「ECMAScript言語仕様、5.1版」、ECMA 262、2011年6月、<http://www.ecma-international.org/ecma-262/5.1/ ECMA-262.pdf>。
[IANA.MediaTypes] IANA, "Media Types", <http://www.iana.org/assignments/media-types>.
[IANA.MediaTypes] IANA、「メディアタイプ」、<http://www.iana.org/assignments/media-types>。
[ITU.X690.2008] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 2008.
[ITU.X690.2008] International Telecommunications Union、「Information Technology-ASN.1 encoding rules：Specification of Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）and Distinguished Encoding Rules（DER）」、ITU-T勧告X .690、2008。
[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.
[JWA]ジョーンズ、M。、「JSON Web Algorithms（JWA）」、RFC 7518、DOI 10.17487 / RFC7518、2015年5月、<http://www.rfc-editor.org/info/rfc7518>。
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <http://www.rfc-editor.org/info/rfc7517>.
[JWK]ジョーンズ、M。、「JSON Web Key（JWK）」、RFC 7517、DOI 10.17487 / RFC7517、2015年5月、<http://www.rfc-editor.org/info/rfc7517>。
[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワークインターチェンジのASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<http://www.rfc-editor.org/info/rfc20>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、DOI 10.17487 / RFC2045、1996年11月、<http：//www.rfc- editor.org/info/rfc2045>。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、<http://www.rfc-editor.org / info / rfc2046>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, DOI 10.17487/RFC4945, August 2007, <http://www.rfc-editor.org/info/rfc4945>.
[RFC4945] Korver、B。、「IKEv1 / ISAKMP、IKEv2、およびPKIXのインターネットIPセキュリティPKIプロファイル」、RFC 4945、DOI 10.17487 / RFC4945、2007年8月、<http://www.rfc-editor.org/ info / rfc4945>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<http://www.rfc-editor.org/info/rfc4949>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<http://www.rfc-editor.org/info/rfc6125>。
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 2011, <http://www.rfc-editor.org/info/rfc6176>.
[RFC6176]ターナー、S。およびT.ポーク、「Prohibiting Secure Sockets Layer（SSL）Version 2.0」、RFC 6176、DOI 10.17487 / RFC6176、2011年3月、<http://www.rfc-editor.org/info/ rfc6176>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。
[CanvasApp] Facebook, "Canvas Applications", <http://developers.facebook.com/docs/authentication/ canvas>.
[CanvasApp] Facebook、「Canvas Applications」、<http://developers.facebook.com/docs/authentication/ canvas>。
[JSS] Bradley, J. and N. Sakimura, Ed., "JSON Simple Sign", September 2010, <http://jsonenc.info/jss/1.0/>.
[JSS] Bradley、J。およびN.崎村編、「JSON Simple Sign」、2010年9月、<http://jsonenc.info/jss/1.0/>。
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <http://www.rfc-editor.org/info/rfc7516>.
[JWE]ジョーンズ、M。およびJ.ヒルデブランド、「JSON Web Encryption（JWE）」、RFC 7516、DOI 10.17487 / RFC7516、2015年5月、<http://www.rfc-editor.org/info/rfc7516>。
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <http://www.rfc-editor.org/info/rfc7519>.
[JWT]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<http://www.rfc-editor.org / info / rfc7519>。
[MagicSignatures] Panzer, J., Ed., Laurie, B., and D. Balfanz, "Magic Signatures", January 2011, <http://salmon-protocol.googlecode.com/svn/trunk/ draft-panzer-magicsig-01.html>.
[MagicSignatures] Panzer、J.、Ed。、Laurie、B。、およびD. Balfanz、「Magic Signatures」、2011年1月、<http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer- magicsig-01.html>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<http：//www.rfc-editor .org / info / rfc2104>。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、DOI 10.17487 / RFC3447、2003年2月、<http：//www.rfc -editor.org/info/rfc3447>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<http：//www.rfc-editor .org / info / rfc4086>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「Universally Unique IDentifier（UUID）URN Namespace」、RFC 4122、DOI 10.17487 / RFC4122、2005年7月、<http：//www.rfc- editor.org/info/rfc4122>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC6211] Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute", RFC 6211, DOI 10.17487/RFC6211, April 2011, <http://www.rfc-editor.org/info/rfc6211>.
[RFC6211] Schaad、J。、「Cryptographic Message Syntax（CMS）Algorithm Identifier Protection Attribute」、RFC 6211、DOI 10.17487 / RFC6211、2011年4月、<http://www.rfc-editor.org/info/rfc6211>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<http：//www.rfc- editor.org/info/rfc6838>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.
[SHS]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、FIPS PUB 180-4、2012年3月、<http://csrc.nist.gov/publications/fips/fips180-4/ fips-180 -4.pdf>。
[W3C.NOTE-xmldsig-bestpractices-20130411] Hirsch, F. and P. Datta, "XML Signature Best Practices", World Wide Web Consortium Note NOTE-xmldsig-bestpractices-20130411, April 2013, <http://www.w3.org/TR/2013/ NOTE-xmldsig-bestpractices-20130411/>.
[W3C.NOTE-xmldsig-bestpractices-20130411] Hirsch、F。およびP. Datta、「XML署名のベストプラクティス」、World Wide WebコンソーシアムノートNOTE-xmldsig-bestpractices-20130411、2013年4月、<http：// www。 w3.org/TR/2013/ NOTE-xmldsig-bestpractices-20130411 />。
[W3C.NOTE-xmldsig-core2-20130411] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Roessler, T., Yiu, K., Datta, P., and S. Cantor, "XML Signature Syntax and Processing Version 2.0", World Wide Web Consortium Note NOTE-xmldsig-core2-20130411, April 2013, <http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>.
[W3C.NOTE-xmldsig-core2-20130411] Eastlake、D.、Reagle、J.、Solo、D.、Hirsch、F.、Roessler、T.、Yiu、K.、Datta、P。、およびS. Cantor 、「XML署名構文と処理バージョン2.0」、World Wide Web Consortium Note NOTE-xmldsig-core2-20130411、2013年4月、<http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/ >。
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"}
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保護ヘッダー）を表す実際のオクテットシーケンスも以下に含まれています。 （改行のプラットフォーム表現の違い（CRLFとLF）、行の最初と最後の間隔の違い、最後の行に終端の改行があるかどうか、およびその他の原因により、あいまいさが生じる可能性があることに注意してください。この例では、最初の行に先頭または末尾のスペースがなく、CRLF改行（13、10）が最初の行と2番目の行の間で発生し、2番目の行に先頭のスペースが1つ（32）あり、末尾のスペースがなく、最後の行この例でのUTF8（JWS保護ヘッダー）を表すオクテット（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]
「１２３、 ３４、 １１６、 １２１、 １１２、 ３４、 ５８、 ３４、 ７４、 ８７、 ８４、 ３４、 ４４、 １３、 １０、 ３２、 ３４、 ９７、 １０８、 １０３、 ３４、 ５８、 ３４、 ７２、 ８３、 ５０、 ５３、 ５４、 ３４、 １２５」
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
このJWS保護ヘッダーをBASE64URL（UTF8（JWS保護ヘッダー））としてエンコードすると、次の値が得られます。
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}
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 Payload））としてエンコードすると、次の値が表示されます（表示専用の改行あり）。
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 Protected Header））として組み合わせる|| 「。」 || BASE64URL（JWS Payload）は次の文字列を提供します（表示目的のみの改行付き）：
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]
「１１６、 ２４、 ２２３、 １８０、 １５１、 １５３、 ２２４、 ３７、 ７９、 ２５０、 ９６、 １２５、 ２１６、 １７３、 １８７、 １８６、 ２２、 ２１２、 ３７、 ７７、 １０５、 ２１４、 １９１、 ２４０、 ９１、 ８８、 ５、 ８８、 ８３、 １３２、 １４１、 １２１」
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コンパクトシリアライゼーションを使用して、この完全な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値を検証するために、HMAC SHA-への入力として、正しいキーとJWS署名入力（これは、2番目のピリオド文字を含まないまでのJWSコンパクトシリアル化表現の最初のサブストリング）を使用する前のプロセスを繰り返します。 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"}
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]
「１２３、 ３４、 ９７、 １０８、 １０３、 ３４、 ５８、 ３４、 ８２、 ８３、 ５０、 ５３、 ５４、 ３４、 １２５」
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 Payload）の値は同じになるので、その計算はここでは繰り返されません。
{"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 Protected Header））として組み合わせる|| 「。」 || BASE64URL（JWS Payload）は次の文字列を提供します（表示目的のみの改行付き）：
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 ewHgHAjLYsp1ZSe7zFY Hj7C6ul7TjeLQeZD_YwD66t62wDmpe_HlB-TNBA -njbglfIsRLtXlnDzQkv5dTltRJ11BKBBypeeF6689rjcJIDEz9RWdc " "DP"： "BwKfV3Akq5_MFZDFZCnW-WZL-CCo83WoZvnLQwCTeDv8uzluRSnm71I3Q CLdhrqE2e9YkxvuxdBfpT_PI7Yz-FOKnu1R6HsJeDCjn12Sk3vmAktV2zb 34MCdy7cpdTh_YVr7tss2u6vneTwrA86rZtu5Mbr1C1XsmvkxHQAdYo0"、 "DQ"： "h_96-mK1R_7glhsum81dZxjTnYynPbZpHziZjeeHcXYsXaaMwkOlODsWa 7I9xXDoRwbKgB719rrmI2oKr6N3Do9U0ajaHF-NKJnwgjMd2w9cjz3_-KY NlxAr2v4IKhGNpmM5iIgOS1VZnOZ68m6_pbLBSp3nssTdlqvd0tIiTHU"、 "気"：" 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秘密鍵がRSA署名関数に渡されます。RSA署名関数は、ハッシュタイプSHA-256とJWS署名入力も入力として受け取ります。デジタル署名の結果は、ビッグエンディアン整数を表すオクテットシーケンスです。この例では、次のとおりです。
[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シグニチャー）としてエンコードすると、次の値が生成されます（表示目的でのみ改行されます）。
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コンパクトシリアライゼーションを使用して、この完全なJWS表現が生成されます（表示専用の改行あり）。
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コンパクトシリアライゼーション表現の最初の部分文字列）を渡します。 SHA-256ハッシュ関数を使用するように構成されているRSASSA-PKCS1-v1_5署名検証子に2番目のピリオド文字を含めます）。
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"}
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, 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 Protected Header））としてエンコードすると、次の値が得られます。
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 Payload）の値は同じになるので、その計算はここでは繰り返されません。
{"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 Protected Header））として組み合わせる|| 「。」 || BASE64URL（JWS Payload）は次の文字列を提供します（表示目的のみの改行付き）：
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_tue659LNpXW6pCyStyYQQYYQQYQQYYQYQQYQQYYQYQQQYQYYQQYQQYQQYYQQQYQQYQQYQQYQQYQQQQdQuQM
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がECDSA署名関数に渡されます。この関数は、曲線タイプP-256、ハッシュタイプSHA-256、およびJWS署名入力を入力として受け取ります。デジタル署名の結果は、楕円曲線（EC）ポイント（R、S）です。ここで、RとSは符号なし整数です。この例では、ビッグエンディアン整数を表すオクテットシーケンスとして指定されたRおよびSの値は次のとおりです。
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| 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 Signature）としてエンコードすると、次の値が生成されます（表示専用の改行あり）。
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コンパクトシリアライゼーションを使用して、この完全な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をデコード）を2つの32オクテットシーケンスに分割する必要があります。最初はRを表し、2番目はSを表します。次に、公開鍵（x 、y）、署名（R、S）、およびJWS署名入力（これは、2番目のピリオド文字が含まれるまでのJWS Compact Serialization表現の最初のサブストリングです）を使用するように構成されているECDSA署名検証SHA-256ハッシュ関数を使用したP-256曲線。
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"}
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]
「１２３、 ３４、 ９７、 １０８、 １０３、 ３４、 ５８、 ３４、 ６９、 ８３、 ５３、 ４９、 ５０、 ３４、 １２５」
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文字列「ペイロード」です。この文字列の表現は、次のオクテットシーケンスです。
[80, 97, 121, 108, 111, 97, 100]
「８０、 ９７、 １２１、 １０８、 １１１、 ９７、 １００」
Encoding this JWS Payload as BASE64URL(JWS Payload) gives this value:
このJWSペイロードをBASE64URL（JWS Payload）としてエンコードすると、次の値が得られます。
UGF5bG9hZA
乾かす
Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string:
これらをBASE64URL（UTF8（JWS Protected Header））として組み合わせる|| 「。」 || BASE64URL（JWS Payload）は次の文字列を提供します。
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"、 "×"： "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がECDSA署名関数に渡されます。この関数は、曲線タイプP-521、ハッシュタイプ、SHA-512、およびJWS署名入力も入力として受け取ります。デジタル署名の結果はECポイント（R、S）です。ここで、RとSは符号なし整数です。この例では、ビッグエンディアン整数を表すオクテットシーケンスとして指定されたRおよびSの値は次のとおりです。
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| 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 Signature）としてエンコードすると、次の値が生成されます（表示専用の改行あり）。
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZOXWYKYWYKYWYKYWYKYWYKJYKYWYKYWYKYKYWYKJYKYKYKYQJQYQJQYQJQYQJQYQJQYQJYKJQYQJQKQYQJYKJQYQJYKYY
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コンパクトシリアライゼーションを使用して、この完全なJWS表現が生成されます（表示専用の改行あり）。
eyJhbGciOiJFUzUxMiJ9 . UGF5bG9hZA . AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
eyJhbGciOiJFUzUxMiJ9。 UGF5bG9hZA。 AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZOXWYKYWYKYWYKYWYKYWYKJYKYWYKYWYKYKYWYKJYKYKYKYQJQYQJQYQJQYQJQYQJQYQJYKJQYQJQKQYQJYKJQYQJYKYY
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）を渡します。 SHA-512ハッシュ関数でP-521曲線を使用するように構成されたECDSA署名検証へのJWS署名入力。
The following example JWS Protected Header declares that the encoded object is an Unsecured JWS:
次の例のJWS保護ヘッダーは、エンコードされたオブジェクトが非セキュアJWSであることを宣言しています。
{"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 Payload）の値は同じになるので、その計算はここでは繰り返されません。
{"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コンパクトシリアライゼーションを使用して、この完全な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"}
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"}
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値は、署名ごとのヘッダーパラメーターを使用して両方のキーに提供されます。これらのキーIDを表すために使用される2つのJWS非保護ヘッダー値は次のとおりです。
{"kid":"2010-12-29"}
and
そして
{"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非保護ヘッダー値を組み合わせると、最初と2番目の署名にそれぞれ使用されるJOSEヘッダー値は次のようになります。
{"alg":"RS256",
"kid":"2010-12-29"}
and
そして
{"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"}]
}
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シリアル化構文を使用した例が含まれています。この例は、単一のデジタル署名またはMACをフラット化されたJSON構造で伝達する機能を示しています。
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"
}
Appendix B. "x5c" (X.509 Certificate Chain) Example
付録B.「x5c」（X.509証明書チェーン）の例
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.
この付録では、パディングを使用する標準のbase64エンコードおよびデコード関数に基づいて、パディングなしでbase64urlエンコードおよびデコード関数を実装する方法について説明します。
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 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
}
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. キーについて信頼の決定を下します。アプリケーションの信頼基準を満たさないキーで作成された署名は受け入れられません。そのような基準には、キーのソース、TLS証明書がURLから取得されたキーを検証するかどうか、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の検証を実行するのが妥当です。
Appendix E. Negative Test Case for "crit" Header Parameter
付録E.「crit」ヘッダーパラメーターの否定テストケース
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のJWS保護ヘッダー値は次のとおりです。
{"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 ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbSRUUUUQUUUUUUUUUUUUUUUUUUUUUUUUUUQUUUUUUUUUUUUUUUUUUUUU 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 Payload）を含む）の値を空の文字列に置き換えることで削除が行われます。 JWS JSONシリアライゼーションを使用する場合、削除は「ペイロード」メンバーを削除することによって行われます。この方法では、受信者がJWSで使用される正確なペイロードを再構築できると想定しています。変更されたオブジェクトを使用するために、受信者はペイロード表現を変更されたオブジェクトに再挿入してJWSを再構築し、通常の方法で結果のJWSを使用します。アプリケーションは標準のJWSライブラリの入力と出力を変更してこのメソッドを使用できるため、このメソッドはJWSライブラリからのサポートを必要としないことに注意してください。
Acknowledgements
謝辞
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.
ダークバルファンズ、リチャードバーンズ、ブライアンキャンベル、アリッサクーパー、ブレノデメデイロス、スティーブンファレル、ヤロンY.ゴランド、ディックハード、ジョーヒルデブランド、ジェフホッジス、ラスハウズリー、エドマンドジェイ、テロキビネン、ベンローリー、テッドレモン、ジェームズマンガー、マットミラー、キャスリーンモリアーティ、トニーナダリン、奈良英樹、アクセルネンカー、ジョンパンツァー、レイポーク、エマニュエルラヴィアート、エリックレスコーラ、ピートレズニック、ジムシャード、ポールタージャン、ハンネスショコフェニグ、ショーンターナー。
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.
ジムシャードとカレンオドノヒューがJOSEワーキンググループの議長を務め、ショーンターナー、スティーブンファレル、キャスリーンモリアーティがこの仕様の作成中にセキュリティエリアディレクターを務めました。
Authors' Addresses
著者のアドレス
Michael B. Jones Microsoft
マイケルB.ジョーンズマイクロソフト
EMail: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley Ping Identity
ジョンブラッドリーピンアイデンティティ
EMail: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Nat Sakimura Nomura Research Institute
崎村ナット野村総合研究所
EMail: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/