Your solution seems to require resourceuri = audience. Bound config avoids trying to require conversion or urls into aud and vice versa.
Phil > On Mar 16, 2016, at 07:46, John Bradley <ve7...@ve7jtb.com> wrote: > > If the client sends the uri of the resource it intends to send the token to > in the token request the bad guy would get only a token audianced to itself > and not to good RS. > > You can't solve the problem of bearer tokens with multiple audiences leaking. > That is a risk inherent in using that sort of token. Compromise in one RS > will impact all of them. > > The only safe way with bearer to deal with a RS the AS dosen't trust a RS is > to only have one audianced in the token. (or by introspection) > > We have always known that and left it up to clients to make sure they are > secure by not sending tokens to bad RS. > > Now people want a AS check to prevent clients from being tricked if > developers are given bad info statically or dynamically. > > What you are doing is safe as long as your developers don't make any > mistakes. > If you want to be safe and not have to preconfigure the AS you need to use > the refresh to get single audianced tokens, or PoP. > > John B. > >> On Mar 16, 2016 11:27 AM, "George Fletcher" <gffle...@aol.com> wrote: >> >> >>> On 3/15/16 6:14 PM, John Bradley wrote: >>> If the AS is audience restricting the tokens then it just needs to put the >>> right audience in the token based on what the client is asking for. >>> That is safe as the RS wouldn’t be able to replay the token someplace else. >> So let's assuming a client sends a token audience restricted to GoodRS >> instead to EvilRS. When EvilRS replays the token at the GoodRS endpoint, how >> does GoodRS reject the token because when GoodRS sends the token to the AS >> for introspection (or does so itself) the token will be audience restricted >> to the GoodRS and it will process the token. The only way to prevent this is >> with client-authentication so that the presenter can be matched against who >> is allowed to present the token (aka PoP). >> >> In the pure bearer token model, I don't see how this can be prevented at the >> protocol level. >>> >>> That would need to be a AS policy if it wanted to do that for unknown RS. >>> >>> Allowing more than one audience in a token is a convince but a well known >>> security risk with bearer tokens. >> True, but this means clients have to manage many tokens or call the token >> endpoint to get a "downscoped, audience restricted" token every time they >> need one. This is a very different model than what most people think of when >> they think of OAuth2. Not bad, just different:) >>> >>> A AS would probably want to have only one audience in a AT for a >>> untrusted RS, but may allow multiple if they are all trusted. >>> >>> John B. >>> >>> >>>> On Mar 15, 2016, at 6:28 PM, George Fletcher <gffle...@aol.com> wrote: >>>> >>>> >>>>> On 3/15/16 3:26 PM, John Bradley wrote: >>>>> I think Phil and others are concerned that a developer might get bad info >>>>> to put in the client , some out of band discovery goes wrong or the user >>>>> is somehow tricked into specifying a bad resource to the client. >>>>> >>>>> So getting a bad resource is a touch hypothetical. >>>> If we are really trying to solve this problem holistically, then we >>>> probably need to first describe the use cases we want to solve. I'm >>>> starting to wonder if we are all providing solutions to slightly different >>>> use cases. >>>>> >>>>> For Connect we could suppose that someone publishes a malicious discovery >>>>> document listing themselves as the RS but all the other endpoints are at >>>>> the good AS so the client registers, authorizes the user and gives the AT >>>>> to the bad guy. The confused client mitigation by returning >>>>> client_id_and issuer from the authorization endpoint will stop the attack >>>>> before the token can be given to the token endpoint or RS. >>>> Agreed and I'm fine with this solution. >>>>> >>>>> So protecting the AT at this point is more for a unknown attack that >>>>> would confuse whatever protocol/API that is using OAuth about what RS to >>>>> use. >>>> Yes. This is where we need to describe some use cases (preferably real vs >>>> contrived) before we propose solutions. In most cases the RS endpoints are >>>> hard coded into the client or maybe pulled from a >>>> different central config endpoint (which is fixed). >>>> >>>> That's why the only case I could think of is a client that works with >>>> multiple RS endpoints from different providers that server the same >>>> content (e.g. PortableContacts API). In this use case, the user of the >>>> client would need to enter the location of the RS they wanted to use and >>>> then the flow would start from there. In reality, most services like this >>>> would have a fixed set of RS's they work with and again it wouldn't be >>>> dynamic. >>>>> >>>>> In reality this is what PoP is supposed to be for. >>>>> >>>>> I guess the question is what short of PoP can we do to prevent the client >>>>> leaking tokens to bad RS that confuse it via the application protocol. >>>>> >>>>> If we want to del with this in OAuth then we need to tell the AS where >>>>> the token is going to be used or tel the client where the token can be >>>>> used. >>>>> >>>>> I think letting the client tell the AS where it wants the token used >>>>> having the AS construct a audience out of that is probably the best >>>>> thing. to get around having a pre-established relationship between the >>>>> AS and RS. >>>> Even if the client tells the AS where it wants to use the token (via some >>>> endpoint URL), the AS still needs to have a relationship with the RS (at a >>>> minimum as an endpointURL-to-RS map) otherwise how can it determine if it >>>> is allowed to issue an access token to the user for that RS. This map is >>>> what I want to avoid "building" into the AS. Do we need "dynamic RS >>>> registration" to support this? >>>> >>>>> >>>>> John B. >>>>> >>>>>> On Mar 15, 2016, at 3:14 PM, George Fletcher <gffle...@aol.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> I think Justin provided a good break down of the different aspects a >>>>>> client wants to specify about the requested token. (my paraphrase) >>>>>> 1. what RS's the token will be used at >>>>>> 2. authorization privilege requests >>>>>> 3. token-timing adjustments >>>>>> >>>>>> I'm not sure passing the full endpoint to the AS will help with my >>>>>> concerns... The AS could potentially do a webfinger on the resource URI >>>>>> and determine if it's an RS that it supports... though that requires all >>>>>> RS's to support webfinger. What I really want to avoid is the AS having >>>>>> this list of URIs to RS that is almost assuredly to get out of sync. >>>>>> >>>>>> >>>>>> >>>>>>> On 3/15/16 1:56 PM, John Bradley wrote: >>>>>>> I think it is a AS policy decision if it should error or take the >>>>>>> requested resource and issue a token audianced for that resource. >>>>>> Actually, the error cases are interesting. What if the passed in >>>>>> resource/audience doesn't actually match a requested scope? Or some >>>>>> match and some don't? Is it better to send back a token with less >>>>>> capability? or error the entire request? >>>>>>> >>>>>>> >>>>>>> I guess the question is how to transition from now to a future state. >>>>>>> If you cannot upgrade all the clients at once. >>>>>>> >>>>>>> A processing rule on the AS that allowed some clients to not send the >>>>>>> requested resource , but would error out for other upgraded clients >>>>>>> with a "resource not allowed” oauth error would work and not require >>>>>>> the return of the resources. >>>>>>> >>>>>>> If you return the resources and let the client error if it is trying to >>>>>>> send to the wrong endpoint that make upgrading easier, but gives less >>>>>>> control to the AS. >>>>>>> >>>>>>> I could live with it ether way. >>>>>>> >>>>>>> The advantage of always sending it in the token request is that it >>>>>>> allows the AS to do the mapping from a resource URI to one or more >>>>>>> abstract audience for the token. >>>>>> I thought Justin provided a good break down of >>>>>> the different aspects a client wants to specify about the requested >>>>>> token. (my paraphrase) >>>>>> 1. what RS's the token will be used at >>>>>> 2. authorization privilege requests >>>>>> 3. token-timing adjustments >>>>>> >>>>>> The question is how does a client internally reference a resource >>>>>> server? If it's a fixed RS endpoint, then it sort of doesn't matter, the >>>>>> client isn't going to send the token to the wrong endpoint anyway and it >>>>>> can easily reference the audience by an abstract URI. >>>>>> >>>>>> If the client can dynamically find new RS's to interact with. How does >>>>>> that happen? Does the client get handed an endpoint to use? or does it >>>>>> do some sort of discovery to determine the endpoint? I suppose both are >>>>>> possible. >>>>>> >>>>>> Could we prescribe that the realm value of RFC 6750 error response be >>>>>> effectively a resource-service-id (like issuer for the AS). The client >>>>>> would then need to do discovery on that value to find the valid >>>>>> endpoints of the RS. This could be done once and the resource-service-id >>>>>> could be used as the "abstract" RS identifier. This requires no more >>>>>> discovery than adding an AS to the client. >>>>>>> >>>>>>> That might help address George’s concern. >>>>>> I'm not sure passing the full endpoint to the AS will help with my >>>>>> concerns... The AS could potentially do a webfinger on the resource URI >>>>>> and determine if it's an RS that it supports... though that requires all >>>>>> RS's to support webfinger. What I really want to avoid is the AS having >>>>>> this map of URIs to RS that is almost assuredly to get out of sync. >>>>>>> >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> >>>>>>>> On Mar 15, 2016, at 2:44 PM, Brian Campbell >>>>>>>> <bcampb...@pingidentity.com> wrote: >>>>>>>> >>>>>>>> I was thinking it'd be simpler to error, if the requested resource(s) >>>>>>>> weren't okay. That puts the burden of checking in the AS. And doesn't >>>>>>>> add anything to the token or authorization response. I see the >>>>>>>> potential similarity to scope but not sure it's worth it. >>>>>>>> >>>>>>>>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley <ve7...@ve7jtb.com> >>>>>>>>> wrote: >>>>>>>>> If the client specifies the resource it wants the token for, then the >>>>>>>>> meta-data would not be required unless the resources the token is >>>>>>>>> good at are different from the request. >>>>>>>>> Lat is the same logic as scopes. >>>>>>>>> >>>>>>>>> For backwards compatibility if the client is happy with the default >>>>>>>>> resources based on scopes then I think it is a good idea to tell the >>>>>>>>> client what the resources are in the response. >>>>>>>>> >>>>>>>>> I suspect that it is simpler with less optionality and always return >>>>>>>>> the resources, even if they are not required. >>>>>>>>> >>>>>>>>> John B. >>>>>>>>> >>>>>>>>>> On Mar 15, 2016, at 12:46 PM, Brian Campbell >>>>>>>>>> <bcampb...@pingidentity.com> wrote: >>>>>>>>>> >>>>>>>>>> If the client specifies the desired audience(s)/resource(s), is that >>>>>>>>>> metadata to the client needed? The AS can audience restrict the >>>>>>>>>> token as needed or respond with an error if it can't or wont issue a >>>>>>>>>> token for the resource the client asked for. >>>>>>>>>> >>>>>>>>>>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley <ve7...@ve7jtb.com> >>>>>>>>>>> wrote: >>>>>>>>>>> Yes, I think bearer tokens with no audience are a bad idea. >>>>>>>>>>> >>>>>>>>>>> The AS needs to infer an audience from the scopes snd/or have the >>>>>>>>>>> client specify the desired audience. >>>>>>>>>>> >>>>>>>>>>> If the AT has a audience or audiences then as long as the endpoint >>>>>>>>>>> URI are provided as meta-data with the token, the >>>>>>>>>>> client can determine if it >>>>>>>>>>> is sending the token to the correct place. >>>>>>>>>>> >>>>>>>>>>> I think Phil would prefer the server rather than the client do the >>>>>>>>>>> check, but the client >>>>>>>>>>> always needs to take some responsibility to not leak >>>>>>>>>>> tokens giving them to the wrong RS or the code to the wrong token >>>>>>>>>>> endpoint is leaking. >>>>>>>>>>> >>>>>>>>>>> I imagine that claims based access tokens are going to become more >>>>>>>>>>> popular and the static relationship between one RS and one AS will >>>>>>>>>>> not be the majority of deployments over time. >>>>>>>>>>> >>>>>>>>>>> In any case where the client is configured up front to know the RS >>>>>>>>>>> and the AS it seems like that would not require Phil’s Solution, >>>>>>>>>>> but that is the only case supported by that discovery. >>>>>>>>>>> >>>>>>>>>>> If the client itself is bad there is not much you can do to stop it >>>>>>>>>>> from passing on the AT in way way it wants. That however is a >>>>>>>>>>> different problem and needs claimed URI or attestations to prevent >>>>>>>>>>> client spoofing. >>>>>>>>>>> William and I are working on that in the mobile best practices >>>>>>>>>>> draft. >>>>>>>>>>> >>>>>>>>>>> John B. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher <gffle...@aol.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I worry about two directions I see in this thread... >>>>>>>>>>>> >>>>>>>>>>>> 1. Client's accessing resources dynamically so that discovery is >>>>>>>>>>>> required to know the correct AS, etc. This is pretty much the >>>>>>>>>>>> classic use case for UMA and I'd rather not re-invent the wheel. >>>>>>>>>>>> >>>>>>>>>>>> 2. Creating a tight coupling between RS and AS such that RS >>>>>>>>>>>> endpoint changes must be continually communicated to the AS. If an >>>>>>>>>>>> RS supports multiple AS's then the RS has to deal with >>>>>>>>>>>> "guaranteed" delivery. The AS needs an endpoint to receive such >>>>>>>>>>>> communications. If not dynamic via APIs, then deployment of the >>>>>>>>>>>> new RS is bound by the associated AS's getting and deploying the >>>>>>>>>>>> new endpoints. Can both endpoints of the RS be supported within >>>>>>>>>>>> the AS for some period of time, etc. This is an operation >>>>>>>>>>>> nightmare and almost assuredly going to go wrong in production. >>>>>>>>>>>> >>>>>>>>>>>> Maybe an OAuth2 "audience binding" spec is what's needed for those >>>>>>>>>>>> deployments that require this. I believe that is what John Bradley >>>>>>>>>>>> is suggesting. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> George >>>>>>>>>>>> >>>>>>>>>>>>> On 3/14/16 7:29 PM, Hans Zandbelt wrote: >>>>>>>>>>>>> +1, I've found the very same in OAuth deployments that I was >>>>>>>>>>>>> involved in; the hard part is to give names and descriptions to >>>>>>>>>>>>> these concepts so that they cover all use cases and can be >>>>>>>>>>>>> applied unambiguously >>>>>>>>>>>>> >>>>>>>>>>>>> Hans. >>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/14/16 10:44 PM, Justin Richer wrote: >>>>>>>>>>>>>> I agree that this is valuable, and not just for PoP. In all >>>>>>>>>>>>>> honesty, >>>>>>>>>>>>>> it’s not even really required for PoP to function in many cases >>>>>>>>>>>>>> — it’s >>>>>>>>>>>>>> just an optimization for one particular kind of key distribution >>>>>>>>>>>>>> mechanism in that case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In the years of deployment experience >>>>>>>>>>>>>> with OAuth 2, I think we’ve >>>>>>>>>>>>>> really >>>>>>>>>>>>>> got three different kinds of things that currently get folded >>>>>>>>>>>>>> into >>>>>>>>>>>>>> “scope” that we might want to try separating out better: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> - What things do I want to access? (photos, profile) >>>>>>>>>>>>>> - What actions do I want to take on these things? (read, >>>>>>>>>>>>>> write, delete) >>>>>>>>>>>>>> - How long do I want these tokens to >>>>>>>>>>>>>> work? >>>>>>>>>>>>>> (offline_access/refresh_token, one time use, next hour, etc) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think the first one is close to the audience/resource >>>>>>>>>>>>>> parameters that >>>>>>>>>>>>>> have been bandied about a few times, >>>>>>>>>>>>>> including in the current token >>>>>>>>>>>>>> exchange document. We should be consistent across drafts in that >>>>>>>>>>>>>> regard. >>>>>>>>>>>>>> The second is more traditional scope-ish. The third has been >>>>>>>>>>>>>> patched in >>>>>>>>>>>>>> with things like “offline_access” in certain APIs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just another vector to think about if we’re going to be adding >>>>>>>>>>>>>> things >>>>>>>>>>>>>> like “audience” or “resource” or both to the token requests. >>>>>>>>>>>>>> >>>>>>>>>>>>>> — Justin >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley <ve7...@ve7jtb.com >>>>>>>>>>>>>>> <mailto:ve7...@ve7jtb.com>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes I will work on another proposal for allowing clients to >>>>>>>>>>>>>>> specify >>>>>>>>>>>>>>> what resource they want a token for and providing the meta-data >>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>> client about the resources that a token is valid for. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We have part of it in the POP key distribution spec and talked >>>>>>>>>>>>>>> about >>>>>>>>>>>>>>> separating it, as it is used more places than just for >>>>>>>>>>>>>>> assigning keys. >>>>>>>>>>>>>>> I know some AS use different token formats for different RS so >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>> all-ready needing to pass the resource in the request to avoid >>>>>>>>>>>>>>> making >>>>>>>>>>>>>>> a mess of scopes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >>>>>>>>>>>>>>>> <phil.h...@oracle.com >>>>>>>>>>>>>>>> <mailto:phil.h...@oracle.com>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Inline >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Phil >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mar 14, 2016, at 14:13, John Bradley <ve7...@ve7jtb.com >>>>>>>>>>>>>>>> <mailto:ve7...@ve7jtb.com>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We had two mandates. One was to provide a spec for AS >>>>>>>>>>>>>>>>> metadata. >>>>>>>>>>>>>>>>> The other was to mitigate the client mixup attack. The >>>>>>>>>>>>>>>>> request was >>>>>>>>>>>>>>>>> to do the latter without requiring the former for clients >>>>>>>>>>>>>>>>> that don’t >>>>>>>>>>>>>>>>> otherwise need discovery. >>>>>>>>>>>>>>>> There is no mandate for any of this. >>>>>>>>>>>>>>>> See >>>>>>>>>>>>>>>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Returning the issuer and client_id from the authorization >>>>>>>>>>>>>>>>> endpoint >>>>>>>>>>>>>>>>> and the client checking them can be done by the client >>>>>>>>>>>>>>>>> without >>>>>>>>>>>>>>>>> discovery. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> How does this address the issue of whether the client is >>>>>>>>>>>>>>>> talking to >>>>>>>>>>>>>>>> the wrong endpoint? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Any client that has the resource and issuer hard coded >>>>>>>>>>>>>>>>> probably >>>>>>>>>>>>>>>>> doesn’t need discovery. >>>>>>>>>>>>>>>> We agree >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> One of the things that a client will need discovery for is to >>>>>>>>>>>>>>>>> find >>>>>>>>>>>>>>>>> the RS, so requiring the client to know the RS URI before >>>>>>>>>>>>>>>>> getting >>>>>>>>>>>>>>>>> the AS config seems backwards to >>>>>>>>>>>>>>>>> me. >>>>>>>>>>>>>>>> How can you make an assumption on order? You seem to be >>>>>>>>>>>>>>>> conflating >>>>>>>>>>>>>>>> authentication with authorization by assuming the identity >>>>>>>>>>>>>>>> drives >>>>>>>>>>>>>>>> what the resource is. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There are lots of applications that require user rights but >>>>>>>>>>>>>>>> are not >>>>>>>>>>>>>>>> identify centric. For example a document service. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Unless the client tells the AS where it intends to use the >>>>>>>>>>>>>>>>> token we >>>>>>>>>>>>>>>>> will be leaving a security hole because the bearer tokens >>>>>>>>>>>>>>>>> will have >>>>>>>>>>>>>>>>> too loose an audience if they have one at all. >>>>>>>>>>>>>>>> This is the biggest risk we have IMHO. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> True you are telling the AS (Webfinger service) what the RS >>>>>>>>>>>>>>>>> is but >>>>>>>>>>>>>>>>> that is not at a place that is useful in the token production >>>>>>>>>>>>>>>>> process. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This has nothing to do with token production. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What we want to ensure is whether an honest client is >>>>>>>>>>>>>>>> correctly >>>>>>>>>>>>>>>> configured and has not been mislead - eg by a phishing page. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I also think there are use cases where the AS doesn’t know >>>>>>>>>>>>>>>>> all the >>>>>>>>>>>>>>>>> possible RS. That is not something that a out of band check >>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>> address. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> May be. Lets identify them. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There are also cases where a token might be good at multiple >>>>>>>>>>>>>>>>> RS >>>>>>>>>>>>>>>>> endpoints intentionally. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In your solution the client would need to make a discovery >>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>> for each endpoint. >>>>>>>>>>>>>>>> Sure. Otherwise how would it know if there is one AS or a pool >>>>>>>>>>>>>>>> of AS >>>>>>>>>>>>>>>> servers assigned to each instance? >>>>>>>>>>>>>>>>> Those requests lack the context of >>>>>>>>>>>>>>>>> who the client and resource >>>>>>>>>>>>>>>>> owner >>>>>>>>>>>>>>>>> are. I think that will be a problem in some use cases. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Not sure I agree. This is about discovering a valid set of >>>>>>>>>>>>>>>> endpoints. >>>>>>>>>>>>>>>> For mitm, we mainly want to check the hostname is correct. If >>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>> client chooses evil.com <http://evil.com/> the cert can be >>>>>>>>>>>>>>>> valid and >>>>>>>>>>>>>>>> TLS will pass. How does it otherwise know it is supposed to >>>>>>>>>>>>>>>> talk to >>>>>>>>>>>>>>>> res.example.com <http://res.example.com/>? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If this is >> ... > _______________________________________________ > 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
