[OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"

[George Fletcher]

Goals:

1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended
for that RS

Other high-level goals?

Use cases:

1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports
the jabber API)
4. Client that dynamically supports new AS

Feel free to add to the list :)

[Thomas Broyer]

Note that goal #2 is already taken care of by introspection (endpoint
varying response depending on authenticated client/RS), so maybe should be
refined here.

Post by George Fletcher
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended
for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports
the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[George Fletcher]

I was thinking of goal #2 as addressing the issue of audience in the
token. If the RS "authenticates" itself when calling introspection, then
the AS could apply the audience restriction for the RS. Is that what you
were thinking?

Post by Thomas Broyer
Note that goal #2 is already taken care of by introspection (endpoint
varying response depending on authenticated client/RS), so maybe
should be refined here.
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended
for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports
the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Justin Richer]

I'm with George. You can do introspection with no audience restriction.
We implemented introspection with only scope restriction from the RS.

-- Justin

Post by George Fletcher
I was thinking of goal #2 as addressing the issue of audience in the
token. If the RS "authenticates" itself when calling introspection,
then the AS could apply the audience restriction for the RS. Is that
what you were thinking?

Post by Thomas Broyer
Note that goal #2 is already taken care of by introspection (endpoint
varying response depending on authenticated client/RS), so maybe
should be refined here.
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended
for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports
the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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

[Thomas Broyer]

Post by George Fletcher
I was thinking of goal #2 as addressing the issue of audience in the
token. If the RS "authenticates" itself when calling introspection, then
the AS could apply the audience restriction for the RS. Is that what you
were thinking?

Yes (or I think so).
Scopes are declared in relation to "applications" (which can be either
clients or RS), and our introspection endpoint returns {"active":false} if
there's no matching scopes between what the "application" has declared and
those of the token.
We actually do "scope restriction" (only returning the scopes related to
the requesting application), with the added rule that if there's no scope
left we return {"active":false} rather than an empty list of scopes.

[George Fletcher]

This is pretty much what we do today as well. The additional goal is to
specifically bind tokes to a particular resource outside the context of
the scope value. Just like in SAML, the RS would not process any token
which was not specifically created for use with that RS. So it's an
additional layer of protection beyond scopes.

Thanks,
George

Post by George Fletcher
I was thinking of goal #2 as addressing the issue of audience in
the token. If the RS "authenticates" itself when calling
introspection, then the AS could apply the audience restriction
for the RS. Is that what you were thinking?
Yes (or I think so).
Scopes are declared in relation to "applications" (which can be either
clients or RS), and our introspection endpoint returns
{"active":false} if there's no matching scopes between what the
"application" has declared and those of the token.
We actually do "scope restriction" (only returning the scopes related
to the requesting application), with the added rule that if there's no
scope left we return {"active":false} rather than an empty list of scopes.

[Brian Campbell]

The "a. wrong AS /token endpoint" is the mix-up issue, which can be
mitigated by returning an identifier for the AS in the authorization
response. It is something that needs to be addressed but "discovery" or
metadata aren't needed and audience restricted access tokens tokens don't
help.

Maybe that's obvious but there seems to be a lot of confusion on all this
so I wanted to reiterate it.

Post by George Fletcher
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended
for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports
the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt (IDM)]

There are two variations.

Mitm the token endpoint is different then working one legit token endpoint against another thru redirect and state misdirection.

In the mitm version you don't need multiple AS's.

Phil

The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated by returning an identifier for the AS in the authorization response. It is something that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access tokens tokens don't help.
Maybe that's obvious but there seems to be a lot of confusion on all this so I wanted to reiterate it.

Post by George Fletcher
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

How does one Mitm the token endpoint?

Post by Phil Hunt (IDM)
There are two variations.
Mitm the token endpoint is different then working one legit token endpoint
against another thru redirect and state misdirection.
In the mitm version you don't need multiple AS's.
Phil
The "a. wrong AS /token endpoint" is the mix-up issue, which can be
mitigated by returning an identifier for the AS in the authorization
response. It is something that needs to be addressed but "discovery" or
metadata aren't needed and audience restricted access tokens tokens don't
help.
Maybe that's obvious but there seems to be a lot of confusion on all this
so I wanted to reiterate it.

Post by George Fletcher
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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

[Phil Hunt]

By convincing the client to use a bad URL. That’s kinda why we’re worried about bad discovery no?

Depending on the type of client authentication, the client will establish a valid connection to the hacker’s proxy which then replays the token request to the real endpoint. The hacker now has the token.

Same thing for the resource endpoint - except worse. The hacker doesn’t need the token as they now see the payload.

Phil

@independentid

Post by Brian Campbell
How does one Mitm the token endpoint?
There are two variations.
Mitm the token endpoint is different then working one legit token endpoint against another thru redirect and state misdirection.
In the mitm version you don't need multiple AS's.
Phil

