Double-blind Identity

Note: Cross-posted from the Oracle Fusion Blog.

On November 13 and 14, the Government of British Columbia, Canada, launched the first in a series of public consultations on identity and digital services. For several years now, BC has been working on a new identity services project that would enable citizens to securely access government services online. For BC, there is clear motivation: reducing identity management and fraud costs in everything from drivers licenses to health insurance. BC's hope is that this can play a role in helping provide better services down the road as well as improving the overall privacy of residents.


For background to the challenges and motivations for BC, check out former BC CIO Dave Nikolejsin's talk on the importance of identity management in 2012 and the principles behind BC's identity project:

Incidentally my favourite quote from this video is: "Government will never be downstream from your Facebook account".

This first public consultation was focused as technical level-set meeting including standards community members from companies like Microsoft and Oracle and other vendors, as well as some members US Govt's NSTIC program, New Zealand Gov't, and British Columbia including its privacy commissioner, Elizabeth Denham. Most importantly, the meeting included several members of the general BC public picked at random from over 15,000 applicants. The day was spent educating and putting participants on a more equal footing on the basics of identity theory as well the challenges and objectives BC has for this program.

As part of this level-set, Collin Wallis, Identity Architect for the New Zealand Gov't, gave a great talk on how NZ and BC are similar in size and have many of the same overall cultural values and privacy concerns. He spoke about NZ's current "RealMe" deployments and their immediate focus on the "authentication". A similar presentation is available here.

The BC Gov't showed an overall architecture based on issuing new driver's licenses and Government Services Cards with near field chips (NFCs) supplied by SecureKey. The architecture depends mainly on OAuth2 authorization and SAML federation techniques that provide a "directed" identifier approach creating an infrastructure that has privacy qualities that could be said to be "double-blind".

You may recall that the term "double-blind" comes from medical research where both the tester and subject are blinded.  In the case of identity, the term implies the authenticator and relying party are blinded in a way that ensures privacy for the subject (the citizen).  The authenticator is not able to observe what personal information is shared or how the identifier is used assuring the citizen of freedom of use without monitoring. The relying party receives a directed identifier for the citizen unique to the relying party's use (see Kim Cameron's Law of Identity #4). What this stuff means is that two relying parties cannot share information directly based on a common identifier (as would happen if one used an omni-directional identifier like a SSN/SIN or Driver's License number). The same individual authenticating to two different parties appears to have separate identities. Hence the architecture could be said to be a double-blind system with strong privacy enabling qualities in its core design.

If successful, NZ and BC citizens may soon use their New Zealand RealMe or BC Government Services Id as a common authenticator to login and/or obtain services, while at the same time, avoid the privacy problems that occur when using a common identity such as offered by social networks, using personal email addresses. Their biggest challenge: BC and NZ need to avoid the fears of other national identity programs such as the US's "REAL ID" or the UK's "National ID" programs by building public confidence in its privacy-centred architecture.

For me personally, the most inspirational aspect of the consultation process was the leadership that Minister Andrew Wilkinson and his CTO, Ian Bailey, showed by adopting an "unconference" format that those of us in the IAM industry have come to know well at our regular meeting Internet Identity Workshop meetings. Following the first day's level-set session, an unconference session was led by Kaliya Hamlin (aka IdentityWoman) as well as Aron and Mike of IdentityNorth on the second day. This format was so successful that the group acknowledged highlights of the day were the members of the general public who chose not only to participate in deep theoretical discussion, but lead 3 of the most insightful sessions of the day!

To be clear, double-blind identity is not necessarily that new--we may have just put a term to it. After-all, there have been many systems with pseudononymous authentication. However, as technologists, we've been too accustomed to centralized architectures where both authentication and personal information in the form of claims come from a common provider (an Identity Provider). In these traditional enterprise architectures privacy has taken a back seat since employees don't often need to expect privacy in regards to performing their jobs. In contrast, these two governments are showing that privacy-enabled identity systems require separation of personal information from authentication services. I wonder what this means for cloud services architectures of the future and whether the current all-knowing social networks can survive the privacy problems they are running into by amassing so much information. It certainly suggests that the social network big data approach where all personal information is in one place is not the right way to go if governments really care about privacy.

