I agree with the other comments so far. This doesn't seem to be adding anything that you can't already do with RFC7523.
You wrote: > 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. RFC7523 doesn't specify how the JWT was signed. In fact it says "The JWT MUST contain an "iss" (issuer) claim that contains a unique identifier for the entity that issued the JWT." The public key does not need to be pre-registered unless you want it to be. We have implementations of this now where an IdP signs the JWT that is presented as a jwt-bearer grant type, based on https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/ and https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/ I've also had several conversations with people working on similar workload-ish scenarios and guided them towards using the jwt-bearer grant type successfully. Aaron On Fri, Oct 3, 2025 at 6:30 AM Lombardo, Jeff <jeffsec= [email protected]> wrote: > Hi, > > That was an interesting read thanks. I have few questions: > > > - When you said that: > > > *- 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.* > > > > It is not completely accurate against the latest of the Drafts that exist > and are evaluated already by the working group, see > https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/. In > this Draft – Figure 1, from my understanding, the authorization grant JWTis > issued by a trusted 3rd party AS (domain A) to be used at the AS (domain > B). This is highlighted in section 2.1 / (C): > > > > *This requires a trust relationship between the authorization servers in > trust domain A and trust domain B (sometimes called federation, such a > trust relationship typically manifests in the exchange of key material > where domain B's authorization server trusts the public key(s) of domain A > to sign JWT authorization grants).* > > > What would be the differences with the proposal here (introduction of a > new grant type excluded)? > > > > - I fully noted the: > > > > If the request is valid and authorized, the AS issues an access token per > Section 5.1 of [RFC6749]. A refresh token MUST NOT be issued for this grant > type. > > > > But could this be worked out within > https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/ > directly? > > > > Jeff > > > > *Jean-François “Jeff” Lombardo* | Amazon Web Services > > > > Architecte Principal de Solutions, Spécialiste de Sécurité > Principal Solution Architect, Security Specialist > Montréal, Canada > > *Commentaires à propos de notre échange? **Exprimez-vous **ici* > <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$> > *.* > > > > *Thoughts on our interaction? Provide feedback **here* > <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$> > *.* > > > > *From:* Jorge Turrado Ferrero <[email protected]> > *Sent:* October 3, 2025 8:28 AM > *To:* [email protected] > *Cc:* [email protected]; [email protected] > *Subject:* [EXT] [OAUTH-WG] New Draft: OAuth 2.0 External Assertion > Authorization Grant > > > > *CAUTION*: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > *AVERTISSEMENT*: Ce courrier électronique provient d’un expéditeur > externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous > ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas > certain que le contenu ne présente aucun risque. > > > > 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]
