> I don't understand this argument at all. The two questions you > seem to
> think are being confused are the *same* question.I don't think so.> When I
> type in "https://www.amazon.com";, what I want> to know is - do I have a
> secure connection to Amazon?This is an authentication question.> A secure
> connection to someone who is out to steal my> credit card is not really any
> better or worse than in > insecure connection to Amazon.True. > A secure
> connection to an unauthenticated source is of> no value because the
> unauthenticated source could be> the one person who the connection is
> supposed to be> secured from. If there's nobody the connection is > supposed
> to be secured from, why would you care> that the connection is secure?In
> general this is false. There are security paradigms such as SSH where you use
> "leap of faith": strictly you haven't authenticated the remote end, but you
> "know" that your peer is the other box next to you, you verified its PK
> fingerprint visually, so you approve ("authorize") that peer from now on. >
> Authentication and authorization are the same thing.Absolutely not!
> Authentication is "who I am talking to". Authorization is "what I allow you".
> Indeed, usually authorization is meaningless without authentication (not
> always: many systems have the policy "and everybody outside of the group of
> authenticated peers shall be allowed only ...").> They are both requiredThis
> is correct, of course. Because you cannot perform authorization (make
> decision) unless you know whose access you're deciding about. And unless you
> are going to make different decisions based on different peer identities - it
> makes no sense to authenticate.Note that authorization often is degraded to
> "allow or deny login", based on wheher the peer authenticated correctly or
> not.
