Hi Scott,
Il 2022-10-21 15:46 Hollenbeck, Scott ha scritto:
-----Original Message-----
From: Pawel Kowalik <kowa...@denic.de>
Sent: Friday, October 21, 2022 5:18 AM
To: Hollenbeck, Scott <shollenb...@verisign.com>; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] I-D Action:
draft-ietf-regext-rdap-openid-
18.txt
Caution: This email originated from outside the organization. Do not
click links
or open attachments unless you recognize the sender and know the
content is
safe.
Hi Scott,
Am 20.10.22 um 21:02 schrieb Hollenbeck, Scott:
>> Am 19.10.22 um 14:13 schrieb Hollenbeck, Scott:
>>> [SAH] If the PII data you're referring to is what's included in the
>>> userClaims, this might not be an issue if the claims aren't
>>> returned, correct?
>> Correct
> [SAH] Does anyone object to removing the "userClaims" object from the
> "farv1_session" data structure?
[PK] IMHO it's not the best idea to remove userClaims completely.
PII claims can be useful for UX, there are also non PII claims which
can be
returned, like the Specialized Claims for RDAP, which won't be
possible at all if
we remove userClaims.
The provisions of making userClaims optional, under the policy of the
RDAP
server and adding security considerations are in my eyes the right
measures to
address the concerns.
We also didn't complete the discussion about the web clients, where we
can
also minimise the risks by adding a possibility of confidential
clients if
necessary.
[SAH] OK, if we keep the "userClaims" I probably need to add text to
the Security Considerations section. How about this:
"Some of the responses described in this specification return
information to a client from an RDAP server that is intended to help
the client match responses to queries and manage sessions. Some of
that information, such as the "userClaims" described in Section 4.1.1,
can be personally identifiable and considered sensitive if disclosed
to unauthorized parties. An RDAP server operator SHOULD develop
policies for information disclosure to ensure that personally
identifiable information is disclosed only to clients that are
authorized to process that information."
[ML] Sorry but, based on the last sentence, it appears to be unclear to
me how clients are identified by the server as authorized clients and
leaving such an aspect unspecified purposefully could open the way to
unsecure implementations.
Have two possible solution in mind:
- if it is the server that decides on its own whether a client is
authorized or not, think that the client should be identified in some
way. I personally reject this solution due to the security implications
connected with clients issuing their credentials in clear as GET
parameters of the /farv1_login request.
- otherwise, if a client is authorized by the end user, think text
should clarify that consent for disclosing claims is given explicitly by
the end user.
Anyway, a server should manage errors due to unauthorized clients.
Best,
Mario
Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
