An Architecture for Reputation Reporting
Extracted elements (21)
Identity authentication (e.g., DKIM) proves that a name is being used by its owner but does not assess the quality or trustworthiness of that owner. Reputation services fill this gap by providing assessments of authenticated identifiers, distinguishing good actors from bad.
Mandating a standardized, documented rating scale for each Application enables easier aggregation of ratings from multiple reputation service providers and lets clients change providers without learning new score semantics through out-of-band channels.
The architecture deliberately omits the means by which a reputation agent collects data and computes evaluations, scoping itself only to the query/response mechanism. Collection and aggregation methods are implementation-specific and out of scope.
The query/response model is designed to be transport-agnostic and can be carried over HTTP, DNS, email, or a purpose-built protocol. DNS, while not typically considered a transport, can serve as a generic query/response mechanism as demonstrated by DNS blocklists.
RFC 7071 defines the media type and serialization format for reputons; RFC 7072 specifies the HTTP-based query protocol; RFC 7073 registers the first application (email identifier evaluation). Implementations of this architecture depend on these companion documents.
Application-defining documents must specify the type of rating scale used (e.g., linear), and all reputation service providers for that application space must adhere to it. This allows clients to switch providers without out-of-band coordination about score semantics.
Basic collection and storage of reputation data is inherently a privacy issue because the opinions of one party about another are sensitive. Inadvertent or unauthorized exposure of collected data can lead to personal or commercial damage.
If client credentials used to access a reputation service are compromised, the primary victims are the third parties whose reputation data is improperly revealed — not the client or server. Safeguarding credentials is therefore as important as securing the data itself.
Input data submitted to a reputation service (one party's assessment of another) is often meant to be kept in confidence. Both the collection of raw input data and the storage and output of aggregated results require protection against inadvertent or unauthorized exposure.
Reputation exchanges reveal sensitive information in both directions: the client discloses which subjects it is evaluating, and the server discloses its aggregated assessments of those subjects. DNS-based transports are entirely insecure; services handling sensitive data must use a transport with adequate security.
When a client queries a service about a subject, the service provider can infer the existence of that subject and observe which clients inquire about it over time — an unanticipated side-channel leak of private information about client activity and relationships.
A reputation query MUST carry at minimum: (1) the subject of the query, (2) the name of the reputation Application context, and optionally (3) the name(s) of specific reputation assertions of interest. Additional parameters may be required by specific transports or contexts.
A reputation response MUST include at minimum: the identity of the entity providing the reputation data, the identity of the entity being rated, the application context, and the overall rating score. Arbitrary additional fields may be included per the Application definition.
A 'reputon' is the basic response object returned to a reputation query, containing the serialized Response Set for the queried subject. Its specific encoding is left to documents that implement this architecture (defined in RFC 7071).
A 'Response Set' is the full collection of data returned in response to a reputation query within a given Application. It MUST always contain at least: the name of the entity being rated, the Assertion, and the Rating. Additional fields are Application-specific.
An 'Application' is a formally defined, named context in which reputation queries are made (e.g., email-sending-domain evaluation, movie ratings). Each Application defines its own query parameters and Response Set fields, and is registered with IANA to prevent name collisions.
An 'Assertion' is a claim made about the subject of a reputation query (e.g., 'sends spam'). A 'Rating' is a floating-point value between 0.0 and 1.0 indicating the degree of agreement with the assertion, where 0.0 means no support and 1.0 means total agreement.
The 'Reputation Applications' IANA registry, created by RFC 7071, maps symbolic Application names to their specifying documents. It is used to register Response Sets, query parameters, and associated specification documents to prevent name collisions.
A biased or compromised reputation service can adversely affect clients by rating subjects more or less favorably than warranted, leading to admission of spam/malware or wrongful rejection of legitimate content. Clients should prefer services that disclose their computation methods, and protocols must be designed to resist man-in-the-middle attacks on reputation data.
Both clients and servers of reputation systems must be resistant to malformed messages, deliberate or otherwise. Malformations can be used to confound identification of the party responsible for content under evaluation, potentially enabling delivery of dangerous content.
Relying on a third-party reputation service cedes some control over content handling to that party. Clients must be aware of this trust relationship and its implications; further operational security guidance is deferred to companion documents.