要約

  • WebFingerは、覚えやすいアカウント名を問い合わせに変えた。2013年のRFC 7033では、クライアントが名前のドメインにある /.well-known/webfinger を訪れ、JSONのリンクを受け取る。名前はアプリをまたげても、行き先の帳簿はドメインが持つ。
  • 2015年のRFC 7565は acct: をアカウント識別子として定義した。2024年のW3Cコミュニティグループ報告は、同じ検索でActivityPubのactorを見つける方法を記した。携帯しやすいハンドルは、指定されたホストの返事で働く。

呼びやすい名前だけでは場所が分からない

「Carolはexample.comにいる」と人に伝えるのは簡単だ。ソフトウェアはそこからログイン先や人物の文書を探さなければならない。プロフィールのURLは /carol かもしれず、/users/carol や長い識別子かもしれない。名前からURLの形を当てる必要をなくすために、対応表を問い合わせる仕組みが要る。

2013年9月のRFC 7033は、その問い合わせ先をアカウント名のドメインに置いた。クライアントは example.com の /.well-known/webfinger に、たとえば Carolのexample.com上のacct:識別子 を符号化した resource を付けてGETする。応答はJSON Resource Descriptorで、対象、別名、属性、関係の種類を持つリンクを含む。relで必要な関係に絞ることもできる。RFCの例ではCarolのOpenID Connect発行者を探す。人が渡した名から、アプリが使う接続先をドメインが答える。

ここで力を持つのは @ の見た目ではなく、返答するホストだ。クライアントはユーザー名だけから接続先を計算できない。ドメインの運営者は、名を保ちながらリンク先を変えられる。同時に、その窓口が答えなければ遠隔のクライアントにはWebFingerの答えがない。RFCが共通化したのは問い方であり、各ドメインに代わって答える中央の台帳ではない。

acctはプロフィールのURLではない

2015年5月のRFC 7565は acct: URIを、どの通信方式でアカウントを使うかとは独立した、サービス提供者上のアカウント識別子として定義した。Carolのexample.com上のacct:識別子 自体をブラウザーで取得してもプロフィール文書になるわけではない。WebFingerはその識別子を指定ドメインへの質問にし、応答の中で実際のWebリンクを受け取る。

この分離のおかげで、あるアプリは認証先を、別のアプリは著者情報を探せる。ただし、最初の問い合わせ先は常に @ の後ろで決まる。汎用的な書式だけで、そのドメインの運営権が利用者へ移ることはない。対応表を配る者が現実の発見経路を握る。

2024年のW3Cソーシャルウェブ孵化コミュニティグループ報告は、ActivityPubでの使い方を記した。user@domain から acct: を作り、そのドメインのWebFinger窓口へ問い合わせ、actor文書のHTTPS URLを得る。文書のパスはサイトごとに異なってよい。逆方向にactor文書からハンドルを確認する手順もある。これはコミュニティグループの報告であり、W3C勧告として扱う文書ではない。

見つけやすさには別の利用者もいる。RFC 7033は、公開窓口への問い合わせでアカウントの存在が分かり、住所と他の情報を結び付けて収集やフィッシングに使われうると記した。アクセス制御や回数制限が議論される理由だ。実際の窓口を評価するときは、どの質問に答え、どの別名や属性まで返すかを見なければならない。

WebFingerは、サービスごとのURLの癖を暗記せずに、アカウント名から接続先を見つける共通手順を作った。その手順の最初の一歩は名前のドメインへ行くことだ。ハンドルは遠くへ伝わる。住所録はそのドメインの机に残る。