Hi Scott,
Il 31/03/2023 14:32, Hollenbeck, Scott ha scritto:
-----Original Message-----
From: regext <regext-boun...@ietf.org> On Behalf Of Mario Loffredo
Sent: Friday, March 31, 2023 7:45 AM
To: regext@ietf.org
Subject: [EXTERNAL] [regext] Redacting JSContact uid in RDAP - Updated
Caution: This email originated from outside the organization. Do not click
links
or open attachments unless you recognize the sender and know the content is
safe.
Hi folks,
just reported below all the options (including Gavin's proposal) and the
preferences given thus far.
Please, express your preference(s).
Thanks a lot in advance.
1) Redacting by Empty Value method
2) Making uid optional in RDAP and then redacting by Removal method
- J.Gould
3) Recommending the use of UUIDs that prevent from correlation (e.g.
either randomly generated or nil UUIDs)
4) Redacting by using a registered URN in the IANA namespace (e.g.
"urn:ietf:params:json:rdap+jscontact:uidRedacted")
- G. Brown
5) Anything else ?
[SAH] Which of these options is the least likely to break a JSContact parser?
[ML] I would say that it all depends on the constraints your
implementation checks.
Since uid is a JSON String and assuming that it isn't used to model some
JSContact relationship, the possible constraints to check are in order
of priority:
- Not null
- Not empty
- Compliance to a possible format
Unless RDAP overrides the JSContact spec (as stated by options 3 and 4)
, the uid value can be a free-text hence the last constraint can't be
checked.
With regard to the first two constraints:
- option 3 and 4 will make both the checks result in a success
- option 2 will make both the checks result in a failure
- option 1 will make the check on 2nd constraint result in a failure
Some additional considerations:
- if we comply to JSContact recommendation of assigning uid with an URN
in the UUID namespace, option 3 would be preferrable. URI and free-text
(including the empty string) are presently allowed for compatibility
with RFC6350 but could be deprecated in the future. To redact a
mandatory UUID to prevent from correlation, maybe an addtional redaction
method should be considered.
- jscontact-tools checks for the first two constraints (and, in the case
of a group card, it executes other consistency checks). Such constraints
are validated statically through annotations on properties but it's
quite easy to intercept the error messages and skip the failure of "not
null" constraint depending on the validation context.
Given that, my opinion is that option 2 would be preferrable because it
would enable the uid implementation in RDAP to be detached from the
possible uid evolution in the main spec.
As a result, I would also recommend to use an UUID when a server returns
an undisclosed uid property.
Note that an UUIDv5 can be generated from another property (like the
handle) and this enables a server to generate always the same uid value
without storing it somewhere.
Apologize for the long explanation.
Hope it could be helpful.
Best,
Mario
My preference is leans towards whichever option or options will be the most
compatible with implementations of JSContact such that any RDAP complexity is
handled in the RDAP-implementing software.
Scott
_______________________________________________
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
