+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

Reply via email to