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://www.ietf.org/mailman/listinfo/regext
