November 07
Andrew Nash

It’s Time for the Identity Ecosystem to Grow Up

Over the last 15 years, we’ve seen an enormous amount of great work go into designing modern identity systems—from SAML V1 kicking off the concept of identity federations to OpenID Connect and OAuth.

Today, we’re still largely focused on how identities are created, verified (at your favorite assurance level) and authenticated—or if you’re really adventurous, how identity attributes are shared (with consent?).

However, it is way past due for us to turn our attention to trusted operation of identity services, not just up-front establishment of authentication.

We happily designate  the service providers that utilize digital identities as “relying parties”, but fail to provide the most basic operational mechanisms to provide confidence in the ongoing health and effective use of those digital identities after they’ve been created.

Identity providers have no mechanisms in place to provide relying services with even rudimentary session-level status information. Management of sessions, including sign-off and suspension, are still being talked about. When it comes to fraudulent activity detection, risk evaluation and transactional health and safety, we’ve barely even scratched the surface.

In turn, service providers have a wealth of information based on transactional success or failure and behavior of identities on their system. Information invaluable in assisting an identity provider to more quickly determine that an identity they manage has been subverted.

In December, my daughter had an experience with a Skype hacker. I started receiving unusual messages from her via Skype chat (before you ask, yes, she had a unique, complex password that she changes regularly). Several hours after resetting her password, the hacker was still in control of her account and sending me messages on her behalf. The reason was that, even within Skype, password reset doesn’t cause open sessions to be terminated.

Recently, we’ve seen several specs formulated for sharing identity alerts. However, the current direction for the use of these specs is for email and identity providers such as Google and Microsoft to more conveniently share information with each other. More effective support of relying parties, or even the individual consumers whose identities are represented, is a “maybe, some day” result.

Identity providers around the world are hard at work supporting identities for government, financial and other high-assurance contexts. But in almost all cases, they’ve failed to implement risk evaluation engines, even for their own protection. Identity providers like Google and Microsoft that have invested in risk evaluation, don’t share the results of such information with their relying parties.

The UK Verify system has some rudimentary requirements about sharing “contra indicators” and “transaction monitoring”. But if a transaction turns out to be fraudulent based on misuse of an identity, the identity providers aren’t notified.

The UK Open Banking platform has a wonderful set of aspirations for changing banking and online commerce in the UK, enabled by the use of digital identities. But to date, it has no provision for sharing even operational alerts about identity usage, and there’s certainly nothing that covers fraud detection and mitigation.

I find it shocking to reflect on years of working on so many issues associated with digital identity, only to realize that the ecosystem is still in such a terribly immature state. It’s time to grow up and start dealing with operational issues and fraud detection.

1 The OIDF RISC ( and ITEF SET ( specifications are the best examples.

By Andrew Nash

View More Posts

Identiverse is engagement!

— Lance Peterman