Subject: [regext] Ideas to address the privacy implication of reverse search draft

From: Ali Hussain <[email-masked]>
Date: Thu, 3 Dec 2020 16:47:44 -0800

Hi All,

It wa  interesting to see the interest during REGEXT IETF 109 meeting call
to address the the privacy aspects of draft
(draft-ietf-regext-rdap-reverse-search).

So far my idea to improve the reverse search to first make the JSON object
for the required level of privacy critical data. Based on the tag the
partial response suppresses the privacy part of responses by encoding and
in order to decode it, it must present an identity to federated access
control.

I am also reviewing the hrpc draft to bring some valuable input form their
guidance.

Please let me know what you think and is anyone else interested to work on
this?

Thanks,

Regards,
Ali Hussain

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 4 Dec 2020 10:24:01 +0100

Hi Ali,

thanks a lot for your interest.

Obviously, I'm willing to collaborate with anyone who plans to implement 
the reverse-search capability and I'm open to any idea that can 
contribute to make the proposal more comprehensive.

I'm also available to give my humble contribution to harmonize the 
reverse-search specification with the concepts described in the hrpc draft.

That being said, if I interpreted your idea correctly, you are proposing 
an operation model where the capability is open to everyone but the 
access to possible sensitive response data are reserved only to 
authenticated users, right?

If so, I have a couple of comments:

- The RDAP servers are already engaged in tailoring their responses on 
different user profiles due to GDPR. Sensitive data redaction is usually 
achieved through a combination of practices like not returning optional 
sensitive data, replacing the value of  mandatory sensitive data (like 
jCard "fn" for individuals), publishing only those sensitive data which 
the owner has previously given the explicit consent for. So which 
additional issues should your proposal address?

- In the case of a reverse-search, what must be allowed to authenticated 
users is not the access to the data returned by the capability but 
rather the capability itself.  Of course, the reverse search is not the 
only query capability that can be controlled. For example, at .it we 
don't permit everyone to submit a generic search query.  This can be 
done either through the well-known HTTP authentication methods as 
described in RFC7480 or by applying a federated authentication to RDAP 
as defined by Scott's rdap-openid extension.  To make an ad-hoc access 
control easy to implement, the reverse-search draft introduces the 
specific "/reverse" path and lets servers furtherly regulate the access 
on a per-entiy-role basis.

Definitively, maybe I'm missing something but do we really need anything 
other than what already exists?

Best,

Mario

Il 04/12/2020 01:47, Ali Hussain ha scritto:
> Hi All,
>
> It wa  interesting to see the interest during REGEXT IETF 109 
> meeting call to address the the privacy aspects of draft 
> So far my idea to improve the reverse search to first make the JSON 
> object for the required level of privacy critical data. Based on the 
> tag the partial response suppresses the privacy part of responses by 
> encoding and in order to decode it, it must present an identity to 
> federated access control.
> I am also reviewing the hrpc draft to bring some valuable input form 
> their guidance.
> Please let me know what you think and is anyone else interested to 
> work on this?
> Thanks,
> Regards,
> Ali Hussain
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

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