Slashdot brings us this article highlighting yet another picture-perfect case for the VRM Personal Data Store:
Technical Writing Geek writes with the news that the retail industry is getting mighty fed up over credit card company policies requiring them to store payment data. The National Retail Federation (NRF) has gone to bat for store owners, asking the credit industry to change their policies. The frustration stems from payment card industry (PCI) standards and new security measures going into place across the retail experience. Retailers are now trying to point out that many of the elements of the standard would not be a requirement if they didn’t have to store so much payment data.
“Even if the NRF’s demands were immediately met, it would take several years before retailers could purge their systems and applications of credit card data, he said. Over the years, retailers have collected and stored credit card data in myriad systems and places — including relatively old legacy environments — and they are just now realizing the data can be a challenge, he said. Purging it can be a bigger headache because the data is often inextricably linked to and used by a variety of customer and marketing applications; simply removing it could cause huge disruptions.”
This is another excellent example where the Personal Data Stores of the Vendor Relationship Management initiative would profoundly simplify integration challenges. The current situation has each retailer acting as an unwitting data silo, storing sensitive information just waiting for hackers to bust it open. The PCI standards try to address this problem by hardening the silos, making the myriad of retailer data systems a sort of armored field of honeypots–and making the retailers liable for breaches. Understandably, retailers are a bit frustrated by the additional demands. However, if the data stores were completely distributed based on the user, rather than the retailer, we could not only remove the liability from the retailer, we could turn the field of honeypots (each with data on potentially hundreds or thousands of users) into endless fields of pollen-bearing flowers, each with just the data for a single individual.
Ultimately, each Personal Data Store–indeed any data store–is a potential target for hackers. However, PDs turn the retailer’s problems upside down in two ways. First, to the extent that PDs are distributed down to individuals’ own computers, the potential identity theft is reduced from a sweet haul of data for potentially tens of thousands (or more) individuals stored at a single retailer down to a single, isolated identity at one individual’s computer. That is, the honey is disaggregated back into the pollen, making it much less attractive to potential hackers… a much lower payoff for the same hard work.
Second, generally speaking, retailers aren’t well-equipped to handle secure IT issues. That’s not their business, even if a few do it well. That means most retailers are much better off placing the security risk in the hands of a service provider who is a specialist in maintaining a secure data store. That’s precisely what they are asking the credit card industry to let them do, even if they aren’t quite thinking of it that way. By moving the at-risk information into Personal Data Stores run by companies whose entire business is in protecting and maintaining those Data Stores, the risk can be managed by trained professionals whose sole goal in life is protecting that data. This would seem much better than leaving it in the hands of retailers whose business focus is, appropriately, on innovative ways make money selling products to customers.
Reintegrating with the user as the focal point would turn this problem inside out and give retailers, credit card companies, and credit card users a more robust, reliable, and secure solution with less risk and reduced liabilities. I’m not sure who the right entities are to build out this solution, but I’m betting that XRI/XDI, Higgins, and VRM are all enablers.
Another great use case.
It occurs to me that this model works best (or maybe only works at all) where the data store’s view of the world is relatively small. For example, there are lots and lots of health care providers or retailers out there, but I only deal with a fairly small number of them. That means I can reasonably keep track of who has access to the sensitive parts of my data store
Some parts, e.g., the blog-like parts, might be open to the public at large. That’s also easy to track: “Anybody and everybody” is basically one list item. Or “people in my friends list” is also one item. Things get dicey when I have to keep track of, say, dozens or more items on the access list. Defining groups definitely helps, as long as I don’t spend all my time managing the groups …