要約

  • /.well-known/knowledge-linkset は知識成果物の発見、ダイジェスト照合、廃止ノードから後継への案内を整えられるが、後継先に旧主体の信頼や権限を自動付与するものではない。
  • クライアントは旧ノードの終了を保存し、後継関係を一つの主張として記録した上で、新しい配信元・鍵・ライセンス・行動権限を最初から評価すべきだ。

古いノードは正しく墓標を返し、新しい場所を一つ示していた。利用者にとっては親切な移転案内だった。しかし移転先は別会社が運営し、署名鍵も利用条件も変わっていた。クライアントが後継リンクを同一主体の継続とみなした瞬間、過去に与えた信頼は審査なしで別の管理者へ渡った。

この問題を具体化するのが、Paul Besleaga が2026年9月30日に提出した The 'knowledge-linkset' Well-Known URI for Publishing Knowledge Artefacts の00版である。提案は、オリジンが /.well-known/knowledge-linkset に JSON の発見文書を置き、コンテキスト、グラフ、オントロジー、スキル、現在状態、台帳、サーフェス、協力窓口、ピアなどへの型付きリンクを公開できるようにする。

現時点では IETF の合意済み標準ではない。個人提出の現行ドラフトで、想定ステータスは Informational。担当ワーキンググループや責任 AD、テレチャット予定はなく、well-known 名の申請は暫定、プロファイル URI の登録は別手続きである。したがって評価すべきなのは提案の機能と境界であり、IETF のページにあることを内容への承認と取り違えてはならない。

発見の継続と主体の継続

RFC 8615 はオリジン配下に予測可能な well-known URI を設ける。RFC 8288 と RFC 9264 はリンク関係と linkset の表現を与える。これらを利用すれば、クライアントは各サイト固有の入口を推測せず、オリジンが提示する知識地図から探索を始められる。

地図に寿命があるのは当然だ。プロジェクトが終了し、組織が統合され、ドメインが移管される。墓標は「以前の識別子は終わった」という重要な事実を残し、後継リンクは利用者に新しい候補を示す。ここで保存すべきなのは二つの異なる事実である。旧ノードが終了を表明したこと。そして旧ノードがある別ノードを後継だと主張したことだ。

後者は、暗黙の同一性証明ではない。新ノードは運営者、法域、編集方針、ライセンス、署名鍵、データ保持、可用性保証を変え得る。旧ノードに対して許可した読み取りや自動処理を、そのまま新ノードへ適用すべきではない。クライアントは旧識別子と終了時刻を保持し、後継先を新規オリジンとして発見し直し、信頼ポリシーを再評価する必要がある。

HTTP のリダイレクトだけで移転を処理すると、主体変化が見えなくなることがある。最終 URL だけでなく、開始 URL、全リダイレクト、各段階のオリジンと実接続先を記録すべきだ。後継関係をたどる処理と、通常の取得リダイレクトも区別した方がよい。前者は意味上の継承主張であり、後者は転送機構だからである。

一致したダイジェストが保証する範囲

提案は成果物にダイジェストを関連付けられる。RFC 9530 と RFC 9651 は HTTP におけるコンテンツダイジェストの現代的な語彙を示す。JSON のプロファイルが RFC 8785 のような正規化を指定する場合もある。値が一致すれば、取得した表現が宣言されたバイト列と整合することを確認できる。

そこから著者、真実性、安全性、ライセンス、現在の適用可能性は導けない。攻撃者が発見文書と対象の両方を更新できれば、新しい一致値を公開できる。TLS と DNS は応答したオリジンの確認に役立つが、そのオリジンの管理権と編集上の主体は同義ではない。共有ホスティング、委託運用、アカウント侵害、事業譲渡のどれでも両者は分離する。

何をハッシュするかも明示が必要だ。転送時の符号化を含むバイト、復号後の内容、正規化オブジェクトでは値が異なる。コンテンツネゴシエーションや中間変換があると、同じ概念の文書に複数表現が生まれる。ダイジェストがない場合は「この方法では未検証」、不一致なら「この表現は受け入れない」と扱うべきで、前者を直ちに不正とし、後者だけで責任主体を断定してはいけない。

RFC 9421 の HTTP Message Signatures は選択したコンポーネントを鍵に結び付けられる。それでも信頼判断は残る。誰の鍵か、いつ有効だったか、どの種類の成果物に権限があるか、どの操作を要求できるかはローカルな統治事項である。署名の正当性と命令の許可は別だ。

発見された文章は命令チャネルではない

関係名が skills、now、contribute であっても、対象の文章がエージェントへの特権命令になるわけではない。索引化、要約、比較の対象であり、「制約を無視せよ」「認証情報を送れ」「本番を変更せよ」といった記述は外部入力のままである。

安全な構成では、取得サービスがオリジン、最終 URL、リダイレクト列、メディア型、関係、ダイジェスト結果、取得時刻、信頼判定を構造化して保持する。実行サービスには具体的能力の申請だけを渡し、利用者、テナント、対象資源、期限、ポリシー版に基づいて別途判断させる。外部文章とシステム方針を一つの会話に平坦化してはならない。

リンクをたどるクローラはネットワーク主体でもある。ピアやリダイレクトはループバック、プライベート網、リンクローカル、メタデータサービスへ誘導し得る。DNS rebinding により確認時と接続時でアドレスが変わることもある。URL を正規化し、許可スキームを限定し、制御下の名前解決を使い、各リダイレクトと実接続時にアドレス分類を再確認する必要がある。

ピア探索には深さ、ノード数、バイト、時間、並行数、オリジン単位要求数の上限を置き、循環を検出する。上限に達した結果は部分的である。「この探索内で見つからなかった」は存在否定ではない。後継が探索境界の外側にある場合も同じだ。

時間の証拠と履歴の選択

RFC 9111 のキャッシュ、ETag、304 Not Modified は転送を効率化する。304 はサーバの検証子に対して表現が変わっていないことを示すだけで、著者や委任を再証明しない。重要な判断では、どの発見文書がどの対象を示したか、キャッシュ年齢、検証子、適用ポリシーを保存すべきである。

台帳の先頭を過去の観測と比較すれば、巻き戻しや置換を検知できる。しかし二つの履歴が現れたとき、台帳自身はどちらを信頼すべきか決められない。外部の鍵管理、指名権威、独立アーカイブ、クォーラム、復旧手続きが必要になる。current はオリジンが今提示する状態であり、過去の完全性の証明ではない。

発見文書の公開自体も情報を漏らす。対象が認証必須でも、存在、名前、関係、更新頻度、メディア型、ダイジェストが見える場合がある。公開ビューを縮小し、認証主体には別ビューを返し、機微な値を省略できる設計が必要だ。縮小ビューで見えないものを不存在と扱ってはならない。

冒頭の移転では、最適な挙動は自動追随でも全面拒否でもない。旧ノードの終了を確定し、後継主張を証拠として保存し、新しい主体を新規に審査することである。knowledge-linkset は知識の道標を長持ちさせられる。道標が指した相手に、旧所有者の権限まで運ばせてはならない。

Sources