Hello,
In first place, thank you for taking a look and the feedback
You’re totally right and maybe we didn’t define the example so well, sorry for
that.
Using `urn:ietf:params:oauth:grant-type:jwt-bearer`, the validation is not
there (I mixed my ideas when wrote the email) but the RFC 7521 assumes that you
can control the JWT token used for the assertion and requires some parameters
which are difficult to enforce when you are not the JWT issuer. This draft
proposes a flow that uses external IDP tokens as assertion and in that case,
the JWT token used as assertion is something that you can’t control, for
example, the subject of a GH token is
`repo:{organization}/{repository}:{entity}` and it can’t be modified. Other
case is Kubernetes, where the subject is
`system:serviceaccount:{namespace}:{serviceaccount}`
The first thought could be using the JWT token as client auth, but this
requires that the JWT subject is the client and in case of setting `client_id`,
it must match with the `sub`, so the assertion can’t be used as client auth.
In the other hand, using the assertion as grant, we're in the same case because
the needed info expected as part of the assertion can’t be added in any way. I
mean, it’s true that RFC doesn’t define how to validates the assertion as grant
type, but because of this “openness”, each external IDP has to be supported in
a specific way, checking the issuer or so to define the rules (Github sub is
quite different than Kubernetes sub).
We have also received some drafts from other working groups that fit the user
case we want to cover (this is specifically the one that solves it ->
https://datatracker.ietf.org/doc/draft-levy-wimse-headless-jwt-authentication/01/),
so we can just remove our I-D (we don’t know how to proceed with this tbh, we
are quite newbies).
Thanks a lot for the feedback and sorry for the noise.
Cheers
From: Warren Parad <[email protected]>
Date: Friday, 3 October 2025 at 15:12
To: Jorge Turrado Ferrero <[email protected]>
Cc: [email protected] <[email protected]>,
[email protected]
<[email protected]>
Subject: Re: [OAUTH-WG] New Draft: OAuth 2.0 External Assertion Authorization
Grant
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]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
