Interestingly enough, when I bought, over the Internet, a ticket to Film
Forum in New York, the way it worked, it amounted to a number (token),
which I had to redeem at the movie theater. I was authenticated by
showing my credit card with which I bought the ticket; I guess I could
have been asked for a drivers license, too. So even in the movie ticket
case, there was a (sort of) strong authentication of the token bearer at
the point of obtaining the resource. Interestingly enough, the same
method is being used with the airline tickets, where the risks are much
higher.
This is why I am taking the same position as Eran.
Igor
Eran Hammer-Lahav wrote:
On 1/15/10 7:58 AM, "John Kemp" <[email protected]> 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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
