On Apr 2, 2011, at 3:19 PM, Phillip Hunt wrote: > If we take the current implementers as evidence it shows we have little or no > security either due to misunderstandings or business decisions to accept risk > for flexibility. >
This type of language is also not helpful for moving us forward. I'd like to see the discussion focused on the development of a useful specification that also meets the challenge of being open (working with many different use cases and contributors) as opposed to subjectively evaluating the polices or relative qualities of individual companies. This is the reason we are working together in an open community to collaborate, rather than each company developing their own proprietary solution. I'm actually quite proud that nearly since our inception Kiva has always protected every bit of consumer-private data via HTTPS, including pages with private data and connections bearing secure session cookies. However, the default security we've put in place for every user may be more security than they care about. Opening this data via API allows new uses of the data outside the current constraints of the core product. As an example, every user's lending profile is currently private and secured over HTTPS. If a third party app wants to allow users to share their complete lending profiles to the public internet (or to one's friends on a social network running over HTTP only), such an API can allow that. If OAuth can't serve as the permissions mechanism to enable such sharing or flexibility of data it would be a shame. It's really outside the scope of this spec to police the policies of developer programs or their effectiveness in communicating to their users the risks or na ture of the apps in their ecosystems. I hope we can return to a productive discussion in striking a balance between a flexible and effective specification. I think most of us understand the risks of the MITM attacks being described, yet sensational language and judgements are being tossed about - and for what purpose I don't understand. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
