[mseebach]

There is a major use case around "card not present" transactions.

Anything recurring, such as AWS, hotel/car rental express check-out/return, Amazon 1-click and Uber and similar mobile payment use cases will get significantly higher friction if you have to complete a chip-and-pin for each of these.

A quite simple fix to these would be to allow storage of a token linked to the PAN which is locked to a specific merchant - so, they're worthless if stolen, but can be used like the PAN is today to perform "card not present" transactions for that merchant.

[BlackFly]

This problem has already been solved.

Most interchange protocols contain flags for recurring payments and standing authorizations. Only the first such transaction contains chip data to prove that the cardholder actually wants to authorize a standing auth/recurring auth.

In these cases, the standing authorization is already tied to the merchant + PAN + address details. Using chip in the first place is what allows a database compromise which leaks the PAN to not enable a criminal to authorize at another merchant: they won't be able to generate the ARQC needed to authorize.

All subsequent standing auths are card not present anyways.