> -----Original Message----- > From: Pawel Kowalik <[email protected]> > Sent: Wednesday, October 12, 2022 3:35 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 19:07 schrieb Hollenbeck, Scott: > > > >> 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? > > Important factor here is that the document shall leave it open whether the > tokens are issued by the OP or the RDAP server. > > The tokens are opaque to the client and this is up to the implementation of > the > RDAP server to forward the tokens from the OP, to exchange them or generate > own. > > From this perspective also the revocation end-point shall be offered by the > RDAP server as only RDAP server would know what to do to revoke the token > according to the own implementation. > > To keep the solution more flexible we may signal the revocation end-point as > an URL in the /help path, not as a fixed one.
[SAH] I'm still not following. To revoke a token, the RDAP server needs to know who issued it (so the revocation endpoint can be found), and it needs the token itself. How does the RDAP server acquire both if all it receives from the client is a path segment like farv1_token_revocation? A "default" OP can address the first need, but a token still needs to be included in the revocation request. Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
