rfc-7072

A Reputation Query Protocol

N. Borenstein, M. Kucherawy
date2013-11 streamIETF areaapp wgrepute statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc7072 doi10.17487/RFC7072
This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) using JavaScript Object Notation (JSON) as the payload meta-format.

Extracted elements (21)

design-rationale §3.1

There is no automated discovery protocol for finding reputation services; these are subscription services negotiated between operators out-of-band. This avoids complexity while reflecting the controlled, trust-based nature of reputation relationships.

security

design-rationale §3.3

Using URI templates (RFC 6570) rather than a fixed query URL format allows reputation service providers to extend the query parameter set and gives servers flexibility in their URI structure, while keeping the base parameters (application, service, subject, assertion) standardized.

http

interoperability-note §3.3

Reputation applications can extend the set of optional or required query parameters as part of their IANA registration. Private extensions defined by specific service providers are not registered with IANA and represent bilateral arrangements between client and server.

http, registry

normative-requirement §3.1 MUST

A server receiving a query about an application it does not recognize or explicitly support MUST return a 404 error code.

http, security

normative-requirement §3.5 SHOULD

A server SHOULD include support for providing reputation service over HTTP and publish templates indicating that support, as a baseline for interoperability with arbitrary clients.

http

normative-requirement §3.2 MUST

A template file containing more than one template MUST separate each template with a carriage return (ASCII 0x0D) and newline (ASCII 0x0A) character pair.

http

normative-requirement §3.2 SHOULD NOT

If an Expires field is present in the template response, the client SHOULD NOT send another query to the same server before the indicated timestamp. If no Expires field is present, the client SHOULD wait at least one day before re-querying.

http

normative-requirement §3.4 MUST

If the server includes an HTTP Expires header in its response, that timestamp MUST align with the 'expires' field within the reputon payload. Misalignment can cause a state where the payload has expired but the HTTP reply has not, preventing the client from fetching a fresh answer.

http, json

normative-requirement §3.3 MUST

Service providers crafting URI templates MUST ensure that expansion of optional variables (including empty-string substitution) still produces a syntactically and semantically valid, unambiguous URI.

http

normative-requirement §3.2 MUST

The server's response to the template retrieval request MUST use the text/plain media type and SHOULD include an Expires header field indicating how long clients should consider the template valid.

http

normative-requirement §3.3 MUST

The 'service' variable in the query URI template MUST be the same host to which the template retrieval query was issued, preventing cross-host template redirection.

http, security

protocol-element §3.3

Clients MUST provide three variables when expanding a query template: 'application' (IANA-registered application name, MIME token syntax), 'service' (the hostname or IP of the reputation server), and 'subject' (the entity being evaluated, MIME value syntax).

http

protocol-element §3.4

Reputation query responses are delivered using the 'application/reputon+json' media type as defined in RFC 7071. The response body is a JSON-encoded reputon structure.

http, json

protocol-element §3.2

The client attempts each expanded template in file order, using the first URI scheme it can connect to. This allows a server to offer multiple transport options (e.g., HTTP and HTTPS) in priority order.

http

protocol-element §3.3

The optional 'assertion' variable names the specific reputation assertion requested. If absent, the client requests all available assertion information. A specific application definition may declare this parameter mandatory.

http

protocol-element §1

The reputation query protocol is a two-stage process: (1) a client retrieves a URI template from the reputation server at a well-known location, and (2) the client expands the template and issues an HTTP GET to obtain reputation data.

http, json, security

protocol-element §3.2

The URI template is retrieved by requesting the well-known URI 'repute-template' from the reputation service host using HTTP. The client then expands template variables to form the actual query URI.

http

registry §4

This document registers the 'repute-template' well-known URI in the IANA 'Well-Known URI' registry (RFC 5785). The URI suffix is 'repute-template', the change controller is IETF, and the specification document is RFC 7072.

registry, http

security-consideration §3.3

Authentication between reputation client and server is explicitly outside the scope of this specification and must be provided through separate transport-based or object-based mechanisms.

security, http

security-consideration §5

The template retrieval mechanism uses plain HTTP, which is not secure without extensions. Confidentiality of reputation queries and responses can be achieved by using HTTP over TLS (HTTPS).

security, http, tls

security-consideration §5

Validity and appropriate use of reputation information are security concerns beyond the scope of this specification; implementers should consult RFC 7070 and the operational considerations document for general guidance.

security