The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated by returning an identifier for the AS in the authorization response. It is something that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access tokens tokens don't help.
Maybe that's obvious but there seems to be a lot of confusion on all this so I wanted to reiterate it.
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

[John Bradley]

The Mitigation we agreed on for the bad token endpoint is returning the issuer and client_id form the authorization endpoint.

Phil are you saying that you no longer agree with that?

The question that was unresolved was how the client would get a bad resource URI, and what the correct mitigation is if any.

John B.

Post by Phil Hunt
By convincing the client to use a bad URL. That’s kinda why we’re worried about bad discovery no?
Depending on the type of client authentication, the client will establish a valid connection to the hacker’s proxy which then replays the token request to the real endpoint. The hacker now has the token.
Same thing for the resource endpoint - except worse. The hacker doesn’t need the token as they now see the payload.
Phil
@independentid

Post by Brian Campbell
How does one Mitm the token endpoint?
There are two variations.
Mitm the token endpoint is different then working one legit token endpoint against another thru redirect and state misdirection.
In the mitm version you don't need multiple AS's.
Phil

The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated by returning an identifier for the AS in the authorization response. It is something that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access tokens tokens don't help.
Maybe that's obvious but there seems to be a lot of confusion on all this so I wanted to reiterate it.
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

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

[Phil Hunt]

John,

I haven’t changed my mind. But I now think we’ve come away with a different understanding of the threats.

I recall that we agreed that “iss” and “client_id” are for mitigating mix-up, by allowing a client to figure out what token endpoint a grant is for. There is nothing that helps a client to determine that the token endpoint it is about to use is valid. IOW. The client could have the correct “iss” and “client_id” from the AS authorization endpoint, but it thinks it is supposed to pass the grant to token.evil.com instead of token.example.com to redeem it.

Phil

@independentid

Post by John Bradley
The Mitigation we agreed on for the bad token endpoint is returning the issuer and client_id form the authorization endpoint.
Phil are you saying that you no longer agree with that?
The question that was unresolved was how the client would get a bad resource URI, and what the correct mitigation is if any.
John B.

Post by Phil Hunt
By convincing the client to use a bad URL. That’s kinda why we’re worried about bad discovery no?
Depending on the type of client authentication, the client will establish a valid connection to the hacker’s proxy which then replays the token request to the real endpoint. The hacker now has the token.
Same thing for the resource endpoint - except worse. The hacker doesn’t need the token as they now see the payload.
Phil
@independentid

Post by Brian Campbell
How does one Mitm the token endpoint?
There are two variations.
Mitm the token endpoint is different then working one legit token endpoint against another thru redirect and state misdirection.
In the mitm version you don't need multiple AS's.
Phil

The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated by returning an identifier for the AS in the authorization response. It is something that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access tokens tokens don't help.
Maybe that's obvious but there seems to be a lot of confusion on all this so I wanted to reiterate it.
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

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

[John Bradley]

The mitigation prevents the client from sending the code to a token endpoint that is not associated with the AS returning the code.

I think you need to describe a MiTM attack on the token endpoint that the proposed mitigation that was reviewed by the researchers doesn’t mitigate.

You seem to have defined some new attacks as not being the confused client attacks that you are trying to mitigate.

Perhaps not understanding the attack is causing some of us to not understand the value of the mitigation you propose.

John B.

Post by Phil Hunt
John,
I haven’t changed my mind. But I now think we’ve come away with a different understanding of the threats.
I recall that we agreed that “iss” and “client_id” are for mitigating mix-up, by allowing a client to figure out what token endpoint a grant is for. There is nothing that helps a client to determine that the token endpoint it is about to use is valid. IOW. The client could have the correct “iss” and “client_id” from the AS authorization endpoint, but it thinks it is supposed to pass the grant to token.evil.com <http://token.evil.com/> instead of token.example.com <http://token.example.com/> to redeem it.
Phil
@independentid

Post by John Bradley
The Mitigation we agreed on for the bad token endpoint is returning the issuer and client_id form the authorization endpoint.
Phil are you saying that you no longer agree with that?
The question that was unresolved was how the client would get a bad resource URI, and what the correct mitigation is if any.
John B.

Post by Phil Hunt
By convincing the client to use a bad URL. That’s kinda why we’re worried about bad discovery no?
Depending on the type of client authentication, the client will establish a valid connection to the hacker’s proxy which then replays the token request to the real endpoint. The hacker now has the token.
Same thing for the resource endpoint - except worse. The hacker doesn’t need the token as they now see the payload.
Phil
@independentid

Post by Brian Campbell
How does one Mitm the token endpoint?
There are two variations.
Mitm the token endpoint is different then working one legit token endpoint against another thru redirect and state misdirection.
In the mitm version you don't need multiple AS's.
Phil

The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated by returning an identifier for the AS in the authorization response. It is something that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access tokens tokens don't help.
Maybe that's obvious but there seems to be a lot of confusion on all this so I wanted to reiterate it.
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

[John Bradley]

