Re: [regext] Request WGLC for draft-ietf-regext-rdap-redacted

["Gould, James" <[e-mail]>]

Mario,

Thank you for clarification around the vCard specific example of the partial redaction of the formatted text properties “LABEL” and “FN”.  I don’t believe any of the existing redaction methods cover this case of a partial redaction of a formatted text property value.  I realize this is a corner case, but to fully address it in RDAP, we may need to add a new redaction method to draft-ietf-regext-rdap-redacted.  The redaction method could be “Redaction by Partial Value Method” with the “method” member value of “partialValue”.  This would signal to the client that the formatted text property value has been partially redacted.  The concrete case are the “LABEL” and “FN” vCard properties, but other formatted text properties could be defined in the future.

Thoughts on adding a new redaction method for covering this corner case?

--

JG

[cid:image001.png@01D90E02.1DB1B810]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: Mario Loffredo <[e-mail]>
Date: Saturday, December 10, 2022 at 3:31 AM
To: James Gould <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: [regext] Request WGLC for draft-ietf-regext-rdap-redacted


Hi James,

please find my comments below.
Il 09/12/2022 19:15, Gould, James ha scritto:
Mario,

Sorry for the delay in responding to your feedback.  Thanks for the feedback and below are the responses to it.

--

JG

[cid:image002.png@01D90E02.1DB1B810]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://secure-web.cisco.com/10wmXnAxec1RRrOtGTl4db_iLXMUtPfYFQrLzw-IA2PHbfNc9ze5KbXK3eWCAxJSio1lPtr_6pKioWeYvtLLrnVmZPkJWjQzok4esvmclUfrfkyRBCyDoJt_ryHsKxqZnXSbirKJywEyxB25w9OZqILiskden6igDu3eWZ8GZbgLoDDPJFLJVheJMYKuASxkT76O1U0JGRZ0wh5gYU7PxQ9YOsffUD0yMTCKG3C_S6kW9V15m-UfLxS6qupeP2j7qkhOOudeo--y4d2AzM-KUXiu-EqrQCbjBAN1DGuZ41tA/http%3A%2F%2Fverisigninc.com%2F>

From: Mario Loffredo <[e-mail]><mailto:[e-mail]>
Date: Tuesday, November 15, 2022 at 9:05 AM
To: James Gould <[e-mail]><mailto:[e-mail]>, "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Subject: [EXTERNAL] Re: [regext] Request WGLC for draft-ietf-regext-rdap-redacted


Hi James,

some comments from my side:

1) With reference to the following sentence in section 3.2:

such as "" for a jCard [RFC7095] Text ("text") property or null for non-Text ("text") properties.

it seems to me that RFC7095 doesn't include a clear statement in that sense.

Some VCard types (i.e. text, uri, language-tag, utc-offset, and all date type variants) are mapped to JSON strings, other VCard types are mapped to other JSON primitive types (i.e number, boolean).

Given that, apart from "fn"  that is a required "text" property, a JSON string can be either null or empty.

For sure, the use of the empty string makes more sense for "text" values, but null value is not clearly prohibited for the other VCard properties mapped to JSON strings.

JG – Yes, the other jCard properties may be mapped to a JSON string, but they include additional string format requirements that would not be met with the use of an empty string.  The reference to the Text (“text”) property does not apply to the other jCard properties that map to a JSON string, so the redaction is handled with the use of a null value.

2) WIth regard to redaction by replacement method, should the example in Fig.7 be updated as in the following:

OLD

   "redacted": [

     {

       "name": {

         "type": "Registrant Email"

       },

       "path": "$.entities[?(@.roles[0]=='registrant')].<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')][3]>

                  vcardArray[1][?(@[0]=='email')][3]"<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')][3]>,

       "replacementPath": "$.entities[?(@.roles[0]=='registrant')].<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')][3]>

                  vcardArray[1][?(@[0]=='contact-uri')][3]"<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')][3]>,

       "pathLang": "jsonpath",

       "method": "replacementValue",

     }

   ]

NEW

   "redacted": [

     {

       "name": {

         "type": "Registrant Email"

       },

       "path": "$.entities[?(@.roles[0]=='registrant')].<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')]>

                  vcardArray[1][?(@[0]=='email')]"<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='email')]>,

       "replacementPath": "$.entities[?(@.roles[0]=='registrant')].<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')]>

                  vcardArray[1][?(@[0]=='contact-uri')]"<mailto:$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')]>,

       "pathLang": "jsonpath",

       "method": "replacementValue",

     }

   ]

