Hi Marc, Pawel and others,
as you may have known, I have asked CalExt for defining in JSContact
spec possible conditions where uid can be optional, for example the use
of JSContact in another protocol.
Let's wait for a response and then we'll be able to make a definitive
proposal about this matter.
Meantime, thanks everyone who has joined the discussion thus far.
Best,
Mario
Il 16/01/2023 23:33, Marc Blanchet ha scritto:
Le 16 janv. 2023 à 16:18, Pawel Kowalik <kowa...@denic.de> a écrit :
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.
If the object is in a CDN (with id=1), then the client make the request and
then either get the CDN cached object (which we don’t want per definition of a
new id every time) or the CDN go get another version from the server because
cached data has expired and therefore the server is queried. To properly serve
an object whose internal id change every time, one must set the expire to
always expire (i.e. no-cache), which means cache are not useful.
Marc.
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
--
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: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
