RDAP Simple Redaction

Background This document defines "simple redaction", an extension for redacting information from Registration Data Access Protocol (RDAP) response. Simple redaction only defines redaction in JSON strings of RDAP responses. This narrowed scope meets the purposes of known redaction policies, such as the ICANN Registration Data Policy, where redaction is applied against "personal data" which is only found in JSON strings in the RDAP specification (). The only place in RDAP where booleans or integers are used in the base specification of are in the DNSSEC portion of the domain object class, and there is unlikely to be policy for redaction of such information as it also visible in the public DNS. This specification does not require the removal of JSON values or components that would otherwise make the resulting JSON invalid according to nor syntactically invalid according to or . Therefore, the resulting responses are syntactically valid but semantically redacted. Finally, this specification has the benefit that if an RDAP client does not recognize this extension and simply passes the redaction signals onto the user, in some contexts the user may still understand that the information is redacted. The following is an example of an RDAP response using simple redaction:

Redaction Keys Simple redaction allows a server to define a set of keys, each used to signify when data in a string has been redacted. Clients use these keys to identify the information being redacted.

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 character ("////"), 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:

TEL URIs Keys for use in "tel" URIs () follow a form similar to but with a restricted set of characters to conform to the "tel" URI syntax. These keys begin and end with four forward-slash characters, but the set of characters allowed between the slashes is limited to 0 through 9. For example: ////0123456789////. The following is an example of a "tel" URI used in a jCard array: The above is just an example, but , which defines the structures in , does not require the "tel" property to be a URI. So this maybe written as:

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.

Explicit Keying All redaction keys () are explicitly specified by the server.

The "simpleRedaction" Array Each defined key MUST be given in the "simpleRedaction" array value. This array contains JSON objects. Each JSON object has a REQUIRED JSON string named "key", a JSON array named "reasons", and an OPTIONAL "links" array as defined by (see and on usage). The "reasons" array is OPTIONAL but if present MUST NOT be empty. The "reasons" array contains JSON objects. These objects SHOULD have a "lang" member as defined by and MUST have a JSON array named "description". The "description" array contains only JSON strings. The following is an example: A key MAY be used more than once in an RDAP object, but it MUST only appear once in the "simpleRedaction" array of objects. A client MUST NOT consider any key not found to be the "simpleRedaction" array of objects as a valid redaction (i.e. do not signal to the user that the information has been redacted). The "simpleRedaction" JSON value MUST only be in the top-most object of the RDAP response.

Alternates The "simpleRedaction" array described in allows each key to be accompanied by an array of links, as defined by . Usage of the links may be used to signal an alternate usage in cases where the alternate can be expressed as a URI. To do this, servers MUST use the "alternate" link relation and clients SHOULD signal to users that the "href" value is available for alternate usage. The following example demonstrates the signaling on a web-based contact form to be used instead of email. This example demonstrates signaling that an alternate email address is to be used. Clients should consider, when presenting information to a user, that an alternate use may differ from the form in the RDAP response. For example, the RDAP response may contain an email address but the alternate usage is a web page.

Redaction Policy The "links" array described in may also be used to link to a web page describing the redaction policy. When the array is to be used for this purpose, the "about" relationship MUST be used. The following is an example.

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 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".