On Oct 27, 2010, at 8:09 PM, Freeman, Tim wrote: > The questions currently interesting to me about use cases are: > > * The only use cases that made sense to me about signatures used them for > auditability, where they enabled blame to be properly placed after > information leaked to the wrong people. People were proposing use cases that > claimed that signatures improved privacy, that is, the ability to keep the > information out of the hands of the wrong people. So far as I know all use > cases where signatures improved privacy seemed to fall apart after a few > minutes inspection. Do we agree that signatures improve auditability but not > privacy, or does someone still believe in a use case where signatures improve > privacy?
For Kiva, our use case would be something along the lines of "secondary protection mechanism." To access certain types of data we want client authentication (ie, identification) to request and use tokens. The specification w/o signatures depends only on SSL to protect secrets, passwords, and tokens and thus client identity. By requesting signed requests we have a second mechanism on top of SSL to protect secrets in the event that request is leaked to an improper endpoint - as secrets are never sent over the wire. To reuse some of Zachary's language, we're combining two solutions to solve one problem. We agree of course, that SSL, properly used - with no human error, is enough to secure the secrets between the two parties. However, secondary protection mechanisms are popular in the financial world - site keys, RSA fobs, shared secrets, IP-filtering, SMS-issued pins. Though any one mechanism is enough, a second mechanism makes things even more difficult for clever attackers (and careless developers). Given the options available to us, shared secrets confirmed though the use of signatures offer the most attractive balance of protection vs. ease of deployment (many of our partners are in developing countries which offer logistical and technological challenges to other methods). That said, I don't advocate requiring signatures as a part of the spec (our needs/preferences are possibly too unique?), but I would like them included. Thus, if some non-political use cases drive signatures to be added, we'd certainly like to adopt the common standard. In lack of a published standard for signatures, we'll add our own layer additional layers of protection onto the spec as others have done. (OAuth 1.0a signatures suit us in lack of a simpler new standard for 2.0, especially given the amount of published works related to doing them correctly.) skylar _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