You still have a good AS and a bad AS it is just that the bad AS is using the good AS’s authorization endpoint.

I guess it comes down to how you define what a AS is if it is malicious.

Remember all of the attacks postulated in the papers require a xsrf attack or man in the network to cause a client to start a authorization with the bad AS triggering bad discovery and registration.

If the bad AS is publishing a malicious RS and the “good” registration, authorization, and token endpoints. It will have a different issuer from the
good AS authorization endpoint. When the client performs authorization thinking it is going to bad AS and gets back the issuer for good AS that will trigger an error in the client and it will never present the AT to the bad RS’s resource endpoint.

If the developer hard codes some bad RS endpoint in the client then, I admit returning the iss and client_id from the authorization endpoint won’t help.

John B.

Post by Phil Hunt (IDM)
There are two variations.
Mitm the token endpoint is different then working one legit token endpoint against another thru redirect and state misdirection.
In the mitm version you don't need multiple AS's.
Phil

The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated by returning an identifier for the AS in the authorization response. It is something that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access tokens tokens don't help.
Maybe that's obvious but there seems to be a lot of confusion on all this so I wanted to reiterate it.
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

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

[Phil Hunt]

John

You are trying to solve a completely different problem.

In the bad discovery scenario there is no good AS and bad AS.

1. There is only one AS and one RS infrastrucutre

2. The client is mis-configured because it has been given a bad endpoint for one of dyn-reg, token, or resource

The client has no way to know what constitutes a valid set of endpoints.

The AS is acting in good faith in all respects. It become promiscuous because it is turning over grants and/or tokens over to clients that are sending them to a bad endpoint.

Phil

@independentid

Post by John Bradley
You still have a good AS and a bad AS it is just that the bad AS is using the good AS’s authorization endpoint.
I guess it comes down to how you define what a AS is if it is malicious.
Remember all of the attacks postulated in the papers require a xsrf attack or man in the network to cause a client to start a authorization with the bad AS triggering bad discovery and registration.
If the bad AS is publishing a malicious RS and the “good” registration, authorization, and token endpoints. It will have a different issuer from the
good AS authorization endpoint. When the client performs authorization thinking it is going to bad AS and gets back the issuer for good AS that will trigger an error in the client and it will never present the AT to the bad RS’s resource endpoint.
If the developer hard codes some bad RS endpoint in the client then, I admit returning the iss and client_id from the authorization endpoint won’t help.
John B.

Post by Phil Hunt (IDM)
There are two variations.
Mitm the token endpoint is different then working one legit token endpoint against another thru redirect and state misdirection.
In the mitm version you don't need multiple AS's.
Phil

The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated by returning an identifier for the AS in the authorization response. It is something that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access tokens tokens don't help.
Maybe that's obvious but there seems to be a lot of confusion on all this so I wanted to reiterate it.
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

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

[John Bradley]

Phil someone is giving the client the bad endpoints. From the perspective of the client that is an AS.

I count that as two entities one good and one bad.

We agreed not to force clients to do discovery.

How is the client being given this bad set of endpoints?

If it is being given them by dereferencing a issuer to get the .well-known then the mitigation will stop the attack because the two issuers can’t be the same unless the attacker has compromised the good AS’s .well-known, and that I would argue is a different problem.

John B.

Post by Phil Hunt
John
You are trying to solve a completely different problem.
In the bad discovery scenario there is no good AS and bad AS.
1. There is only one AS and one RS infrastrucutre
2. The client is mis-configured because it has been given a bad endpoint for one of dyn-reg, token, or resource
The client has no way to know what constitutes a valid set of endpoints.
The AS is acting in good faith in all respects. It become promiscuous because it is turning over grants and/or tokens over to clients that are sending them to a bad endpoint.
Phil
@independentid

Post by John Bradley
You still have a good AS and a bad AS it is just that the bad AS is using the good AS’s authorization endpoint.
I guess it comes down to how you define what a AS is if it is malicious.
Remember all of the attacks postulated in the papers require a xsrf attack or man in the network to cause a client to start a authorization with the bad AS triggering bad discovery and registration.
If the bad AS is publishing a malicious RS and the “good” registration, authorization, and token endpoints. It will have a different issuer from the
good AS authorization endpoint. When the client performs authorization thinking it is going to bad AS and gets back the issuer for good AS that will trigger an error in the client and it will never present the AT to the bad RS’s resource endpoint.
If the developer hard codes some bad RS endpoint in the client then, I admit returning the iss and client_id from the authorization endpoint won’t help.
John B.

Post by Phil Hunt (IDM)
There are two variations.
Mitm the token endpoint is different then working one legit token endpoint against another thru redirect and state misdirection.
In the mitm version you don't need multiple AS's.
Phil

The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated by returning an identifier for the AS in the authorization response. It is something that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access tokens tokens don't help.
Maybe that's obvious but there seems to be a lot of confusion on all this so I wanted to reiterate it.
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended for that RS
Other high-level goals?
1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>