The problem is that a malicious client can register a malicious redirect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (as previously discussed)
regards antonio On Sep 15, 2014, at 10:43 PM, Phil Hunt <phil.h...@oracle.com> wrote: > If a server accepts a URL from a client to be used as a redirect that the > server doesn’t recognize or is not registered, that is an open redirect. > > The specification does no allow open-redirects, it considers this a > mis-configuration. > > Take a look at sections 3.1.2.2 and 10.15 of RFC6749. > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > On Sep 15, 2014, at 1:00 PM, John Bradley <ve7...@ve7jtb.com> wrote: > >> There may be a problem with semantics in this discussion. >> >> There is a redirect performed by athe authorization endpoint to a fixed uri >> that is pre registered with the authorization server without user prompting. >> >> That probably doesn't fit the strict definition of a open redirector. >> >> It may however create similar security issues in situations with relatively >> open registration of clients. >> >> The largest issues are that the browser might leak information across the >> redirect in the fragment or referrer. That has been used in attacks against >> Facebook in the past. >> >> This is no where near the end of the world, however we need to look at the >> security considerations and see if we can provide better advice to >> implementors. In some cases returning a error to the browser may be best. >> >> I don't think we need to go so far as not returning any error to the client >> under any circumstance. >> >> John B. >> >> Sent from my iPhone >> >>> On Sep 15, 2014, at 4:41 PM, Phil Hunt <phil.h...@oracle.com> wrote: >>> >>> Simply not true. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.h...@oracle.com >>> >>> >>> >>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso <asa...@adobe.com> wrote: >>>> >>>> hi *, >>>> >>>> my understanding is that there is a rough consensus that if an OAuth >>>> Provider follows rfc6749 verbatim will end up having an open redirector. >>>> My next question would be now, is there anything we can do to raise some >>>> awareness about this issue? >>>> >>>> regards >>>> >>>> antonio >>>> >>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt <hzandb...@pingidentity.com> >>>>> wrote: >>>>> >>>>> I am convinced about the issue in the use case Antonio provided but I >>>>> hope not to close the door on returning errors to known and trusted >>>>> clients. Not sure anymore if that's possible though because the >>>>> distinction can't be "registered"... >>>>> >>>>> Hans. >>>>> >>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>> hi Bill >>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke <bbu...@redhat.com> wrote: >>>>>>> >>>>>>> FWIW, Antonio convinced me and I'm going to change this in our IDM >>>>>>> project. Thanks Antonio. What convinced me was that the user is >>>>>>> probably expecting a login screen. Since there is this expectation, it >>>>>>> might make it a little easier for the attacker to convince the user >>>>>>> that a spoofed login screen is real. I know this issue can only happen >>>>>>> with unrestricted registration, but, IMO, this proposed change doesn't >>>>>>> really have much of an effect on usability and is even backward >>>>>>> compatible with the current RFC. >>>>>>> >>>>>>> Wouldn't it better though to never do a redirect on an invalid request >>>>>>> and just display an error page? >>>>>> >>>>>> thanks for sharing your thoughts :). Display an error 400 is what Google >>>>>> does :) >>>>>> >>>>>> regards >>>>>> >>>>>> antonio >>>>>> >>>>>>> >>>>>>>> On 9/4/2014 3: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 >>>>>>>>> <hzandb...@pingidentity.com> 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 <asa...@adobe.com >>>>>>>>>> <mailto:asa...@adobe.com>> 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 <asa...@adobe.com >>>>>>>>>>> <mailto:asa...@adobe.com>> 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 >>>>>>>>>>>> <hzandb...@pingidentity.com >>>>>>>>>>>> <mailto:hzandb...@pingidentity.com>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>> <hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com>> >>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> <hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com> >>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com>> 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 <ve7...@ve7jtb.com >>>>>>>>>>>>>>>>>> <mailto:ve7...@ve7jtb.com> >>>>>>>>>>>>>>>>>> <mailto:ve7...@ve7jtb.com> >>>>>>>>>>>>>>>>>> <mailto:ve7...@ve7jtb.com>> 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 <bbu...@redhat.com >>>>>>>>>>>>>>>>>>> <mailto:bbu...@redhat.com> >>>>>>>>>>>>>>>>>>> <mailto:bbu...@redhat.com> >>>>>>>>>>>>>>>>>>> <mailto:bbu...@redhat.com>> 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 >>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>>> <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>> <mailto:OAuth@ietf.org><mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>> <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>> hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com> >>>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com>| Ping >>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>> hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com> | >>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com>| >>>>>>>>>>>>> Ping >>>>>>>>>>>>> Identity >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandb...@pingidentity.com | Ping Identity >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> -- >>>>>>> Bill Burke >>>>>>> JBoss, a division of Red Hat >>>>>>> http://bill.burkecentral.com >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandb...@pingidentity.com | Ping Identity >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
