Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-jscontact-15.txt

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

Mario,



The recommendation in draft-ietf-regext-rdap-jscontact is that the JSCard “uid” property SHOULD contain the same value as the RDAP “handle” property.  We do provide an example of redacting the domain RDAP “handle” property in draft-ietf-regext-rdap-redacted, so it’s not a stretch to also redact the entity RDAP “handle” property.  Based on the IRT OneDoc and the supporting draft Version 2.2 of the RDAP Response Profile, the “handle” for the Registrant (e.g., “Registry Registrant ID”) and Tech (e.g., “Registry Tech ID”) contacts are subject to redaction requirements, so this is not much of a corner case in RDAP.  You may want to follow-up with calext on the possibility of having to redact the “uid” field, since it looks like a true possibility downstream in RDAP.  I don’t believe draft-ietf-regext-rdap-jscontact can make a required field of JSContact optional, but I don’t believe it can be made mandatory in RDAP.  Attempting to redact a required field of an RDAP extension in draft-ietf-regext-rdap-redacted gets into thorny compliance issues, such as removing a required field via the Redaction by Removal Method or keeping the field by clearing the value that may have format requirements via the Redaction by Empty Value Method.



I believe Redaction by Removal Method is the cleanest method of redaction for a standard JSON member.  It will be up to the RDAP extensions to be more conservative in their normative language for JSON members to support redaction if required by server policy.  I don’t recommend updating draft-ietf-regext-rdap-redacted to attempt to override the normative language of an RDAP extension explicitly by removing the member or implicitly by returning an empty value.



--



JG







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/>



On 1/4/23, 4:58 AM, "Mario Loffredo" <[e-mail]> wrote:





    Hi James,



    honestly don't think that the "uid" field will ever get redacted, I

    mean, it's recommended to be an UUID and normally UUIDs are opaque. Both

    UUIDv3 (MD5) and UUIDv5 (SHA1) can be derived from a string (like for

    example the entity handle) so there is no need to generate and store a

    new value.  If it was optionally represented as an URI, a reasonable

    value could be the URL of the entity lookup whose response includes the

    contact card. Since the entity lookup is based on the entity handle

    value and such a value is a registry unique identifier, either in this

    case, the "uid" redaction seems very unlikely to me. Anyway, I can't

    completely exclude such a corner case. In the unlikely event that the

    "uid" field is redacted, I would process it in the same way as the jCard

    "fn" property.



    Both of them are required text fields so don't see why they should be

    processed differently. In addition, there is a requirement from calext

    about keeping uid mandatory.





    Best,



    Mario





    Il 03/01/2023 17:33, Gould, James ha scritto:

    > Mario,

    >

    > I don't see any need to add a dependency between draft-ietf-regext-rdap-jscontact and draft-ietf-regext-rdap-redacted, but this does add an interesting case for draft-ietf-regext-rdap-redacted with redacting a required JSON member.  Do you see the requirement to be able to redact the required "uid" JSContact property?  If there is the need to redact it, then wouldn't that make the case for it not to be defined as mandatory in draft-ietf-calext-jscontact?  I'm not sure whether providing an empty value via the Redaction by Empty Value Method is any better than simply removing it via the Redaction by Removal Method.  We would need to first determine whether there is the need to cover the case of redacting a required JSON member in draft-ietf-regext-rdap-redacted and if so how best to handle it.

    >

    > Thanks,

    >

    --

    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://secure-web.cisco.com/1dUrW2nmIC0BLllxqOdvyNJK5jfCH4-D45wpX6KaFLgWfNx6Le_Mud9m9ktIoHTtzUlk6SlpeYMgGQfmJzds6HeOkZj1FfogRWY5RhWmnpk_EPL0BD7rHq_455H43ZDeaKw0Q-sqQ7YkhmF2P0Adk40p5dh5EU__t9yITWm551g0_Uqs90zOztBNH7H4wL2gmnkaAOYeYWTsVhoNWX7ctYsHaYgBBfwWXwxa8xRzSjbaNJMblH--htjDjKydpncQJJZevOW9_fICNnUf5GZih5lIRzGvDFUnqb_4QSFuu73M/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo