Two decades ago, I was asked to serve on a special committee to investigate how the Social Security Administration (SSA) could make better use of then-emerging public key infrastructure. We did the usual series of meetings, followed by the usual report, followed by the usual read-out, and so on and so forth. It was all pretty standard fare, except for this one comment - and I wasn't sure if it was super dumb or super deep - that a congressman made during our briefing.
Specifically, he suggested openly that the SSA should not be allowed to see the social security numbers of U.S. citizens. Now, as you would imagine, eyes immediately began to roll amidst the muffled guffaws of our panel members. But I remember thinking that just perhaps this member had stumbled - quite by accident - onto a key point. That is, if you are the supervising entity for authorization, then perhaps you shouldn't play a central role in generating or storing secrets.
This point came to mind today as I sat down with Lou Steinberg to discuss a new capability he and his team are developing. Members of our community will recognize Lou as the recent CTO of TD Ameritrade, as well as a long-time contributor to the IT and security community. Lou's team is called the Authoriti Network and they've developed a clever scheme for client-side generation of authorization tokens that reduces fraud and infrastructure costs. Here's the idea:
We all know that real secrets are never really secret unless extraordinary measures are taken by all participants in handling the secret. So, that person in the bar who hesitates to share their personal mobile number or email is assuming - incorrectly - that you cannot go find this information on your own. Or that person collecting an authorization PIN generated by a service provider is also assuming the PIN is secret - and this may not be a reasonable assumption.
In response to this weakness of server-generated and stored credentials, the Authoriti Network team has created a new process based on something they call an Authoriti Permission Code. The idea is that the client generates this code locally, sets appropriate authorization policy, and then shares the permission with a service provider. All management and control reside with the client, thus ensuring that authorization secrecy is no longer server-dependent.
"What we have done essentially," Steinberg explained, "is create a solution in which multi-factor authorization can be provided to consumers. And we've done this with client generated permission codes that include flexible policy options, and a simple interface embedded in a standard mobile app. This improved transaction model returns authorization control to the users where it belongs."
The primary use-case for Authoriti Permission Codes is surprisingly simple: A consumer begins by locally generating a permission code, which is then protected by a private key, and which embeds the desired policy-based usage constraints directly into the code. The consumer then requests a transaction from some institution and provides an identifier and the permission code as part of the request.
The institution checks the request via a simple web service, providing the received permission code to a back-end support Authoriti validator - presumably an entity that is established to perform this function for this institution or group of institutions. A simple validation response of yes or no is provided back to the requested institution to signal whether the consumer's desired transaction should be authorized.
"We see two main benefits to our new model," Steinberg explained. "First, there will be a dramatic reduction in fraud, simply because unlike server-based authentication, authorization really originates at the client and is secured end-end as the real secret. And second, there will be considerable cost reductions involved for the institutional service provider, because the infrastructure required to support this multi-factor authorization scheme is greatly reduced from the current server-based PIN approach."
I asked Steinberg about how his model might extend to third-parties and he was quick to explain how simple the integration would be. Consumers would start by authorizing limited data access to a trusted third-party, who would then go through the normal data request with the institution via the web service API. Again, the primary goal is to make a yes or no determination via the validation entity as to whether a given transaction is authorized.
We spent some time going through the Authoriti mobile app, and I liked the different policy options embedded in the design. But it seems clear to me that the real power will not come from some downloadable app offered by Authoriti, but rather through partnership with a set of institutions. And the executive team Steinberg has assembled, including veterans Larry Bettino and Marv Adams, certainly has the knowledge and relationships to make this happen.
If you work in an institution that is struggling to improve its authorization process for some consumer service, then you would be well-advised to give Lou Steinberg and the team at Authoriti Networks a call. I am convinced that multi-factor authorization based on client-generated secrets is a winning model, and one that should not only help make services less expensive, but that will also have a meaningful impact on reducing fraud.