要約

  • RFC 8259はオブジェクト名を一意にすべきだとする一方、重複時には最後だけを返す実装、エラーにする実装、全件を返す実装があると明記する。
  • パーサーが重複を一つのマップへ潰した後では、スキーマ検証、ログ、正規化を重ねても捨てられたメンバーは復元できない。
  • 受信時の証拠を保ち、エスケープ処理後の名前で衝突を検出し、意味を使う前に拒否することが、説明可能な境界となる。

文字列からマップへ移るときに何かが消える

通信路を通るJSONオブジェクトは、名前と値が並んだ文字列である。アプリケーションが欲しいのは通常、一つの名前から一つの値を引けるマップだ。名前が一意なら両者の差は表面化しない。同じ名前が二度あれば、変換には必ず衝突規則が要る。

しかも、その規則を業務コードが選ぶとは限らない。Webサーバーやミドルウェアが先に本文をオブジェクト化し、ゲートウェイが権限を読み、サービスが処理し、監査機能が受け取ったマップを書き戻す。各パーサーの規則が違えば、全工程が正常終了しても、それぞれが見た主張の集合は異なる。

「パースできた」という記録は、一義的だったことの証明ではない。ある実装がある結果を作れたというだけである。

RFC 8259のSHOULDをMUSTに読み替えない

RFC 8259は、オブジェクト内の名前を一意に SHOULD と定める。基礎文法の絶対的な禁止として MUST を置いてはいない。このため重複名を含むテキストがJSON構文として受理される場合がある。

しかし相互運用性についての警告は強い。名前が一意なら受信実装は名前と値の対応で合意できる。重複すると挙動は予測不能になり、多くは最後の組だけを報告し、別の実装はエラーまたは解析失敗とし、さらに別の実装は重複を含むすべての組を返す。メンバー順を呼び出し側へ見せるかどうかもライブラリごとに異なる。

前段が最初の値で許可し、後段が最後の値で実行し、ログが一つへ縮んだ結果だけを残せば、記録は整っていても判断経路を再現できない。これは特殊な攻撃を仮定しなくても成立する。構成要素が同じデータモデルを共有していないからだ。

I-JSONは受け入れ条件を狭める

RFC 7493のI-JSONでは、オブジェクトに重複名のメンバーがあってはならない。ここで同名かどうかは、エスケープされた文字を処理した後のUnicode文字列で判断する。生の表記が異なって見えても、デコード後に同じ名前になることがある。

したがって、本文の字面だけを探す前置フィルターでは不十分だ。すべてのデコード済み名称を観測しつつ、通常のマップが先に重複を消さない経路が必要になる。I-JSONに従わないメッセージを受信側が拒否または無視でき、セキュリティプロトコルが信頼しないよう要求できる点も重要だ。

検査の位置を誤ると規則は名目だけになる。「最後を残す」処理済みマップを検査しても、そこに重複は残っていない。重複を通知できるパーサーモード、またはマップ構築前に全メンバーを見るトークン層で拒否しなければならない。

最初のパーサーが無言の決裁者になる

明示的な契約がなければ、ライブラリの既定値が価格、宛先、権限、保存内容のどれを後段へ渡すか決める。便利なデータ構造を提供するだけだったはずの部品が、事実上のポリシー決裁者になる。

堅牢な入口はこの責任を表に出す。本文サイズと深さを制限し、名前を一貫してデコードし、エスケープ処理後の衝突を検知し、業務上の副作用より前に止める。さらにプライバシーと保持方針に合わせ、受信オクテットまたはその暗号学的ダイジェストをアプリケーションオブジェクトとは別に残す。

処理済みマップの再シリアライズは代替証拠にならない。それが語るのはパーサーが何を残したかであって、何が届いたかの全体ではない。

JWSの規則はヘッダーに境界を持つ

RFC 7515では、JOSE Header Parameterの名前を一意にしなければならない。JWSパーサーは重複を拒否するか、辞書順で最後の重複メンバーだけを返すJSONパーサーを使う必要がある。

これは対象が明示されたプロトコル規則であり、「JSONは常に最後勝ち」という一般原則ではない。JOSEヘッダーパラメーターに対する規則を、任意のAPI本文、設定ファイル、JWSペイロードへ自動的に広げてはならない。また署名の検証は、保護されたバイト列と鍵の暗号学的関係を確認する。表された操作を許可すべきかまでは決めない。

限定的な互換動作も、ゲートウェイ、検証器、サービス、監視系が同じ境界で同じ規則を使って初めて成立する。一部だけが異なる解釈をすれば、仕様があっても事実は分裂する。

正規化は失われた入力を取り戻さない

RFC 8785のJCSは、JSONを決定的な表現にする方式である。前提としてI-JSONへ適合させ、オブジェクトに重複プロパティ名を認めず、プリミティブを定義どおりにシリアライズし、プロパティを決定的に並べる。

順番が核心だ。曖昧な入力を正規化が解決するのではなく、曖昧さのないデータモデルが先に必要になる。一般パーサーが一つのメンバーを捨てた後でJCSを適用すれば、結果は決定的になり得る。ただし決定的なのはパーサーの投影であり、原文に重複がなかったことは証明せず、消えた値も戻さない。

署名用途についてJCSは、JSONを解析してI-JSON適合を確認し、利用環境固有の規則を検証し、その後に署名を確認する手順を示す。どこかで失敗すれば処理を中止する。構文上の受理、意味上の妥当性、暗号学的真正性は別の判断である。

単体テストではなく経路を試す

設計書では、受信オクテット、デコード済みトークン列、重複がなく受理されたオブジェクト、検証済みドメインモデル、必要に応じた正規形または署名包という状態を区別すべきだ。各遷移に責任者、失敗時の動作、証拠の扱いを割り当てる。

試験データには複数のネスト位置で重複を入れ、エスケープ解決後だけ衝突する名前も含める。実際のゲートウェイ、ミドルウェア、署名経路、ログ経路を通す。期待結果はエラー応答だけではない。副作用がなく、拒否理由が分類され、保持したダイジェストが元本文に対応することまで確認する。

パーサー、ランタイム、ゲートウェイ、シリアライザーの更新でも同じ適合データを再実行する。業務スキーマが不変でも、衝突時の意味論は変わり得る。

出典