> -Original Message-
> From: regext On Behalf Of Tom Harrison
> Sent: Tuesday, January 18, 2022 6:14 PM
> To: Mario Loffredo
> Cc: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] id_token parameter usage in rdap-openid
[SAH] snip
> The only difference I can see between the approach used in the draft and
> the approach described in the OIDC specification is that the relationship
> between the RDAP server and the RDAP client is maintained by passing the
> tokens back to the RDAP client, and having the RDAP client include them in
> requests to the server. I don't think this makes the RDAP server an (OAuth)
> resource server, or the RDAP client an (OAuth) client. The fact that the
> RDAP
> server makes authorisation decisions based on the information provided to it
> by the OpenID provider doesn't change this. It seems to me to be analogous
> to an
> (OIDC) relying party (an (OAuth) client) making authorisation decisions
> based
> on the "acr" claim in the ID token (e.g., per the OIDC
> documentation: "[a]uthentications with level 0 SHOULD NOT be used to
> authorize access to any resource of any monetary value").
>
> > For example, now the mostly used access token format is JWT. Such a
> > format is perfectly consistent with the reference pattern because it
> > isn't normally exchanged outside a trusted context.
> >
> > So, with reference to the draft, we cannot say that the access token
> > MUST be opaque but we can say that it MUST be treated as opaque by the
> > RDAP client and, anyway, it MUST NOT include sensitive information.
> >
> > In addition, we cannot say that the RDAP server MUST treat the access
> > token as opaque because it is normally inspected by the RS.
>
> I think updating the document in this way makes it sufficiently different
> from
> the standard OAuth/OIDC model that ensuring that it retains all the
> important properties of those models will be difficult. The fact that the
> RDAP
> client gets the ID token and access token is a little unusual as it is
> (IME), but
> turning the RDAP server into a sort of hybrid (OAuth) client and (OAuth)
> resource server, along with guaranteeing the format and claims in an access
> token, goes quite a bit further than that. This may all be moot, though, if
> using cookies (or similar) to maintain a session between the RDAP client and
> RDAP server is acceptable.
>
> >>> 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.
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?
Scott
__