Based on the example in Fig.6, the "email" property instead of the "email" value is replaced.

JG – Yes, I agree that the “email” property instead of the “email” value is replaced.  This will be addressed in draft-ietf-regext-rdap-redacted-10.



3) Would rephrase the following sentence in section 4.2

OLD

The "redacted" member contains an array of redacted

   objects with the following child members

NEW

The "redacted" member contains an array of

   objects with the following child members

The objects in the "redacted" array are not redacted but rather the response fields represented by those objects.

JG – This will be updated in draft-ietf-regext-rdap-redacted-10.

4) Wonder if section 6.2 should include an entry for pathLang.

JG – Yes, based on the feedback from Pawel Kowalik, the “redacted expression language” type will be added with an initial registration of the “jsonpath” value for the JSON Values Registry.

5) A last feedback about JSONPath Considerations:

5.a) Is it allowed to use wildcard in JSONPath? Think it could be useful especially when the same redaction rule is applied to each result of a search response.

For example, if a registry policy consists in redacting all the domain handles, the "redacted" content could simply be:

           "redacted": [

             {

               "name": {

                 "type": "Registry Domain ID"

               },

               "path": "$.domainSearchResults[*].handle",

               "pathLang": "jsonpath",

               "method": "removal",

               "reason": {

                 "type": "Server policy"

               }

             }

           ]

JG – Actually for searches the “redacted” member can be included on a per-object basis, since the redaction may be different per object.  Attempting to define crosscutting redaction definitions for all objects included in the search seems like something the server could do, but I don’t believe it should be encouraged.

5.b) I consider this a corner case so feel free to ignore it  ;-)

The VCard label property (as well as the JSContact fullAddress property) is usually derived from the postal address information.

When the postal address is partially redacted, what should be the label value and the related redaction method?

If you think it's worth managing this case, I would suggest a conservative solution:  the label property should be omitted and the redaction method should be "removal".

JG – The rule is if the property can be and is removed due to redaction, then it is omitted, and the redaction method should be “removal”.  I’m not sure if this fully answers your feedback, so please let me know with an example if it doesn’t.

[ML]  As I wrote in my previous mail, maybe it's not worth addressing this case. In general, it is connected with the redaction of vCard elements, namely the FN property and the LABEL parameter of the ADR property, that are generated by formatting their structured counterparts. If the structured components get partially redacted by the emptyValue redaction method, what redaction method should I use to redact the formatted versions?

Here in the following an example clarifying my question.

Before redaction:

         [

                   "adr",

                   {"label": "Suite 1236\n4321 Rue Somewhere\nQuebec\QC\G1V 2M2\Canada"},

                   "text",

                   [

                     "",

                     "Suite 1236",

                     "4321 Rue Somewhere",

                     "Quebec",

                     "QC",

                     "G1V 2M2",

                     "Canada"

                   ]

                 ]

After redaction:

1)

         [

                   "adr",

                   {"label": "QC\nCanada"},

                   "text",

                   [

                     "",

                     "",

                     "",

                     "",

                     "QC",

                     "",

                     "Canada"

                   ]

                 ]

2)



         [

                   "adr",

                   {},

                   "text",

                   [

                     "",

                     "",

                     "",

                     "",

                     "QC",

                     "",

                     "Canada"

                   ]

                 ]



Since the specification doesn't allow the server to signal that a value has been partially redacted, and I don't see the need to  add another redaction method only for this corner case, my proposal was simply the following: "those properties that are generated from other properties that can be partially redacted must be redacted by using the removal method" (Solution 2)

Best,

Mario



Hope it could be helpful.

Best,

Mario




Il 10/11/2022 19:38, Gould, James ha scritto:
This is a formal request to start the WGLC for draft-ietf-regext-rdap-redacted.  There is a normative reference to draft-ietf-jsonpath-base, which has a JSONPath working group November milestone.  draft-ietf-jsonpath-base looks stable and can progress in parallel with draft-ietf-regext-rdap-redacted.

Thanks,

--

JG

