A Media Type for Reputation Interchange
Extracted elements (20)
JSON was selected as the meta-format for reputons rather than XML or other alternatives, leading to the definition of the application/reputon+json media type. The JSON syntax is intentionally extensible to allow provider-specific information beyond the standard fields.
The "expires" field is optional rather than mandatory, and caching is not mandated on the client side. However, the document notes obvious operational benefits to caching, and warns that stale ratings can cause desirable traffic to be misidentified as undesirable (or vice versa).
The units of the "sample-size" field are deliberately not normatively specified, because not all reputation service providers collect data the same way. Consumers should assume the count refers to distinct data points rather than aggregations unless out-of-band information specifies otherwise.
Extension attribute names registered for a specific application SHOULD be prefixed with the application name (e.g., the "foo" application registers "foo-bar") to avoid namespace collisions between independently developed application extensions.
Implementers may encounter "application" values, attribute/value pairs, or response set items that they do not support; these are to be ignored. This ensures forward compatibility as new applications and extensions are registered.
A reputon's "rating" value SHOULD NOT have more than three decimal places of precision. The same precision limit applies to "confidence" and "normal-rating" values.
Documents defining specific reputation applications are REQUIRED to define the syntax and semantics of the "rated" field, since the nature of the rated identity is application-specific (e.g., domain names, email addresses, or other unique identifiers).
When a reputon contains an "expires" field, the client SHOULD NOT use the rating after that timestamp and SHOULD issue a new query. Expiration timestamps SHOULD be lower for subjects about which little data has been collected, since reputation data is most volatile for young subjects.
Within a reputon, the fields rater-value, assertion-value, rated-value, and rating-value are REQUIRED. A specific reputon-element MUST NOT appear more than once in a single reputon object.
A "reputon" is a single independent JSON object containing reputation information. A reputation query response may contain one or more reputons. The top-level JSON object carries an "application" member identifying the reputation application context and a "reputons" array of reputon objects.
An empty reputon (one with no assertion data) serves as a positive acknowledgment that the server received the request but has no information for the subject. This is semantically equivalent to returning a reputon with a "sample-size" of zero.
Each reputon MUST contain four required fields: "rater" (DNS domain name of the aggregating entity), "assertion" (keyword for the specific claim), "rated" (identity of the entity being rated, application-specific), and "rating" (floating-point score 0.0–1.0 inclusive).
If a client requests a subject without specifying an assertion, the server may return reputons for any assertion for which it has data. A client that receives an irrelevant reputon simply ignores it.
Optional reputon fields include: "confidence" (0.0–1.0 certainty of the rating), "normal-rating" (expected baseline rating), "sample-size" (unsigned 64-bit integer count of data points), "generated" (Unix timestamp of generation), and "expires" (Unix timestamp after which the score is likely invalid). Applications registered with IANA may define additional extension fields.
The "rating" field represents the overall score as a floating-point number between 0.0 and 1.0. By convention, 1.0 implies full agreement with the assertion while 0.0 indicates no support. Each registered application must define what the anchor values mean and specify the scale type to which all providers for that application must adhere.
IANA has created the "Reputation Applications" registry for symbolic names of reputation applications used with application/reputon+json. Registrations require: symbolic name (MIME token syntax), short description, defining document, status (current/deprecated/historic), subject syntax, assertions with 0.0/1.0 anchor meanings, optional query parameters, and optional response set extension keys. Policy is IETF Review or Specification Required.
IANA has registered the media type "application/reputon+json" for JSON-encoded reputation data. The type takes no required or optional parameters and uses "7bit" encoding. It carries the reputation response set for a specific application context as defined by the Reputation Applications registry.
RFC 7071 is primarily an IANA media type registration action and does not itself introduce new protocol security considerations. Discussion of security and operational impacts of reputation services in general is deferred to the companion document on operational considerations for reputation services.
A reputon is encoded as a JSON object. "rating", "confidence", and "normal-rating" are JSON NUMBERs (floating-point 0.0–1.0). "sample-size" is a non-negative JSON INTEGER (unsigned 64-bit). "generated" and "expires" are non-negative JSON INTEGERs representing seconds since 1970-01-01 00:00 UTC.
The top-level reputation-object is a JSON OBJECT containing exactly two members: "application" (a STRING naming the application context) and "reputons" (an ARRAY of reputon objects). The order of members within a reputon is not significant.