On Jun 1, 2011, at 10:18 AM, Brian Eaton wrote: > And it would meet the requirement of having a clear path forward for > people who don't want to trust native apps to keep secrets really > secret.
I just want to re-iterate my point from a few months ago that it necessarily helpful to draw the line for secret protection between native and non-native apps. For our users we're going to use the terms VERIFIABLE and FORGEABLE with respect to client identity. We'll help users determine if the can keep secrets or not. Developers who understand they can't keep secrets will understand their app identity to be forgeable (and thus they will not be issued secrets). Most native apps will be forgeable thus we'll point them in this direction, but there will be exceptions (especially with partners with protected app distribution). My point is, we should focus on having developers understand if and why their app can't keep secrets, not merely thinking "oh, this is app is native so I have to do it this way." Verifyable and Forgeable were the best terms we've come up with so far in attempt to put a label on "apps that can keep secrets" and "apps that can't keep secrets," respectively. There are some aspects of OAuth flow that are unique to native apps (mostly on account of the app not executing in a user agent), but ability to keep secrets is not a property shared or exclusive to all native apps. (Some web apps might not be able to keep secrets based on open development or deployment model). _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
