要約

  • REGEXTで検討されている現行Internet-Draftは、RDAPのどの連絡先属性を、いつ、誰が、どの方法・証拠・信頼枠組みで確かめたかを表現できる。ただし主要項目の多くは任意であり、検証済みという事実は無制限の公開や依拠を許すものではない。
  • 運用者は、検証イベントと開示判断の間に「閲覧者・有効性開示記録」を置くべきだ。誰に、何の目的で、どの項目を示し、いつまで利用可能と判断したかを残す。この記録はDaniel Kadeによる編集上の提案であり、IETF草案の要件ではない。

一つの確認結果に、複数の見せ方がある

あるレジストラが、登録者のメールアドレスへリンクを送り、受信者がクリックしたとする。その翌日、匿名の利用者が公開RDAPを検索する。別の時間には、認証済みの不正利用対応担当者が具体的な調査目的を示して照会する。さらに、法的根拠を持つ当局から限定的な情報提供を求められるかもしれない。

元になった確認操作は一つでも、三者へ返す情報が同じである必然性はない。検証は「どの手続が、どの属性に対して行われたか」を示す。開示は「どの受け手に、どの情報を渡せるか」を決める。依拠は「受け手がその結果から何を判断してよいか」を定める。三つを一つの緑色の印にまとめれば、見た目は簡単になるが、説明責任は失われる。

意味の喪失は、連携が成功するほど起きやすい。最初のサービスは属性、日付、方法を保持していても、次の画面は「検証済み」だけを表示する。CSV出力では対象属性が消え、スコアリング基盤では時刻が消える。やがて「3月10日にメール到達性を確認」が「登録者は信頼できる」に変わる。元データが誤っていたのではない。境界のある事実を、境界のない評価へ変換したことが誤りなのである。

第04版を標準として扱ってはいけない

Registration Data Access Protocol (RDAP) Extension for Verified Contact Information の第04版は、2026年8月24日付である。IETF Datatrackerでは、REGEXTの文脈にある有効なInternet-Draftで、作業部会の状態は「Candidate for WG Adoption」、IESGの状態は「I-D Exists」と表示されている。IETFによる正式な承認や採択を意味しない。文書の冒頭にある「Intended status: Standards Track」も目標を示すもので、手続の完了を示すものではない。

草案はRDAPのentityオブジェクトへ verifiedContacts_data という配列を加える。各要素は、メール、電話番号、FAX、住所、氏名、名、姓、生年月日など、検証対象となったclaimを示せる。さらに、検証完了日時、検証者の識別子と表示名、検証処理の識別子、信頼枠組み、方法、証拠の種類、備考、拡張情報を格納できる。

配列であることには意味がある。氏名は身分証で照合され、メールはリンクで到達性を確かめ、住所はデータベースで確認されたかもしれない。それぞれ実施者も時期も規則も違う。一つのentityに複数の検証オブジェクトを置ける設計は、その違いを残す。画面側で一つの真偽値に畳み込めば、設計が守った差異を実装が捨てることになる。

主要な説明項目の多くは任意である。したがって、存在しない値を都合のよい既定値で埋めてはならない。第04版は verificationDate について、検証処理が完了した時点を表し、項目がないからといって現在も有効であることを意味しない、と明記した。日時があっても、それ自体は有効期限ではない。何か月前の確認を現在の不正利用調査で使えるかは、用途、変更履歴、リスクに応じて運用者が決める。

第03版との比較では、JSON例の修正に加え、最新のRDAP versioning草案に合わせた記述と、検証完了時点に関する説明の追加が確認できる。第04版自身の変更履歴は、例の訂正、versioning文書への追随、文章の整理と要約している。更新が続く作業文書である以上、実装者は版を固定して意味を記録する必要がある。

到達性、本人性、権限は別の問い

草案はverification methodとevidenceを分けている。reachability は、コード入力やリンクのクリック、受領確認など、受信者の能動的な応答によって通信手段の到達性を確かめる。ほかに、物理的・画像的な文書確認、電子記録の照合、暗号学的検査、電子認証、トークン、知識ベース質問、対面・遠隔の人的確認、生体照合などがある。

証拠の種類には、IDカード、旅券、在留許可、銀行・公共料金・税務に関する書類、出生や住民の記録、書面・電子の証明、メールや郵便の確認ログ、住所データベースなどが挙げられる。同じ証拠を別の方法で調べることも、同じ方法を別の証拠へ用いることもできる。意味を持つのは、対象claim、方法、証拠、信頼枠組みの組み合わせである。

メールへの到達性が示すのは、ある時点でその通信経路を使った操作が完了したことだ。法的な本人確認とは限らない。本人確認ができても、法人を代表する現在の権限までは示さない。代表権があっても、ドメインや番号資源を現に支配している証明とは別である。一つの属性の確認から、登録データ全体の完全性も導けない。

この区別は検証の価値を弱めない。むしろ用途に合わせて使えるようにする。不正利用対応では新しい到達性情報が連絡の優先順位に役立つ。資源移転では、より強い本人性や権限の証拠が必要になる。判断の強さを証拠の射程に合わせればよい。

private を世界共通の保証水準にしない

