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
