Am 12.10.22 um 14:56 schrieb Hollenbeck, Scott:
[SAH] Since the draft already includes text that describes support for two
different types of clients, I'm OK with the idea of adding (or re-adding) text
that describes support for web service clients, too. The challenge is in
deciding how to support those clients.
Pawel, what I had in the earlier versions of the draft worked liked this:
Client requests access, ID, and refresh tokens by sending a query to the RDAP
server.
RDAP server retrieves tokens from the OP and returns them to the client.
The access token can then be passed to the server for use with an RDAP query
by including the encoded token in an HTTP Bearer authorization header.
Does this address the issue?
Yes, this addresses the issue, requires some added elements however.
Keeping the flow as per draft version 17, with farv1_session/login path
starting the authentication and authorisation, we cannot deliver the
tokens as a response directly. This flow has to finish with a HTTP
redirect back to the client which initiated the flow. It requires
appropriate query parameters redirect_uri and state added to the
farv1_session/login path.
For the tokens I propose then to add a dedicated path
farv1_session/tokens which can be queried after successful
authentication, otherwise 401 error code. CORS requirements need to be
added here, so that this endpoint can be reached within the same session.
I'm not confident that the token refresh and revocation descriptions in -09
are workable, though. It describes passing the refresh token as a query
parameter; can that work? Can a refresh token be passed in an authorization
header?
I would follow the pattern of RFC 6749 Section 6, so a POST request to
farv1_session/tokens with refresh_token in
"application/x-www-form-urlencoded" parameters. Response would then be
the new set of tokens.
For the token revocation RFC 7009 can be used as-is, all we'd need to
specify would be the path segment like farv1_token_revocation and add
signalling if the RDAP server supports it or not in the /help response.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
