Earlier in the year I posted some comments for the GDPR Article 29 market consultation on Guidelines on consent. I look forward to the publication of the final guidelines.

In the mean time, this week I had the good fortune to have a conversation with a lawyer specializing in GDPR and PSD2. During this conversation the lawyer agreed with my opinion that the proof of 'Strong Customer Authentication' (SCA) / proof of Consent is deemed to be 'personal data' and as such the 'Data Subject' / 'Payment Services User' (PSU) is entitled to request a copy of the proof. Also because the PSU provided this personal data, they are also entitled to request an electronic link be established with a third party company to transmit this data.

This leads me to ask, can the proof of SCA / Consent be deemed to have been shared unless sufficient data is provided to enable the PSU/Data Subject to verify the proof?. Indeed, if the proof cannot be verified, it is essentially worthless.

Today's EMV bank cards contain a (secret) 'symmetric key'. The bank holds a duplicate copy of this secret key, which it uses to verify the proof of SCA/Consent. Therefore in order for the PSU/Data Subject (or a third party company company on their behalf) to verify the proof, they must also be provided with a copy of the secret key. In principle the PSU could use their EMV bank card, however if they were to lose the card or cut it up (as instructed, following expiry), they would be unable to subsequently verify the proof. From a security perspective, the bank is unable to distribute copies of the secret key. Therefore this leads me to question the applicability of using an EMV bank card to perform SCA/ Consent capture.

One way of overcoming this issue would be for the 'symmetric key' to be replaced with an 'asymmetric' public/private key pair. The private element would reside on the bank card only. The public element is packaged as part of the SCA/Consent proof. This allows the proof to be shareable and verifiable by multiple parties. This is the approach that has been adopted by eIDAS with respect to eSignatures.