Re: [OAUTH-WG] open redirect in rfc6749

[Hans Zandbelt <[e-mail]>]

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