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

[Pawel Kowalik <[e-mail]>]

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.

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

[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