--- 1/draft-ietf-regext-rdap-redacted-07.txt 2022-06-24 11:13:38.828519809 -0700 +++ 2/draft-ietf-regext-rdap-redacted-08.txt 2022-06-24 11:13:38.896521546 -0700 @@ -1,21 +1,21 @@ Network Working Group J.G. Gould Internet-Draft D.S. Smith Intended status: Standards Track VeriSign, Inc. -Expires: 27 November 2022 J.K. Kolker +Expires: 26 December 2022 J.K. Kolker R.C. Carney GoDaddy Inc. - 26 May 2022 + 24 June 2022 Redacted Fields in the Registration Data Access Protocol (RDAP) Response - draft-ietf-regext-rdap-redacted-07 + draft-ietf-regext-rdap-redacted-08 Abstract This document describes an RDAP extension for explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 27 November 2022. + This Internet-Draft will expire on 26 December 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -70,37 +70,38 @@ 10.1. Informative References . . . . . . . . . . . . . . . . . 32 10.2. Normative References . . . . . . . . . . . . . . . . . . 33 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 34 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 34 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 35 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 35 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 35 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 36 A.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 36 A.7. Change from 06 to 07 . . . . . . . . . . . . . . . . . . 36 + A.8. Change from 07 to 08 . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction This document describes an RDAP extension for explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language. A redacted RDAP field is one that has data - removed from the RDAP response due to the lack of client privilege to - receive the field. This extension can be used to identify redacted - RDAP fields in any RDAP object class, as defined in [RFC9083], or - RDAP fields defined in RDAP extensions. Because an RDAP response may - exclude a field due to either the lack of data or based on the lack - of RDAP client privileges, this extension is used to explicitly - specify which RDAP fields are not included in the RDAP response due - to redaction. It thereby provides a capability for disambiguation - between redaction and possible other reasons for data or field - absence. + removed or replaced in the RDAP response due to server policy, such + as the lack of client privilege to receive the field. This extension + can be used to identify redacted RDAP fields in any RDAP object + class, as defined in [RFC9083], or RDAP fields defined in RDAP + extensions. Because an RDAP response may exclude a field due to + either the lack of data or based on the lack of RDAP client + privileges, this extension is used to explicitly specify which RDAP + fields are not included in the RDAP response due to redaction. It + thereby provides a capability for disambiguation between redaction + and possible other reasons for data or field absence. In [RFC9082] RDAP supports both lookup and search queries, where a lookup query responds with a single object and a search query responds with a list of objects. This document applies to redaction of a single object of a lookup response and in each of the objects of a search response. JSONPath, as defined in [I-D.ietf-jsonpath-base], is used as the default expression language to reference RDAP fields that have been redacted. The redacted JSON fields will either be removed or have @@ -135,42 +136,43 @@ arrays. An example is the vCard [RFC6350] "ADR" property / jCard [RFC7095] "adr" property that defines a sequence of address components. According to [RFC6350], when an "ADR" property component value is missing, the associated component separator MUST still be specified. jCard [RFC7095] extends the use of arrays with each individual vCard property being represented by an array of three fixed elements, followed by one or more additional elements. The mix of JSON objects and JSON arrays impacts the methods used for redaction in RDAP. - The redaction of RDAP fields fall into the two categories of - Redaction by Removal Method (Section 3.1) and Redaction by Empty - Value Method (Section 3.2), defined in the following sub-sections. + The redaction of RDAP fields fall into the three categories defined + in the following sub-sections. 3.1. Redaction by Removal Method The Redaction by Removal Method is when the RDAP field is removed from the RDAP response, which is the preferred method. The Redaction by Removal Method can be done for all RDAP response fields other than response fields using the position in an array to signal the redacted field (e.g., the JSON arrays used with jCard [RFC7095]). RDAP extensions such as JSContact in Registration Data Access Protocol (RDAP) JSON Responses [I-D.ietf-regext-rdap-jscontact] do not have a dependency on the use of positional JSON arrays and are therefore suited for the Redaction by Removal Method. When an RDAP object is redacted by removal, all of the RDAP object's child fields are also removed. Only the redacted RDAP object needs to be referenced in the list of redacted fields, as defined in - Section 4.2. An example of redacting an RDAP object is removing the - administrative contact from the RDAP response and including the - following "redacted" member: + Section 4.2. + + An example of redacting an RDAP object is removing the administrative + contact from the RDAP response and including the following "redacted" + member: "redacted": [ { "name": { "type": "Administrative Contact" }, "path": "$.entities[?(@.roles[0]=='administrative')]", "method": "removal" } ] @@ -326,26 +328,26 @@ "rdapConformance": [ "rdap_level_0", "redacted_level_0_3" ] Figure 8: "rdapConformance" with Redacted Extension 4.2. "redacted" Member The "redacted" member MUST be added to the RDAP response when there - are redacted fields. The "redacted" member is included as a member - of the object class in a lookup response, such as the object classes - defined in [RFC9083], and as a member of the object instances in a - search response, such as the object instances defined in [RFC9083]. - The "redacted" member contains an array of redacted objects with the - following child members: + is one or more redacted fields. The "redacted" member is included as + a member of the object class in a lookup response, such as the object + classes defined in [RFC9083], and as a member of the object instances + in a search response, such as the object instances defined in + [RFC9083]. The "redacted" member contains an array of redacted + objects with the following child members: "name": A logical name for the redacted field. The logical name used for the redacted field is up to server policy. The logical name is defined using an object with a "type" field denoting a registered redacted name (see Section 6.2) or a "description" field denoting an unregistered redacted name. The registered redacted names and the chosen unregistered names can meet the needs of different RDAP services or industries. "path": The JSON expression references a removed JSON field in the @@ -359,26 +361,33 @@ "replacementPath": OPTIONAL JSON expression of the replacement field of the redacted field with the Redaction by Replacement Value Method (Section 3.3), using the expression language defined by the "pathLang" member. "pathLang": OPTIONAL JSON path expression language used, with the default value of "jsonpath" for JSONPath ([I-D.ietf-jsonpath-base]). Other JSON path expression languages MAY be used based on server policy. - "method": OPTIONAL redaction method used with "removal" indicating - the Redaction By Removal Method (Section 3.1), "emptyValue" - indicating the Redaction by Empty Value Method (Section 3.2), and - "replacementValue" indicating the Redaction by Replacement Value - Method (Section 3.3). The default value is "removal" when not - provided. + "method": OPTIONAL redaction method used; with one of the following + values: + + * "removal" indicating the Redaction By Removal Method + (Section 3.1), + + * "emptyValue" indicating the Redaction by Empty Value Method + (Section 3.2), or + + * "replacementValue" indicating the Redaction by Replacement + Value Method. (Section 3.3) + + The default value is "removal" when not provided. "reason": OPTIONAL human readable reason(s) for the redacted field in the language defined by the [RFC9083] "lang" member. The default language is "en" if the [RFC9083] "lang" member is not specified. The reason is defined using an object with an OPTIONAL "type" field denoting a registered redacted reason (see see Section 6.2) and an OPTIONAL "description" field denoting an unregistered redacted reason. The "description" field MUST NOT be a client processing dependency. @@ -1645,22 +1656,35 @@ 1. Fixed a couple nits. 2. Updated the Redaction by Replacement Value Method email web form examples to use the "contact-uri" jCard property of RFC 8605. A.7. Change from 06 to 07 1. Added the optional replacementPath child member for use with the Redaction by Replacement Value Method. -Authors' Addresses +A.8. Change from 07 to 08 + + 1. Updates based on the Rick Wilhelm feedback: + 1. Updated the definition of a redacted RDAP field in the + Introduction section. + 2. Updated the reference to three methods instead of two in the + Redaction Methods section. + 3. Created a new paragraph for the example in the Redaction by + Removal Method section. + 4. Explicity specified one or more redacted fields for inclusion + of the "redacted" member in the "redacted" Member section. + 5. Updated the description of the "method" member in the + "redacted" Member section. +Authors' Addresses James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 United States of America Email: jgould@verisign.com URI: http://www.verisigninc.com David Smith VeriSign, Inc.