Re: [calsify] JSContact in RDAP

[Mario Loffredo <[e-mail]>]

Hi Robert,

Il 17/01/2023 09:59, Robert Stepanek ha scritto:
>
> On Fri, Jan 13, 2023, at 7:05 PM, Mario Loffredo wrote:
>>
>> To avoid correlation of contacts associated with domains across RDAP 
>> domain query responses, the uid property could be redacted by the 
>> RDAP server. The possible redaction methods are defined in another 
>> draft currently under discussion at RegExt, namely 
>> draft-ietf-regext-rdap-redacted 
>> <https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/>.
>>
>> The preferrable redaction method would be the uid removal but, 
>> unfortunately, it doesn't comply with the mandatory constraint on uid.
>>
>
> I say we need to sort this out to make JSContact work for RDAP, so I 
> am generally open to all options. But we should first consider if we 
> can support this specific use case and keep uid mandatory. That being 
> said, UID also is optional in vCard4 but we want to do away with that 
> in JSContact.
>
>> I have proposed some alternatives to work around this issue (e.g. 
>> using randomly generated UUIDs at every response or setting the uid 
>> to an empty string since the free-text format is allowed). 
>> Nevertheless, I must agree that it would be better if the uid 
>> property was optional in RDAP.
>>
>
> Is the only goal to not allow correlating JSContact objects by uid? If 
> so, I do not understand why a random uuid4 per request does not 
> resolve that issue. Or is it also important to signal to the recipient 
> that the uid property value is redacted? In that case, how about 
> setting the nil uuid (all bits set to zero)?

Thanks for the questions so that I'm able to provide further information 
about the context of my post.

Based on what is described in draft-ietf-regext-rdap-redacted, the RDAP 
server signals the client about the redacted response fields by 
including them in the "redacted" array. Each array entry contains 
information about the method used for redaction. The most suitable 
methods for uid could be: "redaction by removal", obviously under the 
assumption that the method is not mandatory, and"redaction by emtpy 
value", which has been introduced to redact some jCard properties that 
can't be removed such as the "adr" components and the "fn" property.

Since the free-text format is allowed for uid,  the latter method could 
be used but the former is considered better due to the following reasons:

- RDAP already makes use of another property, namely the entity handle, 
to identify a contact. Therefore, to avoid the case of two distinct 
unrelated identifiers for the same object, it would be advisable that 
the uid value was related to/derived from the handle value, for example 
the uid value could include the RDAP entity lookup URL (e.g. 
https://example.com/rdap/entity/XXXX where "XXXX" is the handle value). 
But the entity handle value is defined as optional and could be redacted 
due to the server policy (see the ICANN RDAP response profile for 
gTLDs). Making the uid property optional could allow the RDAP server to 
consistently display/redact both the properties .

- secondly, the use of a randomly generated UUID as well as a nil UUID 
would result in defining in the rdap-redacted doc a new redaction method 
to be likely used just for the uid property (e.g. redaction either by a 
random value or by a pre-defined value). Another objection against the 
use of randomly generated UUIDs is that it is expected that an RDAP 
server always provides the same response values based on the user profile;

- last but not the list, making uid optional in RDAP would make RDAP 
independent on any future change of the uid format.

As a sort of mediator between RegExt and CalExt, would like to point out 
that I'm merely explaining the reasons supporting the RegExt request for 
making the uid property optional. I'm not advocating a way to proceed.

>
>> I strongly apologize if I didn't introduce the matter earlier but 
>> this is the time I'm finalizing rdap-jscontact for the WGLC and only 
>> now some RegExt members asked me as JSContact co-author for seeking a 
>> possible way to make uid optional in RDAP.
>>
>
> Better we resolve this now than publish a spec that turns out not to 
> be useful for other working groups.
Totally agreed.
>
>> For example, would it make sense to state in JSContact spec that the 
>> mandatory constraint on uid can be overriden when JSContact is used 
>> within other specifications?
>>
>
> The moment we do that any protocol-independent JSContact parser 
> implementation will have to support optional uid properties anyway. 
> Let's try to come up with a solution that fits all our known use cases 
> first.

Cheers,

Mario

>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo