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 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
