Central to any Privilege Entitlement Access Control negotiation is the concept of “risk”.  The level of potential risk to the asset or service determines the required level of security, including strong user authentication, before access is granted.  Further, the binary decision to deploy strong authentication, including biometrics, is also risk based and, specifically economic risk-based, which can also be viewed as economic feasibility.  Stakeholders won’t deploy it if they lose money at it. The reason industry stakeholders and technology leaders have declared traditional Credentialing & Access Control systems dead, like password/PIN, is because the expense of the frauds and breaches has become sufficiently large enough to offset the cost of replacing those systems.  The risk of relying on traditional access control mechanisms is now too high.  Thus, today, the question of “should we upgrade our Privilege Entitlement & Access Control Systems?” has been replaced with “How should we upgrade these systems?”  Further, “How do we upgrade the system as efficiently as possible without compromising trust or incurring risk?”  Further yet, just how do we do that in a distributed mobile network environment?  To answer that question, we must consider the authentication system design, in terms of economic feasibility, liability, trust and convenience.  Unfortunately, these concepts are perceived and valued very differently by service providers than by consumer privilege holders.

Importantly, the location of the authentication transaction affects the risks, liability, convenience and economic feasibility for the service provider and consumer differently.  Consider that there are effectively only two locations the user-authentication transaction can occur; on the device, and/or in the cloud.  Let’s consider each location in terms of economic feasibility, risk, liability and trust.

Authentication on the device implies just that, processing the authentication of the user on the phone.  Many phone manufacturers contemplate including fingerprint sensors on the device to authenticate the phone user, presumably the entitled privilege holder associated with the credentials stored on the phone or in some data repository elsewhere.  On-device authentication suggests that the fingerprint comparison occurs, or is transacted, literally on the phone, with a binary result then transmitted securely to the service provider for acceptance or rejection.  In this case, the service provider accepts higher risk and liability, as that service provider must agree to trust any and all authentication data transmitted from that phone.  This means the service provider has limited control of the risk and may be unlikely to accept this authentication in higher-value transactions.  Moreover, this model may be less economically feasible as that service provider must also support the potential multitude of disparate and proprietary authentication data sources that could be generated by any number of handset manufacturers, cellular operators, fingerprint sensors or matching algorithm template providers.  This could be costly to administrate and support.  However, refusing to support various disparate authentication systems could create inconvenience for the potential customer, including and maybe especially the enterprise customer, requiring the customer to use a select phone manufacturer or forgo the benefit of the service.  Moreover, the customer owning multiple devices would be required to enroll on each device and potentially for each service.  Further still, the enterprise customer may experience significant friction and cost related to upgrades and end-of-life replacement plans and is, thus, unlikely to invest in this model.  Therefore, in our opinion, this model may be utilized early in the adoption cycle for strong mobile credentialing, but is less likely to enjoy long-term or deep penetration.  The system will evolve to something different.

Authenticating in the service providers cloud implies capturing the biometric data on the phone and securely retrieving or transmitting it to the service provider’s cloud, where the authentication transaction takes place.  In this case, the service provider could reduce risk by comparing user-authentication data, captured during applicant enrollment, to data of existing customers to negate dual enrollments and fraud.  This is not possible when enrolling and authenticating on the phone.   Further, the service provider would enjoy reduced risk by maintaining control of the authentication process.  It seems natural that the service provider can trust its own, in house, systems more than those owned and operated outside the service provider’s control.   Deploying a hardware and operating system agnostic authentication engine in the service providers cloud would provide complete interoperability with handset input devices, significantly reducing the service provider’s capital investment in multiple disparate authentication engines.  This would further allow the individual and enterprise customer the choice of handset providers, without disrupting service availability, reducing friction and cost, while increasing convenience of upgrade and end-of-life replacement.  Both consumer and enterprise customers are likely to prefer and invest in this model, as a result.  In our opinion, this model reduces risk and capital outlay to the service provider, while increasing convenience to the consumer.  Further, in our opinion, this model is viable in enterprise environments, while the on-device model is not.  Thus, we believe strong authentication in the mobile credentialing evolution will emerge on-device, primarily in consumer applications, but will migrate to the cloud over time, which will facilitate enterprise adoption.

There is, however, a third design option involving a third-party authentication service in the cloud.  In this case, the on-device sensor captures the print, converts it to a template and securely sends it to the third-party cloud, which presumably would utilize the aforementioned single hardware/operating system agnostic and interoperable authentication engine.  The service provider must agree to trust binary authentication confirmation data from the third-party provider, but this would eliminate the need to trust more than one outside source.  Otherwise, this design would operate similarly to that of the service provider cloud-based system.  Assuming the third-party authentication service provider incorporates hardware and operating system agnostic (interoperable) systems, the consumer and enterprise customer would enjoy open choices between handset providers, who also would enjoy open choices between sensor providers.  This would reduce risk and cost to the service provider, the handset manufacturer and, both, the consumer and enterprise customer.  The third-party authentication system would allow the consumer and enterprise customer to enroll only once, but associate that single user identity with multiple services and across multiple devices, regardless of make or design.  In effect, the third-party, cloud-based authentication service would allow for “Identity Anywhere” or “Identity Everywhere”.

Mobile payments are part of a larger Secure Credentialing & Identification evolution.  Our Privilege Entitlement & Access Control systems are migrating into the emerging smart mobile computing ecosystem and must satisfy both risk and economic requirements, without excessive friction.  In our opinion, the migration of these strong authentication systems, including biometrics, will emerge on devices in relatively cumbersome consumer-facing applications.  They will continue to migrate to the cloud and ultimately will largely reside and function in the cloud.  Risk determinations, including economic feasibility, will determine whether the authentication occurs in the service providers cloud (highest risk assurance), or in the third-party cloud (middle risk assurance), or on the device (light risk assurance).  End user convenience and cost, will likely drive the majority of Mobile Credentialing authentication to the cloud, especially at the enterprise level.  Thus, we encourage stakeholders to consider the evolutionary trajectory of such capabilities and invest accordingly.