Hi Pavel,
please find my comments embedded below.
Il 26/10/2022 17:56, Pawel Kowalik ha scritto:
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.
[ML] Doesn't make sense to me that the RDAP server could operate as an
IdP proxy for RDAP clients. It's already a bit weird that in this model
the RDAP server acts simultaneously as a Relying Party and a Resource
Server but I admit that, when the RDAP client is a browser, the RDAP
server is the only intermediary application between the end user and
the IdP.
Instead of making the RDAP server more complex, the easy way is that, if
an RDAP client needs PII claims for providing the end user with a better
UX or for any other purpose, it should register with an IdP and ask
those claims to that IdP under the end user consent.
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.
[ML] I see possible drawbacks in both solutions.
Anyway, if I am the only dissonant voice in this discussion, no worries.
Best,
Mario
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
