IETF 124, November 2024. Montreal was cold outside, the discussions inside were heated. AI agents were the topic on everyone’s lips, and every working group seemed to be looking at the problem through their own lens. The WIMSE folks were thinking about workload identity. The OAuth crowd was extending grants and tokens. SPIFFE was already deployed in production for service mesh identity. And the Agent2Agent BOF and WebBotAuth WG were trying to address the same topics through their own lens.

The identity community had spent the better part of two decades building a robust, battle-tested toolkit for authentication, authorization, delegation, and observability. OAuth 2.0, SPIFFE, WIMSE, Transaction Tokens, Shared Signals, OpenID Connect. This stuff works. It’s deployed at planet scale. And yet, every new “agent identity” proposal we were seeing started from first principles, reinventing token formats, credential lifecycle, even basic concepts like “what is a workload identity.”

Quickly we sat down with Pieter Kasselman, pointing at the elephant in the room: we don’t have a standards gap. We have an assembly gap. With the support of Brian Campbell, Nick Steele, Yaroslav Rosomakho, and Aaron Parecki, this thinking became draft-klrc-aiagent-auth, now at version -03. A personal Draft that introduces a simple but strong conceptual model called AIMS (Agent Identity Management System).

The thesis: agents are workloads

The core argument is deceptively simple: an AI agent is a workload. It needs an identifier. It needs credentials. It authenticates to other systems. It requests authorization. In short, something the industry has been solving for services, containers, and microservices for years.

Still, what makes agents operationally different is the risk profile:

Dynamic action surface. An agent doesn’t have a fixed API contract. It decides at inference time which tools to call, in what order, based on reasoning that didn’t exist when the agent was deployed.

Cross-domain by default. A single agent task routinely spans internal services, third-party APIs, other agents; each in different trust domains.

Time sensitive and high-churn. Agent instances spin up, fan out, terminate. Some are long lived, running for hours or days, most are short lived, running for seconds or minutes.

High-value targets. An agent with not-contextualized or not-bound credentials is essentially a privileged insider with no audit trail.

What AIMS actually does

AIMS defines a layered stack where each layer is built on guarantees from the one below. There’s no single solution to all of this: it takes a wide range of technologies covering identifiers, authentication, authorization, delegation, and monitoring. What didn’t exist before was the organizing framework that ties them together.

Here’s how it breaks down:

Identifiers. Foundation for everything. The draft proposes WIMSE identifiers (a superset of SPIFFE IDs). A URI that uniquely identifies the agent workload.

Credentials. Authentication and authorization rely on credentials that cryptographically bind identifiers to agents, instead of bare identifiers or long-lived secrets like API keys. The WIMSE credentials specification (X.509 certificates and Workload Identity Tokens) fits well here, along with SPIFFE JWT-SVIDs. Cryptographic proof of ownership of the identifier.

Provisioning. SPIFFE for the general case, while leveraging platform-specific mechanisms (MDMs for end-user posture assessment, cloud-native posture evaluation) depending on where the agent runs.

Authentication. Agents authenticate to LLMs, tools, services, resources, other agents. The draft maps WIMSE credential mechanisms with mTLS at the transport layer and HTTP Message Signatures, WIMSE Proof Tokens at the application layer. The through-line: avoid static pre-shared credentials, it’s an anti-pattern.

Authorization. Specifically, delegated authorization through OAuth. What an agent can access, whether it’s acting on behalf of a user or on its own, how end-users authorize agents to act on their behalf. The draft maps the existing OAuth specs to specific agent use cases: authorization code flow for delegated user flows, client credentials for autonomous agents, token exchange scope and authorization details management, identity chaining via ID-JAG for multi-domain workflows and leaves a space for policy based authorization which may be facilitated through AuthZEN and other policy based authorization standards

