When I was in Britain earlier this summer, I met Toby Stevens. How should I describe him? Can we invent the category of privacy entrepreneur?
Toby understands privacy issues deeply, and works in conjunction with veterans and visionaries like Simon Davies. He talks with wit and matter-of-factness about privacy as an opportunity for better relationships with customers – and potential for competitive wins. Not a whiff of odius obligation! Calm and relaxed, Toby easily convinces us that the new privacy era will be as hard to take as a pint of beer on a muggy day.
Now he has launched “a corporate membership body with the objective of identifying, developing and propagating best practice in privacy management. The forum (called Enterprise Privacy Group) will consider a broad spectrum of privacy and freedom of information issues.” A number of companies have joined already (including Microsoft, if I understand right).
He's also started a blog – and if this intelligent piece is any indication, it's a must-subscribe:
“Over recent weeks I've been talking with quite a number of potential member organisations, and one of the challenges has been explaining how we intend to cover a range of privacy issues, from very basic data protection through to some advanced identity management concepts. I had some difficulty explaining this spread, and from this I got round to thinking about the concept of a maturity model for privacy.
“My first ideas are in the diagram below:
“As the organisation develops through the maturity scale, it goes the following stages:
- Data Protection: at the earliest stages, the organisation understands that it has valuable personal information, and that there is a legal requirement to protect it in certain ways. However, there is no executive recognition that legal compliance does not necessarily protect the organisation from the consequences of misuse of that data.
- Privacy: the organisation recognises the moral imperative for ethical use of personal data, and that a proper usage policy – that applies greater controls than necessarily required by law – may reduce information risks and lead to better relationships with the individuals whose data is being stored and processed.
- Identity / Data Sharing: these issues are two sides of the same coin. In the private sector, organisations begin to recognise that data needs to be linked to an individual, rather than an asset. For example, a bank may start to link multiple accounts to the same account holder, and treat that holder as an individual in accordance with their privacy wishes. Data Sharing is the equivalent issue in public sector, where (contrary to common perception) most civil servants know that they already respect privacy of the citizen, and are seeking mechanisms to share data with other government departments without compromising that respect. Identity is crucial here if data is to be shared accurately and efficiently.
- ‘Data Rejection’: The top of the scale is Anonymity – an understanding that much of the personal data held by the organisation is simply unnecessary, and could in fact be more of a liability than an asset. For example, a bank does not (in theory, ignoring financial regulations) need to know who an account is, but simply how to check their credit score and how to contact them if necessary. The same bank faces heavy costs for compliance and risks of misuse whilst it holds that personal data. This has worked perfectly well for the Swiss banking industry for a very long time. When organisations start to minimise their personal data assets, then they are pushing to the top of the maturity model.
“Of course, ‘Data Rejection’ should be the goal of any true federated identity scheme. Once organisations and their clients realise the value of anonymised credentials, and the opportunities for new revenue streams based upon the trust that can be created this way, we should finally see someone reach this level in the maturity model (or maybe there's an organisation out there that's already done it?)
“I'd welcome comments on this idea, since it clearly needs lots of work before I start to back it up with hard survey data. Please feel free to let me know what you think.”
Toby's concept of Data Rejection bowls me over – I'll use it from now on. I think the continuum he has set up is tremendously useful. We haven't had a shorthand or sound bite – or even a word, really – to represent the practice of consistently using “just-in-time” information rather than taking on an unnecessary information retention liability. Now we have one.
At some point in the InfoCard research I realized that by associating the identity with a set of claims – under the control of the user – we do more than just give the user a way to conceptualize a digital identity that can be proven through use of a key. We also give her the ability to release claims as part of any identity negotiation process. By remembering what claims we have released where, the identity provider can make the same claims available to the same site next time they are asked for (assuming, of course, they have not changed, and the user hasn't decided to annul the relationship).
This means the relying party no longer has to remember them – even if they are essential to the business of the site – and data rejection becomes technologically feasable. The site just obtains the requisite information as convenient during its interaction with the user, and need not assume any information storage liability. Put another way, the information is stored in one place (the identity provider) rather than a hundred places (the sites a user visits). This reduces the probability of compromise by at least two orders of magnitude. We can probably expect that the difference could be closer to three orders of magnitude because maintaining the confidentiality of identity data would be the Identity Provider's core competency, not some burden it takes on in spite of itself.
If the relying party does need to audit and remember some information beyond its realtime usage, it should encrypt it under an asymmetric key guarded by special procedures within the glass house. None of the machinery of business needs to decrypt this information in realtime or on the network, greatly reducing the risk of vulnerability.
Maybe we should have a separate name for this, too.
