> -----Original Message----- > From: Tom Harrison <t...@apnic.net> > Sent: Wednesday, January 19, 2022 9:09 PM > To: Hollenbeck, Scott <shollenb...@verisign.com> > Cc: mario.loffr...@iit.cnr.it; regext@ietf.org > Subject: [EXTERNAL] Re: Re: [regext] id_token parameter usage in rdap- > openid
[SAH] [snip] > > [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. [SAH] According to the OpenID Connect Discovery protocol, it *is* possible to determine the OpenID Provider based on the identifier alone and out-of-band means. See: https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery So, I think we have that covered. > > 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.) [SAH] Understood! Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
