Category: user-centric

e-Voting and Identity

In my own city, Edmonton, they have been talking up e-voting for a while now.  There was an announcement yesterday that a pilot project is being conducted to validate the process of running an online election.  (More information can be found here and here.)

First of all, I think that this is exactly the type of pilot project that governments must run to be progressive and forward-thinking.  These types of initiatives are high value, not just to validate a solution for this defined need, but for the organization’s other online initiatives.  And the proposed e-voting identification process is an interesting one…

To be frank, I don’t have e-voting very high on my personal list of municipal problems to be solved, BUT I do have a keen interest in how people are identified online.

The City’s new project has an identity proofing process for this pilot project.  It includes a unique method of collecting identity proofing documents that I haven’t seen before: citizens scan (or take a picture of) their real-world identification, then upload it to the City’s website.  Allowed documents include drivers license, passport, Canadian military cards, etc. (see sidebar).

The image of the identification document is then reviewed manually by employees in the elections department and presumably compared to lists of eligible voters. Only when the document matches up with a previously registered voter will a credential be issued to the citizen for voting purposes.

This approach is convenient to citizens, or at least those that are savvy enough to scan a document and upload it to a website (which is probably a pretty high percentage of those that will consider online voting).

But whenever I see ‘convenience’ cited as a reason to do something online, I can’t help but look for the security and privacy compromises required to make that thing convenient.  On first review (I haven’t done a deep dive s feel free to correct me!) here are a few things that might be compromised by such a process:

  • How does the process ensure that the citizen is in control of the document at the time e-voting registration takes place?  For example, the passports for a household might be stored in a filing cabinet.  Let’s say one member of the household is politically active and the rest don’t vote at all.  How difficult would it be for the one family member to round up the passports and create multiple e-voting credentials?
  • There may be a privacy issue here.  Scanned identification documents contain a payload of sensitive information.  My passport has my legal name and birthdate — two attributes that are useful for the voter vetting process.  But it also contains my passport number, my place of birth and my citizenship.  None of these attributes are needed by this process, and should not be collected and stored as part of the process. (Update: The City’s 311 service has informed me that the data will be stored in Canada and destroyed no later than December 31, 2012. Also, only authorized personnel can view the data and they are subject to confidentiality agreements.)
  • Finally, how can one be sure that the scanned identity document has not been digitally tampered with? Paper and plastic documents have physical safeguards to increase reliability.  For example, the Alberta drivers license has a hologram on it and ‘declined width text wave’ feature (and these are just two of a dozen security features).  How do these features translate to the scanned image? Assuming many of these features do not translate well, how well does the scan of the document actually prove the citizen’s identity? As a comparison, would such a scan, subsequently printed, be acceptable as ID at the polling station?

It will be interesting to see how these and other challenges of e-voting will be overcome in the coming months.

Mike

Is PayPal the ‘killer app’ for Identity?

At great risk of dating myself, I was using PCs before the first killer app (Lotus 1-2-3) was launched in 1983.  This spreadsheet software was so useful to companies that PC sales skyrocketed and a revolution was started.  Killer apps have a way of shaking things up.

Email is often referred to as the killer app for the Internet, because it was the first widely used tool that required connected networks.  I was using email on internal networks prior to my first Internet mail account, but the real utility of Internet-based email launched me (and millions of others) into a habit that continues to hold.

A killer app for identity management has yet to emerge, but the folks and eBay and PayPal are looking to change that.  eBay’s foray into identity, PayPal Identity Services, hopes to solve the convenience, security and privacy problem associated with having dozens of online accounts.  Users register by providing information that can be can verified by a third party such as a bank. The service then issues an Azigo or Windows CardSpace information card for the user to use on subsequent transactions.

The PayPal Identity Services info card can then be used by the user to share information about themselves with e-commerce or e-government sites.  The idea is that the relying site does not need to collect a user profile — it can reliably collect the verified information directly from the supplied card. (Or, if it does need to create a profile, it could be automatically filled in, with the user’s permission, using data from the card.)

This type of service offers privacy protection, convenience and a more trusted transaction.  The identity management industry and its customers are eager to have these solutions available to support higher-value implementations.  Does eBay/PayPal have the marketing savvy and presence necessary to make this the identity killer app?

If it does gain ground, it would change the way organizations and companies offer enhanced services to their users.  The ability to rely on a quality credential from another party is a game-changer: higher levels of identity assurance, more simply achieved, will allow greater value transactions and more frequent online business to take place.

Mike

For more on information cards, please visit the Information Card Foundation.

Federation: SAML, Open ID and InfoCards

I came across a very succinct summary of these technologies and the scenarios they support over at Matthew Gardiner’s blog:

