Hi Pavel,
Il 29/10/2022 10:59, Pawel Kowalik ha scritto:
Hi Mario,
Am 28.10.22 um 16:36 schrieb Mario Loffredo:
[PK] There is quite relevant drawback from this scenario, that there
is no assurance the identity provided to the RDAP client by the IdP
would be the same as the one used towards the RDAP server if there
is no relation. An IdP may hold more than one identity of the same
user and offer account selection in the authorization step.
[ML] Are you meaning that the two accounts are related to the same
user_id? AFAIK, one can use the same user_id (e.g. the mail) for
signing up with different IdPs. Never heard before it happens within
the same IdP.
[PK] I was rather referring to 2 different user_ids at the same IdP.
In this case if the authorization is done unrelated from the RDAP
client and RDAP server, there is a possible mismatch. Not very likely,
but possible. There are also other cases to consider, where a
mis-configured RDAP server would choose to authenticate the user with
wrong IdP etc.
Anyway, even admitting the unusual case that an end user could select
two different identities in two close authentications, why should the
related PII be absolutely the same if they are used for two different
purposes?
[PK] I don't want to go into discussion whether the purposes are the
same or not, as these are policy questions which may have different
answers for each setup RDAP Client / RDAP Server / IdP. I see a valid
use case for RDAP client to have some level of information about the
user who queried the RDAP server. Especially "rdap" scope is relevant
to RDAP client as it determines which of the query parameters defined
in Section 4.3 can be used within the session not risking 403 responses.
Apart from that, based on my interpretation of GDPR, a generic
third-party client application processing the PII coming from the
RDAP server as claims should be authorized by the end user through a
specific request for consent.
[PK] I would stay away from any interpretation of GDPR in context of
technical protocol. The protocol as proposed allows RDAP server to
apply any policy it find appropriate, including not sharing any data
at all, sharing some or all data without or with consent. It is very
alike OpenID core Section 3.1.2.4. which does not mandate any specific
way of authorization and includes "establishing consent via conditions
for processing the request or other means (for example, via previous
administrative consent)" which is exactly what server policy defines.
[ML] IMO you are not allowed to stay away. I mean, you should address
the potential privacy implications of one single consent authorizing PII
processing for two different purposes by the client and the server.
Beside GDPR, Section 5.2.3 of RFC6973 states that secondary use defined
as "the use of collected information about an individual without the
individual's consent for a purpose different from that for which the
information was collected" is a potential privacy threat to avoid or
mitigate.
Given that usually a public RDAP client is unknown to the RDAP server
and it can't leverage other lawful basis to legitimize its PII
processing, my understanding of that statement is that the draft should
declare somewhere (Privacy Considerations ?) that an additional consent
is required for public clients. With regard to confidential clients, one
consent could be sufficient (am not completely sure) assuming that all
the purposes for PII processing are explicitly declared in the server's
DPP and, presumably, all of them are regulated by contract.
My only concern is that without an option for confidential clients the
choice of options when defining the policy would be limited by the
technical capability of the protocol, because each policy will need to
deal with a case of sharing data to potentially unknown party.
This is because the request for consent from the Authorization Server
regards only the server processing.
BTW, if "scope" is optional, should the farv1_openidcConfiguration
object include a "scopeSupported" property?
[PK] Agreed. I would define it as a list of strings scopes_supported,
same as RFC8414.
In that case, I expect that the empty list will be allowed meaning that
the scope parameter is unsupported.
Best,
Mario
Kind Regards,
Pawel
--
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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
