I would say I fundamentally disagree with the "difference from the existing jwt-bearer grant" that you've outlined. There is nothing that would prevent the jwt-bearer grant being used in the scenario you are talking about. The verification of those JWTs is outside of the scope of the RFC, so it already handles the core scenario of crossing trust boundaries.
Even if someone could suggest that the jwt-bearer RFC doesn't handle your scenario, then surely RFC 8693 <https://datatracker.ietf.org/doc/html/rfc8693> does. That one contains explicit expectations for token exchanges generated by one authority for another. As such, there is no need for another standard unless we can outline what exactly cannot be done within the scope of these other RFCs. At the current time, the new draft doesn't include semantics to account for anything new as yet unaccounted for. On Fri, Oct 3, 2025 at 2:30 PM Jorge Turrado Ferrero < [email protected]> wrote: > Hello, > > We submitted > https://datatracker.ietf.org/doc/draft-external-assertion-oauth-grant/ > > This draft introduces a new OAuth 2.0 authorization grant type, > "urn:ietf:params:oauth:grant-type:external-assertion", that allows a client > to obtain an access token from an Authorization Server by presenting a > verifiable assertion issued by a trusted external Identity Provider. > > The motivation is to support zero trust architectures in cloud and server > farm environments, where workloads and applications often authenticate with > different identity providers but must access shared resources under a > common authorization server. Today, each deployment implements its own > bespoke token exchange or local credential system, leading to fragmented > approaches and operational overhead. > > The External Assertion Grant standardizes this flow so that: > > - Workloads can present a JWT assertion from a trusted external IdP. > - Authorization Servers can validate and transform it into a short-lived > access token. > - Access can be consistently enforced without long-lived secrets or > provider-specific hacks. > > A key difference from the existing > "urn:ietf:params:oauth:grant-type:jwt-bearer" grant is the trust model: > - In the jwt-bearer grant, the client presents a JWT it has signed, and > the Authorization Server validates it using a public key that has been > pre-registered or exchanged. > - In the external-assertion grant, the JWT is issued by an external entity > the AS already trusts (for example, a federated IdP). The AS validates it > using that IdP’s keys and trust configuration, not a per-client key > exchange. > > This enables practical zero trust at scale: every request is authenticated > and authorized based on verifiable, short-lived identity tokens, even when > crossing trust boundaries between providers. > > Feedback from the WG is very welcome on scope, validation requirements, > and applicability to real-world multi-cloud and server farm scenarios. > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
