MIME-Version: 1.0
References: 
 <177766812746.75245.12094592946228704989@dt-datatracker-cf648cc8f-zwz66>
 <CAKOuegBtN2RbXJj8bp9Pn8pPn2eHNhHq-UBpt1JmSQqmZECz7A@mail.gmail.com>
In-Reply-To: 
 <CAKOuegBtN2RbXJj8bp9Pn8pPn2eHNhHq-UBpt1JmSQqmZECz7A@mail.gmail.com>
From: Karl McGuinness <me@karlmcguinness.com>
Date: Fri, 1 May 2026 14:53:29 -0700
Message-ID: 
 <CAPVrLW3OKejyUfQNopu9w2-3Bz_W6jpg0Ee7MvmzTNQ40D8Z3w@mail.gmail.com>
To: Ramki Krishnan <ramkri123@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000002d36310650c89d7d"
Message-ID-Hash: QSN4PAZTPUBXLVSK6A4OSKTS6ATLPS6U
CC: oauth@ietf.org, "A. Prasad" <ap1729@gmail.com>,
 Diego Lopez <diego.r.lopez@telefonica.com>,
 srini addepalli <addepalli.srinivasa@gmail.com>
Precedence: list
Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_New_submission=3A_draft-mw-oauth-actor-chain-?=
	=?utf-8?q?00_=E2=80=94_Actor_Chains_for_RFC_8693?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/oauth/6VQNYKti4ZzKGDpDJlPhxsp9Qr8>

--0000000000002d36310650c89d7d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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-mcg=
uinness-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=E2=80=AFPM Ramki Krishnan <ramkri123@gmail.com>=
 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-trus=
t
> workload deployments =E2=80=94 all cases where knowing *who acted, in wha=
t 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 delegati=
on
> 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 =E2=80=94 covering deployments where the Authori=
zation Server
>    is the trust anchor for chain integrity.
>    - *Verified* (actor-signed step proofs + cumulative commitment hash):
>    Full, Subset, and Actor-Only =E2=80=94 covering deployments where cryp=
tographic
>    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 behavio=
r
> 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 =E2=80=94 step proofs, commi=
tment
>    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: <internet-drafts@ietf.org>
> Date: Fri, May 1, 2026 at 1:42=E2=80=AFPM
> Subject: New Version Notification for draft-mw-oauth-actor-chain-00.txt
> To: Diego R. Lopez <diego.r.lopez@telefonica.com>, A Prasad <
> a.prasad@oracle.com>, Ramki Krishnan <ramkri123@gmail.com>, Srinivasa
> Addepalli <srinivasa.addepalli@aryaka.com>
>
>
> A new version of Internet-Draft draft-mw-oauth-actor-chain-00.txt has bee=
n
> 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-chai=
n
>
>
> 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 -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>

--0000000000002d36310650c89d7d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div>I recently published OAuth Ac=
tor Profile for Delegation <a href=3D"https://datatracker.ietf.org/doc/draf=
t-mcguinness-oauth-actor-profile/">https://datatracker.ietf.org/doc/draft-m=
cguinness-oauth-actor-profile/</a> which has overlap here.=C2=A0 I also str=
uggled with the scope of a single document, so I punted many issues to addi=
tional=C2=A0profiles and focused this profile on=C2=A0delegation clarity. c=
lient_id identifies the OAuth client registration, sub identifies the autho=
rizing principal, and act.sub identifies the actor exercising that authoriz=
ation.=C2=A0<div><br></div><div>I also have a very early work in progress o=
m a companion OAuth Actor Receipts for Delegation Provenance (<a href=3D"ht=
tps://mcguinness.github.io/draft-mcguinness-oauth-actor-profile/draft-mcgui=
nness-oauth-actor-receipts.html">https://mcguinness.github.io/draft-mcguinn=
ess-oauth-actor-profile/draft-mcguinness-oauth-actor-receipts.html</a>) spe=
c that pulled over the provenance=C2=A0gap from=C2=A0the core profile. This=
 wasn&#39;t ready for publishing yet so went ahead and just published the c=
