This may be true for a "secret" of sorts in some applications, but not for the client_credential in OAuth. The client secret is the only element that can secure the identity of the app and if it is compromised then so is the ability of the app to assert its identity. There's no way a software program on a open mass-market runtime can secure the secret as a part of its own software distribution (and likely true for any mass-distirbuted system) . So we should stick with the advisement that apps that can't keep secrets not be issued them - its a big win for setting the correct expectations to developers and users over 1.0.
If the client_secret were merely one element in protecting access maybe this your suggestion would be true. However, given the difficulty of embedding and obfuscating a secret in a hard-to-find way, and the requirement that every developer would have to do this in his own proprietary and secret way, it seems not a scalable solution for the multitudes of apps that will be OAuth clients. It's better for developers to consider other mechanisms - starting with secure distribution of the software. skylar On Jun 2, 2011, at 11:54 PM, Dave Nelson wrote: > On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton <bea...@google.com> wrote: > >> Well, "rely" is a strong-term. I know of various teams who do this. I >> don't know of any teams that put a heavy reliance on it. > > It might validly be just one element of a defense-in-depth strategy. > > Regards, > > Dave > > David B. Nelson > Sr. Software Architect > Elbrys Networks, Inc. > www.elbrys.com > +1.603.570.2636 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth