Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

[Ash Narayanan <[e-mail]>]

Fully support Annabelle's idea of idempotent tokens.
1. It makes sense (give me the same code/verifier, I'll give you back the
same tokens).
2. It negates the possible attack vectors mentioned by  Daniel.
3. It is easy to implement.

Regarding Mike's comments...

As I see it, the retry in case of network failures should happen by
> performing a new authorization request – not by trying to reuse an
> authorization code – which is indistinguishable from an attack.

This offers no additional security and creates a poor user experience. With
idempotent tokens, there is no incentive for the attacker to replay than to
just use the already generated tokens, which I assume the attacker would
have access to given they have access to the code/verifier.

Let’s not use OAuth 2.1 as an opportunity to sanction behaviors that we
> can’t distinguish from attacks.

I would argue that we should also take the opportunity to make Oauth2.1
more meaningful/easier to implement, by reducing unnecessary requirements
that offer no additional security.

Daniel did also mention this bit, which I agree with:

> And ideally, the code SHOULD also be invalidated if the PKCE verifier does
> not match, not sure if that is in the current text or not.
>


On Sat, Oct 16, 2021 at 10:42 AM Mike Jones <Michael.Jones=
> [e-mail]> wrote:
>
As I see it, the retry in case of network failures should happen by
> performing a new authorization request – not by trying to reuse an
> authorization code – which is indistinguishable from an attack.
>
>
>
> Let’s not use OAuth 2.1 as an opportunity to sanction behaviors that we
> can’t distinguish from attacks.
>
>
>
> The prohibition on clients reusing an authorization code needs to remain.
>
>
>
>                                                           -- Mike
>
>
>
> *From:* Vittorio Bertocci <Vittorio=[e-mail]>
> *Sent:* Friday, October 15, 2021 4:19 PM
> *To:* Richard Backman, Annabelle <[e-mail]>
> *Cc:* Mike Jones <[e-mail]>; [e-mail]
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth
> 2.1
>
>
>
> I am a fan of this approach. It feels pretty empty to cast people out of
> compliance just because they are handling a realistic circumstance, such as
> network failures, that we know about beforehand.
>
> In addition, this gives us a chance to provide guidance on how to handle
> the situation, instead of leaving AS implementers to their own device.
>
>
>
> On Fri, Oct 15, 2021 at 11:32 AM Richard Backman, Annabelle <richanna=
> [e-mail]> wrote:
>
>     The client MUST NOT use the authorization code more than once.
>
>
>
> This language makes it impossible to build a fault tolerant, spec
> compliant client, as it prohibits retries. We could discuss whether a retry
> really constitutes a separate "use", but ultimately it doesn't matter;
> multiple presentations of the same code look the same to the AS, whether
> they are the result of retries, the client attempting to get multiple sets
> of tokens, or an unauthorized party trying to replay the code.
>
>
>
> I think we can have a fault tolerant, replay-proof implementation, but it
> takes some effort:
>
>
>
>    1. The AS can prevent the authorized client from using one code to get
>    a bunch of independent refresh and access token pairs by either re-issuing
>    the same token (effectively making the token request idempotent) or
>    invalidating previously issued tokens for that code. (Almost but not quite
>    idempotent…idempotent-adjacent?)
>    2. The AS can prevent unauthorized parties from replaying snooped
>    codes+PKCE by requiring stronger client authentication: implement dynamic
>    client registration and require a replay-resistant client authentication
>    method like `jwt-bearer`. The AS can enforce one-time use of the client
>    credential token without breaking fault tolerance, as the client can easily
>    mint a new one for each retry to the token endpoint.
>
>
>
> Yes, I know, this is way more complex than just a credential-less public
> client doing PKCE. Perhaps we can have our cake and eat it too with
> language like:
>
>
>
> The client MUST NOT use the authorization code more than once, unless
> retrying a token request that failed for reasons beyond the scope of this
> protocol. (e.g., network interruption, server outage) Refer to [Fault
> Tolerant Replay Prevention] for guidance.
>
>
>
> …where Fault Tolerant Replay Prevention is a subsection under Security
> Considerations. I don't think this wording is quite right, as the guidance
> is really going to be for the AS, not the client, but hopefully it's enough
> to get the idea across.
>
>
>
> —
>
> Annabelle Backman (she/her)
>
> [e-mail]
>
>
>
>
>
>
>
> On Oct 15, 2021, at 8:27 AM, Mike Jones <
> Michael.Jones=[e-mail]> 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.
>
>
>
> I agree with Daniel.
>
>
>
> Also, while we’ve talked about server requirements, I think it’s equally
> important that we retain this client requirement:
>
>
>
>     The client MUST NOT use the authorization code more than once.
>
>
>
>                                                           -- Mike
>
>
>
> *From:* OAuth <[e-mail]> *On Behalf Of *Daniel Fett
> *Sent:* Friday, October 15, 2021 8:13 AM
> *To:* [e-mail]
> *Subject:* Re: [OAUTH-WG] Re: Authorization code reuse and OAuth 2.1
>
>
>
> I don't think that a MAY is appropriate here.
>
>
>
> I wasn't in the call yesterday, so I hope I don't miss anything here,
> but...
>
>
>
> Even with PKCE, the one-time use requirement of the code is still
> important. First and foremost, if we allow unlimited re-use of the same
> code, even just as an option, we change the semantics of this artifact. I
> guess there are many examples where this causes issues, but one would be
> DPoP. It assumes that there is only one (successful) token request and in
> that request, the token is bound to a specific key. If there can be more
> than one successful token request, all it takes is code_challenge and the
> code sitting around somewhere in accessible memory and an XSS attacker can
> exfiltrate them and use them on his own device, binding the resulting token
> to an attacker-controlled key. This is the attack outcome against which we
> introduced the nonce in DPoP. (Probably we should add this thought as a
> security consideration to DPoP, but that is a different topic.) I guess we
> can come up with many other mechanisms and mitigations that depend on code
> being one-time use.
>
>
>
> The attack described also shows nicely that code replay protection and
> PKCE serve similar purposes, but are not the same thing.
>
>
>
> The Security BCP introduces a second layer of defense at pretty much all
> the critical places in the protocol, because practice shows that a single
> defense can break too easily. For example, an attacker with read-only
> access to the token request would be pretty bad without code replay
> protections in place. Such attackers are considered in FAPI. (Somebody
> capable of reading system logs at the client or server, proxy logs at the
> client or server, browser logs, etc.)
>
>
>
> Therefore, in my opinion, the code MUST be short-lived and at least
> SHOULD, better MUST be one-time use.
>
>
>
> And ideally, the code SHOULD also be invalidated if the PKCE verifier does
> not match, not sure if that is in the current text or not.
>
>
>
> -Daniel
>
>
>
>
>
>
>
> Am 15.10.21 um 11:04 schrieb Pieter Kasselman:
>
> SHOULD is more likely to cause the right conversations to take place for
> implementors as they weigh the risks. Reducing it to MAY risks diluting it
> too much.
>
>
>
> *From:* OAuth <[e-mail]> <[e-mail]> *On
> Behalf Of *Warren Parad
> *Sent:* Friday 15 October 2021 09:25
> *To:* Pieter Kasselman <pieter.kasselman=[e-mail]>
> <pieter.kasselman=[e-mail]>
> *Cc:* IETF oauth WG <[e-mail]> <[e-mail]>
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and
> OAuth 2.1
>
>
>
> I wouldn't be against lowering it to MAY but only if we stipulate a SHOULD
> on an expected lifetime of an authorization code. I think sending the
> message that these should be one time use except in exceptional
> circumstances.
>
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service. Implement
> Authress
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154740432%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6rSI2UvnakrWNh3qtBEgIMbRO8L9oXu8zGj4Fd128B8%3D&reserved=0>
> .
>
>
>
>
>
> On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman <pieter.kasselman=
> [e-mail]> wrote:
>
> Any weakening of the requirement should include a clear outline of the
> risks to help implementors make informed decisions.
>
>
>
> *From:* OAuth <[e-mail]> *On Behalf Of *Ash Narayanan
> *Sent:* Friday 15 October 2021 01:51
> *To:* Aaron Parecki <[e-mail]>
> *Cc:* IETF oauth WG <[e-mail]>
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and
> OAuth 2.1
>
>
>
> You don't often get email from [e-mail]. Learn why this
> is important <http://aka.ms/LearnAboutSenderIdentification>
>
> Yes, as I said before, authorization servers are free to enforce one-time
> use of the authorization code even if there isn't a requirement to. The
> proposal is just to remove the *requirement* of authorization servers
> enforcing it.
>
>
>
> I agree, and therefore I think what it really ought to be is "MAY".
>
>
>
> Annabelle said:
>
> There are legitimate use cases for a client to replay an authorization
> code. Connection failures happen. Servers fall over before completing
> requests. Users hit browser refresh buttons. Permitting replay of
> authorization codes (assuming valid PKCE, client creds, etc.) allows
> clients to handle these failure modes simply and gracefully via retries.
>
>
>
> Couldn't agree more. Having experienced these exact use-cases, I can
> honestly say that denying users a smooth experience just to be compliant
> with the spec, which offers no additional security if PKCE is also being
> used, makes no sense.
>
> It is also more effort (from a repository layer perspective) to implement
> one-time use than do PKCE verification.
>
>
>
> What is the practical reason for allowing "plain" PKCE in OAuth 2.1? Are
> there really use cases out there where SHA-256 is a deal breaker?
>
>
>
> I'd be interested in these use-cases as well (I can't think of any).
>
>
>
> On Thu, Oct 14, 2021 at 8:36 AM Aaron Parecki <[e-mail]> wrote:
>
> Yes, as I said before, authorization servers are free to enforce one-time
> use of the authorization code even if there isn't a requirement to. The
> proposal is just to remove the *requirement* of authorization servers
> enforcing it.
>
>
>
> I am okay with Mike's suggestion of changing the language to "SHOULD" to
> continue to point out the possibility of enforcing one-time authorization
> codes if desired.
>
>
>
>
>
>
>
> On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman <
> [e-mail]> wrote:
>
> Log files can exist in lots of place (clients, servers, data lakes). The
> question is whether it is a valid assumption that an attacker cannot obtain
> an Authorization Code and a Code Verifier and present it a second time
> round. Limiting the validity period is one layer of defence, PKCE is
> another layer, one time use enforcement is another. Assuming breach and
> designing from a defence in depth perspective is a good practice, so why
> not give implementors options (and guidance) to add additional layers of
> defence to match their risk profiles?
>
>
>
>
>
> *From:* OAuth <[e-mail]> *On Behalf Of *Sascha Preibisch
> *Sent:* Wednesday 13 October 2021 22:06
> *To:* Aaron Parecki <[e-mail]>
> *Cc:* IETF oauth WG <[e-mail]>
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and
> OAuth 2.1
>
>
>
> Ok, if the goal is to avoid unnecessary requirements I am suggesting to
> point out why MUST was changed to SHOULD. Otherwise developers will start
> to mix and match OAuth 2.0 and OAuth 2.1 requirements as they see them fit
> their needs.
>
> In regards to encrypted values in PKCE, Aaron, I can also not confirm that
> as the general implementation.
>
>
>
> On Wed, 13 Oct 2021 at 13:56, Aaron Parecki <[e-mail]> wrote:
>
> The PKCE spec actually says "Typically, the "code_challenge" and
> "code_challenge_method" values are stored in encrypted form in the "code"
> itself" which I feel like might be a stretch to say that's typical, but
> this scenario was clearly thought of ahead of time. Doing that would enable
> an AS to avoid storing server-side state.
>
>
>
> On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch <
> [e-mail]> wrote:
>
> If the challenge is based on distributed authorization server
> configurations, how would they handle PKCE? I imagine that managing the
> state for PKCE is not less challenging than managing authorization codes on
> the server side, preventing reuse of them.
>
> With that in mind I am not sure if I follow the given argument. I would
> prefer to keep MUST as it is today.
>
>
>
>
>
> On Wed, 13 Oct 2021 at 13:37, Aaron Parecki <[e-mail]> wrote:
>
> HTTPS, because if that's broken then the rest of OAuth falls apart too.
>
>
>
> On Wed, Oct 13, 2021 at 1:36 PM Warren Parad <[e-mail]> wrote:
>
> I feel like I'm missing something, what stops just plain old network
> sniffing and replying the whole encrypted payload to the AS and getting
> back a valid token?
>
>
> <image001.jpg>
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service. Implement
> Authress
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154750385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y86Gy8RiRIbIAW3So8hr4PxYsta1VWX1X7l%2FHzVbcvI%3D&reserved=0>
> .
>
>
>
>
>
> On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki <[e-mail]> wrote:
>
> Aside from the "plain" method, the PKCE code verifier never leaves the
> client until it's sent along with the authorization code in the POST
> request to the token endpoint. The only place it can leak at that point is
> if the authorization server itself leaks it. If you have things leaking
> from the authorization server log, you likely have much bigger problems
> than authorization code replays.
>
>
>
> Keep in mind that even with the proposed change to drop the requirement of
> authorization codes being one time use, authorization servers are free to
> enforce this still if they want. Authorization code lifetimes are still
> expected to be short lived as well.
>
>
>
> Aaron
>
>
>
>
>
> On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman <
> [e-mail]> wrote:
>
> Aaron, I was curious what prevents an attacker from presenting an
> Authorization Code and a PKCE Code Verifier for a second time if the one
> time use requirement is removed. Is there another countermeasure in  PKCE
> that would prevent it? For example, an attacker may obtain the
> Authorization Code and the Code Verifier from a log and replay it.
>
>
>
> Cheers
>
>
>
> Pieter
>
>
>
> *From:* OAuth <[e-mail]> *On Behalf Of *Aaron Parecki
> *Sent:* Wednesday 13 October 2021 18:40
> *To:* Warren Parad <wparad=[e-mail]>
> *Cc:* Mike Jones <Michael.Jones=[e-mail]>;
> [e-mail]
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth
> 2.1
>
>
>
> Warren, I didn't see you on the interim call, so you might be missing some
> context.
>
>
>
> The issue that was discussed is that using PKCE already provides all the
> security benefit that is gained by enforcing single-use authorization
> codes. Therefore, requiring that they are single-use isn't necessary as it
> doesn't provide any additional benefit.
>
>
>
> If anyone can think of a possible attack by allowing authorization codes
> to be reused *even with a valid PKCE code verifier* then that would warrant
> keeping this requirement.
>
>
>
> ---
>
> Aaron Parecki
>
>
>
>
>
> On Wed, Oct 13, 2021 at 10:27 AM Warren Parad <wparad=
> [e-mail]> wrote:
>
> Isn't it better for it to be worded as we want it to be, with the
> implication being that of course it might be difficult to do that, but that
> AS devs will think long and hard about sometimes not denying the request?
> Even with MUST, some AS will still allow reuse of auth codes. Isn't that
> better than flat out saying: *sure, there's a valid reason*
>
>
>
> In other words, how do we think about RFCs? Do they exist to be followed
> to the letter or not at all? Or do they exist to stipulate this is the way,
> but acknowledge that not everyone will build a solution that holds them as
> law.
>
>
>
> Let's look at *SHOULD*
>
> This word, or the adjective "RECOMMENDED", mean that there may exist valid
> reasons in particular circumstances to ignore a particular item, but the
> full implications must be understood and carefully weighed before choosing
> a different course.
>
>
>
> I think *recommended* here is not sufficient nor are there valid reasons.
> "It's too hard" isn't really a valid reason. Isn't it better in this case
> for an AS to not be compliant with the RFC, than it is to relax this to
> SHOULD and have lots of AS thinking reusing auth codes is a viable
> solution, "because they are a special snowflake where SHOULD should apply".
>
>
>
> Are we setting the standard or instead attempting to sustain a number of
> "AS that are in compliance with the RFC"?
>
>
>
> <image001.jpg>
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service. Implement
> Authress
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lbb9cJl0VUcfBD9IwzKF4BeB5nnggZxLB1TwlZYdNK4%3D&reserved=0>
> .
>
>
>
>
>
> On Wed, Oct 13, 2021 at 7:17 PM Mike Jones <Michael.Jones=
> [e-mail]> wrote:
>
> During today’s call, it was asked whether we should drop the OAuth 2.0
> language that:
>
>          The client MUST NOT use the authorization code
>
>          more than once.  If an authorization code is used more than
>
>          once, the authorization server MUST deny the request and SHOULD
>
>          revoke (when possible) all tokens previously issued based on
>
>          that authorization code.”
>
>
>
> The rationale given was that enforcing one-time use is impractical in
> distributed authorization server deployments.
>
>
>
> Thinking about this some more, at most, we should relax this to:
>
>          The client MUST NOT use the authorization code
>
>          more than once.  If an authorization code is used more than
>
>          once, the authorization server SHOULD deny the request and SHOULD
>
>          revoke (when possible) all tokens previously issued based on
>
>          that authorization code.”
>
>
>
> In short, it should remain illegal for the client to try to reuse the
> authorization code.  We can relax the MUST to SHOULD in the server
> requirements in recognition of the difficulty of enforcing the MUST.
>
>
>
> Code reuse is part of some attack scenarios.  We must not sanction it.
>
>
>
>                                                           -- Mike
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154760332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=u3yNDEeIsFvqGwu3x8%2F22D25o3bVO9PkrBEA2IEKSzY%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154770299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7JX5eYOgW7gjFIIySrFurb2%2B9dBhH4IAsXhIMkV%2FGps%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154770299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7JX5eYOgW7gjFIIySrFurb2%2B9dBhH4IAsXhIMkV%2FGps%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154780256%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lJqE32wIC4OoFoYfUMYr8zd3pgEz2abBr2aga42rFsA%3D&reserved=0>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
>
> https://danielfett.de
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>