[OAUTH-WG] Re: Clarification on Nested act Claim Semantics in RFC 8693 Token Exchange

["Lombardo, Jeff" <[e-mail]>]

Hi,

My Canadian 0.02$

From all the past and current discussions I had on the actor claim from RFC 8693 / Token Exchange, all the examples are not normative even if not explicitly stated as such. Therefore, the structure of the actor claim needs to be profiled to suit your needs, a lot of discussion on Agentic AI are in fact requiring this thinking to happen.

Why do I think the examples are not normative?

Section 4.1 states that:

  *   The act (actor) claim provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated.
     *   A means is not a definite, normalized, nor rigid structure
  *   The claims that make up the act claim identify and possibly provide additional information about the actor. For example, the combination of the two claims iss and sub might be necessary to uniquely identify an actor.
     *   Those two sentences express that additional information can exist and that `iss` might be another good one on top of sub. `iss` is not present in any of the examples.
  *   A chain of delegation can be expressed by nesting one act claim within another.
     *   This is not a MUST as per RFC keywords. Therefore, this is not normative. Therefore, it is up to you to decide (maybe profile) what you want.

What could be another valid example in your case?


Original Access Token (subject token received from initial token exchange):

{

  "sub": "37371c22-dc65-47e8-8714-a8d4b54d9fda",

  "client_id": "client-A",

  "act": {

    "sub": "6982ffbf-1ab2-460d-a49f-58a62b03fd80"

  }

}


After Subsequent Token Exchange (the same actor exchanges the token again):

{

  "sub": "37371c22-dc65-47e8-8714-a8d4b54d9fda",

  "client_id": "client-B",

  "act": {

    "sub": "6982ffbf-1ab2-460d-a49f-58a62b03fd80",

    "act": {

      "sub": "6982ffbf-1ab2-460d-a49f-58a62b03fd80",

      "client_id": "client-A"

    }

  }

}

Here adding client_id in the nested actor structure provides an information on the path of the nested delegation and the fact that an actor is a sub through a client.

What to do from here?

As you seek interoperability with other systems / trust domains, submitting a formal profile for Token Exchange would be the way to go. Now, as this actor claim represents a traceability log I am not sure a complete generic convergence can be met on this. I foresee profiling for use cases and domains, but generally saying things like “don’t duplicate the act structure if unchanged” or other guidance of this type sounds like too much overstepping on implementer’s threat modelling and design for mitigations.

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: Thilakasiri H.A.B.D <[e-mail]>
Sent: January 15, 2026 10:37 PM
To: [e-mail]
Subject: [EXT] [OAUTH-WG] Clarification on Nested act Claim Semantics in RFC 8693 Token Exchange


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.


Hi all,


I am writing to seek clarification regarding the semantics and expected behavior of the act (actor) claim in OAuth 2.0 Token Exchange as defined in RFC 8693, particularly in relation to nested delegation chains.


I am implementing OAuth 2.0 Token Exchange (RFC 8693) and have observed that the act claim becomes nested when the same actor performs multiple sequential token exchanges. In our scenario, an actor receives an exchanged token and then the same actor exchanges that same token again (for example, to change the audience or downscope for a downstream service). This results in the same actor identifier appearing multiple times within the nested act claim structure.


Observed Behavior


Original Access Token (subject token received from initial token exchange):

{

  "sub": "37371c22-dc65-47e8-8714-a8d4b54d9fda",

  "client_id": "client-A",

  "act": {

    "sub": "6982ffbf-1ab2-460d-a49f-58a62b03fd80"

  }

}


After Subsequent Token Exchange (the same actor exchanges the token again):

{

  "sub": "37371c22-dc65-47e8-8714-a8d4b54d9fda",

  "client_id": "client-B",

  "act": {

    "sub": "6982ffbf-1ab2-460d-a49f-58a62b03fd80",

    "act": {

      "sub": "6982ffbf-1ab2-460d-a49f-58a62b03fd80"

    }

  }

}


This results in the same actor identifier appearing multiple times in the nested act claim, because each token exchange adds a new layer to the act structure, even though it's the same actor performing the exchanges.


Section 4.1 of RFC 8693 states that "a chain of delegation can be expressed by nesting one act claim within another," but does not explicitly address:

(1) repeated actors in the delegation chain

(2) whether duplicate actors should be preserved or consolidated. Is the intent that authorization servers always preserve the full delegation history, even if redundant and the same actor appears multiple times?


I would like to ensure that my implementation is fully compliant with RFC 8693, interoperable with other OAuth implementations, and aligned with security best practices. Any clarification, guidance, or references to existing implementation notes or discussions would be greatly appreciated. If this area is considered underspecified and could benefit from further clarification in future revisions, I would be happy to contribute to that discussion.


Thank you for your time and for your continued work on OAuth standards.


Kind regards,

Binula

[e-mail]<mailto:[e-mail]>