Hi Scott and Tom,
Il 20/01/2022 03:08, Tom Harrison ha scritto:
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.
[ML] To Tom:
Sorry but I didn't catch how the user identifier is sufficient to
determine the Authorization Server in order to obtain the access token
but then is no more sufficient when the same access token needs to be
validated.
The 'iss' claim (passed as a parameter instead of the "id" parameter
once the access token has been obtained) can be helpful to save the RDAP
server to run the discovery process at every request, However, the
issuer is included in the ID Token so, unless such information was
included in the /tokens response, it should be obtained by decrypting
the ID token.
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?
[ML] To Scott:
I mentioned the session managment because I have a little feeling that
the OIDC pattern described in the draft may result in a inefficiency if
the OP implements session management but, honestly, cannot estimate its
extent.
Session management is an optional OIDC feature. In addition, I'm only
experienced with a local OP, specifically Keycloak, implementing the
session management and I don't know how many OPs operate in the same
manner.
Just to summarize the matter, in OIDC session managment, once the
end-user has been authenticated, a session (in place of an access token)
is exchanged between the web browser and the RP. As a consequence, in
order to comply with the draft spec, the RDAP server (acting as an RP in
the draft) would be required to invalidate the session at every response
and regenerate the security context starting from the access token at
every request.
I just presented my experience so if you think the draft shouldn't
address this topic, I'm OK.
Best,
Mario
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
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
