摘要

  • WebFinger 把熟悉的账号名变成一次查询。2013 年的 RFC 7033 要求客户端去名字后面的域名，向 /.well-known/webfinger 提问，再从返回的 JSON 链接中找目标。名字可以跨应用传播，地址簿仍由那个域名供应。
  • 2015 年的 RFC 7565 把 acct: 定义为账号标识；2024 年 W3C 社区组报告描述了用同一查询寻找 ActivityPub actor。看似便于携带的 user@domain，能否被找到，仍取决于域名是否回答。

好记的名字，难猜的住址

告诉别人「Carol 在 example.com」，对人足够清楚，对软件却只是一半答案。登录服务在哪个网址？个人主页是 /carol、/users/carol，还是一串没有意义的编号？各网站可以自行设计地址。要让应用找到目标，需要一个把账号名映射成链接的目录。

2013 年 9 月发布的 RFC 7033把目录放在账号所属域名下。客户端可向 example.com 发送 GET /.well-known/webfinger?resource=acct%3Acarol%40example.com。服务器返回 JSON Resource Descriptor，包含主题、可能的别名、属性和带关系类型的链接。客户端还可用 rel 指定想找哪一类关系。RFC 的例子是查询 Carol 的 OpenID Connect 身份提供者。人给出账号名，应用从域名取得服务入口。

关键权力不在漂亮的 @ 符号，而在回答查询的主机。客户端不能凭用户名拼出提供者的网址；它向主机发问，按返回的关系走。域名运营者可以在名字保持原样时改变映射。这个灵活性也是依赖：如果端点不作答，远程应用就拿不到此名的 WebFinger 答案。标准统一了问题，没有在别处建立一份替域名说话的总通讯录。

账号标识不是网页

2015 年 5 月的 RFC 7565另行定义了 acct: URI：它标识服务提供者处的账号，不预设与账号交互的协议。Carol 在 example.com 的 acct: 账号标识符 是账号身份，不是浏览器直接抓取 Carol 主页的 HTTP 地址。WebFinger 才把它转成发往指定域名的问题，再由域名给出实际可访问的链接。

这个分工让不同应用能询问不同关系：某个程序要登录服务，另一个要作者或主页信息。然而，问题的第一站始终由 @ 后的域名决定。acct: 的通用写法没有把该域名的控制权交给用户。谁运行这个主机，谁维护活的映射。

2024 年 W3C 社交网络孵化社区组报告把做法用于 ActivityPub：将 user@domain 转成 acct: 资源，向该域名的 WebFinger 端点查询，取回指向 actor 文档的 HTTPS 链接；文档的实际网址可以采用不同路径。报告还描述反向发现，让 actor 文档指回名字。这是一份社区组最终报告，记录后来的社交网络惯例；它不是 W3C 推荐标准。

容易发现也意味着容易打听。RFC 7033 指出，公开查询可能暴露某个账号是否存在，并将其他资料与地址关联，给收集名单和钓鱼者可乘之机。RFC 因而讨论访问控制与限速。检查实际服务时，要看它对何种请求作答、返回了哪些别名和属性，而不是把「可发现」当成无条件的好消息。

WebFinger 的贡献很具体：应用不用猜每个网站的个人主页路径，就能用 HTTPS 找到与账号相关的服务或文档。代价同样写在请求路径里：客户端先到域名门口，问它该往哪儿去。用户名容易带走，地址簿留在原地。