Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Brian Campbell]

Your point about refresh tokens having a different threat model to access
tokens is taken, however, I think I'd stop short of saying a private key is
always at the same risk.

I will be at OSW next week and look forward to your presentation. Hopefully
it'll help me better understand the threat model and goals and constraints
and etc. you are working with.

As far as the document is concerned, there are folks that are interested in
the cert-binding of refresh tokens for public clients. So I don't it should
be removed. The text in -13 has a SHOULD for it so your case of not
cert-binding RTs is still within the lines of the spec. But perhaps that
SHOULD can be loosened and/or qualified somewhat so as to better
accommodate that case. I was trying to avoid it, but introducing a client
metadata flag to toggle the RT binding behavior is also a potential option.

On Thu, Mar 14, 2019 at 1:49 PM Neil Madden 
wrote:

> Comments in-line:
>
> On 14 Mar 2019, at 18:50, Brian Campbell 
> wrote:
>
> Certificate-binding refresh tokens issued to *public clients* (those that
> don't have authentication credentials established with the AS, a.k.a.
> clients configured or registered with the "none" authentication method,
> which will typically be native apps on a phone or similar) adds protections
> against malicious use or reuse of those refresh tokens where no protections
> would otherwise exist.
>
>
> Refresh tokens have a different threat model to access tokens as they are
> only communicated directly between the client and the AS over a secure
> channel. The main risk is of them being compromised on the client [*], but
> then a private key is at the same risk. Even if you generate the private
> key in a TPM on the device (eg mobile device with secure hardware), any
> malicious actor that is able to extract the refresh token from the client
> is also presumably in a position to either proxy requests through an
> existing TLS connection on that client or else interact with the TPM to
> create a new one.
>
> [*] Or by a compromise of TLS, but that breaks everything.
>
> It's true that certificate rotation in that situation would invalidate the
> refresh token. But not being able to rotate a strong asymmetric credential
> without invaliding the refresh token seems a very reasonable trade off vs..
> not having a credential bound to the token at all.
>
>
> I would not make that trade-off. If you are at OSW next week, I am
> presenting some cases for OAuth mTLS in a kubernetes environment that have
> public clients with long-lived grants that use refresh tokens to
> periodically rotate certs.
>
> I guess I would say that what is returned when introspecting such a
> refresh token is an implementation detail that is at the discretion of said
> implementation. That seems consistent with the level of guidance in
> introspection for refresh tokens currently. And there's not really an
> interoperability angle that I can see. So that seems fine. Also, some form
> of authorization is required to access the introspection endpoint so I'm
> not sure how a refresh token issued to a public client would realistically
> get introspected. I guess, if I'm being honest, I don't really get refresh
> token introspection in general so probably better that I stop opining on
> the subject.
>
>
> Ok, I’m happy to just ignore that aspect for refresh tokens then.
>
> — Neil
>
>
>
>
>
>
>
> On Thu, Mar 14, 2019 at 7:13 AM Neil Madden 
> wrote:
>
>> It’s not clear to me how this works or what problem it is solving. If a
>> refresh token is bound to the certificate, does that mean that a call to
>> the introspection endpoint with that refresh token should also return a
>> “cnf” claim as per
>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ?
>>
>> It also seems problematic to implement this for refresh tokens. As
>> mentioned by Filip, rotation of the certificate is out of the question.
>> Currently in our implementation a client could present a new certificate
>> when using the refresh token and this would result in the newly issued
>> access token being bound to the new certificate. If the refresh token is
>> bound to the original certificate, then this would be ruled out (the new
>> certificate would be rejected) and certificate rotation becomes impossible
>> in all cases. Am I missing something?
>>
>> — Neil
>>
>> > On 14 Mar 2019, at 12:28, Brian Campbell 
>> 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 

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Neil Madden]

Comments in-line:

> On 14 Mar 2019, at 18:50, Brian Campbell  wrote:
> 
> Certificate-binding refresh tokens issued to *public clients* (those that 
> don't have authentication credentials established with the AS, a.k.a. clients 
> configured or registered with the "none" authentication method, which will 
> typically be native apps on a phone or similar) adds protections against 
> malicious use or reuse of those refresh tokens where no protections would 
> otherwise exist.