ore profile first.=C2=A0=C2=A0</div><div><br></div><div>I also explored may=
_act processing=C2=A0semantics but this introduced more authorization scope=
 into the spec than necessary, and it felt like it belonged in a authorizat=
ion specific=C2=A0profile.=C2=A0</div><div><br></div><div>Happy to collabor=
ate=C2=A0here as I think the key challenge is correctly layering the specs =
rather than trying to solve everything in 1 spec.=C2=A0 =C2=A0I anticipate =
for example that I will need to break out each token profile in=C2=A0<a hre=
f=3D"https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/=
">https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/</a=
> into subspecs later.=C2=A0=C2=A0</div><div><br></div><div>-Karl</div><div=
><br></div></div><br><div class=3D"gmail_quote gmail_quote_container"><div =
dir=3D"ltr" class=3D"gmail_attr">On Fri, May 1, 2026 at 1:57=E2=80=AFPM Ram=
ki Krishnan &lt;<a href=3D"mailto:ramkri123@gmail.com">ramkri123@gmail.com<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:&quot;cou=
rier new&quot;,monospace"><div id=3D"m_1462032043979721519gmail-root" style=
=3D"display:flex;max-width:100%;color:rgb(51,51,51);font-family:-apple-syst=
em,BlinkMacSystemFont,&quot;Segoe UI&quot;,Roboto,sans-serif;font-size:13px=
"><div style=3D"display:flex;overflow:hidden;color:rgb(97,97,97);background=
-color:rgb(242,242,242)"><div style=3D"display:flex;overflow:hidden"><div s=
tyle=3D"display:flex;overflow:hidden"><div style=3D"display:flex;overflow:h=
idden"><div style=3D"display:flex;overflow:hidden;line-height:1.5"><div sty=
le=3D"overflow:hidden auto;display:flex;min-width:0px;padding:0px 20px 40px=
;isolation:isolate"><div style=3D"display:flex"><div style=3D"display:flex;=
padding:8px 0px 8px 30px"><span style=3D"overflow-x:hidden;width:439.143px"=
><p style=3D"white-space:pre-wrap;margin-top:0.1em;margin-bottom:0.2em">Dea=
r Oauth group,

Any system that exchanges tokens across more than one hop faces the same ga=
p in RFC 8693: prior actors in the chain are informational only and delegat=
ion-path continuity is undefined. This affects service meshes, API gateway =
tiers, CI/CD pipelines, and zero-trust workload deployments =E2=80=94 all c=
ases where knowing <em>who acted, in what order, under whose authority</em>=
 is a correctness or audit requirement, not just nice-to-have.</p><p style=
=3D"white-space:pre-wrap;margin-top:0.1em;margin-bottom:0.2em">RFC 8693 def=
ines token exchange and the <code style=3D"color:rgb(163,21,21);background-=
color:rgba(0,0,0,0.1);padding:2px 4px;border-radius:3px;word-break:break-wo=
rd;font-size:0.9em">act</code> claim for the current actor. It does not def=
ine how a delegation path is preserved or validated across a sequence of ex=
changes. 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.</p><p style=3D"=
white-space:pre-wrap;margin-top:0.1em;margin-bottom:0.2em">draft-mw-oauth-a=
ctor-chain-00 closes that gap with six interoperable profiles on top of RFC=
 8693, organized in two branches:</p><ul><li><strong>Declared</strong>=C2=
