Encrypting basic card data

Hi all,

We discussed putting together a more sophisticated card payment method spec
at the f2f but I wonder if we shouldn't raise the bar slightly for the
basic card spec before we go to CR already?

The obvious solution is encrypting the card data in the payment response.
The challenge is deciding what key and cipher suite to use and that
introduces a massive amount of complexity.

We can use asymmetric crypto and the merchant can provide a public key in
the request (either unique per transaction or not) which the payment app
uses to encrypt the response data. This would not eliminate MiM attacks as
a MiM could substitute the key for their own and still steal the
credentials. It would however prevent sniffing data from this channel so
that an attacker that is monitoring the events/logs but isn't able to
actually intercept the messages is thwarted.

I believe this is a simple enough solution that we could specify it as a
minimum bar and all payment apps/browsers would be capable of implementing
this from day 1. What do you think?

Note: I'm leaving talk of a more sophisticated solution where the keys are
bound to the merchant and can be verified by the payment app to another
discussion, there was a decent size group of volunteers in London
interested in exploring that topic.

Adrian