On Wed, Jun 1, 2011 at 1:41 AM, Skylar Woodward <sky...@kiva.org> wrote: > 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.
You might be on to something there. There are two ways clients are authenticated in the spec. - client credentials - registered callback URLs People are combining them in interesting ways. And there is stuff outside the spec, such as the app-to-app authentication built into smart phone platforms. (This is used heavily in the facebook developer platform. We use it on Android, not on iPhone yet.) I haven't tried it yet, but I suspect organizing the security considerations based on how your client authenticates would be constructive. > (Some web apps might not be able to keep secrets based on open development or > deployment model). Can you clarify what you mean by this? What flows are you using for those apps? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
