What's the difference between LRDD discovery and Webfinger?

Question

So I've been trying to understand WebFinger (RFC7033) and stumbled upon Web Host Metadata (RFC6415). As far as I can tell, they are both RFCs and solving the same problem in almost the same way.

So if I wanted to lookup information about a person or a thing by their URI, I could do two things:

• WebFinger suggests that I navigate to /.well-known/webfinger?resource=...
• Host-Meta suggests I take a look at /.well-known/host-meta which returns a JRD or an XRD with something like <link rel="lrdd" template="http://example.com/lrdd?uri={uri}">

Webfinger just has one less lookup and encourages JRDs. Why can't I just create a host-meta with a template that looks like http://example.com/.well-known/webfinger?resource={uri} and doing both things (albeit redundantly)?

Is there any important difference between the two I'm missing? Should I prefer one over the other?

Answer 1

Author of RFC 7033 here.

WebFinger was a work-in-progress for several of years and underwent a number of changes during that time. RFC 6415 was the first attempt to standardize the concept of WebFinger, which included host-meta and LRDD. The process of discovery using RFC 6415 was complicated by the fact that one needed to perform two queries and then merge information from each of the queries to create a resulting set of link relations. Also, there had been a move for a while toward JSON. WebFinger had used XML, but RFC 6415 Appendix A introduced a JSON encoding. People wanted that to be the only encoding.

Working with the original authors of RFC 6415 and others in the WebFinger community, a group of us in the IETF worked to simplify the process, make the move to JSON as the content encoding, ensure the solution was secure (HTTPS only), and get agreement on a URI scheme for querying user account information (the "acct" URI).

So with RFC 7033 we have a secure, simple, one-query mechanism for discovery that works basically like this:

$ wfinger [email protected]

What this "wfinger" client would do is find the domain "packetizer.com" and then issue the following query (using curl just to make the example clear):

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

Note that any URI scheme may still be used with WebFinger -- that concept was not lost. So as intended with the original WebFinger, it was possible to query for information about web pages (e.g., www.packetizer.com) or other types of content. Here is one example:

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

That would return link relations and other metadata about the page "http://www.packetizer.com".

Answer 2

WebFinger and Host-Meta overlap in what they can be used for. They can be and are used together (see Mastodon for example), but they can also express additional things on their own.

On the surface, both provide metadata about entities using a Resource Descriptor document. They differ in the primary serialization format: Host-Meta requires the XML-based XRD (application/xrd+xml) while WebFinger promotes the JSON-based JRD (application/jrd+json). There are no big differences between those formats in terms of capability and they can be easily converted back and forth. Perhaps the only notable difference is a lack of standardized extensibility in JRD, so it is slightly less capable in these situations. It is best to provide both at any endpoint, selectable via content negotiation (the Accept header), and using JRD by default for /.well-known/webfinger and /.well-known/host-meta.json, and XRD for /.well-known/host-meta.

Resource Descriptors are linked to a resource they describe using the lrdd Link Relation, regardless of which technology they use:

Refers to further information about the link's context, expressed as a LRDD ("Link-based Resource Descriptor Document") resource. See [RFC6415] for information about processing this relation type in host-meta documents. When used elsewhere, it refers to additional links and other metadata. Multiple instances indicate additional LRDD resources. LRDD resources MUST have an "application/xrd+xml" representation, and MAY have others.

WebFinger satisfies this definition, and as long as you provide an XRD representation (alongside JRD), you are perfectly entitled to <Link rel="lrdd" template="/.well-known/webfinger?resource={uri}"/>. I would go as far as to say that if you use WebFinger, you should advocate it this way in host-meta, for others to discover and for compatible software to take advantage of. To sum up your questions ‒ you should start with WebFinger as the baseline, and if you offer both JRD and XRD, then implementing Host-Meta just means providing the host-meta document (even statically) with the lrdd link. From a client implementation's perspective, checking /.well-known/webfinger is the fastest option, ensuring that it provides complete information about the resource, but if that is not found, going through the slow route of host-meta and looking for lrdd links is always a possibility.

Lastly, there are differences in capability of both technologies as well: WebFinger supports optional filtering of the links through the rel parameter, which Host-Meta (being a generalization of sorts) lacks. However, Host-Meta allows you to provide concrete resource-specific links for all resources at once (I could not find whether that is supposed to mean all resources in the universe, or only the resources managed by a particular host), so if you cache the document, you could in theory find the resource even more quickly, e.g.:

Through WebFinger, you can request /.well-known/webfinger?resource=acct:[email protected]&rel=icon if you are looking for Bob's icon, and the server retrieves it (if it exists) amongst the links. In Host-Meta, you may however specify:

<Link rel="icon" template="/icon?for={uri}"/>

and you automatically know to look at /icon?for=acct:[email protected] whenever you need Bob's (or anyone's) icon (percent-encoding omitted for readability). Multiple lrdd links may also be provided, even pointing to different servers, so you can have a delegation of description of sorts for the client to combine (whereas in WebFinger such burden would be on the server).

In addition, Host-Meta obviously also allows you to provide properties and links pertaining to the host itself, but that is expressible in WebFinger too (if you agree on the host's URI).

Answer 3

Although the Webfinger RFC says /.well-known/webfinger? actual implementations use /.well-known/host-meta

See: http://hueniverse.com/2009/09/02/implementing-webfinger/

It seems WF has been superseded by WHM.