要約

  • 10月28日付の個人Internet-Draftは、主張、発行者の結論、根拠資料のダイジェスト、使った規則を一つの「verdict record」に収める案を示す。
  • 調べる側は自分の方針と信頼の起点を使う。結果は released、held、refused などと手順別に伝え、記録全体を「verified」と呼ぶ表示を避ける。

判を押す手は誰のものか

発行者が証拠一覧を添えて「合格」と書く。受け手が見たいのは、その文字の美しさではない。挙げられた資料を全部持っているか、指紋は一致するか、同じ規則をもう一度動かすと同じ答えになるか。Darren Wrightの新提案は、この確認を発行者の報告から切り離す。文書はExperimentalを意図した個人草案の段階にある。

記録の中身は厳格なJSONだ。項目の順序や数値、深さに決まりを置き、正確なバイト列のSHA-256で証拠を指す。writer は発行者、body は主張と計算に使う値、check は規則と結果を示す。改訂版は前版のダイジェストを挙げられる。一方、署名、鍵と発行者の結び付き、記録が存在した時刻の上限は外側の容器で確かめる。SCITTの署名声明と受領証はその一例だ。JSONの整列だけで発行者の身元は決まらない。

中心にあるのは入力の独立だ。確認を通す材料は、発行者が自由に作り直せる主張だけであってはならない。受け手は自分が持つバイト列から指紋を計算し、署名を確かめ、規則を再実行する。どの証拠形式を受け入れ、どの鍵を信頼するかも受け手の方針で決める。発行者が「確かめた」と書いた事実は残せるが、それで受け手の作業が完了したことにはならない。

資料が欠けたときの扱いも具体的だ。引用された一件を受け手が持たなければ、その段階は NOT RUN。持っていても形式を検証できなければ同じだ。機械的な規則を再実行して答えが違えば失敗になる。人の判断に当たる judgement は、受け手自身の方針が許す種類に限られる。資料を渡す側が不都合な一件を隠しても、欠落は空白のまま残り、合格票には変わらない。

報告の語彙は四つに分かれる。すべての段階が通れば released。失敗があれば refused。失敗はなくても必要な入力が足りなければ held。調べる側の方針そのものが無効なら no verdict。どの段階で何が起きたかに加え、時刻上限と方針・信頼の起点のダイジェストも載せる。草案は記録全体に「verified」「valid」「true」「trusted」「correct」「proven」「confirmed」「OK」といった札を付けることまで禁じる。画面の一語が、発行者の発言を世界の事実に変えてしまうからだ。

released が示すのは、発行者がその時刻までに、指定の証拠と規則の下でその結果を述べたという履歴だ。主張そのものの真偽は別の調査に残る。確認可能な書類と、正しい結論を同じ棚に置かない設計である。

出典：Wright草案、Datatrackerの状態、RFC 9943、RFC 8259。