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 <jot...@jothan.com> Sent: Sunday, January 30, 2022 2:47 PM To: Hollenbeck, Scott <shollenb...@verisign.com> Cc: Registration Protocols Extensions <regext@ietf.org> 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. 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=40verisign....@dmarc.ietf.org <mailto:40verisign....@dmarc.ietf.org> > 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: 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 _______________________________________________ regext mailing list regext@ietf.org <mailto:regext@ietf.org> 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>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
