Q1: 通常のJSON serializationだけでは、共通のsignature inputとして不十分な理由はどれ？
単一選択**解説:**
A: 同じparsed dataでも、これらの正しい表記差によって異なるbyte列になりうる。
B: RFC 8259はstringとnumberを定義する.
C: parseとcryptographic verificationは別の処理である。
参照仕様
Q2: JCS implementationがcanonicalizeする前に拒否すべきinputはどれ？
単一選択**解説:**
A: canonicalizationがpropertyをsortするため、inputの順序はcanonicalでなくてよい。
B: JCSのinput objectは、重複したproperty名を含んではならない。
C: arrayはobjectを含められ、そのobjectも再帰的に処理される。
Q3: JCS outputではJSON token間のwhitespaceをどうする？
単一選択**解説:**
A: JCSはseparator spaceを出力しない。
B: JCSはparsed dataを処理し、sourceのformattingを保持しない。
C: RFC 8785はJSON token間にwhitespaceを出力しないよう要求する。
Q4: JCSはJSON objectのpropertyをどのように並べる？
単一選択**解説:**
A: JCSはunsigned UTF-16 code-unit比較を使い、すべてのchild objectをsortする。
B: locale固有の照合やescape表記では、仕様どおりの共通順序にならない。
C: insertion orderはJCSのsorting ruleで置き換えられる。
Q5: JCSはarray elementの順序をどう扱う？
単一選択**解説:**
A: elementの順序を変えると、JSON data modelそのものが変わる。
B: array内も再帰的に処理するが、elementの位置は変えない。
C: JCSは順序が固定されたarrayを扱える。
Q6: JCS implementationは署名前にstringへUnicode normalizationを適用してよい？
単一選択**解説:**
A: RFC 8785は意図的にUnicode normalizationを適用しない。
B: 見た目が同じことは、parsed string dataを変更する規則にはならない。
C: string dataを変えるとcanonicalize対象のvalueが変わり、signatureを壊しうる。
Q7: JCSはJSON numberをどのようにserializeする？
単一選択**解説:**
A: JCSはECMAScriptのserialization algorithmでnumber表記を固定する。
B: JCSはparsed numeric valueをcanonicalizeし、sourceの表記は保持しない。
C: applicationは大きなnumberをstringで表現できるが、JCSがJSON typeを勝手に変えることはない。
Q8: parsed valueにlone surrogateまたはInfinityがある。適合するJCS implementationはどうする？
単一選択**解説:**
A: 黙って置き換えるとdataが変わり、signatureの動作が曖昧になる。
B: RFC 8785はinvalid UnicodeとJSON外のnumeric valueに対してerrorを要求する。
C: JCSはnullへのlossy conversionを定義しない。
Q9: parser差分を防ぐvalidation boundaryはどれ？
単一選択署名付きAgent CardのJSONにendpoint propertyが二つある。signature componentはparse時に最初の値を残し、request routerは後の値を残す。teamは両componentで別々にJCSを適用する案を出した。
**解説:**
RFC 8785 Section 3.1は、JCS入力objectに重複property nameがあってはならないと定める。canonicalizationは制約済みのparsed dataを対象とし、最初の値と最後の値という競合解釈を同一にはできない。Cはsignature検証とroutingが分岐する前に曖昧さを除く。AとBはJCSに不適合な入力を受け入れ、Dはsignature inputの構築にparse済みdataが必要なJCSでは成立しない。
Q10: 有効なsignatureはissuerが意図したamountを保持している？
単一選択A2A payment grantがamount=9007199254740993をJSON numberで表す。issuer実装はIEEE 754 doubleとしてparseし、丸められた値へJCSを適用して署名する。verifierも同じJCS byteを再現するのでsignatureは有効だが、business layerは別に保持した入力bufferの元decimalを表示する。
**解説:**
RFC 8785 Section 3.1はJCSのnumber dataをIEEE 754 double precisionで表現可能な値に制限し、より高精度の値にはstringを推奨する。Appendix Dはその扱いを説明している。JCSが署名するのはparse後の値であり、先に失われた精度を戻したり、署名されていない別bufferをbindしたりはしない。Bは二つの境界を修正する。Dは強すぎる断定で、許容範囲のJSON numberは利用できる。