Information Cards provide a very elegant system for use cases which require and/or benefit from explicit user participation. With Microsoft’s impending release of supporting server side tooling, it will be an important force in Web identity management for many years to come. However, for applications for which explicit user participation is unnecessary or counter-productive – simple Internet SSO being the goal – SAML remains the best choice. OpenID’s focus remains on easing access to applications for which assuring true user identity is not really necessary.

Even better is the link to the IEEE Security and Privacy whitepaper The Venn of Identity.  Pretty much a must-read if you are interested in Federated Identity.

Mike

Identity Providers in Government

Most of my consulting projects are delivered in the public  sectors: higher education, central services, municipal and, a few years ago, in the health department. Until recently, my projects have involved implementing systems to deliver identity and access management — usually on a deadline, usually for a specific application or set of applications.

But I have also had the opportunity to work on more conceptual projects including defining an IdM strategy for a government department. Starting in the next few weeks, my team will begin architecting and designing federated and user-centric identity solutions.

The first thing we are working through are use cases that will help drive out solution designs.  We already know what the technologies are capable of and we have selected the products we need to conduct the proofs-of-concept.  But what are we going to do with this technology?

If we break down the emerging identity model into Identity Providers, Service Providers and Users, we can define actions in our use cases by these actors.  This post starts the discussion with what makes a good Identity Provider (IdP).  Specifically, the discussion is around the Citizen to Government context.

Who should act as an IdP? I believe that there are actually a limited number of government organizations that can fulfill this role.  While many government departments (and divisions and branches within those departments) might maintain citizen information, only a few actually maintain citizen registries.  And it is these registries — legislated databases of citizen information that are highly secured and carefully maintained — that are ideally suited to supporting an IdP implementation.

Why? Because citizen registries matter.  These databases are consistently used for identification to support both real-world and electronic transactions. A registry of citizens is used to support eligibility for health services in a province. A registry of drivers allows for issuance of drivers licenses and enforcement of road use laws. Student registries ensure that the right student gets credit for exam results, course marks and certifications.  The tax department keeps a reliable registry of citizen tax payers.

In my home province there are also registries for seniors, land titles, vital statistics, children/youth, and a perhaps few others — but that’s about it.  Federally we have citizen registries for taxation, family benefits, veterans, guns (well… the people that own them), and others.

The point to all this is that there are a finite number of authoritative sources of citizen identity information.  It therefore makes sense to leverage these databases for purposes of building reliable identity provider services.

I would even take it a step further — it makes very little sense to build a citizen IdP that is not built on a government registry. Why? Because the legislative authority to build a registry — and the effort to maintain it over time — are not trivial things. Therefore, government departments that contain registries take the job seriously. Registries are secured, monitored and carefully updated.  They often contain key identity attributes such as legal name, date of birth and residential address. Registries are subject to review by provincial and national privacy commissioners. Some registries contain some unique information as well, such as relationships: parent to student, husband to wife, driver to vehicle.

In the event of problems, bodies that manage registries have processes for citizens to correct information to contained in these databases. Most of us care very much if a registry does not have our correct information.  Errors can lead to late payments, loss of hard-earned certifications or denial of critical services.  For example, if the tax department mis-spells our name, it is difficult to cash our refund cheque and we’ll be certain to correct them at the first opportunity.

To further bring this point home, consider the municipal property tax role.  The city maintains this database and it is important to them that the rate payer be linked to correct property.  They want to know who to contact if taxes are in arrears or if a ticket needs to be issued for icy sidewalks.  But municipalities don’t deliver most of the type of life-sustaining or entitlement services that truly matter to us.  Cities and towns also don’t have a business need to record useful identity information like date of birth or gender.  If my city tax assessment arrived and my name was spelled incorrectly, I would probably ask that it be changed, but there would be limited consequences if I didn’t. For these reasons, the city’s tax role would make a poor choice as an IdP.

But a municipal government still needs to deliver services based on citizen entitlements, and identification can play an important role in electronic service delivery.  So if my city’s own databases are poor choices, where should they turn?  To a higher level of government, namely a provincial or federal IdP based on a robust registry.  By establishing an agreement with one or more registry-based IdPs, my city can focus on delivery services — acting as a Service Provider — and leave the more difficult identification and authentication of citizens to an IdP.

Finally, the idea of using registries is aligned with the Pan-Candian Identity Management and Authentication Framework.  While use of registries is not specifically prescribed, the concepts presented in the Identity Component — identity context, identity lifecyle, identity assurance levels and identity relationships — seem to map well when considering registries as ‘sources of truth’ for identity.

There will be a proliference of IdP services established over the next decade so the quality of identity proofing — especially for establishing credentials that are use in higher value transactions — is critical.  Establishing Identity Providers that are based on government registries will be key to the success of future identity management and electronic service delivery initiatives.

Mike

User-Centric IdM for the Public Sector

