Separate publication, access and trust
05Discovery can expose personal information and reader activity. Permission to publish data, browser access to a response and access to a linked resource are separate decisions. A successful query does not authenticate a person or make assertions accurate.
An email From-triggered automatic query is stopped pending user authorization in this example. Separate service-side mitigation is context-dependent, not a fixed RFC-mandated rate quota.
Source for this drawing: RFC 7033 · Read RFC section 9.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Publish only explicitly authorized selections and interpret results within the application’s rules.
- Services exposing personal data MUST provide an interface for users to select exposed elements. They MUST NOT publish personal data through WebFinger without explicit authorization from the person. Earlier sharing in a limited environment is not implied authorization for WebFinger publication.
- Services MUST include Access-Control-Allow-Origin. Public access SHOULD use *. Sensitive intranet services SHOULD NOT use a wildcard and SHOULD restrict allowed origins. Cross-Origin Resource Sharing (CORS) controls browser access to responses; it is not user authentication.
- The endpoint can require authentication and MAY return different information by client/context. A linked resource can need independent authentication. Authentication mechanisms and access policy are outside this RFC’s scope.
- Applications MUST define URI schemes, host resolution when needed, properties and link semantics (§§8.1–8.4). Defined property identifiers and token relation names MUST be registered as specified in §8.6. Valid unknown properties/links SHOULD be ignored (§8.5). HTTPS cannot make false server or user information true (§9.4).
- Abuse mitigation is RECOMMENDED and context-dependent. Rate-limiting is an example, not a mandatory universal quota. The RFC strongly advises clients to query only as authorized by users: automatically querying unique email From values can reveal reader activity (§9.3).
The publication gate is an offline selection model. CORS examples are illustrative. No real personal data, accounts, mail, credentials, reports or privacy settings are used or changed.
Read the RFC section ↗