Hi Mario,
Am 29.10.22 um 16:41 schrieb Mario Loffredo:
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.
[PK] The current draft allows the RDAP server to add any interactive
step in between RDAP "login" request and the response, so if needed RDAP
server MAY add a second consent according to own policy and legal
requirements. I agree that 2 consents are not the best possible UX, but
keeping it open for RDAP server operator to decide is for me the best
option as only the RDAP server operator knows its policy and legal
requirements.
We may add some text around it to 3.2.1 (as an optional step in the
process) and/or 4.2 to give implementers a clear indication of this
consideration to take when implementing the server. A separate "Privacy
Considerations" section is another possible approach. @Scott, what would
you suggest?
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.
[PK] RFC8414 defines it like this scopes_supported RECOMMENDED. JSON
array containing a list of the OAuth 2.0 [RFC6749] "scope" values that
this authorization server supports.
Servers MAY choose not to advertise some supported scope values
even when this parameter is used.
With this definition an empty list may also mean the parameter is
supported but the server does not specify its allowed values. RFC6749
also does not have to cope with "scope" not supported as it is a
mandatory parameter in OAuth2.
We may take a guidance of OpenID Connect Discovery, where 2 server
metadata items are used in analog case for claims parameter:
claims_parameter_supported (bool) and claims_supported (list of strings).
So for our case it would be scope_parameter_supported and scopes_supported.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
