要約

  • 2026年10月1日の draft-newbold-atp-aturi-00 は、複数のコロンを含む DID を // 後の authority に置く構文が RFC 3986 の共通文法に合わず、この版は RFC 7595 の恒久登録要件を満たせないと述べる。
  • IANA の at は2023年から暫定登録されている。これは名称の登録を示すが、IETF の正式審査、汎用パーサーとの互換性、handle からレコード内容までの永続性を保証しない。

標準化で最も価値のある文章は、ときに機能一覧ではなく、自分が越えていない境界である。新しい at URI 草案は、稼働中の仕組みを否定せず、その構文がまだ得ていない資格を明記した。

改訂00は個人提出である。ヘッダーには Standards Track の意図があるが、凍結した Datatracker レコードには stream、state、標準レベルがない。議論先に Authenticated Transfer のメーリングリストが書かれていても、WG 採択や IESG 承認にはならない。まして RFC ではない。

識別子は at:// の後に account authority を置き、必要なら collection と record key を続ける。authority は読みやすい handle でも、恒久的な account identifier でもよい。専用リゾルバーはそれを解釈して repository の record へ進める。

問題は DID の形にある。did:plc:… のような値は複数の未エンコードのコロンを持つ。RFC 3986 の authority は、任意の userinfo、host、任意の port という共通構造を持つ。RFC 7595 は URI 全体の構文を個別 scheme が上書きできないとする。草案は、このため現在の DID authority 方式が恒久登録の対象になれないと結論する。

ここで「動かない」と読み替えてはいけない。専用パーサーが authority を不透明な文字列として扱えば運用できる。草案も利用を記録している。恒久登録に不適格なのは、この改訂で示した構文であり、将来の全設計ではない。拒否決定や移行命令も資料にはない。

IANA には別の現実がある。at は2023年6月から Provisional で登録済みだ。RFC 7595 の暫定登録は、単一組織内に閉じない利用を名前空間に記録するための First Come First Served 手続きである。恒久登録は Expert Review を経て、共通構文などの条件を満たす。

at に付いた専門家ノートは、暫定登録が IETF の正式レビューでも一般利用の推奨でもないと説明する。また短い at という名前の混同可能性と、atproto や atp という代案が議論されたことを記す。それが将来の恒久申請の障害になり得るともいう。ただしノート自体は IETF や IANA の公式見解ではない。

したがって運用台帳は四つの欄を必要とする。実利用、暫定 IANA 登録、個人草案の Standards Track 意図、現行構文の恒久登録不適格である。「登録済み」の一語では精度が足りない。

handle も同様に入口と主体を分ける。handle は変更でき、別の DID に再利用され得る。古い URI が無効になるだけでなく、別 repository を指す可能性がある。草案は長期保存前に handle を恒久 account identifier へ解決し、record 内では恒久識別子を使うよう求める。

それでも DID は保管場所でも内容でもない。authority は account identity を示し、repository endpoint は別に解決される。collection と key は論理 record を示すが、record は更新・削除され得る。AT URI は content-addressed ではない。強い参照が必要なら CID を併記するのが実装指針だ。

必要な証跡は、構文 profile と改訂、parser と version、handle/DID の別、handle 解決時刻、repository endpoint、collection/key と取得 revision、CID、最後の application outcome である。最初の parse 成功が最後の処理結果を証明することはない。

公式文書には Python urllib と JavaScript url-parse が扱える例、Go net/url と多くの Rust crate が扱えない例として挙げられる。これは有用な注意書きだが、全 version と全 binding の独立調査ではない。実運用は自分の組合せを試験すべきだ。

Heng Lu の Running-Code Primacy は、制度名で稼働実態を消すことを拒む。同時に、稼働実態が制度承認を自称することも許さない。Minimum Initial Specification は handle、恒久 identity、location、record、content hash の最小分離を守る。Reality Layers は registry row、parser output、取得 byte、利用者結果を別の層に戻す。

これは標準と実装の勝敗ではない。protocol、registry、expert review、operator、application が、それぞれ証明できる範囲だけを引き受けるための設計である。

出典