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> 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 > https://www.ietf.org/mailman/listinfo/regext >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
