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

["Thilakasiri H.A.B.D" <[e-mail]>]

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]