RDAP Simple Redaction

Background This document defines a simple redaction extension for redacting information from Registration Data Access Protocol (RDAP) responses. This extension offers a much simpler approach to the redaction of information than RFC 9537. Additionally, it has several advantages over RFC 9537:

The reasons for a redaction may be specified in multiple languages.
All redactions may be processed by a client programmatically.
String data may be partially redacted.
It re-uses remarks and notices from and is backward-compatible with clients that do no support this extension.
Re-use of remarks and notices enables linking of redacted data to redaction policies.
In most cases, notifications of redacted data is passed to the user with clients that do not support this extension.
Clients are not required to evaluate complicated and error-prone JSONPath expressions.
Usage in RDAP object containers, such as RDAP search results or bulk Whois-like documents, does not require rewriting of JSONPath expressions.

The following is an example of an RDAP response using simple redaction: The methods for noting redactions in this extension cannot redact numbers or booleans in JSON arrays. However, there are no known RDAP data structures either in or any RDAP extension that use arrays containing numbers or booleans. Additionally, there are no known redaction policies that require anything more than redaction of string data.

Redaction Keys Simple redaction allows a server to define a set of keys, each used to signify when data has been redacted. Clients use these keys to notify a user of redacted information.

Redaction of Data in Strings Data found in strings is the most common data type to be redacted. As of this writing, there are no known redaction policies that require the redaction of non-string data.

Unstructured Text Keys signifying redaction for unstructured text, i.e. free form text, take the form of ////REDACTION_KEY////. These keys begin with four forward-slash characters ("////"), followed by one or more of the upper and lower case characters A through Z, 0 through 9, hyphen ("-"), or under-bar ("_"), followed by four more forward-slash characters. The following example demonstrates redaction of the full name value from a jCard () array: These keys may be placed in a string with other characters thus allowing for the partial redaction of a string:

Telephone Numbers Keys for telephone numbers may either be represented as text or "tel" URIs. Both jCard and JSContact allow telephone numbers to be represented in either format.

Telephone Numbers as Text Keys for telephone numbers represented as text use the same format as unstructured text (see ). The following is an example for jCard ().

TEL URIs Keys for use in "tel" URIs () use local numbers with the phone context of "redacted.example". These keys begin with four dash characters ("----"), followed by one or more HEXDIGITs as defined by , followed by four more dash characters. The following is an example of a "tel" URI used in a jCard array: When possible, it is RECOMMENDED to use a text representation as keys for "tel" URIs are more complex.

Email Addresses Keys for email addresses MUST use a host part that is "redacted.invalid" but may use any local part allowable in an email address. For example: redacted_email@redacted.invalid. The ".invalid" TLD is a special-use domain defined in and is unusable on the Internet.

URIs with Host Names Keys used in a URI with host names, such as an HTTP URI, MUST use a host name that is "redacted.invalid". For example: https://redacted.invalid/redacted_web_page. The ".invalid" TLD is a special-use domain defined in and is unusable on the Internet.

Dates and Times Date and times in RDAP use . Keys for these MUST use the year 0000. For example: 0000-00-00T23:20:50.52Z.

Redaction of Other JSON Object Members Signaling of the redaction of other JSON data type is a JSON object use the insertion of the "simpleRedaction_data" member into the object where the data has been redacted by removal. For example, consider an RDAP autnum object: Should policy dictate the redaction of "endAutnum", this could be signaled in the following way: The "simpleRedaction_data" member is an array of objects. Each object contains a "key" string signifying the redaction key and a "members" string array signifying the JSON members associated with the redaction key.

Specifying Keys All redaction keys () are explicitly specified by the server, inside a structure called "simpleRedaction_keys" which is inserted in either an RDAP remark or notice. Keys MUST be specified at least once but MAY be specified more than once. Each "simpleRedaction_keys" object MUST have a member named "keys" which is an array of strings containing the redaction keys . The following is an example: A redaction key MAY appear in more than one remark or notice to allow a server to describe the cause of the redaction in more than one language. The following is an example: A client MUST NOT consider any key not found to be a "simpleRedaction_keys" structure as a valid redaction (i.e. do not signal to the user that the information has been redacted). The "links" array found in remarks and notices, as described by may be used to link to a web page describing the redaction policy. Clients may notify the user of the link, such as through hover-text or pop-ups. The "about" relationship MUST be used for this purpose. The following is an example. This specification allows the use of "simpleRedaction_keys" in both RDAP remarks and notices. In RDAP, remarks are data pertaining to registered objects whereas notices are data pertaining to the response as a whole and the service being provided. Therefore, specifying redaction of data pertaining to registered objects should use RDAP remarks. And, unlikely as it would be, redaction of data pertaining service information should use RDAP notices.

Keying Strategies

Unclean Data While it seems odd that some users would be allowed to give an email address with a host of "redacted.invalid" or a string that begins and ends with four forward-slashes to an Internet registration authority, some registries must deal with such data for various reasons. One strategy servers may use would be to append a set of random characters to each key. For example, if a registered resource was given as "////I-fooled-you////" then the server could thwart this by appending the random characters "1234-NO-YOU-DID-NOT" to make the key "////I-fooled-you_1234-NO-YOU-DID-NOT////".

Handles For servers operating under policies in which the "handle", as defined by must be redacted, it would be beneficial to some clients to create unique redaction keys for each handle. While clients SHOULD use "self" links, as described in , to differentiate between objects returned in a response, in the absence of "self" links they often use the "handle". Therefore, servers SHOULD create a unique redaction key for each handle that is redacted.

Examples

Unstructured Addresses allows for the representation of unstructured postal addresses. The following is a simple example of an RDAP response with simple redactions where the postal address is given as unstructured.

Structured Addresses allows for the representation of structured postal addresses. The following is a simple example of an RDAP response with simple redactions where the postal address is given as structured.

A Complete Example The following is an example an RDAP response to a domain lookup in which the redactions specified in ICANN Registration Data Policy, have been applied.

Security Considerations TBD.

IANA Considerations TBD: registration of "simpleRedaction".