> The group is operating under the assumption that most > native apps are publicly deployed or that copies of the > app bundle/binary can at least be obtained by a malicious > party.
Agreed. > ... its always possible for the attacker to disassemble the > program and obtain the secret. Always possible? In theory, perhaps. As with any threat analysis, it depends on the resources available to the attacker and the motivations for mounting the attack. I firmly believe that secrets can be sufficiently obfuscated in code delivered in binary format without the benefit of a symbol table, so as to be sufficiently resistant to discovery via disassembly by attackers you'd expect to encounter in a typical commercial environment. I'm not talking about printable strings stored in contiguous memory. I think it's important, for a number of use cases, some of them of particular interest to me, for an application to be able to use this form of identification, when sufficient care has been taken to mitigate the threat model for the intended use. I'd rather see the risks inherent in providing secure storage of application credentials thoroughly discussed in the Security Considerations section, rather than discouraging it's use altogether in the normative protocol definition sections of the draft. I agree that there are many deployment scenarios in which secrets or passwords would not be an appropriate method of client identification, but I see some in which is clearly would be appropriate. 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