Refresh tokens have a different threat model to access tokens as they are only 
communicated directly between the client and the AS over a secure channel.. The 
main risk is of them being compromised on the client [*], but then a private 
key is at the same risk. Even if you generate the private key in a TPM on the 
device (eg mobile device with secure hardware), any malicious actor that is 
able to extract the refresh token from the client is also presumably in a 
position to either proxy requests through an existing TLS connection on that 
client or else interact with the TPM to create a new one. 

[*] Or by a compromise of TLS, but that breaks everything. 

> It's true that certificate rotation in that situation would invalidate the 
> refresh token. But not being able to rotate a strong asymmetric credential 
> without invaliding the refresh token seems a very reasonable trade off vs. 
> not having a credential bound to the token at all. 

I would not make that trade-off. If you are at OSW next week, I am presenting 
some cases for OAuth mTLS in a kubernetes environment that have public clients 
with long-lived grants that use refresh tokens to periodically rotate certs. 

> I guess I would say that what is returned when introspecting such a refresh 
> token is an implementation detail that is at the discretion of said 
> implementation. That seems consistent with the level of guidance in 
> introspection for refresh tokens currently. And there's not really an 
> interoperability angle that I can see. So that seems fine. Also, some form of 
> authorization is required to access the introspection endpoint so I'm not 
> sure how a refresh token issued to a public client would realistically get 
> introspected. I guess, if I'm being honest, I don't really get refresh token 
> introspection in general so probably better that I stop opining on the 
> subject. 

Ok, I’m happy to just ignore that aspect for refresh tokens then. 

— Neil

> 
> 
> 
> 
> 
> 
>> On Thu, Mar 14, 2019 at 7:13 AM Neil Madden  
>> wrote:
>> It’s not clear to me how this works or what problem it is solving.. If a 
>> refresh token is bound to the certificate, does that mean that a call to the 
>> introspection endpoint with that refresh token should also return a “cnf” 
>> claim as per 
>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ? 
>> 
>> It also seems problematic to implement this for refresh tokens. As mentioned 
>> by Filip, rotation of the certificate is out of the question. Currently in 
>> our implementation a client could present a new certificate when using the 
>> refresh token and this would result in the newly issued access token being 
>> bound to the new certificate. If the refresh token is bound to the original 
>> certificate, then this would be ruled out (the new certificate would be 
>> rejected) and certificate rotation becomes impossible in all cases. Am I 
>> missing something?
>> 
>> — Neil
>> 
>> > On 14 Mar 2019, at 12:28, Brian Campbell  
>> > 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  
>> > 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  wrote:
>> > 
>> >> Point being that since the refresh token is only usable on the IdP then 
>> >> mtls client auth already covers this, and since RTs 

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[George Fletcher]

The one use case I've run across for introspecting refresh_tokens is to 
determine the lifetime of the refresh_token (i.e. when it expires). Some 
authorization servers bind the refresh_token to the user's 
authentication session and hence they have a defined lifetime. I suppose 
another use case might be to determine all the scopes that were issued 
to the refresh_token. That of course should require the correct 
authorization at the introspection endpoint in order to obtain the scope 
data:)


On 3/14/19 2:50 PM, Brian Campbell wrote:
Certificate-binding refresh tokens issued to *public clients* (those 
that don't have authentication credentials established with the AS, 
a.k.a. clients configured or registered with the "none" authentication 
method, which will typically be native apps on a phone or similar) 
adds protections against malicious use or reuse of those refresh 
tokens where no protections would otherwise exist. It's true that 
certificate rotation in that situation would invalidate the refresh 
token. But not being able to rotate a strong asymmetric credential 
without invaliding the refresh token seems a very reasonable trade off 
vs. not having a credential bound to the token at all.


I guess I would say that what is returned when introspecting such a 
refresh token is an implementation detail that is at the discretion of 
said implementation. That seems consistent with the level of guidance 
in introspection for refresh tokens currently. And there's not really 
an interoperability angle that I can see. So that seems fine. Also, 
some form of authorization is required to access the introspection 
endpoint so I'm not sure how a refresh token issued to a public client 
would realistically get introspected. I guess, if I'm being honest, I 
don't really get refresh token introspection in general so probably 
better that I stop opining on the subject.







