> -----Original Message----- > From: Tom Harrison <[email protected]> > Sent: Thursday, July 29, 2021 1:45 AM > To: Hollenbeck, Scott <[email protected]> > Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid- > 07.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. > > Hi Scott, > > On Mon, Jun 28, 2021 at 12:40:52PM +0000, Hollenbeck, Scott wrote: > >> -----Original Message----- > >> From: I-D-Announce <[email protected]> On Behalf Of > >> [email protected] > >> Sent: Monday, June 28, 2021 8:29 AM > >> To: [email protected] > >> Cc: [email protected] > >> Subject: [EXTERNAL] I-D Action: draft-ietf-regext-rdap-openid-07.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. > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the Registration Protocols Extensions WG > >> of the IETF. > >> > >> Title : Federated Authentication for the Registration > >> Data Access > >> Protocol (RDAP) using OpenID Connect > >> Author : Scott Hollenbeck > >> Filename : draft-ietf-regext-rdap-openid-07.txt > >> Pages : 25 > >> Date : 2021-06-28 > >> > >> Abstract: > >> The Registration Data Access Protocol (RDAP) provides "RESTful" web > >> services to retrieve registration metadata from domain name and > >> regional internet registries. RDAP allows a server to make access > >> control decisions based on client identity, and as such it includes > >> support for client identification features provided by the Hypertext > >> Transfer Protocol (HTTP). Identification methods that require > >> clients to obtain and manage credentials from every RDAP server > >> operator present management challenges for both clients and servers, > >> whereas a federated authentication system would make it easier to > >> operate and use RDAP without the need to maintain server-specific > >> client credentials. This document describes a federated > >> authentication system for RDAP based on OpenID Connect. > > > > [SAH] This version addresses some feedback provided by Mario Loffredo > > and Tom Harrison. See the > > I was reviewing this again, and realised that the provider discovery text is > still > in there (section 3.1.3.1). From discussion some time > back: > > On Tue, Sep 27, 2016 at 02:13:26PM +0000, Hollenbeck, Scott wrote: > > On Tue, Sep 27, 2016 at 09:09:23AM +1000, Tom Harrison wrote: > >> Google doesn't appear to support OpenID Provider Issuer Discovery, as > >> per section 2 of > >> https://secure-web.cisco.com/1L9NEQZM-qSKygxsYxQ32YisafVvl_f- > DvzOP3de > >> o38vVjZPUo1nwcQgRrScW9Ph6SQDJJcqUhS1qQ7xtNoZ3-SSRf2RkFMP- > 7fZTSnFSfYai > >> Xt60Z4C9okyO-8bM-h6PIAiPXwHNudVH91Mqhd45Lxg_EA9ov6- > dmU9KjP23PsKqpm6rQ > >> > o0nT8CWIIgAy0TceUa9uF4b4i356lpXNafrXsKH9cuplHHWuxB8lKvsU9c3Hjf47A > AE1fmVn8XCWnvC/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid- > connect-discovery-1_0.html Do any of the IDPs used by the Verisign > implementation support it? If not, what approach did you take for mapping > from user identifier to IDP? > > > > Thanks for the note, Tom! Have you seen this? > > > > > https://developers.google.com/identity/protocols/OpenIDConnect#discove > > ry > > > > https://accounts.google.com/.well-known/openid-configuration does > > indeed resolve, but what they're doing does not appear to be > > consistent with the OpenID Connect discovery specification for > > identifiers like Gmail addresses. Microsoft doesn't seem to support it > > for Hotmail accounts, either. > > > > The IDPs implemented by Verisign and CZ.NIC support discovery. > > Truthfully, though, I don't know if it makes sense to keep discovery > > in the specification. Discovery makes more sense in the context of > > dynamic provider registration, and manual, off-line registration of > > IDPs might make more sense in our operating environment. > > I think this change still makes sense, so suggested text for 3.1.3.1: > > 3.1.3.1. Provider Discovery > > An RDAP server/RP needs to be able to map a given End-User's > identifier to an OP. The way in which this happens is out of > scope for the purposes of this document. One possible approach > is to use the "OpenID Connect Discovery" protocol [OIDCD].
[SAH] Thanks, Tom. I'll get this into the next update. Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
