[要約] RFC 8785は、JSONデータの正規化スキームであるJCSについての要約と目的を提供します。JCSは、JSONデータの一意性と整合性を確保するために設計されています。
Independent Submission A. Rundgren
Request for Comments: 8785 Independent
Category: Informational B. Jordan
ISSN: 2070-1721 Broadcom
S. Erdtman
Spotify AB
June 2020
JSON Canonicalization Scheme (JCS)
JSON正規化スキーム（JCS）
Abstract
概要
Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results.
ハッシュや署名などの暗号化操作では、データを不変の形式で表現して、操作を確実に繰り返すことができるようにする必要があります。これに対処する1つの方法は、データの正規表現を作成することです。正規化により、「ワイヤー」上で元の形式でデータを交換することもできます。一方、プロデューサーエンドポイントとコンシューマーエンドポイントでデータの正規化されたカウンターパートに対して実行される暗号化操作は、一貫した結果を生成します。
This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting.
このドキュメントでは、JSON Canonicalization Scheme（JCS）について説明します。この仕様は、ECMAScriptによって定義されたJSONプリミティブの厳密なシリアル化メソッドを構築し、JSONデータをインターネットJSON（I-JSON）サブセットに制約し、確定的なプロパティソートを使用することにより、JSONデータの正規表現を作成する方法を定義します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8785.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8785で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Terminology
3. Detailed Operation
3.1. Creation of Input Data
3.2. Generation of Canonical JSON Data
3.2.1. Whitespace
3.2.2. Serialization of Primitive Data Types
3.2.2.1. Serialization of Literals
3.2.2.2. Serialization of Strings
3.2.2.3. Serialization of Numbers
3.2.3. Sorting of Object Properties
3.2.4. UTF-8 Generation
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. ECMAScript Sample Canonicalizer
Appendix B. Number Serialization Samples
Appendix C. Canonicalized JSON as "Wire Format"
Appendix D. Dealing with Big Numbers
Appendix E. String Subtype Handling
E.1. Subtypes in Arrays
Appendix F. Implementation Guidelines
Appendix G. Open-Source Implementations
Appendix H. Other JSON Canonicalization Efforts
Appendix I. Development Portal
Acknowledgements
Authors' Addresses
This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON [RFC8259] data by building on the strict serialization methods for JSON primitives defined by ECMAScript [ECMA-262], constraining JSON data to the I-JSON [RFC7493] subset, and by using deterministic property sorting. The output from JCS is a "hashable" representation of JSON data that can be used by cryptographic methods. The subsequent paragraphs outline the primary design considerations.
このドキュメントでは、JSON Canonicalization Scheme（JCS）について説明します。この仕様は、ECMAScript [ECMA-262]によって定義されたJSONプリミティブの厳密なシリアル化メソッドに基づいて構築し、JSONデータをI-JSON [RFC7493]サブセットに制限することにより、JSON [RFC8259]データの正規表現を作成する方法を定義します。確定的なプロパティの並べ替え。 JCSからの出力は、暗号化メソッドで使用できるJSONデータの「ハッシュ可能な」表現です。以降の段落では、主な設計上の考慮事項について概説します。
Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to accomplish this is to convert the data into a format that has a simple and fixed representation, like base64url [RFC4648]. This is how JSON Web Signature (JWS) [RFC7515] addressed this issue. Another solution is to create a canonical version of the data, similar to what was done for the XML signature [XMLDSIG] standard.
ハッシュや署名などの暗号化操作では、データを不変の形式で表現して、操作を確実に繰り返すことができるようにする必要があります。これを実現する1つの方法は、base64url [RFC4648]のような単純で固定された表現を持つフォーマットにデータを変換することです。これが、JSON Web Signature（JWS）[RFC7515]がこの問題に対処する方法です。別の解決策は、XML署名[XMLDSIG]標準に対して行われたのと同様に、データの正規バージョンを作成することです。
The primary advantage with a canonicalizing scheme is that data can be kept in its original form. This is the core rationale behind JCS. Put another way, using canonicalization enables a JSON object to remain a JSON object even after being signed. This can simplify system design, documentation, and logging.
正規化スキームの主な利点は、データを元の形式で維持できることです。これは、JCSの根底にある根拠です。言い換えると、正規化を使用すると、署名された後でもJSONオブジェクトをJSONオブジェクトのままにすることができます。これにより、システムの設計、文書化、およびロギングを簡素化できます。
To avoid "reinventing the wheel", JCS relies on the serialization of JSON primitives (strings, numbers, and literals), as defined by ECMAScript (aka JavaScript) [ECMA-262] beginning with version 6.
「ホイールの再発明」を回避するために、JCSは、バージョン6以降のECMAScript（別名JavaScript）[ECMA-262]で定義されているJSONプリミティブ（文字列、数値、およびリテラル）のシリアル化に依存しています。
Seasoned XML developers may recall difficulties getting XML signatures to validate. This was usually due to different interpretations of the quite intricate XML canonicalization rules as well as of the equally complex Web Services security standards. The reasons why JCS should not suffer from similar issues are:
熟練したXML開発者は、XML署名を検証する際の問題を思い出すかもしれません。これは通常、非常に複雑なXML正規化ルールと同様に複雑なWebサービスセキュリティ標準の解釈が異なるためでした。 JCSが同様の問題に悩まされるべきではない理由は次のとおりです。
* JSON does not have a namespace concept and default values.
* JSONには名前空間の概念とデフォルト値はありません。
* Data is constrained to the I-JSON [RFC7493] subset. This eliminates the need for specific parsers for dealing with canonicalization.
* データはI-JSON [RFC7493]サブセットに制限されています。これにより、正規化を処理するための特定のパーサーが不要になります。
* JCS-compatible serialization of JSON primitives is currently supported by most web browsers as well as by Node.js [NODEJS].
* JSONプリミティブのJCS互換のシリアル化は、現在ほとんどのWebブラウザーとNode.js [NODEJS]でサポートされています。
* The full JCS specification is currently supported by multiple open-source implementations (see Appendix G). See also Appendix F for implementation guidelines.
* 完全なJCS仕様は現在、複数のオープンソース実装でサポートされています（付録Gを参照）。実装ガイドラインについては、付録Fも参照してください。
JCS is compatible with some existing systems relying on JSON canonicalization such as JSON Web Key (JWK) Thumbprint [RFC7638] and Keybase [KEYBASE].
JCSは、JSON Web Key（JWK）Thumbprint [RFC7638]やKeybase [KEYBASE]などのJSON正規化に依存している既存のシステムと互換性があります。
For potential uses outside of cryptography, see [JSONCOMP].
暗号化以外の潜在的な用途については、[JSONCOMP]を参照してください。
The intended audiences of this document are JSON tool vendors as well as designers of JSON-based cryptographic solutions. The reader is assumed to be knowledgeable in ECMAScript, including the "JSON" object.
このドキュメントの対象読者は、JSONベースの暗号化ソリューションの設計者だけでなく、JSONツールベンダーでもあります。読者は、「JSON」オブジェクトを含むECMAScriptに精通していることを前提としています。
Note that this document is not on the IETF standards track. However, a conformant implementation is supposed to adhere to the specified behavior for security and interoperability reasons. This text uses BCP 14 to describe that necessary behavior.
このドキュメントは、IETF標準トラックには含まれていません。ただし、準拠する実装は、セキュリティと相互運用性の理由から、指定された動作に準拠することになっています。このテキストでは、BCP 14を使用してその必要な動作を説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This section describes the details related to creating a canonical JSON representation and how they are addressed by JCS.
このセクションでは、正規のJSON表現の作成に関連する詳細と、JCSによるそれらの表現方法について説明します。
Appendix F describes the RECOMMENDED way of adding JCS support to existing JSON tools.
付録Fでは、JCSサポートを既存のJSONツールに追加する推奨方法を説明しています。
Data to be canonically serialized is usually created by:
正規化されてシリアル化されるデータは、通常、次のように作成されます。
* Parsing previously generated JSON data.
* 以前に生成されたJSONデータの解析。
* Programmatically creating data.
* プログラムでデータを作成する。
Irrespective of the method used, the data to be serialized MUST be adapted for I-JSON [RFC7493] formatting, which implies the following:
使用される方法に関係なく、シリアル化されるデータは、I-JSON [RFC7493]のフォーマットに適合させる必要があります。これは、以下を意味します。
* JSON objects MUST NOT exhibit duplicate property names.
* JSONオブジェクトは、重複したプロパティ名を示すことはできません。
* JSON string data MUST be expressible as Unicode [UNICODE].
* JSON文字列データはUnicode [UNICODE]として表現できる必要があります。
* JSON number data MUST be expressible as IEEE 754 [IEEE754] double-precision values. For applications needing higher precision or longer integers than offered by IEEE 754 double precision, it is RECOMMENDED to represent such numbers as JSON strings; see Appendix D for details on how this can be performed in an interoperable and extensible way.
* JSON数値データは、IEEE 754 [IEEE754]倍精度値として表現できる必要があります。 IEEE 754倍精度で提供されるよりも高い精度または長い整数が必要なアプリケーションでは、JSON文字列などの数値を表すことをお勧めします。これを相互運用可能かつ拡張可能な方法で実行する方法の詳細については、付録Dを参照してください。
An additional constraint is that parsed JSON string data MUST NOT be altered during subsequent serializations. For more information, see Appendix E.
追加の制約は、解析されたJSON文字列データは、後続のシリアル化中に変更してはならないことです。詳細については、付録Eを参照してください。
Note: Although the Unicode standard offers the possibility of rearranging certain character sequences, referred to as "Unicode Normalization" [UCNORM], JCS-compliant string processing does not take this into consideration. That is, all components involved in a scheme depending on JCS MUST preserve Unicode string data "as is".
注：Unicode標準では、「Unicode Normalization」[UCNORM]と呼ばれる特定の文字シーケンスを再配置する可能性がありますが、JCS準拠の文字列処理ではこれが考慮されません。つまり、JCSに依存するスキームに含まれるすべてのコンポーネントは、Unicode文字列データを「そのまま」保持する必要があります。
The following subsections describe the steps required to create a canonical JSON representation of the data elaborated on in the previous section.
次のサブセクションでは、前のセクションで詳しく説明したデータの正規JSON表現を作成するために必要な手順について説明します。
Appendix A shows sample code for an ECMAScript-based canonicalizer, matching the JCS specification.
付録Aは、JCS仕様に一致するECMAScriptベースの正規化子のサンプルコードを示しています。
Whitespace between JSON tokens MUST NOT be emitted.
JSONトークン間の空白は出力してはいけません。
Assume the following JSON object is parsed:
次のJSONオブジェクトが解析されると仮定します。
{
"numbers": [333333333.33333329, 1E30, 4.50,
2e-3, 0.000000000000000000000000001],
"string": "\u20ac$\u000F\u000aA'\u0042\u0022\u005c\\\"\/",
"literals": [null, true, false]
}
If the parsed data is subsequently serialized using a serializer compliant with ECMAScript's "JSON.stringify()", the result would (with a line wrap added for display purposes only) be rather divergent with respect to the original data:
解析されたデータがECMAScriptの「JSON.stringify()」に準拠したシリアライザを使用してその後シリアル化される場合、結果は（表示目的でのみ行折り返しが追加された状態で）元のデータとは異なります。
{"numbers":[333333333.3333333,1e+30,4.5,0.002,1e-27],"string":
"€$\u000f\nA'B\"\\\\\"/","literals":[null,true,false]}
The reason for the difference between the parsed data and its serialized counterpart is due to a wide tolerance on input data (as defined by JSON [RFC8259]), while output data (as defined by ECMAScript) has a fixed representation. As can be seen in the example, numbers are subject to rounding as well.
解析されたデータとそのシリアル化されたデータの違いの理由は、入力データ（JSON [RFC8259]で定義）の許容範囲が広いためですが、出力データ（ECMAScriptで定義）の表現は固定されています。この例でわかるように、数値も丸められます。
The following subsections describe the serialization of primitive JSON data types according to JCS. This part is identical to that of ECMAScript. In the (unlikely) event that a future version of ECMAScript would invalidate any of the following serialization methods, it will be up to the developer community to either stick to this specification or create a new specification.
次のサブセクションでは、JCSによるプリミティブJSONデータ型のシリアル化について説明します。この部分はECMAScriptの部分と同じです。 ECMAScriptの将来のバージョンで以下のシリアル化メソッドが無効になる（まれに）イベントでは、この仕様に固執するか、新しい仕様を作成するかは、開発者コミュニティの責任になります。
In accordance with JSON [RFC8259], the literals "null", "true", and "false" MUST be serialized as null, true, and false, respectively.
JSON [RFC8259]に従って、リテラル「null」、「true」、および「false」は、それぞれnull、true、falseとしてシリアル化する必要があります。
For JSON string data (which includes JSON object property names as well), each Unicode code point MUST be serialized as described below (see Section 24.3.2.2 of [ECMA-262]):
JSON文字列データ（JSONオブジェクトのプロパティ名も含む）の場合、各Unicodeコードポイントは、下記のようにシリアル化する必要があります（[ECMA-262]のセクション24.3.2.2を参照）：
* If the Unicode value falls within the traditional ASCII control character range (U+0000 through U+001F), it MUST be serialized using lowercase hexadecimal Unicode notation (\uhhhh) unless it is in the set of predefined JSON control characters U+0008, U+0009, U+000A, U+000C, or U+000D, which MUST be serialized as \b, \t, \n, \f, and \r, respectively.
* Unicode値が従来のASCII制御文字の範囲（U + 0000からU + 001F）に含まれる場合、事前定義されたJSON制御文字U + 0008のセットに含まれていない限り、小文字の16進Unicode表記（\ uhhhh）を使用してシリアル化する必要があります。 U + 0009、U + 000A、U + 000C、またはU + 000D。それぞれ\ b、\ t、\ n、\ f、および\ rとしてシリアル化する必要があります。
* If the Unicode value is outside of the ASCII control character range, it MUST be serialized "as is" unless it is equivalent to U+005C (\) or U+0022 ("), which MUST be serialized as \\ and \", respectively.
* Unicode値がASCII制御文字の範囲外にある場合、U + 005C（\）またはU + 0022（ "）と同等でない限り、「そのまま」シリアル化する必要があります。 、それぞれ。
Finally, the resulting sequence of Unicode code points MUST be enclosed in double quotes (").
最後に、結果のUnicodeコードポイントのシーケンスは二重引用符（ "）で囲む必要があります。
Note: Since invalid Unicode data like "lone surrogates" (e.g., U+DEAD) may lead to interoperability issues including broken signatures, occurrences of such data MUST cause a compliant JCS implementation to terminate with an appropriate error.
注：「サロゲート」などの無効なUnicodeデータ（U + DEADなど）は、署名の破損などの相互運用性の問題を引き起こす可能性があるため、このようなデータが発生すると、準拠するJCS実装が適切なエラーで終了する必要があります。
ECMAScript builds on the IEEE 754 [IEEE754] double-precision standard for representing JSON number data. Such data MUST be serialized according to Section 7.1.12.1 of [ECMA-262], including the "Note 2" enhancement.
ECMAScriptは、JSON数値データを表すためのIEEE 754 [IEEE754]倍精度標準に基づいています。このようなデータは、「注2」の拡張を含め、[ECMA-262]のセクション7.1.12.1に従ってシリアル化する必要があります。
Due to the relative complexity of this part, the algorithm itself is not included in this document. For implementers of JCS-compliant number serialization, Google's implementation in V8 [V8] may serve as a reference. Another compatible number serialization reference implementation is Ryu [RYU], which is used by the JCS open-source Java implementation mentioned in Appendix G. Appendix B holds a set of IEEE 754 sample values and their corresponding JSON serialization.
この部分は比較的複雑であるため、アルゴリズム自体はこのドキュメントには含まれていません。 JCS準拠の番号シリアル化の実装者は、V8 [V8]でのGoogleの実装が参照として役立つ場合があります。別の互換性のある番号シリアル化リファレンス実装は、Ryu [RYU]です。これは、付録Gで説明されているJCSオープンソースJava実装で使用されます。
Note: Since Not a Number (NaN) and Infinity are not permitted in JSON, occurrences of NaN or Infinity MUST cause a compliant JCS implementation to terminate with an appropriate error.
注：非数（NaN）および無限大はJSONでは許可されていないため、NaNまたは無限大が発生すると、準拠JCS実装が適切なエラーで終了する必要があります。
Although the previous step normalized the representation of primitive JSON data types, the result would not yet qualify as "canonical" since JSON object properties are not in lexicographic (alphabetical) order.
前の手順ではプリミティブJSONデータ型の表現を正規化しましたが、JSONオブジェクトのプロパティは辞書式（アルファベット順）の順序ではないため、結果はまだ「正規」とは見なされません。
Applied to the sample in Section 3.2.2, a properly canonicalized version should (with a line wrap added for display purposes only) read as:
セクション3.2.2のサンプルに適用すると、適切に正規化されたバージョンは（表示目的でのみ行折り返しを追加して）次のように読み取る必要があります。
{"literals":[null,true,false],"numbers":[333333333.3333333,
1e+30,4.5,0.002,1e-27],"string":"€$\u000f\nA'B\"\\\\\"/"}
The rules for lexicographic sorting of JSON object properties according to JCS are as follows:
JCSによるJSONオブジェクトプロパティの辞書式ソートのルールは次のとおりです。
* JSON object properties MUST be sorted recursively, which means that JSON child Objects MUST have their properties sorted as well.
* JSONオブジェクトのプロパティは再帰的にソートする必要があります。つまり、JSON子オブジェクトのプロパティもソートする必要があります。
* JSON array data MUST also be scanned for the presence of JSON objects (if an object is found, then its properties MUST be sorted), but array element order MUST NOT be changed.
* JSON配列データもJSONオブジェクトの存在をスキャンする必要があります（オブジェクトが見つかった場合、そのプロパティをソートする必要があります）が、配列要素の順序を変更してはなりません（MUST NOT）。
When a JSON object is about to have its properties sorted, the following measures MUST be adhered to:
JSONオブジェクトがそのプロパティをソートしようとしているときは、次の措置を遵守する必要があります。
* The sorting process is applied to property name strings in their "raw" (unescaped) form. That is, a newline character is treated as U+000A.
* 並べ替えプロセスは、「生の」（エスケープされていない）形式のプロパティ名文字列に適用されます。つまり、改行文字はU + 000Aとして扱われます。
* Property name strings to be sorted are formatted as arrays of UTF-16 [UNICODE] code units. The sorting is based on pure value comparisons, where code units are treated as unsigned integers, independent of locale settings.
* 並べ替えられるプロパティ名の文字列は、UTF-16 [UNICODE]コード単位の配列としてフォーマットされます。並べ替えは純粋な値の比較に基づいて行われ、ロケール設定に関係なく、コード単位は符号なし整数として扱われます。
* Property name strings either have different values at some index that is a valid index for both strings, or their lengths are different, or both. If they have different values at one or more index positions, let k be the smallest such index; then, the string whose value at position k has the smaller value, as determined by using the "<" operator, lexicographically precedes the other string. If there is no index position at which they differ, then the shorter string lexicographically precedes the longer string.
* プロパティ名の文字列は、両方の文字列に有効なインデックスであるいくつかのインデックスで異なる値を持っているか、それらの長さが異なるか、またはその両方です。 1つ以上のインデックス位置に異なる値がある場合、kをそのようなインデックスの最小値とします。次に、「<」演算子を使用して決定された、位置kの値が小さい値の文字列が、辞書順で他の文字列の前に置かれます。それらが異なるインデックス位置がない場合は、短い文字列が辞書順で長い文字列に先行します。
In plain English, this means that property names are sorted in ascending order like the following:
プレーンな英語では、これはプロパティ名が次のように昇順でソートされることを意味します：
"" "a" "aa" "ab"
「」「a」「aa」「ab」
The rationale for basing the sorting algorithm on UTF-16 code units is that it maps directly to the string type in ECMAScript (featured in web browsers and Node.js), Java, and .NET. In addition, JSON only supports escape sequences expressed as UTF-16 code units, making knowledge and handling of such data a necessity anyway. Systems using another internal representation of string data will need to convert JSON property name strings into arrays of UTF-16 code units before sorting. The conversion from UTF-8 or UTF-32 to UTF-16 is defined by the Unicode [UNICODE] standard.
ソートアルゴリズムをUTF-16コード単位に基づいた根拠は、ECMAScript（WebブラウザーとNode.jsで機能）、Java、および.NETの文字列型に直接マッピングすることです。さらに、JSONはUTF-16コード単位として表現されたエスケープシーケンスのみをサポートしているため、このようなデータの知識と処理がとにかく必要になります。文字列データの別の内部表現を使用するシステムは、ソートする前にJSONプロパティ名文字列をUTF-16コード単位の配列に変換する必要があります。 UTF-8またはUTF-32からUTF-16への変換は、Unicode [UNICODE]標準で定義されています。
The following JSON test data can be used for verifying the correctness of the sorting scheme in a JCS implementation:
次のJSONテストデータは、JCS実装でのソートスキームの正確さを確認するために使用できます。
{
"\u20ac": "Euro Sign",
"\r": "Carriage Return",
"\ufb33": "Hebrew Letter Dalet With Dagesh",
"1": "One",
"\ud83d\ude00": "Emoji: Grinning Face",
"\u0080": "Control",
"\u00f6": "Latin Small Letter O With Diaeresis"
}
Expected argument order after sorting property strings:
プロパティ文字列をソートした後に期待される引数の順序：
"Carriage Return" "One" "Control" "Latin Small Letter O With Diaeresis" "Euro Sign" "Emoji: Grinning Face" "Hebrew Letter Dalet With Dagesh"
「復帰」「1」「コントロール」「分音記号付きラテン小文字O」「ユーロ記号」「絵文字：ニヤリと顔」「ヘゲライ文字ダゲシュ文字ダレット」
Note: For the purpose of obtaining a deterministic property order, sorting of data encoded in UTF-8 or UTF-32 would also work, but the outcome for JSON data like above would differ and thus be incompatible with this specification. However, in practice, property names are rarely defined outside of 7-bit ASCII, making it possible to sort string data in UTF-8 or UTF-32 format without conversion to UTF-16 and still be compatible with JCS. Whether or not this is a viable option depends on the environment JCS is used in.
注：確定的なプロパティの順序を取得するために、UTF-8またはUTF-32でエンコードされたデータの並べ替えも機能しますが、上記のようなJSONデータの結果は異なるため、この仕様と互換性がありません。ただし、実際には、プロパティ名が7ビットASCIIの外で定義されることはほとんどないため、UTF-16に変換せずに文字列データをUTF-8またはUTF-32形式でソートでき、JCSと互換性があります。これが実行可能なオプションであるかどうかは、JCSが使用されている環境によって異なります。
Finally, in order to create a platform-independent representation, the result of the preceding step MUST be encoded in UTF-8.
最後に、プラットフォームに依存しない表現を作成するには、前のステップの結果をUTF-8でエンコードする必要があります。
Applied to the sample in Section 3.2.3, this should yield the following bytes, here shown in hexadecimal notation:
セクション3.2.3のサンプルに適用すると、次のバイトが生成されます。ここでは、16進表記で示しています。
7b 22 6c 69 74 65 72 61 6c 73 22 3a 5b 6e 75 6c 6c 2c 74 72 75 65 2c 66 61 6c 73 65 5d 2c 22 6e 75 6d 62 65 72 73 22 3a 5b 33 33 33 33 33 33 33 33 33 2e 33 33 33 33 33 33 33 2c 31 65 2b 33 30 2c 34 2e 35 2c 30 2e 30 30 32 2c 31 65 2d 32 37 5d 2c 22 73 74 72 69 6e 67 22 3a 22 e2 82 ac 24 5c 75 30 30 30 66 5c 6e 41 27 42 5c 22 5c 5c 5c 5c 5c 22 2f 22 7d
7b 22 6c 69 74 65 72 61 6c 73 22 3a 5b 6e 75 6c 6c 2c 74 72 75 65 2c 66 61 6c 73 65 5d 2c 22 6e 75 6d 62 65 72 73 22 3a 5b 33 33 33 33 33 33 33 33 33 2e 33 33 33 33 33 33 33 2c 31 65 2b 33 30 2c 34 2e 35 2c 30 2e 30 30 32 2c 31 65 2d 32 37 5d 2c 22 73 74 72 69 6e 67 22 3a 22 e2 82 ac 24 5c 75 30 30 30 66 5c 6e 41 27 42 5c 22 5c 5c 5c 5c 5c 22 2f 22 7d
This data is intended to be usable as input to cryptographic methods.
このデータは、暗号化メソッドへの入力として使用できるように意図されています。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
It is crucial to perform sanity checks on input data to avoid overflowing buffers and similar things that could affect the integrity of the system.
システムの整合性に影響を与える可能性のあるバッファのオーバーフローや同様のものを回避するために、入力データの健全性チェックを実行することが重要です。
When JCS is applied to signature schemes like the one described in Appendix F, applications MUST perform the following operations before acting upon received data:
付録Fで説明されているような署名方式にJCSが適用される場合、アプリケーションは受信したデータを処理する前に次の操作を実行する必要があります。
1. Parse the JSON data and verify that it adheres to I-JSON.
1. JSONデータを解析し、I-JSONに準拠していることを確認します。
2. Verify the data for correctness according to the conventions defined by the ecosystem where it is to be used. This also includes locating the property holding the signature data.
2. データが使用されるエコシステムによって定義された規則に従って、データが正しいことを確認します。これには、署名データを保持するプロパティの検索も含まれます。
3. Verify the signature.
3. 署名を確認します。
If any of these steps fail, the operation in progress MUST be aborted.
これらのステップのいずれかが失敗した場合、進行中の操作を中止する必要があります。
[ECMA-262] ECMA International, "ECMAScript 2019 Language Specification", Standard ECMA-262 10th Edition, June 2019, <https://www.ecma-international.org/ecma-262/10.0/ index.html>.
[ECMA-262] ECMA International、「ECMAScript 2019 Language Specification」、Standard ECMA-262 10th Edition、2019年6月、<https://www.ecma-international.org/ecma-262/10.0/ index.html>。
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2019, DOI 10.1109/IEEESTD.2019.8766229, <https://ieeexplore.ieee.org/document/8766229>.
[IEEE754] IEEE、「IEEE Standard for Floating-Point Arithmetic」、IEEE 754-2019、DOI 10.1109 / IEEESTD.2019.8766229、<https://ieeexplore.ieee.org/document/8766229>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>.
[RFC7493]ブレイ、T。、編、「The I-JSON Message Format」、RFC 7493、DOI 10.17487 / RFC7493、2015年3月、<https://www.rfc-editor.org/info/rfc7493>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[UCNORM] The Unicode Consortium, "Unicode Normalization Forms", <https://www.unicode.org/reports/tr15/>.
[UCNORM] Unicodeコンソーシアム、「Unicode Normalization Forms」、<https://www.unicode.org/reports/tr15/>。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <https://www.unicode.org/versions/latest/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard」、<https://www.unicode.org/versions/latest/>。
[JSONCOMP] Rundgren, A., ""Comparable" JSON (JSONCOMP)", Work in Progress, Internet-Draft, draft-rundgren-comparable-json-04, 13 February 2019, <https://tools.ietf.org/html/draft-rundgren-comparable-json-04>.
[JSONCOMP] Rundgren、A。、「 "Comparable" JSON（JSONCOMP）」、Work in Progress、Internet-Draft、draft-rundgren-comparable-json-04、2019年2月13日、<https://tools.ietf.org / html / draft-rundgren-comparable-json-04>。
[KEYBASE] Keybase, "Canonical Packings for JSON and Msgpack", <https://keybase.io/docs/api/1.0/canonical_packings>.
[KEYBASE]キーベース、「JSONおよびMsgpackの正規パッキング」、<https://keybase.io/docs/api/1.0/canonical_packings>。
[NODEJS] OpenJS Foundation, "Node.js", <https://nodejs.org>.
[NODEJS] OpenJS Foundation、「Node.js」、<https://nodejs.org>。
[OPENAPI] OpenAPI Initiative, "The OpenAPI Specification: a broadly adopted industry standard for describing modern APIs", <https://www.openapis.org/>.
[OPENAPI] OpenAPIイニシアチブ、「OpenAPI仕様：最新のAPIを記述するために広く採用されている業界標準」、<https://www.openapis.org/>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>。
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<https://www.rfc-editor.org / info / rfc7515>。
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/info/rfc7638>.
[RFC7638]ジョーンズ、M。およびN.崎村、「JSON Web Key（JWK）Thumbprint」、RFC 7638、DOI 10.17487 / RFC7638、2015年9月、<https://www.rfc-editor.org/info/rfc7638> 。
[RYU] "Ryu floating point number serializing algorithm", commit 27d3c55, May 2020, <https://github.com/ulfjack/ryu>.
[RYU]「Ryu浮動小数点数シリアル化アルゴリズム」、コミット27d3c55、2020年5月、<https://github.com/ulfjack/ryu>。
[V8] Google LLC, "What is V8?", <https://v8.dev/>.
[V8] Google LLC、「V8とは」、<https://v8.dev/>。
[XMLDSIG] W3C, "XML Signature Syntax and Processing Version 1.1", W3C Recommendation, April 2013, <https://www.w3.org/TR/xmldsig-core1/>.
[XMLDSIG] W3C、「XML署名構文および処理バージョン1.1」、W3C勧告、2013年4月、<https://www.w3.org/TR/xmldsig-core1/>。
Below is an example of a JCS canonicalizer for usage with ECMAScript-based systems:
以下は、ECMAScriptベースのシステムで使用するJCS正規化子の例です。
////////////////////////////////////////////////////////////
// Since the primary purpose of this code is highlighting //
// the core of the JCS algorithm, error handling and //
// UTF-8 generation were not implemented. //
////////////////////////////////////////////////////////////
var canonicalize = function(object) {
var buffer = '';
serialize(object);
return buffer;
function serialize(object) {
if (object === null || typeof object !== 'object' ||
object.toJSON != null) {
/////////////////////////////////////////////////
// Primitive type or toJSON, use "JSON" //
/////////////////////////////////////////////////
buffer += JSON.stringify(object);
} else if (Array.isArray(object)) {
/////////////////////////////////////////////////
// Array - Maintain element order //
/////////////////////////////////////////////////
buffer += '[';
let next = false;
object.forEach((element) => {
if (next) {
buffer += ',';
}
next = true;
/////////////////////////////////////////
// Array element - Recursive expansion //
/////////////////////////////////////////
serialize(element);
});
buffer += ']';
} else {
/////////////////////////////////////////////////
// Object - Sort properties before serializing //
/////////////////////////////////////////////////
buffer += '{';
let next = false;
Object.keys(object).sort().forEach((property) => {
if (next) {
buffer += ',';
}
next = true;
/////////////////////////////////////////////
// Property names are strings, use "JSON" //
/////////////////////////////////////////////
buffer += JSON.stringify(property);
buffer += ':';
//////////////////////////////////////////
// Property value - Recursive expansion //
//////////////////////////////////////////
serialize(object[property]);
});
buffer += '}';
}
}
};
The following table holds a set of ECMAScript-compatible number serialization samples, including some edge cases. The column "IEEE 754" refers to the internal ECMAScript representation of the "Number" data type, which is based on the IEEE 754 [IEEE754] standard using 64-bit (double-precision) values, here expressed in hexadecimal.
次の表は、いくつかのエッジケースを含む、ECMAScript互換の番号シリアル化サンプルのセットを保持しています。 「IEEE 754」列は、「数値」データタイプの内部ECMAScript表現を指します。これは、64ビット（倍精度）値を使用するIEEE 754 [IEEE754]標準に基づいており、ここでは16進数で表現されています。
+==================+===========================+====================+
| IEEE 754 | JSON Representation | Comment |
+==================+===========================+====================+
| 0000000000000000 | 0 | Zero |
+------------------+---------------------------+--------------------+
| 8000000000000000 | 0 | Minus zero |
+------------------+---------------------------+--------------------+
| 0000000000000001 | 5e-324 | Min pos number |
+------------------+---------------------------+--------------------+
| 8000000000000001 | -5e-324 | Min neg number |
+------------------+---------------------------+--------------------+
| 7fefffffffffffff | 1.7976931348623157e+308 | Max pos number |
+------------------+---------------------------+--------------------+
| ffefffffffffffff | -1.7976931348623157e+308 | Max neg number |
+------------------+---------------------------+--------------------+
| 4340000000000000 | 9007199254740992 | Max pos int (1) |
+------------------+---------------------------+--------------------+
| c340000000000000 | -9007199254740992 | Max neg int (1) |
+------------------+---------------------------+--------------------+
| 4430000000000000 | 295147905179352830000 | ~2**68 (2) |
+------------------+---------------------------+--------------------+
| 7fffffffffffffff | | NaN (3) |
+------------------+---------------------------+--------------------+
| 7ff0000000000000 | | Infinity (3) |
+------------------+---------------------------+--------------------+
| 44b52d02c7e14af5 | 9.999999999999997e+22 | |
+------------------+---------------------------+--------------------+
| 44b52d02c7e14af6 | 1e+23 | |
+------------------+---------------------------+--------------------+
| 44b52d02c7e14af7 | 1.0000000000000001e+23 | |
+------------------+---------------------------+--------------------+
| 444b1ae4d6e2ef4e | 999999999999999700000 | |
+------------------+---------------------------+--------------------+
| 444b1ae4d6e2ef4f | 999999999999999900000 | |
+------------------+---------------------------+--------------------+
| 444b1ae4d6e2ef50 | 1e+21 | |
+------------------+---------------------------+--------------------+
| 3eb0c6f7a0b5ed8c | 9.999999999999997e-7 | |
+------------------+---------------------------+--------------------+
| 3eb0c6f7a0b5ed8d | 0.000001 | |
+------------------+---------------------------+--------------------+
| 41b3de4355555553 | 333333333.3333332 | |
+------------------+---------------------------+--------------------+
| 41b3de4355555554 | 333333333.33333325 | |
+------------------+---------------------------+--------------------+
| 41b3de4355555555 | 333333333.3333333 | |
+------------------+---------------------------+--------------------+
| 41b3de4355555556 | 333333333.3333334 | |
+------------------+---------------------------+--------------------+
| 41b3de4355555557 | 333333333.33333343 | |
+------------------+---------------------------+--------------------+
| becbf647612f3696 | -0.0000033333333333333333 | |
+------------------+---------------------------+--------------------+
| 43143ff3c1cb0959 | 1424953923781206.2 | Round to even (4) |
+------------------+---------------------------+--------------------+
Table 1: ECMAScript-Compatible JSON Number Serialization Samples
表1：ECMAScript互換のJSON番号シリアル化サンプル
Notes:
ノート：
(1) For maximum compliance with the ECMAScript "JSON" object, values that are to be interpreted as true integers SHOULD be in the range -9007199254740991 to 9007199254740991. However, how numbers are used in applications does not affect the JCS algorithm.
（1）ECMAScript「JSON」オブジェクトに最大限準拠するには、真の整数として解釈される値は-9007199254740991〜9007199254740991の範囲にある必要があります。ただし、アプリケーションでの数値の使用方法はJCSアルゴリズムに影響しません。
(2) Although a set of specific integers like 2**68 could be regarded as having extended precision, the JCS/ECMAScript number serialization algorithm does not take this into consideration.
（2）2 ** 68のような特定の整数のセットは拡張精度を持つと見なすことができますが、JCS / ECMAScript番号シリアル化アルゴリズムはこれを考慮しません。
(3) Values out of range are not permitted in JSON. See Section 3.2.2.3.
（3）範囲外の値はJSONでは許可されていません。セクション3.2.2.3を参照してください。
(4) This number is exactly 1424953923781206.25 but will, after the "Note 2" rule mentioned in Section 3.2.2.3, be truncated and rounded to the closest even value.
（4）この数値は正確に1424953923781206.25ですが、セクション3.2.2.3で説明されている「注2」のルールの後、切り捨てられ、最も近い偶数値に丸められます。
For a more exhaustive validation of a JCS number serializer, you may test against a file (currently) available in the development portal (see Appendix I) containing a large set of sample values. Another option is running V8 [V8] as a live reference together with a program generating a substantial amount of random IEEE 754 values.
JCS番号シリアライザのより徹底的な検証のために、サンプル値の大規模なセットを含む開発ポータル（付録Iを参照）で（現在）利用可能なファイルに対してテストできます。別のオプションは、相当量のランダムなIEEE 754値を生成するプログラムと共にライブ参照としてV8 [V8]を実行することです。
Appendix C. Canonicalized JSON as "Wire Format"
付録C.「ワイヤー形式」としての正規化されたJSON
Since the result from the canonicalization process (see Section 3.2.4) is fully valid JSON, it can also be used as "Wire Format". However, this is just an option since cryptographic schemes based on JCS, in most cases, would not depend on that externally supplied JSON data already being canonicalized.
正規化プロセス（セクション3.2.4を参照）の結果は完全に有効なJSONであるため、「ワイヤー形式」としても使用できます。ただし、これは単なる選択肢です。JCSに基づく暗号化スキームは、ほとんどの場合、すでに正規化されている外部から提供されたJSONデータに依存しないためです。
In fact, the ECMAScript standard way of serializing objects using "JSON.stringify()" produces a more "logical" format, where properties are kept in the order they were created or received. The example below shows an address record that could benefit from ECMAScript standard serialization:
実際、「JSON.stringify()」を使用してオブジェクトをシリアル化するECMAScriptの標準的な方法では、より「論理的な」形式が生成され、プロパティは作成または受信された順序で保持されます。以下の例は、ECMAScript標準シリアル化の恩恵を受けることができる住所レコードを示しています。
{
"name": "John Doe",
"address": "2000 Sunset Boulevard",
"city": "Los Angeles",
"zip": "90001",
"state": "CA"
}
Using canonicalization, the properties above would be output in the order "address", "city", "name", "state", and "zip", which adds fuzziness to the data from a human (developer or technical support) perspective. Canonicalization also converts JSON data into a single line of text, which may be less than ideal for debugging and logging.
正規化を使用すると、上記のプロパティは「住所」、「市」、「名前」、「州」、「zip」の順に出力され、人間（開発者または技術サポート）の観点からデータにあいまいさが追加されます。正規化では、JSONデータも1行のテキストに変換されます。これは、デバッグやロギングに理想的ではない場合があります。
There are several issues associated with the JSON number type, here illustrated by the following sample object:
JSON番号タイプに関連する問題がいくつかあります。ここでは、次のサンプルオブジェクトで示しています。
{
"giantNumber": 1.4e+9999,
"payMeThis": 26000.33,
"int64Max": 9223372036854775807
}
Although the sample above conforms to JSON [RFC8259], applications would normally use different native data types for storing "giantNumber" and "int64Max". In addition, monetary data like "payMeThis" would presumably not rely on floating-point data types due to rounding issues with respect to decimal arithmetic.
上記のサンプルはJSON [RFC8259]に準拠していますが、アプリケーションは通常、「giantNumber」と「int64Max」の格納に異なるネイティブデータタイプを使用します。さらに、「payMeThis」などの通貨データは、10進数演算に関する丸めの問題のため、おそらく浮動小数点データ型に依存しません。
The established way of handling this kind of "overloading" of the JSON number type (at least in an extensible manner) is through mapping mechanisms, instructing parsers what to do with different properties based on their name. However, this greatly limits the value of using the JSON number type outside of its original, somewhat constrained JavaScript context. The ECMAScript "JSON" object does not support mappings to the JSON number type either.
JSON番号タイプのこのような「オーバーロード」を（少なくとも拡張可能な方法で）処理する確立された方法は、マッピングメカニズムを介して、パーサーに名前に基づいてさまざまなプロパティをどうするかを指示することです。ただし、これにより、JSON数値タイプを元の、多少制約のあるJavaScriptコンテキスト以外で使用する価値が大幅に制限されます。 ECMAScriptの「JSON」オブジェクトは、JSON数値タイプへのマッピングもサポートしていません。
Due to the above, numbers that do not have a natural place in the current JSON ecosystem MUST be wrapped using the JSON string type. This is close to a de facto standard for open systems. This is also applicable for other data types that do not have direct support in JSON, like "DateTime" objects as described in Appendix E.
上記のため、現在のJSONエコシステムで自然な位置にない数値は、JSON文字列タイプを使用してラップする必要があります。これは、オープンシステムの事実上の標準に近いものです。これは、付録Eで説明されている「DateTime」オブジェクトなど、JSONで直接サポートされていない他のデータ型にも適用できます。
Aided by a system using the JSON string type, be it programmatic like
JSON文字列型を使用するシステムによって支援されます。
var obj = JSON.parse('{"giantNumber": "1.4e+9999"}');
var biggie = new BigNumber(obj.giantNumber);
or declarative schemes like OpenAPI [OPENAPI], JCS imposes no limits on applications, including when using ECMAScript.
またはOpenAPI [OPENAPI]のような宣言的スキームでは、JCSはECMAScriptを使用する場合を含め、アプリケーションに制限を課しません。
Due to the limited set of data types featured in JSON, the JSON string type is commonly used for holding subtypes. This can, depending on JSON parsing method, lead to interoperability problems, which MUST be dealt with by JCS-compliant applications targeting a wider audience.
JSONで特徴付けられるデータ型のセットが限られているため、JSON文字列型は一般にサブタイプを保持するために使用されます。これは、JSON解析方法に応じて、相互運用性の問題を引き起こす可能性があります。これは、より広い対象者を対象とするJCS準拠のアプリケーションで処理する必要があります。
Assume you want to parse a JSON object where the schema designer assigned the property "big" for holding a "BigInt" subtype and "time" for holding a "DateTime" subtype, while "val" is supposed to be a JSON number compliant with JCS. The following example shows such an object:
スキーマデザイナが「BigInt」サブタイプを保持するためのプロパティ「big」と「DateTime」サブタイプを保持するための「time」を割り当てたJSONオブジェクトを解析するとします。「val」は、 JCS。次の例は、そのようなオブジェクトを示しています。
{
"time": "2019-01-28T07:45:10Z",
"big": "055",
"val": 3.5
}
Parsing of this object can be accomplished by the following ECMAScript statement:
このオブジェクトの解析は、次のECMAScriptステートメントによって実行できます。
var object = JSON.parse(JSON_object_featured_as_a_string);
After parsing, the actual data can be extracted, which for subtypes, also involves a conversion step using the result of the parsing process (an ECMAScript object) as input:
解析後、実際のデータを抽出できます。サブタイプの場合、解析プロセスの結果（ECMAScriptオブジェクト）を入力として使用する変換ステップも含まれます。
... = new Date(object.time); // Date object
... = BigInt(object.big); // Big integer
... = object.val; // JSON/JS number
Note that the "BigInt" data type is currently only natively supported by V8 [V8].
「BigInt」データ型は現在、V8 [V8]でのみネイティブでサポートされていることに注意してください。
Canonicalization of "object" using the sample code in Appendix A would return the following string:
付録Aのサンプルコードを使用して「オブジェクト」を正規化すると、次の文字列が返されます。
{"big":"055","time":"2019-01-28T07:45:10Z","val":3.5}
Although this is (with respect to JCS) technically correct, there is another way of parsing JSON data, which also can be used with ECMAScript as shown below:
これは（JCSに関して）技術的には正しいですが、JSONデータを解析する別の方法があり、以下に示すようにECMAScriptでも使用できます。
// "BigInt" requires the following code to become JSON serializable
BigInt.prototype.toJSON = function() {
return this.toString();
};
// JSON parsing using a "stream"-based method
var object = JSON.parse(JSON_object_featured_as_a_string,
(k,v) => k == 'time' ? new Date(v) : k == 'big' ? BigInt(v) : v
);
If you now apply the canonicalizer in Appendix A to "object", the following string would be generated:
付録Aの正規化子を「オブジェクト」に適用すると、次の文字列が生成されます。
{"big":"55","time":"2019-01-28T07:45:10.000Z","val":3.5}
In this case, the string arguments for "big" and "time" have changed with respect to the original, presumably making an application depending on JCS fail.
この場合、 "big"と "time"の文字列引数が元の引数に対して変更されているため、おそらくJCSに依存するアプリケーションが失敗します。
The reason for the deviation is that in stream- and schema-based JSON parsers, the original string argument is typically replaced on the fly by the native subtype that, when serialized, may exhibit a different and platform-dependent pattern.
偏差の理由は、ストリームベースおよびスキーマベースのJSONパーサーでは、通常、元の文字列引数は、シリアル化されたときに異なるプラットフォーム依存のパターンを示す可能性があるネイティブサブタイプによってその場で置き換えられるためです。
That is, stream- and schema-based parsing MUST treat subtypes as "pure" (immutable) JSON string types and perform the actual conversion to the designated native type in a subsequent step. In modern programming platforms like Go, Java, and C#, this can be achieved with moderate efforts by combining annotations, getters, and setters. Below is an example in C#/Json.NET showing a part of a class that is serializable as a JSON object:
つまり、ストリームベースおよびスキーマベースの解析では、サブタイプを「純粋な」（不変の）JSON文字列タイプとして扱い、その後のステップで指定されたネイティブタイプへの実際の変換を実行する必要があります。 Go、Java、C＃などの最新のプログラミングプラットフォームでは、アノテーション、ゲッター、セッターを組み合わせることにより、適度な労力でこれを実現できます。以下は、JSONオブジェクトとしてシリアル化可能なクラスの一部を示すC＃/ Json.NETの例です。
// The "pure" string solution uses a local
// string variable for JSON serialization while
// exposing another type to the application
[JsonProperty("amount")]
private string _amount;
[JsonIgnore]
public decimal Amount {
get { return decimal.Parse(_amount); }
set { _amount = value.ToString(); }
}
In an application, "Amount" can be accessed as any other property while it is actually represented by a quoted string in JSON contexts.
アプリケーションでは、「金額」は他のプロパティとしてアクセスできますが、実際にはJSONコンテキストで引用符付きの文字列で表されます。
Note: The example above also addresses the constraints on numeric data implied by I-JSON (the C# "decimal" data type has quite different characteristics compared to IEEE 754 double precision).
注：上記の例は、I-JSONによって暗示される数値データの制約にも対処しています（C＃の「10進数」データ型は、IEEE 754倍精度と比較してまったく異なる特性を持っています）。
Since the JSON array construct permits mixing arbitrary JSON data types, custom parsing and serialization code may be required to cope with subtypes anyway.
JSON配列構成では任意のJSONデータ型を混在させることができるため、いずれにしてもサブタイプを処理するにはカスタムの解析およびシリアル化コードが必要になる場合があります。
The optimal solution is integrating support for JCS directly in JSON serializers (parsers need no changes). That is, canonicalization would just be an additional "mode" for a JSON serializer. However, this is currently not the case. Fortunately, JCS support can be introduced through externally supplied canonicalizer software acting as a post processor to existing JSON serializers. This arrangement also relieves the JCS implementer from having to deal with how underlying data is to be represented in JSON.
最適なソリューションは、JCSのサポートをJSONシリアライザーに直接統合することです（パーサーは変更を必要としません）。つまり、正規化は、JSONシリアライザーの追加の「モード」にすぎません。ただし、現在のところそうではありません。さいわい、JCSサポートは、既存のJSONシリアライザーのポストプロセッサとして機能する外部から提供された正規化ソフトウェアを通じて導入できます。また、この配置により、JCS実装者は、基礎となるデータをJSONで表現する方法を処理する必要がなくなります。
The post processor concept enables signature creation schemes like the following:
ポストプロセッサの概念により、次のような署名作成スキームが可能になります。
1. Create the data to be signed.
1. 署名するデータを作成します。
2. Serialize the data using existing JSON tools.
2. 既存のJSONツールを使用してデータをシリアル化します。
3. Let the external canonicalizer process the serialized data and return canonicalized result data.
3. 外部正規化プログラムにシリアル化されたデータを処理させ、正規化された結果データを返します。
4. Sign the canonicalized data.
4. 正規化されたデータに署名します。
5. Add the resulting signature value to the original JSON data through a designated signature property.
5. 指定された署名プロパティを通じて、結果の署名値を元のJSONデータに追加します。
6. Serialize the completed (now signed) JSON object using existing JSON tools.
6. 既存のJSONツールを使用して、完成した（署名された）JSONオブジェクトをシリアル化します。
A compatible signature verification scheme would then be as follows:
互換性のある署名検証スキームは次のようになります。
1. Parse the signed JSON data using existing JSON tools.
1. 既存のJSONツールを使用して、署名されたJSONデータを解析します。
2. Read and save the signature value from the designated signature property.
2. 指定された署名プロパティから署名値を読み取って保存します。
3. Remove the signature property from the parsed JSON object.
3. 解析されたJSONオブジェクトから署名プロパティを削除します。
4. Serialize the remaining JSON data using existing JSON tools.
4. 既存のJSONツールを使用して残りのJSONデータをシリアル化します。
5. Let the external canonicalizer process the serialized data and return canonicalized result data.
5. 外部正規化プログラムにシリアル化されたデータを処理させ、正規化された結果データを返します。
6. Verify that the canonicalized data matches the saved signature value using the algorithm and key used for creating the signature.
6. 正規化されたデータが、署名の作成に使用されたアルゴリズムとキーを使用して、保存された署名の値と一致することを確認します。
A canonicalizer like above is effectively only a "filter", potentially usable with a multitude of quite different cryptographic schemes.
上記のような正規化子は、事実上「フィルター」にすぎず、多数のまったく異なる暗号化スキームで潜在的に使用できます。
Using a JSON serializer with integrated JCS support, the serialization performed before the canonicalization step could be eliminated for both processes.
統合されたJCSサポートを備えたJSONシリアライザーを使用すると、正規化手順の前に実行されたシリアライゼーションを両方のプロセスで排除できます。
Appendix G. Open-Source Implementations
付録G.オープンソース実装
The following open-source implementations have been verified to be compatible with JCS:
次のオープンソース実装は、JCSと互換性があることが確認されています。
* JavaScript: <https://www.npmjs.com/package/canonicalize>
* JavaScript：<https://www.npmjs.com/package/canonicalize>
* Java: <https://github.com/erdtman/java-json-canonicalization>
* Java：<https://github.com/erdtman/java-json-canonicalization>
* Go: <https://github.com/cyberphone/json-canonicalization/tree/master/go>
* ご： ＜ｈっｔｐｓ：／／ぎてゅｂ。こｍ／ｃｙべｒｐほね／ｊそんーかのにかぃざちおん／ｔれえ／まｓてｒ／ご＞
* .NET/C#: <https://github.com/cyberphone/json-
canonicalization/tree/master/dotnet>
* Python: <https://github.com/cyberphone/json-canonicalization/tree/master/python3>
* Python：<https://github.com/cyberphone/json-canonicalization/tree/master/python3>
Appendix H. Other JSON Canonicalization Efforts
付録H.その他のJSON正規化の取り組み
There are (and have been) other efforts creating "Canonical JSON". Below is a list of URLs to some of them:
「Canonical JSON」を作成する他の取り組みがあります（されています）。以下はそれらのいくつかへのURLのリストです。
* <https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-
00>
* <https://gibson042.github.io/canonicaljson-spec/>
* <http://wiki.laptop.org/go/Canonical_JSON>
The listed efforts all build on text-level JSON-to-JSON transformations. The primary feature of text-level canonicalization is that it can be made neutral to the flavor of JSON used. However, such schemes also imply major changes to the JSON parsing process, which is a likely hurdle for adoption. Albeit at the expense of certain JSON and application constraints, JCS was designed to be compatible with existing JSON tools.
リストされている取り組みはすべて、テキストレベルのJSONからJSONへの変換に基づいています。テキストレベルの正規化の主な機能は、使用するJSONのフレーバーに中立にすることができることです。ただし、このようなスキームは、JSON解析プロセスへの大きな変更も意味します。これは、採用のハードルになる可能性があります。特定のJSONおよびアプリケーションの制約を犠牲にしても、JCSは既存のJSONツールと互換性があるように設計されています。
Appendix I. Development Portal
付録I.開発ポータル
The JCS specification is currently developed at: <https://github.com/cyberphone/ietf-json-canon>.
JCS仕様は現在<https://github.com/cyberphone/ietf-json-canon>で開発されています。
JCS source code and extensive test data is available at: <https://github.com/cyberphone/json-canonicalization>.
JCSソースコードと広範なテストデータは、<https://github.com/cyberphone/json-canonicalization>で入手できます。
Acknowledgements
謝辞
Building on ECMAScript number serialization was originally proposed by James Manger. This ultimately led to the adoption of the entire ECMAScript serialization scheme for JSON primitives.
ECMAScript番号のシリアル化に基づくことは、もともとJames Mangerによって提案されました。これにより、最終的には、JSONプリミティブにECMAScriptシリアル化スキーム全体が採用されました。
Other people who have contributed with valuable input to this specification include Scott Ananian, Tim Bray, Ben Campbell, Adrian Farell, Richard Gibson, Bron Gondwana, John-Mark Gurney, Mike Jones, John Levine, Mark Miller, Matthew Miller, Mark Nottingham, Mike Samuel, Jim Schaad, Robert Tupelo-Schneck, and Michal Wadas.
この仕様に貴重な情報を提供してくれた他の人々には、スコットアナニアン、ティムブレイ、ベンキャンベル、エイドリアンファレル、リチャードギブソン、ブロンゴンドワナ、ジョンマークガーニー、マイクジョーンズ、ジョンレバイン、マークミラー、マシューミラー、マークノッティンガム、 Mike Samuel、Jim Schaad、Robert Tupelo-Schneck、Michal Wadas。
For carrying out real-world concept verification, the software and support for number serialization provided by Ulf Adams, Tanner Gooding, and Remy Oudompheng was very helpful.
現実世界の概念検証を実行するために、Ulf Adams、Tanner Gooding、およびRemy Oudomphengによって提供されるソフトウェアと番号シリアル化のサポートが非常に役立ちました。
Authors' Addresses
著者のアドレス
Anders Rundgren Independent Montpellier France
アンデルスラングレンインディペンデントモンペリエフランス
Email: anders.rundgren.net@gmail.com
URI: https://www.linkedin.com/in/andersrundgren/
Bret Jordan Broadcom 1320 Ridder Park Drive San Jose, CA 95131 United States of America
ブレットジョーダンBroadcom 1320 Ridder Park Driveサンノゼ、CA 95131アメリカ合衆国
Email: bret.jordan@broadcom.com
Samuel Erdtman Spotify AB Birger Jarlsgatan 61, 4tr SE-113 56 Stockholm Sweden
Samuel Erdtman Spotify AB Birger Jarlsgatan 61、4tr SE-113 56ストックホルムスウェーデン
Email: erdtman@spotify.com