Right - this is what we have implemented. No support for certificate-bound refresh tokens, the client can be configured to require TLS cert client authentication instead.
Neil > On 14 Mar 2019, at 08:09, Filip Skokan <panva...@gmail.com> wrote: > > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
