The question at hand
You're designing an identity ecosystem that needs to scale across multiple organizations, jurisdictions, or sectors. Do you build on open standards like OpenID Connect and OAuth 2.0, accepting their constraints and governance overhead? Or do you develop proprietary protocols that fit your exact requirements and timeline?
This isn't an academic debate. The OpenID Foundation's OpenID Connect standard is used by billions of people across millions of applications, but plenty of closed ecosystems still thrive. Your choice affects everything from your integration timeline to your long-term vendor dependencies.
The case for open standards
Open standards offer interoperability by default. When you implement OpenID Connect or FAPI, you're joining an ecosystem where relying parties already understand your authentication flows. Your wallet can communicate with their verifier without custom integration work.
The technical debt argument is compelling. Standards bodies like the OpenID Foundation have already solved session management edge cases, Back-Channel Communication timing issues, and Proof Key for Code Exchange attacks you haven't encountered yet. You inherit battle-tested security profiles instead of discovering vulnerabilities in production.
Cross-border adoption becomes feasible. If you're building a digital credential ecosystem that needs to work across jurisdictions, proprietary protocols create friction at every border. Standards like eIDAS exist specifically to enable this interoperability. The OpenID Well-Known Conference (February 2-4, 2027, in London) focuses on exactly this challenge: how ecosystems achieve scale by sharing approaches to trust frameworks and adoption barriers.
Elizabeth Garber, the OpenID Foundation's Strategy and Marketing Director, frames it as collective learning: "Every ecosystem that works toward scale learns lessons that others can use." That knowledge transfer only works when you're speaking the same protocol language.
The case for proprietary approaches
Open standards move slowly. If you need to ship a working identity system in six months, waiting for working group consensus on a specification extension isn't realistic. You can build exactly what you need, when you need it.
The governance overhead is real. Participating in standards bodies means attending working group calls, commenting on draft specifications, and implementing features that serve the broader ecosystem but not your immediate use case. Your team becomes a standards contributor whether you planned for that role or not.
Proprietary protocols let you optimize for your specific threat model. If you're building an internal privileged access system with Just-in-Time Elevation, you might not need the full OAuth 2.0 Authorization Code Flow. You can strip out Front-Channel Communication entirely if your architecture doesn't require it. Standards force you to implement capabilities you don't use.
Vendor lock-in cuts both ways. Yes, proprietary systems create dependency on your provider. But open standards create dependency on the standards body's roadmap and the broader ecosystem's implementation quality. You're trusting that FIDO2 authenticator manufacturers will implement the spec correctly and that your relying parties will keep their libraries updated.
The adoption argument assumes you need widespread adoption. If you're building identity infrastructure for a closed ecosystem with a fixed set of participants, interoperability with external systems might be irrelevant. A proprietary protocol optimized for your exact requirements might serve you better than a general-purpose standard.
Where practitioners actually land
Most production deployments end up in hybrid territory. You implement OAuth 2.0 for federation with external partners because the ecosystem demands it. You extend it with proprietary claims and non-standard flows for internal use cases where you control both the Policy Decision Point and the relying party.
The scale question matters more than the technology question. If you're issuing credentials to thousands of holders across dozens of sectors, open standards become necessary infrastructure. The coordination cost of proprietary protocols exceeds the implementation cost of standards compliance. But if you're managing privileged access for 500 administrators within a single trust boundary, that calculus inverts.
Practitioners who've scaled identity ecosystems consistently report the same barrier: not technical interoperability, but trust framework alignment. You can implement OpenID Connect perfectly and still fail at adoption if your governance model doesn't align with your relying parties' risk tolerance. The protocol is necessary but not sufficient.
The AI integration question adds complexity without changing the fundamental tradeoff. Whether you're using machine learning for anomaly detection in session management or for identity verification, you still need to decide: do you build on protocols that other systems understand, or do you optimize for your specific architecture? AI doesn't make that decision easier.
Our take
Build on open standards when you need to cross organizational or jurisdictional boundaries. The implementation overhead pays for itself in reduced integration friction. If you're designing a digital wallet that needs to work with relying parties you don't control, proprietary protocols are a non-starter.
Go proprietary when you control the full stack and need to move faster than standards bodies. Internal PAM systems, closed-loop credential issuance, or highly specialized authentication flows can justify custom protocols. But document your decision and plan for the migration cost when your requirements inevitably expand.
The real risk isn't picking the wrong approach initially. It's failing to recognize when your scale requirements have changed. If your proprietary system suddenly needs to federate with external partners, you're facing a costly protocol migration. If your standards-based system is drowning in governance overhead for features you don't use, you're paying a tax that doesn't serve your users.
Track your integration count and your trust boundary expansion. When you cross five external integrations or three jurisdictions, open standards stop being overhead and start being infrastructure. Until then, optimize for shipping working code.
