Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Dick Hardt]

Thanks for pointing out the Oblivious draft Justin. It is interesting, but
looks to be focussed on privacy rather than non-repudiation. Was I missing
non-repudiation aspects?
ᐧ

On Sat, Oct 23, 2021 at 4:55 PM Justin Richer  wrote:

> Dick, you would probably be interested in the Oblivious HTTP effort that
> has recently been chartered to solve similar encapsulation problems in
> HTTP.
>
> - Justin
> 
> From: OAuth [oauth-boun...@ietf.org] on behalf of Dick Hardt [
> dick.ha...@gmail.com]
> Sent: Friday, October 22, 2021 6:08 PM
> To: Richard Backman, Annabelle
> Cc: David Waite; oauth
> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth
> Proof of Possession Tokens with HTTP Message Signature
>
> I have a use case for a self contained request that can be independently
> verified by multiple parties. IE, not just have PoP at HTTP endpoint, but
> by components doing processing further down the line. It also provides
> non-repudiation.
>
> For example, a JWT that is sent as an HTTP payload includes the request
> and the access token.
>
> mTLS, DPoP, and HTTP signing don't provide this functionality
>
> It is not clear if others have similar requirements, or if there is value
> in standardization effort, but I wanted to call out a use case not solved
> by the current efforts.
>
> /Dick
>
> On Wed, Oct 13, 2021 at 2:55 PM Richard Backman, Annabelle  40amazon@dmarc.ietf.org<mailto:40amazon@dmarc.ietf.org>> wrote:
> If keeping DPoP simple means we have to have come up with 10 different
> variants to handle all the different cases that it doesn't support, then it
> isn't keeping it simple, it is just pushing the problem forward to the
> implementers to figure out which set of RFCs to implement.
>
> I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone
> has use cases that aren't covered by one or more of those, they should
> bring those up so we can discuss them and decide what changes are
> warranted. (Either here, or in HTTPbis if changes should be made to Message
> Signatures) My preference would've been to stop at 2, but the consensus has
> not been in favor of expanding the scope of use cases served by DPoP.
>
> [
> https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D=zerocontent=593dd17a-bb93-449b-8126-3b72052d76b2]ᐧ
> <https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D=zerocontent=593dd17a-bb93-449b-8126-3b72052d76b2]%E1%90%A7>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Justin Richer]

Dick, you would probably be interested in the Oblivious HTTP effort that has 
recently been chartered to solve similar encapsulation problems in HTTP. 

- Justin

From: OAuth [oauth-boun...@ietf.org] on behalf of Dick Hardt 
[dick.ha...@gmail.com]
Sent: Friday, October 22, 2021 6:08 PM
To: Richard Backman, Annabelle
Cc: David Waite; oauth
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of 
Possession Tokens with HTTP Message Signature

I have a use case for a self contained request that can be independently 
verified by multiple parties. IE, not just have PoP at HTTP endpoint, but by 
components doing processing further down the line. It also provides 
non-repudiation.

For example, a JWT that is sent as an HTTP payload includes the request and the 
access token.

mTLS, DPoP, and HTTP signing don't provide this functionality

It is not clear if others have similar requirements, or if there is value in 
standardization effort, but I wanted to call out a use case not solved by the 
current efforts.

/Dick

On Wed, Oct 13, 2021 at 2:55 PM Richard Backman, Annabelle 
mailto:40amazon@dmarc.ietf.org>> 
wrote:
If keeping DPoP simple means we have to have come up with 10 different variants 
to handle all the different cases that it doesn't support, then it isn't 
keeping it simple, it is just pushing the problem forward to the implementers 
to figure out which set of RFCs to implement.

I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone has use 
cases that aren't covered by one or more of those, they should bring those up 
so we can discuss them and decide what changes are warranted. (Either here, or 
in HTTPbis if changes should be made to Message Signatures) My preference 
would've been to stop at 2, but the consensus has not been in favor of 
expanding the scope of use cases served by DPoP.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D=zerocontent=593dd17a-bb93-449b-8126-3b72052d76b2]ᐧ
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Dick Hardt]

I have a use case for a self contained request that can be
independently verified by multiple parties. IE, not just have PoP at HTTP
endpoint, but by components doing processing further down the line. It also
provides non-repudiation.

For example, a JWT that is sent as an HTTP payload includes the request and
the access token.

mTLS, DPoP, and HTTP signing don't provide this functionality

It is not clear if others have similar requirements, or if there is value
in standardization effort, but I wanted to call out a use case not solved
by the current efforts.