Observability and Remediation. Risk evaluation changes. Authorization may need to change mid-session. How do you propagate that? The OpenID Foundation’s prior work here is directly applicable: Shared Signals Framework (SSF), CAEP for continuous access evaluation, RISC for account-level signals. Audit critical details, revoke credentials, trigger re-evaluation.

Policy and Compliance. What are the rules? How do you measure against them? This is inherently deployment-specific. The draft deliberately doesn’t point to any single policy standard here, leaving room for organizations to fit their existing infrastructure in.

Every single component in that stack is either an existing RFC, a mature IETF draft, or an OpenID specification that’s already deployed in production somewhere. The draft doesn’t define any new wire protocol. It profiles and composes.

The constraints that motivated us

Through this work, we set ourselves a few constraints early:

If it exists and works, use it. Don’t reinvent credential formats. Don’t create yet another token type. Don’t define a new discovery mechanism when OAuth Server Metadata and Protected Resource Metadata already exist.

If something is genuinely new, call it out as a gap. The draft explicitly identifies areas where profiles, extensions, or new work is needed. Human-in-the-loop mid-execution authorization is one: CIBA gets close but the message flow and client initiation model don’t map well to an agent needing approval during execution, not before. That gap has already produced a new draft (more below). Cross-domain use of transaction tokens is another. Dynamic client relationship management proved DCR was not the end goal, the emergence of CIMD was helpful.

Don’t solve the deployment architecture. AIMS is a conceptual model, not a product spec. It might be one component or distributed across identity providers, authorization servers, policy engines, and runtime enforcement points. That was intentional as it has to map to real deployments that already look different from each other. 

The ecosystem is moving

This is the part that gives me optimism. The framework isn’t just a document; it helped catalyzing focused work on the specific areas where profiles and extensions are genuinely needed. It proved people aren’t reinventing but they’re extending precisely where the existing tire doesn’t fit the road.

The market started validating the thesis of the draft independently. Sean O’Dell, Distinguished Engineer at CVS Health and now a co-author on the Transaction Token Chaining Profile, published “You Already Have the Pieces. Now Build It.” on The Identity Underground. It’s worth reading in full. He opens with the same observation we built the draft around.

OpenAI, Anthropic, and Snowflake have all shipped Workload Identity Federation endpoints  using OIDC and SPIFFE-style credentials to authenticate workloads against their platforms without static API keys. This is literally the AIMS model landing in real systems. The theory is catching up to what practitioners are already doing, and vice versa.

Finally, new proposals have come out of this work:

OAuth Transaction Authorization Challenge by Yaroslav Rosomakho, Brian Campbell, Karl McGuinness, and Pieter Kasselman tackles head-on the human-in-the-loop gap we identified. CIBA’s message flow doesn’t map well to mid-execution approval as it’s client-initiated, not resource-driven. This draft flips it: the protected resource issues a signed challenge when a specific operation requires additional authorization; the agent relays the challenge to a client, which presents it to an authorization server that obtains approval and issues a transaction-scoped access token. It reuses OAuth’s existing capabilities.

Transaction Tokens for Agents by Ashay Raut extends the Transaction Token specification with agent-specific semantics through the act claim for identifying the agent performing the action, and an agentic_ctx claim for conveying operational constraints relevant to authorization, auditing, and policy evaluation within the service graph.

Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining by George Fletcher, Pieter Kasselman, and Sean O’Dell defines how a Transaction Token scoped to a single trust domain can be used as an authorization grant to obtain a JWT Authorization Grant for crossing a trust boundary. This is what makes cross-domain multi-agent workflows practical without requiring every authorization server to trust every other one directly.

WISE: Workload Identity Security Events by Dag Sneeggen, Sean O’Dell, Pieter Kasselman, and myself profiles the Shared Signals Framework for workload identity lifecycle events. SSF, CAEP, and RISC solved the human identity signal story, and WISE extends the same asynchronous event model to workloads: credential rotation, trust revocation, posture changes, and the security state transitions that arise when agents act on behalf of humans, on behalf of other agents, or autonomously. It builds on RFC 8417 (SET), the WIMSE identifier and credential specifications, and the CAEP Interoperability Profile patterns.

