> -----Original Message----- > From: Marc Blanchet <[email protected]> > Sent: Tuesday, November 15, 2022 10:57 AM > To: Pawel Kowalik <[email protected]> > Cc: Hollenbeck, Scott <[email protected]>; [email protected] > Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115 > > 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. > > > > Le 15 nov. 2022 à 10:50, Pawel Kowalik <[email protected]> a écrit : > > > > Hi Scott, > > > > Am 15.11.22 um 14:54 schrieb Hollenbeck, Scott: > >> [SAH] Based on the testing you and I've been doing, we already know > >> that web service clients require token processing features that > >> aren't currently specified. That's fixable; earlier versions of the > >> draft included text that was demonstrated to work. However, we also > >> know that login processing will be a problem if the client-side > >> application > can't process third-party cookies. > >> That might be more difficult to overcome. What do you have in mind? > > > > I think for web clients we need to let the clients do the OAuth2 flow on > > their > own, receive tokens from the IdP directly and then use the token to interact > with the RDAP server. > > RDAP server would remain stateless and session-less in the role of OAuth2 > resource server when tokens are in use. > > The draft would be limited to defining profile of the OAuth2 protocol to > maintain interoperability (scopes / claims or flows / endpoints that need to > be > supported etc.) as well as the discovery part of the IdP (likely just a > property > add to what we have in /help already). > > A "pure OAuth2" solution is probably way more warrant of future, IMHO. > > Marc.
[SAH] ...but it's not OpenID Connect, which is the focus of the current draft. Incorporating these concepts into the current draft could mean significant change to generalize from "Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect" to "Federated Authentication for the Registration Data Access Protocol (RDAP)" or "Federated Authentication for the Registration Data Access Protocol (RDAP) using <something else>". I'm not opposed to generalization if it produces a more complete specification, BUT: OAuth doesn't do identification and authentication [1]. A "pure OAuth2" solution would require *something else* to provide identification and authentication. What can we use? [1] https://oauth.net/articles/authentication/ Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
