Pan-Canadian Identity Assurance Model

September 17, 2013

In October 2008, I wrote a five part review of identity assurance, based on the framework contained in the Pan-Canadian Strategy for Identity Management and Authentication.  At the time these blog posts were the only Canadian resource available for analyzing and planning identity assurance.

Since then a number of changes have occurred that have prompted me to update these posts.  For example, an Assurance, Identity and Trust Working Group was established by the national Identity Management Steering Committee.  This team prepared a report, the Pan-Canadian Assurance Model, that provides more guidance and detail than the original framework.

Having said this, the goal of the model remains unchanged; it strives to standardize identity assurance to allow for provincial and federal systems to interoperate.  It is foundational to the broader Pan-Canadian framework, and is key to implementing citizen services across the country.

The identity assurance model is primarily concerned with establishing agreed-to levels of assurance and defining the concepts and terms each party need to understand.  It has an emphasis on federation and looks to support risk management activities within partnering organizations.

The Pan-Canadian identity assurance model is represented as follows (click/tap to enlarge):

identity_assurance_standard

While this model is an important input into this blog post series, it needs to be supplemented by real-world experience.  For each topic in the series, I will inject examples from my experience implementing IAM solutions over the past ten years, and provide insight into the opportunities and challenges offered by the model.

First in the series, click here for the post on Information Classification.

Mike


SecureKey — The Interview

September 24, 2012

Andre Boysen is an Executive Vice President at SecureKey Technologies Inc., the Toronto-based technology company that is working with Canadian governments and business on next-generation identity management solutions.  With the backing of Intel, Telus and Visa (among others) SecureKey looks to make a big splash in the world of secure payments and online identity.

SecureKey Concierge is a credential broker solution that allows government web sites to use banking credentials.  With SecureKey Concierge, government sites can take advantage of existing banking credentials in a secure and privacy-protected way.

I had the chance to interview Andre last week.

Code Technology: Tell us a bit about what SecureKey Technologies is all about.

Andre Boysen: SecureKey is in the business of making online authentication easier, that’s basically what we are trying to do.  We got started helping banks to solve ‘card not present problems’ — this type of fraud went to zero with the introduction of chip cards and PINs.  But it still is an problem on the Internet – anyone finds your credit card number and billing address basically they can start ordering stuff.  It’s hard for the banks to figure out who’s real and who’s not.

We noticed that banks were moving to contact-less chips (based on near-field communications or NFC) in order to speed up things.  With NFC for quick purchases like papers and coffee, the customer just has to tap the card, no need to enter a PIN.

We saw the opportunity to use this technology to do payments on the Internet.  We have built an NFC reader and the concept is that you can have this reader on your computer, at home, and when you want to buy something on the Internet, instead of typing in a card number you just tap your card on the reader and pay that way.

One of our strategies is to get our technology embedded into all consumer electronics.  Intel is a significant investor in SecureKey and all the Ultrabooks coming out actually have our NFC reader built in.  And we are working to get it embedded in cell phones.

Code: So how does this technology lend itself to the direction you have taken with SecureKey Concierge?

Andre: So, yes, that’s a good question… Part of this is that we noticed that we are all drowning in user IDs and passwords.  And the problem for governments is that they know who I am on paper but they don’t know me in person, and when I show up on the Internet they have a hard time knowing it’s me.  The solution in the past is for the government to roll out their own credential — the current incarnation is called Access Key.  But (for higher-value transactions) that includes installing software on my computer and with all the support costs related to this, the government realized that serving me online is much more expensive that serving me in person…

The federal government’s idea was to delegate authentication.  An RFP was issued looking for proposals with 10,000,000 subscribers and at least three credential service providers.  SecureKey, partnering with three of the largest Canadian banks, was the only respondent.

Code: Why are the banks interested in this?

Andre: Their primary motivator is that they want to see identity move online. Banks want customer identities, today largely based on the provincial drivers license, to be verifiable.  With SecureKey’s model four key players will participate: federal government, provincial government, banks and telcos.  These four players have a critical role in the consumer’s life.  The federal government can set standards and leverage its buying power in a way that individual provinces can’t.  The provinces are the source of identity — birth certificates and the licenses we carry around in our wallets.  But the problem is that we don’t deal with the province very often; it’s rare that we have to talk with them and this makes it hard to authenticate online.

This is where the banks come in.  They have a very tight relationship with 98% of Canadians — they see their customers often and know them well.  By participating in SecureKey, the banks will get better digital identities, which will help them when accounts are opened.

