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
