On Wed, Jan 19, 2022 at 01:22:04PM +0000, Scott Hollenbeck wrote: >>>>> I'm not saying that it is a wrong proposal but it would simply >>>>> result in refactoring the document. We should give answer to some >>>>> questions, such as: should the /tokens endpoint still be useful? >>>>> which information should the token response contain? how could >>>>> refreshment be requested ? >>>> >>>> Without having thought about this in detail: >>>> >>>> - The /tokens endpoint would no longer be useful, and would be >>>> removed. >>>> - Assuming that the RDAP server is able to use cookies to maintain >>>> session state with relevant RDAP clients, then the RDAP server >>>> could handle token refresh transparently. In the event that the >>>> token was expired and could not be refreshed, the RDAP server would >>>> prompt the user to authenticate again. >>> >>> [ML] Personally, I wouldn't object to your proposal. >>> >>> ... >>> >>> Anyway, if there was a consensus on reviewing radically the document >>> to be more compliant with the OIDC reference pattern, I would be pleased. >> >> Does anybody else have any input on this? > > [SAH] I wonder if the changes made in -09 are helpful or not in the > context of this discussion. It's worth re-reading the draft to be > sure.
It looks like the key update is that the ID token is no longer passed to the RDAP server by the RDAP client, with the user's identifier taking the place of that token. However, if the RDAP server has only an access token and a user identifier, it won't be able to determine definitively the authorisation server that it needs to contact to verify that token (I don't think the user's identifier is sufficient for a 1:1 mapping to an authorisation server in this respect). Possibly another option is to pass back the 'iss' claim from the ID token to the RDAP client, and have the RDAP client provide that claim on each request. > Anyway, after thinking about it a bit I don't think we have an issue > with sessions. I'm working with the following assumptions: > > 1. Every RDAP query is a discrete transaction between an RDAP client > and an RDAP server. > 2. Every access token has a validity period. > 3. Every RDAP request that requires federated > authentication/authorization includes an access token. > 4. Access tokens can be refreshed when they get close to the end of > their validity period. > 5. An RDAP query that doesn't include an HTTP Authorization header > should be treated as a request that does not require > authentication/authorization. > > I don't see the need for additional session management features if > these assumptions are valid. A "session" is tied to the validity > period of the access token. The client requests tokens from the RDAP > server (using a /tokens query) and is authenticated as a result of > making that request. If the client can be authenticated, they > receive a set of tokens that can be used for subsequent queries. The > client provides the access token with each query that requires > authentication/authorization. The client refreshes the access token > (sending the refresh token to the RDAP serve using a /tokens query > and a query parameter) as needed, and there's no need for the server > to maintain additional state information. > > Am I missing something? The above is fine (IMHO, as somebody without any particular experience in OAuth/OIDC/security) save for the need to map the request to a given authorisation server. If returning the 'iss' claim to the RDAP client and having the RDAP client include that on subsequent requests solves that problem, while also addressing the concerns around the use of the ID token, then maybe that's the only extra thing that needs to happen. (My suggestion about cookies was mostly about trying to head off the possibility of the RDAP server inspecting the access token directly.) -Tom _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