/Dick

On Wed, Oct 13, 2021 at 2:55 PM Richard Backman, Annabelle  wrote:

> If keeping DPoP simple means we have to have come up with 10 different
> variants to handle all the different cases that it doesn't support, then it
> isn't keeping it simple, it is just pushing the problem forward to the
> implementers to figure out which set of RFCs to implement.
>
>
> I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone
> has use cases that aren't covered by one or more of those, they should
> bring those up so we can discuss them and decide what changes are
> warranted. (Either here, or in HTTPbis if changes should be made to Message
> Signatures) My preference would've been to stop at 2, but the consensus has
> not been in favor of expanding the scope of use cases served by DPoP.
>
> ᐧ
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Justin Richer]

> On Oct 14, 2021, at 8:47 AM, Warren Parad  
> wrote:
> 
> I feel like there are a bunch of pieces of the implementation fundamentally 
> missing here, so we are back to, as it is right now, the draft isn't 
> sufficient.

Of course the draft isn’t sufficient for  publication — that’s what the call 
for adoption is all about! It’s not meant to say “this is done, let’s ship it”, 
it’s meant  to say “this is an idea, let’s finish it in the WG”.

> What prevents the signature from being used without this RFC?

I’m not sure what you’re asking here. HTTP Message Signatures  can be  used 
without the OAuth-specific RFC. Someone could also use HTTP Signatures with 
OAuth tokens without following anything from the OAuth WG. There are people 
doing that today in the wild, using the  predecessors  of the  HTTP Message 
Signatures draft and their own grafting.

> How do you do expect the symmetric key exchange to be oauth compliant?

I can think of a number of approaches that would work: Pre-registration of 
keys, key derivation functions, cloud key escrow systems — these are things 
that the OAuth profile of HTTP Signatures would have to answer, as I laid out 
in my presentation.

> How does the RS know that there is supposed to be a signature, if the client 
> doesn't provide it?

The same way that it knows there’s supposed to be a particular MTLS certificate 
or DPoP Proof today — the token metadata. The RS can get that through 
introspection, through something in the token itself (like the JWT “cnf” 
claim), or some other internal system. 

 — Justin

> 
>   
> Warren Parad
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement Authress 
> .
> 
> 
> On Wed, Oct 13, 2021 at 11:55 PM Richard Backman, Annabelle 
> mailto:richa...@amazon.com>> wrote:
>> If keeping DPoP simple means we have to have come up with 10 different 
>> variants to handle all the different cases that it doesn't support, then it 
>> isn't keeping it simple, it is just pushing the problem forward to the 
>> implementers to figure out which set of RFCs to implement.
> 
> I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone has 
> use cases that aren't covered by one or more of those, they should bring 
> those up so we can discuss them and decide what changes are warranted. 
> (Either here, or in HTTPbis if changes should be made to Message Signatures) 
> My preference would've been to stop at 2, but the consensus has not been in 
> favor of expanding the scope of use cases served by DPoP.
> 
> 
>> If there are really so many cases, then I think we need to focus on 
>> recreating PoP in an extensible way that allows the DPoP to sit on top, and 
>> other RFCs to be layered in without a bunch of RFCs to all have competing 
>> semantics.
> 
> This is what we are doing with Message Signatures. We're providing a general 
> purpose signature mechanism, which higher-level protocols can build on.
> 
> 
>> Here's a great example. I think having an additional header is unjustified, 
>> DPoP, Signature, or whatever you want to call it. But the only thing more 
>> unjustified than that is having different headers for different 
>> implementations of PoP. We can start with a new Draft that just says, PoP 
>> header is X, end of story, might as well call it Authorization-Extra-Info, 
>> and then layer in what you want in there.
> 
> I can see the argument for DPoP including the proof in the `Authorization` 
> header field, since the proof is intrinsically related to the access token 
> and request authorization – not making a judgement on that, as this is the 
> wrong thread and I don't have a horse in that race. Packing everything into a 
> single header field doesn't make sense for Message Signatures, since they may 
> or may not have anything to do with request authorization, access tokens, or 
> anything of the sort. Additionally, the use of separate `Signature-Input` and 
> `Signature` header fields allows us to have a very simple field syntax using 
> Structured Field Values for HTTP 
> , and makes it easy for 
> intermediaries to chain signatures. (E.g., a reverse proxy might add an 
> `X-Forwarded-For` header field, and add a Message Signature covering that 
> header field plus the PoP signature included by the client.) …and I'll stop 
> there lest we dive into topics for the HTTPbis WG.
> 
> —
> Annabelle Backman (she/her)
> richa...@amazon.com 
> 
> 
> 
> 
>> On Oct 13, 2021, at 12:01 PM, Warren Parad > > wrote:
>> 
>> CAUTION: This email originated from outside of the organization. Do not 
>> click links or open attachments unless you can confirm the sender and know 
>> the content is safe.
>> 
>> 
>> If keeping DPoP simple means we have to have come up with 10 different 
>> variants to handle all the different cases that it doesn't support, then it 
>> isn't keeping it 

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Warren Parad]

