As I kinda said on that call, I understand the ask and I do think it'd be reasonable to mention refresh tokens in the abstract now that the document does describe binding refresh tokens to the client certificate with public clients.
I'm struggling to see the fix as pretty easy, however, given the text of the abstract (copied below for ease of reference) and the content and scope of the document. Do you think changing the first sentence to have "certificate-bound access and refresh tokens" is sufficient (and accurate)? Or something more or different? In which case proposed text is always welcome. Abstract This document describes OAuth client authentication and certificate- bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci <vittorio.bertocci= 40auth0....@dmarc.ietf.org> wrote: > Hi all, > during today's office hours call I pointed out that oauth-mtls-13's abstract > only mentions access token, although the spec does provide (some) guidance > on refresh token binding as well.. > Although in the end implementers would do the right thing, given that they > have to read the spec in its entirety, having a mention of refresh tokens > in the abstract as well would make it easier for superficial readers to > learn that the spec does address RTs as well. Refresh tokens leakage is one > of the top concerns of the customers I deal with, and those people rarely > read specs from cover to cover: having language in the abstract explicitly > calling out RTs might make some conversations easier. > > This is admittedly very minor, but the fix would also be pretty easy, > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
