If it's impossible to validate who a client is for even one particular protocol in the spec, doesn't this leave a provider's web service open to anyone making an authentication/login request to that implemented profile in the spec? Unless I'm missing something, this is a problem because a provider would be opening themselves up to likely phishing attacks, and no way to stop it except by shutting down the entire protocol that allowed it. Perhaps this is just a documentation issue because implementing this portion of the spec could potentially make a provider less secure with no real way of stopping it after it's implemented.
~/Jason Hullinger On Thu, Mar 4, 2010 at 9:37 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > As was discussed on the OAuth list, desktop apps can NOT be secured, so > there is no way to ensure it really is the desktop app you think it is. For > most phone platforms, this is also the case. For totally locked platforms > where the app is part of the OS (xbox, PS3, some phones, settop boxes) -- > then one can have high confidence the app is the app. So far I consider > these the exception rather than the rule. > > -- Dick > > > On 2010-03-04, at 8:37 PM, David Recordon wrote: > > +ietf list > > > On Mar 4, 2010, at 8:16 PM, Jason Hullinger < <sshja...@gmail.com> > sshja...@gmail.com> wrote: > > I think there are probably going to be more instances of providers needing > this than otherwise. The current Username and Password profile is not a > solution in a for every sense, and there clearly is a need for a secure > protocol where you can validate that the client is who they say they are in > a profile such as on a phone or desktop application. > > ~/Jason Hullinger > > On Thu, Mar 4, 2010 at 7:30 PM, Luke Shepard < > <lshep...@facebook.com><lshep...@facebook.com> > lshep...@facebook.com> wrote: > >> Is Facebook the only one who needs this? >> >> Sent from my iPhone >> >> On Mar 4, 2010, at 6:41 PM, "Dick Hardt" < >> <dick.ha...@gmail.com><dick.ha...@gmail.com> >> dick.ha...@gmail.com> wrote: >> >> The spec allows the AS to define additional parameters, so for these >> specialized use cases, Facebook could ask Microsoft and Sony to include an >> identifier in the request. >> >> Is that adequate? >> >> On Thu, Mar 4, 2010 at 6:28 PM, David Recordon < >> <record...@gmail.com><record...@gmail.com><record...@gmail.com> >> record...@gmail.com> wrote: >> >>> Devices such as an XBox or PS3 can keep secrets which is primarily >>> where we envision using the username/password profile. >>> >>> On Thu, Mar 4, 2010 at 5:52 PM, Dick Hardt < >>> <dick.ha...@gmail.com><dick.ha...@gmail.com><dick.ha...@gmail.com> >>> dick.ha...@gmail.com> wrote: >>> > >>> > On 2010-03-04, at 3:58 PM, Luke Shepard wrote: >>> > >>> >> On Mar 4, 2010, at 3:42 PM, Marius Scurtescu wrote: >>> >> >>> >>> On Thu, Mar 4, 2010 at 11:58 AM, Jason Hullinger >>> >>> <<sshja...@gmail.com><sshja...@gmail.com><sshja...@gmail.com> >>> sshja...@gmail.com> wrote: >>> >>>> >>> >>>> wrap_client_id - Required. The client identifier >>> >>>> wrap_username - Required. The User’s username >>> >>>> wrap_password - Required. The User’s password >>> >>>> wrap_scope - Optional. Authorization scope values defined by the >>> server >>> >>>> Additional parameters - Any additional parameter defined by the >>> >>>> authorization server >>> >>>> >>> >>>> From the above parameters there is no way of insuring that a client >>> is ever >>> >>>> who they say they are because a user could easily obtain the >>> wrap_client_id >>> >>>> and make requests using that. Does anyone have an implementation of >>> this or >>> >>>> any recommended additional parameters? >>> >>> >>> >>> I don't think you need to trust this client itself in any way, the >>> >>> user trusted the client and provided his/her username and password, >>> >>> that's all that counts. The should just verify these credentials and >>> >>> then issue refresh and access tokens. >>> >> >>> >> It's pretty important to Facebook that we be able to validate who the >>> client is when they pass in user credentials. We have pretty strict >>> restrictions on the ability for apps to take user credentials directly and >>> we need to be able to enforce those restrictions. I would like to see the >>> ability to authenticate the app as well in this profile. >>> > >>> > This profile was motivated by the use case of rich clients where >>> redirection of a browser is challenging. ie. a twitter app on a phone. >>> > >>> > Per previous discussions in OAuth, it is not feasible with current >>> platforms for an app running on a user machine to keep secrets from >>> malicious users. A web app of course can keep a secret from the user, but >>> use of this profile by a web app does not seem to make sense. >>> > >>> > -- Dick >>> > >>> > >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "OAuth WRAP WG" group. >>> > To post to this group, send email to >>> > <oauth-wrap...@googlegroups.com><oauth-wrap...@googlegroups.com><oauth-wrap...@googlegroups.com> >>> oauth-wrap...@googlegroups.com. >>> > To unsubscribe from this group, send email to >>> <oauth-wrap-wg%2bunsubscr...@googlegroups.com><oauth-wrap-wg+unsubscr...@googlegroups.com><oauth-wrap-wg+unsubscr...@googlegroups.com> >>> oauth-wrap-wg+unsubscr...@googlegroups.com. >>> > For more options, visit this group at >>> <http://groups.google.com/group/oauth-wrap-wg?hl=en><http://groups.google.com/group/oauth-wrap-wg?hl=en><http://groups.google.com/group/oauth-wrap-wg?hl=en> >>> http://groups.google.com/group/oauth-wrap-wg?hl=en. >>> > >>> > >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "OAuth WRAP WG" group. >>> To post to this group, send email to >>> <oauth-wrap...@googlegroups.com><oauth-wrap...@googlegroups.com><oauth-wrap...@googlegroups.com> >>> oauth-wrap...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> <oauth-wrap-wg%2bunsubscr...@googlegroups.com><oauth-wrap-wg+unsubscr...@googlegroups.com><oauth-wrap-wg+unsubscr...@googlegroups.com> >>> oauth-wrap-wg+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> <http://groups.google.com/group/oauth-wrap-wg?hl=en><http://groups.google.com/group/oauth-wrap-wg?hl=en><http://groups.google.com/group/oauth-wrap-wg?hl=en> >>> http://groups.google.com/group/oauth-wrap-wg?hl=en. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OAuth WRAP WG" group. >> To post to this group, send email to >> <oauth-wrap...@googlegroups.com><oauth-wrap...@googlegroups.com> >> oauth-wrap...@googlegroups.com. >> To unsubscribe from this group, send email to >> <oauth-wrap-wg+unsubscr...@googlegroups.com><oauth-wrap-wg+unsubscr...@googlegroups.com> >> oauth-wrap-wg+unsubscr...@googlegroups.com. >> For more options, visit this group at >> <http://groups.google.com/group/oauth-wrap-wg?hl=en><http://groups.google.com/group/oauth-wrap-wg?hl=en> >> http://groups.google.com/group/oauth-wrap-wg?hl=en. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OAuth WRAP WG" group. >> To post to this group, send email to >> <oauth-wrap...@googlegroups.com><oauth-wrap...@googlegroups.com> >> oauth-wrap...@googlegroups.com. >> To unsubscribe from this group, send email to >> <oauth-wrap-wg%2bunsubscr...@googlegroups.com><oauth-wrap-wg+unsubscr...@googlegroups.com> >> oauth-wrap-wg+unsubscr...@googlegroups.com. >> For more options, visit this group at >> <http://groups.google.com/group/oauth-wrap-wg?hl=en><http://groups.google.com/group/oauth-wrap-wg?hl=en> >> http://groups.google.com/group/oauth-wrap-wg?hl=en. >> > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth WRAP WG" group. > To post to this group, send email to <oauth-wrap...@googlegroups.com> > oauth-wrap...@googlegroups.com. > To unsubscribe from this group, send email to > <oauth-wrap-wg+unsubscr...@googlegroups.com> > oauth-wrap-wg+unsubscr...@googlegroups.com. > For more options, visit this group at > <http://groups.google.com/group/oauth-wrap-wg?hl=en> > http://groups.google.com/group/oauth-wrap-wg?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth WRAP WG" group. > To post to this group, send email to oauth-wrap...@googlegroups.com. > To unsubscribe from this group, send email to > oauth-wrap-wg+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/oauth-wrap-wg?hl=en. > > > > _______________________________________________ > 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