I feel like there are a bunch of pieces of the implementation fundamentally
missing here, so we are back to, as it is right now, the draft isn't
sufficient. What prevents the signature from being used without this RFC?
How do you do expect the symmetric key exchange to be oauth compliant? How
does the RS know that there is supposed to be a signature, if the client
doesn't provide it?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 13, 2021 at 11:55 PM Richard Backman, Annabelle <
richa...@amazon.com> wrote:

> If keeping DPoP simple means we have to have come up with 10 different
> variants to handle all the different cases that it doesn't support, then it
> isn't keeping it simple, it is just pushing the problem forward to the
> implementers to figure out which set of RFCs to implement.
>
>
> I'm hoping we can stop at 3: mTLS, DPoP, and Justin's draft. If someone
> has use cases that aren't covered by one or more of those, they should
> bring those up so we can discuss them and decide what changes are
> warranted. (Either here, or in HTTPbis if changes should be made to Message
> Signatures) My preference would've been to stop at 2, but the consensus has
> not been in favor of expanding the scope of use cases served by DPoP.
>
>
> If there are really so many cases, then I think we need to focus on
> recreating PoP in an extensible way that allows the DPoP to sit on top, and
> other RFCs to be layered in without a bunch of RFCs to all have competing
> semantics.
>
>
> This is what we are doing with Message Signatures. We're providing a
> general purpose signature mechanism, which higher-level protocols can build
> on.
>
>
> Here's a great example. I think having an additional header is
> unjustified, DPoP, Signature, or whatever you want to call it. But the only
> thing more unjustified than that is having different headers for different
> implementations of PoP. We can start with a new Draft that just says, PoP
> header is X, end of story, might as well call it
> *Authorization-Extra-Info*, and then layer in what you want in there.
>
>
> I can see the argument for DPoP including the proof in the `Authorization`
> header field, since the proof is intrinsically related to the access token
> and request authorization – not making a judgement on that, as this is the
> wrong thread and I don't have a horse in that race. Packing everything into
> a single header field doesn't make sense for Message Signatures, since they
> may or may not have anything to do with request authorization, access
> tokens, or anything of the sort. Additionally, the use of separate
> `Signature-Input` and `Signature` header fields allows us to have a very
> simple field syntax using Structured Field Values for HTTP
> , and makes it easy for
> intermediaries to chain signatures. (E.g., a reverse proxy might add an
> `X-Forwarded-For` header field, and add a Message Signature covering that
> header field plus the PoP signature included by the client.) …and I'll stop
> there lest we dive into topics for the HTTPbis WG.
>
> —
> Annabelle Backman (she/her)
> richa...@amazon.com
>
>
>
>
> On Oct 13, 2021, at 12:01 PM, Warren Parad  wrote:
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
> If keeping DPoP simple means we have to have come up with 10 different
> variants to handle all the different cases that it doesn't support, then it
> isn't keeping it simple, it is just pushing the problem forward to the
> implementers to figure out which set of RFCs to implement.
>
> I would agree with keeping DPoP simple if it meant that 99% of problems
> were solved, in which case the question would be why do we need this RFC,
> and if what is here is so common, then what good is the DPoP one? Simple is
> useless if it is never used.
>
> If there are really so many cases, then I think we need to focus on
> recreating PoP in an extensible way that allows the DPoP to sit on top, and
> other RFCs to be layered in without a bunch of RFCs to all have competing
> semantics.
>
> Here's a great example. I think having an additional header is
> unjustified, DPoP, Signature, or whatever you want to call it. But the only
> thing more unjustified than that is having different headers for different
> implementations of PoP. We can start with a new Draft that just says, PoP
> header is X, end of story, might as well call it
> *Authorization-Extra-Info*, and then layer in what you want in there.
> Then the number of differences through these refactoring between these two
> drafts becomes smaller. Surely we can agree to a draft that contains only
> the semantics that are the same between the existing two, and then reuse
> the same terminology and the same implementation, header name, etc...
>
> We 

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Richard Backman, Annabelle]

