要約

  • RFC 9560により、RDAPサーバーはOpenID ConnectとOAuthを使い、各サービスで別々の資格情報を持たせずに利用者を識別し、Bearer Tokenを検証できる。
  • 用途と追跡拒否のクレームはローカルポリシーへの入力であり、実際の動機、個別照会の権利、全経路での非記録、返された登録情報の質を保証しない。
  • 監査可能な記録には、トークン検証だけでなく、ポリシー版、照会目的、開示フィールド、元記録の来歴、その後の調査結果が必要だ。

Bearer Tokenの検証が通った。発行者、対象受信者、有効期限、形式について、サーバーが処理を続けられるだけの根拠が得られたということだ。ところが運用文書では、ここから意味が滑りやすい。「認証済みの利用者」が「照会する権利を持つ利用者」になり、「許可された用途」が「本当の意図」になり、最後には返答が「確認済みの現実」になる。RFC 9560はこの短絡を認めていない。

2024年4月にIETF標準化過程で公開されたRFC 9560は、RDAPでOpenID Providerを発見し、セッション型またはトークン型の手順を使う方法を定める。サーバーごとにアカウントを作る負担を減らしながら、どの登録情報を見せるかは各RDAPサーバーのポリシーに残した。

認証が閉じる問いは一つだけ

トークン型の照会では、サーバーはローカルポリシーに従ってトークンを検証し、正当なアクセストークンであることを確認しなければならない。RFC 7662のイントロスペクションもJWT解析も使える。audが別の依存当事者を指すなら信頼しない選択があり、RFC 8693のトークン交換で対象を合わせる方法もある。

ここで確かめたのは、この通信で資格情報に依拠できるかどうかである。閲覧可能なデータはまだ決まっていない。検証後にサーバーはクレームとローカルポリシーを照合し、照会ごとに許可を判断する。拒否、項目の省略、マスキング、開示はそれぞれ別の結果だ。

用途は付与された資格であって、動機の観測ではない

任意のrdap_allowed_purposesは、その身元に認められた利用目的を示す。Identity Providerは、使う資格のある身元にだけ目的値を付与する。クライアントは個別照会の目的をfarv1_qpで示せる。許可集合にない目的ならサーバーは403を返す。

この仕組みはアクセス制御を整理するが、内心を読むものではない。ある区分を使う資格、今回その区分を申告したこと、取得後も同じ目的を守ったことは三つの別件だ。目的がローカルポリシーと合わなければ、サーバーはクレームとパラメーターを無視できる。目的指定がなくても、別の情報でアクセス判断を行う責任は残る。

追跡拒否は監査との交換条件を持つ

rdap_dnt_allowedが受け入れられると、サーバーは利用者の身元と照会との対応をログに残さない。条件は、識別と権限確認、trueのクレーム、現地の記録規則への適合である。RFCは、この約束がサーバーとプロキシの善意、事前の帯域外信頼に依存し、情報損失によって監査能力を大きく損なう可能性があると明記する。

機密性の高い調査に照会秘匿が必要なことはある。だからこそ、誰が付与し、どの中継点まで覆い、どんな代替証拠を残し、いつ失効するかを決める必要がある。「追跡拒否を受理した」はポリシー上の出来事であり、世界中の全システムが対応関係を保持しなかったという暗号学的証明ではない。

応答データにも固有の立証責任がある

応答中のfarv1は拡張への適合を示すだけで、基礎となる登録記録を認証しない。正しい応答でもポリシー上の一部だけかもしれず、元記録には更新時刻、確認方法、訂正履歴、曖昧な役割が残る。HTTP 200は完全性や有用性を、403は利用者の不正を証明しない。

共通化すべき最小層は、発見、トークン処理、クレーム名、照会パラメーターである。全世界の正当目的、開示基準、調査結論まで共通化したふりをしてはいけない。Lu Hengが論じる現実の層で見れば、身元、トークン、目的資格、許可判断、開示記録、現実の成果は、いずれも実在するが互いの代用にはならない。