Thank you for the clarification Brian, this makes sense. So for clients not using mtls (or is this only clients using "none"?) to authenticate the tls_client_certificate_bound_access_tokens client metadata property also conditions binding the refresh token. At the cost of the RT being unusable if the client loses or rotates the certificate.
Best, *Filip* On Thu, 14 Mar 2019 at 13:29, Brian Campbell <bcampb...@pingidentity.com> wrote: > Yeah, so regular old RFC 6749 OAuth requires that a refresh token be bound > to the client to whom it was issued. And that confidential clients (those > having established authn credentials) authenticate to the AS when > presenting a refresh token. Thus, for both MTLS methods of OAuth client > authentication, refresh tokens are indirectly certificate-bound through > their binding to a client and its credentials (and the client rotating its > cert doesn't invalidate the refresh token). > > What was added in the -13 revision of the draft (in a new section > https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a > brief description of certificate binding refresh tokens for public clients. > > The ask from Vittorio was a mention of refresh tokens in abstract. Which > seems reasonable. But the proper wording to succinctly and accurately > convey the aforementioned subtleties is proving difficult for me. > > > > > > On Thu, Mar 14, 2019 at 2:26 AM Neil Madden <neil.mad...@forgerock.com> > wrote: > >> 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 >> <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 >> >> > *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
