The authentication model for the Internet is changing. We have hit an inflection point and are moving from application-centric authentication to user-centric authentication. But what does that mean?
The current model for user enrollment in an Internet service is app-centric. Every application creates a database of user accounts – users and their associated privileges. Users assert their authority to control their accounts and exercise their privileges by providing the application with a user ID and a password, or credential. (A bankcard plus PIN is also a credential.) The credential is provisioned to the user when the user enrolls in the Internet service.
The problem with the app-centric model is the cognitive load it puts on users. Two issues make life difficult for users in this model. First, the volume of user applications is high and growing, so users have long lists of passwords to manage. This leads to the second user issue: a security conflict. Users cope with large volumes of user IDs and passwords by making their passwords as short as possible, using the same password on multiple sites, and storing their passwords in a “safe” place, such as a spreadsheet on a smartphone. This user coping mechanism clashes with and flies in the face of application security – users are diluting the policies that are designed to protect them and keep their data safe. Users are not doing this out of spite – it is simply the only way they can cope. And so the authentication model must change.
The Internet is moving to a user-centric model. User-centric means that users bring their own credentials (BYOC) from a trusted provider whose assurance level matches the assurance requirements of the app the user wishes to access. Assurance refers to how much rigour is applied in the issuance (identity-proofing), the management of credentials, and the strength of the authentication used. For example, the low level of assurance for a Facebook credential means it is not well suited to help change the legal title to a house. By contrast, using a Google account to access a travel site, or using an ePassport credential to access an online government service, are situations where the assurance level of the credential is well matched to the assurance requirements of the app.
So if the authentication model is changing, application providers have a decision to make: should they build credentials or buy them?
The truth is that every app already provides credentials for its users (for example, a user ID and password), so the build decision really means reinvesting to make the providers’ credentials stronger (by using multifactor authentication, for example). The buy decision means acquiring credentials from a trustworthy credential provider.
So, how do app providers make their decision? The answer is found in user password lists. If users keep their credential for an application on a password list, then that application should buy credentials from a partner (a credential subscriber or CS). If users do not keep an application’s credential on a user password list, the application is in a very good position to sell or share its credential (a credential provider, or CP). This sounds counterintuitive, but if a user keeps an application’s credential on a password list, then the user has not memorized it, which means the user is a relatively infrequent user of the application’s services. For example, most people have committed their e-mail and bank account passwords to memory – they do not have them written down.
So the build-or-buy decision actually turns on the question of whether the application is (or wants to be) in the business of resetting passwords. Applications with high usage rates have low password reset rates, because of user usage frequency. Applications with low usage rates have high password reset rates. If an app has high password reset rates, then it should buy credentials from a partner. If the password reset rate is low, then the app is in a great position to make life better for users online.
Economics of credential sharing
In addition to coping with the user frustration caused by password resets, a would-be credential subscriber app also has to handle password reset costs, which can be $25 per call and higher. By contrast, the cost of purchasing an authentication contract can be as little as $2 per active user per year. Not only is the cost much lower, the password-reset costs are borne by a trustworthy credential provider (which has low password reset rates).
This sounds lopsided, but a credential provider benefits from a revenue multiplier based on the number of sites to which the user takes the credential. So providers can be paid 10-20 times for taking the user to their Internet destinations and receive the additional benefit of providing a service that keeps users coming back more often – what marketers call a very “sticky” service.
The move to a user-centric authentication model is really about market specialization. Some application providers will become CPs and make their credentials even stronger by investing in multifactor authentication. Some CSs will seek to partner with those providers with strong credentials. Both parties win. Credential providers benefit from stronger relationships with users, while credential subscribers benefit from being able to offer stronger credentials than they can on their own, with better risk management, lower costs, and less friction or hassle for users. More meaningful services will be possible with stronger authentication, and users will be better served.
The government of Canada recently subscribed to a credential broker service that allows it to deliver online services that rely on a user’s current banking credentials. Customers of the Bank of Montreal, Bank of Nova Scotia, and TD Canada Trust are able to use their bank credentials to access many federal services. Users have fewer credentials, the banks benefit by providing more services to their customers (and getting paid for it), and the government achieves better outcomes at a lower cost and without password resets.
SecureKey Technologies launched SecureKey Concierge to provide Canadians with this credential broker service. The service is triple blind to protect user privacy: users can be confident that banks cannot see what they are doing online; the government cannot see the user’s banking details; and the Concierge service is not aware of the user’s identity.
SecureKey Concierge acts as an intermediary, connecting credential subscribers to credential providers. It matches the CS and CP, takes care of the market functions of fulfillment and delivery of anonymous authentication contracts, provides an any-to-any connection hub, and administers and executes the policy framework agreed to by its members.
The service is a working example of the move to user-centric apps. The government of Canada is a credential subscriber for its online services. The banks are credential providers. The model scales: more CSs and CPs are planned for the service. Users enjoy quick and convenient access to government services, CPs are pleased to provide a sticky service and get paid for it, and CSs can offer more compelling services online with better results at a lower cost.
Andre Boysen is executive vice president, digital identity and government solutions at SecureKey Technologies. He also lectures at Wilfred Laurier’s Schlegel Entrepreneurship Centre (www.securekeyconcierge.com).
