My design principles would be the following as we already have protocols that solve many complex usecases
1. Simple programming model 3. Reduce deployment barriers 2. Limited or no client side code (works with a browser) 3. Replace username/password scenarios 4. No client side key distribution nightmares -----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eve Maler Sent: Monday, March 22, 2010 4:01 PM To: OAuth WG Subject: [OAUTH-WG] What are the OAuth design principles? Since the discussion in the "OAuth after-party" seemed to warrant bringing it up, I mentioned the UMA design principles/requirements document. You can find it here: http://kantarainitiative.org/confluence/display/uma/UMA+Requirements The discussion is around "Why can't Kerberos just be used for your use cases?" The UMA principles might be able to inform how the OAuth WG makes its case for why Kerberos doesn't suffice. (If we discover it does, hey, our work here is done. :-) Eve Eve Maler e...@xmlgrrl.com http://www.xmlgrrl.com/blog _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
