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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 29 Jul 2021 12:16:37 +0000

> -----Original Message-----
> From: Tom Harrison <[email-masked]>
> Sent: Thursday, July 29, 2021 1:45 AM
> To: Hollenbeck, Scott <[email-masked]>
> 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-masked]> On Behalf Of
> >> [email-masked]
> >> Sent: Monday, June 28, 2021 8:29 AM
> >> To: [email-masked]
> >> Cc: [email-masked]
> >> 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