WebFinger
Extracted elements (31)
Easy, unauthenticated discovery of user information is a deliberate design goal, not a flaw. Administrators who need to restrict access should use standard web authentication and access-control mechanisms rather than expecting the WebFinger protocol itself to enforce privacy.
The 'subject' value returned by a WebFinger resource MAY differ from the queried 'resource' URI to support identity migration (e.g., a user moves accounts) or canonical URI normalization, enabling persistent queries even when the underlying identity changes.
WebFinger is intentionally limited to static information (e.g., profile links, identity providers) and is not intended for dynamic data such as CPU temperature or toner levels. This scoping keeps the protocol simple and the caching model tractable.
Because support for the 'rel' parameter is not guaranteed, clients MUST NOT assume that the 'links' array contains only the requested link relation types. Clients should filter results themselves after receiving the full JRD.
A client MUST query the WebFinger resource using HTTPS only. If the certificate is invalid, the server returns 4xx/5xx, or the HTTPS connection cannot be established, the client MUST accept failure and MUST NOT reissue the request over HTTP.
A WebFinger resource MUST return a JRD as the default representation. Any redirect MUST only be to an 'https' URI, and the client MUST perform certificate validation again when redirected.
Any simple token used as a link relation type MUST be registered with IANA per RFC 5988 Section 6.2.1. Defined properties MUST be registered in the WebFinger Properties registry.
Clients MUST verify that the certificate used on an HTTPS connection is valid and MUST accept a response only if the certificate is valid.
If the 'resource' parameter is absent or malformed, the server MUST return HTTP 400. If the server has no information for the resource, it MUST return HTTP 404.
Servers MUST include the Access-Control-Allow-Origin HTTP header in WebFinger responses to support CORS. Servers SHOULD support the least restrictive setting ('*') unless serving sensitive data.
Systems exposing personal data via WebFinger MUST provide a user interface through which users can select which data elements are exposed. WebFinger MUST NOT be used to publish personal data without explicit authorization from the person whose data is shared.
The 'rel' member MUST be present in every link relation object and MUST contain exactly one URI or IANA-registered relation type.
The 'subject' member SHOULD be present in the JRD. When processing a JRD, the client MUST ignore any unknown member and not treat unknown members as errors.
WebFinger application specifications MUST define URI scheme(s) used for queries. If the URI scheme has no host portion, the application MUST define host resolution procedures including any default host.
WebFinger resources MUST NOT be served with any URI scheme other than HTTPS. The path component of a WebFinger URI MUST be '/.well-known/webfinger', and the query component MUST include the 'resource' parameter.
WebFinger resources SHOULD support the 'rel' parameter. If not supported, the resource MUST ignore it and process the request as if no 'rel' values were present.
Automatic WebFinger queries by mail clients on incoming message senders could expose the user's IP address, email checking activity, and client identity to spammers. Clients MUST NOT perform WebFinger queries unless explicitly authorized by the user.
WebFinger can be used to cross-correlate a user's accounts across multiple services from a single identifier (e.g., email address). Users should be warned that information published via WebFinger is globally visible and that context data such as location could put them at risk.
A link relation object in the 'links' array may contain: 'rel' (required, URI or registered type), 'type' (optional, media type), 'href' (optional, target URI), 'titles' (optional, language-tagged human-readable strings), and 'properties' (optional, URI-keyed values). The order of the 'links' array MAY indicate preference.
For hosted WebFinger services, when a client queries a domain, the web server MUST return a redirect status code with a Location header pointing to the hosted WebFinger service URI. That URI need not follow the well-known path convention.
The JSON Resource Descriptor (JRD) is a JSON object containing four top-level members: 'subject' (string URI), 'aliases' (array of URI strings), 'properties' (URI-keyed name/value pairs), and 'links' (array of link relation objects). All members except 'subject' are OPTIONAL.
The 'titles' object within a link relation object contains name/value pairs whose names are language tags (per BCP 47) or 'und' for unknown language. A JRD SHOULD NOT include more than one title per language tag within a single link relation object.
This specification establishes the IANA 'WebFinger Properties' registry. Properties are registered with Specification Required review by Designated Experts via [email protected]. The registration template includes Property Identifier (URI), Link Type, Description, Reference, and optional Notes.
This specification registers the 'application/jrd+json' media type with IANA for use with the JSON Resource Descriptor. The file extension is 'jrd'. Implementers must guard against JSON injection when parsing.
This specification registers the 'webfinger' well-known URI suffix in the IANA 'Well-Known URIs' registry (RFC 5785). Queries to this path return a JSON Resource Descriptor (JRD) as described in Section 4.4.
WebFinger applications reuse the IANA 'Link Relation Types' registry established by RFC 5988. Simple token link relation types used by WebFinger applications must be registered there per Section 6.2.1 of RFC 5988.
HTTPS is required for all WebFinger exchanges to prevent modification in transit. A compromised network could substitute an HTTP endpoint for an HTTPS one; clients must never fall back to HTTP under any circumstances.
WebFinger cannot guarantee the accuracy of information provided by users or that information has not been manipulated at the server. HTTPS addresses transit manipulation but not server-side falsification; clients should treat information from untrusted sources with skepticism.
WebFinger servers face abuse potential including email address harvesting for spam, user profiling, and phishing. Rate-limiting by IP address is RECOMMENDED to mitigate harvesting, though mandatory strategies are not prescribed because the appropriate choice depends on context.
The WebFinger query string is constructed by percent-encoding each parameter value (including '=' and '&' within values) and concatenating 'name=value' pairs with '&' separators. The 'resource' parameter carries the query target URI; 'rel' parameters carry link relation types. No spaces are permitted.
The WebFinger request is an HTTPS GET to 'https://{host}/.well-known/webfinger?resource={percent-encoded-URI}[&rel={type}]*'. The media type of the response MUST be 'application/jrd+json'.