- Unsupervised Learning
- Posts
- UnifyID and Continuous Authentication
UnifyID and Continuous Authentication
So I was just watching the pitches for the six Disrupt finalists, and there were a couple that had The Glow for me.
First, was Carbon Health, which is basically like 90% mobile-device-based healthcare. It’s fantastic. And there were a couple of others, which I will talk about in my show this week that were interesting as well.
But the one I absolutely loved was UnifyID.
What they’ve done is implement the idea I wrote about in my blog post called The Future of Authentication last April.
The idea is that authentication will no longer be point in time and based on a single (or even two) factor(s). Instead, authentication will happen constantly, will be sourced from hundreds of various factors in a constant, streaming way, and your challenge level will match the sensitivity of the action you’re wanting to perform.
UnifyID has addressed the major piece there by capturing around 100 different metrics on a person and using them in the algorithm. They haven’t addressed constant authentication, per say, but that’s because it requires the receiving system to support that as well, which will take a larger industry change.
But I’m super excited to see someone working on the various factors that can become Continuous Authentication.
I had some observations about the company and the pitch, however.
Thoughts
The name is not great. It’s not ID (Identity) that they’re addressing—it’s authentication. I imagine they had collision issues with good names around “Auth”, but this could prove to be problematic for them in the future. When I heard the name I thought it was something around Federated ID, or, you know—unifying identification. It’s very much not that at all, so they’ll probably have to change their name in the future. Good options would be things like: MeAuth, AuthMe, UniqID, SenseSelf, and 10 others I could come up with. Of course, locking in names and domains is non-trivial, so they could have already been down that path.
The final question on stage had to do with sneakers vs. high heels, and that’s a major problem for these types of algorithms, i.e., if you change part of your pattern, for whatever reason like injury or a life event happens or whatever, you suddenly alter the data coming into the algorithm. I used to work with a company that did just typing authentication, and if you hurt your hand or had a few drinks, it caused you to fail to authenticate. They gave the right answer here by saying that the other inputs should compensate, but it’s still a hard problem.
I’m unbelievably happy to see this company on the stage. I think it’s far and away the most interesting in the bunch.
My prediction is that it will either be them or Carbon Health that wins.
Notes
What this technology needs is a compliment that handles other pieces of the authentication puzzle, such as integration with various platforms, policy-based authentication using your location, various other attributes of your current state, etc. I’m affiliated with one such company, called FlexSecure, which does a lot of that stuff that compliments this approach. They’re separate but related problems.
Thanks to Mark Cunningham for talking through this auth problem many times over the years.
The ID/Auth space is massive, with room for this type of play, companies that only address policy and integration, and a whole other set of offerings that unify the ID part. Before you can even do authentication you have to know which of your identities you’re authenticating as.