Hi Marc,
Comment below
Am 16.01.23 um 16:49 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.
Okay, but then, we are essentially disabling any kind of caching if the uid is
always different and random at each query for the same object. That would have
an impact on the servers, as clients will always query the servers, and the
server operators won’t be able to use caching services to help manage trafic.
Sad for an object that is so “cachable” as it otherwise does not change
frequently.
Marc.
[PK] I think the statement is not fully true. All http-based strategies
for caching will remain available, as long as the server operator would
not exclude caching on purpose by setting appropriate http headers. The
server operator would have to balance out the privacy policy vs. the
strategies of uid redaction and the implications on the server
performance. I think it is a fair deal if this decisions are left out to
the server operator rather than arbitrarily deciding it on the protocol
level.
One consideration we may think of, is whether there is (enough) value
for the server to inform the client (by the mean of specific new
redaction methods) whether the redacted uid is random each time, or it's
random but stable for a given entity in the same context, or it's
redacted with a static value and always the same for all entities. It
may serve a benefit for the clients and their caching / object
management strategies, but adds certain complexity to the protocol.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
