> -----Original Message----- > From: regext <[email protected]> On Behalf Of Pawel Kowalik > Sent: Tuesday, October 18, 2022 3:19 AM > To: [email protected] > 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 _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
