Summary

  • WebFinger made a familiar account name into a query. RFC 7033 in 2013 directed a client to the domain in that name, where /.well-known/webfinger returned a JSON list of links. The name could be passed between applications; the domain supplied the map.
  • RFC 7565 later defined acct: as an account identifier independent of the protocol used to talk to that account. A 2024 W3C Community Group report described the same lookup for ActivityPub actors. A portable-looking handle still depended on the named host answering for it.

The name was easy to say; the destination was not

“Carol at example.com” is a usable way to tell another person who you mean. It does not tell an application whether Carol's login provider, profile page or social actor lives at a predictable URL. A website might use /carol, another /users/carol, a third a long opaque identifier. The name and the document needed a directory between them.

RFC 7033, published in September 2013, placed that directory at the account's domain. A client could send GET /.well-known/webfinger?resource=acct%3Acarol%40example.com to example.com. The server returned a JSON Resource Descriptor: a subject, optional aliases, properties and typed links. The requesting program could ask for a particular rel relation to narrow the answer. The RFC's own example used the method to find Carol's OpenID Connect issuer. A human gave an account name; the application got a provider link from the domain named in it.

That endpoint was the quiet seat of authority. The client did not derive the provider from the username's spelling. It asked the host and used the returned relation. The domain operator could change the mapping while keeping the handle recognizable. The same control made the domain a point of dependence: when its endpoint gave no answer, a remote client had no WebFinger answer for that name. The standard provided a common question, not a universal address book maintained elsewhere.

An account identifier was not a web page

The related RFC 7565 of May 2015 defined the acct: URI scheme for an account at a service provider, independent of the particular protocol used to interact with it. The acct: identifier for Carol at example.com identifies an account; it is not an HTTP address that a browser can simply fetch as Carol's profile. WebFinger turns that identifier into a question directed to the named host, and the host's answer supplies actual web links.

That separation gave the system room to work across services. An application could look for an identity provider relation; another could look for profile or author information. It also fixed the place where interpretation began. The domain after @ determined the host to query. Neither the attractive @ notation nor the acct: scheme by itself transferred control of the name to its user. A service provider operating the domain held the live map.

In 2024, a W3C Social Web Incubator Community Group report described how this pattern serves ActivityPub. A person-friendly user@domain address becomes an acct: resource. A client queries that domain's WebFinger endpoint and receives a link to an actor document, whose actual HTTPS URL may follow a different shape. The report also described reverse discovery to link an actor document back to the handle. It is a Community Group report, not a W3C Recommendation; its value here is that it records the later social-web use of the 2013 lookup pattern.

A public directory can answer the wrong visitor too

RFC 7033 recognized the other side of easy discovery. A public endpoint can reveal whether an account identifier is valid and attach other information to it. That can assist address harvesting or more convincing phishing. The RFC discussed access controls and rate limiting as responses, with implementation choices depending on context. A directory useful to legitimate clients is also useful to anyone who can ask it questions.

The record to inspect is therefore the actual response, not a slogan about decentralized identity. Which resource was queried? Which host answered? What rel did the client ask for, and which links came back? Did the response expose aliases or properties beyond the requested relation? A dated request and response would settle those questions for a real account. The RFC describes the protocol; the 2024 report describes a later convention. Neither is a captured response from a named user's server.

WebFinger did something modest and consequential. It made an account-shaped name discoverable through ordinary HTTPS without requiring every application to guess each provider's URL layout. The bargain was explicit in the request path: the client travelled to the domain and asked it where to go next. The handle travelled well. The address book stayed home.