=A0(AS-asserted chain continuity): Full, Subset, and Actor-Only disclosure =
=E2=80=94 covering deployments where the Authorization Server is the trust =
anchor for chain integrity.</li><li><strong>Verified</strong>=C2=A0(actor-s=
igned step proofs + cumulative commitment hash): Full, Subset, and Actor-On=
ly =E2=80=94 covering deployments where cryptographic auditability of the d=
elegation path is required, independent of AS availability.</li></ul><p sty=
le=3D"white-space:pre-wrap;margin-top:0.1em;margin-bottom:0.2em">All six pr=
ofiles preserve the existing semantics of <code style=3D"color:rgb(163,21,2=
1);background-color:rgba(0,0,0,0.1);padding:2px 4px;border-radius:3px;word-=
break:break-word;font-size:0.9em">sub</code>, <code style=3D"color:rgb(163,=
21,21);background-color:rgba(0,0,0,0.1);padding:2px 4px;border-radius:3px;w=
ord-break:break-word;font-size:0.9em">act</code>, and <code style=3D"color:=
rgb(163,21,21);background-color:rgba(0,0,0,0.1);padding:2px 4px;border-radi=
us:3px;word-break:break-word;font-size:0.9em">may_act</code>. Plain RFC 869=
3 impersonation-shaped outputs remain valid RFC 8693 behavior and are outsi=
de this profile family. The specification defines a JWT/JWS binding; a COSE=
/CBOR binding is deferred to a future companion.</p><p style=3D"white-space=
:pre-wrap;margin-top:0.1em;margin-bottom:0.2em">The draft includes a refere=
nce implementation, canonicalization test vectors, and end-to-end wire-form=
at examples.</p><p style=3D"white-space:pre-wrap;margin-top:0.1em;margin-bo=
ttom:0.2em">We are seeking WG adoption as a Standards Track document. Feedb=
ack is particularly welcome on:</p><ul><li>The two-branch (declared vs. ver=
ified) structure and profile boundary conditions</li><li>The verified branc=
h security properties =E2=80=94 step proofs, commitment chain, cross-domain=
 re-issuance</li><li>Whether the six profiles are the right granularity or =
should be consolidated</li></ul><div><span style=3D"white-space:pre-wrap">D=
raft: </span><a href=3D"https://datatracker.ietf.org/doc/draft-mw-oauth-act=
or-chain/" rel=3D"noopener noreferrer" style=3D"color:rgb(0,106,177);white-=
space:pre-wrap;text-decoration:rgb(0,106,177)" target=3D"_blank">https://da=
tatracker.ietf.org/doc/draft-mw-oauth-actor-chain</a><span style=3D"white-s=
pace:pre-wrap">=20
</span><br></div><p style=3D"white-space:pre-wrap;margin-top:0.1em;margin-b=
ottom:0.2em">Looking forward to your comments and thoughts.</p><p style=3D"=
white-space:pre-wrap;margin-top:0.1em;margin-bottom:0.2em"><br></p><p style=
=3D"white-space:pre-wrap;margin-top:0.1em;margin-bottom:0.2em">Thanks, Ramk=
i (on behalf of the co-authors)</p></span></div></div></div></div></div></d=
iv></div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">---------- Forwarded message ---------<br>From: <span =
dir=3D"auto">&lt;<a href=3D"mailto:internet-drafts@ietf.org" target=3D"_bla=
nk">internet-drafts@ietf.org</a>&gt;</span><br>Date: Fri, May 1, 2026 at 1:=
42=E2=80=AFPM<br>Subject: New Version Notification for draft-mw-oauth-actor=
-chain-00.txt<br>To: Diego R. Lopez &lt;<a href=3D"mailto:diego.r.lopez@tel=
efonica.com" target=3D"_blank">diego.r.lopez@telefonica.com</a>&gt;, A Pras=
ad &lt;<a href=3D"mailto:a.prasad@oracle.com" target=3D"_blank">a.prasad@or=
acle.com</a>&gt;, Ramki Krishnan &lt;<a href=3D"mailto:ramkri123@gmail.com"=
 target=3D"_blank">ramkri123@gmail.com</a>&gt;, Srinivasa Addepalli &lt;<a =
href=3D"mailto:srinivasa.addepalli@aryaka.com" target=3D"_blank">srinivasa.=
addepalli@aryaka.com</a>&gt;<br></div><br><br>A new version of Internet-Dra=
ft draft-mw-oauth-actor-chain-00.txt has been<br>
successfully submitted by ramki krishnan and posted to the<br>
IETF repository.<br>
<br>
Name:=C2=A0 =C2=A0 =C2=A0draft-mw-oauth-actor-chain<br>
Revision: 00<br>
Title:=C2=A0 =C2=A0 Cryptographically Verifiable Actor Chains for OAuth 2.0=
 Token Exchange<br>
