要約

  • JMAP Enhanced Result References は、先行メソッドの応答から選んだ値を、後続のオブジェクト属性、パッチ、検索条件へ渡せるようにする。
  • 参照結果をキャッシュするなら、応答と式だけでなく、主体、アカウント、アクセス制御の時点、宛先コンテキストを束縛しなければならない。キャッシュヒットは再利用の権限を証明しない。

最初の要求が処理された時点で、利用者は非公開ワークスペースの正規メンバーだった。先行する JMAP メソッドの応答から JSON Path が識別子を一つ選び、後続メソッドがその値を使った。サーバーは結果をキャッシュした。

その後、管理者がメンバーシップを取り消した。元の応答データも、式も、選択される文字列も変わらない。次の要求でキャッシュキーが同じになり、値は瞬時に返された。構造上は正しい。だが、以前の可視性を前提に作られた値が、新しい権限状態を飛び越えた。

この障害を「古いデータ」とだけ呼ぶのは不十分だ。値そのものは最新であり得る。古かったのは、その値を選択して再利用してよいという根拠だった。

JMAP Enhanced Result References の第 02 版は 2026 年 6 月 21 日付で、12 月 23 日に失効する。調査時点では JMAP ワーキンググループの Standards Track 向け Internet-Draft であり、最終 RFC、実装証明、普及率調査ではない。

草案は RFC 8620 の結果参照を拡張する。JMAP 要求内でメソッドは順番に実行され、後続呼び出しは resultOf、name、path を使って先行応答のデータを選べる。拡張により、その参照を /set の属性、PatchObject の値、/query の FilterCondition で利用できる。JSON Pointer に加え、能力が広告されていれば JSON Path も選べる。

これは要求内のデータフローを簡潔にする仕組みである。時間を越えて権限を保存する仕組みではない。

キャッシュキーに足りないもの

技術者はキャッシュ可能性を、入力と出力の決定性から判断しがちだ。同じ応答本文に同じ式を適用すれば、同じノードリストが得られる。この範囲では正しい。

しかし、参照値を後続操作に使ってよいかは、JSON の外側にある事実にも依存する。誰が要求したのか。どのアカウントか。元データを読む権限は現在もあるか。宛先の公開範囲は何か。その値を別コンテキストへ移す権限があるか。

草案は、キャッシュを利用者やセキュリティコンテキストの間で共有してはならず、アクセス制御が変化した場合に無効化すべきだとする。実務上のキーには、主体、アカウント、関連する ACL またはポリシーのエポックを含める必要がある。高い影響を持つ用途では、宛先コンテキストも必要になる。

同じ値が内部計算には使えても、公開オブジェクトへのコピーには使えないことがあるからだ。読み取り権限と書き込み権限を別々に持つことは、両者を接続する移送権限を自動的には作らない。

監査記録は、新規評価とキャッシュ再利用を区別しなければならない。後者なら、どのセキュリティ時点に結び付いており、なぜ現在も有効と判断したのかを残す。cache hit は性能の説明であって、許可の説明ではない。

選択の成功は出所の完全証明ではない

結果参照は先行呼び出しを resultOf で示し、メソッド名とパスを指定する。この情報は実行時のリネージとして重要だ。どの応答のどこから値が来たかを再構成できる。

ただし、そのリネージを「業務上の真正な出所」と読み替えてはならない。先行応答が返した事実は分かるが、その応答を生んだ元情報の正しさ、鮮度、法的権限までは分からない。識別子がどのノードに存在したかは、その識別子が後続判断を支配すべき理由にはならない。

必要な証拠は二方向に伸びる。上流には、主体、アカウント、応答、可視性、選択式がある。下流には、宛先属性またはフィルター、期待型、対象読者、認可判断、最終効果がある。値だけを保存すると、この接続が失われる。

Heng Lu の薄いレイヤーという考え方は、ここで有効である。調整層は限定された問題を正確に解き、その境界を維持することで信頼を得る。参照解決は JSON を運ぶ。だからといって、人や組織の委任を獲得するわけではない。

空の結果は安全な既定値ではない

JSON Path はゼロ、一つ、複数のノードを返せる。草案は、宛先型に応じてノードリストを値へ変換する。プリミティブまたは単一オブジェクトなら、一つはその値、ゼロは null、複数は invalidResultReference になる。配列ならゼロは []、一つ以上は RFC 9535 の順序による配列になる。マップならゼロは {}、一つの適合オブジェクトだけが受け入れられる。

この規則はサーバー間の挙動を揃える。空の意味までは揃えない。

ある属性で null は「値を消去せよ」を意味し、別の場所では単なる欠落を表す。空配列は「候補なし」かもしれないし、「全メンバーを削除せよ」かもしれない。空マップは上書きなしにも、全設定の置換にもなり得る。

JSON Pointer では、ワイルドカードを含まない正確なパスが存在しなければエラーになる一方、ワイルドカードのゼロ一致は型付きの空へ解決され得る。エラーを減らす目的で式を広げると、欠落が状態変更へ変わる可能性がある。

重要な宛先は、ゼロ一致を拒否するか、既存値を保つか、明示的に消すかを宣言すべきだ。共通リゾルバーに決めさせると、構造規則が業務ポリシーを代行してしまう。

型検証は意味検証の代わりではない

解決後、サーバーは宛先型を検証する。/set の属性で不適合なら invalidProperties、/query の条件なら invalidArguments になる。文字列を数値や真偽値へ暗黙変換したり、複雑なオブジェクトを文字列化したりして通過させてはならない。

拒否は大切な証拠を保存する。文字列 "01" がコードなのに数値 1 へ変換されれば、別の概念になり得る。不適合は、上流と下流の契約が一致していないことを示す。自動変換は、その不一致を見えなくする。

それでも、正しい JSON 型は意味を保証しない。メールボックス ID は正しい文字列でも別アカウントに属し得る。添付ファイル ID は正しい形式でも、後続オブジェクトの読者に開示できない内容を指し得る。

したがって、型、ドメイン、認可を別々に確認する必要がある。型は形状を、ドメインは所属を、認可はこの主体がこの宛先で使う権利を示す。一つの成功表示に統合すると、どの問いが未回答か分からなくなる。

中間層は意味を知らなくてよい

草案は、構文的な中間層が不透明な JSON に JSON Pointer または JSON Path を適用できる構成を示す。メソッド型や属性の意味を知らずに選択し、実行層が後で宛先型を解釈する。

これは良い責任分離である。ゲートウェイが全 JMAP データモデルを実装せず、共通の解決機能を提供できる。だが、その層が発行できる証明は狭い。式が何件を選び、どの形になったかは言える。なぜその値が後続判断に適切かは言えない。

監査も層をまたいで構成する必要がある。元呼び出し、式、ノード数、解決型、宛先、型検証、認可結果をつなぐ。最終オブジェクトだけでは、「値がある」ことは分かっても「値が影響力を得た理由」は分からない。

能力広告 urn:ietf:params:jmap:refplus も同じ境界を持つ。サーバーが拡張を理解し、アカウント能力が JSON Path 対応を示すことは、技術的利用可能性の証明である。任意のデータを任意の文脈へ動かす委任ではない。

表現力には資源上限が要る

JSON Pointer は正確な構造経路をたどる。JSON Path はフィルター、ワイルドカード、再帰下降を使える。大きな応答に対する複雑な式は、巨大なノードリストと高い計算負荷を生む。

順次実行は単純な直接循環を防ぐが、深い参照や大きなオブジェクトの反復コピーまでは防がない。サーバーは式の複雑度、評価時間、ノード数、参照総数、ネスト深度、累積コストを制限すべきである。

上限を超えたら明示的に拒否し、黙って切り詰めてはならない。切り詰めは選択結果を変えながら成功を装う。特に単一値の宛先では、本来複数だった候補を一つに見せかねない。

JSON Path パーサーもセキュリティ依存関係である。保守、パッチ、隔離、悪意ある式への試験が要る。評価時間の異常や invalidResultReference の増加は、攻撃だけでなく、上流応答の肥大化やクライアント式の劣化を示す場合がある。

時間を含む証拠にする

参照成功は、先行応答を特定し式を評価したことを示す。カーディナリティ規則は、ノード集合が値へ変換された方法を示す。型検証は、宣言された JSON 契約への適合を示す。

どれも単独では、鮮度、業務上の出所、宛先への移送権限を証明しない。特にキャッシュは、正しい値と失効した資格を組み合わせられる。証拠には値だけでなく、判断時点が必要である。

実装試験では、権限変更前後のキャッシュ、利用者間の分離、ゼロ・一つ・複数一致、正確なポインター欠落と空ワイルドカード、異なるアカウントの同型 ID、資源上限を確認すべきだ。さらに、最終書き込みから元の応答と認可時点を逆算できるかを試す。

キャッシュされた識別子は嘘をつかなかった。システムが忘れたのは、その識別子を使ってよいという判断には期限があることだ。拡張結果参照を安全に使う鍵は、値の再利用と権限の再利用を同じものと考えないことである。

出典