That seems reasonable to me. We should make sure to distill this discussion into a "security considerations" section for that profile.
On Mar 10, 2010, at 8:55 AM, Dick Hardt wrote: > +1 > > On 2010-03-10, at 8:51 AM, Allen Tom wrote: > >> +1 >> >> I'd like to keep the existing username/password profile as it currently is, >> with the understanding that Service Providers may add additional proprietary >> parameters and secret sauce to authenticate the client. >> >> Allen >> >> >> On 3/9/10 9:32 PM, "Brian Eaton" <bea...@google.com> wrote: >> >>> On Tue, Mar 9, 2010 at 12:02 PM, David Recordon <record...@gmail.com> wrote: >>>> I'd rather support the client secret and document the hell out of the >>>> security considerations for the profile. >>> >>> Thinking out loud... what if we called it the "server you trust to use >>> username and password profile" instead of the client app profile? >>> >>> That would actually meet the xbox use case, as follows: >>> >>> 1) Microsoft uses magic security sauce to authenticate the xbox to >>> their servers. >>> This magic security sauce will be obscure, will probably change >>> frequently, and is probably going to rely on hardware security >>> modules. It makes no sense to standardize this, because the goal is >>> specifically to avoid interoperable implementations. =) >>> >>> 2) Their servers hold the client secret, and use it to authenticate to >>> whatever service they are using for password validation. >>> Note that they can actually change this secret, because it is >>> stored server-side. >>> >>> I'm sure that people are going to run off and use this profile to >>> hard-code secrets in their iphone apps, and if the secrets are >>> important they will be reverse-engineered and abused. But that's what >>> happens when you take a profile intended for one kind of deployment >>> environment and use it in a very, very different environment. >>> >>> (Also note that the user experience/completion rate for the >>> browser-redirect flows on thick clients can actually be pretty good. >>> We've done usability studies, and it works: >>> http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps. For >>> trusted partners you can customize the login and approval screen as >>> well.) >>> >>> Cheers, >>> Brian >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > -- > 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
