The 36-Day Countdown That Isn't

On October 17, 2026, the IETF Datatracker for the Identity Assertion JWT Authorization Grant specification reads one line: I-D Exists. The document sits at revision -04. It has sat there for roughly a year. There is no Working Group Last Call scheduled. No responsible Area Director has been named. And somewhere in a content calendar, a headline was written: The Industry's Primary Agent Identity Standard Expires in 36 Days.

Here is the first thing the framing gets wrong. IETF Internet-Drafts expire every six months. Tens of thousands of them, per year, as a matter of administrative hygiene. The expiry date on the cover of a draft is a filing system artifact, not a failure signal. The piece that generated this round of urgency admits as much in its own fifth paragraph, then proceeds to build an entire investment narrative on top of the thing it just conceded was routine.

I have spent the last nine months building on-chain and off-chain identity graphs for agent-funded wallet clusters, and I have watched this exact rhetorical pattern repeat across three market cycles: take an administrative event with a visible timer, attach a countdown to it, and let the reader's anxiety do the analytical work. The countdown is not a signal. It is a substitute for one.

So let me do what the countdown piece did not: separate the four things that are actually being conflated here — protocol maturity, interoperability, commercial adoption, and standard capture — and price each one honestly.

What ID-JAG Actually Is, Stripped of the Narrative

Aaron Parecki, Dick Hardt, and Karl McGuinness are the names on the draft. All three are real, verifiable figures in the OAuth ecosystem. Parecki chairs the OAuth Working Group. That last sentence deserves to be read twice, and I will return to it, because it is the single most under-analyzed fact in the entire conversation.

The mechanism itself is mundane in the best sense. ID-JAG is a profile — a specialization, not an invention. It composes three components that have been stable for over a decade: RFC 8693 Token Exchange, RFC 7523 JWT Authorization Grant, and IdP-mediated SSO trust. It wires them into a specific shape for agent-to-application authorization. That shape solves a genuine and sharp problem.

Consider what an autonomous agent actually needs to do to be useful. It must read a mailbox, adjust a calendar, dispatch a notification, and write to a CRM. That is four trust boundaries, crossed in sequence, within seconds. Under the Authorization Code flow, each boundary requires a human in the loop, clicking approve. Under static API keys, no human is needed but the credential is long-lived, unnarrowable, unauditable to a human principal, and catastrophic on leak. Neither works at agent scale. ID-JAG issues short-lived, scope-limited, human-anchored JWTs from an already-established SSO relationship, then exchanges those downstream. The audit chain terminates at a person. That is the whole point.

This is real value. I want to be clear that I think the technical judgment underlying the urgency narrative is correct — ID-JAG addresses the authorization continuity problem, which is the actual bottleneck to agent utility, not model capability. An agent that needs a human to approve every hop is an agent with zero marginal value.

But the correctness of the mechanism is precisely why it will move slowly, and the piece that spawned this conversation misdiagnoses the cause.

The Diagnosis Error: Profile, Not Institution

The OAuth ecosystem has a well-documented pattern. Protocols get built fast. Profiles get validated slowly. This is not institutional sclerosis — it is structural. The correctness of a profile can only be established through multi-vendor deployment, and the IETF does not deploy. Vendors deploy. The IETF ratifies what vendors have already proven.

So when a profile stalls at revision -04, the diagnostic question is not "why is the institution failing?" It is "who is missing from the deployment set?"

Here the numbers thin out fast. Okta is the originating implementer, with the commercial XAA product in general availability on enterprise tiers since August 2026. Descope shipped on October 15 — thirty-eight days before the expiry date, a timing choice that reads as market positioning rather than engineering readiness. That is two implementations. There is no public third-party interoperability test result. None.

The originating piece claims 25+ partners. It lists Anthropic, Cloudflare, Keycloak, and WorkOS. I want to be precise about what that list does and does not mean, because it is doing heavy narrative work with no verification behind it. Anthropic is the demand side — the party manufacturing agents. Cloudflare is infrastructure — the edge that would verify tokens. Keycloak is an open-source implementation. WorkOS is a competitor and complement. These four entities occupy four different positions in the value chain. Flattening them into a single partner count destroys the only information that count could have carried.

And the list is missing the one metric that matters: of the 25+ partners, how many are receivers? An IdP that issues tokens is worthless if downstream applications cannot validate them and map them to local permissions. This is the actual short board in the barrel. The originating piece does not identify it. It counts issuers and calls the ecosystem healthy.

Twenty thousand Okta customers is cited as market proof. That is Okta's installed base, not XAA enablement. I have watched this substitution — installed base traded for adoption — corrupt more on-chain metrics than almost any other single swap. It is the same error as counting wallets that hold a token as users of a protocol.

The Conflict Nobody Wrote Down

Now to the structural fact that the urgency narrative steps around entirely.