All of these are exactly the kind of focused, incremental work that the AIMS framework was designed to surface as missing.

What this means for practitioners

If you’re an identity architect or an IAM practitioner reading this, here’s the takeaway: you already have most of what you need to secure agentic workloads. The standards are written. The protocols are mature. What’s been missing is the map showing how they connect as well as the clarity on where the gaps actually are.

That’s what AIMS provides. And where the map shows blank spots, the community is filling them in with targeted, interoperable specifications rather than competing greenfield stacks.

We’re heading into IETF 126 in Vienna later this month. The AIMS draft is already shaping the standards landscape. I expect to have more exciting updates as those meetings wrap up. In the meantime, the pieces are on the table. Time to assemble.

About the Author

Jeff Lombardo is a Principal Identity Specialist at AWS based in Montreal. He contributes to IETF and OpenID Foundation work on identity architecture for agentic systems. The views expressed here are his own.

The post Assembly Required: How we Stopped Reinventing and Started Composing Standards for Agentic Identity appeared first on IDPro.

Part 2 of 3

By Vidyaa Ganesh

This is Part 2 of a three-part series on IAM maturity measurement. Part 1 reviewed the published research showing that 60-70% of organizations remain at early-to-mid stages of IAM maturity. This installment examines the frameworks currently available and the structural reasons no standard has emerged.

If 60% to 70% of organizations are stuck at early-to-mid stages of IAM maturity, as five independent research sources consistently show, a natural question follows: why can’t they measure and track their way out? The answer is not that frameworks are absent. Several exist. The answer is that they are incompatible with each other and, in most cases, not designed for cross-organizational comparison.

CMMI and General-Purpose Maturity Models

The Capability Maturity Model Integration, now maintained by ISACA, provides a well-established framework for assessing process maturity across domains. Its five-level structure (Initial, Managed, Defined, Quantitatively Managed, Optimizing) has been widely adopted outside its original software engineering context. CMMI’s staged representation introduces an important concept: lower-level capabilities must be satisfied before higher levels can be claimed. An organization cannot skip foundational process areas and still achieve a high maturity rating.

CMMI’s limitation for IAM is that it is domain-agnostic. It provides structure and principles, but it does not define what IAM-specific capabilities should be measured, how they should be weighted, or what constitutes a reasonable benchmark for a given industry.

Gartner IAM Program Maturity Model

Gartner’s IAM Program Maturity Model, published in September 2025, defines six dimensions of IAM maturity across five levels. It is perhaps the most authoritative vendor-neutral reference available, and its dimension structure (covering governance, identity lifecycle, access management, privileged access, and related areas) reflects a comprehensive view of what IAM programs should include.

However, the model is paywalled, which limits its utility as a shared community standard. It also does not publish empirical benchmark data showing where organizations in specific industries typically fall on its scale. Without that benchmark layer, an organization can assess itself against the model’s definitions but has no way to know how it compares to its peers.

SailPoint Horizons Framework

SailPoint’s Horizons framework is notable because it publishes actual empirical data. The five-horizon model is based on annual surveys, uses a clustering algorithm to assign organizations to maturity levels, and breaks results out by industry, geography, and organizational size. It also explicitly incorporates the concept of capability prerequisites: to be placed in a given horizon, an organization’s capabilities must cover most environments and identity types.

The limitation is that SailPoint is a vendor with commercial interests in the identity governance space. While the research methodology appears sound, a vendor-published framework will always face questions about objectivity, particularly when the recommended path to higher maturity runs through capabilities that the vendor sells.

CISA Zero Trust Maturity Model

The Cybersecurity and Infrastructure Security Agency published a Zero Trust Maturity Model that includes an identity pillar with explicit maturity levels. It is publicly available and government-backed, which gives it credibility. The model explicitly states dependencies between pillars: identity capabilities must be established before device trust or network trust can be meaningful.

