> -----Original Message----- > From: Pawel Kowalik <[email protected]> > Sent: Wednesday, October 12, 2022 12:36 PM > To: Hollenbeck, Scott <[email protected]>; [email protected] > Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17 - > Clients > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content is > safe. > > 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.
[SAH] I'm going to try to describe an outline for a new section in the draft that covers this. That'll be after I address the "easier" feedback. > > 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. [SAH] OK. > 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. [SAH] 7009 describes the interaction with the Authorization Server. I assume the RDAP client would send the refresh token via POST as described above, and then the RDAP server submits the 7009 revocation request to the authorization server - right? Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
