Re: [calsify] JSContact in RDAP

[Robert Stepanek <[e-mail]>]

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)?

> 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.

> 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.