Disclosure:  I am a resident of British Columbia. While my employer is a supplier to the government of British Columbia, I am not currently directly involved in this or any other projects with BC. My participation and comments are based as both resident and a member of the identity standards community. The views expressed are my own and do not necessarily reflect those of my employer.

Canada backpedals on sharing ID database with U.S. - What is the difference between sharing and copying?

The Globe and Mail posted an interesting article entitled "Canada backpedals on sharing ID database with U.S.".

Here is a great example of the differences between sharing access to information and copying information between organizations. It seems the original plan was to let the U.S. "house a database of personal information about Canadians who hold special driver's licences aimed at better securing the border." Plans changed after criticism from both federal and provincial privacy commissioners.

Once in the control of the U.S., the data "could be disclosed to other organizations for any other purpose as authorized by law." While there are obviously good intentions by all parties, the problem is, that once out of the control of Canadian authorities, it would be difficult for them to audit how the U.S. used the data. And in the event of any problem, the multi-jurisdictional issues, would be difficult at best. Sharing entire databases requires enormous trust between governments for this to happen.

The Canadian Border Services Agency now says the data will be housed in Canada where the agency will be responsible for its security. What is the difference? Well, a couple come to mind:
1. The data remains in Canadian jurisdiction and its use subject to Canadian law.
2. The CBSA is now in a position to audit each use of the data by the U.S.

In this scenario, the CBSA is acting as an "authoritative" data source. By collecting and retaining the information, it is appropriate that the authority maintain control over the data's use as it has the responsibility for loss, breaches in security, and most importantly the quality of that data.

The sad thing, is that proposals to share CDs of databases are nothing new. I seem to recall an incident in the UK not too long ago.

Because of this issue alone, it is my personal belief that federated identity systems are going to become critical to improving personal privacy down the road. To date, the focus of federated system deployments has been on single-sign-on approaches linking different sites that each hold permanent copies of our personal information. But as federation technologies become more widely deployed, they can and should be used to share identity information, on-demand, where the transfer can be secured with user consent, and where request for information can be audited.

Government as a Justifiable Party

For those of you who don't know, Vikram Kumar of the New Zealand State Services Commission has an excellent blog on Identity and Privacy.

Vikram's latest post, "When is government a Justifiable Party?" is a must read on the issues of government participating in a transaction.

