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

[Mario Loffredo <[e-mail]>]

Hi Ali,

please find my comments inline.

Il 22/12/2020 07:33, Ali Hussain ha scritto:
> Hi Dr. Mario,
[ML] please simply Mario :-)
>
> Apologies for replying too late.
>
> First of all thanks for your detailed comments about the proposed 
> tentative iea to make reverse search more privacy complaints keeping 
> hrpc guidelines as reference.
>
> One possible new work in giving better privacy to reverse search would 
> be to have privacy by design implementation in addition to federated 
> access using HTTP and limiting the response. The proposed mechanism 
> may use an integrity protection mechanism HMAC or standard 
> authorization mechnaum like JSON web token to bring in additional data 
> confidentiality and privacy benefits. This way we would be able to 
> easily define the custom access control policies.
>
> What do you think about it.?

[ML] The WG has already adopted a document written by Scott Hollenbeck 
(i.e. https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid 
<https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid>) about 
how to implement a federated authentication in RDAP context. OpenId is 
based on tokens exchanged between the various actors involved (e.g. RDAP 
client, RDAP server, Authorization Server). In particular, the ID Token 
is provided according the JWT format and contains information regarding 
the user identification and a set of claims describing the user. The 
RDAP server can then make identification, authorization, and access 
control decisions based on local policies and the information included 
in the ID Token.

Furthermore, the rdap-openid document defines RDAP specific claims in 
addition to the standard ones. In my opinion, the combination of OpenId 
and RDAP specific claims are appropriate to make an authorization 
decision for a client submitting a reverse search. Especially the set of 
values defined for the "purpose" claim seems to me comprehensive enough 
to include purposes which might be used to legitimate a reverse search 
request. Note also that the set of admissible "purpose" values can be 
extended.

Therefore, it seems to me that your requirements/solutions have been 
addressed by rdap-openid.

Definitively, reverse search is only one of the possible queries clients 
can submit and servers can authorize so I don't think we need to add in 
the reverse-search draft anything beyond what is stated by RFC7481 and 
rdap-openid.

Neither we must explicitly require an RDAP provider to accept always a 
reverse search only if previously authorized. As it is stated in section 
7, we can only require that this capability must be compliant with the 
rules about privacy protection each RDAP provider is subject to and each 
RDAP provider is responsible for pursuing this objective.


Best,

Mario

>
> Thanks,
>
> Regards,
> Ali Hussain
>
>
> On Fri, Dec 4, 2020 at 1:27 AM Mario Loffredo 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     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
>>     (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
>>
>>     _______________________________________________
>>     regext mailing list
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/regext  <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: [phone]
>     Web:http://www.iit.cnr.it/mario.loffredo  <http://www.iit.cnr.it/mario.loffredo>
>
-- 
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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo