Pawel, > It may be a valid point to expect RDAP server to always deliver the same > response to the same query, which would imply the same entity delivering > the same redacted uid in the same query context, instead of fully random > uids. I assume however that even that may be too much from privacy > policy perspective of some registries, therefore IMHO the specification > shall allow for such radical redaction and the client applications have > to be able to deal with it.
The same entity JSContact "uid" does exist in the form of the "handle", but the issue is that there is a known use case where the handle may be redacted. Yes, the RDAP client applications must be able to deal with the redaction of information with the inclusion of the "handle" in the context of a domain query response. The purpose of draft-ietf-regext-rdap-redacted is to provide the explicit signal to the client application that a field has been redacted along with the method of redaction. Providing an empty or fully random "uid" field is pretty much the same as removing it, since they don't provide the client application with any useful information and are being used just to get around a constraint imposed by a dependent specification (e.g., I-D or RFC). Hopefully, draft-ietf-calext-jscontact can make the "uid" field optional to support the use of JSContact in other protocols, so that the existing entity "handle" field can be used for the JSContact "uid" field with the support for Redaction by Removal Method to address the known redaction use case. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 1/16/23, 10:44 AM, "regext on behalf of Pawel Kowalik" <regext-boun...@ietf.org on behalf of kowa...@denic.de> wrote: Hi, My comment below. Am 11.01.23 um 19:03 schrieb Marc Blanchet: > >> Le 11 janv. 2023 à 12:43, Gould, James <jgould=40verisign....@dmarc.ietf.org> a écrit : >> >> Mario, >> >> I'm assuming that JSContact will define an expected format for the "uid" field that we must comply with in RDAP, which is not needed for RDAPs use case. Use of redaction by empty value would not be compliant with the potential format language. The difference between jCard and JSContact is that jCard was already an RFC when RDAP was being created, where JSContact is currently an Internet Draft. You are aware of the need to redact the "uid" field for the RDAP use case, so why not make the "uid" optional in JSContact to make it meet the broader use case of RDAP with some potential caveats (e.g., the "uid" MUST be set when there is the need for discovering, comparing, or synchronizing contact cards)? RDAP doesn't have those needs, so the inclusion of the "uid" can be optional and used where it makes sense, such as returning in an entity query response. The "uid" could match the "handle" and be redacted in the domain query response. > My 2 cents. an object shall have a mandatory unique identifier. I think we are going way too far by removing a unique (random) object identifier for the purpose of privacy. A UID/UUID does not provide any privacy related info. I’m aware of the cross references, but I just think we are going way too far. I would vote for keeping the UID as mandatory, since for an implementer perspective, I can keep this object and its UID, put it in a database and know when I have an updated version of that object because the UID is unique and mandatory. Without UID, all objects are different, and this is no fun to correlate: I would potentially have multiple copies of the same object without being able to flush them out, unless a do a full deep comparison, which does not make any sense. I think we would be going too far if the technical / protocol decision would implicitly narrow down privacy policy options of the registry. If this is mandatory for the data structure to contain uid, that's fine. One of the rules in this draft was not to break data formats by the redaction. This can be achieved by replacing the real uid with a generated and privacy-preserving one, as raised already in some of the proposals. It should be properly signaled, same as for any other redaction taking place. The client applications basically shall not rely on identifiers, which have been redacted. It may be a valid point to expect RDAP server to always deliver the same response to the same query, which would imply the same entity delivering the same redacted uid in the same query context, instead of fully random uids. I assume however that even that may be too much from privacy policy perspective of some registries, therefore IMHO the specification shall allow for such radical redaction and the client applications have to be able to deal with it. Kind Regards, Pawel _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1JZymeI8F7nS7MJSw2pB-B9HraLBfobyCv0oT5WqCsDKwU8Nk21b6hHYJnSkWsT0W9l-XqOtdKL6jPAQfKU112fJSL9DSD0tgBSitRuKVqYBkZvLgy_NgWpPtu-lq9gkbDFS_BbtTa9XeTePDKjGEuzgS9xUGzad4Wrb7paM9vRur5BQhWGAQuxuPdRMY2ZrKL2HSWQJ_j_Qb6JbaXDgRbSuC46uB08xVBwxOHrs_pIQUatsdRfPYVBwFjc5HpPaIWAcpB2h8NGdn3Y5UWrSr4W0BKl1_os9T5vSaR0n0SA8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