Agreed with keeping DPoP simple, which was why I was asking if the proposal 
could indicate it was targeting some of these other use cases.

It's clear from the feedback that the current draft does not clearly express 
these use cases. There is overlap with DPoP – on a technical level, Message 
Signatures ought to be able to handle DPoP's use cases, albeit complexity in 
different places. But not vice-versa.


The current draft being proposed for adoption I believe is fixed to the same 
HTTP properties that DPoP leverages, and thus appears to be targeting the same 
use cases with a different proof expression.

This is a misconception that should get clarified in the draft. One of the core 
concepts behind Message Signatures is that it defines a standard mechanism for 
signature components of an HTTP message and for communicating which components 
are signed, but it does not dictate which components need to be signed. That 
will vary from deployment to deployment, based on which components are 
semantically meaningful. E.g., an RS that accepts POST requests and receives 
parameters in the request body may require that the `Digest` header field be 
signed, whereas one that only accepts GET requests may only need the URL to be 
signed. The draft defines an `Accept-Signature` header field that can be 
included in a message to indicate which components need to be signed.

Justin's draft introduces a requirement that signatures intended to provide PoP 
for OAuth MUST sign the `Authorization` header field, since that's where the 
access token is. Beyond that, RSes can indicate their API-specific signing 
requirements via `Accept-Signature`. (And/or through out-of-band documentation)

The duplication within the token is also a trade-off: it allows an 
implementation to have a white list of acceptable internal values, if say the 
host and path are rewritten by reverse proxies.

I agree, there are trade-offs. For some, especially those already using JWTs 
all over the place, the simplicity of using a format and libraries they are 
already familiar with may outweigh the risk I described.

FWIW, the Message Signatures approach to the situation you described would be 
for the reverse proxy to add an `X-Forwarded-Host` or similar header field, and 
add a signature over that, the `Host` header field, and the client's signature. 
(Message Signatures supports multiple signatures on one message) I like this 
approach as the signatures are guaranteed to be validated against the same data 
the application uses. (Since there's only one copy of the data)

—
Annabelle Backman (she/her)
richa...@amazon.com




On Oct 13, 2021, at 11:41 AM, David Waite 
mailto:da...@alkaline-solutions.com>> wrote:

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle 
mailto:richa...@amazon.com>> wrote:

Those issues that could be addressed without completely redesigning DPoP have 
been discussed within the Working Group multiple times. (See quotes and meeting 
notes references in my previous message) The authors have pushed back on 
extending DPoP to cover additional use cases them due to a desire to keep DPoP 
simple and lightweight. I don't begrudge them that. I think it's reasonable to 
have a "dirt simple" solution, particularly for SPAs given the relative 
limitations of the browser environment.

Other issues are inherent to fundamental design choices, such as the use of JWS 
to prove possession of the key. E.g., you cannot avoid the data duplication 
issue since a JWS signature only covers a specific serialization of the JWT 
header and body.

Agreed with keeping DPoP simple, which was why I was asking if the proposal 
could indicate it was targeting some of these other use cases. The current 
draft being proposed for adoption I believe is fixed to the same HTTP 
properties that DPoP leverages, and thus appears to be targeting the same use 
cases with a different proof expression.

The duplication within the token is also a trade-off: it allows an 
implementation to have a white list of acceptable internal values, if say the 
host and path are rewritten by reverse proxies. It also allows an 
implementation to give richer diagnostic information when receiving 
unacceptable DPoP tokens, which may very well come at runtime from an 
independently-operating portion of an organization reconfiguring intermediaries.

-DW

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Warren Parad]

If keeping DPoP simple means we have to have come up with 10 different
variants to handle all the different cases that it doesn't support, then it
isn't keeping it simple, it is just pushing the problem forward to the
implementers to figure out which set of RFCs to implement.

I would agree with keeping DPoP simple if it meant that 99% of problems
were solved, in which case the question would be why do we need this RFC,
and if what is here is so common, then what good is the DPoP one? Simple is
useless if it is never used.

If there are really so many cases, then I think we need to focus on
recreating PoP in an extensible way that allows the DPoP to sit on top, and
other RFCs to be layered in without a bunch of RFCs to all have competing
semantics.

Here's a great example. I think having an additional header is unjustified,
DPoP, Signature, or whatever you want to call it. But the only thing more
unjustified than that is having different headers for different
implementations of PoP. We can start with a new Draft that just says, PoP
header is X, end of story, might as well call it *Authorization-Extra-Info*,
and then layer in what you want in there. Then the number of differences
through these refactoring between these two drafts becomes smaller. Surely
we can agree to a draft that contains only the semantics that are the same
between the existing two, and then reuse the same terminology and the same
implementation, header name, etc...

We definitely need a PoP RFC, there's no question there (at least I don't
think there is), so let's start with the subset of all pieces that both
sets of authors can agree to.

Is this the list of current concerning limitations?

>
>1. Does not support symmetric keys.
>2. Requires the same key to be used with AS and RSes.
>3. Does not support multiple valid signing keys.
>4. Signed content is copied into the JWT and therefore duplicated
>within the message. This allows for bugs where the verifier fails to check
>that these values match, or performs that check incorrectly. (e.g.,
>assuming case insensitivity)
>5. Only covers the method, scheme, host, and path. Allows for
>additional arbitrary content to be signed, but does not provide any
>guidance or support for defining interoperable extensions.
>6. Depends on JWT, which may be a new dependency, particularly for
>clients that are doing OAuth 2.0 but not OIDC.
>
> Can we narrow this down to the non-negotiables? For instance surely (1),
(4), (6) aren't that bad, sure they may not be optimal for every case. I
can (2) & (3) to be actually limiting and (5) to be easy to allow
extensibility. Would your concerns be at least somewhat be mitigated by
allowing for solutions regarding (2) & (3)?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Oct 13, 2021 at 8:41 PM David Waite  wrote:

>
>
> > On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle <
> richa...@amazon.com> wrote:
> >
> > Those issues that could be addressed without completely redesigning DPoP
> have been discussed within the Working Group multiple times. (See quotes
> and meeting notes references in my previous message) The authors have
> pushed back on extending DPoP to cover additional use cases them due to a
> desire to keep DPoP simple and lightweight. I don't begrudge them that. I
> think it's reasonable to have a "dirt simple" solution, particularly for
> SPAs given the relative limitations of the browser environment.
> >
> > Other issues are inherent to fundamental design choices, such as the use
> of JWS to prove possession of the key. E.g., you cannot avoid the data
> duplication issue since a JWS signature only covers a specific
> serialization of the JWT header and body.
>
> Agreed with keeping DPoP simple, which was why I was asking if the
> proposal could indicate it was targeting some of these other use cases. The
> current draft being proposed for adoption I believe is fixed to the same
> HTTP properties that DPoP leverages, and thus appears to be targeting the
> same use cases with a different proof expression.
>
> The duplication within the token is also a trade-off: it allows an
> implementation to have a white list of acceptable internal values, if say
> the host and path are rewritten by reverse proxies. It also allows an
> implementation to give richer diagnostic information when receiving
> unacceptable DPoP tokens, which may very well come at runtime from an
> independently-operating portion of an organization reconfiguring
> intermediaries.
>
> -DW
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [UNVERIFIED SENDER] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[David Waite]

> On Oct 13, 2021, at 12:26 PM, Richard Backman, Annabelle 
>  wrote:
> 
> Those issues that could be addressed without completely redesigning DPoP have 
> been discussed within the Working Group multiple times. (See quotes and 
> meeting notes references in my previous message) The authors have pushed back 
> on extending DPoP to cover additional use cases them due to a desire to keep 
> DPoP simple and lightweight. I don't begrudge them that. I think it's 
> reasonable to have a "dirt simple" solution, particularly for SPAs given the 
> relative limitations of the browser environment.
> 
> Other issues are inherent to fundamental design choices, such as the use of 
> JWS to prove possession of the key. E.g., you cannot avoid the data 
> duplication issue since a JWS signature only covers a specific serialization 
> of the JWT header and body.

Agreed with keeping DPoP simple, which was why I was asking if the proposal 
could indicate it was targeting some of these other use cases. The current 
draft being proposed for adoption I believe is fixed to the same HTTP 
properties that DPoP leverages, and thus appears to be targeting the same use 
cases with a different proof expression.

The duplication within the token is also a trade-off: it allows an 
implementation to have a white list of acceptable internal values, if say the 
host and path are rewritten by reverse proxies. It also allows an 
implementation to give richer diagnostic information when receiving 
unacceptable DPoP tokens, which may very well come at runtime from an 
independently-operating portion of an organization reconfiguring intermediaries.

-DW
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth