要約

  • 2026年9月28日付の個人提出Internet-Draft「CAID」第-04版は、新旧両版が受理する行為オブジェクトについて、スイート、要約値、正規形を変えないと説明する。
  • 一方で、-03版では有効なCAIDを持てた一部の入力を新たに拒む。照合用の文字列だけでは、過去の判定を現在の規則で読み替える根拠にならない。

行為IDを長期の結合キーにする構想は魅力的だ。承認の記録と実行の記録が異なる製品で作られても、同じ対象を指すか比較しやすくなる。ただし、数年後に古い記録を再検証する場面を想像してほしい。保存してあるIDは昨日と同じなのに、新しい検証器は元の行為オブジェクトを拒否する。ここで「IDが一致したから問題なし」と言うのも、「昔の判断は誤りだった」と言うのも早計だ。変わったのがバイト列ではなく受理規則なら、両方の判定をそれぞれの時点のものとして扱わなければならない。

Iman Schrockが提案するCanonical Action Identifier（CAID）は、認可、委任、実行、監査の証跡で表現が異なる行為を比較するため、型付きの行為オブジェクト、正規化とダイジェストの組み合わせ、短い識別子、重要なフィールドを指定する型定義を設ける。今回の-04版は9月26日付の-03版から二日後に出た。IETF Datatrackerは個人のInternet-Draftであり、標準化過程における正式な立場を持たないと明記する。表紙にある意図された位置づけと、実際の採択やRFC化は別だ。既存システムの障害が起きたという資料でもない。

第14節は、今回の変更を実質的な処理モデルの改訂と位置づける。そのうえで、両版が受理するオブジェクトのスイート、ダイジェスト、正規形は変えないという限定を付ける。「共通して受理するもの」の限定を外して読めば、誤った互換性の約束になる。第14.1節は、旧版が受理したか扱いを定めなかった入力を列挙し、特に一部の行為オブジェクトには旧版で有効なCAIDがあったと説明する。深さ64階層を超えるオブジェクト、正規化後の符号化が16,777,216オクテットを超えるもの、Unicodeの非文字を含む文字列、小文字のtやzを使う時刻などが具体例だ。旧版のIDがすべて失効するわけではない。境界が狭まったという事実こそ重要である。

型名が同じでも、検証する内容まで同じとは限らない。-04版は型定義の検証上の意味に対応するdefinition_sha256を導入し、期待する定義の値と違えばdefinition_mismatchを報告できるようにした。提案者の参照レジストリは第5版になり、第4版のファイルをそのまま履歴として残す。これは過去の判定を再現するときに参照すべき版を指し示す工夫だが、IANAに申請する各レジストリが既に設置されたという意味ではない。参照資料と公的な標準化結果を取り違えてはならない。

入力の読取りにも差がある。改訂版は厳格なJSONテキストの条件、拒否理由の順番、適合しない定義の処理を明示した。エスケープを解いた結果同じ名前になるJSONメンバーも、重複として拒否される。ただし、このニュースを重複キーだけの話に縮めるべきではない。識別子を使う組織にとっての問題は、ある版が「比較できる」とした対象が、次の版でも比較の土台に乗るとは限らないことだ。後段のハッシュをどれほど厳密に扱っても、入口の適格性が異なれば「同じ行為」の主張の射程が変わる。

CAIDは行為を命名しても、実行権限を授けない。草案自身が、本人確認、権限、認可、実際の実行、安全性、法的な依拠を識別子の効力から除外している。マッピング用プロファイルの比較結果にも「条件付きで同等」「異なる」「判定不能」があり、判定不能を便宜的に同等扱いできない。これらの境界を踏まえても、今回の改訂が示す固有の課題はもっと手前にある。まず、比較する当事者が同じ検証版と同じ型定義を使ったかを証明できるか、という課題だ。

そこでDaniel Kadeが提案するのは、将来の実装で検証結果を版付きの記録として残すことだ。元のオブジェクトか検証可能な参照、CAIDとスイート、解析器と実装の版、型定義のダイジェストまたは固定したレジストリの写し、受理・拒否の理由、移行時の判断者を結び付ける。草案がこの名前の通信項目を義務づけているわけではない。IDだけを保存して定義を失うと、後から起きる不一致の原因を見分ける材料がなくなるための運用上の提案である。

出典