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> 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> 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> 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> 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> 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> >>> >>> 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. >>> > 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. >>> > >>> > >>> >>> -- >>> 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. >>> >>> >>> >>> -- >>> 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. >> >> >> -- >> 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. >> >> >> -- >> 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. > > > -- > 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