On Thu, Mar 14, 2019 at 7:13 AM Neil Madden > wrote:


It’s not clear to me how this works or what problem it is solving.
If a refresh token is bound to the certificate, does that mean
that a call to the introspection endpoint with that refresh token
should also return a “cnf” claim as per
https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2
 ?

It also seems problematic to implement this for refresh tokens. As
mentioned by Filip, rotation of the certificate is out of the
question. Currently in our implementation a client could present a
new certificate when using the refresh token and this would result
in the newly issued access token being bound to the new
certificate. If the refresh token is bound to the original
certificate, then this would be ruled out (the new certificate
would be rejected) and certificate rotation becomes impossible in
all cases. Am I missing something?

— Neil

> On 14 Mar 2019, at 12:28, Brian Campbell
mailto: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
mailto: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 mailto: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 mailto:panva@gmail.com>> wrote:
>> Even before refresh tokens were mentioned in draft 13 i was
about to implement this binding in nodejs 

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Brian Campbell]

Certificate-binding refresh tokens issued to *public clients* (those that
don't have authentication credentials established with the AS, a.k.a.
clients configured or registered with the "none" authentication method,
which will typically be native apps on a phone or similar) adds protections
against malicious use or reuse of those refresh tokens where no protections
would otherwise exist. It's true that certificate rotation in that
situation would invalidate the refresh token. But not being able to rotate
a strong asymmetric credential without invaliding the refresh token seems a
very reasonable trade off vs. not having a credential bound to the token at
all.

I guess I would say that what is returned when introspecting such a refresh
token is an implementation detail that is at the discretion of said
implementation. That seems consistent with the level of guidance in
introspection for refresh tokens currently. And there's not really an
interoperability angle that I can see. So that seems fine. Also, some form
of authorization is required to access the introspection endpoint so I'm
not sure how a refresh token issued to a public client would realistically
get introspected. I guess, if I'm being honest, I don't really get refresh
token introspection in general so probably better that I stop opining on
the subject.






On Thu, Mar 14, 2019 at 7:13 AM Neil Madden 
wrote:

> It’s not clear to me how this works or what problem it is solving.. If a
> refresh token is bound to the certificate, does that mean that a call to
> the introspection endpoint with that refresh token should also return a
> “cnf” claim as per
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ?
>
> It also seems problematic to implement this for refresh tokens. As
> mentioned by Filip, rotation of the certificate is out of the question.
> Currently in our implementation a client could present a new certificate
> when using the refresh token and this would result in the newly issued
> access token being bound to the new certificate. If the refresh token is
> bound to the original certificate, then this would be ruled out (the new
> certificate would be rejected) and certificate rotation becomes impossible
> in all cases. Am I missing something?
>
> — Neil
>
> > On 14 Mar 2019, at 12:28, Brian Campbell 
> 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 
> 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  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  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  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 

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Brian Campbell]

Yeah Filip, that's about right. Currently the text says to do it only for
public clients (clients using "none").

On Thu, Mar 14, 2019 at 6:53 AM Filip Skokan  wrote:

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

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Neil Madden]

It’s not clear to me how this works or what problem it is solving. If a refresh 
token is bound to the certificate, does that mean that a call to the 
introspection endpoint with that refresh token should also return a “cnf” claim 
as per https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ? 

It also seems problematic to implement this for refresh tokens. As mentioned by 
Filip, rotation of the certificate is out of the question. Currently in our 
implementation a client could present a new certificate when using the refresh 
token and this would result in the newly issued access token being bound to the 
new certificate. If the refresh token is bound to the original certificate, 
then this would be ruled out (the new certificate would be rejected) and 
certificate rotation becomes impossible in all cases. Am I missing something?

— Neil

> On 14 Mar 2019, at 12:28, Brian Campbell  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  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  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  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 
>>  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 
>>  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 

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Filip Skokan]

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

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Brian Campbell]

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

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Neil Madden]

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

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Filip Skokan]

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

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Filip Skokan]

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

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Brian Campbell]

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

[OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Vittorio Bertocci]

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