Point being that since the refresh token is only usable on the IdP then mtls client auth already covers this, and since RTs are long-lasting, it does this better because cert rotation is possible for both mtls methods.
S pozdravem, *Filip Skokan* On Thu, 14 Mar 2019 at 08:07, Filip Skokan <panva...@gmail.com> wrote: > Even before refresh tokens were mentioned in draft 13 i was about to > implement this binding in nodejs oidc-provider, > > the thing i struggled with and ultimately didn't do this was > > 1) if the refresh token is bound to a specific cert then this cert > rotation is out of the question > 2) if having the RT somehow covered is needed, isn't MTLS client auth > already the right thing to do? Especially given it supports cert rotation > > Now the normative language is SHOULD therefore disallowing cert rotation. > Or am I missing something? > > S pozdravem, > *Filip Skokan* > > > On Thu, 14 Mar 2019 at 00:21, Brian Campbell <bcampbell= > 40pingidentity....@dmarc.ietf.org> wrote: > >> 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 >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
