Hi Andy,
please find below my reply to this post along with my feedback on
SimpleRedaction:
- I'm not OK with redacting only the JSON String values. IMO, it's
better to have a comprehensive approach dealing with any JSON value,
including objects and arrays. Just to give an example: for the sake of
compatibility with the WHOIS response, .it RDAP server redacts the
events of those contacts who did not give the consent for publishing.
Think that it would be easier for servers to redact the events array
instead of populating it with fake dates. Similarly, clients could
signal that all the events have been redacted.
- Some placeholder values must comply with specific formats (e.g. email
addresses, phone numbers, dates). Sometimes those values look really
odd (e.g. what could be a placeholder for a date-time value ?
"9999-01-01T00:00:00Z" ?). But i'm more concerned about the result when
SimpleRedaction is not implemented by the client. I'm afraid that the
fake values displayed to the user would be interpreted as server errors
instead of values used on purpose. Conversely, if RFC9437 was not
implemented by a client, no fake value would be presented to the user.
- JSContact uid needs no ad-hoc placeholder value to be redacted. The
"Security Considerations" section of rdap-jscontact describes how to
redact it by using the Nil UUID through the replacementValue method
when the UUID format is used or, the empty string through the emptyValue
method otherwise. Please note that the Nil UUID is already defined by
RFC9562 for this purpose:
A Nil UUID value can be useful to communicate the absence of any
other UUID value in situations that otherwise require or use a
128-bit UUID. A Nil UUID can express the concept "no such value
here". Thus, it is reserved for such use as needed for
implementation-specific situations.
- Repeating once again my mantra, the problem here is not the redaction
method but rather how data are structured. To represent contact data
that might be redacted, objects should always be preferred to arrays and
arrays should be redacted instead of their items when arrays have to be
used. That would considerably help both servers and clients in handling
redacted data. There would be no ambiguity in selecting a JSON value and
we wouldn't have to distinguish the path before from the path after the
redaction because the object members as well as the map entries are
selected by name and their removal doesn't impact on their siblings.
Best,
Mario
Il 21/06/2024 14:41, Andrew Newton (andy) ha scritto:
On 6/20/24 16:39, rcar...@godaddy.com wrote:
I was not sure if I should reply to this thread or the "Simple"
thread but as the "Simple" thread appears to be a product of this
one, I thought I would post here.
Several years ago, there were many discussions (in the REGEXT WG, the
RDAP WG and others) on how to handle redaction in the RDAP response
and using placeholder text was an option that was discussed. Through
those discussions it was determined that using placeholder text was
not fit for purpose (typed data, different types of redactions,
varied server implementations, etc) and was deemed as an engineering
"hack" and called for an original solution. Not using placeholder
text was exactly what drove us to the creation and eventual
publication of RFC 9537.
Roger,
It is not simple placeholder text but patterned keys that retain
syntactic validity. I did search the archives and did not find any
discussion of this approach. However, if you can point us to the those
technical discussions or, better, recite them here that would be very
helpful. While some may pejoratively refer to it as a "hack", there is
another saying often used by engineers, "the best is the enemy of the
good."
This solution also has some clear benefits.
1. It can cleanly deal with JSContact UIDs, whereas we had many
discussions on the list regarding the interaction between JSContact
and 9537.
2. It can distinguish the parts of a string that are redacted from the
parts that are not.
3. Even if the client doesn't support the extension and passes the
data onto the user, there is some chance that the user will understand
that the data has been redacted.
-andy
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: 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
To unsubscribe send an email to regext-le...@ietf.org
