+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" <[email protected]> wrote:
> 
>> On Tue, Mar 9, 2010 at 12:02 PM, David Recordon <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to