Date:=C2=A0 =C2=A0 =C2=A02026-05-01<br>
Group:=C2=A0 =C2=A0 Individual Submission<br>
Pages:=C2=A0 =C2=A0 97<br>
URL:=C2=A0 =C2=A0 =C2=A0 <a href=3D"https://www.ietf.org/archive/id/draft-m=
w-oauth-actor-chain-00.txt" rel=3D"noreferrer" target=3D"_blank">https://ww=
w.ietf.org/archive/id/draft-mw-oauth-actor-chain-00.txt</a><br>
Status:=C2=A0 =C2=A0<a href=3D"https://datatracker.ietf.org/doc/draft-mw-oa=
uth-actor-chain/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.=
ietf.org/doc/draft-mw-oauth-actor-chain/</a><br>
HTML:=C2=A0 =C2=A0 =C2=A0<a href=3D"https://www.ietf.org/archive/id/draft-m=
w-oauth-actor-chain-00.html" rel=3D"noreferrer" target=3D"_blank">https://w=
ww.ietf.org/archive/id/draft-mw-oauth-actor-chain-00.html</a><br>
HTMLized: <a href=3D"https://datatracker.ietf.org/doc/html/draft-mw-oauth-a=
ctor-chain" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.o=
rg/doc/html/draft-mw-oauth-actor-chain</a><br>
<br>
<br>
Abstract:<br>
<br>
=C2=A0 =C2=A0Multi-hop service-to-service and agentic workflows need a<br>
=C2=A0 =C2=A0standardized way to preserve and validate delegation-path cont=
inuity<br>
=C2=A0 =C2=A0across successive token exchanges.=C2=A0 This document defines=
 six actor-<br>
=C2=A0 =C2=A0chain profiles for OAuth 2.0 Token Exchange [RFC8693].=C2=A0 [=
RFC8693]<br>
=C2=A0 =C2=A0permits nested act claims, but prior actors remain information=
al only<br>
=C2=A0 =C2=A0and token exchange does not define how a delegation path is pr=
eserved<br>
=C2=A0 =C2=A0and validated across successive exchanges.<br>
<br>
=C2=A0 =C2=A0This document profiles delegation-chain tokens and defines pro=
file-<br>
=C2=A0 =C2=A0specific processing for multi-hop workflows.=C2=A0 The six pro=
files are:<br>
=C2=A0 =C2=A0Declared Full Disclosure; Declared Subset Disclosure; Declared=
 Actor-<br>
=C2=A0 =C2=A0Only Disclosure; Verified Full Disclosure; Verified Subset<br>
=C2=A0 =C2=A0Disclosure; and Verified Actor-Only Disclosure.<br>
<br>
=C2=A0 =C2=A0These profiles preserve the existing meanings of sub, act, and=
<br>
=C2=A0 =C2=A0may_act.=C2=A0 They support same-domain and cross-domain deleg=
ation and<br>
=C2=A0 =C2=A0provide different tradeoffs among visible chain-based authoriz=
ation,<br>
=C2=A0 =C2=A0cryptographic accountability, auditability, privacy, and long-=
running<br>
=C2=A0 =C2=A0workflow support.=C2=A0 Plain RFC 8693 impersonation-shaped ou=
tputs remain<br>
=C2=A0 =C2=A0valid RFC 8693 behavior but are outside this profile family.<b=
r>
<br>
<br>
<br>
The IETF Secretariat<br>
<br>
<br>
</div><div><br clear=3D"all"></div><div><br></div><span class=3D"gmail_sign=
ature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div=
 dir=3D"ltr">Thanks,=C2=A0<div>Ramki<br></div></div></div></div>
_______________________________________________<br>
OAuth mailing list -- <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">o=
auth@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:oauth-leave@ietf.org" tar=
get=3D"_blank">oauth-leave@ietf.org</a><br>
</blockquote></div>

--0000000000002d36310650c89d7d--