Redacted Fields in the Registration Data Access Protocol (RDAP) Response
Extracted elements (25)
jCard's heavy reliance on positional arrays (inherited from vCard) necessitates the Redaction by Empty Value Method for required properties like "fn", since removing array elements would produce non-conformant jCard and jCard extensions like JSContact avoid this issue entirely.
JSONPath (RFC 9535) is chosen as the default expression language because RDAP responses are JSON documents and JSONPath provides a standardized way to reference arbitrary JSON fields both before and after redaction, without requiring prior knowledge of the response structure.
The extension distinguishes between "prePath" (referencing the field's location in the pre-redacted response) and "postPath" (referencing the field's location in the redacted response) to handle both cases where the field is absent (removal) and where it remains with a modified value (empty/partial/replacement).
The extension exists to disambiguate between fields absent due to redaction versus fields absent due to lack of data, providing implementers and clients a reliable signal for why data is missing from an RDAP response.
For jCard field redaction using the Redaction by Empty Value Method, servers MUST reference jCard property values at array index 3 and greater (the value positions), not at index 0 (the property name). This allows clients to directly identify which jCard property values have been redacted.
Servers SHOULD use absolute JSONPath expressions beginning with '$' and SHOULD validate "prePath" expressions against the non-redacted response to ensure they resolve to the intended field. RDAP extensions SHOULD define any special JSONPath considerations needed for their redacted fields.
When a server uses the Redaction by Removal or Replacement Value Methods, the JSONPath expression in "prePath" will not resolve successfully against the redacted response. Clients MUST key off the "name" member for display logic rather than attempting to evaluate "prePath" against the response.
When a single entity carries multiple roles that are each independently subject to redaction, servers SHOULD include a separate "redacted" entry for each applicable basis, though at minimum one entry is required. This documents all relevant server policies clearly.
RDAP responses containing redacted fields MUST indicate conformance by including "redacted" in the "rdapConformance" value. Placeholder text such as "XXXX" MUST NOT be used for redaction, as it may not match format requirements of RDAP fields.
The "prePath" member MUST NOT be set when the "postPath" member is set, and vice versa. "postPath" MUST be set when the redacted field still exists in the redacted response (Empty Value, Partial Value, or Replacement Value methods).
The "reason" object's "description" field MUST NOT be used as a client processing dependency; it is human-readable text only.
The "redacted" member MUST be added to the RDAP response when one or more fields are redacted. It MUST appear as a member of the object instance in a lookup response, and as a member of each object instance in a search response.
The Redaction by Empty Value Method MUST be used only when redacting JSON response fields that use position in an array to signal the redacted field (e.g., jCard arrays). Optional jCard properties MUST use the Redaction by Removal Method instead.
The Redaction by Removal Method MUST NOT be used to remove an element of an array where the position of the element determines semantic meaning, such as individual data fields in jCard arrays.
The required jCard "fn" property MUST use the Redaction by Empty Value Method to redact the property value. Removing the "fn" property would violate vCard (RFC 6350), and removing the value would violate fixed jCard array positions.
Servers including redaction signals provide unauthorized clients additional information about the existence of data. Servers MAY omit redacted member entries for fields where the data-existence signal itself constitutes a privacy risk, and MAY publish a redaction policy describing their implementation.
The "method" member specifies one of four redaction methods: "removal" (field removed from response), "emptyValue" (field set to empty/null), "partialValue" (portion of value removed), or "replacementValue" (field replaced with different value). Default is "removal" when not provided.
The "name" member is REQUIRED in each redacted object entry. It uses either a "type" field referencing a registered redacted name from the RDAP JSON Values registry, or a "description" field for an unregistered name.
The "pathLang" member specifies the JSON path expression language, defaulting to "jsonpath" for JSONPath (RFC 9535). Other languages registered in the RDAP JSON Values registry MAY be used based on server policy.
The "redacted" member is a JSON array of objects, each with a required "name" member (logical name of the redacted field) and optional members: "prePath", "postPath", "replacementPath" (JSONPath expressions), "pathLang" (expression language, default "jsonpath"), "method" (redaction method, default "removal"), and "reason" (human-readable explanation).
The Redaction by Replacement Value Method uses a "prePath" referencing the original field position and a "replacementPath" referencing the replacement field. This supports anonymized email addresses or contact-uri redirect properties as privacy-preserving substitutes.
IANA has registered "jsonpath" as a "redacted expression language" value in the RDAP JSON Values registry, referencing JSONPath as defined in RFC 9535.
IANA has registered the "redacted" extension identifier in the "RDAP Extensions" registry. The extension is applicable to any RDAP registry operator and identifies redacted fields in an RDAP response.
The "RDAP JSON Values" registry (Section 10.2 of RFC 9083) is updated to accept three new Type field values: "redacted name" (for predefined logical names of redacted fields), "redacted reason" (for predefined redaction reasons), and "redacted expression language" (for predefined path expression languages).
The redaction extension does not provide any security services beyond those described by RFC 9083. Servers MAY exclude redacted member entries for RDAP fields where even signaling the existence of data would itself be a privacy concern.