Re: [OAUTH-WG] open redirect in rfc6749

[John Bradley <[e-mail]>]

In a enterprise case likely there is some trusted relationship.

In the Web 2.0 API economy case there is a tension between providers wanting the maximum number of users and validating the developer registering the client.
Often having a email someplace is sufficient to register a client.  That is not a particularly high bar if you are someone intent on hacking or phishing.

Each AS is going to have some different policy regarding the vetting of clients/developers.

So AS need to take appropriate precautions based on there policies.

John B.
On Sep 4, 2014, at 2:29 PM, Hans Zandbelt <[e-mail]> wrote:

> exactly, but my point would be that the attacker needs to have an relationship/account with the OP; this is where the approval is and I agree with Antonio/you that that is tricky for consumer ASs and deserves a warning
> 
> Hans.
> 
> On 9/4/14, 2:22 PM, John Bradley wrote:
>> Registration requiring a valid email address is not sufficient to stop a "bad" person from registering a client that appears to be perfectly legitimate but is later used as a redirect.
>> 
>> So it is a bit slippery to differentiate good from bad.
>> 
>> In general clearing the referrer and fragment from incoming requests is a good practice on redirects to prevent leakage of information across the redirect.
>> 
>> The other concern is using the redirect as part of a phishing attack to make the target site look more legitimate.
>> That is a more complicated problem unless you validate every client by looking at them to make sure they are not bad in some way.
>> 
>> John B.
>> 
>> 
>> On Sep 4, 2014, at 2:09 PM, Hans Zandbelt <[e-mail]> wrote:
>> 
>>> Maybe just to clarify my point: where did the client_id in the example that you gave come from?
>>> 
>>> Hans.
>>> 
>>> On 9/4/14, 1:58 PM, Hans Zandbelt wrote:
>>>> yes, you are right about the unrestricted client use case; I just got
>>>> caught by the fact that you were talking about *unrestricted* client
>>>> registration all the time (standards-based or not) which deserves extra
>>>> caution whereas Google (and the spec) also provides *restricted* client
>>>> registration the deviation or caution is not needed
>>>> 
>>>> Hans.
>>>> 
>>>> On 9/4/14, 1:44 PM, Antonio Sanso wrote:
>>>>> hi Hans
>>>>> 
>>>>> On Sep 4, 2014, at 10:58 AM, Hans Zandbelt
>>>>> <[e-mail]> wrote:
>>>>> 
>>>>>> Agreed, I see you point about the big providers using exactly the
>>>>>> unrestricted flow for which the trust model (by definition) is out of
>>>>>> scope of the spec. This may be the reason for the implemented
>>>>>> behavior indeed and a security consideration is a good idea for other
>>>>>> deployments; there's not much more that can be done.
>>>>>> 
>>>>>> But Google also provides explicit registration for API clients (which
>>>>>> is where my mind was):
>>>>>> https://developers.google.com/accounts/docs/OAuth2 (step 1)
>>>>>> and they would not need to deviate from the spec for that, nor would
>>>>>> the spec need to change
>>>>> 
>>>>> I do really struggle to understand your point here :) (at least the
>>>>> "nor would the spec need to change part" :)).
>>>>> 
>>>>> Probably I need to explain myself better.
>>>>> Since Google is “safe” (due the “deviation” from the spec) I would
>>>>> take Google as example here (I could point out open redirector in the
>>>>> wild to proof my point but I will not do…)
>>>>> 
>>>>> Let’s start from scratch…
>>>>> 
>>>>> If Google would have something like
>>>>> http://www.google.com?goto=attacker.com this is without any doubt an
>>>>> open redirector… see  also OWASP 10 [0].
>>>>> 
>>>>> Now if Google would have implemented the spec rfc6749 verbatim
>>>>> something like
>>>>> 
>>>>> https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=788732372078.apps.googleusercontent.com&scope=WRONG_SCOPE&redirect_uri=http://attacker.com
>>>>> 
>>>>> 
>>>>> would have redirect to http://attacker.com.
>>>>> 
>>>>> So why this is not an open redirect ? :)
>>>>> 
>>>>> Now maybe we are saying the same thing but I felt like better explain
>>>>> my point :)
>>>>> 
>>>>> regards
>>>>> 
>>>>> antonio
>>>>> 
>>>>> [0]
>>>>> https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Hans.
>>>>>> 
>>>>>> On 9/4/14, 9:50 AM, Antonio Sanso wrote:
>>>>>>> Hi Hans,
>>>>>>> 
>>>>>>> I really fail to see how this can be addressed at registration time
>>>>>>> for cases where registration is unrestricted (namely all the big
>>>>>>> Providers)
>>>>>>> 
>>>>>>> regards
>>>>>>> 
>>>>>>> antonio
>>>>>>> 
>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt
>>>>>>> <[e-mail]> wrote:
>>>>>>> 
>>>>>>>> Classifying like this must also mean that consent should not be
>>>>>>>> stored until the client is considered (admin) trusted, and admin
>>>>>>>> policy would interfere with user policy.
>>>>>>>> 
>>>>>>>> IMHO the security consideration would apply only to dynamically
>>>>>>>> registered clients where registration is unrestricted; any other
>>>>>>>> form would involve some form of admin/user approval at registration
>>>>>>>> time, overcoming the concern at authorization time: there's no
>>>>>>>> auto-redirect flow possible for unknown clients.
>>>>>>>> 
>>>>>>>> Hans.
>>>>>>>> 
>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
>>>>>>>>> I think this advice isn't a bad idea, though it's of course up to
>>>>>>>>> the AS
>>>>>>>>> what an "untrusted" client really is. In practice, this is something
>>>>>>>>> that was registered by a non-sysadmin type person, either a
>>>>>>>>> dynamically
>>>>>>>>> registered client or something available through self-service
>>>>>>>>> registration of some type. It's also reasonable that a client, even
>>>>>>>>> dynamically registered, would be considered "trusted" if enough
>>>>>>>>> time has
>>>>>>>>> passed and enough users have used it without things blowing up.
>>>>>>>>> 
>>>>>>>>>  -- Justin
>>>>>>>>> 
>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso <[e-mail]
>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>> 
>>>>>>>>>> hi again *,
>>>>>>>>>> 
>>>>>>>>>> after thinking a bit further IMHO an alternative for the untrusted
>>>>>>>>>> clients can also be to always present the consent screen (at least
>>>>>>>>>> once) before any redirect.
>>>>>>>>>> Namely all providers I have seen show the consent screen if all the
>>>>>>>>>> request parameters are correct and if the user accepts the redirect
>>>>>>>>>> happens.
>>>>>>>>>> If one of the parameter  (with the exclusion of the client id and
>>>>>>>>>> redirect uri that are handled differently as for spec) is wrong
>>>>>>>>>> though
>>>>>>>>>> the redirect happens without the consent screen being shown..
>>>>>>>>>> 
>>>>>>>>>> WDYT?
>>>>>>>>>> 
>>>>>>>>>> regards
>>>>>>>>>> 
>>>>>>>>>> antonio
>>>>>>>>>> 
>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso <[e-mail]
>>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Well,
>>>>>>>>>>> I do not know if this is only dynamic registration...
>>>>>>>>>>> let’s talk about real use cases, namely e.g. Google , Facebook ,
>>>>>>>>>>> etc.. is that dynamic client registration? I do not know… :)
>>>>>>>>>>> 
>>>>>>>>>>> Said that what the other guys think?  :)
>>>>>>>>>>> Would this deserve some “spec adjustment” ? I mean there is a
>>>>>>>>>>> reason
>>>>>>>>>>> if Google is by choice “violating” the spec right? (I assume to
>>>>>>>>>>> avoid
>>>>>>>>>>> open redirect…)
>>>>>>>>>>> But other implementers do follow the spec hence they have this open
>>>>>>>>>>> redirector… and this is not nice IMHO...
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt
>>>>>>>>>>> <[e-mail]
>>>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt
>>>>>>>>>>>>> <[e-mail]
>>>>>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Is your concern clients that were registered using dynamic
>>>>>>>>>>>>>> client
>>>>>>>>>>>>>> registration?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> yes
>>>>>>>>>>>> 
>>>>>>>>>>>> I think your issue is then with the trust model of dynamic client
>>>>>>>>>>>> registration; that is left out of scope of the dynreg spec (and
>>>>>>>>>>>> the
>>>>>>>>>>>> concept is not even part of the core spec), but unless you want
>>>>>>>>>>>> everything to be open (which typically would not be the case),
>>>>>>>>>>>> then
>>>>>>>>>>>> it would involve approval somewhere in the process before the
>>>>>>>>>>>> client
>>>>>>>>>>>> is registered. Without dynamic client registration that
>>>>>>>>>>>> approval is
>>>>>>>>>>>> admin based or resource owner based, depending on use case.
>>>>>>>>>>>> 
>>>>>>>>>>>>>> Otherwise the positive case is returning a response to a
>>>>>>>>>>>>>> valid URL
>>>>>>>>>>>>>> that belongs to a client that was registered explicitly by the
>>>>>>>>>>>>>> resource owner
>>>>>>>>>>>>> 
>>>>>>>>>>>>> well AFAIK the resource owner doesn’t register clients…
>>>>>>>>>>>> 
>>>>>>>>>>>> roles can collapse in use cases especially when using dynamic
>>>>>>>>>>>> client
>>>>>>>>>>>> registration
>>>>>>>>>>>> 
>>>>>>>>>>>>>> and the negative case is returning an error to that same URL.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> the difference is the consent screen… in the positive case you
>>>>>>>>>>>>> need
>>>>>>>>>>>>> to approve an app.. for the error case no approval is needed,,,
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I fail to see the open redirect.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> why?
>>>>>>>>>>>> 
>>>>>>>>>>>> because the client and thus the fixed URL are explicitly
>>>>>>>>>>>> approved at
>>>>>>>>>>>> some point
>>>>>>>>>>>> 
>>>>>>>>>>>> Hans.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hans.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt
>>>>>>>>>>>>>>> <[e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: why
>>>>>>>>>>>>>>>> would you
>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is provided and
>>>>>>>>>>>>>>>> call it
>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is
>>>>>>>>>>>>>>>> provided?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> as specified below in the positive case (namely when the
>>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>>> scope
>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via the
>>>>>>>>>>>>>>> consent
>>>>>>>>>>>>>>> screen (at least once).
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hans.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote:
>>>>>>>>>>>>>>>>> hi John,
>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley <[e-mail]
>>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client
>>>>>>>>>>>>>>>>>> registrations with
>>>>>>>>>>>>>>>>>> arbitrary redirect_uri.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a
>>>>>>>>>>>>>>>>>> client
>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I think that if anything it may be the registration step
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> needs
>>>>>>>>>>>>>>>>>> the security consideration.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It
>>>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration time….
>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely
>>>>>>>>>>>>>>>>> returning
>>>>>>>>>>>>>>>>> 400 with the cause of the error..
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> *400.* That’s an error.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> *Error: invalid_scope*
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]}
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the
>>>>>>>>>>>>>>>>> spec so
>>>>>>>>>>>>>>>>> far….
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> antonio
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> John B.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke <[e-mail]
>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I don't understand.  The redirect uri has to be valid in
>>>>>>>>>>>>>>>>>>> order for a
>>>>>>>>>>>>>>>>>>> redirect to happen.  The spec explicitly states this.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote:
>>>>>>>>>>>>>>>>>>>> hi *,
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable
>>>>>>>>>>>>>>>>>>>> to open
>>>>>>>>>>>>>>>>>>>> redirect.
>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0]
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or
>>>>>>>>>>>>>>>>>>>> mismatching
>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or
>>>>>>>>>>>>>>>>>>>> invalid,
>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource
>>>>>>>>>>>>>>>>>>>> owner of the
>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the
>>>>>>>>>>>>>>>>>>>> user-agent to the
>>>>>>>>>>>>>>>>>>>> invalid redirection URI.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or if the
>>>>>>>>>>>>>>>>>>>> request
>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid
>>>>>>>>>>>>>>>>>>>> redirection URI,
>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by adding the
>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>> parameters to the query component of the redirection URI
>>>>>>>>>>>>>>>>>>>> using the
>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B
>>>>>>>>>>>>>>>>>>>> <https://tools.ietf.org/html/rfc6749#appendix-B>:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Now let’s assume this.
>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com
>>>>>>>>>>>>>>>>>>>> <http://thevictim.com/>
>>>>>>>>>>>>>>>>>>>> <http://victim.com/><http://victim.com
>>>>>>>>>>>>>>>>>>>> <http://victim.com/>
>>>>>>>>>>>>>>>>>>>> <http://victim.com/>>
>>>>>>>>>>>>>>>>>>>> <http://victim.com <http://victim.com/>
>>>>>>>>>>>>>>>>>>>> <http://victim.com/>>
>>>>>>>>>>>>>>>>>>>> provider.
>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com
>>>>>>>>>>>>>>>>>>>> <http://uriattacker.com/>
>>>>>>>>>>>>>>>>>>>> <http://attacker.com/><http://attacker.com
>>>>>>>>>>>>>>>>>>>> <http://attacker.com/> <http://attacker.com/>>
>>>>>>>>>>>>>>>>>>>> <http://attacker.com <http://attacker.com/>
>>>>>>>>>>>>>>>>>>>> <http://attacker.com/>>.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am
>>>>>>>>>>>>>>>>>>>> redirected
>>>>>>>>>>>>>>>>>>>> back to
>>>>>>>>>>>>>>>>>>>> attacker.com <http://attacker.com/>
>>>>>>>>>>>>>>>>>>>> <http://attacker.com/><http://attacker.com
>>>>>>>>>>>>>>>>>>>> <http://attacker.com/>
>>>>>>>>>>>>>>>>>>>> <http://attacker.com/>> <http://attacker.com
>>>>>>>>>>>>>>>>>>>> <http://attacker.com/> <http://attacker.com/>>.
>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector.
>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters are
>>>>>>>>>>>>>>>>>>>> fine this
>>>>>>>>>>>>>>>>>>>> doesn’t apply since the resource owner MUST approve the
>>>>>>>>>>>>>>>>>>>> app
>>>>>>>>>>>>>>>>>>>> via the
>>>>>>>>>>>>>>>>>>>> consent screen (at least once).
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than
>>>>>>>>>>>>>>>>>>>> redirect
>>>>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do)
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> antonio
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Bill Burke
>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>>>>>>>>>>> <http://bill.burkecentral.com/>
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>>>>>> <mailto:[e-mail]><mailto:[e-mail]>
>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>>>> <mailto:[e-mail]>| Ping
>>>>>>>>>>>>>>>> Identity
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]> |
>>>>>>>>>>>>>> Ping Identity
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>|
>>>>>>>>>>>> Ping
>>>>>>>>>>>> Identity
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>>> [e-mail] | Ping Identity
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>> [e-mail] | Ping Identity
>>>>> 
>>>> 
>>> 
>>> --
>>> Hans Zandbelt              | Sr. Technical Architect
>>> [e-mail] | Ping Identity
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> -- 
> Hans Zandbelt              | Sr. Technical Architect
> [e-mail] | Ping Identity