trustFramework は拡張可能で、草案は eidas と private を定義している。private は、外部の登録済み枠組みではなく、サーバー運用者の方針に沿った検証を意味する。これは無効の印ではない。しかし、世界のどこでも同じ保証水準を表す印でもない。

解釈には、適用した方針そのものと版が要る。受け入れる証拠、再確認の周期、確認を行える主体、例外条件が改定されれば、同じ private という文字列でも意味は変わる。方針名だけを保存するのは、規則を引用しながら公布日を落とすのと同じだ。

外部枠組みの場合も名前だけで十分とは限らない。どのclaimに、どの保証水準を、どの法域で適用したかが必要である。相互運用性とは、違いを消して同じ印を表示することではない。違いを壊さずに比較できることだ。

証拠の種類だけでもプライバシー情報になる

旅券の画像や銀行明細そのものをRDAPで返さなければ安全、とは言い切れない。「旅券を使った」「税務記録を照会した」「生体照合を行った」というメタデータだけでも、その人がどのような本人確認を受けたかが分かる。正当な権限を持つ受け手には必要でも、匿名の閲覧者には過剰な場合がある。

草案のSecurity Considerationsは短いが明確だ。連絡先検証データにはプライバシー上の影響があり得るため、サーバーは開示が適用法令と方針に従うよう確保しなければならない。また序文は、一般公開のRDAPと、正当なアクセス要求者や当局に事前認可を求める閉じたRDAPの双方を想定する。

つまり草案は一つの公開範囲を選んでいない。同じデータ構造を異なるアクセス制度で使えるようにしている。どの項目をどの利用者へ返すかは実装と運用の責任である。公開応答では最小限にし、認証済み応答では目的に必要な範囲を返し、証拠の種類はどちらにも出さない、という設計もあり得る。

草案はNIS2第28条を、ドメイン名登録データの正確性と完全性に関する背景として挙げる。そこから、検証メタデータの全面公開義務を導くべきではない。収集、維持、検証、制限付きアクセス、一般公開は異なる処理であり、それぞれに根拠が要る。

万能の認証印が作る五つの空白

単一の「検証済み」表示には、少なくとも五つの空白がある。どのRDAPオブジェクトか。どの属性を確かめたか。どの方法と証拠を使ったか。いつ実施され、現在どの鮮度規則が適用されるか。誰への開示を認めた情報か。どれか一つが変わっても、印は同じまま残り得る。

公開応答に検証情報がないことを「未検証」と読むのも誤りだ。検証済みでも、現在の閲覧者に見せない決定かもしれない。データ品質と開示状態を同じ軸に置くと、プライバシー保護が品質不足と誤認され、過剰公開への圧力が生まれる。

そして、一度外部へコピーされた印は回収しにくい。元の運用者が訂正や取消しを行っても、検索索引、データ仲介業者、案件記録には古い状態が残る。プロトコル上の訂正可能性だけで、社会的な可逆性は確保できない。

閲覧者・有効性開示記録

必要なのは、保持している検証情報をRDAP応答へ変換するたびに、判断記録を残すことである。ここでは「閲覧者・有効性開示記録」と呼ぶ。草案のwire formatへ追加する提案ではなく、運用者が説明責任を果たすための内部記録である。

第一に、情報源を結ぶ。RDAPオブジェクト、正確なclaim集合、検証識別子、検証者、完了日時、実際のmethodとevidence、trust frameworkを記録する。枠組みを解釈した方針の識別子と版も添える。項目がなければ「なし」とし、推測で補わない。

第二に、受け手を結ぶ。匿名公開、認証済み利用者、内部担当、当局などの区分、必要な場合の認証主体、申告目的、公開・制限チャネル、開示・非開示・マスキングした項目を残す。法令、契約、公開アクセス方針、個別判断のいずれが認可根拠かをたどれるようにする。判断者と異議申立ての経路も必要だ。

第三に、有効性を結ぶ。再検証間隔、イベントによる見直し条件、日付欠落時の扱い、訂正・取消し・置換の状態を記録する。これは verificationDate を勝手に有効期限へ変えることではない。過去の結果を現在の目的へ使えるかという、運用者自身の判断を可視化する作業である。

この記録に、身分証の画像、生体情報、検証用の秘密を複製してはならない。残すべきなのは、なぜその時点で、その受け手へ、そのメタデータを見せたのかという境界である。

小さく始め、変更可能性を守る

Heng Luが示すminimum initial specification、localized future decision、voluntary adoptionという考え方は、この課題に適している。claim、method、evidence、frameworkの共通語彙は協調を助けるが、全世界で一つの開示方針を即座に採用する必要はない。

最初は一つの連絡先属性、版管理された一つの方針、認証済みの一種類の受け手、短い再確認期間に絞れる。公開応答ではRFC 9537のredaction表現を活用し、証拠の種類そのものは返さない選択もできる。古い情報、誤った依拠、異議申立てを観測してから範囲を広げればよい。

共通の構文は経験を比較可能にし、ローカルな判断記録は責任主体を残す。最小化とは永遠に閉じることではない。最初の実装を、後から修正できる制度として作ることだ。

情報源