| Identity <> Authentication <> Authority I deal with this in my industry (telecommunications). Just because you've provided proof of identity (eg your phone number, account number), there are still things you're not allowed to do until you've authenticated your identity--and the system determines your authority, to perform an action. This is accomplished through a password, a PIN, etc. On a phone, it's an interesting shift because with a PIN, we essentially bypassed the need for identity and used only a password; regardless of who you are, you can get in if you have the right key. With the move to identity being sufficient to unlock a device, we're saying that just on the basis of identity, the authority that used to come with a password (sans identity) can be granted. It's a 180 degree turn. I don't see a way on my iPhone 6s to require both Touch ID and PIN; it's one or the other. Very few interactions require both, i.e. after a restart it requires the PIN before Touch ID will work. edit: to clarify the difference |
For example, most phone manufacturers think that the owner of a phone should always have permission to perform any action on the phone, so as long as they can authenticate the person holding the phone, they can authorize them to do anything. In this case, authentication => authorization.
Contrast this with OAuth, which it seems most people don't understand well. OAuth is a mechanism for authorizing people other than yourself to perform actions on your behalf, e.g. a third party application to post on your Facebook wall. In this case, authorization !=> authentication.
However, sometimes third-party applications don't care about performing actions on your behalf. They work on the assumption that only the owner of the account could authorize an OAuth token to give back to them, so they use other OAuth providers as authentication, e.g. login via Facebook. So in this case, authorization => authentication.
Another example is accessing secret files at a company. A person might be authorized to view the files but only from a secure device. In this case, authentication is required but not sufficient for authorization. In this case, authentication !=> authorization.
In the case of payment via phone, you need authorization. Authentication can be one factor in the authorization process, but clearly its not sufficient because the authorizing party could be asleep and therefore unaware of the transaction. Phone manufacturers might want to look at risk-based escalation -- requiring more factors for some applications, or as the sum of money increases, or perhaps even based on time of day.