Subject: [regext] A Radical Idea for draft-ietf-regext-rdap-openid

From: "Hollenbeck, Scott" <[email-masked]>
Date: Sun, 30 Jan 2022 14:23:58 +0000

I've been writing my own RDAP server code to test the concepts described in the latest version of draft-ietf-regext-rdap-openid. That's given me some real insight into what works, what doesn't, and how easy or hard it is to use.

An RDAP server that supports OpenID Connect MUST implement basic session management to associate an RDAP query with the redirect that comes back from an OpenID Provider after an end-user is identified and authenticated. That got me thinking: if the server must do session management, how can I make this easier for the client/end-user so that they don't have to deal with the tokens?

Here's my radical idea: change the draft such that it includes login and logout functions and eliminate the externally visible token management functions. Instead of a flow that looks like this:

Client sends RDAP "tokens" query to RDAP server
RDAP server redirects client to OpenID Provider for identification and authentication
OpenID Provider does its thing
OpenID Provider redirects client back to RDAP server with identification and authentication result
RDAP server displays result (including token info if successful) to client
Client sends other RDAP queries to server with ID and token info to authorize each query
Client refreshes or revokes tokens to continue to end token validity

We could do something that looks like this:

Client sends RDAP "login" query to RDAP server
RDAP server redirects client to OpenID Provider for identification and authentication
OpenID Provider does its thing
OpenID Provider redirects client back to RDAP server with identification and authentication result
RDAP server displays result (storing token info in the session) to client
Client sends other RDAP queries to server, server accesses stored info to confirm authorization
Client sends RDAP "logout" query to end a session

This seems easier to me, and it looks more like what people are used to when working with a web service. The login function could return an indication of success or failure, and the set of claims (end-user identification information) that will be used for subsequent commands that require identification, authentication, and authorization. The logout command can return an indication of success or failure.

What do you think?

Scott

---

From: Jothan Frakes <[email-masked]>
Date: Sun, 30 Jan 2022 11:47:14 -0800

Great Idea, Scott.

Let's call those Path A and Path B

Were you envisioning that A or B were ok, or are you suggesting Path B only?

I recommend that either should be possible in order to let this grow faster
in adoption.

If what you described in Path B could be presented as an option, leaving
room for those for whom Path A would be preferred to still use Path A, it
might be best.

I look at the n+1 on integrations that of BERO and registrar systems in the
wild, and then consider there are 5-6 or more OID providers out there.

That is a bit of a matrix.  Also consider all the various topologies of
architecture where systems are isolated for security, there might be a lot
of work forced on Ry/Rr if they have to operate some form of shim to
support Path B automation.

Path B integrations vs just receiving a couple fields on an administrative
panel in Path A also could represent more engineering costs and perhaps in
some cases contractual or financial relationships for use of those systems.

Among the benefits from DNSSEC has been good user journey data on how
additional integration work can hobble adoption, despite all the added
elegance or increased benefits.

-Jothan

On Sun, Jan 30, 2022, 6:24 AM Hollenbeck, Scott <shollenbeck=
[email-masked]> wrote:

> I've been writing my own RDAP server code to test the concepts described
> in the latest version of draft-ietf-regext-rdap-openid. That's given me
> some real insight into what works, what doesn't, and how easy or hard it is
> to use.
>
> An RDAP server that supports OpenID Connect MUST implement basic session
> management to associate an RDAP query with the redirect that comes back
> from an OpenID Provider after an end-user is identified and authenticated.
> That got me thinking: if the server must do session management, how can I
> make this easier for the client/end-user so that they don't have to deal
> with the tokens?
>
> Here's my radical idea: change the draft such that it includes login and
> logout functions and eliminate the externally visible token management
> functions. Instead of a flow that looks like this:
>
> This seems easier to me, and it looks more like what people are used to
> when working with a web service. The login function could return an
> indication of success or failure, and the set of claims (end-user
> identification information) that will be used for subsequent commands that
> require identification, authentication, and authorization. The logout
> command can return an indication of success or failure.
>
> What do you think?
>
> Scott
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 31 Jan 2022 13:45:16 +0000

