> -----Original Message----- > From: Mario Loffredo <[email protected]> > Sent: Wednesday, November 16, 2022 2:31 AM > To: Hollenbeck, Scott <[email protected]>; > [email protected]; [email protected] > Cc: [email protected] > Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-rdap-openid Post IETF-115
[SAH] [snip] > Why wouldn't it be OpenID? On the contrary, I would say (as a matter of fact > have always said) that it's the classic OpenID scheme where the RDAP server > acts only as a Resource Server and the RDAP client as a Relying Party. > > We all know that OpenID is built on top of OAuth, hence it's absolutely > normal > to talk about OAuth flow between the RDAP client and the RDAP server because > the authentication services are requested by the client before submitting > any > request to the server. At that stage of OpenID flow, authentication is over > and > only the authorization services (i.e the OAuth flow) are needed. > > Up to now, in order to address the use case of browser operating as RDAP > clients, we have forcefully requested the RDAP server to play two roles, > namely > RS and RP, but it's unusual in the OpenID context. > > In addition, the UserInfo endpoint (that the RDAP server can always > access) has been introduced by OpenID. [SAH] My point was that "pure OAuth" doesn't include the identification and authentication functions provided by OpenID Connect. Pawel's reply made it clear that "pure OAuth" was being described in the context of the exchange between the RDAP client and the RDAP server, with the client taking on the responsibility of doing the identification/authentication steps with an OP. That might work. Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
