1 Internet Engineering Task Force (IETF) J. Gould
2 Request for Comments: 9537 D. Smith
3 Category: Standards Track VeriSign, Inc.
4 ISSN: 2070-1721 J. Kolker
5 R. Carney
6 GoDaddy Inc.
7 March 2024
8
9
10 Redacted Fields in the Registration Data Access Protocol (RDAP) Response
11
12 Abstract
13
14 This document describes a Registration Data Access Protocol (RDAP)
15 extension for specifying methods of redaction of RDAP responses and
16 explicitly identifying redacted RDAP response fields, using JSONPath
17 as the default expression language.
18
19 Status of This Memo
20
21 This is an Internet Standards Track document.
22
23 This document is a product of the Internet Engineering Task Force
24 (IETF). It represents the consensus of the IETF community. It has
25 received public review and has been approved for publication by the
26 Internet Engineering Steering Group (IESG). Further information on
27 Internet Standards is available in Section 2 of RFC 7841.
28
29 Information about the current status of this document, any errata,
30 and how to provide feedback on it may be obtained at
31 https://www.rfc-editor.org/info/rfc9537.
32
33 Copyright Notice
34
35 Copyright (c) 2024 IETF Trust and the persons identified as the
36 document authors. All rights reserved.
37
38 This document is subject to BCP 78 and the IETF Trust's Legal
39 Provisions Relating to IETF Documents
40 (https://trustee.ietf.org/license-info) in effect on the date of
41 publication of this document. Please review these documents
42 carefully, as they describe your rights and restrictions with respect
43 to this document. Code Components extracted from this document must
44 include Revised BSD License text as described in Section 4.e of the
45 Trust Legal Provisions and are provided without warranty as described
46 in the Revised BSD License.
47
48 Table of Contents
49
50 1. Introduction
51 2. Conventions Used in This Document
52 3. Redaction Methods
53 3.1. Redaction by Removal Method
54 3.2. Redaction by Empty Value Method
55 3.3. Redaction by Partial Value Method
56 3.4. Redaction by Replacement Value Method
57 4. Redacted RDAP Response
58 4.1. RDAP Conformance
59 4.2. "redacted" Member
60 5. JSONPath Considerations
61 5.1. JSONPath Client Considerations
62 5.2. JSONPath Server Considerations
63 6. IANA Considerations
64 6.1. RDAP Extensions Registry
65 6.2. RDAP JSON Values Registry
66 7. Security Considerations
67 8. References
68 8.1. Normative References
69 8.2. Informative References
70 Acknowledgements
71 Authors' Addresses
72
73 1. Introduction
74
75 This document describes an RDAP extension for specifying methods of
76 redaction of RDAP responses and explicitly identifying redacted RDAP
77 response fields, using JSONPath as the default expression language.
78 A redacted RDAP field is one that has data removed or replaced in the
79 RDAP response due to server policy, such as the lack of client
80 privilege to receive the field. This extension can be used to
81 identify redacted RDAP fields in any RDAP object class, as defined in
82 [RFC9083], or RDAP fields defined in RDAP extensions. Because an
83 RDAP response may exclude a field due to either the lack of data or
84 the lack of RDAP client privileges, this extension is used to
85 explicitly specify which RDAP fields are not included in the RDAP
86 response due to redaction. It thereby provides a capability for
87 disambiguation between redaction and other possible reasons for data
88 or field absence.
89
90 In [RFC9082], RDAP supports both lookup and search queries, where a
91 lookup query responds with a single object and a search query
92 responds with a list of objects. This document applies to redaction
93 of a single object of a lookup response and in each of the objects of
94 a search response.
95
96 JSONPath, as defined in [RFC9535], is used as the default expression
97 language to reference RDAP fields that have been redacted. The
98 redacted JSON fields will be removed, have empty values, have partial
99 values, or be replaced in the RDAP response. JSON is defined by
100 [RFC8259].
101
102 2. Conventions Used in This Document
103
104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
106 "OPTIONAL" in this document are to be interpreted as described in
107 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
108 capitals, as shown here.
109
110 The JSON examples include extra line breaks and empty space. For
111 instance, the JSONPath expressions are broken out into multiple lines
112 when required for illustration.
113
114 The JSONPath expressions in the examples are for illustration
115 purposes with single-role entities, and the exact expressions to be
116 used by the server are out of scope.
117
118 3. Redaction Methods
119
120 Redaction in RDAP can be handled in multiple ways. The resulting
121 redacted RDAP response MUST comply with the format defined in the
122 RDAP RFCs, such as [RFC9083] and updates. The use of placeholder
123 text for the values of the RDAP fields, such as "XXXX", MUST NOT be
124 used for redaction, since the placeholder text value may not match
125 the format requirements of each of the RDAP fields, which could
126 provide an inconsistent and unreliable redaction signal. This
127 section covers the redaction methods that can be used with the
128 redaction signaling defined in Section 4.2.
129
130 RDAP responses, as defined in [RFC9083], include a mix of JSON
131 objects and JSON arrays, where JSON arrays are heavily used for
132 entity objects with jCard [RFC7095]. jCard is a JSON representation
133 of vCard [RFC6350] that inherits its dependency on arrays. An
134 example is the vCard "ADR" property [RFC6350], or the jCard "adr"
135 property [RFC7095], which defines a sequence of address components.
136 According to [RFC6350], when an "ADR" property component value is
137 missing, the associated component separator MUST still be specified.
138 jCard extends the use of arrays with each individual vCard property
139 being represented by an array of three fixed elements, followed by
140 one or more additional elements. The mix of JSON objects and JSON
141 arrays impacts the methods used for redaction in RDAP.
142
143 The redaction of RDAP fields fall into the four categories defined in
144 the following subsections.
145
146 3.1. Redaction by Removal Method
147
148 The Redaction by Removal Method is when the RDAP field is removed
149 from the RDAP response, which is the default method. The Redaction
150 by Removal Method can be done for all RDAP response fields except for
151 response fields using the position in an array to signal the redacted
152 field (e.g., the JSON arrays used with jCard). RDAP extensions, such
153 as the one described in "Using JSContact in Registration Data Access
154 Protocol (RDAP) JSON Responses" [RDAP-JSCONTACT], do not have a
155 dependency on the use of positional JSON arrays and are therefore
156 suited for the Redaction by Removal Method.
157
158 When an RDAP object is redacted by removal, all of the RDAP object's
159 child fields are also removed. Only the redacted RDAP object needs
160 to be referenced in the list of redacted fields, as defined in
161 Section 4.2.
162
163 An example of redacting an RDAP object is removing the administrative
164 contact from the RDAP response and including the following "redacted"
165 member:
166
167 "redacted": [
168 {
169 "name": {
170 "description": "Administrative Contact"
171 },
172 "prePath": "$.entities[?(@.roles[0]=='administrative')]",
173 "method": "removal"
174 }
175 ]
176
177 Figure 1: Redacted Administrative Contact
178
179 The Redaction by Removal Method MUST NOT be used to remove an element
180 of an array where the position of the element in the array determines
181 semantic meaning. For example, removal of an individual data field
182 in jCard will result in a non-conformant jCard array definition.
183
184 3.2. Redaction by Empty Value Method
185
186 The Redaction by Empty Value Method is when a redacted field is not
187 removed but its value is set to an empty value, such as "" for a
188 jCard text ("text") property or null for a non-text property. The
189 empty jCard values ("" or null) are referenced in the "redacted"
190 member in place of the jCard property name in an array, such as
191 referencing the "fn" jCard property value at position 3 instead of
192 referencing the "fn" jCard property name at position 0. The
193 Redaction by Empty Value Method MUST be used only when redacting JSON
194 response fields that use the position in an array to signal the
195 redacted field (e.g., jCard arrays). Optional jCard properties MUST
196 use the Redaction by Removal Method (Section 3.1) to redact the
197 entire property. The required jCard "fn" property, defined in
198 Section 6.2.1 of vCard [RFC6350], MUST use the Redaction by Empty
199 Value Method to redact the property value. Removing the "fn"
200 property would violate vCard [RFC6350], and removing the property
201 value would violate the fixed array positions defined in jCard.
202
203 [
204 "fn",
205 {},
206 "text",
207 ""
208 ]
209
210 Figure 2: Redacted "fn" jCard Property Using the Redaction by
211 Empty Value Method
212
213 An example of the "redacted" member for the redacted "fn" jCard
214 property value, which is array position 3:
215
216 "redacted": [
217 {
218 "name": {
219 "description": "Registrant Name"
220 },
221 "postPath": "$.entities[?(@.roles[0]=='registrant')].
222 vcardArray[1][?(@[0]=='fn')][3]",
223 "pathLang": "jsonpath",
224 "method": "emptyValue",
225 "reason": {
226 "description": "Server policy"
227 }
228 }
229 ]
230
231 Figure 3: Redacted Registrant Name Using an Array Position
232
233 3.3. Redaction by Partial Value Method
234
235 The Redaction by Partial Value Method is when a redacted field is not
236 removed but its value has a portion of the data removed, such as for
237 the "label" or "fn" jCard properties. The partial values are
238 referenced in the "redacted" member in place of the property name in
239 an array, such as referencing the "fn" jCard property value at
240 position 3 instead of referencing the "fn" jCard property name at
241 position 0. The Redaction by Partial Value Method SHOULD be used
242 only when redacting JSON response fields that use a formatted value,
243 where a portion of the value is removed.
244
245 An example of the "label" jCard property in Section 3.3.1.3 of
246 [RFC7095] that redacts "123 Maple Ave\nSuite 901\n":
247
248 ["adr",
249 {
250 "type":"home",
251 "label":"Vancouver\nBC\n1239\n"
252 },
253 "text",
254 [
255 "", "", "", "", "", "", ""
256 ]
257 ]
258
259 Figure 4: Redacted "label" jCard Property
260
261 An example of the "redacted" member for the redacted "label" jCard
262 property value, based on Section 3.3.1.3 of [RFC7095]:
263
264 "redacted": [
265 {
266 "name": {
267 "description": "Home Address Label"
268 },
269 "postPath": "$.vcardArray[1][?(@[0]=='adr')][1].label",
270 "pathLang": "jsonpath",
271 "method": "partialValue",
272 "reason": {
273 "description": "Server policy"
274 }
275 }
276 ]
277
278 Figure 5: Redacted Label Using the Redaction by Partial Value Method
279
280 3.4. Redaction by Replacement Value Method
281
282 The Redaction by Replacement Value Method is when a redacted field is
283 not removed but its value is replaced with a different value, such as
284 protecting the "email" jCard property value with an anonymized email
285 "text" value or the use of an alternative "uri" value to a web form.
286 Replacing a property value is a form of redaction, since it protects
287 the true property value for privacy reasons.
288
289 [
290 "email",
291 {},
292 "text",
293 "anonymized123@example.com"
294 ]
295
296 Figure 6: Redacted "email" jCard Property Using the Redaction by
297 Replacement Value Method with an Anonymized Email
298
299 "redacted": [
300 {
301 "name": {
302 "description": "Registrant Email"
303 },
304 "postPath": "$.entities[?(@.roles[0]=='registrant')].
305 vcardArray[1][?(@[0]=='email')][3]",
306 "pathLang": "jsonpath",
307 "method": "replacementValue",
308 }
309 ]
310
311 Figure 7: Redacted Email Using a Replacement Value with an
312 Anonymized "text" Value
313
314 [
315 "contact-uri",
316 {},
317 "uri",
318 "https://email.example.com/123"
319 ]
320
321 Figure 8: Redacted "email" jCard Property Using the Redaction by
322 Replacement Value Method with a "contact-uri" jCard Property to a
323 Web Form
324
325 "redacted": [
326 {
327 "name": {
328 "description": "Registrant Email"
329 },
330 "prePath": "$.entities[?(@.roles[0]=='registrant')].
331 vcardArray[1][?(@[0]=='email')]",
332 "replacementPath": "$.entities[?(@.roles[0]=='registrant')].
333 vcardArray[1][?(@[0]=='contact-uri')]",
334 "pathLang": "jsonpath",
335 "method": "replacementValue",
336 }
337 ]
338
339 Figure 9: Redacted Email Using a Replacement Value with a
340 "contact-uri" jCard Property to a Web Form
341
342 4. Redacted RDAP Response
343
344 4.1. RDAP Conformance
345
346 RDAP responses that contain values described in this document MUST
347 indicate conformance with this specification by including an
348 "rdapConformance" [RFC9083] value of "redacted". The "redacted"
349 extension identifier is described in Section 6.1.
350
351 "rdapConformance": [
352 "rdap_level_0",
353 "redacted"
354 ]
355
356 Figure 10: "rdapConformance" with Redacted Extension
357
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
358 4.2. "redacted" Member
359
360 The "redacted" member MUST be added to the RDAP response when there
361 is one or more redacted fields. The "redacted" member is included as
362 a member of the object instance in a lookup response, such as the
363 object classes defined in [RFC9083], and as a member of the object
364 instances in a search response.
365
366 The server, including a redacted signal, provides an unauthorized
367 client additional information related to the existence of data and
368 MAY exclude the redacted members for RDAP fields that are considered
369 a privacy issue in providing a data existence signal. The server MAY
370 choose to publish a redaction policy describing how this extension is
371 implemented for their constituency. The contents of such a policy
372 are outside the scope of this specification.
373
374 The "redacted" member contains an array of objects with the following
375 child members:
376
377 "name": REQUIRED logical name for the redacted field. The logical
378 name used for the redacted field is up to server policy. The
379 logical name is defined using an object with a "type" field
380 denoting a registered redacted name (see Section 6.2) or a
381 "description" field denoting an unregistered redacted name. The
382 registered redacted names and the chosen unregistered names can
383 meet the needs of different RDAP services or industries.
384
385 "prePath": OPTIONAL JSON path expression referencing a redacted JSON
386 field in the pre-redacted response, using the expression language
387 defined by the "pathLang" member. The "prePath" member MAY be
388 set when the redacted field does not exist in the redacted
389 response for the Redaction by Removal Method (Section 3.1) and
390 the Redaction by Replacement Value Method (Section 3.4). The
391 "prePath" member MUST NOT be set when the "postPath" member is
392 set.
393
394 "postPath": OPTIONAL JSON path expression referencing a redacted
395 JSON field in the redacted (post-redacted) response, using the
396 expression language defined by the "pathLang" member. The
397 "postPath" member MUST be set when the redacted field does exist
398 in the redacted response for the Redaction by Empty Value Method
399 (Section 3.2), the Redaction by Partial Value Method
400 (Section 3.3), and the Redaction by Replacement Value Method
401 (Section 3.4). The "postPath" member MUST NOT be set when the
402 "prePath" member is set.
403
404 "replacementPath": OPTIONAL JSON path expression of the replacement
405 field of the redacted field with the Redaction by Replacement
406 Value Method (Section 3.4), using the expression language defined
407 by the "pathLang" member.
408
409 "pathLang": OPTIONAL JSON path expression language used, with the
410 default value of "jsonpath" for JSONPath [RFC9535]. Other JSON
411 path expression languages registered with the "redacted
412 expression language" Type in the "RDAP JSON Values" registry MAY
413 be used based on server policy.
414
415 "method": OPTIONAL redaction method used, with one of the following
416 values:
417
418 * "removal" indicating the Redaction by Removal Method
419 (Section 3.1),
420
421 * "emptyValue" indicating the Redaction by Empty Value Method
422 (Section 3.2),
423
424 * "partialValue" indicating the Redaction by Partial Value
425 Method (Section 3.3), or
426
427 * "replacementValue" indicating the Redaction by Replacement
428 Value Method (Section 3.4).
429
430 The default value is "removal" when not provided.
431
432 "reason": OPTIONAL human-readable reason(s) for the redacted field
433 in the language defined by the "lang" [RFC9083] member. The
434 default language is "en" if the "lang" [RFC9083] member is not
435 specified. The reason is defined using an object with an
436 OPTIONAL "type" field denoting a registered redacted reason (see
437 Section 6.2) and an OPTIONAL "description" field denoting an
438 unregistered redacted reason. The "description" field MUST NOT
439 be a client processing dependency.
440
441 Example of the unredacted version of an RDAP lookup response:
442
443 {
444 "rdapConformance": [
445 "rdap_level_0"
446 ],
447 "objectClassName": "domain",
448 "handle": "ABC123",
449 "ldhName": "example.com",
450 "secureDNS": {
451 "delegationSigned": false
452 },
453 "notices": [
454 {
455 "title": "Terms of Use",
456 "description": [
457 "Service subject to Terms of Use."
458 ],
459 "links": [
460 {
461 "rel": "self",
462 "href": "https://www.example.com/terms-of-use",
463 "type": "text/html",
464 "value": "https://www.example.com/terms-of-use"
465 }
466 ]
467 }
468 ],
469 "nameservers": [
470 {
471 "objectClassName": "nameserver",
472 "ldhName": "ns1.example.com"
473 },
474 {
475 "objectClassName": "nameserver",
476 "ldhName": "ns2.example.com"
477 }
478 ],
479 "entities": [
480 {
481 "objectClassName": "entity",
482 "handle": "123",
483 "roles": [
484 "registrar"
485 ],
486 "publicIds": [
487 {
488 "type": "IANA Registrar ID",
489 "identifier": "1"
490 }
491 ],
492 "vcardArray": [
493 "vcard",
494 [
495 [
496 "version",
497 {},
498 "text",
499 "4.0"
500 ],
501 [
502 "fn",
503 {},
504 "text",
505 "Example Registrar Inc."
506 ],
507 [
508 "adr",
509 {},
510 "text",
511 [
512 "",
513 "Suite 100",
514 "123 Example Dr.",
515 "Dulles",
516 "VA",
517 "20166-6503",
518 "US"
519 ]
520 ],
521 [
522 "email",
523 {},
524 "text",
525 "contact@organization.example"
526 ],
527 [
528 "tel",
529 {
530 "type": "voice"
531 },
532 "uri",
533 "tel:+1.7035555555;ext=1234"
534 ],
535 [
536 "tel",
537 {
538 "type": "fax"
539 },
540 "uri",
541 "tel:+1.7035555556"
542 ]
543 ]
544 ],
545 "entities": [
546 {
547 "objectClassName": "entity",
548 "roles": [
549 "abuse"
550 ],
551 "vcardArray": [
552 "vcard",
553 [
554 [
555 "version",
556 {},
557 "text",
558 "4.0"
559 ],
560 [
561 "fn",
562 {},
563 "text",
564 "Abuse Contact"
565 ],
566 [
567 "email",
568 {},
569 "text",
570 "abuse@organization.example"
571 ],
572 [
573 "tel",
574 {
575 "type": "voice"
576 },
577 "uri",
578 "tel:+1.7035555555;ext=1234"
579 ]
580 ]
581 ]
582 }
583 ]
584 },
585 {
586 "objectClassName": "entity",
587 "handle": "XXXX",
588 "roles": [
589 "registrant"
590 ],
591 "vcardArray": [
592 "vcard",
593 [
594 [
595 "version",
596 {},
597 "text",
598 "4.0"
599 ],
600 [
601 "fn",
602 {},
603 "text",
604 "Registrant User"
605 ],
606 [
607 "org",
608 {},
609 "text",
610 "Example Inc."
611 ],
612 [
613 "adr",
614 {},
615 "text",
616 [
617 "",
618 "Suite 1235",
619 "4321 Rue Somewhere",
620 "Quebec",
621 "QC",
622 "G1V 2M2",
623 "Canada"
624 ]
625 ],
626 [
627 "email",
628 {},
629 "text",
630 "registrant.user@example.com"
631 ],
632 [
633 "tel",
634 {
635 "type": "voice"
636 },
637 "uri",
638 "tel:+1-555-555-1235;ext=123"
639 ],
640 [
641 "tel",
642 {
643 "type": "fax"
644 },
645 "uri",
646 "tel:+1-555-555-5321"
647 ]
648 ]
649 ]
650 },
651 {
652 "objectClassName": "entity",
653 "handle": "YYYY",
654 "roles": [
655 "technical"
656 ],
657 "vcardArray": [
658 "vcard",
659 [
660 [
661 "version",
662 {},
663 "text",
664 "4.0"
665 ],
666 [
667 "fn",
668 {},
669 "text",
670 "Technical User"
671 ],
672 [
673 "org",
674 {},
675 "text",
676 "Example Inc."
677 ],
678 [
679 "adr",
680 {},
681 "text",
682 [
683 "",
684 "Suite 1234",
685 "4321 Rue Somewhere",
686 "Quebec",
687 "QC",
688 "G1V 2M2",
689 "Canada"
690 ]
691 ],
692 [
693 "email",
694 {},
695 "text",
696 "technical.user@example.com"
697 ],
698 [
699 "tel",
700 {
701 "type": "voice"
702 },
703 "uri",
704 "tel:+1-555-555-1234;ext=321"
705 ],
706 [
707 "tel",
708 {
709 "type": "fax"
710 },
711 "uri",
712 "tel:+1-555-555-4321"
713 ]
714 ]
715 ]
716 },
717 {
718 "objectClassName": "entity",
719 "handle": "ZZZZ",
720 "roles": [
721 "administrative"
722 ],
723 "vcardArray": [
724 "vcard",
725 [
726 [
727 "version",
728 {},
729 "text",
730 "4.0"
731 ],
732 [
733 "fn",
734 {},
735 "text",
736 "Administrative User"
737 ],
738 [
739 "org",
740 {},
741 "text",
742 "Example Inc."
743 ],
744 [
745 "adr",
746 {},
747 "text",
748 [
749 "",
750 "Suite 1236",
751 "4321 Rue Somewhere",
752 "Quebec",
753 "QC",
754 "G1V 2M2",
755 "Canada"
756 ]
757 ],
758 [
759 "email",
760 {},
761 "text",
762 "administrative.user@example.com"
763 ],
764 [
765 "tel",
766 {
767 "type": "voice"
768 },
769 "uri",
770 "tel:+1-555-555-1236;ext=789"
771 ],
772 [
773 "tel",
774 {
775 "type": "fax"
776 },
777 "uri",
778 "tel:+1-555-555-6321"
779 ]
780 ]
781 ]
782 },
783 {
784 "objectClassName": "entity",
785 "handle": "WWWW",
786 "roles": [
787 "billing"
788 ],
789 "vcardArray": [
790 "vcard",
791 [
792 [
793 "version",
794 {},
795 "text",
796 "4.0"
797 ],
798 [
799 "fn",
800 {},
801 "text",
802 "Billing User"
803 ],
804 [
805 "email",
806 {},
807 "text",
808 "billing.user@example.com"
809 ]
810 ]
811 ]
812 }
813 ],
814 "events": [
815 {
816 "eventAction": "registration",
817 "eventDate": "1997-06-03T00:00:00Z"
818 },
819 {
820 "eventAction": "last changed",
821 "eventDate": "2020-05-28T01:35:00Z"
822 },
823 {
824 "eventAction": "expiration",
825 "eventDate": "2021-06-03T04:00:00Z"
826 }
827 ],
828 "status": [
829 "server delete prohibited",
830 "server update prohibited",
831 "server transfer prohibited",
832 "client transfer prohibited"
833 ]
834 }
835
836 Figure 11: Unredacted RDAP Lookup Response
837
838 Example of the redacted version of an RDAP lookup response:
839
840 {
841 "rdapConformance": [
842 "rdap_level_0",
843 "redacted"
844 ],
845 "objectClassName": "domain",
846 "ldhName": "example.com",
847 "secureDNS": {
848 "delegationSigned": false
849 },
850 "notices": [
851 {
852 "title": "Terms of Use",
853 "description": [
854 "Service subject to Terms of Use."
855 ],
856 "links": [
857 {
858 "rel": "self",
859 "href": "https://www.example.com/terms-of-use",
860 "type": "text/html",
861 "value": "https://www.example.com/terms-of-use"
862 }
863 ]
864 }
865 ],
866 "nameservers": [
867 {
868 "objectClassName": "nameserver",
869 "ldhName": "ns1.example.com"
870 },
871 {
872 "objectClassName": "nameserver",
873 "ldhName": "ns2.example.com"
874 }
875 ],
876 "entities": [
877 {
878 "objectClassName": "entity",
879 "handle": "123",
880 "roles": [
881 "registrar"
882 ],
883 "publicIds": [
884 {
885 "type": "IANA Registrar ID",
886 "identifier": "1"
887 }
888 ],
889 "vcardArray": [
890 "vcard",
891 [
892 [
893 "version",
894 {},
895 "text",
896 "4.0"
897 ],
898 [
899 "fn",
900 {},
901 "text",
902 "Example Registrar Inc."
903 ],
904 [
905 "adr",
906 {},
907 "text",
908 [
909 "",
910 "Suite 100",
911 "123 Example Dr.",
912 "Dulles",
913 "VA",
914 "20166-6503",
915 "US"
916 ]
917 ],
918 [
919 "email",
920 {},
921 "text",
922 "contact@organization.example"
923 ],
924 [
925 "tel",
926 {
927 "type": "voice"
928 },
929 "uri",
930 "tel:+1.7035555555"
931 ],
932 [
933 "tel",
934 {
935 "type": "fax"
936 },
937 "uri",
938 "tel:+1.7035555556"
939 ]
940 ]
941 ],
942 "entities": [
943 {
944 "objectClassName": "entity",
945 "roles": [
946 "abuse"
947 ],
948 "vcardArray": [
949 "vcard",
950 [
951 [
952 "version",
953 {},
954 "text",
955 "4.0"
956 ],
957 [
958 "fn",
959 {},
960 "text",
961 "Abuse Contact"
962 ],
963 [
964 "email",
965 {},
966 "text",
967 "abuse@organization.example"
968 ],
969 [
970 "tel",
971 {
972 "type": "voice"
973 },
974 "uri",
975 "tel:+1.7035555555"
976 ]
977 ]
978 ]
979 }
980 ]
981 },
982 {
983 "objectClassName": "entity",
984 "handle": "XXXX",
985 "roles": [
986 "registrant"
987 ],
988 "vcardArray": [
989 "vcard",
990 [
991 [
992 "version",
993 {},
994 "text",
995 "4.0"
996 ],
997 [
998 "fn",
999 {},
1000 "text",
1001 ""
1002 ],
1003 [
1004 "adr",
1005 {},
1006 "text",
1007 [
1008 "",
1009 "",
1010 "",
1011 "",
1012 "QC",
1013 "",
1014 "Canada"
1015 ]
1016 ]
1017 ]
1018 ]
1019 },
1020 {
1021 "objectClassName": "entity",
1022 "handle": "YYYY",
1023 "roles": [
1024 "technical"
1025 ],
1026 "vcardArray": [
1027 "vcard",
1028 [
1029 [
1030 "version",
1031 {},
1032 "text",
1033 "4.0"
1034 ],
1035 [
1036 "fn",
1037 {},
1038 "text",
1039 ""
1040 ],
1041 [
1042 "org",
1043 {},
1044 "text",
1045 "Example Inc."
1046 ],
1047 [
1048 "adr",
1049 {},
1050 "text",
1051 [
1052 "",
1053 "Suite 1234",
1054 "4321 Rue Somewhere",
1055 "Quebec",
1056 "QC",
1057 "G1V 2M2",
1058 "Canada"
1059 ]
1060 ]
1061 ]
1062 ]
1063 }
1064 ],
1065 "events": [
1066 {
1067 "eventAction": "registration",
1068 "eventDate": "1997-06-03T00:00:00Z"
1069 },
1070 {
1071 "eventAction": "last changed",
1072 "eventDate": "2020-05-28T01:35:00Z"
1073 },
1074 {
1075 "eventAction": "expiration",
1076 "eventDate": "2021-06-03T04:00:00Z"
1077 }
1078 ],
1079 "status": [
1080 "server delete prohibited",
1081 "server update prohibited",
1082 "server transfer prohibited",
1083 "client transfer prohibited"
1084 ],
1085 "redacted": [
1086 {
1087 "name": {
1088 "description": "Registry Domain ID"
1089 },
1090 "prePath": "$.handle",
1091 "pathLang": "jsonpath",
1092 "method": "removal",
1093 "reason": {
1094 "description": "Server policy"
1095 }
1096 },
1097 {
1098 "name": {
1099 "description": "Registrant Name"
1100 },
1101 "postPath": "$.entities[?(@.roles[0]=='registrant')].
1102 vcardArray[1][?(@[0]=='fn')][3]",
1103 "pathLang": "jsonpath",
1104 "method": "emptyValue",
1105 "reason": {
1106 "description": "Server policy"
1107 }
1108 },
1109 {
1110 "name": {
1111 "description": "Registrant Organization"
1112 },
1113 "prePath": "$.entities[?(@.roles[0]=='registrant')].
1114 vcardArray[1][?(@[0]=='org')]",
1115 "pathLang": "jsonpath",
1116 "method": "removal",
1117 "reason": {
1118 "description": "Server policy"
1119 }
1120 },
1121 {
1122 "name": {
1123 "description": "Registrant Street"
1124 },
1125 "postPath": "$.entities[?(@.roles[0]=='registrant')].
1126 vcardArray[1][?(@[0]=='adr')][3][:3]",
1127 "pathLang": "jsonpath",
1128 "method": "emptyValue",
1129 "reason": {
1130 "description": "Server policy"
1131 }
1132 },
1133 {
1134 "name": {
1135 "description": "Registrant City"
1136 },
1137 "postPath": "$.entities[?(@.roles[0]=='registrant')].
1138 vcardArray[1][?(@[0]=='adr')][3][3]",
1139 "pathLang": "jsonpath",
1140 "method": "emptyValue",
1141 "reason": {
1142 "description": "Server policy"
1143 }
1144 },
1145 {
1146 "name": {
1147 "description": "Registrant Postal Code"
1148 },
1149 "postPath": "$.entities[?(@.roles[0]=='registrant')].
1150 vcardArray[1][?(@[0]=='adr')][3][5]",
1151 "pathLang": "jsonpath",
1152 "method": "emptyValue",
1153 "reason": {
1154 "description": "Server policy"
1155 }
1156 },
1157 {
1158 "name": {
1159 "description": "Registrant Email"
1160 },
1161 "prePath": "$.entities[?(@.roles[0]=='registrant')].
1162 vcardArray[1][?(@[0]=='email')]",
1163 "method": "removal",
1164 "reason": {
1165 "description": "Server policy"
1166 }
1167 },
1168 {
1169 "name": {
1170 "description": "Registrant Phone"
1171 },
1172 "prePath": "$.entities[?(@.roles[0]=='registrant')].
1173 vcardArray[1][?(@[1].type=='voice')]",
1174 "method": "removal",
1175 "reason": {
1176 "description": "Server policy"
1177 }
1178 },
1179 {
1180 "name": {
1181 "description": "Technical Name"
1182 },
1183 "postPath": "$.entities[?(@.roles[0]=='technical')].
1184 vcardArray[1][?(@[0]=='fn')][3]",
1185 "method": "emptyValue",
1186 "reason": {
1187 "description": "Server policy"
1188 }
1189 },
1190 {
1191 "name": {
1192 "description": "Technical Email"
1193 },
1194 "prePath": "$.entities[?(@.roles[0]=='technical')].
1195 vcardArray[1][?(@[0]=='email')]",
1196 "method": "removal",
1197 "reason": {
1198 "description": "Server policy"
1199 }
1200 },
1201 {
1202 "name": {
1203 "description": "Technical Phone"
1204 },
1205 "prePath": "$.entities[?(@.roles[0]=='technical')].
1206 vcardArray[1][?(@[1].type=='voice')]",
1207 "method": "removal",
1208 "reason": {
1209 "description": "Server policy"
1210 }
1211 },
1212 {
1213 "name": {
1214 "description": "Technical Fax"
1215 },
1216 "prePath": "$.entities[?(@.roles[0]=='technical')].
1217 vcardArray[1][?(@[1].type=='fax')]",
1218 "reason": {
1219 "description": "Client request"
1220 }
1221 },
1222 {
1223 "name": {
1224 "description": "Administrative Contact"
1225 },
1226 "prePath": "$.entities[?(@.roles[0]=='administrative')]",
1227 "method": "removal",
1228 "reason": {
1229 "description": "Refer to the technical contact"
1230 }
1231 },
1232 {
1233 "name": {
1234 "description": "Billing Contact"
1235 },
1236 "prePath": "$.entities[?(@.roles[0]=='billing')]",
1237 "method": "removal",
1238 "reason": {
1239 "description": "Refer to the registrant contact"
1240 }
1241 }
1242 ]
1243 }
1244
1245 Figure 12: Redacted RDAP Lookup Response
1246
1247 Example of the unredacted version of an RDAP search response:
1248
1249 {
1250 "rdapConformance": [
1251 "rdap_level_0"
1252 ],
1253 "domainSearchResults":[
1254 {
1255 "objectClassName": "domain",
1256 "handle": "ABC121",
1257 "ldhName": "example1.com",
1258 "links":[
1259 {
1260 "value":"https://example.com/rdap/domain/example1.com",
1261 "rel":"self",
1262 "href":"https://example.com/rdap/domain/example1.com",
1263 "type":"application/rdap+json"
1264 },
1265 {
1266 "value":"https://example.com/rdap/domain/example1.com",
1267 "rel":"related",
1268 "href":"https://example.com/rdap/domain/example1.com",
1269 "type":"application/rdap+json"
1270 }
1271 ]
1272 },
1273 {
1274 "objectClassName": "domain",
1275 "handle": "ABC122",
1276 "ldhName": "example2.com",
1277 "links":[
1278 {
1279 "value":"https://example.com/rdap/domain/example2.com",
1280 "rel":"self",
1281 "href":"https://example.com/rdap/domain/example2.com",
1282 "type":"application/rdap+json"
1283 },
1284 {
1285 "value":"https://example.com/rdap/domain/example2.com",
1286 "rel":"related",
1287 "href":"https://example.com/rdap/domain/example2.com",
1288 "type":"application/rdap+json"
1289 }
1290 ]
1291 }
1292 ]
1293 }
1294
1295 Figure 13: Unredacted RDAP Search Response
1296
1297 Example of the redacted version of an RDAP search response:
1298
1299 {
1300 "rdapConformance": [
1301 "rdap_level_0",
1302 "redacted"
1303 ],
1304 "domainSearchResults":[
1305 {
1306 "objectClassName": "domain",
1307 "ldhName": "example1.com",
1308 "links":[
1309 {
1310 "value":"https://example.com/rdap/domain/example1.com",
1311 "rel":"self",
1312 "href":"https://example.com/rdap/domain/example1.com",
1313 "type":"application/rdap+json"
1314 },
1315 {
1316 "value":"https://example.com/rdap/domain/example1.com",
1317 "rel":"related",
1318 "href":"https://example.com/rdap/domain/example1.com",
1319 "type":"application/rdap+json"
1320 }
1321 ],
1322 "redacted": [
1323 {
1324 "name": {
1325 "type": "Registry Domain ID"
1326 },
1327 "prePath": "$.domainSearchResults[0].handle",
1328 "pathLang": "jsonpath",
1329 "method": "removal",
1330 "reason": {
1331 "type": "Server policy"
1332 }
1333 }
1334 ]
1335 },
1336 {
1337 "objectClassName": "domain",
1338 "ldhName": "example2.com",
1339 "links":[
1340 {
1341 "value":"https://example.com/rdap/domain/example2.com",
1342 "rel":"self",
1343 "href":"https://example.com/rdap/domain/example2.com",
1344 "type":"application/rdap+json"
1345 },
1346 {
1347 "value":"https://example.com/rdap/domain/example2.com",
1348 "rel":"related",
1349 "href":"https://example.com/rdap/domain/example2.com",
1350 "type":"application/rdap+json"
1351 }
1352 ],
1353 "redacted": [
1354 {
1355 "name": {
1356 "description": "Registry Domain ID"
1357 },
1358 "prePath": "$.domainSearchResults[1].handle",
1359 "pathLang": "jsonpath",
1360 "method": "removal",
1361 "reason": {
1362 "description": "Server policy"
1363 }
1364 }
1365 ]
1366 }
1367 ]
1368 }
1369
1370 Figure 14: Redacted RDAP Search Response
1371
1372 5. JSONPath Considerations
1373
1374 JSONPath [RFC9535] is the default JSON path expression language.
1375 This section includes JSONPath considerations for clients and
1376 servers.
1377
1378 5.1. JSONPath Client Considerations
1379
1380 This section covers considerations for clients that receive responses
1381 from servers using JSONPath [RFC9535] to identify redacted RDAP
1382 fields with the "prePath", "postPath", or "replacementPath" member of
1383 redacted objects in the "redacted" member. The list of JSONPath
1384 client considerations include:
1385
1386 1. When the server is using the Redaction by Removal Method
1387 (Section 3.1) or the Redaction by Replacement Value Method
1388 (Section 3.4) with an alternative field value, the JSONPath
1389 expression of the "prePath" member will not resolve successfully
1390 with the redacted response. The client can key off the "name"
1391 member for display logic related to the redaction.
1392
1393 5.2. JSONPath Server Considerations
1394
1395 This section covers considerations for servers using JSONPath
1396 [RFC9535] to identify redacted RDAP fields with the "prePath",
1397 "postPath", or "replacementPath" member of redacted objects in the
1398 "redacted" member. The list of JSONPath considerations include:
1399
1400 1. Use absolute paths with the '$' JSONPath element. An example is
1401 "$.handle" for the "Registry Domain ID" in a lookup response or
1402 "$.domainSearchResults[0].handle" in a search response.
1403
1404 2. Validate a JSONPath expression with the non-redacted RDAP
1405 response when using the "prePath" member, where evaluating the
1406 expression results in returning the redacted field.
1407
1408 3. Reference the removed object field when redacting an entire
1409 object by the Redaction by Removal Method (Section 3.1), where
1410 all of the object's child fields are explicitly removed. An
1411 example is "$.entities[?(@.roles[0]=='administrative')]" for the
1412 entire "Administrative Contact".
1413
1414 4. Use multiple bases for the redaction of certain content. For
1415 example, if server policy is such that all administrative-role
1416 entities are redacted and all technical-role entities are
1417 redacted, then an entity having both the administrative role and
1418 the technical role could be redacted for two different reasons.
1419 In this situation, a server is required to include at least one
1420 "redacted" entry, but it should consider including a separate
1421 "redacted" entry for each applicable basis for redaction to
1422 clearly document the server policies that are relevant to
1423 redaction in each instance.
1424
1425 5. Reference the removed field when using the Redaction by Removal
1426 Method (Section 3.1). An example is "$.handle" for the "Registry
1427 Domain ID".
1428
1429 6. Reference index 0 of the jCard property array, which is the jCard
1430 "name" property, with a filter expression containing the name of
1431 the field when redacting a jCard field using the Redaction by
1432 Removal Method (Section 3.1). An example is "$.entities[?(@.role
1433 s[0]=='registrant')].vcardArray[1][?(@[0]=='email')]" for the
1434 "Registrant Email".
1435
1436 7. Reference the jCard field value or values redacted by array index
1437 3 and greater when redacting a jCard field using the Redaction by
1438 Empty Value Method (Section 3.2). The jCard property array index
1439 3 and greater contain the property values, where the property
1440 values set with an empty value are referenced directly in place
1441 of the jCard property name. Servers can then systematically
1442 redact the jCard field value or values based on the JSONPath
1443 expressions, and clients will directly know which jCard property
1444 values have been redacted. An example is "$.entities[?(@.roles[0
1445 ]=='registrant')].vcardArray[1][?(@[0]=='fn')][3]" for the
1446 "Registrant Name" or "$.entities[?(@.roles[0]=='registrant')].vca
1447 rdArray[1][?(@[0]=='adr')][3][5]" for the "Registrant Postal
1448 Code".
1449
1450 8. RDAP extensions should define any special JSONPath considerations
1451 required to identify redacted RDAP fields if these considerations
1452 are insufficient.
1453
1454 6. IANA Considerations
1455
1456 6.1. RDAP Extensions Registry
1457
1458 IANA has registered the following value in the "RDAP Extensions"
1459 registry:
1460
1461 Extension Identifier: redacted
1462
1463 Registry Operator: Any
1464
1465 Specification: RFC 9537
1466
1467 Contact: IETF <iesg@ietf.org>
1468
1469 Intended Usage: This extension identifies the redacted fields in an
1470 RDAP response.
1471
1472 6.2. RDAP JSON Values Registry
1473
1474 Section 10.2 of [RFC9083] defines the "RDAP JSON Values" registry
1475 with predefined Type field values and a registration policy of Expert
1476 Review [RFC8126]. This specification defines three new Type field
1477 values that can be used to register predefined redacted name, reason,
1478 and expression language values. IANA has updated the "RDAP JSON
1479 Values" registry to accept these additional Type field values as
1480 follows:
1481
1482 "redacted name": Redacted name being registered. The registered
1483 redacted name is referenced using the "type" field of the
1484 redacted "name" field.
1485
1486 "redacted reason": Redacted reason being registered. The registered
1487 redacted reason is referenced using the "type" field of the
1488 redacted "reason" field.
1489
1490 "redacted expression language": Redacted expression language being
1491 registered. The registered redacted expression language is
1492 referenced using the "pathLang" field.
1493
1494 IANA has also listed this document as a reference for the "RDAP JSON
1495 Values" registry and has registered the following value:
1496
1497 Value: jsonpath
1498
1499 Type: redacted expression language
1500
1501 Description: JSON path expression language, as defined in RFC 9535.
1502
1503 Registrant: IETF
1504
1505 Contact Information: iesg@ietf.org
1506
1507 Reference: RFC 9537
1508
1509 7. Security Considerations
1510
1511 The extension described in this document does not provide any
1512 security services beyond those described by [RFC9083].
1513
1514 8. References
1515
1516 8.1. Normative References
1517
1518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1519 Requirement Levels", BCP 14, RFC 2119,
1520 DOI 10.17487/RFC2119, March 1997,
1521 <https://www.rfc-editor.org/info/rfc2119>.
1522
1523 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
1524 DOI 10.17487/RFC6350, August 2011,
1525 <https://www.rfc-editor.org/info/rfc6350>.
1526
1527 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
1528 DOI 10.17487/RFC7095, January 2014,
1529 <https://www.rfc-editor.org/info/rfc7095>.
1530
1531 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
1532 Writing an IANA Considerations Section in RFCs", BCP 26,
1533 RFC 8126, DOI 10.17487/RFC8126, June 2017,
1534 <https://www.rfc-editor.org/info/rfc8126>.
1535
1536 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1537 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1538 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1539
1540 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
1541 Interchange Format", STD 90, RFC 8259,
1542 DOI 10.17487/RFC8259, December 2017,
1543 <https://www.rfc-editor.org/info/rfc8259>.
1544
1545 [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
1546 Protocol (RDAP) Query Format", STD 95, RFC 9082,
1547 DOI 10.17487/RFC9082, June 2021,
1548 <https://www.rfc-editor.org/info/rfc9082>.
1549
1550 [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
1551 Registration Data Access Protocol (RDAP)", STD 95,
1552 RFC 9083, DOI 10.17487/RFC9083, June 2021,
1553 <https://www.rfc-editor.org/info/rfc9083>.
1554
1555 [RFC9535] Gössner, S., Ed., Normington, G., Ed., and C. Bormann,
1556 Ed., "JSONPath: Query Expressions for JSON", RFC 9535,
1557 DOI 10.17487/RFC9535, February 2024,
1558 <https://www.rfc-editor.org/info/rfc9535>.
1559
1560 8.2. Informative References
1561
1562 [RDAP-JSCONTACT]
1563 Loffredo, M. and G. Brown, "Using JSContact in
1564 Registration Data Access Protocol (RDAP) JSON Responses",
1565 Work in Progress, Internet-Draft, draft-ietf-regext-rdap-
1566 jscontact-17, 7 December 2023,
1567 <https://datatracker.ietf.org/doc/html/draft-ietf-regext-
1568 rdap-jscontact-17>.
1569
1570 Acknowledgements
1571
1572 The authors wish to thank the following persons for their feedback
1573 and suggestions: Marc Blanchet, Tom Harrison, Scott Hollenbeck, Pawel
1574 Kowalik, Mario Loffredo, Gustavo Lozano, Andy Newton, Jasdip Singh,
1575 and Rick Wilhelm.
1576
1577 Authors' Addresses
1578
1579 James Gould
1580 VeriSign, Inc.
1581 12061 Bluemont Way
1582 Reston, VA 20190
1583 United States of America
1584 Email: jgould@verisign.com
1585 URI: http://www.verisign.com
1586
1587
1588 David Smith
1589 VeriSign, Inc.
1590 12061 Bluemont Way
1591 Reston, VA 20190
1592 United States of America
1593 Email: dsmith@verisign.com
1594 URI: http://www.verisign.com
1595
1596
1597 Jody Kolker
1598 GoDaddy Inc.
1599 14455 N. Hayden Rd., #219
1600 Scottsdale, AZ 85260
1601 United States of America
1602 Email: jkolker@godaddy.com
1603 URI: http://www.godaddy.com
1604
1605
1606 Roger Carney
1607 GoDaddy Inc.
1608 14455 N. Hayden Rd., #219
1609 Scottsdale, AZ 85260
1610 United States of America
1611 Email: rcarney@godaddy.com
1612 URI: http://www.godaddy.com
1613
Figure 13:
{
"rdapConformance": [
"rdap_level_0"
],
"domainSearchResults":[
{
"objectClassName": "domain",
"handle": "ABC121",
"ldhName": "example1.com",
"links":[
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example1.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"related",
"href":"https://example.com/rdap/domain/example1.com",
"type":"application/rdap+json"
}
]
},
{
"objectClassName": "domain",
"handle": "ABC122",
"ldhName": "example2.com",
"links":[
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example2.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"related",
"href":"https://example.com/rdap/domain/example2.com",
"type":"application/rdap+json"
}
]
}
]
}
Figure 14:
{
"rdapConformance": [
"rdap_level_0",
"redacted"
],
"domainSearchResults":[
{
"objectClassName": "domain",
"ldhName": "example1.com",
"links":[
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example1.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"related",
"href":"https://example.com/rdap/domain/example1.com",
"type":"application/rdap+json"
}
],
"redacted": [
{
"name": {
"type": "Registry Domain ID"
},
"prePath": "$.domainSearchResults[0].handle",
"pathLang": "jsonpath",
"method": "removal",
"reason": {
"type": "Server policy"
}
}
]
},
{
"objectClassName": "domain",
"ldhName": "example2.com",
"links":[
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example2.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"related",
"href":"https://example.com/rdap/domain/example2.com",
"type":"application/rdap+json"
}
],
"redacted": [
{
"name": {
"description": "Registry Domain ID"
},
"prePath": "$.domainSearchResults[1].handle",
"pathLang": "jsonpath",
"method": "removal",
"reason": {
"description": "Server policy"
}
}
]
}
]
}
Figure 13:
{
"rdapConformance": [
"rdap_level_0"
],
"domainSearchResults":[
{
"objectClassName": "domain",
"handle": "ABC121",
"ldhName": "example1.com",
"links":[
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example1.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"related",
"href":"https://example.net/rdap/v1/domain/example1.com",
"type":"application/rdap+json"
}
]
},
{
"objectClassName": "domain",
"handle": "ABC122",
"ldhName": "example2.com",
"links":[
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example2.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"related",
"href":"https://example.net/rdap/v1/domain/example2.com",
"type":"application/rdap+json"
}
]
}
]
}
Figure 14:
{
"rdapConformance": [
"rdap_level_0",
"redacted"
],
"domainSearchResults":[
{
"objectClassName": "domain",
"ldhName": "example1.com",
"links":[
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example1.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example1.com",
"rel":"related",
"href":"https://example.net/rdap/v1/domain/example1.com",
"type":"application/rdap+json"
}
],
"redacted": [
{
"name": {
"type": "Registry Domain ID"
},
"prePath": "$.domainSearchResults[0].handle",
"pathLang": "jsonpath",
"method": "removal",
"reason": {
"type": "Server policy"
}
}
]
},
{
"objectClassName": "domain",
"ldhName": "example2.com",
"links":[
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"self",
"href":"https://example.com/rdap/domain/example2.com",
"type":"application/rdap+json"
},
{
"value":"https://example.com/rdap/domain/example2.com",
"rel":"related",
"href":"https://example.net/rdap/v1/domain/example2.com",
"type":"application/rdap+json"
}
],
"redacted": [
{
"name": {
"description": "Registry Domain ID"
},
"prePath": "$.domainSearchResults[1].handle",
"pathLang": "jsonpath",
"method": "removal",
"reason": {
"description": "Server policy"
}
}
]
}
]
}
Noticed that the "self" and "related" links in Figure 13 and Figure 14 examples have the same "href" value. From RFC 9083: A "related" link relation MUST NOT include an "href" URI that is the same as the "self" link relation "href" URI to reduce the risk of infinite client processing loops. (The new "href" values for the "related" links are per James Gould's earlier suggestion.)