I’m proposing to replace the token processing path segments (tokens, 
tokens/revoke, and tokens?refresh_token) with login and logout path segments 
that perform the same basic function without requiring the client to manage 
the access, ID, and refresh tokens. Thinking ahead to IESG evaluation and an 
IETF last call, I think it’ll be hard to defend keeping the manual token 
processing stuff in the draft when it just isn’t done that way anywhere else 
(as far as I know).

Scott

From: Jothan Frakes <[email-masked]>
Sent: Sunday, January 30, 2022 2:47 PM
To: Hollenbeck, Scott <[email-masked]>
Cc: Registration Protocols Extensions <[email-masked]>
Subject: [EXTERNAL] Re: [regext] A Radical Idea for 
draft-ietf-regext-rdap-openid

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.

Great Idea, Scott.

I recommend that either should be possible in order to let this grow faster in 
adoption.

If what you described in Path B could be presented as an option, leaving room 
for those for whom Path A would be preferred to still use Path A, it might be 
best.

That is a bit of a matrix.  Also consider all the various topologies of 
architecture where systems are isolated for security, there might be a lot of 
work forced on Ry/Rr if they have to operate some form of shim to support Path 
B automation.

-Jothan

On Sun, Jan 30, 2022, 6:24 AM Hollenbeck, Scott 
<shollenbeck=[email-masked] 
<mailto:[email-masked]> > wrote:

I've been writing my own RDAP server code to test the concepts described in 
the latest version of draft-ietf-regext-rdap-openid. That's given me some real 
insight into what works, what doesn't, and how easy or hard it is to use.

An RDAP server that supports OpenID Connect MUST implement basic session 
management to associate an RDAP query with the redirect that comes back from 
an OpenID Provider after an end-user is identified and authenticated. That got 
me thinking: if the server must do session management, how can I make this 
easier for the client/end-user so that they don't have to deal with the 
tokens?

Client sends RDAP "tokens" query to RDAP server
RDAP server redirects client to OpenID Provider for identification and 
authentication
OpenID Provider does its thing
OpenID Provider redirects client back to RDAP server with identification and 
authentication result
RDAP server displays result (including token info if successful) to client
Client sends other RDAP queries to server with ID and token info to authorize 
each query
Client refreshes or revokes tokens to continue to end token validity

Client sends RDAP "login" query to RDAP server
RDAP server redirects client to OpenID Provider for identification and 
authentication
OpenID Provider does its thing
OpenID Provider redirects client back to RDAP server with identification and 
authentication result
RDAP server displays result (storing token info in the session) to client
Client sends other RDAP queries to server, server accesses stored info to 
confirm authorization
Client sends RDAP "logout" query to end a session

This seems easier to me, and it looks more like what people are used to when 
working with a web service. The login function could return an indication of 
success or failure, and the set of claims (end-user identification 
information) that will be used for subsequent commands that require 
identification, authentication, and authorization. The logout command can 
return an indication of success or failure.

What do you think?

Scott

_______________________________________________
regext mailing list
[email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext 
<https://secure-web.cisco.com/1zdx377Gg36VgLHmhF3lxE4fF1N8qav8pbQixiBfTjCSYwYAO8rJK-ZQ_22ShQwrJlimC9zE4DJwFJCLoCN5fLHe5erII2UvTDoeXGx2WoKVpXD22CL17hRKF8ljfG0Jz_m3LbYYbagAhBIqIsC8nlQQDs2b8JqztQIiLjU_Zv0YDGoX33yBcKbxDUal2g8zD4MU10KIa_GaCeKo5WWqbuorX-Nvn5dmY-OoXhK-OUd-oxHJRdDi0gE0s0vpcfm2d/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>