To take this further, BC is launching new services card and drivers license with an NFC chip inside.  This is compatible with SecureKey technology and will make it easier to conduct secure transactions related to provincial programs.

What the telcos bring to this is something that Canadians always have in their pockets — their phones.  We are working to get phones and carrier networks working with the system as well.

Code: What is the typical use case SKC is looking to solve?

Andre: Any Canadian who wants quick and convenient access to any federal government service can use their bank account to gain that access.

Code: Can you confirm for us the high-level architecture? Is it primarily an identity broker service that sits between the IdP and relying party?

Andre: No, it is better described as a ‘credential’ broker service because there is no identity information passed. The government never gets the unique MBUN  (meaningless but unique number), only a service-specific number.  There is no information about the user passed to the government other than they are an authenticated bank user.  The government does its own enrolment and identity verification.

Code: Is SecureKey Concierge based on SAML?

Andre: The service is based on SAML 2.o and has support for older versions of SAML and Shibboleth.  OAuth and WS-Trust are planned.

Code: How can the service support an investigation?

Andre: It is important to point out that SKC has a privacy-enhanced design — triple blind.  No one participant has a complete picture of the transaction.

Each bank produces an anonymous MBUN for each customer. The banks will pass the MBUN to SKC during authentication. Our service will log any transactions completed in the session against the MBUN.  To preserve anonymity between services SKC will further anonymize the MBUN for each relying party service and SKC will pass a unique number called the Persistent Anonymous Identifier to each RP.

Event tracking is supported.  So let’s say CRA comes to us and says we have an event here and we need to do an investigation.  Keep in mind that the ‘handle’ we give to the RP is the Persistent Anonymous Identifier (PAI).  CRA can provide us with this number and we can provide the event logs that relate to that PAI.  If this isn’t sufficient, we can use the MBUN to go to the banks and get the details of the authentication event from them. Of course, it depends on how serious the issue is — if it is a judicial enquiry there will be more disclosure, but for other investigations we will keep the ‘privacy veil’ on.

For a compromised account, the bank is going to shut it down and the government won’t see that account again.  It is worth noting that banks have pretty sophisticated systems for detecting problems, so breaches are pretty rare events.

Code: Can you share with us the attributes that are passed between the bank and the government site? From my recent use of the service, I couldn’t tell if the bank asserted my name information.

Andre: Only PAI is passed. Name info is not passed. Note that each service (relying party) does own enrolment and may collect name.

We are all about consumer convenience, choice and privacy control. This service is very user-centric. Users are presented options to approve any information via on-screen prompts.  To facilitate this, SecureKey Concierge will have a set of templates to allow RPs to collect pre-determined ‘bundles’ of information.  The RP will use these templates to collect all the info consistently from a provincial card or bank record.

This broker concept becomes even more important as we move into sharing identity attributes.  We want to make sure we continue to support minimal disclosure.

Code: I’ve worked on citizen identity for a while now, and there is always the challenge of keeping up with their preferences and ‘life-changes’.  How does the SKC service manage changes to the citizen’s banking credentials? Let’s say I decide to switch banks, but want to keep my access to the Service Canada site in place. Is this possible?

Andre: Yes, a bank account change can be made via a the ‘Switch My Sign-In Partner’.  The process requires that you have control of both bank accounts in order to make the switch.

Code: The SecureKey Concierge two-factor solution looks to be a bit of a game changer for high-value and/or high-risk transactions.  Where do you see this technology being adopted in the online government-to-citizen space?

Andre: Enterprise authentication is something we can do. SecureKey is trying to make it easier for employees using their access badges. We see healthcare and government and finance are three verticals we are targeting, all with needs for strong authentication.

Code: How are things going? Has interest in SecureKey Concierge started to pick up? Have you seen interest in the service outside of the federal government, BC and Alberta?

Andre: We launched with the government of Canada in April, and have 15 agencies/departments online today.  Two bigger departments, HRDC and CRA, are set to launch this fall.  We expect that by the end of 2012 we’ll have the bulk of Canadian departments online with SecureKey Concierge.

As for other interest — there is nothing we can share just yet! But ‘wrapping up Canada’ (all remaining provinces) is the current goal.  We also want more credential service providers including partners from outside of the banking sector.

Code: Thanks for your time today Andre.

Andre: You’re welcome!


Service Canada and SecureKey Concierge

September 19, 2012

