Apologies if this is a duplicate. Resending this due to a mailing list subscription issue.
On Fri, May 8, 2026 at 10:19 PM A. Prasad <[email protected]> wrote: > Hi Karl, > > Apologies for the delayed response. > > Thanks for sharing the drafts and the background. The layering point seems > like the right place to focus, especially around where actor representation > ends and where provenance, disclosure, and authorization-specific semantics > should begin. It may be more productive to compare notes in a smaller > discussion. Please let’s follow up off-list with the main areas where you > think comparison or alignment would be most useful, and we can coordinate a > call from there. > > Best, > Prasad > > On Fri, May 1, 2026 at 2:53 PM Karl McGuinness <[email protected]> > wrote: > >> 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 <[email protected]> >> 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: <[email protected]> >>> 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 <[email protected]>, A Prasad < >>> [email protected]>, Ramki Krishnan <[email protected]>, Srinivasa >>> Addepalli <[email protected]> >>> >>> >>> 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 -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
