[OAUTH-WG] Re: New submission: draft-mw-oauth-actor-chain-00 — Actor Chains for RFC 8693

[Karl McGuinness <[e-mail]>]

Hi,

I recently published OAuth Actor Profile for Delegation
https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/
which has overlap here.  I also struggled with the scope of a single
document, so I punted many issues to additional profiles and focused this
profile on delegation clarity. client_id identifies the OAuth client
registration, sub identifies the authorizing principal, and act.sub
identifies the actor exercising that authorization.

I also have a very early work in progress om a companion OAuth Actor
Receipts for Delegation Provenance (
https://mcguinness.github.io/draft-mcguinness-oauth-actor-profile/draft-mcguinness-oauth-actor-receipts.html)
spec that pulled over the provenance gap from the core profile. This wasn't
ready for publishing yet so went ahead and just published the core profile
first.

I also explored may_act processing semantics but this introduced more
authorization scope into the spec than necessary, and it felt like it
belonged in a authorization specific profile.

Happy to collaborate here as I think the key challenge is correctly
layering the specs rather than trying to solve everything in 1 spec.   I
anticipate for example that I will need to break out each token profile in
https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/ into
subspecs later.

-Karl


On Fri, May 1, 2026 at 1:57 PM Ramki Krishnan <[e-mail]> wrote:

> Dear Oauth group, Any system that exchanges tokens across more than one
> hop faces the same gap in RFC 8693: prior actors in the chain are
> informational only and delegation-path continuity is undefined. This
> affects service meshes, API gateway tiers, CI/CD pipelines, and zero-trust
> workload deployments — all cases where knowing *who acted, in what order,
> under whose authority* is a correctness or audit requirement, not just
> nice-to-have.
>
> RFC 8693 defines token exchange and the act claim for the current actor.
> It does not define how a delegation path is preserved or validated across a
> sequence of exchanges. That gap has existed since publication. What MCP,
> A2A, and agentic service deployments have done is push multi-hop delegation
> into production at a scale that makes leaving it unstandardized untenable.
>
> draft-mw-oauth-actor-chain-00 closes that gap with six interoperable
> profiles on top of RFC 8693, organized in two branches:
>
>    - *Declared* (AS-asserted chain continuity): Full, Subset, and
>    Actor-Only disclosure — covering deployments where the Authorization Server
>    is the trust anchor for chain integrity.
>    - *Verified* (actor-signed step proofs + cumulative commitment hash):
>    Full, Subset, and Actor-Only — covering deployments where cryptographic
>    auditability of the delegation path is required, independent of AS
>    availability.
>
> All six profiles preserve the existing semantics of sub, act, and may_act.
> Plain RFC 8693 impersonation-shaped outputs remain valid RFC 8693 behavior
> and are outside this profile family. The specification defines a JWT/JWS
> binding; a COSE/CBOR binding is deferred to a future companion.
>
> The draft includes a reference implementation, canonicalization test
> vectors, and end-to-end wire-format examples.
>
> We are seeking WG adoption as a Standards Track document. Feedback is
> particularly welcome on:
>
>    - The two-branch (declared vs. verified) structure and profile
>    boundary conditions
>    - The verified branch security properties — step proofs, commitment
>    chain, cross-domain re-issuance
>    - Whether the six profiles are the right granularity or should be
>    consolidated
>
> Draft: https://datatracker.ietf.org/doc/draft-mw-oauth-actor-chain
>
> Looking forward to your comments and thoughts.
>
>
> Thanks, Ramki (on behalf of the co-authors)
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Fri, May 1, 2026 at 1:42 PM
> Subject: New Version Notification for draft-mw-oauth-actor-chain-00.txt
> To: Diego R. Lopez <[e-mail]>, A Prasad <
> [e-mail]>, Ramki Krishnan <[e-mail]>, Srinivasa
> Addepalli <[e-mail]>
>
>
> A new version of Internet-Draft draft-mw-oauth-actor-chain-00.txt has been
> successfully submitted by ramki krishnan and posted to the
> IETF repository.
>
> Name:     draft-mw-oauth-actor-chain
> Revision: 00
> Title:    Cryptographically Verifiable Actor Chains for OAuth 2.0 Token
> Exchange
> Date:     2026-05-01
> Group:    Individual Submission
> Pages:    97
> URL:
> https://www.ietf.org/archive/id/draft-mw-oauth-actor-chain-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-mw-oauth-actor-chain/
> HTML:
> https://www.ietf.org/archive/id/draft-mw-oauth-actor-chain-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-mw-oauth-actor-chain
>
>
> Abstract:
>
>    Multi-hop service-to-service and agentic workflows need a
>    standardized way to preserve and validate delegation-path continuity
>    across successive token exchanges.  This document defines six actor-
>    chain profiles for OAuth 2.0 Token Exchange [RFC8693].  [RFC8693]
>    permits nested act claims, but prior actors remain informational only
>    and token exchange does not define how a delegation path is preserved
>    and validated across successive exchanges.
>
>    This document profiles delegation-chain tokens and defines profile-
>    specific processing for multi-hop workflows.  The six profiles are:
>    Declared Full Disclosure; Declared Subset Disclosure; Declared Actor-
>    Only Disclosure; Verified Full Disclosure; Verified Subset
>    Disclosure; and Verified Actor-Only Disclosure.
>
>    These profiles preserve the existing meanings of sub, act, and
>    may_act.  They support same-domain and cross-domain delegation and
>    provide different tradeoffs among visible chain-based authorization,
>    cryptographic accountability, auditability, privacy, and long-running
>    workflow support.  Plain RFC 8693 impersonation-shaped outputs remain
>    valid RFC 8693 behavior but are outside this profile family.
>
>
>
> The IETF Secretariat
>
>
>
>
> --
> Thanks,
> Ramki
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>