LRDD 发现和 Webfinger 之间有什么区别？

Question

所以我一直在尝试理解WebFinger (RFC7033) 并偶然发现了Web Host Metadata (RFC6415)。据我所知，它们都是 RFC，并且以几乎相同的方式解决相同的问题。

因此，如果我想通过 URI 查找有关人或物的信息，我可以做两件事：

• WebFinger 建议我导航到/.well-known/webfinger?resource=...
• Host-Meta 建议我看一下/.well-known/host-meta返回 JRD 或 XRD 的内容，例如<link rel="lrdd" template="http://example.com/lrdd?uri={uri}">

Webfinger 只是少了一次查找并鼓励 JRD。为什么我不能只创建一个host-meta看起来像http://example.com/.well-known/webfinger?resource={uri}并且做这两件事（尽管是多余的）的模板？

我所缺少的两者之间有什么重要的区别吗？我应该选择其中之一而不是另一种吗？

Answer 1

RFC 7033 的作者在这里。

WebFinger 已经开发了好几年，并在此期间经历了许多变化。RFC 6415 是标准化 WebFinger 概念的第一次尝试，其中包括主机元和 LRDD。使用 RFC 6415 的发现过程很复杂，因为需要执行两个查询，然后合并每个查询的信息以创建一组链接关系结果。此外，一段时间以来人们一直在转向 JSON。WebFinger 曾使用 XML，但 RFC 6415 附录 A 引入了 JSON 编码。人们希望这是唯一的编码。

我们 IETF 中的一组人与 RFC 6415 的原作者和 WebFinger 社区的其他人合作，致力于简化流程，转而使用 JSON 作为内容编码，确保解决方案是安全的（仅限 HTTPS），并获得就用于查询用户帐户信息的 URI 方案（“acct”URI）达成一致。

因此，通过 RFC 7033，我们拥有一种安全、简单、单查询的发现机制，其工作原理基本如下：

$ wfinger paulej@packetizer.com

这个“wfinger”客户端要做的是找到域“packetizer.com”，然后发出以下查询（使用curl只是为了使示例清晰）：

$ curl https://packetizer.com/.well-known/webfinger?resource=acct%3Apaulej%40packetizer.com

请注意，任何 URI 方案仍可与 WebFinger 一起使用——这一概念并未丢失。因此，正如原始 WebFinger 的预期，可以查询有关网页（例如 www.packetizer.com）或其他类型内容的信息。这是一个例子：

$ curl https://packetizer.com/.well-known/webfinger?resource=http%3A%2F%2Fwww.packetizer.com

这将返回有关页面“ http://www.packetizer.com ”的链接关系和其他元数据。