The model is scoped to zero trust architecture, not IAM broadly. It does not cover domains like identity governance and administration, customer identity, or the operational and organizational dimensions of an IAM program. It is useful as a reference but incomplete as a general-purpose IAM maturity standard.

Vendor-Specific Models

Several vendors have published maturity models specific to their market segment. Okta published a four-stage CIAM maturity curve (Basic, Automated, Intelligent, Continuous). Auth0, now part of Okta, published an Identity Maturity Framework with six assessment dimensions. WSO2 published a five-level CIAM maturity model.

These models are useful for understanding capability progression within a specific domain, but they share a common limitation: none publishes empirical data about where organizations actually fall on their respective scales. They define the levels but do not populate them with benchmark data.

The Comparability Problem

The fundamental issue is not that frameworks are absent. It is that they are mutually incompatible. An organization assessed using SailPoint’s five-horizon model cannot compare its results to one assessed using Bravura’s four-level model or Gartner’s six-dimension framework. The scales differ, the dimensions differ, the weighting logic (where it exists) differs, and the definitions of what constitutes each level differ.

For IAM practitioners, this means that changing consultants often means starting the measurement process from scratch. For CISOs reporting to boards, it means that year-over-year comparisons are only valid if the same assessment approach is used each time. For the industry as a whole, it means there is no aggregate data pool that could raise the bar for everyone.

Table 2. Comparison of existing IAM maturity frameworks

Why No Standard Has Emerged

Given the clear need for standardized measurement, it is reasonable to ask why one does not already exist. Several structural factors have worked against the emergence of a shared standard.

Vendor incentives cut against standardization. Identity vendors benefit from publishing their own maturity models because it frames the conversation in terms of their product capabilities. A vendor’s maturity model will, almost by definition, position the vendor’s strongest features as markers of advanced maturity. This creates a structural incentive against converging on a shared, vendor-neutral standard.

IAM spans too many domains. IAM encompasses identity governance and administration, privileged access management, workforce authentication, customer identity, cloud identity, identity threat detection, and governance and strategy. Each has its own maturity curve, vendor landscape, and regulatory drivers. Building a single model that meaningfully covers all of them requires significant domain expertise and difficult weighting decisions.

No governing body has taken ownership. Unlike financial accounting (which has GAAP and IFRS) or software process maturity (which has CMMI), identity management does not have a single governing body that has taken responsibility for defining and maintaining a measurement standard. Organizations like IDPro, IDSA, NIST, and ISACA each contribute pieces of the puzzle, but none has published a comprehensive, empirically-grounded IAM maturity standard.

Measurement requires difficult methodological choices. How should domains be weighted against each other? Should privileged access management carry more weight than governance? How do you handle the scenario where an organization scores highly in advanced areas but has gaps in foundational controls? These are not trivial questions, and without empirical data to validate different approaches, any methodology choice can be challenged.

The CIAM measurement gap. While workforce IAM has at least some benchmark data available, the CIAM space has essentially none. Gartner’s 2025 research found that over 50% of organizations still use homegrown or no CIAM solution at all. Multiple vendors have published CIAM maturity models, but none has published empirical data about where organizations actually fall on those models.

Endnotes

9. ISACA, CMMI Version 3.0 (CMMI Institute/ISACA, 2023).

10. Gartner, Inc., Identity and Access Management Program Maturity Model (September 2025), Document ID: 1203314.

11. SailPoint, Horizons 2025-2026, Appendix, p. 44.

12. Cybersecurity and Infrastructure Security Agency, Zero Trust Maturity Model (CISA, 2023).

13. Okta, Inc., From Zero to Hero: The Path to CIAM Maturity (Okta eBook).

14. Auth0/Okta, Auth0 Identity Maturity Framework (IMF) (Auth0, 2021).

15. WSO2, A Maturity Model for Customer IAM (WSO2 Blog).

16. Gartner, Inc., Innovation Insight for Customer and Partner IAM (April 2025).

NEXT IN THIS SERIES

Part 3: What Good Measurement Looks Like

If the IAM community is going to move toward standardized measurement, what would a credible framework need to include? Seven design principles, the open questions that remain, and a call to action.

About the Author

Vidyaa Ganesh is a Senior IAM Engineer and a solutions architect with over six years of experience delivering identity governance programs for financial services, energy, telecommunications, and public sector clients. She holds a Master of Engineering from Concordia University, is a member of IDPro, and is the creator of AXIS (axis.identara.ca), an open IAM maturity assessment framework.

The post Assembly Required: How We Stopped Reinventing and Started Composing Standards for Agentic Identity appeared first on IDPro.

True confession: Many decades ago, my 17-year-old self created a synthetic identity with ready-made biometric authentication…otherwise known as a fake ID. Living in Hawaii, I needed a faraway place to call my fake home, and I picked Yonkers, New York. You could call me a real-life reverse McLovin.

Get yours today! Credit: Amazon

Fast forward to now. Identification is, of course, much more easily checked – but it’s also much more easily faked. In large part that’s thanks to generative AI, which dramatically increases the scale and automation of attacks.

Crowdstrike’s Global Threat Report documents how “identity threats exploded in 2023” with a boost from genAI, and that’s not even the half of it. Read on to understand where the threat is coming from and what to do about it.

Biometrics, We Hardly Knew Ye

Many organizations have been making upgrades to strengthen their authentication capabilities, often through the application of biometrics.

But is biometric authentication the factor you think it is?

Authentication Factors: Thou Shalt Count to Three

Classically, there are three factors used to verify the authenticity of a credential; using them in combination contributes to authentication strength. (Other contextual cues in their infinite variety form a phantom fourth factor. Five is right out!)

• Something you know, like a password, is what NIST’s Digital Identity Guidelines call a “memorized secret”.
• Something you have, like your association with a particular mobile device, is what NIST refers to as an “out-of-band authenticator”.
• Something you are, like your particular face or fingerprint, is what NIST calls a “biometric characteristic”.

Two of my financial services providers just rolled out voice authentication as a new “strong” method lately, and tout not just its ease of use but also its security. We are assured, for example, that “Your voiceprint is stored securely as a mathematical equation, and only works for verification with our system.”

Now why would there be a Spinal Tap reference here? Credit: MakeAGIF

Is that really how things work?

Biometrics Are Different

The unfortunate fact is that biometrics make a better username than a password. That is, they’re pretty good at distinguishing “you” from “other people”, but limited in their ability to confirm that you are you. As NIST says:

For a variety of reasons, this document supports only limited use of biometrics for authentication.

Their reasons are important to understand:

• The nature of biometric comparison is to be probabilistic – based on statistical likelihood – rather than deterministic, such as when a system compares a presented vs. pre-registered password or device. It gets a letter grade vs. a pass/fail.
• The false match rate (FMR) and false non-match rate (FNMR) of a biometric method are critical stats — but you don’t interpret a low FMR alone as giving high authentication confidence. This rate doesn’t even account for spoofing attacks.
• Unlike with a password or device, there are few circumstances where you can properly revoke a biometric. After all, you can’t just do a “fingerprint reset” on yourself.

• The biggest distinction is that biometric characteristics aren’t secrets! Many biometrics make terrible secrets because they’re part of our exhaust data, both online and IRL. It’s a losing battle to protect something like a unique face from being seen.
• As a result, we must rely on liveness detection to ensure a binding between the presented biometric and the person. And that means we must trust a complex chain of detection sensors and processors.

The Last Decade Saw a Legit Biometrics Revolution

This isn’t to say that biometrics can’t form a crucial part of secure ecosystems.

