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 <[email protected]>
Sent: January 15, 2026 10:37 PM
To: [email protected]
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
[email protected]<mailto:[email protected]>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
