Hi all, Cross-posting to wimse@ and spice@: Actor Chain uses workload/actor identity inputs and includes subset-disclosure profiles relevant to selective disclosure.
"Actor Chain" draft version 01 available at: draft-mw-oauth-actor-chain <https://datatracker.ietf.org/doc/draft-mw-oauth-actor-chain/>. It continues the earlier draft-mw-spice-actor-chain <https://datatracker.ietf.org/doc/draft-mw-spice-actor-chain/> work, now scoped as OAuth because it defines RFC 8693 Token Exchange profiles for actor-path continuity in multi-hop service, workload, and agentic workflows. Feedback welcome, especially on the core substrate, disclosure profiles, and what belongs in the core spec versus companion work. Additional technical notes are included below as an aid to reviewers. Thanks, Prasad on behalf of the co-authors ------------------------------ *Additional notes on Actor Chain (draft-mw-oauth-actor-chain <https://datatracker.ietf.org/doc/draft-mw-oauth-actor-chain/>) for reviewers:* *What it is:* RFC 8693 defines Token Exchange and the "act" claim, but leaves append-only actor-path progression, workflow correlation, profile-controlled disclosure, and proof-bound hop continuity unspecified. Actor Chain preserves the RFC 8693 meanings of "sub", "act", and "may_act"; adds profile semantics only when "actp" is present; and keeps ordinary tokens compact. The core claims are "actp" (profile selector), "acti" (workflow instance identifier), RFC 8693 "act" (the disclosed actor path), and "actc" (compact cumulative commitment state in verified profiles). The profiles avoid one-size-fits-all behavior: "declared" means AS-asserted continuity, while "verified" adds actor-signed step proofs and cumulative commitment state, and the disclosure modes are "full" for the full visible actor path, "subset" for an ordered subset selected by the AS for that recipient, and "actor-only" for only the current actor. *What it is not:* Actor Chain keeps the OAuth token deliberately slim and limited to actor-path state, continuity evidence, and receiver acknowledgment. Other data-plane, actor-domain, or deployment-specific information can layer on top or be evaluated by the AS, RS, gateway, or resource-side policy engine. These include authorization policy and decisions, application result provenance, terminal-result evidence, and audit or compliance evidence. *Related work:* draft-ietf-oauth-identity-chaining <https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/> and draft-ietf-oauth-transaction-tokens <https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/> are complementary, providing cross-AS identity and authorization continuity, and transaction/request context, respectively. Our companion SPICE drafts, draft-mw-spice-intent-chain <https://datatracker.ietf.org/doc/draft-mw-spice-intent-chain/> and draft-mw-spice-inference-chain <https://datatracker.ietf.org/doc/draft-mw-spice-inference-chain/>, extend this separation: Intent Chain addresses content and transformation provenance in delegated agent workflows, while Inference Chain addresses computational provenance. draft-liu-oauth-chain-delegation <https://datatracker.ietf.org/doc/draft-liu-oauth-chain-delegation/> addresses delegation records with attestation, optional policy and authorization evidence, while Karl’s draft-mcguinness-oauth-actor-profile <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/> and related work address actor representation and evidence layering. The Liu and McGuinness work could compose with Actor Chain’s Verified Full Disclosure profile, while Actor Chain remains focused on AS-mediated actor-path progression, disclosure, and continuity across successive RFC 8693 exchanges.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
