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.
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.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