Service Canada now uses the SecureKey Concierge identity broker service.  This new service allows Canadians to access services using their online banking credentials.  This may be the first federated identity implementation in Canada targeted at citizens.  Until now, Fed ID implementations have been limited to higher education and industry federations.

Here is a screen-by-screen walk-through of how Service Canada’s site can be accessed using SecureKey Concierge and a citizen’s bank account.  (Please excuse the image sizes [click to enlarge].)

1. First, from the ‘Access My Service Canada Account’ page, the link to SecureKey Concierge (SKC) is easy to locate near the bottom of the page:

Note that the government has kept their own Access Key as a login option.

2. Clicking on the SKC login brings up the SKC discovery service.  It is here where you select your preferred identity provider from a list of bank services:

3. Select your bank from the list.  The service then redirects to a customized bank login page (Scotiabank in my case).  Note that this page is different than the bank’s regular online login page – the look, content and URL are different.
4. Note that the SKC logo is carried through to this page.  Once I login — and yes, this is the exact same credential as I use with Scotiabank — I was sent to the SKC terms and privacy notice:

5. The terms and conditions can be found here.  When you ‘Accept and Continue’ you are returned to a Service Canada page:

6. This page confirms which credential the user is to use, and offers to convert an Access Key credential to the SKC credential.  Next:

7. Now, Service Canada lets you know what is upcoming, and informs you of various privacy and service terms.  Once you get past this page, you arrive at their enrolment/registration form: 

This is where Service Canada enrols you into their service by asking for selected shared secrets: SIN, DoB, an access code and your province of residence.  Note that your name is not passed in from SKC, and it appears that your name is not needed on this screen to confirm your identity.

(Also note the use of the term ‘authentication’.  I’d prefer they use ‘enrolment’ but I suppose for users of this service it doesn’t really matter all that much…)

8. Finally, upon successfully entering this information you are rewarded with a lengthy privacy notice and terms page:

9. Accepting terms here results in the main Service Canada service page being displayed (with links to your personal information):

In summary:

  • Service Canada provides an SKC login option.
  • SKC allows the user to select their bank login from a discovery service (page with list of partnering banks).
  • The bank login page is a modified version of what the user is familiar with. The user logs in using their regular online banking credential.
  • SKC’s terms are displayed and agreed to by the user.
  • Service Canada then takes over and walks the user through service-specific enrolment pages.
  • The user accesses the service.

Time for me to complete: 5 mins, 18 seconds.

Once enrolled using the above steps, returning to the service is simpler because the link between your bank credential and the service is maintained.  This link is anonymized so that the bank is not aware of what service you accessed, and Service Canada doesn’t know what bank credential you used.

When returning to the service page, select the SKC login option.  Select your bank and login.  You then get access to the service without being prompted for enrolment information.

Aside from the technology and user experience, there is a lot going on here.  Join the discussion at LinkedIn – Canadiam.

  Updated: Click here for the SecureKey interview…

Mike


Assessing IAM

June 8, 2011

My experience with formal technology planning spans over 20 years.  As an external consultant, I have the advantage of being objective, and can offer fresh insights as inputs to planning and strategy development. However, as an outsider, coming into an organization to perform planning can be difficult because I often lack an understanding of the infrastructure, software and procedures in place.

As a result, the planning methodologies I have used have always included an assessment phase — a set of tasks in the project that is primarily concerned with collecting information about the environment.  This has worked well when doing large project planning, IT strategy work and program development.

Assessments are also a vital part of Code Technology’s work in identity management.  An IAM Assessment can be delivered on its own, or as part of an identity strategy project.  The approach we have formulated for IAM Assessments is a little different than the generic IT information gathering.  Identity management assessments need to be structured to address key components that impact IAM design and delivery.

If you’ve followed this blog for any length of time, you’ll know that I regularly reference the Pan-Canadian Identity Management and Authentication (IdM&A) Framework.  This framework has provided an excellent structure for assessment and strategy development work.

My approach, then, is to leverage the framework in the development of an IAM assessment.  Without the structure and completeness of this framework it would be difficult to ensure everything was covered.

The heart of the assessment is information gathering: infrastructure, applications, identity stores, policies, processes, etc.  Analysis of the environment is then performed using  the seven Pan-Canadian IdM&A components:

  • Legal –Under what legal agreements and legislation does the organization operate?
  • Privacy – How well does the environment match to privacy obligations?
  • Security – Does the current environment meet or exceed information security standards?
  • Trust – What trust arrangements (if any) exist between federated organizations?
  • Assurance – What processes and technology exist to ensure information assets are protected to the appropriate level of assurance?
  • Identity – How are identities organized and managed?  What identity attributes are stored and utilized?
  • Service Management – How robust and flexible is the current environment?  How will it need to be supported?
