Am 26.10.22 um 15:48 schrieb Mario Loffredo:
[ML] Before going into detail with technical aspects, think we should
address some privacy implications connected with the following sentence:
RDAP server SHOULD merge the scopes requested by the client with the
scopes needed for authorization purposes when building an
authorization request to OP.
Since the authorization requests would come from the RDAP server
(acting as a registered OpendID client), the request for consent would
be for processing claims by the RDAP server. Hence, only the RDAP
server should be authorized to process the requested claims. Correct?
In addition, IMO the following aspects related to GDPR should be
considered:
- The RDAP server would be entitled to process PII under the consent
lawful basis but the RDAP client wouldn't be allowed to leverage such
a basis for its own PII processing.
- Usually, domain registries have a web page showing their own Data
Protection Policy. In the case where the RDAP server could process
PII, the DPP should state (more or less) that the RDAP server
processes PII only for making access control decision and removes it
at the end of an authenticated session. The DPP should also ensure
that PII is not revealed unintentionally to other parties.
For that said, can't see how such a DPP could cover PII processing by
other application than the RDAP server.
What's your opinion?
[PK] The text was proposed in the way which does not exclude certain
valid use-cases but still allows the RDAP server to set its own policy
on sharing data.
This is clear that RDAP server is acting as sort of Identity Provider
towards its clients, so the similar considerations about data sharing
shall apply. RDAP server may ask the user for the consent about sharing
PII as well, decision is clearly by the RDAP server operator.
The proposal is also not obliging RDAP server to obey to the scope
request from the RDAP client and same time not mandating forwarding any
data to the client.
But if the RDAP server operator is comfortable to do so the protocol
allows for that as well.
One reason why I put confidential clients as an open point is that
currently only supporting public clients which are not authenticated by
any way means that RDAP server has no means to apply different policies
to registered trusted clients. Currently all are same so likely the
least privileged policy would always apply, meaning no PII shared.
A way forward could be to indicate option for confidential clients but
leaving the details up to implementation. The other option is to propose
also a standard way of client authentication within this draft.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
