@techreport{sato-soos-mjwt-06,
    number =    {draft-sato-soos-mjwt-06},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-sato-soos-mjwt/06/},
    author =    {Tom Sato},
    title =     {{The Mandate JWT (MJWT) for Agentic AI Systems}},
    pagetotal = 43,
    year =      2026,
    month =     sep,
    day =       7,
    abstract =  {An AI agent that can act without a verifiable, human-traceable authorization record is an agent without an owner. Existing authorization credentials tell you what an agent is permitted to do; none of them tell you who authorized it, on which specific object, under which mission, or how far that authority can be delegated before it reaches this agent. This document defines the Mandate JWT (MJWT): a WIMSE workload credential profile that binds an AI agent's authority to a specific Sovereign Object instance under a named human principal, with a cryptographically enforced delegation ceiling and an eight-dimensional Narrowing Property that prevents any sub-agent from exceeding the authority of the human principal at the root of the chain. Version -02 adds a seventh narrowing dimension (consent scope), the consent\_scope claim carrying data subject consent state for APPI/GDPR compliance, the sub\_agent\_scope claim for consent attenuation across delegation hops, a Purpose Code Registry, and HEM\_CONSENT\_REQUIRED integration for fail-closed consent enforcement. The MJWT is the authorization primitive referenced by the other SOOS governance drafts. Version -03 corrects an IANA registration issue: the two registries requested there are renamed to drop the redundant word "Registry" from the registry name itself, and each now includes the Designated Expert Guidance that a Specification Required registration policy requires. No new claims, codes, or normative behavior are introduced in -03; this is a registration-format correction only. Version -04 addresses four findings from a WIMSE security review checklist dry-run against -02/-03 (DR-MJWT-KIA-CHECKLIST-01): the parent-mandate check at Cedar-action verification time is tightened from a disjunctive "retrieve or verify" to a mandatory live re-verification of the parent's current signature and revocation status, closing a parent-swap-class window; the Revocation Registry is now stated explicitly to be the same Revocation Registry the KIA draft defines, and the residual cross-instance propagation-lag risk this implies is now named explicitly, mirroring how that draft discloses its own XPID revocation gap; and a new Security Considerations entry states plainly that MJWT does not itself establish or verify a human\_principal\_id's root authority. Version -05 closes gaps surfaced by a WIMSE-style security review pass against -04's own text: an eighth Narrowing Property dimension, max\_delegation\_depth, closes an unbounded-delegation- depth Denial of Service vector that -04's own text named but did not bound; the consent\_reference staleness defense is upgraded from a SHOULD-level recommendation to a MUST, extending the same live-re-verification discipline already applied to parent mandates; and the Introduction's description of RFC 8693 inheritance is corrected to no longer claim use of the optional may\_act claim, which this document does not in fact use. This revision also carries minor idnits and citation-hygiene fixes. Version -06 is an editorial revision with no normative content changes: six sibling-draft citations (HEM, CAP, KIA, MAD, AEP, IDP) had gone stale against those drafts' current live versions and are updated to draft-sato-soos-hem-07, draft-sato-soos-cap-06, draft-sato-soos-kia-06, draft-sato-soos-mad-04, draft-sato-soos-aep-04, and draft-sato-soos-idp-06 respectively.},
}