Category: trust

Should government sites use social media login?

I’ve been thinking about how the public sector model for identity has changed in recent years from one where the government body controls the credential AND acts as an identity provider, to one where the credential management is delegated to a service provider. Social media login and, at the premium end, SecureKey’s briidge.net are examples of this model.

Social media credentials from Twitter, Facebook and Google are used everyday by millions of Canadians.  Why not leverage these existing accounts to access government services?

The problem I have when talking to clients about these solutions is the assumption that any credential service provider (CSP) will do.  That is, a public organization can (and should) readily accept any common credential, add a layer of identity proofing, create a link back to the credential (for future access) and start counting the costs saved. After all, it is all about citizen choice isn’t it?

This isn’t as simple issue.  There are some fundamental problems with using low-end credentials, such as social media logins, that need to be carefully considered when delegating authentication to a third party:

  • Operational Disruptions — There was a great post from the Basecamp blog a few years ago (since deleted) that described how difficult it was to maintain the link between a credential provider and the site. This post talked specifically to OpenID and how changes to the credential may not be properly shared with relying parties, resulting in support calls and manual fixes. Users would also forget which OpenID account they used, and Basecamp had no automated way to reconnect them.  In the end, disruptions were common for OpenID users, support costs spiked, and Basecamp discontinued its use.
  • Longevity — Which social media credential providers are going to be around for the long run? What consolidations of login services or outright mergers are coming? How might the protocols for social media login change? For a public-sector service wanting to provide stable, long-term services, picking the right credential service providers is extremely difficult.
  • Wrong Message — Social media companies (Google, Facebook, even LinkedIn) often misbehave when it comes to privacy. They routinely run afoul of privacy commissioners and even irritate their user bases when ever-invasive features are introduced.  Given the poor privacy records, should a  public-sector website be encouraging the use of social media login to access government services? What are the downstream risks?
  • Convenience — Social media login can certainly save time when it comes to authentication. I use my Twitter account to access Level 1 (low value) services frequently. I’ll admit it is convenient and I like that blogs, news websites and the like offer this option. But convenience is far less important to me when accessing my personal information on a government website. First of all, security and privacy protection matter a lot more. Further, I don’t access these sites all that often so if I have to login (or request an automated password reset) it isn’t that big of a deal to me. What would be more useful would be a common credential for all of a particular government’s services, so that I can experience single sign-on.

So what are the benefits of leveraging a social media credential for government websites? Well, for those more trusting than me, convenience and the benefit of having fewer passwords to remember is a definite plus. And cost savings can be significant for large websites, although keep in mind that a full IAM stack is still required — the public sector website will still need to provide their own login service as not all citizens will trust an alternate credential.

Ultimately, social media login for services won’t meet government privacy and security requirements for access to sensitive information. Existing in-house systems and credential solutions (like SecureKey) that specifically address the trust issue will likely prevail.

Mike

Service Canada and SecureKey Concierge

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

Facebook’s latest privacy troubles

After years of controversy, Facebook may well end up in a Canadian Federal court this fall.

In August last year, Canada’s privacy watchdog, Jennifer Stoddart, announced that Facebook had agreed to improve its privacy protocols to be compliant with the Personal Information Protection and Electronic Documents Act (PIPEDA).

But instead of working to address the concerns, last December Facebook implemented changes that effectively further reduced user privacy.  These changes effectively required users to manually modify settings to avoid friends, personal information and photos from being shared.  According to the Wikipedia entry Critcism of Facebook:

… a user whose “Family and Relationships” information was set to be viewable by “Friends Only” would default to being viewable by “Everyone” (publicly viewable). That is, information such as the gender of partner you are interested in, relationship status, and family relations became viewable to those even without a Facebook account.

Facebook clearly have decided that the increased revenue possible from sharing personal information is worth battling government privacy commissioners and lawyers.  And that’s fine — so long as our government continues to enforce our laws and bring violators to account, we can play that game too.

I’ve never had a Facebook account.  I can be patient.

But those that still trust Facebook with personal information — and haven’t bothered to examine the minutia of the site’s privacy settings — will continue to have their personal information shared with 400 million users and thousands of advertisers, data aggregators and, well, pretty much anyone else on the Internet.  At least until the wheels of justice grind to conclusion…

Mike

Cloud Computing: Schneier and Ranum weigh in

Unless you’ve been living in a cave over the past six months, you are probably aware that Cloud Computing is Next Big Thing.  Of course, it isn’t new or unique — it is a form of centralized computing and application delivery has existed since the first time-sharing systems emerged in the 60s.

But the big vendors need a story to push their products and services, and Cloud Computing is it for 2009. It isn’t suprising that the information security and privacy protection aspects of cloud computing are starting to get a lot of attention as well.

What are the risks? How secure is my data in the Cloud? What privacy protections can I rely on? Do you really trust your service provider?

Bruce Schneier and Marcus Ranum have a video from their Face-Off series that is well worth viewing for anyone looking to take advantage of Cloud Computing services.

I like Ranum’s emphasis on limited data access and lack of portability. Locking clients into a hosted application and database is going to be a problem when the client wants to use another provider. Just how do you move five years of email from Gmail to your own mail server? Can you quickly extract and replatform your critical sales data from Salesforce.com if Salesforce gets bought out by one of your competitors?

Mike

Identity Assurance — Trust Levels

3rd in a series [ <- previous ] [ <- first ]

The second part of the Assurance Component of the Pan-Canadian Assurance Model to discuss are Transaction Assurance Levels, or more simply, Trust Levels.

Trust Levels are defined in the pan-Canadian IdM&A Framework as ‘a pre-established statement of the level of certainty that is needed to access information or conduct a transaction.’  They are directly linked to the Information Classification.

The model establishes four trust levels:

1. No Trust — Anonymous Transaction.  Used with information that is unclassified (e.g. published information).

2. Low Trust — Routine Transaction.  Used for protection of systems containing basic information, i.e. information with a Security Classification of Low.

3. Medium Trust — Verified Transaction.  Used with systems that need to protect confidential data, such as some medical records, tax information, identity information, etc.

4. High Trust — Corroborated Transaction.  The highest level of trust; required for protecting information classified as High (e.g. cabinet documents, criminal trial information, etc.)

It is important to note that the ‘transaction’ referred to in this discussion is the business transaction that will be supported by the identity and access management system.  For example, medium trust is needed by business transactions that needs to be verified (due to the sensitivity of the information being protected).

In Practice:

Trust Levels allow for a clear description of what we need to establish before we allow access to an application or information set.  On the surface, the Trust Levels differ little from the Security Classifications, but the exercise in assessing trust and assigning a Trust Level is important.  It forces the business to ask some key questions: How much do I need to do before allowing access to this information?  Have I classified the information correctly and is it reflected the Trust Level?

As can be seen from these questions, the word ‘trust’ forces the business to look at the Security Classifications in a somewhat different light.  That allows for better conversations around what the value of the information is and what an appropriate access solution might look like.

Next: Registration Process.