I’m not sure I understand why this is an OAuth protocol problem? If you are starting with a false client with a false registration, everything down stream is likely invalid.
This seems like a registration curation (whitelisting) problem. This is a bit like saying, how can I prove that the application on this jail-broken phone is legitimate? Phil @independentid www.independentid.com phil.h...@oracle.com On Sep 15, 2014, at 1:52 PM, Antonio Sanso <asa...@adobe.com> wrote: > 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
