Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-18.txt

[Mario Loffredo <[e-mail]>]

Il 18/10/2022 09:27, Pawel Kowalik ha scritto:
> Am 17.10.22 um 15:32 schrieb Hollenbeck, Scott:
>
>>> [SAH] This update addresses most of the feedback received during the 
>>> recent WG last call. There are still a few open issues for which I'm 
>>> hoping to see WG discussion:
> Thank you Scott.
>>> 1. How do we address web service clients?
>
> [PK] I think the elements we need for web service clients were already 
> elaborated in the discussion over the version 17.
> I'm happy to support with text proposal if needed.
>
>
> One additional point that appeared in the side discussion is whether 
> such client shall be able to request additional claims from the OP.
> Currently the specification only allows RDAP server to request claims 
> which leaves the web client without such possibility, which in turn 
> may end up in a broken experience.
> The proposal here is to add a "scope" query parameter to the /login 
> path which RDAP server may use to request additional claims from the 
> OP on behalf of the client.
>
>>>
>>> 2. Are there any security concerns associated with return of the 
>>> "userID", "iss", and "userClaims" members of the "farv1_session" 
>>> data structure?
>
> [PK] The specification does not foresee any (even optional) 
> authentication of the client application. In this sense each client 
> has to be treated as a public client.
> There is a risk of malicious client obtaining access to those PII data 
> because all the user sees in the consent step is RDAP requesting data 
> to the OP.
> Device flow is in this sense more vulnerable to phishing attacks to 
> obtain PII and also access to RDAP data as such.
> A countermeasure could be the RDAP server offering an own 
> consent/confirmation screen displaying some identifiable information 
> about the client requesting access.

[ML] Sounds unusual to me that an RP asks the end-user for the consent 
for using claims on behalf of another application.

An RP should ask the user for that consent with respect to a precise 
purpose.

In addition, according to what is written about PII in the "Privacy 
Considerations" section of OIDCC, "only necessary UserInfo data should 
be stored at the Client and the Client SHOULD associate the received 
data with the purpose of use statement." (please note that "Client" 
means the RP here)

That said, it seems to me that we are talikng about two different 
purposes for two different applications.

In the proposed OpendID implementation, the RDAP server is the RP and 
its purpose is to make access control decisions based on client identity 
while the RDAP client purpose might be to improve the UX.

Therefore, IMO, an RDAP client other than a browser should be a 
registered application that at login could ask the user for using some 
claims for its own purpose.

As a consequence, the RDAP server shouldn't provide the client with the 
user claims or, alternatively, should return only those claims that 
don't correspond to PII.

>
>>> 3. Anything else I might have inadvertently missed.

[ML] In the following sentence of section 3.1.3.6, I would clarify who 
the word "server" refers to:

The server provides returned claims in the ID Token.

Given that the RDAP server no longer returns the ID Token since version 
-10, guess it refers to the AS. Correct ?

Best,

Mario

>
> [PK] "userClaim" is marked OPTIONAL in 4.1.1 whereas the following 
> chapters indicate it is mandatory most of the times:
>
> 4.2.3.  Login Response
> 4.4.  Session Status
> 4.5.  Session Refresh
>
> I suggested to change:
> ...response MUST include a "farv1_session" data structure that 
> includes a "userClaims" object and a "sessionInfo" object.
>
> to
>
> ..response MUST include a "farv1_session" data structure that includes 
> a "sessionInfo" object and an optional "userClaims" object.
>
>
> Kind Regards,
>
> Pawel
>
> _______________________________________________
> regext mailing list
> [e-mail]
> 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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo