Network Working Group T. Sato
Internet-Draft MyAuberge K.K.
Intended status: Standards Track 10 June 2026
Expires: 10 December 2026
The Mandate JWT (MJWT) for Agentic AI Systems
draft-sato-soos-mjwt-01
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 a six-dimensional
Narrowing Property that prevents any sub-agent from exceeding the
authority of the human principal at the root of the chain. The MJWT
is the authorization primitive referenced by [I-D.sato-soos-idp],
[I-D.sato-soos-hem], [I-D.sato-soos-gar], [I-D.sato-soos-cap], and
[I-D.sato-soos-sov].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 10 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction
2. Conventions and Definitions
3. Problem Statement
3.1. The Governance Binding Gap
3.2. Why Existing Credentials Are Insufficient
3.3. Relationship to WIMSE
3.4. Relationship to Mission Bound Authorization
3.5. Relationship to the Actor Profile
3.6. Relationship to RFC 8693 Token Exchange
3.7. Relationship to AAuth
4. The Mandate JWT
4.1. MJWT as a WIMSE Workload Credential Profile
4.2. MJWT Claims
4.2.1. Standard JWT Claims
4.2.2. WIMSE Claims
4.2.3. SOOS Governance Claims
4.3. MJWT JSON Structure
5. The Narrowing Property
5.1. Definition
5.2. Narrowing Dimensions
5.3. GEC Verification of Narrowing
6. Mandate Issuance
6.1. Issuance Authority
6.2. Child Mandate Issuance
6.3. Delegation Chain
7. Mandate Revocation
7.1. Revocation Registry
7.2. Cascade Revocation
7.3. Revocation Event Log Entry
8. GEC Verification Protocol
8.1. Verification Steps
8.2. Verification Failure Deny Codes
9. Mandate Ceiling
9.1. Ceiling Definition
9.2. GEC Ceiling Enforcement
10. Relationship to Other SOOS Drafts
11. Security Considerations
12. Privacy Considerations
13. IANA Considerations
14. References
14.1. Normative References
14.2. Informative References
Appendix A. MJWT Examples
1. Introduction
MJWT is a profile of OAuth 2.0 Token Exchange [RFC8693] extended
with cryptographically enforced delegation chain semantics and
governance binding claims. MJWT inherits RFC 8693's token exchange
security properties -- specifically the subject token / actor token
separation, the may_act delegation grant, and the prohibition on
scope escalation across exchange boundaries. MJWT extends this
model with the Narrowing Property (Section 5): each delegation hop
MUST narrow, never expand, the authority encoded in the parent token
across six dimensions. A child MJWT is always a strict subset of
its parent; no exchange operation may produce a token broader than
the one presented.
MJWT is also a profile of the McGuinness Actor Profile
[I-D.mcguinness-oauth-actor-profile]. The delegation_chain claim
is adopted from that profile without modification. The Actor
Profile defines what an actor is on the wire; the MJWT defines what
that actor is authorized to do on a specific Sovereign Object
instance, under a specific human principal, within a declared
mission context. These profiles are complementary layers, not
competing designs.
The IETF community has made significant progress in specifying how
AI agents authenticate using workload credentials [I-D.ietf-wimse-
arch] and how they obtain authorization tokens for API invocation
[I-D.ietf-oauth-v2-1]. These specifications answer the question:
is this agent permitted to perform actions of type X?
The SOOS governance protocol family -- IDP [I-D.sato-soos-idp], HEM
[I-D.sato-soos-hem], GAR [I-D.sato-soos-gar], and CAP
[I-D.sato-soos-cap] -- requires a richer binding. An agent
governed by SOOS is not merely permitted to perform actions of
type X. It is authorized to perform a specific Cedar action set on
a specific Sovereign Object instance [I-D.sato-soos-sov], under the
oversight of a named human principal, within a declared mission
context, subject to a mandate ceiling that cannot be exceeded by any
child mandate in the delegation chain.
No existing credential type carries this combination of claims.
WIMSE workload credentials provide identity. OAuth access tokens
provide scope. Neither provides Sovereign Object instance binding,
human principal linkage, mission reference, mandate ceiling, or
delegation chain traceability with the Narrowing Property enforced
as a normative invariant.
This document defines the Mandate JWT (MJWT): a WIMSE workload
credential profile [I-D.ietf-wimse-arch] that extends the WIMSE
credential model with governance claims specific to the SOOS
protocol family. The MJWT is the authorization primitive that all
five SOOS governance drafts reference: IDP presents it at each
Transition Request; HEM records it at escalation; GAR includes it
in every Session Audit Record; CAP evaluates it before prohibition
enforcement; and SOV binds it to a Sovereign Object instance.
The mission_ref claim in the MJWT composes directly with Mission
Bound Authorization [I-D.mcguinness-oauth-mission-bound-
authorization]: a mission declared under that framework is
referenceable as the mission_ref in the MJWT, binding per-
transition IDP declarations to the broader mission context under
which the agent is operating.
The design principle of the MJWT is instance specificity: an agent
is not authorized to govern objects of type T in the abstract. It
is authorized to perform Cedar actions A1..An on Sovereign Object
instance Y, in lifecycle phases P1..Pm, while the Sovereign Object's
state machine is in states S1..Sk, under human principal H. That
specificity -- impossible to express with OAuth scopes or general
WIMSE credentials -- is what makes SOOS governance auditable,
revocable, and human-principal-traceable at the instance level.
If you are building an agentic AI system today, the absence of a
governance-bound authorization primitive means that when your agent
delegates authority to a sub-agent, you have no cryptographic proof
of who originally authorized that delegation, no enforceable ceiling
on how far it can be delegated onward, and no instance-specific
binding tying the authorization to the exact resource the agent is
operating on. MJWT closes this gap by carrying the governance
claims that WIMSE and OAuth do not: Sovereign Object instance
binding, human principal linkage, delegation ceiling, and a
Narrowing Property enforced at both issuance and verification.
Without it, every governance protocol in the SOOS stack has a
missing authorization primitive at its core.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the following terms:
Mandate JWT (MJWT):
A WIMSE workload credential profile defined in this document that
binds an AI agent's authorization to a specific Sovereign Object
instance under a named human principal.
Root Mandate:
An MJWT issued directly by a human principal or a GEC acting on
explicit human principal instruction. A Root Mandate has no
parent mandate.
Child Mandate:
An MJWT issued by a GEC on behalf of an agent that itself holds
a valid MJWT (the parent mandate). A Child Mandate MUST satisfy
the Narrowing Property with respect to its parent.
Narrowing Property:
The invariant by which a Child Mandate is always a strict subset
of its parent Mandate in every authorization dimension: Sovereign
Object scope, Cedar action scope, permitted SO states, permitted
lifecycle phases, temporal validity, and mandate ceiling.
Mandate Ceiling:
The maximum authorization level that any mandate in a delegation
chain may grant. Expressed as a conformance level integer (1, 2,
or 3) corresponding to the GEC conformance levels defined in
[I-D.sato-soos-idp] Section 9.
Delegation Chain:
The ordered sequence of mandate issuance events from the Root
Mandate to the current MJWT, as recorded in the delegation_chain
claim.
Revocation Registry:
A GEC-maintained store of revoked mandate jti values and their
cascade revocation trees.
Sovereign Object (SO):
As defined in [I-D.sato-soos-sov]: a causally ordered, policy-
governed, typed, living document that evolves through a predefined
finite state space under GEC authority.
Governing Enforcement Component (GEC):
As defined in [I-D.sato-soos-idp]: a runtime component that
enforces authorization policy, records agent actions to a tamper-
evident Event Log, and mediates agent access to governed objects.
Cedar:
A policy language and evaluation engine [Cedar] used by the GEC
to evaluate authorization decisions.
Human Principal:
A natural person who holds authority over an SO Instance and whose
identifier appears in the MJWT human_principal_id claim.
Mission Reference:
A UUID identifying a MissionDeclaration as defined in
[I-D.mcguinness-oauth-mission-bound-authorization] under which
the agent is operating.
3. Problem Statement
3.1. The Governance Binding Gap
The SOOS governance protocol family requires that every agent action
be traceable to:
(a) A specific human principal who authorized the agent's mandate.
(b) A specific Sovereign Object instance the agent is bound to.
(c) A specific Cedar action set the agent is permitted to execute.
(d) A specific mission context under which the agent is operating.
(e) A mandate issuance chain from the authorizing human principal
through every intermediate delegation step.
(f) A mandate ceiling that no child mandate may exceed.
No existing credential standard provides all six properties in a
single verifiable token. This gap means that the four live SOOS
drafts -- IDP, HEM, GAR, and CAP -- each reference a Mandate JWT
as the authorization primitive without a normative specification
of what that JWT must contain. This document fills that gap.
3.2. Why Existing Credentials Are Insufficient
OAuth 2.1 access tokens [I-D.ietf-oauth-v2-1] provide scope-based
authorization. They do not provide Sovereign Object instance
binding, human principal identification, mission reference, mandate
ceiling, or Narrowing Property enforcement. An OAuth scope of
"booking:write" authorizes an agent to perform booking write
operations in general; it does not authorize a specific agent to
perform Cedar action "atp:booking:confirm" on SO instance
"019547ab-..." under human principal "hp-001".
WIMSE workload credentials [I-D.ietf-wimse-arch] provide workload
identity. They authenticate the agent as a specific workload but
do not carry the governance claims required by SOOS: SO binding,
Cedar action scope, human principal linkage, or mandate ceiling.
The MJWT is a WIMSE profile -- it extends WIMSE credentials with
these governance claims, not replaces them.
The McGuinness Actor Profile [I-D.mcguinness-oauth-actor-profile]
provides delegation chain traceability. The MJWT adopts the
delegation_chain claim directly and extends it with SO binding and
SOOS governance claims. The Actor Profile and the MJWT are
complementary, not competing.
3.3. Relationship to WIMSE
The MJWT is a WIMSE workload credential profile. It extends the
WIMSE credential model [I-D.ietf-wimse-arch] by adding governance
claims specific to the SOOS protocol family.
A WIMSE-conforming verifier that does not understand MJWT-specific
claims MUST treat those claims as unrecognized and MUST NOT fail
verification solely because of their presence, consistent with JWT
processing rules [RFC7519]. A GEC verifying an MJWT MUST process
all SOOS governance claims as specified in Section 8.
The MJWT is intended as a candidate for submission to the WIMSE
working group as an AI agent governance profile. The June 2026
WIMSE interim discussion of draft-klrc-aiagent-auth identified
governance binding as a gap in existing AI agent authentication
proposals. The MJWT addresses that gap.
3.4. Relationship to Mission Bound Authorization
Mission Bound Authorization [I-D.mcguinness-oauth-mission-bound-
authorization] defines a framework for binding agent authorization
to a declared mission context. The MJWT mission_ref claim carries
a MissionDeclaration UUID from that framework.
When mission_ref is present in an MJWT, the IDP mission_ref field
[I-D.sato-soos-idp] Section 4.1 MUST match the MJWT mission_ref
at every Transition Request. This binding ensures that per-
transition intent declarations are traceable to the broader mission
context, enabling Cedar policies to distinguish between on-mission
and off-mission agent actions.
The MJWT thus serves as the token-level bridge between Mission Bound
Authorization (the mission declaration framework) and IDP (the per-
transition intent declaration).
3.5. Relationship to the Actor Profile
The McGuinness Actor Profile [I-D.mcguinness-oauth-actor-profile]
defines the delegation_chain claim for recording the sequence of
principals in an authorization delegation. The MJWT adopts this
claim without modification.
In the MJWT, the delegation_chain records the mandate issuance
history from the Root Mandate's human principal through each
intermediate sub-agent delegation to the current mandate holder.
This chain enables the GEC, human principals, and Verified External
Auditors to trace any agent action back to the originating human
authorization -- a requirement for EU AI Act Article 12 compliance
[EUAIA] and for the accountability property that SOOS is designed
to provide.
The Actor Profile defines a sub_profile claim as an entity-type tag
on the actor: end_user, service_account, ai_agent, or workload.
This claim enables resource servers to perform deterministic cross-
domain policy evaluation on actor type without bespoke discovery.
MJWT agents are ai_agent sub-profile entities in the Actor Profile
vocabulary.
Implementations that expose MJWT-governed agents through OAuth
interfaces SHOULD declare sub_profile: "ai_agent" in the Actor
Profile act claim to enable cross-domain policy evaluation at
resource servers that consume the Actor Profile but do not implement
the full SOOS MJWT verification protocol. This is the correct
interoperability bridge between the OAuth layer and the SOOS
governance layer: Actor Profile handles the wire-format identity;
MJWT handles the governance binding.
3.6. Relationship to RFC 8693 Token Exchange
RFC 8693 [RFC8693] defines OAuth 2.0 Token Exchange: a mechanism
by which a client presents a subject token and receives a new token
with a different scope, audience, or type. Token Exchange addresses
the exchange event -- the moment when one token is traded for
another at an authorization server. It does not define what the
resulting token carries beyond standard OAuth claims, and it does
not specify the relationship between successive tokens in a
delegation chain.
MJWT is an RFC 8693 profile in the following sense: the MJWT
issuance event (Section 6) is a token exchange -- a parent mandate
is presented and a child mandate is issued. MJWT extends this
exchange with two properties RFC 8693 does not provide:
First, the Narrowing Property (Section 5): RFC 8693 prohibits scope
escalation at a single exchange step (scope in the issued token MUST
NOT exceed the scope of the subject token). MJWT extends this
prohibition across all six authorization dimensions and enforces it
at both issuance and verification, creating a transitive narrowing
invariant across the entire delegation chain.
Second, governance binding: RFC 8693 produces a general-purpose
token. MJWT produces a token bound to a specific Sovereign Object
instance, a named human principal, a Cedar action scope, and a
declared mission. This binding is what makes the SOOS governance
stack auditable at the instance level rather than at the type level.
RFC 8693 and MJWT compose cleanly: MJWT issuance events MAY be
implemented as Token Exchange requests at a GEC acting as an
authorization server. The GEC is the issuing authority in both
framings.
3.7. Relationship to AAuth
AAuth [I-D.hardt-aauth-protocol] takes a clean-sheet approach to
agent authorization: signed-request-first, no client secret, with
Mission as a first-class field in every authorization request.
AAuth and MJWT address different layers of the same problem.
AAuth's Mission field is a structured statement of what the agent
is trying to do, evaluable by the resource server at the time of
each request. The MJWT mission_ref claim (Section 4.2.3) carries
a UUID reference to a MissionDeclaration as defined in Mission Bound
Authorization [I-D.mcguinness-oauth-mission-bound-authorization].
Both designs recognize mission context as a first-class
authorization input; they differ in representation (inline
structured object vs. UUID reference to a pre-declared mission) and
in scope (AAuth addresses the resource server interaction; MJWT
addresses the governance kernel binding).
MJWT does not require AAuth. MJWT-governed agents MAY present
their MJWT to AAuth-native resources by mapping mission_ref to the
AAuth Mission field, though this mapping is outside the scope of
this document.
4. The Mandate JWT
4.1. MJWT as a WIMSE Workload Credential Profile
The MJWT is a JSON Web Token [RFC7519] that conforms to the WIMSE
workload credential model [I-D.ietf-wimse-arch] and extends it with
SOOS governance claims. The MJWT MUST be signed using the Ed25519
algorithm [RFC8037].
The MJWT is presented by an agent to the GEC as part of every
Transition Request, alongside an IDP [I-D.sato-soos-idp]. The GEC
MUST verify the MJWT before evaluating Cedar policy. The
verification protocol is specified in Section 8.
4.2. MJWT Claims
4.2.1. Standard JWT Claims
iss (Issuer):
REQUIRED. The identifier of the GEC or human principal that
issued this MJWT. For Root Mandates, this is the human
principal's identifier. For Child Mandates, this is the
issuing GEC's identifier.
sub (Subject):
REQUIRED. The identifier of the agent holding this MJWT.
MUST be a WIMSE workload identifier [I-D.ietf-wimse-arch].
jti (JWT ID):
REQUIRED. A UUID v7 [RFC9562] uniquely identifying this MJWT
instance. The jti is the mandate_id referenced by IDP
[I-D.sato-soos-idp] Section 4.1 and GAR [I-D.sato-soos-gar].
UUID v7 is required for its time-ordered property, which enables
chronological mandate issuance queries without additional indexing.
iat (Issued At):
REQUIRED. The time at which this MJWT was issued.
exp (Expiration Time):
REQUIRED. The time after which this MJWT MUST NOT be accepted.
For Child Mandates, exp MUST NOT be later than the parent
mandate's exp claim. This is a dimension of the Narrowing
Property (Section 5).
nbf (Not Before):
OPTIONAL. The time before which this MJWT MUST NOT be accepted.
aud (Audience):
REQUIRED. The identifier of the GEC instance for which this
MJWT is intended. MUST be the KIA-attested instance identifier
of the specific GEC that will verify this MJWT, as defined in
[I-D.sato-soos-kia] Section 5.2 (the kernel_keypair_fingerprint
field of the GEC Manifest). For multi-GEC deployments where a
cluster identifier is applicable, aud MUST identify the specific
GEC instance, not the cluster; cluster-level audience binding
MUST use the gec_cluster_id governance claim (Section 4.2.3).
A GEC MUST reject any MJWT whose aud value does not exactly match
its own KIA-attested instance identifier. Cross-GEC token use is
prohibited unless explicitly authorized through the MAD delegation
protocol [I-D.sato-soos-mad].
The aud claim is the primary defense against cross-GEC replay
attacks, as described in Section 11 (Security Considerations).
4.2.2. WIMSE Claims
The MJWT inherits the following WIMSE claims as defined in
[I-D.ietf-wimse-arch]:
wid (Workload Identifier):
REQUIRED. The WIMSE workload identifier of the agent.
cnf (Confirmation):
REQUIRED. The proof-of-possession key confirmation claim
[RFC7800]. The agent MUST demonstrate possession of the
corresponding private key when presenting the MJWT.
4.2.3. SOOS Governance Claims
The following claims are defined by this document and constitute
the SOOS governance extension to the WIMSE credential model.
so_id:
REQUIRED. The UUID v7 identifier of the Sovereign Object
instance this MJWT binds the agent to, as defined in
[I-D.sato-soos-sov] Section 4.2.1. The GEC MUST verify that
the so_id in the MJWT matches the SO Instance targeted by the
Transition Request.
so_type_id:
REQUIRED. The SO Type identifier of the bound Sovereign Object
instance. MUST match the so_type_id in the SO Instance's
Identity Layer [I-D.sato-soos-sov].
human_principal_id:
REQUIRED. The identifier of the human principal under whose
authority this MJWT was issued. For Root Mandates, this is
the identifier of the natural person who directly authorized
the agent. For Child Mandates, this MUST be the same
human_principal_id as the parent mandate -- the human principal
of the root of the delegation chain does not change through
sub-agent issuance.
The GEC MUST verify that the human_principal_id in the MJWT
matches the human_principal_id in the SO Instance's Identity
Layer [I-D.sato-soos-sov] Section 4.2.1.
cedar_actions:
REQUIRED. A JSON array of Cedar action strings that this MJWT
authorizes the agent to request. The GEC MUST reject Transition
Requests for Cedar actions not present in this array.
For Child Mandates, cedar_actions MUST be a subset of the parent
mandate's cedar_actions. This is a dimension of the Narrowing
Property (Section 5).
permitted_states:
OPTIONAL. A JSON array of SO state strings (as declared in the
SO Type's state machine) in which the authorized cedar_actions
may be performed. If absent, the cedar_actions are permitted in
all states declared in the SO Type. For Child Mandates, if
present, this array MUST be a subset of the parent mandate's
permitted_states.
permitted_phases:
OPTIONAL. A JSON array of SO lifecycle phase strings in which
the authorized cedar_actions may be performed. If absent, the
cedar_actions are permitted in all lifecycle phases. For Child
Mandates, if present, this array MUST be a subset of the parent
mandate's permitted_phases.
mandate_ceiling:
REQUIRED. An integer (1, 2, or 3) specifying the maximum GEC
conformance level at which this MJWT and any child mandates
derived from it may be honored. The GEC MUST reject MJWTs
with a mandate_ceiling below its own conformance level. See
Section 9 for ceiling enforcement rules.
parent_mandate_id:
REQUIRED for Child Mandates; MUST be absent for Root Mandates.
The jti of the parent MJWT from which this Child Mandate was
derived. Enables the GEC to retrieve and verify the parent
mandate for Narrowing Property verification.
delegation_chain:
OPTIONAL; REQUIRED when parent_mandate_id is present. The
delegation chain as defined by [I-D.mcguinness-oauth-actor-
profile]. Each entry in the chain records one issuance step:
the issuing principal, the receiving agent, the issued jti,
and the issuance timestamp. The chain enables complete
traceability from any Child Mandate back to the originating
human principal without requiring the verifier to retrieve
intermediate mandates.
mission_ref:
OPTIONAL. A UUID identifying a MissionDeclaration as defined
in [I-D.mcguinness-oauth-mission-bound-authorization]. When
present, the IDP mission_ref field [I-D.sato-soos-idp]
Section 4.1 MUST match this value at every Transition Request.
The GEC MUST reject Transition Requests where mission_ref is
present in the MJWT but absent or mismatched in the IDP.
zone_b_read:
OPTIONAL. Boolean. If true, this MJWT authorizes the agent
to read Zone B content from the bound SO Instance, subject to
Cedar policy evaluation [I-D.sato-soos-sov] Section 7.2.
Default: false.
zone_b_write:
OPTIONAL. Boolean. If true, this MJWT authorizes the agent
to attach Zone B content to the bound SO Instance, subject to
Cedar policy evaluation. Default: false.
gec_cluster_id:
OPTIONAL. String. When present, identifies the GEC cluster
to which this MJWT is scoped in a multi-GEC deployment. The
aud claim identifies the specific GEC instance; gec_cluster_id
provides the cluster-level audience binding for cluster-aware
policy evaluation. Absent for single-GEC deployments.
4.3. MJWT JSON Structure
The following is the normative JSON structure of an MJWT. Fields
marked REQUIRED MUST be present. Fields marked OPTIONAL MAY be
omitted.
{
"iss": string, ; REQUIRED. Issuer identifier.
"sub": string, ; REQUIRED. WIMSE workload ID.
"jti": string, ; REQUIRED. UUID v7. mandate_id.
"iat": integer, ; REQUIRED. NumericDate.
"exp": integer, ; REQUIRED. NumericDate.
"nbf": integer, ; OPTIONAL. NumericDate.
"aud": string, ; REQUIRED. KIA-attested GEC instance ID.
"wid": string, ; REQUIRED. WIMSE workload ID.
"cnf": { ; REQUIRED. PoP key confirmation.
"jwk": { ... } ; Ed25519 public key [RFC8037].
},
"so_id": string, ; REQUIRED. SO Instance UUID v7.
"so_type_id": string, ; REQUIRED. SO Type identifier.
"human_principal_id": string, ; REQUIRED. Human principal ID.
"cedar_actions": [string], ; REQUIRED. Authorized actions.
"permitted_states": [string], ; OPTIONAL. Permitted SO states.
"permitted_phases": [string], ; OPTIONAL. Permitted SO phases.
"mandate_ceiling": integer, ; REQUIRED. 1, 2, or 3.
"parent_mandate_id": string, ; REQUIRED if child mandate.
"delegation_chain": [object], ; REQUIRED if child mandate.
"mission_ref": string, ; OPTIONAL. Mission UUID.
"zone_b_read": boolean, ; OPTIONAL. Default false.
"zone_b_write": boolean, ; OPTIONAL. Default false.
"gec_cluster_id": string ; OPTIONAL. GEC cluster identifier.
}
The MJWT MUST be signed using Ed25519 [RFC8037]. The JOSE header
MUST include:
{
"alg": "EdDSA",
"kid": "<key identifier of the issuer's signing key>"
}
5. The Narrowing Property
5.1. Definition
The Narrowing Property is a normative invariant of the MJWT
delegation model. A Child Mandate MUST be a strict subset of its
parent Mandate in every authorization dimension. A Child Mandate
MUST NOT grant any authority that its parent Mandate does not itself
hold.
The Narrowing Property is what gives SOOS delegation its security
guarantee: no sub-agent in a delegation chain can exceed the
authority of the human principal at the root of that chain.
5.2. Narrowing Dimensions
The Narrowing Property applies across six dimensions:
(a) Sovereign Object scope. A Child Mandate's so_id MUST reference
the same SO Instance as its parent. A Child Mandate MUST NOT
reference an SO Instance not covered by its parent.
(b) Cedar action scope. A Child Mandate's cedar_actions array MUST
be a subset of its parent's cedar_actions array. The GEC MUST
reject a Child Mandate that contains any Cedar action not present
in the parent mandate's cedar_actions.
(c) Permitted SO states. If a Child Mandate declares
permitted_states, that array MUST be a subset of the parent's
permitted_states. If the parent mandate does not declare
permitted_states (implying all states are permitted), the child
may declare any permitted_states subset.
(d) Permitted lifecycle phases. If a Child Mandate declares
permitted_phases, that array MUST be a subset of the parent's
permitted_phases. If the parent does not declare
permitted_phases, the child may declare any subset.
(e) Temporal validity. A Child Mandate's exp claim MUST NOT be
later than its parent's exp claim. The GEC MUST reject a Child
Mandate whose exp exceeds the parent's exp.
(f) Mandate ceiling. A Child Mandate's mandate_ceiling MUST NOT
exceed its parent's mandate_ceiling. A Root Mandate establishes
the maximum ceiling for the entire delegation tree.
5.3. GEC Verification of Narrowing
The GEC MUST verify the Narrowing Property whenever a Child Mandate
is presented. Verification requires retrieving or caching the
parent mandate identified by parent_mandate_id.
If the parent mandate has been revoked (Section 7), the GEC MUST
treat the Child Mandate as invalid regardless of the Child Mandate's
own revocation status.
Narrowing Property violations MUST result in a NARROWING_VIOLATION
deny code in the GEC DENY response [I-D.sato-soos-idp] Section 6.
The violation MUST be recorded in the SO Instance Event Stream as
a MANDATE_NARROWING_VIOLATION entry.
The delegation_chain claim (Section 4.2.3) MAY be used by the GEC
to verify the full chain without retrieving each intermediate
mandate individually, provided the chain entries are signed by the
GEC that issued each step.
6. Mandate Issuance
6.1. Issuance Authority
Root Mandates MUST be issued by a human principal or by a GEC
acting on explicit, recorded human principal instruction. The
issuance event MUST generate a MANDATE_BOUND entry in the SO
Instance Event Stream [I-D.sato-soos-sov] Section 4.2.3.
A GEC MUST NOT issue a Root Mandate autonomously. Any MJWT that
does not carry a parent_mandate_id and was not issued pursuant to
recorded human principal instruction MUST be treated as invalid.
6.2. Child Mandate Issuance
A Child Mandate is issued by a GEC on behalf of an agent that
itself holds a valid, non-revoked MJWT (the parent mandate). The
issuing GEC MUST:
(a) Verify that the parent mandate is valid and non-revoked.
(b) Verify that the requested Child Mandate satisfies the Narrowing
Property in all six dimensions (Section 5.2).
(c) Set parent_mandate_id to the jti of the parent mandate.
(d) Extend the delegation_chain with a new entry recording this
issuance step.
(e) Set human_principal_id to the same value as the parent mandate's
human_principal_id.
(f) Set aud to the KIA-attested instance identifier of the GEC that
will verify this Child Mandate, retrieved from that GEC's current
GEC Manifest [I-D.sato-soos-kia] Section 5.2.
(g) Generate a MANDATE_BOUND Event Stream entry for the SO Instance.
(h) Sign the Child Mandate with the GEC's Ed25519 signing key.
The GEC MUST NOT issue a Child Mandate that violates the Narrowing
Property. An issuance request that would violate Narrowing MUST
be rejected with a NARROWING_VIOLATION response and MUST be recorded
in the Event Stream.
6.3. Delegation Chain
The delegation_chain claim records the mandate issuance history as
defined by [I-D.mcguinness-oauth-actor-profile]. Each entry in
the chain MUST contain:
issuer_id:
The identifier of the principal (human or GEC) that issued this
mandate step.
recipient_id:
The WIMSE workload identifier of the agent that received this
mandate step.
mandate_jti:
The jti of the MJWT issued at this step.
issued_at:
ISO 8601 timestamp of issuance.
gec_signature:
The Ed25519 signature of the issuing GEC over this chain entry.
For the Root Mandate step (issued by a human principal), this
field carries the human principal's signing key signature if
available, or is marked as human_issued.
The delegation_chain enables a verifier to reconstruct the complete
authorization lineage without retrieving each intermediate MJWT,
provided each chain entry's gec_signature is valid.
7. Mandate Revocation
7.1. Revocation Registry
The GEC MUST maintain a Revocation Registry: a persistent store of
revoked mandate jti values and their associated cascade revocation
trees.
The Revocation Registry MUST be queryable by jti. A query response
MUST indicate:
(a) Whether the queried jti is directly revoked.
(b) Whether the queried jti is cascade-revoked (its parent or an
ancestor has been revoked).
(c) The revocation timestamp.
(d) The jti of the directly revoked ancestor, if cascade-revoked.
The GEC MUST check the Revocation Registry before accepting any
MJWT at a Transition Request. A revoked or cascade-revoked MJWT
MUST result in a MANDATE_REVOKED deny code.
7.2. Cascade Revocation
Revoking a mandate automatically revokes all Child Mandates derived
from it. This is the cascade revocation property.
When a mandate is revoked, the GEC MUST:
(a) Record the jti in the Revocation Registry as directly revoked.
(b) Traverse the mandate issuance tree rooted at the revoked jti
and mark all descendant jtis as cascade-revoked.
(c) Generate a MANDATE_REVOKED Event Stream entry for each revoked
mandate, recording the jti, the revocation reason, the revoking
principal, and the revocation timestamp.
(d) If any revoked mandate is currently bound to an active GEC
session, the GEC MUST immediately enter HEM_PENDING and route
a TERMINATE escalation [I-D.sato-soos-hem] Section 8.4 for
that session.
Cascade revocation MUST be propagated within the trust domain in
which the mandate was issued. Cross-domain cascade revocation
semantics are outside the scope of this document.
7.3. Revocation Event Log Entry
Every revocation event MUST generate a MANDATE_REVOKED entry in the
SO Instance Event Stream with the following fields:
{
"event_type": "MANDATE_REVOKED",
"revoked_jti": string, ; jti of the revoked mandate.
"revocation_type": string, ; "DIRECT" or "CASCADE".
"cascade_root_jti": string, ; jti of directly revoked ancestor
; if revocation_type is "CASCADE".
"revocation_reason": string, ; Human-readable reason.
"revoking_principal": string, ; ID of revoking human principal.
"revoked_at": string ; ISO 8601 timestamp.
}
8. GEC Verification Protocol
8.1. Verification Steps
On receiving a Transition Request carrying an MJWT, the GEC MUST
perform the following verification steps in order before proceeding
to Cedar policy evaluation. Failure at any step MUST result in an
immediate DENY response with the appropriate deny code (Section 8.2).
The DENY MUST be recorded in the SO Instance Event Stream.
Step 1 -- Audience binding.
Verify that the MJWT's aud claim exactly matches the verifying
GEC's KIA-attested instance identifier. An MJWT whose aud does
not match MUST be rejected immediately, before signature
verification. This ordering is intentional: verifying audience
binding before signature verification prevents a verifier from
expending cryptographic resources on tokens not intended for it,
and prevents timing side-channels from leaking signature validity
information for tokens intended for other GEC instances.
Step 2 -- Signature verification.
Verify the MJWT's Ed25519 signature using the issuer's public
key. The issuer's public key MUST be retrieved from the GEC's
trusted key store or from the WIMSE trust anchor for the issuing
workload.
Step 3 -- Temporal validity.
Verify that the current time is after nbf (if present) and
before exp. An expired MJWT MUST be rejected.
Step 4 -- Revocation check.
Query the Revocation Registry for the MJWT's jti. A directly
revoked or cascade-revoked MJWT MUST be rejected.
Step 5 -- SO Instance binding.
Verify that the MJWT's so_id matches the SO Instance targeted
by the Transition Request. Verify that the MJWT's so_type_id
matches the SO Instance's so_type_id.
Step 6 -- Human principal linkage.
Verify that the MJWT's human_principal_id matches the
human_principal_id in the SO Instance's Identity Layer
[I-D.sato-soos-sov] Section 4.2.1.
Step 7 -- Mandate ceiling.
Verify that the MJWT's mandate_ceiling is greater than or equal
to the GEC's conformance level. A mandate ceiling below the
GEC's conformance level MUST be rejected.
Step 8 -- Narrowing Property (Child Mandates only).
If parent_mandate_id is present, retrieve or verify the parent
mandate and verify the Narrowing Property in all six dimensions
(Section 5.2).
Step 9 -- Cedar action scope.
Verify that the cedar_action in the Transition Request is present
in the MJWT's cedar_actions array.
Step 10 -- State and phase restrictions.
If permitted_states is present, verify that the SO Instance's
current_state is in the permitted_states array. If
permitted_phases is present, verify that the SO Instance's
current_phase is in the permitted_phases array.
Step 11 -- Mission reference (if present).
If the MJWT carries mission_ref, verify that the IDP submitted
with this Transition Request also carries mission_ref and that
the values match.
All eleven steps MUST pass before the GEC proceeds to Cedar policy
evaluation.
8.2. Verification Failure Deny Codes
The following deny codes are defined for MJWT verification failures.
These codes are returned in the GEC DENY response as defined in
[I-D.sato-soos-idp] Section 6.
Deny Code | Step | Condition
---------------------------+------+--------------------------------
MJWT_AUD_MISMATCH | 1 | aud does not match GEC instance ID.
MJWT_SIGNATURE_INVALID | 2 | Ed25519 signature invalid.
MJWT_EXPIRED | 3 | Current time after exp.
MJWT_NOT_YET_VALID | 3 | Current time before nbf.
MANDATE_REVOKED | 4 | jti directly or cascade revoked.
MJWT_SO_MISMATCH | 5 | so_id mismatch.
MJWT_SO_TYPE_MISMATCH | 5 | so_type_id mismatch.
MJWT_PRINCIPAL_MISMATCH | 6 | human_principal_id mismatch.
MJWT_CEILING_INSUFFICIENT | 7 | mandate_ceiling below GEC level.
NARROWING_VIOLATION | 8 | Narrowing Property violated.
MANDATE_SCOPE | 9 | cedar_action not in scope.
MJWT_STATE_RESTRICTED | 10 | SO state not in permitted_states.
MJWT_PHASE_RESTRICTED | 10 | SO phase not in permitted_phases.
MJWT_MISSION_REF_MISMATCH | 11 | mission_ref mismatch with IDP.
9. Mandate Ceiling
9.1. Ceiling Definition
The mandate_ceiling claim specifies the maximum GEC conformance
level at which this MJWT and any Child Mandate derived from it
may be honored. The ceiling values correspond to the conformance
levels defined in [I-D.sato-soos-idp] Section 9:
Ceiling Value | GEC Level | Description
---------------+-----------+----------------------------------
1 | Level 1 | Application Profile. GEC as SDK.
2 | Level 2 | Isolated Profile. GEC as sidecar.
3 | Level 3 | Kernel Profile. RATS-attested TEE.
A mandate_ceiling of 2 means this MJWT and all Child Mandates
derived from it MAY be honored by a Level 1 or Level 2 GEC, but
MUST NOT be honored by a Level 3 GEC. This ceiling prevents a
mandate issued in a lower-assurance context from being used to
authorize actions in a higher-assurance enforcement environment.
The ATP Foundation has closed decision TI-2 specifying that the
mandate ceiling for the ATP reference implementation is Level 2.
No mandate issued in the ATP Booking Object governance context
may be honored by a Level 3 (hardware-attested) GEC without
explicit human principal re-authorization at Level 3.
9.2. GEC Ceiling Enforcement
The GEC MUST enforce the mandate ceiling at Step 7 of the
verification protocol (Section 8.1).
A Level 3 GEC MUST reject any MJWT with mandate_ceiling < 3.
A Level 2 GEC MUST reject any MJWT with mandate_ceiling < 2.
A Level 1 GEC accepts MJWTs with any mandate_ceiling value.
When a mandate_ceiling violation is detected, the GEC MUST return
a MJWT_CEILING_INSUFFICIENT deny code and MUST record the event
in the SO Instance Event Stream.
10. Relationship to Other SOOS Drafts
IDP [I-D.sato-soos-idp]:
The IDP mandate_id field carries the jti of the MJWT presented
with each Transition Request, linking every intent declaration
to the specific mandate under which the agent is acting. The
IDP mission_ref field MUST match the MJWT mission_ref when
present. The GEC verifies this match at Step 11 of the
verification protocol (Section 8.1).
HEM [I-D.sato-soos-hem]:
HEM escalation events reference the mandate_id of the MJWT
active at the time of escalation. Mandate revocation during
an active HEM_PENDING state MUST trigger HEM escalation
[I-D.sato-soos-hem] Section 8.4.
The human principal identified by human_principal_id in the
MJWT is the natural person responsible for HEM decision
authority over the SO Instance.
GAR [I-D.sato-soos-gar]:
The Session Audit Record includes the mandate_id of every MJWT
presented during the governed session. The delegation_chain
in each MJWT provides the traceability record that GAR audit
consumers use to reconstruct the full authorization lineage.
CAP [I-D.sato-soos-cap]:
CAP Tier 0 and Tier 1 prohibition evaluation occurs before MJWT
scope verification in the policy evaluation order defined in
[I-D.sato-soos-sov] Section 7.3. A CAP prohibition denies the
action regardless of the MJWT's cedar_actions scope.
KIA [I-D.sato-soos-kia]:
The MJWT aud claim MUST be bound to the kernel_keypair_fingerprint
retrieved from the target GEC's current GEC Manifest
[I-D.sato-soos-kia] Section 5.2. KIA provides the attested
instance identifier that makes aud claim binding normative and
verifiable rather than implementation-specific.
SOV [I-D.sato-soos-sov]:
The MJWT so_id claim binds the mandate to a specific SO Instance
as defined in [I-D.sato-soos-sov]. The Narrowing Property
dimensions (Section 5.2) directly correspond to the binding model
specified in [I-D.sato-soos-sov] Section 8.
11. Security Considerations
The MJWT is the authorization primitive for the SOOS governance
stack. Its security properties depend on the security of the
Ed25519 signing keys used by issuing GECs and human principals.
GEC signing keys MUST be protected at the conformance level
declared by the GEC [I-D.sato-soos-idp] Section 9. At Level 3,
keys MUST be bound to a RATS-attested execution environment. At
Level 2, keys MUST be held in an isolated process inaccessible to
agent code. At Level 1, key protection is application-managed;
SCITT transparency log submission is RECOMMENDED as a compensating
control.
The Narrowing Property (Section 5) is a security invariant. Any
implementation that allows a Child Mandate to exceed the scope of
its parent creates an authorization escalation vulnerability. The
GEC MUST enforce Narrowing at issuance (Section 6.2) and at
verification (Section 8.1 Step 8). Enforcing at both points
provides defense in depth.
Cascade revocation (Section 7.2) requires the GEC to maintain a
complete mandate issuance tree for each SO Instance. Implementations
MUST ensure that the mandate issuance tree is consistent with the
SO Instance Event Stream. An inconsistency between the two is a
critical security finding and MUST trigger HEM escalation
[I-D.sato-soos-hem] Section 8.4.
The mandate_ceiling claim (Section 9) prevents mandate laundering:
an attempt to use a mandate issued in a lower-assurance context to
authorize actions in a higher-assurance enforcement environment.
Implementations MUST enforce ceiling constraints at Step 7 before
proceeding to any further verification.
The human_principal_id claim is a persistent identifier for a
natural person. It MUST be treated as sensitive and MUST be
protected against unauthorized disclosure. Access to MJWT contents
containing human_principal_id MUST be authorized by Cedar policy.
Audience Binding and Cross-GEC Replay
The aud claim (Section 4.2.1) is the primary control against
cross-GEC replay attacks. In a multi-GEC deployment, a valid MJWT
issued for GEC-A is cryptographically valid but operationally
illegitimate when presented to GEC-B. Without aud enforcement,
an attacker who intercepts or obtains a valid MJWT intended for
GEC-A can replay it at GEC-B, gaining authorization for actions on
a Sovereign Object instance in GEC-B's jurisdiction under a mandate
that was never issued for that GEC.
This attack class is analogous to the cross-authorization-server
replay vulnerability disclosed by the OpenID Foundation in January
2025 [OIDF-2025-01], which demonstrated that omission of audience
binding in private_key_jwt client authentication enabled tokens to
be replayed across authorization server instances. MJWT is subject
to the same class of vulnerability in multi-GEC deployments and MUST
implement the mitigations specified in Section 8.1 Step 1.
Three properties together constitute the complete audience binding
defense:
(a) aud claim REQUIRED in every MJWT, identifying the specific GEC
instance by its KIA-attested instance identifier (Section 4.2.1).
(b) aud verification as Step 1 of the GEC Verification Protocol,
before signature verification, preventing cryptographic resource
expenditure on tokens not intended for this GEC and preventing
timing side-channels (Section 8.1).
(c) Cross-GEC token use explicitly prohibited unless authorized
through the MAD delegation protocol [I-D.sato-soos-mad].
Implementations that deploy MJWTs across trust domain boundaries
MUST treat the aud verification step as non-bypassable. A GEC that
accepts MJWTs with mismatched aud values, even for diagnostic or
monitoring purposes, creates an exploitable replay surface.
Formal analysis of the audience binding model against the multi-GEC
attacker model is identified as future work. University-level
security analysis of the SOOS protocol suite is anticipated as part
of the SOOS open-source release programme.
Delegation Chain Size and Full-Chain Retention
The MJWT delegation_chain claim carries the complete mandate
issuance history inline in every token, following the full-chain
retention model described in [I-D.waffles]. This model provides
complete traceability at the verifier without requiring retrieval of
intermediate mandates, at the cost of token size growth linear with
delegation depth.
For deep delegation fan-out (sub-agent chains of depth > 5),
implementations should anticipate token sizes in the range of tens
of kilobytes. MJWT does not specify a maximum delegation depth;
implementations MAY impose operational limits appropriate to their
deployment topology. The compact attestation alternative (smaller
per-hop tokens requiring verifier-side state) is not specified in
this document but is identified as a possible future profile for
constrained environments.
Agent Session Revocation
MJWT operates within the SOOS session lifecycle model. When an
agent session is revoked -- whether by operator action, CAEP signal,
or CAP constitutional violation -- the mandate revocation procedure
specified in Section 7 of this document is superseded by the MAD
session revocation procedure [I-D.sato-soos-mad]. Implementations
MUST NOT issue new child mandates after receiving a session
revocation signal. All MJWTs active at point of revocation MUST be
recorded in the Revocation Registry with completion_state PARTIAL or
CLEAN per the MAD session revocation lifecycle specification.
12. Privacy Considerations
The MJWT carries human_principal_id, a persistent identifier for a
natural person. Implementations MUST NOT expose MJWT contents to
agents or principals not authorized to receive them by Cedar policy.
The delegation_chain records the sequence of principals in a mandate
issuance chain. This chain may constitute personal data under GDPR
Article 4(1) [GDPR] and APPI Article 2 [APPI]. Implementations
MUST apply appropriate access controls to delegation_chain contents.
MJWT jti values (mandate_ids) are UUID v7 values that carry timing
information. Implementations that consider mandate issuance timing
sensitive MUST treat jti values as sensitive identifiers.
The Revocation Registry (Section 7.1) may reveal information about
mandate issuance and revocation patterns. Access to the Revocation
Registry MUST be restricted to authorized GECs and audit principals.
13. IANA Considerations
13.1. JWT Claims Registry
This document requests registration of the following JWT claims in
the IANA JSON Web Token Claims registry [RFC7519]. The aud claim
is an existing registered JWT claim [RFC7519]; its use in MJWT
requires no new registration, only the normative REQUIRED
designation in this profile.
Claim Name: so_id
Claim Description: Sovereign Object instance identifier.
Change Controller: IESG
Reference: This document, Section 4.2.3.
Claim Name: so_type_id
Claim Description: Sovereign Object Type identifier.
Change Controller: IESG
Reference: This document, Section 4.2.3.
Claim Name: human_principal_id
Claim Description: Human principal identifier for agent mandate.
Change Controller: IESG
Reference: This document, Section 4.2.3.
Claim Name: cedar_actions
Claim Description: Authorized Cedar action set.
Change Controller: IESG
Reference: This document, Section 4.2.3.
Claim Name: permitted_states
Claim Description: Permitted Sovereign Object states.
Change Controller: IESG
Reference: This document, Section 4.2.3.
Claim Name: permitted_phases
Claim Description: Permitted Sovereign Object lifecycle phases.
Change Controller: IESG
Reference: This document, Section 4.2.3.
Claim Name: mandate_ceiling
Claim Description: Maximum GEC conformance level for mandate.
Change Controller: IESG
Reference: This document, Section 4.2.3.
Claim Name: parent_mandate_id
Claim Description: JWT ID of parent mandate in delegation chain.
Change Controller: IESG
Reference: This document, Section 4.2.3.
Claim Name: mission_ref
Claim Description: Mission Declaration UUID reference.
Change Controller: IESG
Reference: This document, Section 4.2.3.
Claim Name: zone_b_read
Claim Description: Zone B read authorization flag.
Change Controller: IESG
Reference: This document, Section 4.2.3.
Claim Name: zone_b_write
Claim Description: Zone B write authorization flag.
Change Controller: IESG
Reference: This document, Section 4.2.3.
Claim Name: delegation_chain
Claim Description: Mandate delegation issuance chain (Actor Profile).
Change Controller: IESG
Reference: This document, Section 4.2.3; [I-D.mcguinness-oauth-actor-profile].
Claim Name: gec_cluster_id
Claim Description: GEC cluster identifier for multi-GEC deployments.
Change Controller: IESG
Reference: This document, Section 4.2.3.
13.2. MJWT Deny Code Registry
This document requests IANA to create the following registry:
Registry name: SOOS MJWT Verification Deny Code Registry
Registration procedure: Specification Required.
Initial registrations: As listed in Section 8.2, including:
MJWT_AUD_MISMATCH: MJWT audience claim does not match the KIA-
attested instance identifier of the receiving GEC. Step 1 of the
GEC Verification Protocol. Reference: This document, Section 8.1
Step 1.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, May 2015.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, April 2016.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curves for JOSE", RFC 8037,
January 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017.
[RFC8693] Jones, M., Campbell, B., and C. Mortimore, "OAuth 2.0
Token Exchange", RFC 8693, January 2020.
[RFC9562] Davis, B., Peabody, C., and P. Leach, "Universally
Unique IDentifiers (UUIDs)", RFC 9562, May 2024.
[Cedar] Amazon Web Services, "Cedar Policy Language Specification",
https://docs.cedarpolicy.com/
[I-D.sato-soos-idp]
Sato, T., "The Intent Declaration Primitive (IDP) for
Agentic AI Systems", draft-sato-soos-idp-04, June 2026.
[I-D.sato-soos-hem]
Sato, T., "The Human Escalation Mechanism (HEM) for
Agentic AI Systems", draft-sato-soos-hem-04, June 2026.
[I-D.sato-soos-gar]
Sato, T., "Governance Audit Record (GAR) for Agentic
AI Systems", draft-sato-soos-gar-02, June 2026.
[I-D.sato-soos-cap]
Sato, T., "Constitutional AI Protocol (CAP) for Agentic
AI Systems", draft-sato-soos-cap-03, June 2026.
[I-D.sato-soos-sov]
Sato, T., "The Sovereign Object (SOV) for Agentic AI
Systems", draft-sato-soos-sov-01, June 2026.
[I-D.sato-soos-kia]
Sato, T., "Kernel Identity and Attestation for Governance
Execution Controllers", draft-sato-soos-kia-02,
June 2026.
[I-D.sato-soos-mad]
Sato, T., "Multi-Agent Delegation (MAD) for Agentic AI
Systems", draft-sato-soos-mad-02, June 2026.
[I-D.ietf-wimse-arch]
Salomoni, D., et al., "WIMSE Architecture",
draft-ietf-wimse-arch, work in progress.
[I-D.ietf-oauth-v2-1]
Hardt, D., et al., "The OAuth 2.1 Authorization
Framework", draft-ietf-oauth-v2-1, work in progress.
[I-D.mcguinness-oauth-actor-profile]
McGuinness, K., et al., "OAuth Actor Profile",
draft-mcguinness-oauth-actor-profile-00, 2026.
[I-D.mcguinness-oauth-mission-bound-authorization]
McGuinness, K., et al., "Mission Bound Authorization",
draft-mcguinness-oauth-mission-bound-authorization-00,
2026.
[GDPR] European Parliament, "General Data Protection Regulation",
Regulation (EU) 2016/679, April 2016.
[APPI] Government of Japan, "Act on the Protection of Personal
Information", Act No. 57 of 2003, as amended.
14.2. Informative References
[I-D.sato-soos-faip]
Sato, T., "Federated Agent Intelligence Protocol (FAIP)",
draft-sato-soos-faip-01, forthcoming.
[EUAIA] European Parliament, "Artificial Intelligence Act",
Regulation (EU) 2024/1689, June 2024.
[OIDF-2025-01]
OpenID Foundation, "Responsible Disclosure Notice on
Security Vulnerability for private_key_jwt Client
Authentication", January 2025.
https://openid.net/responsible-disclosure/
[I-D.waffles]
Parecki, A., Hingnikar, A., and S. Cecchetti, "Workload
Authorization Flow for Federated Linked Environments
(Waffles)", draft-hingnikar-cecchetti-wimse-waffles-00,
work in progress.
[I-D.hardt-aauth-protocol]
Hardt, D., "AAuth Protocol", draft-hardt-aauth-protocol-01,
work in progress. https://aauth.app/
A.1. Root Mandate Example
The following is an example Root Mandate issued by a human principal
to an OTA booking agent for a specific ATP Booking Object instance.
Header:
{
"alg": "EdDSA",
"kid": "hp-001-ed25519-key-1"
}
Payload:
{
"iss": "hp-001",
"sub": "wimse:agent:ota-booking-agent-v2",
"jti": "019547ab-1234-7abc-8def-000000000001",
"iat": 1748131200,
"exp": 1748217600,
"aud": "sha256:a3f8c2d1e4b5...",
"wid": "wimse:agent:ota-booking-agent-v2",
"cnf": {
"jwk": {
"kty": "OKP",
"crv": "Ed25519",
"x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"
}
},
"so_id": "019547ab-1234-7abc-8def-000000000099",
"so_type_id": "atp/booking-object/1.0",
"human_principal_id": "hp-001",
"cedar_actions": [
"atp:booking:confirm",
"atp:booking:cancel",
"atp:booking:suspend"
],
"permitted_states": ["CONFIRMED", "PRE_ACTIVITY", "IN_JOURNEY"],
"permitted_phases": ["ACTIVE"],
"mandate_ceiling": 2,
"mission_ref": "mission-uuid-azusa-journey-2026-06-15",
"zone_b_read": true,
"zone_b_write": false
}
Note: The aud value "sha256:a3f8c2d1e4b5..." represents the
kernel_keypair_fingerprint from the target GEC's current GEC Manifest,
retrieved via the KIA API endpoint before mandate issuance.
A.2. Child Mandate Example
The following is a Child Mandate issued by the GEC to a sub-agent
(weather monitoring agent) derived from the Root Mandate in A.1.
The Narrowing Property is demonstrated: cedar_actions is a strict
subset and permitted_states is further restricted.
Payload:
{
"iss": "gec-myauberge-001",
"sub": "wimse:agent:weather-monitor-agent-v1",
"jti": "019547ab-1234-7abc-8def-000000000002",
"iat": 1748131260,
"exp": 1748174400,
"aud": "sha256:a3f8c2d1e4b5...",
"wid": "wimse:agent:weather-monitor-agent-v1",
"cnf": { "jwk": { ... } },
"so_id": "019547ab-1234-7abc-8def-000000000099",
"so_type_id": "atp/booking-object/1.0",
"human_principal_id": "hp-001",
"cedar_actions": ["atp:booking:suspend"],
"permitted_states": ["IN_JOURNEY"],
"permitted_phases": ["ACTIVE"],
"mandate_ceiling": 2,
"parent_mandate_id": "019547ab-1234-7abc-8def-000000000001",
"delegation_chain": [
{
"issuer_id": "hp-001",
"recipient_id": "wimse:agent:ota-booking-agent-v2",
"mandate_jti": "019547ab-1234-7abc-8def-000000000001",
"issued_at": "2026-05-24T12:00:00Z",
"gec_signature": "human_issued"
},
{
"issuer_id": "gec-myauberge-001",
"recipient_id": "wimse:agent:weather-monitor-agent-v1",
"mandate_jti": "019547ab-1234-7abc-8def-000000000002",
"issued_at": "2026-05-24T12:01:00Z",
"gec_signature": "<Ed25519 signature>"
}
],
"mission_ref": "mission-uuid-azusa-journey-2026-06-15",
"zone_b_read": false,
"zone_b_write": false
}
In this Child Mandate:
- cedar_actions is reduced to ["atp:booking:suspend"] only.
- permitted_states is narrowed to ["IN_JOURNEY"] only.
- exp is earlier than the parent mandate's exp.
- zone_b_read is false (parent had true; child reduces it).
- human_principal_id is unchanged: "hp-001".
- aud is the same GEC instance identifier as the root mandate.
- The delegation_chain records both issuance steps.
The weather monitoring agent may only request BOOKING_SUSPENDED
state transitions, only while the Booking Object is IN_JOURNEY,
and cannot read Zone B (traveller personal data). This is the
Narrowing Property in production.
Author's Address
Tom Sato
MyAuberge K.K.
Chino, Nagano, Japan
Email: tomsato@myauberge.jp
URI: https://soosproject.ai/drafts/mjwt