Moving forward, user-centric Identity Management is clearly an interesting alternative to centralized systems.  The promise of a solution where the user has choice over how and what identity information is shared with Service Providers is worth working towards.  It is not surprising that user-centricity is finding its way into pilots and initial implementations in the public sector.

It is becoming clear to me that user-centric IAM is a philosophy / model / strategy that is well-suited to government implementations because it has potential to return ownership of identity information to individuals, many of whom access multiple public services.

If they can avoid it, Canadian governments do not want to hold identity information outside their highly secured core registries.  These government departments recognize that our relatively tough privacy laws prohibit retention of information beyond what is needed to deliver a service.  Storing additional identity information, or unnecessarily storing the same information in more than one place, increases the risk of breaches and identity fraud.

Adopting user-centric strategies can reduce the volume of sensitive data to be managed, move privacy decisions closer to the user and make governments more compliant with their own legislation and policies.  Perhaps most importantly, as Dick Hardt’s Identity 2.0 presentation made it clear, user-centric IdM allows the creation of privacy- and user-driven solutions that mimic the real-world we live in.

This is possible because many systems do not necessarily require identification, but rather authorization.  Or if they do need identity information, they need it to support a transaction and have little need to store it after the transaction is completed.

Think about an e-commerce transaction using a credit card.  The system does not actually need to permanently store identity information. Rather, it needs to know that you have the funds to cover the transaction.  The key information is the card number.  Your name is only provided to support the transaction, i.e. to verify that the card being used can be matched to an accountable card holder.  If these authorization elements are present in the transaction (and not disputed later) then the business can be conducted.  The storing of the name information beyond a reasonable dispute period (say 45 days) is unwarranted.

When faced with breaches of identity information, goverments may soon find themselves needing to identify less.  It may seem counter-intuitive, but for certain low-value business transactions, a government organization may not actually want to know very much about those individuals, or at least they don’t want to have to store information about them in local databases.  What they do want is to ensure that these citizens are authorized to access the system and the information it contains.

An example of a provincial service that could likely dispense with traditional retention of identity information would be a system that issues a fishing license.  When issuing the license, it is important for the individual to properly identify themselves so that their name can be printed on the actual license document.  The license then authorizes the named individual to fish, so after the transaction it is important to have that identity information on the card to support an enforcement officer’s needs for proving ‘eligibility’.  While the issuing department may make a case for retaining the identity information in a license database, does it need to have its own Identity Provider service — chock full of duplicated identity information? Can it not simply trust one of several provincial or federal Identity Providers?

In time, this user-driven approach should result in fewer identity providers and many more relying service providers.  In a provincial government, there could conceiveably be three or four identity providers.  These could be linked to key registries such as HR (for internal users) or public education, health or motor vehicles (for citizens).  Add to this a federally provided IdP, perhaps based on tax records or a passport database, and citizens would have real variety in IdP services.

Moving to user-centric IdM with real choice in identity provider services can provide greater privacy protection and reduce the complexity of government electronic service delivery.

Mike

PS2009 — Epilogue

The 2009 Privacy and Security Conference is over for another year. As usual I was entreated to some interesting new ideas, issues and solutions.

But this year I’m conscious of the number of times that I left the session with a feeling that the speaker had been cut-off or missed delivering their conclusion. It wasn’t that the presenters were weak (they weren’t) but rather that many sessions ended with unanswered questions.  Such is the state of privacy and security in 2009 I suppose…

A random sampling includes:

  • How will IdM and access be effectively implemented in our hospitals and clinics? The physicians see authentication as an obstacle to delivering health services, yet health delivery organizations must have appropriate controls in place.  The CIO for Vancouver Island Health Authority had the problem well defined but didn’t give us insight as to what solutions she saw as promising.
  • When, if ever, will the US introduce effective Federal privacy legislation?  This conference has a fair number of US-based speakers and each one tells an American story prefaced by ‘up here in Canada, this is less a concern because of your privacy laws’.
  • Can government ever leverage Cloud Computing, or will data control always limit its ability to leverage the Cloud?  Nicholas Carr didn’t answer this question for us, and — given this was a public sector conference — I think most of us are skeptical that the Cloud will ever meet government needs.
  • What is the ‘killer use case’ for user-centric IdM?  Stefan Brands was technically very good in his presentation, but too often user-centric IdM is focused on the model and technology.  We get the technology now — but what are we going to use it for beyond low-value SSO?  (This topic is certainly fodder for future posts on this blog.)

Despite these loose-ends, I enjoyed this conference again this year — it was good to meet new people, kibitz with a few clients and enjoy the spring-like maritime weather.  I’m sure to be back in 2010.

Mike

PS2009 — Stefan Brands, Microsoft

Feb 3rd, 3:10pm

Dr. Stefan Brands was in town this week so even though he wasn’t on the original program, the organizers decided to add Microsoft’s newest addition to the conference.  Brands is now an Principal Architect in the Identity and Security Division.  

