Re-subjecting across a SaaS boundary is a mint, not an attenuation, so the IdP must issue each onward grant. ID-JAG covers the first hop, where an application holds the user’s ID Token or SAML assertion to exchange. Subsequent hops hold no end-user credential, which leaves a gap: the intermediate has nothing to present to the IdP to continue the chain. The Identity Continuation Assertion fills it. It is a short-lived, sender-constrained JWT, issued by a Chain Authority the IdP trusts, that carries opaque evidence of the in-flight delegation and is presented as the Token Exchange subject token to request an onward ID-JAG. It is evidence, not authority: it carries no subject and grants no access, the IdP resolves the target audience’s subject and re-decides at every hop, and the continuation handle never reaches a Resource Server.
Identity Assertion Trust Framework and Domain-Authorized Issuer Trust Method
Self-service agent sign-up exposes a first-contact trust problem: a Resource Authorization Server can verify a perfectly valid JWT and still not know whether the issuer is allowed to assert identities for the user’s domain. That is two questions, not one. Federation proves the issuer is authentic, but not that the namespace owner authorized it, and static allowlists do not scale to onboarding unknown domains at runtime. The Identity Assertion Trust Framework lets a Resource AS publish the evidence it requires. The Domain-Authorized Issuer Trust Method lets a domain owner publish which issuers may assert identities in its namespace, fail-closed, the way mail and the web already pushed authority into DNS. Both compose with ID-JAG and the JWT-bearer grant without changing the grant surface.
In Cross-App Access, a single signed-in user’s identity has to cross applications that each name them under a different subject. Workload identity proves which service is calling, not which user delegated the work, and offline attenuation can narrow authority it already holds but cannot create a binding to a name it was never given. So crossing a subject namespace is a mint, not an attenuation: only the IdP or broker that owns the mapping can issue new audience-scoped identity evidence, while the destination Authorization Server still applies its own policy and mints the access token. The same shape holds on the authorization axis, where a different scope or policy model forces a non-amplifying re-mint rather than a narrowing. The open question is not whether that mapping authority is in the loop but how it is invoked: caller-pushed continuation, resource-pulled resolution, or another profile that preserves the trust invariant.
WorkOS auth.md is an agent-readable registration document for one-click setup, with Agent Verified, user-claimed, and anonymous paths. In the Agent Verified path, most pieces already exist across OAuth and OpenID standards: ID-JAG, OAuth metadata, dynamic client registration, standard token endpoints, and SSF/CAEP/OPC. The standards gap is a profile for runtime agent onboarding and trust establishment, not a new grant protocol.
Enterprise SaaS still defaults to app-by-app OAuth islands with their own clients, long-lived artifacts, and revocation paths. The architectural shift is OAuth federation: adopt issuer-mediated federation now for services and workloads, and adopt Cross-App Access (XAA) as the standards direction for user-delegated cross-app access.
ID-JAG, also often called Cross-App Access (XAA), is centered in the current draft on Enterprise IdP trust, but the issuer that matters is the immediate IdP the downstream authorization server already trusts for SSO and subject resolution, not necessarily the top-level workforce IdP. The same trust pattern can also extend architecturally to CIAM and platform identity layers that federate upstream workforce login while remaining authoritative for downstream product trust, tenant context, and subject resolution.
Rich Authorization Requests are the natural first instinct for agent missions, but audience-bound access tokens and uneven cross-domain interoperability limit how far they can carry a governed task. Mission-Bound OAuth solves that by making the Mission a durable authority object at the authorization server. This post explores the authentication-layer companion profile: OpenID Connect Client Context carries purpose and approval input when the user is present, and ID-JAG carries reduced Mission projections across same-IdP trust domains.