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

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: regext <[e-mail]> On Behalf Of Pawel Kowalik
> Sent: Tuesday, October 18, 2022 3:19 AM
> To: [e-mail]
> 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.
>
> 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.

[SAH] Text would be appreciated. Something like this perhaps?

4.2.5 Web Service Clients

<Paragraph that describes what a web service client is>

4.2.5.1 Web Service Client Login

<Query parameters and/or path segment descriptions>

4.2.5.2 Web Service Client Session Management

<Query parameters and/or path segment descriptions>

> 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.

[SAH] Maybe, pending resolution of what to do with the userClaims.

> >> 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.

[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?

> >> 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.

[SAH] Agreed, pending resolution of what to do with the userClaims. More in my response to Mario in a moment...

Scott