Fighting Words: Why PCI's Token Group Blew Up

The PCI group working on the Council's tokenization policy got so embroiled in infighting that it had to be restructured by the Council, which mostly explains the year-long delay in the Council's tokenization policy. But this is hardly surprising, given that the group is mostly employees of competing security vendors, almost all of whom are trying to skew the Council's policy to benefit that vendor's approach.

The token guidance that the group and the Council staff ultimately released on August 12 was a classic compromise, in that it pleased few in the group but was a huge step forward for retail security. The purpose of such guidelines is not to get so specific that it benefits any vendor, but to give instructions to QSAs and retailers on what is permissible and what isn't.

Reaction to the document has fallen into these two camps: one saying that the document was not nearly specific enough and is passing the buck to QSAs, and the other saying that this guidance represents major progress and that it should be applauded. Unlike some political camps, both sides here seem to readily acknowledge the other position, with the "not nearly far enough" crowd generally agreeing that it indeed is a lot better than what was there before (which was essentially nothing), and the "it's a big step forward" crowd agreeing that more specifics would have been helpful.

It's that last point where corporate politics comes into play. Almost all agree that more specifics would have been better. But when it comes to deciding which specifics, well, that's where the technical arguments devolved into impasses.

The key takeaway of the PCI guidance was that tokens—done properly—could be considered out of scope. On the concerns side, some participants were unhappy that the PCI Council opted to say that tokens that can be used directly as payment devices, which it dubbed high-value tokens, might still be in scope.

Token vendor Shift4 quickly posted on its Web site a very pointed attack of what the Council published, and it seemed particularly unhappy with the high-value token suggestions.

"On page 20, we find this little gem: 'Additionally, tokens that can be used to initiate a transaction might be in scope for PCI DSS.' Might? Wasn't the whole purpose of this document to take what 'might' be true and determine what really is true?" Shift4 asked.

Another participant in the talks, Merchant Link Product Group Manager Sue Zloth, also published concerns about the high-value token reference, saying that "I do have an issue" with it. "As it is currently written, [it] will introduce a lot of fear, uncertainty and doubt into many merchants' minds regarding how to keep the systems they have, which are storing only tokens out of scope. For solutions that support these types of tokens, the guidelines state that there must be additional controls in place to detect and prevent fraudulent transactions. This is where I feel the Council's document fell short. They introduced this concept that tokens may potentially be back in scope without providing guidance as to how to keep them out of scope."

StorefrontBacktalk's own PCI columnist, Walter Conway (whose day job is being a QSA), also zeroed in on the high-value token reference and the Council's conclusion that it may have to stay in scope.

"This conclusion likely comes as a surprise to many retailers and other merchants (along with their tokenization providers). For example, E-Commerce merchants who use tokens for one-click ordering and repeat purchases (leaving the underlying PANs with their processor or another third party) just learned their tokens will still be in scope for PCI," Conway wrote in this week's column. "I wonder if the hotel room keycard (or resort account) I use to charge meals is a high-value token because it generates a payment-card transaction? I even wonder if tokens used for exception-item-processing such as chargebacks and refunds are high-value tokens because they impact (even if it is to reverse) transactions?"Ulf Mattsson, the CTO at Protegrity and another participant in the PCI process, said the issue of taking something out of scope and putting things back in scope is critical, and that retailers need to know concretely what will happen if they take specific actions. "When you push out the tokens in the dataflow, there is no way back," he said. "It's in the bloodstream of your enterprise."

Mattsson, like many others, expressed disappointment more for what was not ultimately covered in the guidelines than for what was.

"It took too long to get this supplement out. I have seen so much material that could have been part of this supplement," he said, citing one example of the need to now revise the self-assessment form. "We need to add questions that assess the tokenization area. It's a gaping hole."

Another area of concern for Mattsson is the token training that QSAs will have to go through. "If we had a more detailed guidance document, then less training might be needed. And I would like to see a roadmap for future validation, an independent technology validation."

Mattsson also described the token group's reorganization and how that delayed the guidance. "I think it escalated when we tried to finalize the document. One vendor pushed its encryption and we spent a lot of time fighting about that," he said.

Merchant Link's Zloth said PCI Council management opted to reorganize the group—officially a PCI SIG—by adding more PCI staff people. "The Council decided they were going to put resources on it. Definitely there was a shift from the participating organization-led group to the PCI Council-led group," she said. "It was a shift of people and a shift in what the document ended up looking like."

What was the nature of that shift? "The earlier draft was a combination of a guidance document and a validation document," Zloth said, adding that the final version was solely a guidance document. A validation document would typically trigger a validation program, which would involve training, lab work and other items.

The PCI Council was "not prepared to create a whole validation program for tokenization," she said, especially given the fact that PCI is just about to release the full validation treatment for point-to-point encryption.

Although the compromises were needed to get the document published, a more specific report could have been helpful, Protegrity's Mattsson said.

"My view is that the Council and some card brands are very nervous about new and unknown risks that tokenization may introduce. They point to the QSA, but there is no training or check list available or announced to help the QSA," he said.

The CEO of another tokenization vendor, Shift4, touched on the inherent conflicts in any association such as PCI.

"The greatest balancing act for the PCI Council is not a product of balancing different merchant types or even balancing giant retail chains with mom-and-pop shops. Rather, their biggest roadblock is their apparent desire to satisfy (or balance) all of the needs of the various third parties that have a product to sell," said J. David Oder. "There is a lot of money in security solutions and the pressure on a standards body is immense.

"A weak standard is one thing, but the caveat that merchants and their banks should consult their QSA is indicative of the weakness of PCI. What good is a standard if it has been delegated to 100 different organizations with 100 different opinions, especially when some of the opinions are so obviously swayed by the fact that they sell their own tokenization or end-to-end encryption products?" Oder said. "The QSA community was created by the PCI Council. Yet, unlike many other standards bodies, the Council has not yet created a prohibition on conflict of interest for QSAs. They likewise have no mechanism to arbitrate conflicts between merchants and QSAs, between QSAs, or between suppliers and QSAs."