The first part of the presentation was standard Identity 2.0 stuff. A User accesses a Service Provider (SP), who in turn asks for one or more claims. User then authenticates to an Identity Provider (IdP) to get required claims.  Claims are passed by user to Service Provider.  Access granted.  

Mr. Brands explained how Geneva — a major new release of Microsoft Active Directory Federation Services — fits into each part of the user-centric model:

  • Used by the IdP, Geneva Server will provide claims (including SAML 2.0);
  • CardSpace Geneva will provide user control over distribution of claims by offering an active client; and
  • Geneva Framework will provide tools to applications to accept and process claims.

The interesting part of the presentation was the discussion how U-Prove technology (from Credentica, Brands’ old company) is being incorporated into Geneva to allow for more refined handling of claims by CardSpace users.  As examples:

  • Users can selectively disclose some claims, but not all, to an SP.  If a CardSpace card had six attributes, but the user only needed one to access the services, the user could mask the other five claims.
  • Users can strip down the claims to bare minimum to maximize privacy protection.  For example, if an SP only needed to know that the user was a resident of Quebec, it only would need the first letter of the postal code — “H”.  The user could hide the remaining five characters in the postal code string and only supply the first one to prove residency.

Interesting stuff.

In response to a question, Mr. Brands differentiated federated identity from user-centric by saying that only user-centric identity management is suitable to the large-scale, citizen-oriented systems that government need to deploy. In his view, federation is best suited to enterprise applications and services that are shared between business partners.

Mike

User-Centric IdM

I’ve been working on an Identity Management (IdM) strategy for a client over the past few months.  They have been investing in IdM solutions to meet their needs for several years, so it was becoming important for them to look at the bigger, long-term picture.

A key recommendation in the strategy is to establish user-centric IdM in this organization.  This is based on emerging research that shows users desire more control over identity information, even if that control amounts to simply viewing the information the IdM system possesses.

As I’ve commented on this blog a few times, this emerging user trend is being talked about regularly in industry circles, by select academics and by identity management ‘thought leaders’.  User-centred, or user-centric, IdM can provide practical approaches to meet the increased needs of individuals who wish to better manage their own identity information.

What is less reported and commented on is that user-centric IdM is not a technology, but rather a model or philosophy that is primairly concerned with putting user needs first in IdM solution design.  To be successful, designers of user-centric solutions have to consider the user identity’s full life-cycle and be ‘in tune’ with their needs for privacy and control.  Two noted examples illustrate this point.

Three years ago Kim Cameron came to my city to talk about information cards.  This was a completely new paradigm for those of us that had been designing and building centralized IdM systems.  Mr. Cameron’s use case that day was the payment of an online purchase.  He showed how a user with a Visa account could use an information card to present a cliam to an e-commerce site.  The claim didn’t have to provide any details about the user — simply that the user had been authenticated and that they, Visa, would honour the payment.  All the e-commerce site had to do was present this claim to Visa in order to receive payment.  The user in this scenario did not have to supply personal information to the web site in order for the payment to be processed (of course, a name and address would need to be provided to the shipping department, but that was outside the actual financial transaction).

Around the same time, Dick Hardt was wowing them at the O’Reilly OSCON conference with his Identity 2.0 presentation.  His use case was that of how he, a responsible adult, might purchase a quality vodka product from the local liquor outlet.  The main point was this: in real life we present credentials of our choosing to clerks in order to prove an aspect of our identity, such as our current age.  Liquor store clerks don’t need to record our name and address in order to conduct the transaction — they simply need to verify that the birthdate works out to the correct minimum age for the purchase and, in effect, discard the information after the transaction is completed.  Mr. Hardt goes on to say that there are technology solutons that can virtualize this approach, hence user-centric and privacy-smart identity solutions can emerge.

In both these cases, the needs of the individuals are considered first.  Mr. Cameron could easily have stuffed the vitual credit card with user information, and made the case that the e-commerce site would highly value that information (think Facebook).  Similarly, Mr. Hardt’s example focused on the only reason the individual would want to present identity information: to confirm one aspect of their, that being their age.  Both of these are in tune with the demands of privacy-aware citizen and are excellent examples of user-centric philosophy.

Centralized systems, like the Canadian government’s ePass, scale to millions of users and are well understood by users and designers alike.  But these legacy systems are fraught with challenges related to security, lack of privacy controls and, potentially, accusations of ‘big brother’.  In no way are these system user-centric — they simply were built in a time when user ‘control over identity’ needs were not a priority.

For organizations like large companies and governments, these systems do a disservice because they ultimately will discourage privacy-aware individuals from using the very online services the IdM system is intending to enable.  Only by adopting user-centric philosophies in solution design can IdM systems meet the changing needs of individuals in an increasingly privacy-aware world.

Mike