On Fri, 2010-01-15 at 14:41 -0700, Eran Hammer-Lahav wrote: > > > On 1/15/10 7:58 AM, "John Kemp" <j...@jkemp.net> wrote: > > > When I look at what is possible in the offline world, I would ask - would > > you > > require that movie theatre tickets bought in advance were encrypted in > > transport between the person who bought the ticket and the receptionist at > > the > > cinema? What if the person drops her ticket and it's picked up by someone > > else? The risk of someone dropping his ticket is low, so we don't bother to > > secure it (of course, I haven't been to a city movie theatre in years so > > perhaps you need to show ID even to see a movie these days -- I hope not ;) > > Of > > course, the person who _does_ drop his ticket will be mad when he gets to > > the > > movie theatre, but probably not too mad. The system has worked quite well > > without any real security. We might add more security, but it would, even > > today, probably be hard to justify the cost. > > I don't think this is a fair comparison. Stealing a movie ticket is very > hard, and punishable but fines and prison time (potentially federal is > captured in transit via US Mail). On the other hand, capturing bearer tokens > while sitting at a Starbucks using nothing more than a laptop with a WiFi > card is trivial. > > > Yes, those things change over time, but having a sliding scale of security > > is > > a good thing, not a bad thing - and that is already allowed by OAuth today, > > (TLS/SSL+PLAINTEXT, RSA-SHA1, HMAC-SHA1, PLAINTEXT) and will continue even > > if > > you remove PLAINTEXT from the list. > > We are creating web standards, not just generic technologies. I don't want > to find *any* PLAINTEXT implementation on the web, but don't care if someone > uses it on their own private network. But if that's what they are doing, > they are free to drop TLS/SSL requirement anyway because they control the > environment.
I'm in 100% agreement on this point if the MUST is constrained to limit only non-encrypted PLAINTEXT implementations on the web. > Since we are talking about one word, MUST vs. SHOULD, I think we should > start with MUST and continue having this discussion when we have more pieces > of the puzzle in place. > > EHL > > _______________________________________________ > 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
