Summary

  • RFC 9537 lets an RDAP server identify a field it redacted, the method used and a path associated with the pre- or post-redaction shape. That narrows an ambiguity in the delivered response; it does not reveal or independently verify the protected value.
  • A reason is optional, policy content is outside the RFC, and a server may suppress the redaction signal when even acknowledging a field would leak information. A sound audit therefore preserves the query, server, access class, raw response, time, path evaluation and policy version as separate receipts.

One blank, several histories

Consider two domain lookups that both omit a registrant phone number. In the first record, nobody supplied a phone number. In the second, the registry holds one but the public client is not entitled to see it. The JSON delivered to a reader can look equally blank while the histories behind it are materially different.

That ambiguity matters to more than interface design. A researcher measuring registration-data completeness could count both as missing. An investigator could assume the second value never existed. A compliance system could treat silence as proof that no restriction was applied. Each conclusion adds a fact that the response did not contain.

RFC 9537, published in March 2024, addresses this narrow problem. It defines a redacted member for RDAP objects so a server can identify fields it has removed, emptied, partially concealed or replaced. The document is authored by James Gould, David Smith, Jody Kolker and Roger Carney. Gould’s IETF record, captured for this article on 7 September 2026, lists thirteen RFCs across registration protocols. The Registration Operations Workshop describes him as a Verisign fellow responsible for architectural and technical direction in domain-registry services. Those facts locate the work in a long registration-protocol practice; they do not make Gould the sole inventor or the guarantor of anyone else’s deployment.

The design’s strength lies in its restraint. It gives a server a structured vocabulary for one assertion about its output. It does not claim to settle the surrounding policy dispute.

What the redacted member can say

A response using the extension advertises redacted in rdapConformance. When an object contains one or more redacted fields, it normally includes an array of redaction descriptions. Each description has a required logical name, supplied either as a registered type or as unregistered descriptive text.

Paths connect that name to a response shape. A prePath can point to the location a field occupied before removal; by definition it may not resolve in the JSON the client received. A postPath points to a surviving empty, partial or replacement value. The two are mutually exclusive. When another field carries a substitute, replacementPath can locate it. JSONPath is the default expression language, which gives clients a shared syntax without pretending that a human label is a permanent schema coordinate.

This is useful evidence. The server is no longer forcing a client to infer redaction merely from a hole. The client can record that the server named a field, selected a method and associated it with a path. IANA’s RDAP registries make common extension identifiers, names, reasons and path-language values reusable across implementations.

But the assertion remains bounded. A prePath does not carry the bytes that were there. A logical name does not prove that the underlying record was accurate. A method does not prove that the right access rule was chosen. Even an authenticated response proves only what the responding service asserted under that connection and access context. It is not a notarized copy of the concealed database row.

Four methods leave four different residues

RFC 9537 distinguishes four redaction methods because “not visible” is not a single JSON state.

Removal deletes a field or object from the delivered response. It is the default method if method is absent, except where removing one position would corrupt an array whose positions carry meaning. For positional jCard data, an empty value can preserve the array while replacing the protected slot with an empty string or null. Partial-value redaction leaves a formatted remainder, such as part of an address label. Replacement-value redaction substitutes another value or another field, such as an anonymized email or a contact form.

Those residues should not be flattened in evidence systems. A removed object cannot be tested in the same way as a surviving empty position. A partial address still discloses something. A contact URI may preserve reachability without revealing the original mailbox, but it is not the registrant’s email address. RFC 9537 also rejects repeated-letter filler as a redaction technique because arbitrary text may violate the field format and create an unreliable signal.

The practical test is simple: record what the client actually received, not what a screen chose to display. A user interface may render all four cases as “redacted.” An audit needs the method, path and raw response shape that justify that label.

A reason is not a policy verdict

Each redaction description may carry a reason. That reason can use a registered type or free descriptive text. Yet the description is explicitly not allowed to become a processing dependency. This is a warning against building consequential automation on phrases written for people.

The same separation applies to policy. A server may publish a redaction policy, but RFC 9537 leaves its content outside the specification. The RFC does not determine which client should receive a phone number, whether consent is valid, how a court order applies, or whether a particular disclosure is contractually required. RFC 7481 supplies authentication and tiered-access mechanisms under local authorization policy; it does not make one universal access policy part of RDAP.

ICANN’s 2024 gTLD response profile shows how a constituency can add a more specific layer. It maps named registration-data elements to RFC 9537 techniques and requires particular treatment for fields such as email. That profile is important operational evidence for services within its scope. It is not the base extension, and it cannot be projected onto every registry, registrar or regional Internet registry.

There is a further asymmetry. Merely saying “a registrant field exists but is hidden” can itself reveal information. RFC 9537 therefore permits a server to omit redaction entries when the existence signal raises a privacy issue. Silence is not the inverse of redaction. A response without a marker might be complete, might come from a server that does not implement the extension, or might deliberately avoid acknowledging a protected field. The reader needs more evidence before choosing among those explanations.

The receipt an operator should keep

The smallest useful audit record begins before the response body. Preserve the exact lookup or search URI, the authoritative server and any redirects, the retrieval time, the transport identity, and the client’s authentication and authorization class. A public anonymous query and a privileged authenticated query are different observations even when they ask for the same domain.

Then preserve the raw response bytes or a verifiable hash. Extract rdapConformance, the RDAP record identifier, and every redaction entry’s name, path language, path, method and reason. Record whether a postPath resolved against the received object and how a prePath was interpreted, since the latter describes a shape no longer present. Keep the decoder and JSONPath implementation version; a path-evaluation change can otherwise masquerade as a server change.

If the response links to a policy, record the exact URL and version observed at that time. A later policy page is not automatically evidence of the rule applied to an earlier response. When comparing two views, bind each to its access class and timestamp rather than subtracting anonymous JSON documents and calling the difference a disclosure decision.

RFC 9082’s distinction between lookup and search also belongs in the receipt. RFC 9537 attaches redaction descriptions to the single object in a lookup and to individual objects within search results. A top-level search truncation is not interchangeable with a field removed from one result. RFC 9083’s notices and remarks can explain response-wide or object-level conditions, but they do not replace the per-field structured signal.

The resulting bundle supports a modest conclusion: this server, for this query and access context, described this field as redacted in this way. Any stronger statement requires the next receipt—policy authority, source-record integrity, client entitlement, or disclosure review.

Sources