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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
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: +39.0503153497
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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