Touch ID’s launch in 2013 started something big. Its immediate impact was to make the iPhone 5s easier to unlock. Fingerprint readers had previously required cumbersome end-user processes and erred on the side of extra-low FMRs. For the price of a few more false positives, and with a painless enrollment process built into the experience, Touch ID – and in 2017, Face ID – led to a remarkable cascade of use cases.

• Phone usage increased. In 2013, the year of Touch ID, people were checking their phones 110 times a day. By 2022, that number was up to 352 times a day, or once every three minutes on average. (You know you’ve done it!)
• Phone security increased. In 2013, 53% of phones were kept locked. By 2021, locked phones were ubiquitous at nearly 99%.
• Phones became de facto data wallets. The new mobile environment, involving a secure element, made on-device storage of personal data – including items beyond biometric templates for face and fingerprint matches – attractive.
• Phones became wallets, period. The availability of this data, and the ability to bind it to the end-user with biometrics, unleashed a flood of payment scenarios and the digital wallet era.

Mobile OS-level biometric unlocking isn’t without complications, such as reliance on a memorized secret (PIN) for confirmation and recovery. But the sheer weight of improved security and value has been impressive.

AI Cut Short the Server-Side Biometrics Revolution

Unfortunately, we’re in a dramatic new threat landscape.

I’m focusing on the “server-side” revolution because wholly digital identity scenarios – foreign travel pre-authorization, remote employee onboarding, direct-to-consumer eCommerce, gaming – have become inescapable. And they rely more and more on server-side biometrics for identity verification and authentication. These scenarios are now at extra risk when they use these biometric checks without a trusted device as another factor.

The generative AI revolution took mere weeks to explode from a bubbling low-level concern into a bona fide threat. November 2022 saw the launch of ChatGPT’s API, DALLE-2, and Whisper. Just two months later, organizations experienced disturbingly widespread AI-boosted identity fraud: In a survey concluding in January 2023, Regula Forensics found that 29% of organizations were being targeted by video deepfakes and 37% by voice deepfakes.

By December 2023, iProov’s Threat Intelligence Report revealed that face swaps increased 704% from the first half of the year to the second. They warned that “Face swaps are now firmly established as the deepfake of choice among persistent threat actors,” and that nearly half of the threat groups they’re tracking were newly created.

The report shares an up-to-date example of face swap technology (see the second listed video) that provokes amazement among viewers but is becoming routine among threat actors.

Creepy. Credit: iProov

AI technology can be used cleverly for good even in the deepfake realm – check out HYPR’s Bojan Simic “speaking” in Japanese — but even the creators of the base technologies are spooking themselves about the consequences. OpenAI has stated its Voice Engine should be held back from general release because it’s so good that it’s certain to be misused.

A Brief Tour Through the Consequences

The monetary costs of this new landscape are shocking – but we should also recognize the societal costs of these very personal forms of attack.

Classic Cyber

The most obvious consequence is classic cyber risk and fraud. Most of the attacks are intended for financial gain. A dramatic example came in early February 2024 when a Hong Kong finance professional experienced a unique form of spear phishing: a faked-up request to transfer HK$200 million, supported by an entire cast of senior exec characters deepfaked in the context of video conference calls.

Political

Nonmonetary but serious motivations include disrupting the political landscape. A voice deepfake, not the real President Joe Biden, was behind a series of robocalls in January 2024 urging New Hampshirites not to vote in their state’s primary election. Granite Staters who remembered a similar controversy from mid-2022 may have been extra confused because the earlier instance was a false alarm.

Cultural

The constant uncertainty about what’s real affects not just famous people but all individuals.

Every 100% digital interaction without a definitive authentication method now has question marks around it. We could call this the Voight-Kampff challenge, after the test in the Blade Runner movie (and source novel) to root out non-humans that relied on micro-expressions, bodily functions, and expressions of empathy. To the question “How can people not tell this is AI?” posted in March 2024, one Redditor said:

“Seeing AI pictures, reading AI generated text, I’m starting to feel like Rick Deckard. I’m no longer able to trust anything I see or even ‘people’ I talk to through chat OR voice. I’m giving everyone and everything around me the Turing Test without even realizing it.”