[cid:image003.png@01D90E02.1DB1B810]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://secure-web.cisco.com/1jBgmRGLp97BwyI56ZY6E2KnhXLBn_CyaRjxVZ7GqU5nP4VoGbDmOFaSadTLrZ8OaIMWwNr4CLXsVIYNhnH4Z3c6przEWV0581stOfOtCDYyVb1U8iX-OaeglUaY6UIjRbRsoaAcqnx12w7uDgnjrwnhLrtSCH3NQK20VhpKXQbAofvo4jOJsx4cHjD5sxmv-xKgfyjXZgr7oOpxU9z41XgH02hJZZTYbogCf05948JANuWS0T4DojwwmNtmQHoN9UjVqPRqZKAn7gbjnO0xXK3ZDaxx9N9iz65hy3ZqIgQYHxdSLk5KUHbNvQydrwCxd/http%3A%2F%2Fverisigninc.com%2F>




_______________________________________________

regext mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1QZXPKZg0yOi5FGPtQR9fKFNSa-mIVnC7WC4ALwt1eRfK3-ypZSt6_2xY-hSaVmgzAytTYYHcnL4rCXxWO2UpEtkMlh-OegPiK5nrIShRzg2hBlREYZPS41o1IwIWcM7UZPGQ-FxQBxkkf8fRsG27ZJPh6SN4Npz5Nx0eTyp0BNyD27_AEHQOQGphegY8qsrmx-Wjd9q7Csh129rmKkvKVxpZzed_u_8Pwyn4g4DN11Ns2RGRyh6-ymPx7BK5CxqUGI6OovchjtlylImbPICIi7KiCZMvnjcPCyn_ZDbQbxVQpIu6ikjianxcAM8RpdtD/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>

--

Dott. Mario Loffredo

Technological Unit “Digital Innovation”

Institute of Informatics and Telematics (IIT)

National Research Council (CNR)

via G. Moruzzi 1, I-56124 PISA, Italy

Phone: [phone]

Web: http://www.iit.cnr.it/mario.loffredo<http://secure-web.cisco.com/139AqdF7WT3CdxSSc0UPSoDgA0gl9_QwVKklekryCslll0JvKfIWV4X16QAKacmsRBjPmY6-F04c28s5zpz2HwT6ki7ON7XQHsnRXipvn3m1NoGxfR9XMNRGTtoSlaoXahD0z-bP-mSUPsraAy5ewotwaYuTsKuafF8T5HN8JqEL4pqYsq1WAdl8WS_bHigbb8mVKIhqTDuRazKzVCpoByy52N_M-Hf8megqz4jAbIU_D7CgzVTQH7GQXldLgfms9L0ugpZtQ0bewrH_9DBeNO0aiY2BRkZ8adIM_8V-TsGl3qCbgdfLzBl6RNTz79GpF/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>



_______________________________________________

regext mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1rA9AMtjPXivn2GGQB-ID4QUpd0YAumPZdCk9bomUeA-FW0jgWKt4BP-iZUjN9ZK5RHa3mQ0cgZR2CXGzCn7h5draw6tDsnn1tSB77lEpcrBTek47xmL8JcWRW7nrXcYWxlUJzXRAQbEPjV-zA4CToN9bL-qxyTxiM86Qdl2yf0VHGU9I7jvK8JrtFVS-STzmXEIFF8EaHSM31W6KF8L2VL4rQ4ZGnDL1tI2DNqDdq8GKQjafxSL34HzNHpWSllgqbY7K6JSCJ6773fZIRMhrDaF5f-HmjwipuKwciva27i0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>

--

Dott. Mario Loffredo

Technological Unit “Digital Innovation”

Institute of Informatics and Telematics (IIT)

National Research Council (CNR)

via G. Moruzzi 1, I-56124 PISA, Italy

Phone: [phone]

Web: http://www.iit.cnr.it/mario.loffredo<http://secure-web.cisco.com/1Bl4tTWy6j96jLMQhvvpHAXNQ41oOlRskA5D53vZW-T6wL5phoY08mwHjoDtV7zFoXdlnARj7naYERSK3D1qW0xpd-s6AvJpc0cJ_SoIHX3iNlY-fO3_aB3ZnKwQ65nXXA7jCf0fUrGBdv98Qds0-Y14vwcKUTItJm97dg7egfABvUs7UEhDs1G_C1kNZM-5r7UzETiZxK5ob6tjf5_rSghdo7CrPwb334_rKFyPKsj7HGu2tNYK7iKhzdbMAJXxYdGfnJMRecJSzF646MoK8g1sAcpiQmU0lbVf_fwxvhLo/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>