Vikram talks about the natural and cultural resistance people have to having a government run services and in particular know more than they need to know about us. What is happening now with user-centric identity is that technology is evolving such that governments could act as providers of identity information in ways that do not allow a government to track use of that information. After-all this happens in the physical world. How often do we use a government "card" (such as a driver's license) or "statement" to prove something.

We should expect individual government agencies to offer only very specific assertions or statements about their citizens. These assertions would be related to what that a particular agency is accepted or legislated to be authoritative on. This contrasts greatly with the idea of a single government identity provider that knows too many things about us and holds the potential for inappropriate use (at least in the public's eye). Individual government agencies should only be able to make specific authoritative statements or assertions about their citizens or service consumers. Then it is up to us, as citizens and consumers of services to decide how and when information is transferred between agencies and between agencies and private enterprises.

Aside: one of the problem's I have always had with driver's licenses is they carry entirely too much information on them and are used way too often. An electronic, user-centric, identity network would be able restrict the information released on a need-to-know basis.

To be clear, government as a "justifiable party" is not about governments collecting more information! Government as a justifiable party is about governments securely sharing the information they are authoritative for under the control of the individual citizens about whom the information is about.

SOX Compliance Journal: Identity Governance Framework

An article written by myself and Marco Casassa Mont of HP on Liberty Alliance's IGF initiative addressing privacy and SOX is featured in Sarbanes-Oxley Compliance Journal.

This article is a good introduction to the problems of privacy and compliance as it relates to personal information and how IGF is intended to make the compliance of applications and the businesses that deploy them much easier to achieve.

Enjoy

Copy and Sync Bad for Privacy

I read an article by Rosie Lombardi in InterGovWorld that turned out not to be what I thought it was about on first reading the title "Secret identity: Solving the privacy puzzle in a federated model".

The article turned out to be a discussion not of classic web federation, but one of different approaches to using LDAP in a federated government setting. In the article, Rosie lays out the case for the copy-and-sync meta-directory approach, vs. the case for dynamic access via virtual directories. While the article was not about classic web federation using SAML or InfoCards, the article makes for a very interesting case study in federation, because the author is talking about two very different approaches using the same protocol.

Note: for those that don't know, I came to Oracle as the head of development for OctetString--a virtual directory vendor. I am obviously biased, but I hope you will see my observations are much more general than just about LDAP.

As I read the case for copy-and-sync, another article came to mind from Robin Wilton at Sun. He writes about the recent HMRC security breach in the UK where government entities were copying citizen data between departments and in the process lost one of the copies. As it turned out, their approach of copying information created huge exposure for the UK Government.

Any time entire data sets are being copied eyebrows should be raising. Instead of minimizing information usage, information was being propagated. Control was being distributed, enabling the possibility of mistakes as more systems and hands have access to valuable personal information. In fact, the people with the least control are usually the persons identified within the data -- the persons whose privacy should be protected!

On the other hand, Rosie makes a good case that when you take the minimal approach of federating information on the fly (such as with Virtual Directory), your security may be minimized to the lowest level security provider of the federation. In response, I would contend that bad data is still bad data whether it is obtained through copy-and-sync or through dynamic querying. The fault lies not with the approach but with the data itself. The protocol and approach matters little at this point, bad data is always bad data.

The positive news is that obtaining data dynamically from a provider of personal information means that data is the most current available and not dependent the frequency of the last update. Control is maintained by the information provider and each usage is auditable. Consent is also more easily verified as it is possible to check each specific use of information and whether consent is needed and obtained.

Whether the protocol used for federation was LDAP, SAML, or WS-Trust, the issues remain the same. Those building federated applications need to be able to trust their providers. They have to be able to assess the quality of their sources. There are no easy answers right now. Just as with PKI trust in the past, trusting information transferred comes down to assessing the quality of information and procedures and the quality and stability of the physical infrastructures. Liberty Alliance has launched a new initiative called the Identity Assurance Framework (IAF) where they hope to begin to solve this problem. Check it out.

Separation Anxiety

GovTech.com has an interesting article on how the US and US State governments are stuggling with disconnecting credentials from the concepts of identity.

In this article, the author, Shane Peterson, gets to the key point, the too often we confuse relationships we have with government with identity. The fact is we have multiple relationships.

Harper, a member of the Department of Homeland Security's Data Privacy and Integrity Advisory Committee and author of Identity Crisis: How Identification Is Overused and Misunderstood, said he and former Utah CIO Phil Windley arrived at the same conclusion.

"He expressed it very well [in his book, Digital Identity]," Harper said. "An identity is a relationship. There isn't just one relationship you have with the government, and that defines every other relationship you have. So the idea that we'd have an identity system structured as a government-created identity system is equally inaccurate."

This mindset is what caused the driver's-license-as-credential problem in the first place, he said, and America is still locked into the idea that there's a simple way to create a single, uniform identification system.

It's a holdover from days gone by, he explained, when so many transactions used to happen face-to-face and proving your identity was crucial to carrying out those sorts of transactions.

One great example of separation of identity and privacy is the new TSA Clear Card program.

The card is a credential that tells TSA staff the cardholder passed the TSA's security-threat assessment process and is authorized to use ClearLanes to bypass some aspects of airport security. The card does not reveal the cardholder's identity to TSA staff, effectively separating the person's identity from the physical credential.

Peterson goes on to talk about issues of privacy and the fact that there "is no policy framework for the collection, use, storage, and exchange of identity information." From a programmatic standpoint, this is where the Liberty Alliance Project is hoping to fill the gap. The Identity Governance Framework aims to do just that.