As a follow-up to a previous article on SAML, OpenID and OAuth, we are going to use this blog to review the options that different types of companies are taking to protect financial transactions, whether that takes the form of online payments, online banking or other types of activities.

How do banks approach authentication, authorization, identity and security?

Banks have traditionally done their own authentication and authorization, and for legal and liability reasons, they are unlikely to outsource this capability in the near- or medium-term.  This means that they may act as identity providers for others, but are unlikely to be the relying party within an authentication / identity system.

An example of banks acting as identity providers, in a federated environment, is SecureKey Concierge in Canada.  This is a credential broker service announced in November of 2012 that allows Canadians to use their MasterCard Choice Rewards or bank authentication credentials - BMO Financial Group, Scotiabank and TD Bank Group - to access online services from the Government of Canada.   

SecureKey Concierge authentication mechanism includes traditional login credentials (username and password) or, if offered by their bank, tapping of the bank's chip card on a SecureKey USB card reader, or possibly in the near future, on a SecureKey-enabled laptop or mobile device.  The service increases consumer convenience, while reducing government costs of managing passwords that were often forgotten due to lack of use (most of us access our bank online much more often than any kind of government services).

To comply with the privacy requirements of anonymity, unlinkability and unobservability dictated by the Privacy Act and the Personal Information Protection and Electronic Documents Act (PIPEDA), the systems trusted sign-in partners cannot know which government service is being accessed or for what purpose, and the government does not know which trusted sign-in partner is being used.

It is interesting to note, and certainly a testament to the company's strength, that in August of this year, SecureKey was also awarded a contract by the United States Postal Service® (USPS®) to provide the cloud-based authentication infrastructure for the new Federal Cloud Credential Exchange (FCCX). The FCCX service in the US, very much like SecureKey Concierge in Canada, is designed to enable individuals to securely access online services —such as health benefits, student loan information, and retirement benefit information—at multiple federal agencies without the need to use a different password or other digital identification for each service.

In the case of the Canadian government - although it is SecureKey Concierge that creates the government's required framework of reliability, security and privacy - it was decided to keep identity providers to major financial institutions.  This makes sense for several reasons:

To minimize operational disruptions, ensure longevity of credentials and reduce overall riskOnline banking penetration is among the highest in the world.  In fact, based on comScore data from 2010, at almost 65%, Canada had the highest online banking penetration in the worldThe five major Canadian banks cover the vast majority of Canadian consumers, meaning that working with a few providers can give a very good population coverage
In the case of the US, the National Strategy for Trusted Identities in Cyberspace (NSTIC), of which FCCS is a component, and the Credential and Access Management (ICAM) program have decided to allow a much larger range of identity providers, that include banks (Citi), security companies (Symantec, VeriSign and DigiCert), telcos (Verizon) and technology companies (Google and PayPal) among others.  

It is important to highlight that both systems being built - the one in the US and the one in Canada - support the privacy requirements of anonymity, unlinkability and unobservability.  This means that the FCCS service in the US, and the SecureKey Concierge in Canada, will limit the ability of credential / identity providers and the relying parties to track inidividuals' transactions.

Clearly the trust networks being built are only as safe and secure as the identity providers (IdP).  So how do these companies create a secure environment to enable this new ecosystem?  How do they protect their communication with the end-user and then with the relying party?  

In general, whether the identity provider is a trusted bank or a technology company, the processes are similar:

Communication with the end-user is done over HTTPS (an implementation of the Secure Socket Layer protocol), where the channel is encrypted and the servers identify each other via certs provided by world-wide recognized Certificate Authorities (such as VeriSign).

This is also how these companies protect their customers and users when they are logging in to the services they provide themselves, be it online banking, digital wallet or even e-mail.

Communication with the relying party can be done in a number of different ways, including three we have already discussed in some detail in a previous blog on this site - OpenID, OAuth and SAML.
It is very interesting to realize that, although the information being relayed from the user to the IdP may change - from the traditional username and password, to pins, knowledge-based information or even biometrics - the technology that protects that information, as critical as it may be, is the same that has been in place for a good number of years now.

Question:  Why aren't more banks taking part in overall authentication and identity efforts such as FIDO and NSTIC?