One token, two jobs: ID-JAG in enterprise access and agent registration
The same token type is solving two unrelated problems. Knowing which one you are in decides what you build.
If you have read about ID-JAG twice this year, you may have come away with two mental models that do not fit together.
One goes: an enterprise IdP issues an ID-JAG so an admin can authorize an AI client to reach an MCP server, and nobody sees a consent screen. The other goes: an agent provider issues an ID-JAG so a service can learn who the user behind an agent is and provision them an account.
Both are accurate. They describe different problems, with different issuers, different trust anchors, and different things that go wrong. The token type is the same in both, down to the typ header, which means you cannot tell them apart by inspecting the JWT in isolation.
This post is the side-by-side that neither half of the story usually gets.
What ID-JAG actually is
The Identity Assertion JWT Authorization Grant is defined in draft-ietf-oauth-identity-assertion-authz-grant, currently at revision -04 (21 May 2026), authored by Aaron Parecki, Karl McGuinness, and Brian Campbell. It is an active IETF OAuth working group document, not yet an RFC, and it expires 22 November 2026.
Stripped to its mechanics, it gives you one thing: a way for a party that two other parties already trust to make a short-lived, single-audience, signed statement, which the recipient redeems at a token endpoint for something else. It is not an access token and not an ID token. You cannot send it to an API as a bearer credential.
What the statement says is deliberately not fixed. That openness is why the same grant type ended up carrying two different payloads for two different jobs.
Job one: Authorizing access inside a company
This is Enterprise-Managed Authorization, the MCP extension that reached Stable in June 2026, known as Cross App Access in Okta's implementation of it.
The problem is that inside a company, the user is the wrong person to ask. Whether the engineering team's AI code editor may reach the source control MCP server is an IT decision, not an individual one, and the consent screen is a tax paid dozens of times per employee with no central record of what was granted.
EMA's move is to bring in the IdP that both the client and the server already trust for SSO. The client signs the user in, exchanges the resulting ID token at the IdP for an ID-JAG, and redeems that at your authorization server for an access token. The IdP evaluates admin policy in the middle, and can narrow the granted scopes or refuse outright.
The precondition is load-bearing: the client must have a relying-party relationship with the IdP, and your authorization server must independently trust that same IdP for SSO and subject resolution. If you have no SSO relationship with a customer's IdP, EMA has nothing to stand on for that customer.
For the full flow, the claim set, and the validation rules, see Inside the ID-JAG.
Job two: Establishing who the user is at registration
This is the agent verified flow in auth.md, and the problem it solves sits earlier in the lifecycle.
An agent arrives at your API. There is no account. There may never have been one. Every signup path you have was built to keep automation out: email verification, CAPTCHA, IP heuristics, a browser. The agent has a real person behind it, but no way to prove it.
The observation behind agent verified is that the person is already signed in somewhere. They are signed into Claude, or ChatGPT, or Cursor, at the moment they ask the agent to do something. That platform can attest to who they are.
So the agent asks the user for consent, requests an audience-specific ID-JAG from its provider, and POSTs it to your /agent/identity endpoint. You verify the signature against the provider's JWKS, match or provision the user, and return a service-signed identity_assertion, which the agent then exchanges at /oauth2/token for an access token.
Note the extra hop. EMA redeems the ID-JAG directly for an access token. Registration inserts your own signed artifact in between, because registration has to create or bind a user, and the service wants something of its own bound to that outcome. It also gives you somewhere to return 401 interaction_required when the verified email matches an existing account and you are not willing to bind silently.
The differences that matter
Two questions tell you which world you are in. Does the user already exist in your system? And do you have an SSO relationship with whoever is signing the assertion? EMA answers yes to both. Agent verified registration exists precisely because the answer to both is often no.
Why the claim sets diverge
This is the part worth internalizing, because it explains the split better than any diagram.
An EMA ID-JAG carries an authorization decision. So its claims are about addressing and permission: aud must be your authorization server's issuer identifier, resource names the MCP server per RFC 8707, scope reflects what the admin's policy actually granted rather than what the client asked for, and tenant and aud_tenant disambiguate multi-tenancy on either side.
An agent verified ID-JAG carries an identity attestation. So its claims are about who and how recently: at minimum iss, sub, aud, client_id, jti, iat, exp, auth_time, and at least one verified contact, meaning email_verified or phone_number_verified. You cannot provision a user without a verified contact, and you cannot trust an identity claim of unbounded age, which is why auth_time is required rather than optional and consuming services enforce a max age on it, typically one hour, rejecting stale assertions with 401 login_required.
Same envelope. Different cargo. An authorization decision needs to name the resource and the permissions. An identity attestation needs a verified contact and a freshness guarantee. Neither set makes sense in the other's job.
What this means if you are implementing
Do not build one thing and expect it to cover both.
If your users are employees of companies that run SSO, and the question is whether their AI client may reach your MCP server, you are building EMA. Your work is audience validation, client continuity, subject resolution across tenants, and a documented fallback for when resource is absent.
If agents are arriving at your API with no account, and the question is who is behind them, you are building agent verified registration. Your work is a trust list of providers, JWKS verification, JIT provisioning, a step-up path for when a verified email collides with an existing user, and a receiver for revocation events.
Plenty of services will eventually want both, and they are two integrations, not one.
One honest limitation on the registration side: agent verified only works when the agent's provider participates by minting ID-JAGs. Agents built directly on MCP servers or bare LLM APIs generally cannot. That is why auth.md also defines a user claimed flow, where the agent shows the user a code and the user confirms it in your UI, needing no provider participation at all. If you are picking one to ship first, ship the one that does not depend on somebody else's roadmap.
The thing nobody has solved
Both halves have a revocation story and they are different ones. EMA leans on IdP policy and short token lifetimes. Registration leans on Security Event Tokens pushed from the provider to your events_endpoint, invalidating the registration itself rather than a single credential.
What neither covers is the agent that obtained credentials through one path and then operates in a context governed by the other: registered through its provider, now acting inside a company whose IdP has opinions about it. That seam is where the next round of specification work is going to happen, and it is worth watching if you are building on either side of it.
Sources and further reading
- draft-ietf-oauth-identity-assertion-authz-grant-04, Parecki, McGuinness, Campbell, 21 May 2026
- Inside the ID-JAG: how enterprise-managed authorization actually works
- Cross App Access (XAA): the enterprise way to govern AI app integrations
- Agent registration with auth.md
- auth.md docs: agent verified and for agent providers