An assessment is more than just information gathering — the analysis can help to immediately highlight strengths and weaknesses in the environment.  Follow on work can use this documented ‘snap shot’ of the identity management environment to plan and design improvements and new solutions.
Mike
Code Technology is now offering its standardized IAM assessment service across Canada.  Please contact us at info [at] codetechnology.ca for more information.

A Vision for identity management in Canada

September 13, 2009
The overarching vision of the Task Force has been a Pan-Canadian IdM&A Framework that
supports access by citizens and businesses to a seamless, cross-jurisdictional, user-centric,
multi-channel service delivery experience when interacting with government.

IAM strategy consulting

Most of my consulting work consists of advisory, planning and delivery services in identity management.  So it is no surprise that one of my interests is in seeing how the Pan-Canadian Identity Management & Authentication Strategy can be applied to a variety of IdM projects.  This strategy holds promise for the future development of a national identity framework, one that can cross government jurisdictions and programs.

The Task Force that developed the strategy established a clear vision:

The overarching vision of the Task Force has been a Pan-Canadian IdM&A Framework that supports access by citizens and businesses to a seamless, cross-jurisdictional, user-centric, multi-channel service delivery experience when interacting with government.

For those of us (all of us?) that have had dealings with federal, provincial and municipal governments, this is clearly an ambitious vision. It is fair to say that even working within a single government department today — let alone across jurisdictions — is not seamless and rarely is it multi-channel.  When working between different government departments we encounter a patch-work of online, phone and in-person services that require us to present identification at each step and in inconsistent ways.  Improvements in these areas are clearly in our best interest as citizens and tax payers.

The Pan-Canadian vision promotes standards collaboration.  There must be a basis for establishing ‘trusted, collaborative relationships across jurisdictions’, and only through agreed-to standards can we make this goal a reality. This is particularly true in the high-value online service delivery channel.  Identities for use with applications that require high levels of identity assurance must be well supported by issued organizations to be effective in a cross-jurisdictional use case.

The vision also recognizes the importance of leveraging existing IdM infrastructures — clearly many jurisdictions (and departments within) have IdM services in place that can be adapted and leveraged.  The Pan-Canadian vision does not compel organizations to discard functioning systems, and this shows up in one of the service delivery design principles:

The ability to leverage existing infrastructure and the increased interoperability of systems.

So how does such a vision get realized?  How does a country that is famous for regionalism and inter-jurisdictional disputes move towards a unified and collaborative model?

  • First, governments can improve the chances of realizing this vision by making identity management a priority. In a country as prosperous as ours, the issue is rarely funding but rather one of priority. Establishing that e-government and e-business need IdM to fuel economic and social development in Canada is key to moving forward.
  • Second, the momentum that we are now seeing in implementing the Pan-Canadian strategy needs to be maintained. In-flight projects need to be completed, new ones identified and communications between all parties increased.  Flexibility in the establishment of standards — recognizing differences and allowing for variances — is necessary if all parties are going to participate fully.
  • Finally, the standards that emerge from the project work need to be quickly codified and become mandatory for inter-jurisdictional transactions. I realize that ‘quickly’ is a relative term, but we can’t be talking about standards development five years from now — we need the basic standards and protocols established in the next 12 months if we are going to catch up to what the rest of the world is doing.

A vision of a seamless, cross-jurisdictional, user-centric, multi-channel service delivery experience is very much in the ‘go big or go home’ category — and now that governments are starting to become engaged in the execution of the Pan-Canadian strategy, it will be interesting to see how the resulting solutions match up to this ambitious vision.

Mike

(An article that I wrote last year on the Pan-Canadian Identity Assurance model can be found here.)


Identity Assurance — Putting it Together

February 14, 2009

Last in a series [ <- previous ] [ <– first ]

When I reviewed the Pan-Canadian Identity Management & Authentication Strategy in 2008, my first interest was to understand what it could mean to my client’s identity management projects.  In the area of Identity Assurance I was, frankly, hoping that this new framework would not stray too far from the baseline standards and methods I had been using since 2003.

It turns out that the Pan-Canadian Assurance component was fairly close to the approaches I was already using. Where it differs is primarily in terminology or in the way the classifications for information, registration processes, credential strength and overall assurance have been organized.  Another difference is in the ‘stitching together’ of all components that make up Identity Assurance.