Another fake ID you can go and buy. Credit: eBay

Check out the TRUE project, which is taking this societal risk very seriously indeed.

Doing Battle Against These Risks

What are our best options to mitigate and prevent these risks, when AI is powering high-scale attacks and elaborate spear-phishing episodes alike?

Some options count as obvious CISOcraft (or are perhaps emerging as CIDOcraft). A Zero-Trust mindset and a commitment to layering signals and decision-making actions still go a long way. A LastPass employee recently batted away a social engineering attack that had a deepfake element but smelled wrong for traditional reasons. And successful attacks like these stolen ChatGPT credentials are AI-adjacent but not necessarily a consequence of the AI era.

Here are additional recommendations for battling these dramatic new threats.

Respect the New Arms Race We’re In

Now is the time to develop a deep appreciation for the ways biometrics are different and the ways AI is rapidly creating unknowns. Stay attuned to NIST’s Digital Identity Guidelines in these areas, and stay alert for the forthcoming final fourth revision. As well, check out the work of the Kantara Deepfakes group.

The Liveness.com site reminds us that two-dimensional liveness checking isn’t all it’s cracked up to be, yet. So, increase your awareness of the state of the art in liveness detection and participate in the security community surrounding it. If you’ve got a great solution, consider taking part in Face 2024 and other competitions. The FTC’s recent voice cloning challenge produced heartening results.

Pair Biometrics With Other Authentication Tricks

Passwordless experiences that get still-extant passwords off the wire are still better than password-bearing interactions. Much like Touch ID, they have the potential to reduce ecosystem-wide risk. So, accelerate your plans to move to phishing-resistant authentication methods. Liminal research says 48% of practitioners who are planning to adopt passwordless solutions in the next two years prefer biometric authentication.

FIDO multi-device credentials aren’t perfect, but they hit a new sweet spot for security, privacy, user choice, and user experience. So, use passkeys where possible. They typically leverage biometrics in proper fashion, binding the user to the channel used.

Get Fine-Grained About Verifying Identity Data

If you want to be sure you’re not looking at a “swapped face”, add more identity verification signals to your registration and authentication user journeys. The trick is to scope those signals to individual pieces of data, make them more privacy sensitive, and reduce their invasion into the user experience. An example is privacy-sensitive age estimation, a new biometric technique for responding to the age-appropriate design codes and website age-gating mandates sprouting up.

The emerging verifiable credentials era presents an intriguing opportunity to start trading in verified-identity “small data”. If you could ask for and receive individual verified identity signals from a user’s wallet — with biometric and binding assurances about the quality of those signals — what would you ask for?

Finally: Be wary of simply participating in a classical security arms race as your only strategy. Bots battling bots for inches of fraud detection ground won’t get us where we need to go. Incremental gains in liveness detection will be swamped by AI’s endless invention. We’re in the biometrics singularity now — so we need to innovate more than ever before.

Eve is a globally recognized pioneer in identity and access management and standards. Her roots are in semi-structured data modeling and the API economy and include a passion for fostering successful ecosystems and individual empowerment. At Venn Factory she drives identity, security, and privacy success in the connected world by bridging the gap between technical intricacies and strategic business outcomes.

Eve’s leadership on pivotal protocols such as XML, SAML, UMA, and HEART as well as industry efforts like UK Open Banking, US government health IT, and the medical Internet of Things demonstrate her unwavering commitment to innovation.

As CTO of ForgeRock, Eve oversaw emerging technology R&D, evangelism, and innovation culture, and empowered her team and cross-functional colleagues to deliver results to dozens of Global 5000 customers, partners, analysts, publications, and events. She previously served as a Forrester Research security and risk analyst covering IAM, strong authentication, and API security.

Thanks for reading! Visit the Venn Factory to request an expanded version of this article.

The post Authentication and AI: A Race Against Time appeared first on IDPro.