To put this to use on your projects, you need to first establish organizational standards that are aligned with the Pan-Canadian Assurance component:

  • Create a set of four information classifications — and provide examples of your own information when you draft this standard.  These map to your requirements for Identity Assurance Levels.
  • Document standards for registration processes that map to the Assurance Levels.  These don’t have to be detailed use cases, but rather descriptions of minimum process sets that are needed at each level.
  • Select different levels for credential strength by combining passwords, ‘secrets’, issued authenticators, and — if it is applicable to your business applications — biometrics.  Keep in mind that the quality of the operational infrastructure needs to be consistent with the authentication events you plan to support.

Once these standards are in place your system design can be formally supported.  The process that each project will need to follow is summarized as follows:

  1. Classify the information that will be accessed — this becomes the Security Classification of Information.
  2. State the Identity Assurance Level required (it is the same as the Security Classification).
  3. Determine which Registration Process will be required to match the Level of Assurance.
  4. Select a Credential Strength at the same level.  This is a critical decision — it needs to be strong enough while still being affordable and sufficiently convenient to use.
  5. Review the design: analyze the levels assigned in each category and document.

One final comment: the Pan-Canadian Strategy defines a framework, not a set of fixed rules.  Adapt the models and components described in the strategy to suit your business needs.  Provided you don’t stray too far from the intent of the framework, your systems will still be able to interoperate with others that based on the framework.

Mike

Tired of reading? Check out the 72 Things I’ve Learned About IAM

For more information on designing identity assurance systems and processes, please contact Code Technology at info@codetechnology.ca or 780.990.7742.


Identity Assurance — Credential Strength

January 28, 2009

5th in a series [ <- previous ] [ <– first ]

It’s obvious that stronger credentials allow for access to more sensitive information.  And the Pan-Canadian model emphasizes that the identity-proofing portion of the Registration Processes must be equally strong to ensure that credentials are issued (and subsequently used) by the right person.

The Credential Strength in the model is a combination of the number of factors and the strength of each individual factor.  Three factors are described: something you know, something you have and something you are. These are consistent with industry standard definitions.

With respect to multiple factors, the model makes a good point: multi-factor authentication is not always stronger that single-factor.  Two weak factors (e.g. PIN and PC geolocation) may not be as useful as a single factor that is very strong (e.g. certain biometrics).

A factor’s strength needs to be assessed based on:

  • its fixity to a person, unique factors that can only be attributed to a single individual (think biometric)
  • its distinctiveness, unique attributes that by definition are distinct (think government identifiers)
  • its permanence, the degree to which a factor is permanently linked to the individual (think life history ‘secrets’)

Here is a good  quote from the strategy: “Selection of the authentication factors to be applied to a credential depends on the level of assurance required for a given transaction.” In other words, if you are protecting an asset and it requires High identity assurance, you almost certainly will need multiple factors to achieve High credential strength.

One last point: the Operational Diligence of the IAM environment (bottom row in model) comes into play here. The model defines this as the privacy, security, audit, compliance and other processes that ensure the integrity of the overall system. Environments that lack appropriate rigour cannot be used to deliver higher-value services.  In other words, if your IT shop has a weak record for availability, or has failed multiple security audits, you may need to improve the operations before implementing IAM above Level 2.

In Practice

There is a good table on page 110 of the strategy, adapted from the Identity, Authentication & Authorization Working Group (IAAWG) Guidelines, that identifies different types of credentials and their relative strength.  This table can be used to support decisions around what type of credential should be used for low, medium and high

Examples include:

  • Password or PIN — Low strength.
  • User ID and Strong Password — also Low strength.  This is because both factors are ‘something you know’ and therefore this combination is still single-factor authentication.
  • Strong Password and SMS Text PIN — Medium strength, due to two different factors being used.
  • Password and Biometric — High strength, one weak and one (potentially) very strong factor combined provide the overall strength.
  • Password, Biometric with PKI Certificate and Hardware Token — Very High strength; it would be hard to dispute the identity of the individual presenting this combination…

I’ve done some similar mapping of authentication schemes and come up with similar results.  Putting this sort of table together for your organization is necessary if you are to consistently and accurately determine credential strength for your IdM initiatives.

An important thing to repeat is that the credential strength needs to be consistent with your registration and identity proofing processes.  If these are aligned then you can, for example, allow access to an application with a High information security classification using a High strength credential.

Next: Putting it Together.