Files
ietf-draft-analyzer/workspace/drafts/act/draft-nennemann-act-01.xml

3874 lines
166 KiB
XML
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.35 (Ruby 3.4.8) -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc ipr="trust200902" docName="draft-nennemann-act-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
<front>
<title abbrev="ACT">Agent Context Token (ACT)</title>
<author fullname="Christian Nennemann">
<organization>Independent Researcher</organization>
<address>
<email>ietf@nennemann.de</email>
</address>
</author>
<date year="2026" month="May" day="20"/>
<area>SEC</area>
<keyword>agent authorization</keyword> <keyword>execution accountability</keyword> <keyword>JWT</keyword> <keyword>DAG</keyword> <keyword>delegation</keyword>
<abstract>
<?line 167?>
<t>This document defines the Agent Context Token (ACT), a self-contained
JWT-based format that captures the full invocation context of an
autonomous AI agent — its capabilities, constraints, delegation
provenance, oversight requirements, task metadata, and DAG position —
and unifies authorization and execution accountability in a single
token lifecycle. An ACT begins as a signed authorization mandate and
transitions into a tamper-evident execution record once the agent
completes its task, appending cryptographic hashes of inputs and
outputs and linking to predecessor tasks via a directed acyclic graph
(DAG). ACT requires no Authorization Server, no workload identity
infrastructure, and no transparency service for basic operation. Trust
is bootstrapped via pre-shared keys and is upgradeable to PKI or
Decentralized Identifiers (DIDs). ACT is designed for
cross-organizational agent federation in regulated and unregulated
environments alike. ACT is the general-purpose agent context
primitive; the WIMSE Execution Context Token (ECT)
<xref target="I-D.nennemann-wimse-ect"/> is a sibling profile specialized for
workload-identity-bound execution recording in WIMSE deployments.</t>
</abstract>
</front>
<middle>
<?line 188?>
<section anchor="introduction"><name>Introduction</name>
<t>Autonomous AI agents increasingly operate across organizational
boundaries, executing multi-step workflows where individual tasks are
delegated from one agent to another. These workflows create two
distinct, inseparable compliance requirements:</t>
<t><list style="numbers" type="1">
<t><strong>Authorization</strong>: was the agent permitted to perform the action,
under what constraints, and by whose authority?</t>
<t><strong>Accountability</strong>: what did the agent actually do, with what
inputs, producing what outputs, in what causal relationship to
prior tasks?</t>
</list></t>
<t>Existing specifications address these requirements in isolation.
The Agent Authorization Profile (AAP) <xref target="I-D.aap-oauth-profile"/>
provides structured authorization via OAuth 2.0 but requires a
central Authorization Server. The WIMSE Execution Context Token
<xref target="I-D.nennemann-wimse-ect"/> provides execution accountability but
requires WIMSE workload identity infrastructure (SPIFFE/SPIRE).</t>
<t>This document defines the Agent Context Token (ACT), which addresses
both requirements in a single, self-contained token that requires no
shared infrastructure beyond the ability to verify asymmetric
signatures. The word "Context" in the name reflects what the token
carries: the complete invocation context of an agent — DAG references,
task metadata, capabilities, delegation chain, and oversight claims
— bound together in one cryptographically verifiable envelope. ACT
is positioned as the general agent context primitive, with the
WIMSE Execution Context Token (ECT) <xref target="I-D.nennemann-wimse-ect"/> as a
sibling profile specialized for workload-identity-bound execution
contexts in WIMSE deployments.</t>
<section anchor="problem-statement"><name>Problem Statement</name>
<t>Cross-organizational agent federation today faces a bootstrapping
problem: deploying shared OAuth infrastructure or a common SPIFFE
trust domain requires organizational agreement before the first
message is exchanged. In practice this means either:</t>
<t>(a) agents operate without cryptographic authorization or audit
trails, relying on application-layer access control only; or</t>
<t>(b) organizations adopt one party's identity infrastructure, creating
a hub-and-spoke dependency that contradicts the decentralized
nature of agent networks.</t>
<t>ACT solves this by making pre-shared keys the mandatory-to-implement
trust baseline — two agents can begin a secure, auditable interaction
with nothing more than an out-of-band key exchange — while providing
a clean upgrade path to PKI or DID-based trust without changing the
token format.</t>
</section>
<section anchor="design-goals"><name>Design Goals</name>
<t><list style="symbols">
<t><strong>G1 — Zero infrastructure baseline</strong>: ACT <bcp14>MUST</bcp14> be deployable with
no shared servers, no common identity provider, and no transparency
service.</t>
<t><strong>G2 — Single token lifecycle</strong>: Authorization and accountability
<bcp14>MUST</bcp14> be expressed in the same token format to prevent
authorization-accountability gaps.</t>
<t><strong>G3 — Peer-to-peer delegation</strong>: Delegation chains <bcp14>MUST</bcp14> be
verifiable without contacting an Authorization Server, using
cryptographic chaining of agent signatures.</t>
<t><strong>G4 — DAG-native causal ordering</strong>: Workflows with parallel
branches and fan-in dependencies <bcp14>MUST</bcp14> be expressible natively,
without flattening to a linear chain.</t>
<t><strong>G5 — Cross-organizational interoperability</strong>: ACTs issued by
agents in different trust domains <bcp14>MUST</bcp14> be verifiable by any
participant holding the issuing agent's public key.</t>
<t><strong>G6 — Regulatory applicability</strong>: ACT <bcp14>MUST</bcp14> provide sufficient
evidence for audit requirements in DORA <xref target="DORA"/>, EU AI Act
Article 12 <xref target="EUAIA"/>, and IEC 62304 <xref target="IEC62304"/> without requiring
additional log formats.</t>
<t><strong>G7 — Upgrade path</strong>: The trust model <bcp14>MUST</bcp14> support migration from
pre-shared keys to PKI or DID without breaking existing ACT chains.</t>
</list></t>
</section>
<section anchor="non-goals"><name>Non-Goals</name>
<t>The following are explicitly out of scope:</t>
<t><list style="symbols">
<t>Defining internal AI model behavior or decision logic.</t>
<t>Replacing organizational security policies or procedures.</t>
<t>Defining storage formats for audit ledgers.</t>
<t>Specifying token revocation infrastructure (deployments <bcp14>MAY</bcp14> use
existing mechanisms such as <xref target="RFC7009"/> for this purpose).</t>
<t>Providing non-equivocation guarantees in standalone mode (see
<xref target="equivocation"/> for the equivocation discussion and optional
transparency anchoring).</t>
</list></t>
</section>
<section anchor="relationship-to-related-work"><name>Relationship to Related Work</name>
<t><strong>AAP <xref target="I-D.aap-oauth-profile"/></strong>: ACT addresses the same authorization
problem as AAP but does not require an Authorization Server. ACT
delegation is peer-to-peer via cryptographic signature chaining;
AAP delegation requires OAuth Token Exchange <xref target="RFC8693"/> against a
central AS. ACT is not a profile of AAP; it is an
infrastructure-independent alternative for the same problem class.</t>
<t><strong>WIMSE ECT <xref target="I-D.nennemann-wimse-ect"/></strong>: ACT addresses the same
execution accountability problem as the WIMSE Execution Context Token
but does not require WIMSE workload identity infrastructure. ACT is
not a profile of WIMSE; it is deployable in environments without
SPIFFE/SPIRE. In environments where WIMSE is deployed, ACT <bcp14>MAY</bcp14> be
carried alongside WIMSE tokens to augment accountability with
authorization provenance.</t>
<t><strong>SCITT <xref target="I-D.ietf-scitt-architecture"/></strong>: For deployments requiring
non-equivocation guarantees (see <xref target="equivocation"/>), ACT execution
records <bcp14>MAY</bcp14> be anchored to a SCITT Transparency Service as a Layer 2
mechanism. This is <bcp14>OPTIONAL</bcp14> and not required for basic ACT operation.
Note: The SCITT architecture draft is currently in AUTH48 (RFC
Editor queue) at version -22 and is about to become an RFC; readers
should use the RFC number once assigned.</t>
<section anchor="concurrent-agent-authorization-proposals"><name>Concurrent Agent Authorization Proposals</name>
<t>Several concurrent proposals in the IETF and academic communities
address overlapping portions of the agent authorization problem
space. This subsection situates ACT relative to those proposals.
Protocol-layer comparison of linear versus DAG delegation
structure is deferred to <xref target="dag-vs-linear"/>; the summaries below focus
on scope and deployability.</t>
<t><strong>AIP / IBCTs <xref target="AIP-IBCT"/></strong>: The Agent Interaction Protocol proposes
Interaction-Bound Capability Tokens in two modes: compact signed
JWTs for single-hop invocation and Biscuit/Datalog tokens for
multi-hop delegation, motivated by a survey of approximately 2,000
Model Context Protocol servers that found no authorization
enforcement. ACT addresses the same problem class but relies
exclusively on JWT/JOSE throughout (no Biscuit or Datalog
dependency), defines an explicit two-phase lifecycle separating
authorization (Mandate) from proof-of-execution (Record), and
supports DAG delegation structure. IBCTs are modeled as append-only
chains at the protocol layer; ACT operates at the authorization
graph layer with revocable lifecycle states.</t>
<t><strong>SentinelAgent <xref target="SentinelAgent"/></strong>: SentinelAgent defines a formal
Delegation Chain Calculus with seven verifiable properties, a TLA+
mechanization, and reports 100% true-positive and 0% false-positive
rates against the DelegationBench v4 benchmark. It addresses the
same accountability question as ACT — namely, which principal
authorized a given chain of actions. The differentiator is
deployment substrate: SentinelAgent expresses its guarantees in a
domain-specific formal calculus, whereas ACT encodes the same
invariants in IETF-standard JWT infrastructure (RFC 7519, RFC 7515,
RFC 8032) already deployable in existing OAuth- and JOSE-aware
stacks.</t>
<t><strong>Agentic JWT <xref target="AgenticJWT"/></strong>: Agentic JWT derives a per-agent
identity as a one-way hash of the agent's prompt, registered tools,
and configuration, and chains delegation assertions across
invocations. It is the closest prior-art JWT-based construction
for agentic delegation. ACT differs in that it adds an explicit
two-phase lifecycle — separating the authorization mandate from
the proof-of-execution record — and expresses delegation as a DAG
via the array-valued <spanx style="verb">pred</spanx> claim rather than a strictly linear
chain.</t>
<t><strong>OAuth Transaction Tokens for Agents
<xref target="I-D.oauth-transaction-tokens-for-agents"/></strong>: This draft
extends OAuth Transaction Tokens with an <spanx style="verb">actchain</spanx> claim (an
ordered delegation array), an <spanx style="verb">agentic_ctx</spanx> claim conveying intent
and constraints, and flow-type markers distinguishing interactive
from autonomous invocations. It is complementary to ACT at the
OAuth layer. The primary differentiators are topology and
infrastructure dependency: Transaction Tokens for Agents presume
an OAuth Authorization Server and use a linear <spanx style="verb">actchain</spanx>, whereas
ACT operates peer-to-peer without any AS and uses a DAG-valued
<spanx style="verb">pred</spanx>. A detailed differencing document is referenced in
<xref target="security-considerations"/>.</t>
<t><strong>Helixar Delegation Protocol (HDP)
<xref target="I-D.helixar-hdp-agentic-delegation"/></strong>: HDP specifies
Ed25519 signatures over RFC 8785-canonicalized JSON, an
append-only linear delegation chain with session binding, and
offline verification. ACT addresses the same problem but is
encoded in JWT/JOSE (aligning with the broader IETF token
ecosystem) rather than raw canonical JSON, and its <spanx style="verb">pred</spanx> claim
admits DAG topologies rather than strictly linear chains.</t>
<t><strong>SCITT Profile for AI Agent Execution Records
<xref target="I-D.emirdag-scitt-ai-agent-execution"/></strong>: This draft
defines a SCITT profile in which AgentInteractionRecord (AIR)
payloads are carried as COSE_Sign1 statements anchored to a
SCITT Transparency Service. It is highly complementary to ACT:
where ACT defines the two-phase lifecycle token issued and
consumed by agents at runtime, the SCITT AI Agent Execution
draft defines the payload format suitable for long-term anchoring.
Implementations that anchor Phase 2 ACTs to SCITT
(<xref target="security-considerations"/>) <bcp14>SHOULD</bcp14> consider the AIR payload
structure defined in that draft as the canonical encoding for
anchored records.</t>
</section>
</section>
<section anchor="applicability"><name>Applicability</name>
<t>ACT is designed as a general-purpose primitive for AI agent
authorization and execution accountability. While a sibling
specification <xref target="I-D.nennemann-wimse-ect"/> profiles execution context
tokens specifically for the WIMSE working group's workload identity
infrastructure, ACT operates without any shared identity plane. This
section identifies deployment contexts where ACT applies independently
of WIMSE, and clarifies how ACT complements — rather than competes
with — ecosystem-specific agent protocols.</t>
<section anchor="model-context-protocol-mcp-tool-use-flows"><name>Model Context Protocol (MCP) Tool-Use Flows</name>
<t>The Model Context Protocol <xref target="MCP-SPEC"/> defines a client-server
interface by which LLM hosts invoke external tools via structured
JSON-RPC calls. MCP 2025-11-25 mandates OAuth 2.1 for transport-layer
authentication, but provides no mechanism for carrying per-invocation
authorization constraints or for producing a tamper-evident record
of what arguments were passed and what result was returned.</t>
<t>ACT addresses this gap as follows: when an MCP host is about to
dispatch a tool call on behalf of an agent, it <bcp14>SHOULD</bcp14> issue a Phase 1
ACT Mandate encoding the permitted tool name (e.g., as a capability
constraint), the declaring scope, and any parameter-level constraints
applicable to that invocation. The MCP server, upon receiving the
request, <bcp14>MAY</bcp14> validate the ACT Mandate and, upon completing the tool
execution, <bcp14>SHOULD</bcp14> transition the token to Phase 2 by appending
SHA-256 hashes of the serialized input arguments and the JSON
response, then re-sign. The resulting Phase 2 ACT constitutes an
unforgeable record that a specific tool was called with specific
arguments and returned a specific result, independently of MCP's
OAuth layer.</t>
<t>This integration requires no modification to MCP transport; the ACT
<bcp14>SHOULD</bcp14> be carried in the <spanx style="verb">ACT-Mandate</spanx> and <spanx style="verb">ACT-Record</spanx> HTTP headers
defined in <xref target="http-header-transport"/> of this document.</t>
</section>
<section anchor="openai-agents-sdk-and-function-calling"><name>OpenAI Agents SDK and Function Calling</name>
<t>The OpenAI Agents SDK <xref target="OPENAI-AGENTS-SDK"/> enables composition of
agents via handoffs — structured transfers of control from one agent
to another, each potentially invoking registered function tools. The
SDK provides no built-in mechanism for a receiving agent to verify
that the handoff was authorized by a named principal, nor for the
invoking agent to produce a verifiable record of what functions it
called.</t>
<t>ACT is applicable at the handoff boundary: the orchestrating agent
<bcp14>SHOULD</bcp14> issue a Phase 1 ACT Mandate to the receiving agent at the
moment of handoff, encoding the permitted function set as
capability constraints and the maximum privilege the receiving agent
<bcp14>MAY</bcp14> exercise. The receiving agent <bcp14>SHOULD</bcp14> attach its Phase 2 ACT
Record to any callback or downstream response, providing the
orchestrator with cryptographic evidence of the actions taken. In
multi-turn chains involving multiple handoffs, the DAG linkage
(<xref target="dag-structure"/>) allows each handoff to be expressed as a
parent-child edge, preserving the full causal ordering of the agent
invocation sequence.</t>
<t>Implementations that use the OpenAI function calling API directly,
without the Agents SDK, <bcp14>MAY</bcp14> apply ACT at the application layer: the
calling process issues a Phase 1 ACT before the function call
parameter block is finalized, and the receiving function handler
returns a Phase 2 ACT alongside its JSON result.</t>
</section>
<section anchor="langgraph-and-langchain-agent-graphs"><name>LangGraph and LangChain Agent Graphs</name>
<t>LangGraph <xref target="LANGGRAPH"/> models agent workflows as typed StateGraphs in
which nodes represent agent invocations or tool calls and edges
represent conditional transitions. The DAG structure of ACT
(<xref target="dag-structure"/>) is a natural fit for this model: each LangGraph
node that performs an observable action corresponds to exactly one
ACT task identifier (<spanx style="verb">tid</spanx>), and directed edges in the LangGraph
correspond to <spanx style="verb">pred</spanx> (predecessor) references in successor ACTs.</t>
<t>ACT is applicable at the node boundary: when a LangGraph node
dispatches a sub-agent or invokes a tool with side effects, it <bcp14>SHOULD</bcp14>
issue a Phase 1 ACT Mandate encoding the node's permitted actions
before any external call is made. Upon transition out of the node,
a Phase 2 ACT Record <bcp14>SHOULD</bcp14> be produced and attached to the
LangGraph state object alongside the node's output. Downstream nodes
that fan-in from multiple predecessors <bcp14>MAY</bcp14> retrieve the set of parent
ACT identifiers from the shared state to populate their <spanx style="verb">pred</spanx> array,
thereby expressing LangGraph's fan-in semantics within the ACT DAG
without any additional infrastructure.</t>
<t>In contrast to LangGraph's built-in state audit trail, which is
mutable in-process memory, Phase 2 ACTs are cryptographically signed
and portable: they can be exported from a LangGraph run and
submitted to an external audit ledger, satisfying compliance
requirements that cannot be met by in-process logging alone.</t>
</section>
<section anchor="google-agent2agent-a2a-protocol"><name>Google Agent2Agent (A2A) Protocol</name>
<t>The Agent2Agent protocol <xref target="A2A-SPEC"/> defines a task-oriented JSON-RPC
interface for inter-agent communication, with authentication
delegated to OAuth 2.0 or API key schemes declared in each agent's
Agent Card. A2A provides no mechanism for a receiving agent to
verify the authorization provenance of a task request beyond the
transport-layer credential, and produces no token that represents
the execution of the task in a verifiable, portable form.</t>
<t>ACT is applicable as a session-layer accountability complement to
A2A: a client agent <bcp14>SHOULD</bcp14> include a Phase 1 ACT Mandate in the
<spanx style="verb">metadata</spanx> field of the A2A Task object, encoding the task type as
a capability constraint and the delegating agent's identity as the
ACT issuer. The receiving agent <bcp14>SHOULD</bcp14> validate the Mandate before
beginning task execution and <bcp14>SHOULD</bcp14> return a Phase 2 ACT Record
as an artifact in the A2A TaskResult, enabling the client agent to
retain cryptographic proof of what was executed on its behalf.</t>
<t>This integration does not require modification to A2A's transport or
authentication scheme; ACT and A2A's OAuth credentials operate at
independent layers and are not redundant. A2A's credential answers
"is this client permitted to contact this server?"; the ACT Mandate
answers "is this agent permitted to request this specific task
under these constraints?".</t>
</section>
<section anchor="enterprise-orchestration-without-wimse-crewai-autogen"><name>Enterprise Orchestration Without WIMSE (CrewAI, AutoGen)</name>
<t>Enterprise orchestration frameworks such as CrewAI <xref target="CREWAI"/> and
AutoGen <xref target="AUTOGEN"/> deploy multi-agent systems within a single
organizational boundary, typically without SPIFFE/SPIRE workload
identity infrastructure. In these environments, OAuth Authorization
Servers are often unavailable or impractical to deploy for
intra-process agent communication.</t>
<t>ACT is applicable in this context via its Tier 1 (pre-shared key)
trust model (<xref target="tier1"/>): each agent role in a CrewAI Crew or
AutoGen ConversableAgent graph is assigned an Ed25519 keypair at
instantiation time. The orchestrating agent issues Phase 1 Mandates
to worker agents before delegating tasks, constraining each worker
to only the tools and actions relevant to its role. Worker agents
produce Phase 2 Records on task completion. The resulting ACT chain
is exportable as a structured audit trail that satisfies the
per-action logging requirements of DORA <xref target="DORA"/> and EU AI Act
Article 12 <xref target="EUAIA"/> without requiring shared infrastructure beyond
the ability to exchange public keys at deployment time.</t>
<t>Implementations <bcp14>SHOULD NOT</bcp14> use ACT's self-assertion mode (where an
agent issues and records its own mandate without external sign-off)
in regulated workflows; at minimum, the orchestrating agent <bcp14>MUST</bcp14>
sign the initial Mandate so that accountability is anchored to a
principal outside the executing agent.</t>
</section>
<section anchor="relationship-to-wimse-ect"><name>Relationship to WIMSE ECT</name>
<t>Where WIMSE infrastructure is deployed, ACT and the WIMSE Execution
Context Token <xref target="I-D.nennemann-wimse-ect"/> serve complementary and
non-overlapping functions. The ECT records workload-level execution
in WIMSE terms — which SPIFFE workload executed, in which trust
domain, against which service. ACT records the authorization
provenance — which agent was permitted to request which action,
under what capability constraints, by whose authority — and
transitions that authorization record into an execution record upon
task completion.</t>
<t>In mixed environments, both tokens <bcp14>SHOULD</bcp14> be carried simultaneously:
the <spanx style="verb">Workload-Identity</spanx> header carries the WIMSE ECT; the
<spanx style="verb">ACT-Record</spanx> header carries the ACT. Verifiers <bcp14>MAY</bcp14> correlate the
two by matching the ACT <spanx style="verb">tid</spanx> claim against application-layer
identifiers present in the ECT's task context. Neither token is a
profile or extension of the other; they operate at different
abstraction layers and their co-presence is additive.</t>
</section>
</section>
</section>
<section anchor="conventions-and-definitions"><name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
<?line -18?>
<t><strong>Agent</strong>: An autonomous software entity that executes tasks, issues
ACTs as mandates for sub-agents, and produces ACTs as execution
records of its own actions.</t>
<t><strong>Authorization Mandate</strong>: An ACT in Phase 1, encoding what an agent
is permitted to do, under what constraints, and by whose authority.</t>
<t><strong>Execution Record</strong>: An ACT in Phase 2, encoding what an agent
actually did, including cryptographic hashes of inputs and outputs
and causal links to predecessor tasks.</t>
<t><strong>Directed Acyclic Graph (DAG)</strong>: A graph structure representing task
dependency ordering where edges are directed and no cycles exist. Used
by ACT to model causal relationships between tasks in a workflow.</t>
<t><strong>Delegation Chain</strong>: A cryptographically verifiable sequence of ACT
issuances from a root authority through one or more agents, each
signing a new ACT that reduces privileges relative to the one it
received.</t>
<t><strong>Trust Tier</strong>: A level of key management infrastructure used to
establish the public key of an ACT issuer. Tiers range from
pre-shared keys (Tier 1, mandatory) to PKI (Tier 2) and DIDs
(Tier 3).</t>
<t><strong>Workflow</strong>: A set of related tasks, identified by a shared <spanx style="verb">wid</spanx>
claim, forming a single logical unit of work.</t>
</section>
<section anchor="act-lifecycle"><name>ACT Lifecycle</name>
<t>An ACT has a two-phase lifecycle. The same token format is used in
both phases; the presence or absence of execution claims determines
which phase a token represents.</t>
<t>A token is a <strong>Phase 2 Execution Record</strong> if and only if the claim
<spanx style="verb">exec_act</spanx> is present. A token that does not contain <spanx style="verb">exec_act</spanx> is
a <strong>Phase 1 Authorization Mandate</strong>. Verifiers <bcp14>MUST</bcp14> determine the
phase before applying verification rules, and <bcp14>MUST</bcp14> reject a token
that is presented in the wrong phase for the operation being
performed.</t>
<section anchor="phase-1-authorization-mandate"><name>Phase 1: Authorization Mandate</name>
<t>In Phase 1, an ACT is created by a delegating agent (or a human
operator) to authorize a target agent to perform a specific task. The
token carries:</t>
<t><list style="symbols">
<t>The identity of the issuing agent and the target agent.</t>
<t>The capabilities granted, with associated constraints.</t>
<t>Human oversight requirements for high-impact actions.</t>
<t>The delegation provenance (who authorized the issuer to delegate).</t>
<t>A task identifier and declared purpose.</t>
</list></t>
<t>The Phase 1 ACT is signed by the issuing agent using its private key.
The target agent receives the ACT and uses it as a bearer mandate —
evidence that it is authorized to proceed.</t>
<t>Phase 1 ACTs are short-lived. Implementations <bcp14>SHOULD</bcp14> set expiration
(<spanx style="verb">exp</spanx>) to no more than 15 minutes after issuance (<spanx style="verb">iat</spanx>) for
automated agent-to-agent workflows. Longer lifetimes <bcp14>MAY</bcp14> be used for
human-initiated mandates where the agent may not act immediately.</t>
</section>
<section anchor="phase-2-execution-record"><name>Phase 2: Execution Record</name>
<t>Upon completing the authorized task, the executing agent <bcp14>MUST</bcp14>
transition the ACT to Phase 2 by:</t>
<t><list style="numbers" type="1">
<t>Adding the <spanx style="verb">exec_act</spanx> claim describing the action performed.</t>
<t>Optionally adding <spanx style="verb">inp_hash</spanx> and/or <spanx style="verb">out_hash</spanx> SHA-256 hashes
of task inputs and outputs (<bcp14>RECOMMENDED</bcp14> for regulated environments).</t>
<t>Adding the <spanx style="verb">pred</spanx> array referencing predecessor task identifiers (DAG
dependencies).</t>
<t>Adding <spanx style="verb">exec_ts</spanx> and <spanx style="verb">status</spanx> claims.</t>
<t>Re-signing the complete token with its own private key.</t>
</list></t>
<t>The re-signing is critical: it produces a new signature over the
combined authorization + execution claims, binding the executing
agent's cryptographic identity to both the mandate it received and
the execution it performed. This creates a single, non-repudiable
record that answers both "was this agent authorized?" and "what
did it do?"</t>
<t>Note on issuer signature preservation: re-signing replaces the
Phase 1 signature produced by the issuing agent (<spanx style="verb">iss</spanx>). The
integrity of the original mandate is preserved through the
<spanx style="verb">del.chain</spanx> mechanism: the chain entry's <spanx style="verb">sig</spanx> field is the <spanx style="verb">iss</spanx>
agent's signature over the Phase 1 ACT, and this signature remains
intact and verifiable in the Phase 2 token. For root mandates where
<spanx style="verb">del.chain</spanx> is empty, the issuer's signature is not independently
preserved in Phase 2. Deployments requiring independent
verifiability of the original mandate <bcp14>SHOULD</bcp14> retain the Phase 1
ACT separately alongside the Phase 2 record.</t>
<t>The resulting Phase 2 ACT <bcp14>SHOULD</bcp14> be submitted to an audit ledger
(<xref target="audit-ledger"/>) and <bcp14>MAY</bcp14> be sent to the next agent in the workflow
as evidence of completed prerequisites.</t>
</section>
<section anchor="lifecycle-state-machine"><name>Lifecycle State Machine</name>
<figure><artwork><![CDATA[
[Issuer creates Phase 1 ACT]
|
| sign(issuer_key)
v
+------------------+
| MANDATE | Phase 1: Authorization Mandate
| (unsigned by | Carried as bearer token by target agent
| target agent) |
+------------------+
|
| Target agent executes task
| adds exec_act, inp_hash, out_hash, pred
| re-signs with target_agent_key
v
+------------------+
| RECORD | Phase 2: Execution Record
| (signed by | Submitted to ledger, passed to next agent
| target agent) |
+------------------+
|
| (optional) anchor to SCITT Transparency Service
v
+------------------+
| ANCHORED | Phase 2 + external non-equivocation
+------------------+
]]></artwork></figure>
</section>
</section>
<section anchor="act-token-format"><name>ACT Token Format</name>
<t>An ACT is a JSON Web Token <xref target="RFC7519"/> signed as a JSON Web Signature
<xref target="RFC7515"/> using JWS Compact Serialization. All ACTs <bcp14>MUST</bcp14> use JWS
Compact Serialization to ensure they can be carried in a single HTTP
header value.</t>
<section anchor="jose-header"><name>JOSE Header</name>
<t>The ACT JOSE header <bcp14>MUST</bcp14> contain:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "ES256",
"typ": "act+jwt",
"kid": "agent-a-key-2026-03"
}
]]></sourcecode></figure>
<t><strong>alg</strong> (<bcp14>REQUIRED</bcp14>): The digital signature algorithm. Implementations
<bcp14>MUST</bcp14> support ES256 <xref target="RFC7518"/>. EdDSA (Ed25519) <xref target="RFC8037"/> is
<bcp14>RECOMMENDED</bcp14> for new deployments due to smaller signatures and
resistance to side-channel attacks. Symmetric algorithms (HS256,
HS384, HS512) <bcp14>MUST NOT</bcp14> be used. The "alg" value <bcp14>MUST NOT</bcp14> be "none".</t>
<t><strong>typ</strong> (<bcp14>REQUIRED</bcp14>): <bcp14>MUST</bcp14> be "act+jwt" to distinguish ACTs from other
JWT types.</t>
<t><strong>kid</strong> (<bcp14>REQUIRED</bcp14>): An identifier for the signing key. In Tier 1
deployments (pre-shared keys), this is an opaque string agreed
out-of-band. In Tier 2 deployments (PKI), this is the X.509
certificate thumbprint. In Tier 3 deployments (DID), this is the
DID key fragment (e.g., <spanx style="verb">did:key:z6Mk...#key-1</spanx>).</t>
<t><strong>x5c</strong> (<bcp14>OPTIONAL</bcp14>): In Tier 2 deployments, the X.509 certificate
chain <bcp14>MAY</bcp14> be included to enable verification without out-of-band
key distribution.</t>
<t><strong>did</strong> (<bcp14>OPTIONAL</bcp14>): In Tier 3 deployments, the full DID of the
issuing agent <bcp14>MAY</bcp14> be included for resolution.</t>
</section>
<section anchor="jwt-claims-authorization-phase"><name>JWT Claims: Authorization Phase</name>
<section anchor="standard-jwt-claims"><name>Standard JWT Claims</name>
<t><strong>iss</strong> (<bcp14>REQUIRED</bcp14>): The identifier of the agent issuing the mandate.
Format depends on trust tier: an opaque string (Tier 1), an X.509
Subject DN (Tier 2), or a DID (Tier 3).</t>
<t><strong>sub</strong> (<bcp14>REQUIRED</bcp14>): The identifier of the agent authorized to act.
<bcp14>MUST</bcp14> use the same format convention as <spanx style="verb">iss</spanx>.</t>
<t><strong>aud</strong> (<bcp14>REQUIRED</bcp14>): The intended recipient(s). <bcp14>MUST</bcp14> include the
identifier of the target agent (<spanx style="verb">sub</spanx>). When an audit ledger is
deployed, <bcp14>MUST</bcp14> also include the ledger's identifier. When multiple
recipients are present, <bcp14>MUST</bcp14> be an array. Verifiers that are audit
ledgers <bcp14>MUST</bcp14> verify that their own identifier appears in <spanx style="verb">aud</spanx>.</t>
<t><strong>iat</strong> (<bcp14>REQUIRED</bcp14>): Issuance time as a NumericDate <xref target="RFC7519"/>.</t>
<t><strong>exp</strong> (<bcp14>REQUIRED</bcp14>): Expiration time. Implementations <bcp14>SHOULD</bcp14> set to
no more than 15 minutes after <spanx style="verb">iat</spanx> for automated workflows.</t>
<t><strong>jti</strong> (<bcp14>REQUIRED</bcp14>): A UUID <xref target="RFC9562"/> uniquely identifying this ACT
and, in Phase 2, the task it records. Used as the task identifier
for DAG predecessor references in <spanx style="verb">pred</spanx>.</t>
</section>
<section anchor="act-authorization-claims"><name>ACT Authorization Claims</name>
<t><strong>wid</strong> (<bcp14>OPTIONAL</bcp14>): A UUID identifying the workflow to which this
task belongs. When present, groups related ACTs and scopes <spanx style="verb">jti</spanx>
uniqueness to the workflow.</t>
<t><strong>task</strong> (<bcp14>REQUIRED</bcp14>): An object describing the authorized task:</t>
<figure><sourcecode type="json"><![CDATA[
{
"task": {
"purpose": "validate_patient_dosage",
"data_sensitivity": "restricted",
"created_by": "operator:clinical-admin-01",
"expires_at": 1772064750
}
}
]]></sourcecode></figure>
<t><list style="symbols">
<t><spanx style="verb">purpose</spanx> (<bcp14>REQUIRED</bcp14>): A string describing the intended task.
Implementations <bcp14>SHOULD</bcp14> use a controlled vocabulary or reverse-
domain notation (e.g., "com.example.validate_dosage") to enable
semantic consistency checking by the receiving agent.</t>
<t><spanx style="verb">data_sensitivity</spanx> (<bcp14>OPTIONAL</bcp14>): One of "public", "internal",
"confidential", "restricted". Receiving agents <bcp14>MUST NOT</bcp14> perform
actions that would expose data above this classification.</t>
<t><spanx style="verb">created_by</spanx> (<bcp14>OPTIONAL</bcp14>): An identifier for the human or system
that initiated the workflow. <bcp14>SHOULD</bcp14> be pseudonymous (see
<xref target="privacy-considerations"/>).</t>
<t><spanx style="verb">expires_at</spanx> (<bcp14>OPTIONAL</bcp14>): A NumericDate after which the task
mandate is no longer valid, independent of <spanx style="verb">exp</spanx>.</t>
</list></t>
<t><strong>cap</strong> (<bcp14>REQUIRED</bcp14>): An array of capability objects, each specifying
an action the agent is authorized to perform and the constraints
under which it may do so:</t>
<figure><sourcecode type="json"><![CDATA[
{
"cap": [
{
"action": "read.patient_record",
"constraints": {
"patient_id_scope": "current_task_only",
"max_records": 1,
"data_classification_max": "restricted"
}
},
{
"action": "write.dosage_recommendation",
"constraints": {
"status": "draft_only"
}
}
]
}
]]></sourcecode></figure>
<t>Action names <bcp14>MUST</bcp14> conform to the ABNF grammar:</t>
<figure><artwork><![CDATA[
action-name = component *( "." component )
component = ALPHA *( ALPHA / DIGIT / "-" / "_" )
]]></artwork></figure>
<t>Receiving agents <bcp14>MUST</bcp14> perform exact string matching on action names.
Wildcard matching is NOT part of this specification.</t>
<t>When multiple capabilities match the same action, OR semantics
apply: if ANY capability grants the action, the request is
authorized subject to that capability's constraints. When multiple
constraints exist within a single capability, AND semantics apply:
ALL constraints <bcp14>MUST</bcp14> be satisfied. When the same constraint key
appears in both a capability-level and a policy-level context, the
more restrictive value applies: lower numeric limits, narrower
allow-lists (intersection), broader block-lists (union), and
narrower time windows.</t>
<t><strong>oversight</strong> (<bcp14>OPTIONAL</bcp14>): Human oversight requirements:</t>
<figure><sourcecode type="json"><![CDATA[
{
"oversight": {
"requires_approval_for": ["write.publish", "execute.payment"],
"approval_ref": "https://approval.example.com/workflow/w-123"
}
}
]]></sourcecode></figure>
<t>When <spanx style="verb">requires_approval_for</spanx> lists an action, the receiving agent
<bcp14>MUST NOT</bcp14> execute that action autonomously. The approval mechanism
is out of scope for this specification.</t>
<t><strong>del</strong> (<bcp14>OPTIONAL</bcp14>): Delegation provenance, establishing the chain
of authority from the root mandate to this ACT. If <spanx style="verb">del</spanx> is absent,
the ACT <bcp14>MUST</bcp14> be treated as a root mandate with <spanx style="verb">depth</spanx> = 0 and
further delegation is not permitted (i.e., the receiving agent <bcp14>MUST
NOT</bcp14> issue sub-mandates based on this ACT).</t>
<figure><sourcecode type="json"><![CDATA[
{
"del": {
"depth": 1,
"max_depth": 3,
"chain": [
{
"delegator": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"jti": "550e8400-e29b-41d4-a716-446655440000",
"sig": "base64url-encoded-signature-of-parent-act-hash"
}
]
}
}
]]></sourcecode></figure>
<t><list style="symbols">
<t><spanx style="verb">depth</spanx>: The current delegation depth. 0 means this is a root
mandate issued by a human or root authority.</t>
<t><spanx style="verb">max_depth</spanx>: The maximum permitted delegation depth. Receiving
agents <bcp14>MUST NOT</bcp14> issue sub-mandates that would exceed this depth.</t>
<t><spanx style="verb">chain</spanx>: An array of delegation provenance records ordered from
root to immediate parent (<spanx style="verb">chain[0]</spanx> is the root authority,
<spanx style="verb">chain[depth-1]</spanx> is the direct parent of this ACT). Each entry
contains:
<list style="symbols">
<t><spanx style="verb">delegator</spanx>: The identifier of the agent that authorized this
delegation step (i.e., the <spanx style="verb">iss</spanx> of the parent ACT at that
depth).</t>
<t><spanx style="verb">jti</spanx>: The <spanx style="verb">jti</spanx> of the parent ACT that authorized this
delegation step.</t>
<t><spanx style="verb">sig</spanx>: The delegating agent's signature over the SHA-256 hash
of that parent ACT, providing cryptographic linkage without
requiring the full parent ACT to be transmitted.</t>
</list></t>
</list></t>
<t>The <spanx style="verb">sig</spanx> field in each chain entry is the critical departure from
AAP's delegation model: rather than requiring a central AS to
validate the chain, any verifier holding the delegating agent's
public key can independently verify each step by recomputing the
hash and checking the signature.</t>
</section>
</section>
<section anchor="jwt-claims-execution-phase"><name>JWT Claims: Execution Phase</name>
<t>The following claims are added by the executing agent when
transitioning to Phase 2. Their presence distinguishes an Execution
Record from an Authorization Mandate.</t>
<t><strong>exec_act</strong> (<bcp14>REQUIRED</bcp14> in Phase 2): A string identifying the action
actually performed. <bcp14>MUST</bcp14> conform to the same ABNF grammar as
capability action names. <bcp14>MUST</bcp14> match one of the <spanx style="verb">action</spanx> values in
the <spanx style="verb">cap</spanx> array of the Phase 1 claims.</t>
<t><strong>pred</strong> (<bcp14>REQUIRED</bcp14> in Phase 2): An array of <spanx style="verb">jti</spanx> values of predecessor
tasks in the DAG. An empty array indicates a root task. Each value
<bcp14>MUST</bcp14> be the <spanx style="verb">jti</spanx> of a previously verified ACT (Phase 2) within
the same workflow (same <spanx style="verb">wid</spanx>) or the global ACT store if <spanx style="verb">wid</spanx> is
absent.</t>
<t><strong>inp_hash</strong> (<bcp14>OPTIONAL</bcp14>): The base64url encoding (without padding) of
the SHA-256 hash of the task's input data, computed over the raw
octets of the serialized input. Provides cryptographic evidence of
what data the agent processed.</t>
<t><strong>out_hash</strong> (<bcp14>OPTIONAL</bcp14>): The base64url encoding (without padding) of
the SHA-256 hash of the task's output data, using the same format
as <spanx style="verb">inp_hash</spanx>. Provides cryptographic evidence of what data the
agent produced.</t>
<t><strong>exec_ts</strong> (<bcp14>REQUIRED</bcp14> in Phase 2): A NumericDate recording the
actual time of task execution. <bcp14>MAY</bcp14> differ from <spanx style="verb">iat</spanx> when the agent
queued the mandate before execution. <bcp14>MUST</bcp14> be greater than or equal
to <spanx style="verb">iat</spanx>. <bcp14>SHOULD</bcp14> be less than or equal to <spanx style="verb">exp</spanx>; execution after
mandate expiry is possible when tasks are long-running and <bcp14>MUST NOT</bcp14>
cause automatic rejection, but implementors <bcp14>SHOULD</bcp14> log a warning.</t>
<t><strong>status</strong> (<bcp14>REQUIRED</bcp14> in Phase 2): One of "completed", "failed",
"partial". Allows audit systems to distinguish successful execution
from partial or failed attempts, which is essential for regulated
environments where failed attempts must be recorded.</t>
<t><strong>err</strong> (<bcp14>OPTIONAL</bcp14>, present when <spanx style="verb">status</spanx> is "failed" or "partial"):
An object providing error context:</t>
<figure><sourcecode type="json"><![CDATA[
{
"err": {
"code": "constraint_violation",
"detail": "data_classification_max exceeded"
}
}
]]></sourcecode></figure>
<t>Error detail <bcp14>SHOULD NOT</bcp14> reveal internal system state beyond what is
necessary for audit purposes.</t>
</section>
<section anchor="complete-examples"><name>Complete Examples</name>
<section anchor="example-phase-1-authorization-mandate"><name>Example: Phase 1 — Authorization Mandate</name>
<figure><artwork><![CDATA[
{
"alg": "ES256",
"typ": "act+jwt",
"kid": "agent-clinical-key-2026-03"
}
.
{
"iss": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"sub": "did:key:z6MknGc3omCyas4b1GmEn4xySHgLuSHxrKrUBnrhJekxZHFz",
"aud": [
"did:key:z6MknGc3omCyas4b1GmEn4xySHgLuSHxrKrUBnrhJekxZHFz",
"https://ledger.hospital.example.com"
],
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"task": {
"purpose": "validate_treatment_recommendation",
"data_sensitivity": "restricted",
"created_by": "operator:clinical-admin-01"
},
"cap": [
{
"action": "read.patient_record",
"constraints": {
"patient_id_scope": "current_task_only",
"max_records": 1
}
},
{
"action": "write.safety_assessment",
"constraints": {
"status": "draft_only"
}
}
],
"oversight": {
"requires_approval_for": ["write.publish_assessment"]
},
"del": {
"depth": 0,
"max_depth": 2,
"chain": []
}
}
]]></artwork></figure>
</section>
<section anchor="example-phase-2-execution-record-same-token-re-signed-by-target-agent"><name>Example: Phase 2 — Execution Record (same token, re-signed by target agent)</name>
<figure><artwork><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "agent-safety-key-2026-03"
}
.
{
"iss": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"sub": "did:key:z6MknGc3omCyas4b1GmEn4xySHgLuSHxrKrUBnrhJekxZHFz",
"aud": [
"did:key:z6MknGc3omCyas4b1GmEn4xySHgLuSHxrKrUBnrhJekxZHFz",
"https://ledger.hospital.example.com"
],
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"task": {
"purpose": "validate_treatment_recommendation",
"data_sensitivity": "restricted",
"created_by": "operator:clinical-admin-01"
},
"cap": [
{
"action": "read.patient_record",
"constraints": {
"patient_id_scope": "current_task_only",
"max_records": 1
}
},
{
"action": "write.safety_assessment",
"constraints": {
"status": "draft_only"
}
}
],
"oversight": {
"requires_approval_for": ["write.publish_assessment"]
},
"del": {
"depth": 0,
"max_depth": 2,
"chain": []
},
"exec_act": "write.safety_assessment",
"pred": ["550e8400-e29b-41d4-a716-446655440000"],
"inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"exec_ts": 1772064300,
"status": "completed"
}
]]></artwork></figure>
</section>
</section>
</section>
<section anchor="trust-model"><name>Trust Model</name>
<t>ACT defines four trust tiers. Tier 1 is mandatory-to-implement; all
others are optional upgrades. An ACT verifier <bcp14>MUST</bcp14> be able to process
ACTs from any tier it has configured. The trust tier in use is
determined by the <spanx style="verb">kid</spanx> format and the presence of <spanx style="verb">x5c</spanx> or <spanx style="verb">did</spanx>
header parameters.</t>
<section anchor="tier-0-bootstrap-tofu-trust-on-first-use"><name>Tier 0: Bootstrap (TOFU — Trust On First Use)</name>
<t>Tier 0 is NOT part of the normative trust model and <bcp14>MUST NOT</bcp14> be used
in regulated environments. It is defined here for documentation
purposes only, to describe the common bootstrapping scenario.</t>
<t>In Tier 0, the first ACT received from an agent establishes its
public key. This is equivalent to SSH TOFU behavior: an attacker
who intercepts the first message can substitute their own key. Tier 0
deployments <bcp14>MUST</bcp14> transition to Tier 1 or higher before exchanging
ACTs that carry sensitive capabilities.</t>
</section>
<section anchor="tier1"><name>Tier 1: Pre-Shared Keys (Mandatory-to-Implement)</name>
<t>In Tier 1, both parties exchange public keys out-of-band prior to
the first ACT exchange. The <spanx style="verb">kid</spanx> is an opaque string agreed during
the key exchange. Implementations <bcp14>MUST</bcp14> support Tier 1.</t>
<t>Key exchange <bcp14>MAY</bcp14> occur via any out-of-band mechanism: manual
configuration, a configuration management system, or a prior
authenticated channel. This specification does not mandate a
specific key exchange protocol.</t>
<t>Tier 1 public keys <bcp14>MUST</bcp14> be Ed25519 <xref target="RFC8037"/> or P-256 (ES256)
<xref target="RFC7518"/> keys. RSA keys <bcp14>SHOULD NOT</bcp14> be used in Tier 1 deployments due to
key size. Key rotation <bcp14>MUST</bcp14> be performed out-of-band using the same
mechanism as the initial exchange.</t>
</section>
<section anchor="tier-2-pki-x509"><name>Tier 2: PKI / X.509</name>
<t>In Tier 2, agent identity is bound to an X.509 certificate issued
by a mutually trusted Certificate Authority (CA). The <spanx style="verb">kid</spanx> is the
certificate thumbprint (SHA-256 of the DER-encoded certificate).</t>
<t>Cross-organizational ACT exchange in Tier 2 requires either:</t>
<t>(a) a mutually trusted root CA, or
(b) cross-certification between the organizations' CAs, or
(c) explicit trust anchoring (one organization's CA is added to
the other's trust store).</t>
<t>The <spanx style="verb">x5c</spanx> JOSE header parameter <xref target="RFC7515"/> <bcp14>MAY</bcp14> carry the full
certificate chain to enable verification without out-of-band trust
store configuration.</t>
</section>
<section anchor="tier-3-decentralized-identifiers-did"><name>Tier 3: Decentralized Identifiers (DID)</name>
<t>In Tier 3, agent identity is expressed as a DID <xref target="W3C-DID"/>. The
<spanx style="verb">kid</spanx> is a DID key fragment. The <spanx style="verb">did</spanx> JOSE header parameter carries
the full DID for resolution.</t>
<t>Implementations <bcp14>SHOULD</bcp14> support at minimum <spanx style="verb">did:key</spanx> <xref target="DID-KEY"/> for
self-contained key distribution without external resolution, and
<spanx style="verb">did:web</spanx> <xref target="DID-WEB"/> for organizations that prefer DNS-anchored
identity.</t>
<t>DID resolution latency introduces a dependency on external
infrastructure. To preserve the zero-infrastructure baseline,
implementations using Tier 3 <bcp14>MAY</bcp14> cache DID Documents and <bcp14>MUST</bcp14>
specify a maximum cache TTL in their configuration.</t>
</section>
<section anchor="cross-tier-interoperability"><name>Cross-Tier Interoperability</name>
<t>A delegation chain <bcp14>MAY</bcp14> include agents operating at different trust
tiers. Each step in the chain is verified using the trust tier of
the signing agent at that step. Verifiers <bcp14>MUST NOT</bcp14> reject a chain
solely because it mixes trust tiers, but <bcp14>MAY</bcp14> apply stricter
policy for chains that include Tier 0 or Tier 1 steps when
exchanging sensitive capabilities.</t>
</section>
</section>
<section anchor="delegation-chain"><name>Delegation Chain</name>
<t>ACT delegation is peer-to-peer: no Authorization Server is involved.
Delegation is expressed as a cryptographically verifiable chain of
ACT issuances, where each step reduces privileges relative to the
previous step.</t>
<section anchor="peer-to-peer-delegation"><name>Peer-to-Peer Delegation</name>
<t>When Agent A authorizes Agent B to perform a sub-task, Agent A:</t>
<t><list style="numbers" type="1">
<t>Creates a new ACT with <spanx style="verb">sub</spanx> set to Agent B's identifier.</t>
<t>Sets <spanx style="verb">cap</spanx> to a subset of A's own authorized capabilities,
with constraints at least as restrictive as those in A's mandate.</t>
<t>Sets <spanx style="verb">del.depth</spanx> to A's own <spanx style="verb">del.depth + 1</spanx>.</t>
<t>Sets <spanx style="verb">del.max_depth</spanx> to no more than the <spanx style="verb">del.max_depth</spanx> value
in A's own mandate.</t>
<t>Adds a chain entry containing A's identifier as <spanx style="verb">delegator</spanx>,
the <spanx style="verb">jti</spanx> of A's own mandate, and a <spanx style="verb">sig</spanx> value computed as: <vspace blankLines='1'/>
<figure><artwork><![CDATA[
sig = Sign(A.private_key, SHA-256(canonical_ACT_phase1_bytes))
]]></artwork></figure>
<vspace blankLines='1'/>
where <spanx style="verb">canonical_ACT_phase1_bytes</spanx> is the UTF-8 encoded bytes
of the JWS Compact Serialization of A's Phase 1 ACT.</t>
<t>Signs the new ACT with A's private key.</t>
</list></t>
</section>
<section anchor="privilege-reduction-requirements"><name>Privilege Reduction Requirements</name>
<t>When issuing a delegated ACT, the issuing agent <bcp14>MUST</bcp14> reduce
privileges by one or more of:</t>
<t><list style="symbols">
<t>Removing capabilities (sub-set of parent capabilities only).</t>
<t>Adding stricter constraints (lower rate limits, narrower domains,
shorter time windows, lower data classification ceiling).</t>
<t>Reducing token lifetime (<spanx style="verb">exp</spanx> closer to <spanx style="verb">iat</spanx>).</t>
<t>Reducing <spanx style="verb">del.max_depth</spanx>.</t>
</list></t>
<t>The issuing agent <bcp14>MUST NOT</bcp14> grant capabilities not present in its
own mandate. Capability escalation via delegation is prohibited and
<bcp14>MUST</bcp14> be detected and rejected by verifiers.</t>
<t>For well-known numeric constraints (e.g., <spanx style="verb">max_records</spanx>,
<spanx style="verb">max_requests_per_hour</spanx>), "more restrictive" means a numerically
lower or equal value. For well-known enumerated constraints
(e.g., <spanx style="verb">data_sensitivity</spanx>), "more restrictive" means a value that
is equal or higher in the defined ordering
("public" &lt; "internal" &lt; "confidential" &lt; "restricted").
For unknown or domain-specific constraint keys, verifiers <bcp14>MUST</bcp14>
treat the constraint as non-comparable and <bcp14>MUST</bcp14> reject the
delegation unless the delegated constraint value is byte-for-byte
identical to the parent constraint value.</t>
</section>
<section anchor="delegation-verification"><name>Delegation Verification</name>
<t>A verifier receiving a delegated ACT <bcp14>MUST</bcp14>:</t>
<t><list style="numbers" type="1">
<t>Verify the ACT's own signature (<xref target="auth-verification"/>).</t>
<t>For each entry in <spanx style="verb">del.chain</spanx>, in order from index 0 to
<spanx style="verb">del.depth - 1</spanx>:
a. Retrieve the public key for <spanx style="verb">entry.delegator</spanx>.
b. Verify that <spanx style="verb">entry.sig</spanx> is a valid signature over the SHA-256
hash of the referenced parent ACT (identified by <spanx style="verb">entry.jti</spanx>).
c. Verify that the capabilities in the current ACT are a subset
of the capabilities in the parent ACT, per the constraint
comparison rules in <xref target="privilege-reduction-requirements"/>.</t>
<t>Verify that <spanx style="verb">del.depth</spanx> does not exceed <spanx style="verb">del.max_depth</spanx>.</t>
<t>Verify that <spanx style="verb">del.chain</spanx> length equals <spanx style="verb">del.depth</spanx>.</t>
</list></t>
<t>If any step fails, the ACT <bcp14>MUST</bcp14> be rejected.</t>
</section>
</section>
<section anchor="dag-structure"><name>DAG Structure and Causal Ordering</name>
<t>ACTs in Phase 2 form a DAG over the <spanx style="verb">pred</spanx> (predecessor) claim. The DAG
encodes causal dependencies: a task <bcp14>MAY</bcp14> NOT begin before all its
parent tasks are completed.</t>
<section anchor="dag-validation"><name>DAG Validation</name>
<t>When processing a Phase 2 ACT, implementations <bcp14>MUST</bcp14>:</t>
<t><list style="numbers" type="1">
<t><strong>Uniqueness</strong>: Verify the <spanx style="verb">jti</spanx> is unique within the workflow
(<spanx style="verb">wid</spanx>) or globally if <spanx style="verb">wid</spanx> is absent.</t>
<t><strong>Predecessor Existence</strong>: Verify every <spanx style="verb">jti</spanx> in <spanx style="verb">pred</spanx> corresponds to
a Phase 2 ACT available in the ACT store or audit ledger.</t>
<t><strong>Temporal Ordering</strong>: Verify that for each parent:
<spanx style="verb">parent.exec_ts &lt; child.exec_ts + clock_skew_tolerance</spanx>
(<bcp14>RECOMMENDED</bcp14> tolerance: 30 seconds). Causal ordering is
primarily enforced by DAG structure, not timestamps.</t>
<t><strong>Acyclicity</strong>: Following parent references <bcp14>MUST NOT</bcp14> lead back
to the current ACT's <spanx style="verb">jti</spanx>. Implementations <bcp14>MUST</bcp14> enforce a
maximum ancestor traversal limit (<bcp14>RECOMMENDED</bcp14>: 10,000 nodes).</t>
<t><strong>Capability Consistency</strong>: Verify that <spanx style="verb">exec_act</spanx> matches one
of the <spanx style="verb">action</spanx> values in the <spanx style="verb">cap</spanx> array from Phase 1.</t>
</list></t>
</section>
<section anchor="root-tasks-and-fan-in"><name>Root Tasks and Fan-in</name>
<t>A root task has <spanx style="verb">pred = []</spanx>. A workflow <bcp14>MAY</bcp14> have multiple root tasks
representing parallel branches with no shared predecessor.</t>
<t>Fan-in — a task with multiple parents — is expressed naturally:</t>
<figure><sourcecode type="json"><![CDATA[
{
"pred": [
"550e8400-e29b-41d4-a716-446655440001",
"550e8400-e29b-41d4-a716-446655440002"
]
}
]]></sourcecode></figure>
<t>This indicates the current task depends on the completion of both
referenced parent tasks, which <bcp14>MAY</bcp14> have been executed in parallel
by different agents.</t>
</section>
<section anchor="dag-vs-linear"><name>DAG vs Linear Delegation Chains</name>
<t>Several concurrent proposals for agent authorization model delegation
as an ordered, linear chain of tokens or principals. Examples include
the <spanx style="verb">actchain</spanx> claim of
<xref target="I-D.oauth-transaction-tokens-for-agents"/>, the Agentic JWT
construction of <xref target="AgenticJWT"/>, the AIP / Interaction-Bound Context Token
(IBCT) model of <xref target="AIP-IBCT"/>, and the delegation record defined in
<xref target="I-D.helixar-hdp-agentic-delegation"/>. In each of these
designs, the trail from the originator to the final executor is
represented as an ordered array recording one predecessor per hop.</t>
<section anchor="what-linear-chains-express-well"><name>What Linear Chains Express Well</name>
<t>Linear chains are a natural fit for simple sequential delegation:
agent A delegates to agent B, which delegates to agent C. The chain
records the history of that single hand-off in order, and verifiers
can walk from the current holder back to the originator without
branching. For interactive user-to-agent-to-service flows, where each
step has exactly one predecessor, a linear chain is both sufficient
and compact.</t>
</section>
<section anchor="limitations-of-linear-chains"><name>Limitations of Linear Chains</name>
<t>Agentic workflows in practice are rarely purely linear. Planner
agents dispatch parallel sub-tasks; synthesizer agents consume
results from multiple independent branches; tool calls execute
concurrently and their outputs are merged. A linear chain cannot
faithfully represent the following common topologies:</t>
<t><list style="symbols">
<t><strong>Fork</strong>: A single task spawns multiple independent sub-tasks. A
linear chain cannot express that two concurrent sub-executions
share a common parent authorization but are otherwise
independent; each sub-task would either omit its siblings or
fabricate a false ordering between them.</t>
<t><strong>Join (fan-in)</strong>: A task whose output depends on results from
several predecessors has no single prior hop. Linear chains
cannot express multiple-parent relationships without either
collapsing parallel branches into an arbitrary order or
duplicating records.</t>
<t><strong>Diamond dependencies</strong>: A planner dispatches parallel work and
later synthesizes the results. The synthesis step depends on
every branch, and all branches depend on the same planner.
This diamond shape requires a DAG; a linear chain forces the
verifier to pick one branch and discard the others.</t>
<t><strong>Cross-chain references</strong>: When two independently authorized
chains produce outputs that are later combined (e.g., a shared
cache lookup and a fresh retrieval), linear chains force a
single history and cannot record that the combined result has
two distinct provenances.</t>
</list></t>
</section>
<section anchor="acts-dag-approach"><name>ACT's DAG Approach</name>
<t>As specified in <xref target="jwt-claims-execution-phase"/>, the <spanx style="verb">pred</spanx> claim is
an array of parent <spanx style="verb">jti</spanx> values rather than a single scalar. This
allows an ACT to record:</t>
<t><list style="symbols">
<t>Zero parents (a root task, <spanx style="verb">pred = []</spanx>);</t>
<t>Exactly one parent (a linear chain, equivalent to the
single-predecessor designs referenced above);</t>
<t>Multiple parents (fan-in from parallel branches); and</t>
<t>Any acyclic shape that matches the actual execution structure.</t>
</list></t>
<t>The following example illustrates a diamond workflow. A research
agent (A) dispatches a web-search agent (B) and a code-analysis
agent (C) in parallel; both complete, and their outputs are
combined by a writer agent (D):</t>
<figure><artwork><![CDATA[
+-----+
| A | pred = []
+-----+
/ \
v v
+---+ +---+
| B | | C | pred = [A.jti]
+---+ +---+
\ /
v v
+-----+
| D | pred = [B.jti, C.jti]
+-----+
]]></artwork></figure>
<t>A linear <spanx style="verb">actchain</spanx> representation cannot express that D depends on
both B and C. At best, it can record one of the two parents and lose
the other, or serialize B and C into a false sequential order.</t>
</section>
<section anchor="verifiability-implications"><name>Verifiability Implications</name>
<t>With a DAG representation, an auditor holding the set of Phase 2
ACTs for a workflow can reconstruct the full execution graph, not
just one chain per final record. This matters for:</t>
<t><list style="symbols">
<t><strong>Debugging</strong>: identifying which branch contributed an erroneous
input to a downstream synthesis.</t>
<t><strong>Compliance</strong>: demonstrating that every input to a regulated
decision was itself authorized, not only the most recent hop.</t>
<t><strong>Tamper-evidence</strong>: detecting that a branch has been omitted,
since the surviving siblings' <spanx style="verb">pred</spanx> arrays name the missing
predecessor by <spanx style="verb">jti</spanx>.</t>
</list></t>
</section>
<section anchor="interoperability-with-linear-chain-designs"><name>Interoperability with Linear-Chain Designs</name>
<t>ACT's DAG reduces to a linear chain in the degenerate case where
every <spanx style="verb">pred</spanx> array has length zero or one. An implementation that
requires linear-chain semantics <bcp14>MAY</bcp14> treat such ACTs as equivalent
to <spanx style="verb">actchain</spanx>-style records and ignore the fork/join capability.
The reverse reduction is not available: a linear-chain-only design
cannot represent ACT DAG topologies without loss of information.</t>
<t>ACT therefore takes the linear chain as a strict subset of its
model rather than as a competing approach. The DAG generalization
is deliberate and is motivated by the concurrent, branching nature
of real agentic executions rather than by any deficiency in the
linear-chain designs for the sequential cases they target.</t>
</section>
</section>
</section>
<section anchor="verification-procedure"><name>Verification Procedure</name>
<section anchor="auth-verification"><name>Authorization Phase Verification</name>
<t>A receiving agent <bcp14>MUST</bcp14> verify a Phase 1 ACT as follows:</t>
<t><list style="numbers" type="1">
<t>Parse JWS Compact Serialization per <xref target="RFC7515"/>.</t>
<t>Verify <spanx style="verb">typ</spanx> is "act+jwt".</t>
<t>Verify <spanx style="verb">alg</spanx> is in the verifier's algorithm allowlist. The
allowlist <bcp14>MUST NOT</bcp14> include "none" or any symmetric algorithm.</t>
<t>Retrieve the public key for <spanx style="verb">kid</spanx> per the applicable trust tier
(<xref target="trust-model"/>).</t>
<t>Verify the JWS signature.</t>
<t>Verify <spanx style="verb">exp</spanx> has not passed (with clock skew tolerance:
<bcp14>RECOMMENDED</bcp14> maximum 5 minutes).</t>
<t>Verify <spanx style="verb">iat</spanx> is not unreasonably in the future (<bcp14>RECOMMENDED</bcp14>:
no more than 30 seconds ahead).</t>
<t>Verify <spanx style="verb">aud</spanx> contains the verifier's own identifier.</t>
<t>Verify <spanx style="verb">iss</spanx> is a trusted agent identity per local policy.</t>
<t>Verify <spanx style="verb">sub</spanx> matches the verifier's own identifier (the agent
is the intended recipient of this mandate).</t>
<t>Verify all required claims are present and well-formed.</t>
<t>Verify delegation chain (<xref target="delegation-verification"/>) if
<spanx style="verb">del.chain</spanx> is non-empty.</t>
<t>Verify capabilities are within policy limits.</t>
</list></t>
</section>
<section anchor="execution-phase-verification"><name>Execution Phase Verification</name>
<t>In addition to all Phase 1 verification steps, a verifier processing
a Phase 2 ACT <bcp14>MUST</bcp14>:</t>
<t><list style="numbers" type="1">
<t>Verify <spanx style="verb">exec_act</spanx> is present and matches an <spanx style="verb">action</spanx> in <spanx style="verb">cap</spanx>.</t>
<t>Verify <spanx style="verb">pred</spanx> is present and perform DAG validation
(<xref target="dag-validation"/>).</t>
<t>Verify <spanx style="verb">exec_ts</spanx> is present and is greater than or equal to
<spanx style="verb">iat</spanx>. If <spanx style="verb">exec_ts</spanx> is after <spanx style="verb">exp</spanx>, implementations <bcp14>SHOULD</bcp14> log
a warning but <bcp14>MUST NOT</bcp14> reject the record solely on this basis.</t>
<t>Verify <spanx style="verb">status</spanx> is present and has a valid value.</t>
<t>Verify the re-signature was produced by the <spanx style="verb">sub</spanx> agent (the
executing agent), not the <spanx style="verb">iss</spanx> agent (the mandating agent).
This is verified by checking that the <spanx style="verb">kid</spanx> in the Phase 2 JOSE
header corresponds to the <spanx style="verb">sub</spanx> agent's public key.</t>
<t>If <spanx style="verb">inp_hash</spanx> or <spanx style="verb">out_hash</spanx> are present, verify them against
locally available input/output data when possible.</t>
</list></t>
</section>
</section>
<section anchor="transport"><name>Transport</name>
<section anchor="http-header-transport"><name>HTTP Header Transport</name>
<t>This specification defines two HTTP <xref target="RFC9110"/> header fields for ACT
transport:</t>
<t><strong>ACT-Mandate</strong>: Carries a Phase 1 ACT issued by an upstream agent
or operator. Value is the JWS Compact Serialization of the ACT.</t>
<figure><artwork><![CDATA[
GET /api/safety-check HTTP/1.1
Host: safety-agent.example.com
ACT-Mandate: eyJhbGci...Phase1ACT...
]]></artwork></figure>
<t><strong>ACT-Record</strong>: Carries a Phase 2 ACT from a predecessor agent,
serving as evidence of completed prerequisites.</t>
<figure><artwork><![CDATA[
POST /api/downstream HTTP/1.1
Host: downstream-agent.example.com
ACT-Mandate: eyJhbGci...Phase1ACT...
ACT-Record: eyJhbGci...Phase2ACT...
]]></artwork></figure>
<t>Multiple <spanx style="verb">ACT-Record</spanx> header lines <bcp14>MAY</bcp14> be included when a task has
multiple completed predecessors (DAG fan-in). If any single ACT-Record
fails verification, the receiver <bcp14>MUST</bcp14> reject the entire request.</t>
</section>
<section anchor="non-http-transports"><name>Non-HTTP Transports</name>
<t>For non-HTTP transports (MCP stdio, A2A message queues, AMQP, etc.),
ACTs <bcp14>SHOULD</bcp14> be carried as a dedicated field in the transport's
metadata envelope. The field name <bcp14>SHOULD</bcp14> be <spanx style="verb">act_mandate</spanx> for Phase 1
ACTs and <spanx style="verb">act_record</spanx> for Phase 2 ACTs. Implementations <bcp14>MUST</bcp14> use the
JWS Compact Serialization form in all transports.</t>
</section>
</section>
<section anchor="audit-ledger"><name>Audit Ledger Interface</name>
<t>Phase 2 ACTs <bcp14>SHOULD</bcp14> be submitted to an immutable audit ledger.
A ledger is <bcp14>RECOMMENDED</bcp14> for regulated environments but is not
required for basic ACT operation. This specification does not
mandate a specific storage technology.</t>
<t>When an audit ledger is deployed, the implementation <bcp14>MUST</bcp14> provide:</t>
<t><list style="numbers" type="1">
<t><strong>Append-only semantics</strong>: Once an ACT is recorded, it <bcp14>MUST NOT</bcp14>
be modified or deleted.</t>
<t><strong>Ordering</strong>: A monotonically increasing sequence number per
recorded ACT.</t>
<t><strong>Lookup</strong>: Efficient retrieval by <spanx style="verb">jti</spanx> value.</t>
<t><strong>Integrity</strong>: A cryptographic commitment scheme over recorded
ACTs (e.g., hash-chaining, Merkle tree anchoring, or SCITT
registration per <xref target="I-D.ietf-scitt-architecture"/>).</t>
</list></t>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<section anchor="threat-model"><name>Threat Model</name>
<t>ACT assumes an adversarial environment where:</t>
<t><list style="symbols">
<t>Individual agents may be compromised.</t>
<t>Network paths may be intercepted (mitigated by transport security).</t>
<t>Attackers may attempt to replay valid ACTs from prior interactions.</t>
<t>Colluding agents may attempt to fabricate execution records.</t>
<t>Agents may attempt privilege escalation via manipulated delegation
chains.</t>
</list></t>
<t>ACT does NOT assume:</t>
<t><list style="symbols">
<t>A trusted central authority (by design).</t>
<t>Synchronized clocks beyond the stated skew tolerance.</t>
<t>Availability of external network services during verification.</t>
</list></t>
</section>
<section anchor="self-assertion-limitation"><name>Self-Assertion Limitation</name>
<t>Phase 2 ACTs are self-asserted: an executing agent signs its own
execution record. A compromised agent with an intact private key can
produce Phase 2 ACTs claiming arbitrary inputs, outputs, and action
types, as long as the claimed <spanx style="verb">exec_act</spanx> matches an authorized
capability.</t>
<t>This is a fundamental limitation of self-sovereign attestation. It
is the same limitation affecting WIMSE ECT
<xref target="I-D.nennemann-wimse-ect"/>.</t>
<t>Mitigations:</t>
<t><list style="symbols">
<t><strong>Cross-agent corroboration</strong>: A receiving agent that processes
an ACT-Record as a prerequisite independently verifies that the
claimed <spanx style="verb">out_hash</spanx> matches the data it actually received.</t>
<t><strong>Ledger sequencing</strong>: An append-only ledger with monotonic
sequence numbers prevents retroactive insertion of fabricated
records.</t>
<t><strong>SCITT anchoring</strong>: For high-assurance deployments, Phase 2 ACTs
<bcp14>SHOULD</bcp14> be anchored to a SCITT Transparency Service, providing
external witness that the record was submitted at a claimed time.</t>
</list></t>
</section>
<section anchor="key-compromise"><name>Key Compromise</name>
<t>If an agent's private key is compromised, an attacker can issue
arbitrary Phase 1 mandates (impersonating the agent as an issuer)
and fabricate Phase 2 records (impersonating the agent as an
executor).</t>
<t>Key compromise response:</t>
<t><list style="numbers" type="1">
<t>The compromised agent's identifier <bcp14>MUST</bcp14> be added to all
verifiers' deny lists.</t>
<t>In Tier 2 (PKI) deployments, the certificate <bcp14>MUST</bcp14> be revoked
via CRL or OCSP.</t>
<t>In Tier 3 (DID) deployments, the DID Document <bcp14>MUST</bcp14> be updated
to revoke the compromised key.</t>
<t>In Tier 1 (pre-shared key) deployments, both parties <bcp14>MUST</bcp14>
perform an out-of-band key rotation.</t>
</list></t>
<t>ACT chains that include records signed by a compromised key <bcp14>MUST</bcp14>
be treated as potentially tainted from the point of compromise.
Audit systems <bcp14>MUST</bcp14> flag all ACTs signed after the estimated
compromise time.</t>
</section>
<section anchor="replay-attack-prevention"><name>Replay Attack Prevention</name>
<t><spanx style="verb">jti</spanx> uniqueness within the applicable scope (workflow or global)
provides replay detection. Verifiers <bcp14>MUST</bcp14> reject ACTs whose <spanx style="verb">jti</spanx>
has already been seen and processed.</t>
<t><spanx style="verb">exp</spanx> provides a time-bounded replay window. Verifiers <bcp14>MUST</bcp14> reject
expired ACTs. The combination of <spanx style="verb">jti</spanx> and <spanx style="verb">exp</spanx> means that replay
detection state only needs to be maintained for the duration of token
lifetimes.</t>
</section>
<section anchor="equivocation"><name>Equivocation</name>
<t>In standalone deployment (no audit ledger, no SCITT anchoring), ACT
does NOT provide non-equivocation guarantees. A compromised agent
can maintain two valid ACT chains — presenting Phase 2 records with
different <spanx style="verb">out_hash</spanx> values to different verifiers — and both will
pass independent verification.</t>
<t><strong>Deployments claiming DORA <xref target="DORA"/> Article 10/11 compliance or EU AI
Act <xref target="EUAIA"/> Article 12 compliance <bcp14>MUST</bcp14> use one of:</strong></t>
<t>(a) A shared append-only audit ledger visible to all relevant parties,
with cryptographic integrity (hash chaining or Merkle trees).</t>
<t>(b) SCITT anchoring <xref target="I-D.ietf-scitt-architecture"/> providing external
Transparency Service receipts.</t>
<t>Standalone ACT provides tamper detection (a verifier can detect
modification of a record it has seen) but not split-view prevention
(a verifier cannot detect a different record shown to another
verifier).</t>
</section>
<section anchor="privilege-escalation"><name>Privilege Escalation</name>
<t>Verifiers <bcp14>MUST</bcp14> check that each step in <spanx style="verb">del.chain</spanx> reduces or
maintains (never increases) the capabilities relative to the
preceding step. Implementations <bcp14>MUST</bcp14> reject ACTs where:</t>
<t><list style="symbols">
<t><spanx style="verb">del.depth</spanx> exceeds <spanx style="verb">del.max_depth</spanx>.</t>
<t><spanx style="verb">cap</spanx> contains actions not present in any referenced parent ACT.</t>
<t>Constraints in <spanx style="verb">cap</spanx> are less restrictive than those in the parent.</t>
</list></t>
</section>
<section anchor="denial-of-service"><name>Denial of Service</name>
<t>ACT verification is more computationally expensive than standard JWT
validation due to delegation chain verification and DAG traversal.</t>
<t>Mitigations:</t>
<t><list style="symbols">
<t>Reject ACTs larger than 64KB before parsing.</t>
<t>Enforce maximum <spanx style="verb">del.chain</spanx> length (<bcp14>RECOMMENDED</bcp14>: 10 entries).</t>
<t>Enforce maximum DAG ancestor traversal depth (<bcp14>RECOMMENDED</bcp14>: 10,000
nodes, <xref target="dag-validation"/>).</t>
<t>Cache verification results for recently seen <spanx style="verb">jti</spanx> values within
the token lifetime window.</t>
</list></t>
</section>
</section>
<section anchor="privacy-considerations"><name>Privacy Considerations</name>
<t>ACT tokens and audit ledger records may contain information that
identifies agents, organizations, or individuals. Implementations
<bcp14>SHOULD</bcp14> apply data minimization principles:</t>
<t><list style="symbols">
<t><spanx style="verb">task.created_by</spanx> <bcp14>SHOULD</bcp14> use a pseudonymous identifier rather
than a personal email address or real name.</t>
<t><spanx style="verb">task.purpose</spanx> <bcp14>SHOULD</bcp14> use a controlled vocabulary code rather
than free-text descriptions that may contain personal data.</t>
<t><spanx style="verb">del.chain</spanx> entries reveal organizational structure. Cross-
organizational delegation chains <bcp14>SHOULD</bcp14> use Tier 3 (DID)
identifiers that do not reveal organizational affiliation.</t>
<t><spanx style="verb">inp_hash</spanx> and <spanx style="verb">out_hash</spanx> are hashes of data, not the data
itself, and do not constitute personal data under GDPR
Article 4(1) provided the underlying data is not trivially
reversible (e.g., hashes of very short strings).</t>
</list></t>
<t>For GDPR Article 17 (right to erasure) compliance, audit ledgers
<bcp14>SHOULD</bcp14> store only ACT tokens (which contain hashes, not raw data)
and <bcp14>SHOULD</bcp14> implement crypto-shredding for any associated encrypted
payloads.</t>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<section anchor="media-type-registration"><name>Media Type Registration</name>
<t>This document requests registration of the following media type:</t>
<t><list style="symbols">
<t>Type name: application</t>
<t>Subtype name: act+jwt</t>
<t>Required parameters: none</t>
<t>Encoding considerations: binary (base64url-encoded JWT)</t>
<t>Security considerations: See <xref target="security-considerations"/>.</t>
<t>Interoperability considerations: See <xref target="auth-verification"/>.</t>
<t>Specification: This document.</t>
</list></t>
</section>
<section anchor="http-header-field-registration"><name>HTTP Header Field Registration</name>
<t>This document requests registration of the following HTTP header
fields in the "Hypertext Transfer Protocol (HTTP) Field Name
Registry":</t>
<t><list style="symbols">
<t>Header field name: ACT-Mandate</t>
<t>Applicable protocol: HTTP</t>
<t>Status: permanent</t>
<t>Specification: This document, <xref target="http-header-transport"/>.</t>
<t>Header field name: ACT-Record</t>
<t>Applicable protocol: HTTP</t>
<t>Status: permanent</t>
<t>Specification: This document, <xref target="http-header-transport"/>.</t>
</list></t>
</section>
<section anchor="jwt-claims-registration"><name>JWT Claims Registration</name>
<t>This document requests registration of the following claims in the
IANA "JSON Web Token Claims" registry:</t>
<texttable>
<ttcol align='left'>Claim Name</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>wid</c>
<c>Workflow identifier</c>
<c>This document</c>
<c>task</c>
<c>Task authorization context</c>
<c>This document</c>
<c>cap</c>
<c>Capabilities with constraints</c>
<c>This document</c>
<c>oversight</c>
<c>Human oversight requirements</c>
<c>This document</c>
<c>del</c>
<c>Delegation provenance chain</c>
<c>This document</c>
<c>exec_act</c>
<c>Executed action identifier</c>
<c>This document</c>
<c>pred</c>
<c>Predecessor task identifiers (DAG)</c>
<c>This document</c>
<c>inp_hash</c>
<c>SHA-256 hash of task input</c>
<c>This document</c>
<c>out_hash</c>
<c>SHA-256 hash of task output</c>
<c>This document</c>
<c>exec_ts</c>
<c>Actual execution timestamp</c>
<c>This document</c>
<c>status</c>
<c>Execution status</c>
<c>This document</c>
<c>err</c>
<c>Execution error context</c>
<c>This document</c>
</texttable>
</section>
</section>
</middle>
<back>
<references title='References' anchor="sec-combined-references">
<references title='Normative References' anchor="sec-normative-references">
<reference anchor="RFC7515">
<front>
<title>JSON Web Signature (JWS)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
<date month="May" year="2015"/>
<abstract>
<t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7515"/>
<seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>
<reference anchor="RFC7517">
<front>
<title>JSON Web Key (JWK)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<date month="May" year="2015"/>
<abstract>
<t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7517"/>
<seriesInfo name="DOI" value="10.17487/RFC7517"/>
</reference>
<reference anchor="RFC7518">
<front>
<title>JSON Web Algorithms (JWA)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<date month="May" year="2015"/>
<abstract>
<t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7518"/>
<seriesInfo name="DOI" value="10.17487/RFC7518"/>
</reference>
<reference anchor="RFC7519">
<front>
<title>JSON Web Token (JWT)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
<date month="May" year="2015"/>
<abstract>
<t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7519"/>
<seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>
<reference anchor="RFC8037">
<front>
<title>CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)</title>
<author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
<date month="January" year="2017"/>
<abstract>
<t>This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8037"/>
<seriesInfo name="DOI" value="10.17487/RFC8037"/>
</reference>
<reference anchor="RFC9110">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="RFC9562">
<front>
<title>Universally Unique IDentifiers (UUIDs)</title>
<author fullname="K. Davis" initials="K." surname="Davis"/>
<author fullname="B. Peabody" initials="B." surname="Peabody"/>
<author fullname="P. Leach" initials="P." surname="Leach"/>
<date month="May" year="2024"/>
<abstract>
<t>This specification defines UUIDs (Universally Unique IDentifiers) --
also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform
Resource Name namespace for UUIDs. A UUID is 128 bits long and is
intended to guarantee uniqueness across space and time. UUIDs were
originally used in the Apollo Network Computing System (NCS), later
in the Open Software Foundation's (OSF's) Distributed Computing
Environment (DCE), and then in Microsoft Windows platforms.</t>
<t>This specification is derived from the OSF DCE specification with the
kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have
been incorporated into this document. This document obsoletes RFC
4122.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9562"/>
<seriesInfo name="DOI" value="10.17487/RFC9562"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references>
<references title='Informative References' anchor="sec-informative-references">
<reference anchor="RFC7009">
<front>
<title>OAuth 2.0 Token Revocation</title>
<author fullname="T. Lodderstedt" initials="T." role="editor" surname="Lodderstedt"/>
<author fullname="S. Dronia" initials="S." surname="Dronia"/>
<author fullname="M. Scurtescu" initials="M." surname="Scurtescu"/>
<date month="August" year="2013"/>
<abstract>
<t>This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7009"/>
<seriesInfo name="DOI" value="10.17487/RFC7009"/>
</reference>
<reference anchor="RFC8693">
<front>
<title>OAuth 2.0 Token Exchange</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="A. Nadalin" initials="A." surname="Nadalin"/>
<author fullname="B. Campbell" initials="B." role="editor" surname="Campbell"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="C. Mortimore" initials="C." surname="Mortimore"/>
<date month="January" year="2020"/>
<abstract>
<t>This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8693"/>
<seriesInfo name="DOI" value="10.17487/RFC8693"/>
</reference>
<reference anchor="I-D.nennemann-wimse-ect" target="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/">
<front>
<title>Execution Context Tokens for Distributed Agentic Workflows</title>
<author fullname="Christian Nennemann">
<organization></organization>
</author>
<date year="2026"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-nennemann-wimse-ect-02"/>
</reference>
<reference anchor="I-D.ietf-scitt-architecture">
<front>
<title>An Architecture for Trustworthy and Transparent Digital Supply Chains</title>
<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
<organization>Fraunhofer SIT</organization>
</author>
<author fullname="Antoine Delignat-Lavaud" initials="A." surname="Delignat-Lavaud">
<organization>Microsoft Research</organization>
</author>
<author fullname="Cedric Fournet" initials="C." surname="Fournet">
<organization>Microsoft Research</organization>
</author>
<author fullname="Yogesh Deshpande" initials="Y." surname="Deshpande">
<organization>ARM</organization>
</author>
<author fullname="Steve Lasker" initials="S." surname="Lasker">
</author>
<date day="10" month="October" year="2025"/>
<abstract>
<t> Traceability in supply chains is a growing security concern. While
verifiable data structures have addressed specific issues, such as
equivocation over digital certificates, they lack a universal
architecture for all supply chains. This document defines such an
architecture for single-issuer signed statement transparency. It
ensures extensibility, interoperability between different
transparency services, and compliance with various auditing
procedures and regulatory requirements.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-scitt-architecture-22"/>
</reference>
<reference anchor="I-D.oauth-transaction-tokens-for-agents" target="https://datatracker.ietf.org/doc/draft-oauth-transaction-tokens-for-agents/">
<front>
<title>Transaction Tokens for Agentic AI Systems</title>
<author fullname="Fletcher, G.">
<organization></organization>
</author>
<date year="2026"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-oauth-transaction-tokens-for-agents-06"/>
</reference>
<reference anchor="I-D.aap-oauth-profile" target="https://datatracker.ietf.org/doc/draft-aap-oauth-profile/">
<front>
<title>Agent Authorization Profile (AAP) for OAuth 2.0</title>
<author fullname="Cruz, A.">
<organization></organization>
</author>
<date year="2026" month="February"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-aap-oauth-profile-01"/>
</reference>
<reference anchor="I-D.helixar-hdp-agentic-delegation" target="https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/">
<front>
<title>Helixar Delegation Protocol (HDP) for Agentic Delegation</title>
<author >
<organization>Helixar</organization>
</author>
<date year="2026"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-helixar-hdp-agentic-delegation-00"/>
</reference>
<reference anchor="I-D.emirdag-scitt-ai-agent-execution" target="https://datatracker.ietf.org/doc/draft-emirdag-scitt-ai-agent-execution/">
<front>
<title>A SCITT Profile for AI Agent Execution Records</title>
<author fullname="Emirdag">
<organization></organization>
</author>
<date year="2026" month="April"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-emirdag-scitt-ai-agent-execution-00"/>
</reference>
<reference anchor="AgenticJWT" target="https://arxiv.org/abs/2509.13597">
<front>
<title>Agentic JWT: A JSON Web Token Profile for Delegated Agent Authorization</title>
<author >
<organization></organization>
</author>
<date year="2025"/>
</front>
</reference>
<reference anchor="AIP-IBCT" target="https://arxiv.org/abs/2603.24775">
<front>
<title>AIP: Agent Interaction Protocol with Interaction-Bound Context Tokens</title>
<author fullname="Prakash, S.">
<organization></organization>
</author>
<date year="2026" month="March"/>
</front>
</reference>
<reference anchor="SentinelAgent" target="https://arxiv.org/abs/2604.02767">
<front>
<title>SentinelAgent: A Formal Delegation Chain Calculus for Verifiable Agent Authorization</title>
<author fullname="Patil">
<organization></organization>
</author>
<date year="2026" month="April"/>
</front>
</reference>
<reference anchor="MCP-SPEC" target="https://modelcontextprotocol.io/specification/2025-11-25">
<front>
<title>Model Context Protocol Specification</title>
<author >
<organization></organization>
</author>
<date year="2025" month="November" day="25"/>
</front>
</reference>
<reference anchor="OPENAI-AGENTS-SDK" target="https://openai.github.io/openai-agents-python/">
<front>
<title>OpenAI Agents SDK</title>
<author >
<organization>OpenAI</organization>
</author>
<date />
</front>
</reference>
<reference anchor="LANGGRAPH" target="https://langchain-ai.github.io/langgraph/">
<front>
<title>LangGraph Documentation</title>
<author >
<organization>LangChain</organization>
</author>
<date />
</front>
</reference>
<reference anchor="A2A-SPEC" target="https://github.com/a2aproject/A2A">
<front>
<title>Agent2Agent (A2A) Protocol</title>
<author >
<organization>Google</organization>
</author>
<date />
</front>
</reference>
<reference anchor="CREWAI" target="https://docs.crewai.com/">
<front>
<title>CrewAI Documentation</title>
<author >
<organization>CrewAI</organization>
</author>
<date />
</front>
</reference>
<reference anchor="AUTOGEN" target="https://microsoft.github.io/autogen/">
<front>
<title>AutoGen Documentation</title>
<author >
<organization>Microsoft</organization>
</author>
<date />
</front>
</reference>
<reference anchor="W3C-DID" target="https://www.w3.org/TR/did-core/">
<front>
<title>Decentralized Identifiers (DIDs) v1.0</title>
<author fullname="Sporny, M.">
<organization></organization>
</author>
<date year="2022" month="July"/>
</front>
</reference>
<reference anchor="DID-KEY" target="https://w3c-ccg.github.io/did-method-key/">
<front>
<title>The did:key Method v0.7</title>
<author fullname="Longley, D.">
<organization></organization>
</author>
<date year="2021"/>
</front>
</reference>
<reference anchor="DID-WEB" target="https://w3c-ccg.github.io/did-method-web/">
<front>
<title>did:web Method Specification</title>
<author fullname="Steele, O.">
<organization></organization>
</author>
<date year="2022"/>
</front>
</reference>
<reference anchor="DORA" target="https://eur-lex.europa.eu/eli/reg/2022/2554/oj">
<front>
<title>Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554</title>
<author >
<organization>European Parliament</organization>
</author>
<date year="2022"/>
</front>
</reference>
<reference anchor="EUAIA" target="https://eur-lex.europa.eu/eli/reg/2024/1689/oj">
<front>
<title>EU Artificial Intelligence Act, Regulation (EU) 2024/1689</title>
<author >
<organization>European Parliament</organization>
</author>
<date year="2024"/>
</front>
</reference>
<reference anchor="IEC62304" target="https://www.iec.ch/">
<front>
<title>Medical device software — Software life cycle processes, IEC 62304:2006+AMD1:2015</title>
<author >
<organization>IEC</organization>
</author>
<date year="2015"/>
</front>
</reference>
</references>
</references>
<?line 1702?>
<section numbered="false" anchor="appendix-a-complete-json-schema"><name>Appendix A: Complete JSON Schema</name>
<t>The following JSON Schema (2020-12) describes the claim set of ACT
Phase 1 (Authorization Mandate) and Phase 2 (Execution Record)
tokens. A token is a Phase 2 record if and only if it contains the
<spanx style="verb">exec_act</spanx>, <spanx style="verb">exec_ts</spanx>, <spanx style="verb">pred</spanx>, and <spanx style="verb">status</spanx> claims; otherwise it is
a Phase 1 mandate. The schema validates structure only; semantic
rules (capability subset on delegation, <spanx style="verb">exec_act</spanx> membership in
<spanx style="verb">cap</spanx>, DAG acyclicity, depth bounds) are specified normatively in
the body of this document and cannot be expressed in JSON Schema.</t>
<figure><sourcecode type="json"><![CDATA[
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "urn:ietf:params:act:schema:token",
"title": "Agent Context Token (ACT)",
"type": "object",
"oneOf": [
{ "$ref": "#/$defs/phase1" },
{ "$ref": "#/$defs/phase2" }
],
"$defs": {
"actionName": {
"type": "string",
"pattern": "^[A-Za-z][A-Za-z0-9_-]*(\\.[A-Za-z][A-Za-z0-9_-]*)*$"
},
"numericDate": { "type": "integer", "minimum": 0 },
"uuid": {
"type": "string",
"format": "uuid"
},
"audience": {
"oneOf": [
{ "type": "string" },
{
"type": "array",
"items": { "type": "string" },
"minItems": 1
}
]
},
"task": {
"type": "object",
"required": ["purpose"],
"properties": {
"purpose": { "type": "string", "minLength": 1 },
"data_sensitivity": {
"type": "string",
"enum": [
"public", "internal", "confidential", "restricted"
]
},
"created_by": { "type": "string" },
"expires_at": { "$ref": "#/$defs/numericDate" }
},
"additionalProperties": true
},
"capability": {
"type": "object",
"required": ["action"],
"properties": {
"action": { "$ref": "#/$defs/actionName" },
"constraints": { "type": "object" }
},
"additionalProperties": false
},
"oversight": {
"type": "object",
"properties": {
"requires_approval_for": {
"type": "array",
"items": { "$ref": "#/$defs/actionName" }
},
"approval_ref": { "type": "string" }
},
"additionalProperties": false
},
"delegationEntry": {
"type": "object",
"required": ["delegator", "jti", "sig"],
"properties": {
"delegator": { "type": "string" },
"jti": { "$ref": "#/$defs/uuid" },
"sig": { "type": "string" }
},
"additionalProperties": false
},
"delegation": {
"type": "object",
"required": ["depth", "max_depth", "chain"],
"properties": {
"depth": { "type": "integer", "minimum": 0 },
"max_depth": { "type": "integer", "minimum": 0 },
"chain": {
"type": "array",
"items": { "$ref": "#/$defs/delegationEntry" }
}
},
"additionalProperties": false
},
"error": {
"type": "object",
"required": ["code"],
"properties": {
"code": { "type": "string" },
"detail": { "type": "string" }
},
"additionalProperties": false
},
"commonClaims": {
"type": "object",
"required": [
"iss", "sub", "aud", "iat", "exp", "jti", "task", "cap"
],
"properties": {
"iss": { "type": "string" },
"sub": { "type": "string" },
"aud": { "$ref": "#/$defs/audience" },
"iat": { "$ref": "#/$defs/numericDate" },
"exp": { "$ref": "#/$defs/numericDate" },
"jti": { "$ref": "#/$defs/uuid" },
"wid": { "$ref": "#/$defs/uuid" },
"task": { "$ref": "#/$defs/task" },
"cap": {
"type": "array",
"minItems": 1,
"items": { "$ref": "#/$defs/capability" }
},
"oversight": { "$ref": "#/$defs/oversight" },
"del": { "$ref": "#/$defs/delegation" }
}
},
"phase1": {
"allOf": [{ "$ref": "#/$defs/commonClaims" }],
"not": {
"anyOf": [
{ "required": ["exec_act"] },
{ "required": ["exec_ts"] },
{ "required": ["status"] }
]
}
},
"phase2": {
"allOf": [{ "$ref": "#/$defs/commonClaims" }],
"required": ["exec_act", "pred", "exec_ts", "status"],
"properties": {
"exec_act": { "$ref": "#/$defs/actionName" },
"pred": {
"type": "array",
"items": { "$ref": "#/$defs/uuid" }
},
"inp_hash": { "type": "string" },
"out_hash": { "type": "string" },
"exec_ts": { "$ref": "#/$defs/numericDate" },
"status": {
"type": "string",
"enum": ["completed", "failed", "partial"]
},
"err": { "$ref": "#/$defs/error" }
}
}
}
}
]]></sourcecode></figure>
</section>
<section numbered="false" anchor="appendix-b-test-vectors"><name>Appendix B: Test Vectors</name>
<t>All vectors in this appendix are produced by the reference implementation using fixed Ed25519 seeds and fixed identifiers, and are therefore reproducible. The base timestamp (iat) is 1772064000 (2026-02-26T00:00:00Z). Long Base64url values are wrapped for display only; line breaks are not part of the value.</t>
<section numbered="false" anchor="b0-key-material"><name>B.0. Key Material</name>
<t>Three Ed25519 key pairs are used, identified by kid. Keys are given in JWK <xref target="RFC7517"/> form using the Ed25519 OKP encoding <xref target="RFC8037"/>; "d" is the private seed and "x" is the public key, both Base64url-encoded. These seeds are recognizable test patterns and <bcp14>MUST NOT</bcp14> be used in production.</t>
<figure><sourcecode type="json"><![CDATA[
{
"kty": "OKP",
"crv": "Ed25519",
"kid": "iss-key",
"d": "AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8",
"x": "A6EHv_POEL4dcN0Y50vAmWfk1jCbpQ1fHdyGZBJVMbg"
}
]]></sourcecode></figure>
<figure><sourcecode type="json"><![CDATA[
{
"kty": "OKP",
"crv": "Ed25519",
"kid": "sub-key",
"d": "ICEiIyQlJicoKSorLC0uLzAxMjM0NTY3ODk6Ozw9Pj8",
"x": "Kay64UG8yvCyLhqU000LxzYeUm0L_hLIl5S8kyKWbdc"
}
]]></sourcecode></figure>
<figure><sourcecode type="json"><![CDATA[
{
"kty": "OKP",
"crv": "Ed25519",
"kid": "agent-c-key",
"d": "QEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaW1xdXl8",
"x": "JUO5L_EJVRFHatyDadtt3JM2ZaEZeN2hQE7hBmypVZ0"
}
]]></sourcecode></figure>
</section>
<section numbered="false" anchor="b1-valid-phase-1-act-root-mandate-tier-1-ed25519-no-delegation"><name>B.1. Valid Phase 1 ACT: root mandate, Tier 1 (Ed25519), no delegation</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "iss-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "agent-subject",
"aud": [
"agent-subject",
"https://ledger.example.com"
],
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"task": {
"purpose": "validate_data",
"data_sensitivity": "restricted"
},
"cap": [
{
"action": "read.data",
"constraints": {
"max_records": 10
}
},
{
"action": "write.result"
}
],
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"del": {
"depth": 0,
"max_depth": 2,
"chain": []
}
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJpc3Mta2V5In0.
eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
IjpbImFnZW50LXN1YmplY3QiLCJodHRwczovL2xlZGdlci5leGFtcGxlLmNvbSJd
LCJpYXQiOjE3NzIwNjQwMDAsImV4cCI6MTc3MjA2NDkwMCwianRpIjoiNTUwZTg0
MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDAxIiwidGFzayI6eyJwdXJwb3Nl
IjoidmFsaWRhdGVfZGF0YSIsImRhdGFfc2Vuc2l0aXZpdHkiOiJyZXN0cmljdGVk
In0sImNhcCI6W3siYWN0aW9uIjoicmVhZC5kYXRhIiwiY29uc3RyYWludHMiOnsi
bWF4X3JlY29yZHMiOjEwfX0seyJhY3Rpb24iOiJ3cml0ZS5yZXN1bHQifV0sIndp
ZCI6ImEwYjFjMmQzLWU0ZjUtNjc4OS1hYmNkLWVmMDEyMzQ1Njc4OSIsImRlbCI6
eyJkZXB0aCI6MCwibWF4X2RlcHRoIjoyLCJjaGFpbiI6W119fQ._nVgyp4X0zYvy
ylbyBgE_CWKAVdEMFgHjHIUkhxEsr83PQw_rzxNryDd179_KdkCo_kxWDbfmEQV-
JA1-pknBA
]]></artwork></figure>
<t>Expected result: Accept. The signature verifies under kid "iss-key" and all required Phase 1 claims are present.</t>
</section>
<section numbered="false" anchor="b2-valid-phase-2-act-completed-execution-transition-from-b1"><name>B.2. Valid Phase 2 ACT: completed execution (transition from B.1)</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "sub-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "agent-subject",
"aud": [
"agent-subject",
"https://ledger.example.com"
],
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"task": {
"purpose": "validate_data",
"data_sensitivity": "restricted"
},
"cap": [
{
"action": "read.data",
"constraints": {
"max_records": 10
}
},
{
"action": "write.result"
}
],
"exec_act": "read.data",
"pred": [],
"exec_ts": 1772064300,
"status": "completed",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"del": {
"depth": 0,
"max_depth": 2,
"chain": []
},
"inp_hash": "DHooOQxm8XoCuW4a2BOMC2ZP8VyzFYj1gRvKzRdfX_g",
"out_hash": "n24FIk7teYuF6yXfVBqJ9THKIWuU9C0M5qlGlhLtx2U"
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJzdWIta2V5In0.
eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
IjpbImFnZW50LXN1YmplY3QiLCJodHRwczovL2xlZGdlci5leGFtcGxlLmNvbSJd
LCJpYXQiOjE3NzIwNjQwMDAsImV4cCI6MTc3MjA2NDkwMCwianRpIjoiNTUwZTg0
MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDAxIiwidGFzayI6eyJwdXJwb3Nl
IjoidmFsaWRhdGVfZGF0YSIsImRhdGFfc2Vuc2l0aXZpdHkiOiJyZXN0cmljdGVk
In0sImNhcCI6W3siYWN0aW9uIjoicmVhZC5kYXRhIiwiY29uc3RyYWludHMiOnsi
bWF4X3JlY29yZHMiOjEwfX0seyJhY3Rpb24iOiJ3cml0ZS5yZXN1bHQifV0sImV4
ZWNfYWN0IjoicmVhZC5kYXRhIiwicHJlZCI6W10sImV4ZWNfdHMiOjE3NzIwNjQz
MDAsInN0YXR1cyI6ImNvbXBsZXRlZCIsIndpZCI6ImEwYjFjMmQzLWU0ZjUtNjc4
OS1hYmNkLWVmMDEyMzQ1Njc4OSIsImRlbCI6eyJkZXB0aCI6MCwibWF4X2RlcHRo
IjoyLCJjaGFpbiI6W119LCJpbnBfaGFzaCI6IkRIb29PUXhtOFhvQ3VXNGEyQk9N
QzJaUDhWeXpGWWoxZ1J2S3pSZGZYX2ciLCJvdXRfaGFzaCI6Im4yNEZJazd0ZVl1
RjZ5WGZWQnFKOVRIS0lXdVU5QzBNNXFsR2xoTHR4MlUifQ.ByEeEiMp2MwLHEeiF
iaV-fRjJw37VdIWahoaGdtR3EnlRMxI01jN9-TuPnUSDqIAf8yfzbri3FTjb02zX
h0LBA
]]></artwork></figure>
<t>Expected result: Accept. Phase 2 record; the signature verifies under kid "sub-key" and exec_act "read.data" is present in cap.</t>
</section>
<section numbered="false" anchor="b3-valid-phase-2-act-fan-in-with-two-predecessor-tasks"><name>B.3. Valid Phase 2 ACT: fan-in with two predecessor tasks</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "sub-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "agent-subject",
"aud": "agent-subject",
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-446655440005",
"task": {
"purpose": "merge_results"
},
"cap": [
{
"action": "compute.result"
}
],
"exec_act": "compute.result",
"pred": [
"550e8400-e29b-41d4-a716-446655440003",
"550e8400-e29b-41d4-a716-446655440004"
],
"exec_ts": 1772064200,
"status": "completed",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"del": {
"depth": 0,
"max_depth": 1,
"chain": []
}
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJzdWIta2V5In0.
eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
IjoiYWdlbnQtc3ViamVjdCIsImlhdCI6MTc3MjA2NDAwMCwiZXhwIjoxNzcyMDY0
OTAwLCJqdGkiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDUi
LCJ0YXNrIjp7InB1cnBvc2UiOiJtZXJnZV9yZXN1bHRzIn0sImNhcCI6W3siYWN0
aW9uIjoiY29tcHV0ZS5yZXN1bHQifV0sImV4ZWNfYWN0IjoiY29tcHV0ZS5yZXN1
bHQiLCJwcmVkIjpbIjU1MGU4NDAwLWUyOWItNDFkNC1hNzE2LTQ0NjY1NTQ0MDAw
MyIsIjU1MGU4NDAwLWUyOWItNDFkNC1hNzE2LTQ0NjY1NTQ0MDAwNCJdLCJleGVj
X3RzIjoxNzcyMDY0MjAwLCJzdGF0dXMiOiJjb21wbGV0ZWQiLCJ3aWQiOiJhMGIx
YzJkMy1lNGY1LTY3ODktYWJjZC1lZjAxMjM0NTY3ODkiLCJkZWwiOnsiZGVwdGgi
OjAsIm1heF9kZXB0aCI6MSwiY2hhaW4iOltdfX0.Koikd5apdJ1LLfdl0n0-arQ4
nDWbrygFImdE8QMKtWFwE35bIjIlr8ILXcr-0jDOBt0IJa8b_0yZROkUPlEgCA
]]></artwork></figure>
<t>Expected result: Accept. Phase 2 fan-in; pred lists the two predecessor jti values from the parallel branches.</t>
</section>
<section numbered="false" anchor="b4-valid-phase-1-act-delegated-mandate-depth-1"><name>B.4. Valid Phase 1 ACT: delegated mandate (depth 1)</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "iss-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "agent-c",
"aud": "agent-c",
"iat": 1772064010,
"exp": 1772064600,
"jti": "550e8400-e29b-41d4-a716-446655440006",
"task": {
"purpose": "delegated_read"
},
"cap": [
{
"action": "read.data",
"constraints": {
"max_records": 5
}
}
],
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"del": {
"depth": 1,
"max_depth": 2,
"chain": [
{
"delegator": "agent-issuer",
"jti": "550e8400-e29b-41d4-a716-446655440001",
"sig": "cYYbPuSiYxFV1D45qBKkzUo2GZMjkVkN4IEnJt4433CN8MJ6sAEVy4Huqr4ebuF7fCKpvGijOidrOkfY-BJFCQ"
}
]
}
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJpc3Mta2V5In0.
eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1jIiwiYXVkIjoiYWdl
bnQtYyIsImlhdCI6MTc3MjA2NDAxMCwiZXhwIjoxNzcyMDY0NjAwLCJqdGkiOiI1
NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDYiLCJ0YXNrIjp7InB1
cnBvc2UiOiJkZWxlZ2F0ZWRfcmVhZCJ9LCJjYXAiOlt7ImFjdGlvbiI6InJlYWQu
ZGF0YSIsImNvbnN0cmFpbnRzIjp7Im1heF9yZWNvcmRzIjo1fX1dLCJ3aWQiOiJh
MGIxYzJkMy1lNGY1LTY3ODktYWJjZC1lZjAxMjM0NTY3ODkiLCJkZWwiOnsiZGVw
dGgiOjEsIm1heF9kZXB0aCI6MiwiY2hhaW4iOlt7ImRlbGVnYXRvciI6ImFnZW50
LWlzc3VlciIsImp0aSI6IjU1MGU4NDAwLWUyOWItNDFkNC1hNzE2LTQ0NjY1NTQ0
MDAwMSIsInNpZyI6ImNZWWJQdVNpWXhGVjFENDVxQktrelVvMkdaTWprVmtONElF
bkp0NDQzM0NOOE1KNnNBRVZ5NEh1cXI0ZWJ1RjdmQ0twdkdpak9pZHJPa2ZZLUJK
RkNRIn1dfX0.k4SGmgQrAdUN_f-LsJVAL5A3Q-2NHllGaSx1WOmdbcRzvW2uOfct
1K0e_zxnd_7UHvLClTE01kKiQ3zU1imtCQ
]]></artwork></figure>
<t>Expected result: Accept. Delegated mandate at depth 1; the delegated cap (max_records=5) is a subset of the parent cap (max_records=10).</t>
</section>
<section numbered="false" anchor="b5-valid-phase-2-act-delegated-execution-record"><name>B.5. Valid Phase 2 ACT: delegated execution record</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "agent-c-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "agent-c",
"aud": "agent-c",
"iat": 1772064010,
"exp": 1772064600,
"jti": "550e8400-e29b-41d4-a716-446655440006",
"task": {
"purpose": "delegated_read"
},
"cap": [
{
"action": "read.data",
"constraints": {
"max_records": 5
}
}
],
"exec_act": "read.data",
"pred": [],
"exec_ts": 1772064350,
"status": "completed",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"del": {
"depth": 1,
"max_depth": 2,
"chain": [
{
"delegator": "agent-issuer",
"jti": "550e8400-e29b-41d4-a716-446655440001",
"sig": "cYYbPuSiYxFV1D45qBKkzUo2GZMjkVkN4IEnJt4433CN8MJ6sAEVy4Huqr4ebuF7fCKpvGijOidrOkfY-BJFCQ"
}
]
}
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJhZ2VudC1jLWtl
eSJ9.eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1jIiwiYXVkIjo
iYWdlbnQtYyIsImlhdCI6MTc3MjA2NDAxMCwiZXhwIjoxNzcyMDY0NjAwLCJqdGk
iOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDYiLCJ0YXNrIjp
7InB1cnBvc2UiOiJkZWxlZ2F0ZWRfcmVhZCJ9LCJjYXAiOlt7ImFjdGlvbiI6InJ
lYWQuZGF0YSIsImNvbnN0cmFpbnRzIjp7Im1heF9yZWNvcmRzIjo1fX1dLCJleGV
jX2FjdCI6InJlYWQuZGF0YSIsInByZWQiOltdLCJleGVjX3RzIjoxNzcyMDY0MzU
wLCJzdGF0dXMiOiJjb21wbGV0ZWQiLCJ3aWQiOiJhMGIxYzJkMy1lNGY1LTY3ODk
tYWJjZC1lZjAxMjM0NTY3ODkiLCJkZWwiOnsiZGVwdGgiOjEsIm1heF9kZXB0aCI
6MiwiY2hhaW4iOlt7ImRlbGVnYXRvciI6ImFnZW50LWlzc3VlciIsImp0aSI6IjU
1MGU4NDAwLWUyOWItNDFkNC1hNzE2LTQ0NjY1NTQ0MDAwMSIsInNpZyI6ImNZWWJ
QdVNpWXhGVjFENDVxQktrelVvMkdaTWprVmtONElFbkp0NDQzM0NOOE1KNnNBRVZ
5NEh1cXI0ZWJ1RjdmQ0twdkdpak9pZHJPa2ZZLUJKRkNRIn1dfX0.dCUyOsyvrRA
vM7m0WO6LBnIhijckknlbX3kVGxmkKlzekQmKTAJQbM5H2WbACOh3LpB9LW3hgCE
luEjhd4laAw
]]></artwork></figure>
<t>Expected result: Accept. Phase 2 record for the delegated mandate; the signature verifies under kid "agent-c-key".</t>
</section>
<section numbered="false" anchor="b6-invalid-delegation-depth-exceeds-maximum"><name>B.6. Invalid: delegation depth exceeds maximum</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "iss-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "agent-subject",
"aud": "agent-subject",
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-446655440008",
"task": {
"purpose": "bad_depth"
},
"cap": [
{
"action": "read.data"
}
],
"del": {
"depth": 3,
"max_depth": 2,
"chain": [
{
"delegator": "a",
"jti": "j1",
"sig": "sig1"
},
{
"delegator": "b",
"jti": "j2",
"sig": "sig2"
},
{
"delegator": "c",
"jti": "j3",
"sig": "sig3"
}
]
}
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJpc3Mta2V5In0.
eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
IjoiYWdlbnQtc3ViamVjdCIsImlhdCI6MTc3MjA2NDAwMCwiZXhwIjoxNzcyMDY0
OTAwLCJqdGkiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDgi
LCJ0YXNrIjp7InB1cnBvc2UiOiJiYWRfZGVwdGgifSwiY2FwIjpbeyJhY3Rpb24i
OiJyZWFkLmRhdGEifV0sImRlbCI6eyJkZXB0aCI6MywibWF4X2RlcHRoIjoyLCJj
aGFpbiI6W3siZGVsZWdhdG9yIjoiYSIsImp0aSI6ImoxIiwic2lnIjoic2lnMSJ9
LHsiZGVsZWdhdG9yIjoiYiIsImp0aSI6ImoyIiwic2lnIjoic2lnMiJ9LHsiZGVs
ZWdhdG9yIjoiYyIsImp0aSI6ImozIiwic2lnIjoic2lnMyJ9XX19.bhZ7ZaXG6GN
q4vqquQPcxImFlu50rV8Ae16D06N_X9bRCu9pCiMcY2LTK9XRYWcKlRjUyBRVNJX
02bFXJ5wGAA
]]></artwork></figure>
<t>Expected result: Reject. del.depth (3) exceeds del.max_depth (2).</t>
</section>
<section numbered="false" anchor="b7-invalid-capability-escalation-in-delegated-mandate"><name>B.7. Invalid: capability escalation in delegated mandate</name>
<t>Expected result: Reject. The delegated cap (max_records=100) is not a subset of the parent cap (max_records=10); privilege reduction is violated. This vector is a delegation-creation check; no token is issued.</t>
</section>
<section numbered="false" anchor="b8-invalid-execact-not-present-in-cap"><name>B.8. Invalid: exec_act not present in cap</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "sub-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "agent-subject",
"aud": "agent-subject",
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-446655440009",
"task": {
"purpose": "bad_exec"
},
"cap": [
{
"action": "read.data"
}
],
"exec_act": "delete.everything",
"pred": [],
"exec_ts": 1772064100,
"status": "completed"
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJzdWIta2V5In0.
eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
IjoiYWdlbnQtc3ViamVjdCIsImlhdCI6MTc3MjA2NDAwMCwiZXhwIjoxNzcyMDY0
OTAwLCJqdGkiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMDki
LCJ0YXNrIjp7InB1cnBvc2UiOiJiYWRfZXhlYyJ9LCJjYXAiOlt7ImFjdGlvbiI6
InJlYWQuZGF0YSJ9XSwiZXhlY19hY3QiOiJkZWxldGUuZXZlcnl0aGluZyIsInBy
ZWQiOltdLCJleGVjX3RzIjoxNzcyMDY0MTAwLCJzdGF0dXMiOiJjb21wbGV0ZWQi
fQ.AI-K0abyWHyAUTxIUS22kqhmSdgfOVyLMHaOm6vauEd3YpoRQ8vdzJ2Oblk07
qyXwR5pAlDewYOwCJTSmIK0Cg
]]></artwork></figure>
<t>Expected result: Reject. exec_act "delete.everything" does not match any cap.action.</t>
</section>
<section numbered="false" anchor="b9-invalid-dag-cycle-pred-references-own-jti"><name>B.9. Invalid: DAG cycle (pred references own jti)</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "sub-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "agent-subject",
"aud": "agent-subject",
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-44665544000a",
"task": {
"purpose": "cycle_test"
},
"cap": [
{
"action": "read.data"
}
],
"exec_act": "read.data",
"pred": [
"550e8400-e29b-41d4-a716-44665544000a"
],
"exec_ts": 1772064100,
"status": "completed"
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJzdWIta2V5In0.
eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
IjoiYWdlbnQtc3ViamVjdCIsImlhdCI6MTc3MjA2NDAwMCwiZXhwIjoxNzcyMDY0
OTAwLCJqdGkiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMGEi
LCJ0YXNrIjp7InB1cnBvc2UiOiJjeWNsZV90ZXN0In0sImNhcCI6W3siYWN0aW9u
IjoicmVhZC5kYXRhIn1dLCJleGVjX2FjdCI6InJlYWQuZGF0YSIsInByZWQiOlsi
NTUwZTg0MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDBhIl0sImV4ZWNfdHMi
OjE3NzIwNjQxMDAsInN0YXR1cyI6ImNvbXBsZXRlZCJ9.9V4Pd5QoKBXLnBCAJne
PR_QArbIdLAEYFkM0az0ATr_A8BqjQdCQm-zDxExszLBnSdVclHo1Ns25FSpzrDj
VDg
]]></artwork></figure>
<t>Expected result: Reject. pred references the record's own jti, forming a cycle.</t>
</section>
<section numbered="false" anchor="b10-invalid-missing-predecessor-task-in-dag"><name>B.10. Invalid: missing predecessor task in DAG</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "sub-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "agent-subject",
"aud": "agent-subject",
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-44665544000b",
"task": {
"purpose": "missing_parent"
},
"cap": [
{
"action": "read.data"
}
],
"exec_act": "read.data",
"pred": [
"nonexistent-parent-jti"
],
"exec_ts": 1772064100,
"status": "completed"
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJzdWIta2V5In0.
eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
IjoiYWdlbnQtc3ViamVjdCIsImlhdCI6MTc3MjA2NDAwMCwiZXhwIjoxNzcyMDY0
OTAwLCJqdGkiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMGIi
LCJ0YXNrIjp7InB1cnBvc2UiOiJtaXNzaW5nX3BhcmVudCJ9LCJjYXAiOlt7ImFj
dGlvbiI6InJlYWQuZGF0YSJ9XSwiZXhlY19hY3QiOiJyZWFkLmRhdGEiLCJwcmVk
IjpbIm5vbmV4aXN0ZW50LXBhcmVudC1qdGkiXSwiZXhlY190cyI6MTc3MjA2NDEw
MCwic3RhdHVzIjoiY29tcGxldGVkIn0.PSxajLuiL_b2cAZT2Eab5UR-nZDMs2BE
jEkhzeId8vQzYkldQb9h5xrvvRD9lsjglzda4wscpU-IoW4m8Kw4Cw
]]></artwork></figure>
<t>Expected result: Reject. pred references a jti that is not a previously verified task.</t>
</section>
<section numbered="false" anchor="b11-invalid-tampered-payload"><name>B.11. Invalid: tampered payload</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "iss-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "agent-subject",
"aud": [
"agent-subject",
"https://ledger.example.com"
],
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"task": {
"purpose": "validate_data",
"tata_sensitivity": "restricted"
},
"cap": [
{
"action": "read.data",
"constraints": {
"max_records": 10
}
},
{
"action": "write.result"
}
],
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"del": {
"depth": 0,
"max_depth": 2,
"chain": []
}
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJpc3Mta2V5In0.
eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
IjpbImFnZW50LXN1YmplY3QiLCJodHRwczovL2xlZGdlci5leGFtcGxlLmNvbSJd
LCJpYXQiOjE3NzIwNjQwMDAsImV4cCI6MTc3MjA2NDkwMCwianRpIjoiNTUwZTg0
MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDAxIiwidGFzayI6eyJwdXJwb3Nl
IjoidmFsaWRhdGVfZGF0YSIsInRhdGFfc2Vuc2l0aXZpdHkiOiJyZXN0cmljdGVk
In0sImNhcCI6W3siYWN0aW9uIjoicmVhZC5kYXRhIiwiY29uc3RyYWludHMiOnsi
bWF4X3JlY29yZHMiOjEwfX0seyJhY3Rpb24iOiJ3cml0ZS5yZXN1bHQifV0sIndp
ZCI6ImEwYjFjMmQzLWU0ZjUtNjc4OS1hYmNkLWVmMDEyMzQ1Njc4OSIsImRlbCI6
eyJkZXB0aCI6MCwibWF4X2RlcHRoIjoyLCJjaGFpbiI6W119fQ._nVgyp4X0zYvy
ylbyBgE_CWKAVdEMFgHjHIUkhxEsr83PQw_rzxNryDd179_KdkCo_kxWDbfmEQV-
JA1-pknBA
]]></artwork></figure>
<t>Expected result: Reject. The signature does not verify; one byte of the claims segment was altered after signing.</t>
</section>
<section numbered="false" anchor="b12-invalid-expired-token"><name>B.12. Invalid: expired token</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "iss-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "agent-subject",
"aud": "agent-subject",
"iat": 1772060400,
"exp": 1772061300,
"jti": "550e8400-e29b-41d4-a716-44665544000c",
"task": {
"purpose": "expired_test"
},
"cap": [
{
"action": "read.data"
}
]
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJpc3Mta2V5In0.
eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
IjoiYWdlbnQtc3ViamVjdCIsImlhdCI6MTc3MjA2MDQwMCwiZXhwIjoxNzcyMDYx
MzAwLCJqdGkiOiI1NTBlODQwMC1lMjliLTQxZDQtYTcxNi00NDY2NTU0NDAwMGMi
LCJ0YXNrIjp7InB1cnBvc2UiOiJleHBpcmVkX3Rlc3QifSwiY2FwIjpbeyJhY3Rp
b24iOiJyZWFkLmRhdGEifV19.mK6-ML3hkOlAVvHeG5PPnvr3do9KT-1g4OISjlB
WrcHac-JPWnzOSZmMiESIKA6mXNSYVxnTDLZyFbAPglrCAQ
]]></artwork></figure>
<t>Expected result: Reject. exp is in the past (expired 45 minutes before the verification time).</t>
</section>
<section numbered="false" anchor="b13-invalid-audience-mismatch"><name>B.13. Invalid: audience mismatch</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "iss-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "wrong-agent",
"aud": "wrong-agent",
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-44665544000d",
"task": {
"purpose": "wrong_aud_test"
},
"cap": [
{
"action": "read.data"
}
]
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJpc3Mta2V5In0.
eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJ3cm9uZy1hZ2VudCIsImF1ZCI6
Indyb25nLWFnZW50IiwiaWF0IjoxNzcyMDY0MDAwLCJleHAiOjE3NzIwNjQ5MDAs
Imp0aSI6IjU1MGU4NDAwLWUyOWItNDFkNC1hNzE2LTQ0NjY1NTQ0MDAwZCIsInRh
c2siOnsicHVycG9zZSI6Indyb25nX2F1ZF90ZXN0In0sImNhcCI6W3siYWN0aW9u
IjoicmVhZC5kYXRhIn1dfQ.8vP0564UjixScto2vo0MX5wt5TX_dP9ilDB8aPEpl
WnOovQgQUHywL0_BqSaqgM7NrtjGnITmVoJ6RtUrjV8CA
]]></artwork></figure>
<t>Expected result: Reject. aud does not include the verifier identity.</t>
</section>
<section numbered="false" anchor="b14-invalid-phase-2-record-signed-by-wrong-key"><name>B.14. Invalid: Phase 2 record signed by wrong key</name>
<t>JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "EdDSA",
"typ": "act+jwt",
"kid": "sub-key"
}
]]></sourcecode></figure>
<t>JWT Claims:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "agent-issuer",
"sub": "agent-subject",
"aud": [
"agent-subject",
"https://ledger.example.com"
],
"iat": 1772064000,
"exp": 1772064900,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"task": {
"purpose": "validate_data",
"data_sensitivity": "restricted"
},
"cap": [
{
"action": "read.data",
"constraints": {
"max_records": 10
}
},
{
"action": "write.result"
}
],
"exec_act": "read.data",
"pred": [],
"exec_ts": 1772064300,
"status": "completed",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"del": {
"depth": 0,
"max_depth": 2,
"chain": []
}
}
]]></sourcecode></figure>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJFZERTQSIsInR5cCI6ImFjdCtqd3QiLCJraWQiOiJzdWIta2V5In0.
eyJpc3MiOiJhZ2VudC1pc3N1ZXIiLCJzdWIiOiJhZ2VudC1zdWJqZWN0IiwiYXVk
IjpbImFnZW50LXN1YmplY3QiLCJodHRwczovL2xlZGdlci5leGFtcGxlLmNvbSJd
LCJpYXQiOjE3NzIwNjQwMDAsImV4cCI6MTc3MjA2NDkwMCwianRpIjoiNTUwZTg0
MDAtZTI5Yi00MWQ0LWE3MTYtNDQ2NjU1NDQwMDAxIiwidGFzayI6eyJwdXJwb3Nl
IjoidmFsaWRhdGVfZGF0YSIsImRhdGFfc2Vuc2l0aXZpdHkiOiJyZXN0cmljdGVk
In0sImNhcCI6W3siYWN0aW9uIjoicmVhZC5kYXRhIiwiY29uc3RyYWludHMiOnsi
bWF4X3JlY29yZHMiOjEwfX0seyJhY3Rpb24iOiJ3cml0ZS5yZXN1bHQifV0sImV4
ZWNfYWN0IjoicmVhZC5kYXRhIiwicHJlZCI6W10sImV4ZWNfdHMiOjE3NzIwNjQz
MDAsInN0YXR1cyI6ImNvbXBsZXRlZCIsIndpZCI6ImEwYjFjMmQzLWU0ZjUtNjc4
OS1hYmNkLWVmMDEyMzQ1Njc4OSIsImRlbCI6eyJkZXB0aCI6MCwibWF4X2RlcHRo
IjoyLCJjaGFpbiI6W119fQ.rTp6oHlLzG32Ex6P08rAafhmjzRdwQTjwgU1Cod1a
kFy3x5KpaX5fkfeCiK5i0D6HAtwUYR61_HlBWCcJj5_BA
]]></artwork></figure>
<t>Expected result: Reject. The Phase 2 record claims kid "sub-key" but was signed with the issuer's private key; the signature does not verify.</t>
</section>
<section numbered="false" anchor="b15-invalid-unsigned-token-alg-none"><name>B.15. Invalid: unsigned token (alg "none")</name>
<t>JWS Compact Serialization:</t>
<figure><artwork><![CDATA[
eyJhbGciOiJub25lIiwidHlwIjoiYWN0K2p3dCIsImtpZCI6ImsifQ.eyJpc3MiO
iJhIiwic3ViIjoiYiJ9.
]]></artwork></figure>
<t>Expected result: Reject. The JOSE header alg is "none"; unsigned tokens <bcp14>MUST NOT</bcp14> be accepted.</t>
</section>
</section>
<section numbered="false" anchor="appendix-c-deployment-scenarios"><name>Appendix C: Deployment Scenarios</name>
<section numbered="false" anchor="c1-minimal-deployment-zero-infrastructure"><name>C.1. Minimal Deployment (Zero Infrastructure)</name>
<t>Two organizations exchange pre-shared public keys via secure email.
Each agent signs Phase 1 mandates and Phase 2 records with its
Ed25519 key. No ledger, no external services. Suitable for
development and low-risk workflows.</t>
<t>Limitation: No non-equivocation (<xref target="equivocation"/>).</t>
</section>
<section numbered="false" anchor="c2-regulated-deployment-with-hash-chained-ledger"><name>C.2. Regulated Deployment with Hash-Chained Ledger</name>
<t>Phase 2 ACTs are submitted to a shared append-only ledger with
hash-chaining. Each recorded ACT extends a cryptographic chain,
providing tamper evidence for each ACT and the chain as a whole.
The ledger is shared between all regulated parties participating
in the workflow. Suitable for DORA compliance.</t>
</section>
<section numbered="false" anchor="c3-high-assurance-cross-organizational-deployment"><name>C.3. High-Assurance Cross-Organizational Deployment</name>
<t>Phase 2 ACTs are anchored to a SCITT Transparency Service. SCITT
receipts are attached to the audit record as non-equivocation proofs.
DID-based agent identities (Tier 3) enable self-sovereign key
management without shared CA infrastructure.</t>
</section>
<section numbered="false" anchor="c4-wimse-environment-integration"><name>C.4. WIMSE Environment Integration</name>
<t>In environments where WIMSE is already deployed, ACT-Mandate and
ACT-Record headers are carried alongside the WIMSE Workload-Identity
header. The ECT and ACT serve different purposes: the ECT records
workload-level execution in WIMSE terms; the ACT records the
authorization provenance and capability constraints that governed
the action.</t>
</section>
</section>
<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>
<t>The author thanks the IETF WIMSE, OAuth, and SCITT working groups
for foundational work on workload identity, delegated authorization,
and transparent supply chain records that informs this specification.</t>
</section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+y9a3YbSZYm+N9WYcOoPkEo4RBIilKIUdXZEEhJUPAlkhIl
ZcWIBncD4KLDHeHmIAkxWacX0QuYtcxSeiVz7sMe7gApKSqrZ850xcmTIgB3
e9t9fvfeKIpElVaZ3pFrvbHOK9kv8krfVPKsuNS5XO/1z1prQg2Hpb6CZ/pn
ayJWlR4X5WJHmioRSRHnaqp3ZFKqURXlOs/1VOV5pOIq6m4IMx9OU2PSIq8W
M70jB3tnL0U+nw51uSMSVekdcbUjt4QqtdqRa6d7/TVxqRfXRZnsCCkjqXBc
al5NijL9qqq0yPF7faPjOXySKo6LeV6pYZql1QJ/fHN+hv/u9l7hv4nO9Jje
FdQUNi6klHI0zzKaQn9SpqZKVS4P7TTwiaIcq5z73pGDPNEznScwrBNttCrj
iS7xQT1VabYjU12N/ptbiU6ihciLcqqq9EpDvycv+8+2N7b9n8/8n7/4P5/z
n790t+wDzzc2uvbP7aebO0Kk+ajZdLfr3nz6fAv+HES7Hb8z1+nU6EjH1Q4O
2h6APbegtUNg5Kgo5W5qqjIdziudSDwpaSzPi/JylBXXZo3aUeVYVztyUlUz
s/P4caIqVZUqvtRlB1akU5Tjx0kRP26eFDeex9iO0WWqDcyLxiflIK90mesq
2oU3l4+aayDqbuIreK7kZnfzKX70Ow7/Rd/c8Z+4Bxh1ZOK0qiLY5LTScTUv
tUyNjOdlqfMqW8g0l713Z6+f/CLXT1725V6SVkWJjfwx13PdkqqSV7qEGyCj
zc2OPCvkUMfFVMMOyfmsyOVsPszSGM9XR55olejSYBNmUsyzRM6NltWEXqC7
I4s81lIZk45znXR4j+8ZsD0CBSxEVJUqNyqGzqIKdzgaFWWE98zUj8SZfzQ8
DPYA9AbydGEqPf1zJ+A7hvNjJ+I7Goy6T3/shLzMdAX3uy1f2VVWasZdzcpi
lGa6vmhESHshwZLH9KBc7/WOW7iGR/CA3Ox0/9TSLQ3hxxZq6XWg1PVlsVfp
gbtTzr+2Zc+uykRn6Y0qo0kyo7VO48iT3foSvaZn5a77HVaoKuIik+uvd3mJ
7DHzT/2ptXp4YD+2cA+3FXW733O4inK8I3kJePH0NC0TNbZ3N6XGI8fjGidM
nvYHZ2fuVOFiDWi9pCfjJzouyuTP3c1vDejHlu1brS0vXNR98o3jt0dtCmnP
yZvzsxUXMY1BGNiRPfnm9OhQnushyzbh4vEJs7ytfnlXr58qb9IrXDQ1NI83
t7vPOxtb28+f1eexDcMbHEeDF/3m4AbHO9wbrhlTWXcNrtNqEv4SvSjmedJg
zd81tKfdrc7mk2fPtpeWeOsbS3xcqktlJm15Cpf8FFYz1xkOuj6Z+k+yJ1+C
TJKF97s/UWku+yqL59mc2Mh7XaajVA0z/aeX/Wn3Sae7+ezpsx8+PseqSjMh
5UH/ODo93uvXJ3RQJDpzi+025XSm43TEnHr1AKfwZkwvzvi9Tlo8NuGrj+Fo
RBsb0WZjU/yXR8d7h71B1Hu1d3h2Gp3u/lYf4NFM5/bKG3m6+9vq0RQznau0
M06ryXwIw6AvLDOcLaqJvcs0hpHKjL6falG3Qsr93uGrVye949f1Ye2rfPyq
VLOJ3C3i+VTn1QNLlal8HMOxiGpDhK/H0MYPjAv6xRMG922zt2JHcaU26Zyt
9zZ7LberqwfH44mL6WO1qWZl8QUE1N5m7/sH9aooxhn83j/ZO+8N6uPpl/q6
N/ieZUqK2HTiUl+rFIfz/QOgPmBJ3p0dvdo7bKzIvCpe6fx7hjBN47IwxagK
tknNq2Ksf+TwHNhWhJTnW/1od7BbH9GujnVelSpLv+pEDkDDSkepLo1c3x3s
mpa82rhPXrq+vu5cbyFhODt5nKRJFBelfly/XZtR99k3yMLprCjzRVseAMXb
HexGv+19bMjEEy2TNNm51At5oKtJkcirbufZPcPaiqM4HgfLBkOb4mvRpV40
BrjxjdHtF/k404u23LXDO997UR8eDO1aD+3QvoNiPTjGaz1sLuK3VrDSOtNt
eYRDPDrpNfY4HaeVyoCSlDgolYEWnWapBo2mF1dyHd5qteWJHs8z4h7re+9a
2Pnjze3tJ6vnoedllOmbjp6XxUx19PyxztLHpR4/di8+Lr58z2TwtO5BM1rl
8liVWarghggp9971Bo0Z7b2TvRIOapyqDFl2lqVjO5uV03jyeOPpL8//xDTo
xaVprGZ2D0xjsNd/urnVfdLgejpJY5XJRF+lsZZwVa9VqeX//O//Q57aD1k6
0jJexJmWs7KItTHatKFBSS1udrtP/9I72N3Y2exubN9/W1Mdd+JJ/XBtbN8/
kcFeX4goiqQaGhBcKyHOJqmRCZMvmehRmmuDivK9xqy2VNLobBQBi1ZprhPx
5vwsGiqjE0mWFFlNVCVjNQPVmZqD0y3T/KqgeySZv8tiJFUOBqUiL6bF3IAU
TvYqWLK0MtAM2aVSWKW4yGHsaV6ZdmiTmpXFlc5VHuu2LNBYMJ5UstR/zNNS
w+RMW1bKXMqprhRI7m2p8gSsW3JWmBTH9D//+/8Q8OU8B5pp6hYzfPw+ixmY
MJQ0KdAWgRozbjLucUf2ctnrn8mhHqe5kcrgo2B0aPQwVTlsI/QkUAXHYRmZ
5lUhlazUdKbLSF+laDjzYylRSyF7Bqw1rp+Ii+ks05U2uIow97ZUMzC7pflY
xuViVhUoJKSxnCgz0QY2I81n88rgEIp5Zf+WWZpfwmtVIWelTjQc2qLEVo28
SpVUMklLHYMCoGDaaSyxcbG+23vV6uAC8G4YmRcN5f5Ul1dgIMgLeV2Ul1mh
EomzBGtkmo9KZapyjpYY2re8kLhCM1XqPF6AGoUXDoTioTJpLAtLHTvyrJyb
SqRGDouigtMzm+kERz0rdWQmqtSJvNQLmmpq5Hw2LlWiUa6uCnn820AWpfgW
b6VJwn3SvL2johTAsE0U2j9Vxid8pBMeI5yfkogcLCCeQfdZ6PwqLYscT7FU
WXqpXVew3WOd61Jl0WxezgrD228vmJiV6TQF2+av+PD54OB0T95jqJTre/2z
lri9vcfaeXcHfcLpHWZwGtj0IVEy53WBOds9jOweRkNUvZpHFtpIcx5TomdZ
scBJdohMTdMkybQQPwFLKItkHpP5ubdMLeCSxKVWeAUXvPlaKlx9WV99gYNR
JdITHlI+ltN5VqWRqfQMzyCaZeX1RIO1Mk/SqzSZq4xPvCq1SJzGOyqLqSxy
u/JwWfOimuiyI88m2uigPRhjpWV1XYgEzKY5sLc0N3qmSjxueGtToGM14rUj
xEZHPnpUuzaPHu3Ia2X8nZczXU7TCsYEF1WXQI7pZ1y6NvCDeZ7oUl4jhQ6J
KZy64UJeT/AMUT/V4q9CbGLHNXqHPUMLSZoE3au4mqssW8ikaJP6DQ9Bp0RW
2nBiknkMy42vM4mBJeARqblRmSw1sXszSWeyKqCFWZlagvNXIfZucPXGsqYU
GqmSpNQGl8TUVxC6SE1B7XbE2WSlytwwM9JNWLL13d0hv0kTbaQjTE1qDvTF
mSjlcF55+qcEU5KVZBBPzcMX9cEr6oZ2L7cazivhBkMdLZFdWSe7cv30ePDy
5d7j0+PByV6r8ydFh+tJGk/sLmkjhkU1Wdomy0nbDTlDEmdF4SLgJYIpeGPA
Q70ocj6dPO+qAD9COlpIZRbTqa7KNBZAqxUKKrTw4DeTazz6NRgPNAGSuSz1
KNNxZeiswtc4IhGrEqjJDn5l+e690k4g34D4UeqRBiamTVs0JJS66OOlHYk6
P11ZL+zEmUqnRkC7RG5BuwQyBHMA8lTj+XhPr7z9SOdXOitmxFqAWVqxCA52
jdHUGYx0DIavfDXR4ju4jHzoCIOMJL7BZeQ3uYzgIZr7mMxPP8F9H2Z6Kk8r
VeEJFKL/XRy7KhK1kCMVw30OJIs0HwNxgEZ3uDukU3RGiSA0TmpRSgXHZgok
AG+ZqEBkkUkxVSgZ8FlfGlOpccxyqEdFScLfKC1NJabaGDVGP5u+iScqH+uk
Iwe5nKExFAXF1MipVrmROoVTsiPEumpZdmo5KGxpMa8a8mKd0sH450lakaJS
qjQzbSDhOHGgPrOZ9c1FmVroEugRUGnYn7LIZJFni19BxBLrw1ZtlkDRi1mF
x3emymrxs7mPQrWJucL6owYkJ/NhpPIkMrPiUkvrcY4XrJ1A3ypJ4TrDuiWh
dIctEFXAO4ubn+sKjhwcHJC+TJFdIcEDwXIhp+qSDmtdooSmSa4vykVUFVEK
1AEPGu0x6E1ZmpOKWF0XdgNilZPGgOpWTJIvrDLe1tSbtQXeOhA4UIqhcwBU
Jgf2GhWjaAh0Aowt9ihgX9eTlBTQqxQEMaFknIGWy8KvnCm4zFb6RVMJ6Xg0
bncwoEVUDSZW9SElkO7XLsrC8lWhMiNEJB89erWB3X/SZbFEsnktQLyAJT54
dwpqE18jnDh0KyTI/7zKBnmmQd2B75A7IMwJy5U6g5BWa+jwwDZJTUfeIxta
HA5pSR9cwk3YEeubGXK4xPIPA/wjXB5Wpa7ImlC7UFGDXY/VzNgxbuEYj7Uu
4TDNtC4DvgCD3G1wCWPHJGRI7t32AXONUZRS+T1a2dzQparTAGwdb7i9IAEn
5dE+sVwuyhFfYeW7okx0meZjGPC5F7bhIIMgnGUaHAvDUuUx6KWw1COVR2nu
rzEo6I3VTmFi1FG2AFnXTnKUqarSOSuwCrRZrUqagR3qNg51Je3Hy4YE0Uu/
vf6Zkakxcw1SM+ygVUNkko6Qo1cypOJ+tMEuDBdS5fA20LY0Tmcqr+SkyBK+
UNgD7g20/rNhmANcZjvupzhutpAV5cJS29pQqW++DtLMR2Bqo5NH5gRWnZHA
LMljYEyUt7fwz91dW4K1bgCGOTCLw7AzLTc25e0tWvbgCdgvZ84CRs+2srs7
tyXUB50rlSQpL3VWjPl+uDP0DCf4LqBKMCmQ1Gh50V1EEzTz2awoKzlNx8yl
QTWD5W1S5ZCsuTENS01EXFvtApaObhFRs8Mij5iUwQBGRZYV17g/JZ7CLI1T
QLRAa8VImriY6R2Yxy6Ix6TugncXJP8Bj3yoJ+oKdJsCrnKcIswlK8Zp3BGR
PNGzTKHC1DiUyBOQyBXQK0oHZE5M6AYGnZqqKEEa4JUNtjrTyViX+DTZuRd0
SYBOldrJr01dIBCj5EHvI6Br4CjZZZtq4AqpmRpp5iDvG3l7y7iquzvsHtkm
Wyxa0P2xZUQyL/IITofrfTxXpcorrfE0mgrYaQYSASygXDcaOr+9Dd9xvWhZ
aypJTTxHLB0JzzM2Cci6OQnoTgGns0X7flLXR+mzTpB2CfHoUa93fL+uaO+g
03o8Q6hj8lhshOWCBkFlTApUcdydvI9Ik9QeaAiwuiGTAG20Tr8dtXaU/FcB
3QaNOMGTxFaS3vesEIFbCvg4ENjHcEmqULM9dUYqGL9yYnwxgtn9KtMKjUl5
w74XpQE4UGV4W5B12P3EhbNLFWfKwN189IhVjv7ZQ4rF/Vsh7lWWg135pgFN
rNyz79Ow7XKJpeXC9+2CBbJQmsuaaZDpmAg1dRT660+hSYvG5NrTSZv4RO8j
iAqk0CYSrtnYAM+g5wkMhkx0Pp6Syae2WCie1bUDb5nHfSLcDe3RPWA72qeX
SA89nfEc4yECAdRgiRa0aHJeMSTzo+Hp8nUnq5liZNBZSA9O2byMtvt9VGE2
haNyYDdIQRqQR8dng6PD3j7Lm+4IJIFhGkbijdPisADHDXAT6rcGk0Tsz0Ng
SUFgydVASWvOVkPgR5UDTaocYJC/ypJhkt8NkRQ//fQTHHgezX0GtFlhkEWe
6iu0F8T+jZn91crFAGZmUVolegpyZTGdznO0eQhrzgMjR0bKtQQOj5phMQpN
j80zB3dWmJmKNW+PmQ+NJoiQSau5As8IeSUyIjBVISs0frpBdoRFOLDeCrYd
VaYGlN6RFSNhxecGbTmBQ8pzS7xkI13yAbu9BRzXlYno9bs7Msyb+XSKNmk5
1FlxLUdFPDcCBgtCBC6Rvfp41fAy9QbH8rEEaBRwWAuTovvjLZwr0VE0SW3E
CoSUNTstLGQVNuu6QH5rdmgV4oqdWOD9I5GCrHbRpJiFti8Y+Qtgu2n1eFdV
CkS8yiFhBZnd4R2/eG05Lar0ClksiMjSzMsrvUBNYzYri5t0qiqdLeRmu9vt
inugRqwZkro/wpnlRYPlasB+xyjqdu5j0jVew4bcDE6nvomzuUFtA8wcb87P
Hr85Aio5KYv5GEXK9bywk0dpk+YvvDGi1XamU5U7ERJWO5pNlNFeA5XkJEAD
R/20rx+Q47BFnohZWRQj0Ps9S1snIGMLRXPBYnLzyMqAFdGRAqkWhVSyAZL3
MAJrjWDdks2gFqYl8Zr8GtA47Z6pLzxKIfQ46X0kbQJbC2YMRjli7zV8nLy9
rX2mA19/xK0qSb2ZuB9Jh/0bUMVD3WyGKh+ZXpU82+/9xVL8r3xI4WSXmpZy
o9v9L6CQ6Ijspld0Zbv/hSA97lvBa8LyEiyMH9gLnccTefVEDuGPqSovO3JQ
1c+kIMGxznb/mGtDl41oGmhMYLHOFtbkPivTHPTLzJ0d2FM5TmHWuJl4u5AM
sCHc6bEpKJYgmXh2jNS0KhF0UF93a/kgt3NddFeCdOHIem14b2TMW9Em6YRn
ofMYCI6X0dL8SpWpYrUUWEdE2kCZwO1bUlOAk0EUSFvyX9ttAX/90t3abEmV
AQNcNCUqq8SgzBvhLsKtjhRgN4SpVHxJRzIAxwLxdRBaFjODX8HYcYVnERz4
5J53UiDKFEWuo2u1QEd8jbGBzl8W01kFFtVxaipNbKTITBvBCnGRj9LxvAzO
JN/N4GYrYzRzTXKJCk+gDZ4x9iXHGfCEirxtkSor6bEd5C1kJyyqkDxF3xHR
UDo4zOJVBYKrSpIagROrCBycWk/klomGA0igVs90p0nqGAwBbRFiwx7H2nJI
hYFNoBVhN2WpFtGVysCccwEIhwtyp8hSoQeFLKpAIdMYpDDi3cJakB49Yg3p
gWgPw0677wixsAwcJAeQAIW+qXSeOD1suRckYSqXFyqucFB2/OsqF2ht00lt
BWDCyA7kBW/j57i6sW/FRX6lF9ZekVf2pNW9xWC1iyAmTQKpgh0nn/Z4npqJ
M3bAQK+0QNYU4HxWHEDynCGQskRnHTJkJJKCZo78gqgTuJ3gsTqVIp5VFbMi
K8YL5HYNouBZ787D2wVGIzOfaqFyXvdVijeBNcBjbsVBvwWOmokaP6zp5db2
pPKF7J3a1vh88okUdCI7sicTXakU2LGdNpqGnBc2Nd6dCKZncXtr7UTgRgVN
jgiFubvDY/vNMBI+tA9HbdB5fb17bN3x2oi9ZHN7e+N5YBRGKR4p8S/PftmO
YpUXOfghkRVBaEEboWBeyLAr2nR8WoZNdpxhiogmEm2K0QidKcTH44AoPSDY
gUiXGkHsBi32TpRbV1k6Rhua9W3KYVmA2kSaC/l/dVwYjOJq1ehFqa6lm6Wb
YYKMMSQyQiXTlMUxPrqgB4RNNQiPN0pahfr7All4N78VTLJEf7wwRb1Z4wTC
NkC8wP4CTYL6k+u9wUlLzNQCDB90N51pwcj+0ene59N0nG+QpMcAp1AZF/cr
45ZqTNLxJFusJB47gowdyJQCgMIq5kM2T7bow1GC+zKfsgZCFAFwB/O8Sqe6
je3Q4JaXW5DeHnbJa2CdP2bOjjzYLzCyRJUup97u2BEDNx3i28hJ6Xd5jGPf
JCdEVdA4xPoDl70lT18fvdvflfYHAmoMTuzAREghR4i2sOybJsPmL3+e8brA
zQAtzm0aW1bIbNoLXRHkNQ3hcciGm+g1ByewR5nEpe/HYnbkOXo2HUxN1DBC
D+IO+FyH0BmLo2OV1bUF8AlrkvQGPliPcVnMZz+b70Ay1thCyAksosU5MjOV
sx1DWCNGagGIJjCTSQd58CcfHUIogDvDarYQ1q7IImOmSmprUlyT28PdJ4PC
VEiN4DdAlpLrGX51FNCL9oxIY25i2Hp0j66+ftA/bsmzosiid0bLl+APJB/L
PS/c3tqwo7u7QNeLAQRfRaT6C5Q/AKJBwDYgVPv7B3JSmIoEkEvw2rBDBmVq
tJN7SJcAoh2dHPdBQ8lMB2KdgiAjK5AaB/TaoDOB5KooKzIb4eFFnslCOjAc
h9LKC+8vwbeBQqLsBcqCF5MaVyCQxsCyMCLvD4PrlsDCdC1h0xG6pMrxnK3B
cEpmCl3VcBCuCVxl5lmF2MJSV/OSjH9NLpoa8EzDLSY/mAFMoEbgASwTrHJo
fQTA40xV4A7CtcYlBbsJOMCyUYiNaoPKwAQLKbJUTPM2cBRs7/AkCClsgH0s
MgJsrevOuNMmQuPAVAvh167VtuAPuADgKgNrG90JuIigjEx1pSGg4Epn4aoL
62jN2HQImo7bLRJSYR2M9aLPSDvR6ZWFS4B1WJuqjXboK5WlOCukzMEsVZ7w
2wwtszOGeXq/RduumIeOe4gaejyZawwXHgcuTl/3os3tpwECHMUjXVqkFSI3
gwOjGFMHN0OU2syK3BA7hNlFQNpp7nSIYKwBu6IFTKs5GkFyMQf725iQ1qy5
EaNzhJZ2E44inBedsPDHv4r6wOxpDd+ncbTr5A8metA//tnUFAsGNQLZsA7k
ELM+LRLPRqoCd9dd9V/tvgnehqGXddjWfdHrn0W8qxc4XvyGZKUL+frs7FhO
2CYfMOHbWwj6iOiXyHV4d0e7FaAwmcYuRTZiXy/nOTGOvsqQLSJ5XX729nYp
cPLuTuoc9oh0NBsvUYwEC0ZANScqT4rRiLhFgIrFAaM9oBg5xFcdMi08ZLot
tQJzVVGhSpehx+OqQMYaGEBGdjJItfHACRh8SFWH8zSrADNSJ68quIQOsE2w
UFFZXCdPBs9dYDBDYzRQlsQb1AB5VFpRQLjBuqaJKgMJC4yLNmSD6bGdDhjN
BJ3zjpOXAjrTGB0D2RcEPC0giwoa5Vz/YjURrZEXpF16aVFY754WKFYUI9tp
+z6q67bEaJAWhae3NV5l6cdU3aTTOVir06s002O9ahQCCKO+0WWcGm3JSn2c
PENVVXBuQI0KyI1gPQTP1wIpyFDFlwi1KK5hUFpNpadiDg2Hc/cLWrCRuu5B
d9AZa7DjPazUpc7B8crODaBJ1igH5yO7cvEGs8ztpiFWBEogRNuosQaJHtU0
e5lAjlfIaumW2HOArr0Ac4bwWVSXqiiepFkiAebRRosGKE+8dxiT1UBk1YyP
gZVQGuBV5MRdqZpY7yETFHcaYqI2snc84BAhwGZZYdfBxZH2ECOE874IbD8h
fpQINZ53YVvmGDo65KZxykNkbDgk4Ti7HGZFfAkXbZTmxPTa7pT60+behkXP
dCmI1/j+iL95jzkcRUyYQAyIabMP74YuXNA1a5D4ixHCP3V76+LE7+7IGWP4
5PuoEtDNFhDThChmagSsPyTy5mhELzXuPtxsfDuwv8F1cBIZ3VA4L0b4d+Ii
dxitIDSNriQc2QDNPMKbt+rsYvAQWoNUJkdp5ZFAOLEdOtVu8gJGTqeLY1nQ
hlwM4RATPeQNLUq6wwmqw/pGoa2kyDXSUETVO3WplOsXVZpckDPMh63hlC2r
9mPwbUPTbLZZD4LgWgGCH/FJ85ij40A9f4iM4/Q8DSfhOTgh8LuTmvFkG4A0
4/aBQwYVGGPFaZKL4OTp0QiiFAIpWjzEAGr0HPoEn4Mj60zUBF8kIKNOZUIJ
HnZPJboj34GIGgifDIKzrbZF/aYwafbSEjNK0kOInpMVCC67XxU0FcliCNkE
gusWDJ6iijpy15N4vAPE3hlIihKIo8HBfhIqpITgEH2lWRzGmRBFpf0Mov+w
JXyMEckVs9VZMcMIPvgxLe3ZQdN7G9wXpR4uHHY1H/ud/9nYURqwUVRpTOYB
PpwwAPBehBaDAEPZgBUJMcgZ7W5QIAm7cTISDZpAgQjht47D1Ijp3ILOI0tr
p3palIt23RKF5r2lGBNGCcCmgtgKLSH9XjDEHVagKF0cXXgBynnODuuhD2tD
LxIfwBDE2JZGVakhBKMPoxM1NCsHJueAzRlqCLUBmS6YWFaMEc2OAEOm2ZSF
Qt6f/0L4cDL+febtFDaZRs1OASQpKkowVrDxG6wMgcFihBe8su5Ci4qxFgTy
99TMCkFAYlUEkWdAiI4HiP838URP0V4E6i5pF0hy2dUoOHJLlUkHkoA8YKRY
JUULDq5adtx5DBiq+USRWfsNArVEw3ACER0J6QFErJlE4HhqwWDMpwx6Bb3x
jskPMYC8JoK33WlEm+xqOo00l/wMPnIldLx7KxnMv7fZ23FGqLp8muZxNk/u
I8F0scWFDf26kKNUZ4kdP2zFGcyBqF5DBMfZoRtOGRHaOQK52wk01pcSYMpD
TzSMgtbBzK2n7R6Ju2avsBMhLiEwcIXw9jC4wFSbO4pP8pNcxRSEQkYPmPgR
AI0s3eNlOGGNHnVSuwq1Ra8KEM9ArqpL7OgvdloXKHc0NA3R8yixkTFqlSVg
CdbZNAf0Nns/G28QgHim+g3l+0fwGFgJeoOuqj/qPvhKgQTu0bB4Akk+A1JL
Y0lAfED0Ejbmm5EqN9dgSlhL2VrHS1QLEub4D3qATFV/XXO2DLuvgtuSrq0V
8cb2PlNTznyjzKWgmGMKyg2Uwb+uMYXdA0o3K1Oj5ZHXYotcnjOLIwv7OqXj
aUtOvNMSInizqL05AvEe47UcBp0TBt3eUjYhgC3nibBJfG5vOccPEmowqHNI
OAe3UJpGy4ddtocGLN+Kc224kcwBLZ8OcbnOOyDuhQMPcl6xEL7bXuWLFqcM
dVMof1c6l/NcXak0QzIGrGTKgX9o6LbzA89NCoKBY38rmM1Kyog3MjUuCBQM
QHB9zkC+3kD5OAi4aIkwVGP99rZKdblxd9faCdiPLAtqWNmNgn/gFtkd6gMq
oTQwAGJUBCKDkRnrUsqldTxf6sVMpSVdIoAJAUIAr2o6ZVvCCouJ1SItleYL
YMBEBVumS+sMZIE4IKgYnB6kKMFQEpgfvQhNoFvb2m75KrPVoNSZvlJkM4Kl
hOXoYISB61NYW5IlmezWBeKFhNYaiIslG6yLZBEYEup4H7G4MIbdSYDEW0mo
Shl8hvglUrqspFSTr4pRPVoIZ+gDhlaFCy2HBMmHArpFI6DbxTT60Ch01AY+
MdzwZbMF86HDozM0XvT6Zz8bijh3cCmOMCFfGoATwiNCBmfaANiw4tojlOyc
nKQK5zMqRqOWqKX6cDr8rzDmaZqDTax9nzkPo5wwYJ2CwwAlrTLHfA17IZq5
aZo+dWe6BE3JKU8+Ewb2xZS5GfniwiyEOA8DCepbtRRXYMWPRvSEqAeGP+Sa
Rd7U8PID+YZggBAe7kypdAP2EOFNm+QCxsmX48MBXHg4OOGNjY6NJ0yxvSfX
Sgttj3xAysa4xrbDddJvNr6UceY0imUsbCAd+67ZxqPMaibLD3FajzCnx0qz
a3tFag+LkavlGqIDVBPe2VZNWYjy5bxD4JoSTfKDWuc0vQHDSo19YcYHdqYv
e0pMCjxX5bqYm2yxg5f94tzu24BZ5QW7Sfi1WmBO/+xXkqVD18qKx3v9sw7n
z9Ss86OpxyrsgFCkuO4qnlghE/YRjUeMk3NhT80IdxEaCKwRjcXYPSQ0vGB4
/DvykGLwHQoFbykHAJVIRXITKDToKvmVtGgvLHosnLAZvpzJ1BneU4hiiGhI
Md5UMh1cobZLPDZnqCgkyMIYQjIBoZYLeuQ1HuQ1oEZrbfoXyCj8fbL39t3g
ZG8X/j593dvfd38IfoI23f/l3+wfHRzsHe7Sy0CWa1+JtYPexzXSA9dsoM2a
k0QcBo4AgHCoUpINNZqxwKVm4jIdktr7on/8f/9fGxCc+n+cvOxvbmxAYCJ9
+GXjGUaqTrRNsQFMmz7CiiNETWFWDYUG9Bmk4zPoZjYT4AJAGAGb9TdYmd93
5D8P49nGk//KX8CEa1/aNat9iWu2/M3Sy7SIK75a0Y1bzdr3jZWuj7f3sfbZ
rnvw5T//FRF30cYvf/2vwuGiEQKdh4BPlwuPxV2kNExQjZWdiLUKMicZj6/A
8BJr/DQNY4B9ejm+CxKaMWe20HYcYY2+MfvkEaOsm1v5L1C1CTiRW89Igy5D
xqMfy6yEI2ki9FYNYvPeQfh8SymyJDAxfF9yN5t5iYC95AICr5NZmeENh7pr
DeU9zu9GNjrM74bDZnHcSwHOLGOF4yDuxTucSLgi6zscD59HjgJ2EJ5nCJff
ke+MTsSQ3ENVwRrFiqxRIJ9X11rnnLEL9QorbdF8GvEgNIcHc+RYH5j1ccBp
VWj3Z9NlWRRVwGA5EAgd3UVJuTnsCQbFAEU5wuvkmmBXbM+ig+18o6YRpaax
yRSyOIFtBr3Fjx5hnjtUwWguJOYUI6TZU5WrMVmqGsLaHJN6FEIbUAlSQzBX
L04zMqdmFkK+VqLcjWD8ZoD9OimCbZ/7pGWD7ukniL8A9jLYNYK+2WpRHC/v
EU2BLe8lx1tbKmGZqw0Po54vrtPkQiBnbqNRj5aWFHUKqVcZZHfENuEwIMuD
ie1bHKgQfP0mqBmtQIqSXLmczwPyBlLCD8pqha+ZXzk+itktWE6Hxp6hAGWI
uZsA3g1EJQdoHYXtYN/KReRbOyco5YGwIB89sirhMkWR6cizsXTE1jLAHV/A
AD6ruLrAeHFqG2DmgW3Vmb04DZesvSR81xvyHrJaE7OA/7lZkkqJb1v3Evh+
YdtCALcs55lmOooNlJqcPwy/JuiVm4AH3FyXBfiHsQOL1XSht3KoMVcTeRY5
vNXS/WayF2sHA6nWsQZ3KTitH5/GpolVrqO9fDKfQiwGdg9ew8rHIuIOY4LX
ADbC2ftU3ZRGUBfaH5t2DBJMwJl0liSWEmvJQ5wKFnbU4TfDRGNAxnPUccjJ
YEwRpzi7gKnBi69hQvckW8XlBmQ25DsC+6Jjv9RhAOkPtJ/160kRwm3sJFAw
tu9QuojekleXImTZscFo4g7JrKHJHWyTZCsaLlasEua6QaEBiC/I1Zhr5ayx
cGwU97qEj9xIKzKqDLUqdeksApBc1gFGbFhUWkMXEVgo1ngWgzETXzQT9Isg
tZf32DKAXOqbWUonXKxf6JvZBR41hK/Z1FAb22BqIAzeCCAQlpHJ9YtUVRct
wnTPq2JKCUkxPKAqogbwoIPptHWJxBGsLC6ifs7JgAWe+ogsFdCUk+iI7fsA
7qlaUKIIsPdPpzpJMcQ3vJWbO0vUTYh3K4CR4Zpi3tsV9g2ypTSwkixVeKQk
5d3sJc7ZElA/UgFZq3Bdk84VUJXNjjziNCMZ+WnzsbxI89lnEMwQB/i4KOVF
Ma/4mzomE3KRwYUmH1ZTgJPrgeiOt84bl0LFu9URW/WJBN5oh2DgDGY16a/m
616ncmC1NEytjnjimqb1qQzjG8GtPDe8VqYjtqE4U2TFnlq6RKJpSHOszF67
goIMmu5lJLspmrR34C45dYCEKZ/eBMOOEDBUTIfpctrlvyzx4bYNKqofHGE9
ZnX52pFd0DoLjhKy1z51pIKiSur+ybQKTgoF3BArMUESTLBwlXo2T1AIFTWY
LLtlsNs1ygXrnDP+Fvx1jbRmzMYKKVtT4Ot/XROYfQJdX0Rl/aIxVAxXaCdc
9hITErE52BKp8D0GcaykrusXqTEXLWJi5FwL+FVRpmOAYPnFM3YcyAxImEbj
TqKzDsc5Or80p99EOBUkoYFcgRcmHVtnKoe44hDcVi4fk5BbWCBYGj5Yaszn
BeNHzpYnoY7AooclIXiqO5jMBJWDOv2rTQQM89NZtWgHfK82Qk6lU4/j8Avk
FcaO3F2VOCV8U9ghk6nwvh3wvlpVmxjh8DlYF/If1IE4dvZ0Vt3dXQUI9zbA
JsojBHcAnAw/R/QZkZAgDhK7MSw0IQgI7MkW40ZiIPMrcCuHmE1LesCUoHGV
TEr5BgCo5yLDEFQnDxSYAbUQ//Zv/yak/NuAboy9rsGh+Z2z7uN/f699wM1c
p639jI6x4Ncr/PCXaOm/vwh6WR70Dnd7Z3tBe9+SV/mp9XnuhR76qu/j8FhS
IQIM9zYQdGwLtS9bdl73Dnb17M9CCapm+qk/h9HiltGCYYN4ZVtaHolQ1qT+
EtMojoWm4X7GrmClf2yhgaee7IatPyCC2DWurTB+dRqeaItS4mAbkMncSf2H
rvK6zWrWsvGCNkRwZRzlj61M77D/+uhkb9d3527zX7y3q5mh6f5m4TaxDk4+
IKx7VTk1HLXbRt0xyiW3jSbbMJTQPXZqSaawj27f3bFo/+b8VPY5gc0ph7nY
MOEsI3EblUzwCb45PxUrH0bPY27mJMI6KFsQ8OHsDhDWIdgBgfHcRF8wvPg1
fs3wsf4ZfcnP4iBY6d5BsiO/mCIXt0LKNZWN16Bwyunm9tM1SHW5Vi1m8I2K
q798ua7ou8s0we9QfFdQLSfismVr4o6W/tEjlY0fPQIxkozQrR1O/kFFZjz3
UdkYrFqT6ZL2IWrJF3FMbo9+ubvryL1k97Qn19kz3+LMcd2tZ1hQQDQlWBDf
wsxfyRzNXmYKgRFlGFEOElWpTQru/ZgeShMdgUCQ64xApJemI09ttm8/CyPX
X8NI2+L16dYvT9ry9en2xmZLWgu91WLI3IMLTttXe2ItL3K9hoarajFrrKNN
+Ok2BbVYnyKBDhuFwoBDBzIpIZCLDK6XadJosJeHCq9LiMeSGUjJABoh05sI
V7CBxzAY9kYpy0CFn6k/5hpjzFFSK7XG6h82d7BvdbO2L+vHvw2ClmAsHzrb
3eci1lTNh1xp8+kQPM6Vb2ar3szuYLfejICsnGB5HJWK0sxxIN8Fl43a+fr0
4LLT6fwER3rjgiyHN9sxrJd1UbR2Vg+77Qcqg4FSLg8rUDBcL6F7joJdzSJl
/fvBKkHNZdxdLPJLPtBHjxLaxBWD2loeFAZkwNxJHBN14bk5NFL2TJHZ3oCq
nJ/JPuowTYkAqTT59E/DnDn0NAw1NWYFIQgOXC3hmh1boOx0BBFv1g4JloI2
acD77CwfNbYSUx4SOjqncwJ27x46Q3GbEqTDutQsxWY+/IHx1u0sKq46wpF5
lxGCTbmxc4ICY0GFAXtU8+aNxB4hRUpCse/pDCB261AMBlu3sE/czaWR1SxK
6xdmPgTd6JyDaEP512dfAsMcNq0yU4Tt85MO0AkdcWMW5i7cCMmkxAbTtqNU
ijPDhCZbUjRLBocLzhhLrzjAL0U0pCWq7aFRDl2l6H65UPOEljFVVWMZB9b+
BEYkYuaH86ku03gXaEjA8LEBfdMktXvO6MXwrgcMZFUhHraGoQ2Mk+RaE5i3
ecEAvlRpkzTLd+8GuzRSqCsO8kae/jEH3YjXg1LrApUD3xFG9YY+Pg9UrlwW
BXR32dQLDWMMpmDC+lWBwaYeisJ5Y+jWg3xRJwn+6l8vUSmeT33oXpWCO8T4
F8hJgEODvIX52PCZc2cL0yEY58Ihe2aeUKS1kRdfqvRC0FrlWLqlqPVEvFWZ
y2VeyDEgTQtc3fi3JDrBl2s78hZl0jU2FIOYZAHNn2eqgjvyOSmghgKKUlKu
AS77s9FoLrxKqwW8UmpKzKIT+xR7Aj4P8Xdr7d+JsxSzZkSQ6iWPuhv2ebTW
avNZVWs7cuPZs83u0yfPtqGW750V0SJ5waO8aBw5JqONBXD0CP0FUKpu9V2g
rEUckQuR1ZiAb54BsgqPElj2dSSkrUORFxUnHCRuvBYX046+UdB8x60er1rL
s07MtE9xLJR/xFSogMQTHWOsLNuKGkBzMPNfNFf9onZKj3JU5NfIWQmwEZtf
mwRgTI7GeGj4NdgvMETWujNesGObHKQmtyGdiBfHNKkAnjQaCu4pyG1wpS24
GkCoLucQjN2fhfqoV4txE3KnlIw0hpTUlFLAms5rtyKMmzJ6nhT5AlEWLhs2
2k7jFZlgcGj+2DWGVqO7RA7tPddWUw/Mc3mB2WtItSEQgserFyPsiIh+rJo0
u8fMBk0xHrVGt5o95Oz8WqD11YI4alJI04Fi3Wbs7QoTNlh8BoY1kcchKaQp
lkhErECX+hve0FvWj9eob7r1KulYIkGkmq8zHTnboaMyRGn4hTT5jKQPWuK0
uJ9hYT+Df9a1I+XaVN1w69DSRvALXor6gfs8VTcNisTP3+G/d+37ZnNdppXu
0K3F/qZTDfsLP397VmTgh3YwTRBNot6zkPJ3S8t6tIEQQm+chktVyojs914c
vgQPJCTDpX0RnCUPE3r8CyUgyGHvH63Ltc5a8EVL+L+l/BfZ2z9+3YPH6I/H
cnfwanAmH8u1aA3+//OabNGwVpMCe5YwntQSW4cHLNxxxNl0xHmaJTGI1e6R
1BA5gTyKNldDLRlRB1G0XkCrO2KxHS+cMthTHp34sEBMQrLYAbd+7/BjeI3Q
i2sCn1SbaSzhR8F17y+OYanb5jHx7fxsam7fhjwZBvYjQKcZHhG01Ja9w90g
oJFGLgDTFjZjRVGLO0+4T7cMQVDTpQPjobiDXpAwAIqBvoiypzoJC5/HBYCX
bc5xgFZ9ujiAsSE9n/Mm7cisuNYlpMQGwigzyE8F9WZUWcIPAiPyoyyFpELr
yH84RVOr7ZLFYYy5fWae048IX+ZWSPK9TvPEypjOsd6QzB5yuy9RMveYl3hs
RpPPmEr5SmWfR0UJ5I4pAfJSMwF2ySbazkyhlrr2Owst7s1Sj+Dqu9Ly/L0T
CqDYtmVZj6+jjc2ttVCywY29WDmgC0mL5Yh+e5WIIBzL5qFaADzpbg58mC3I
jGN78E4jAPKF1Tp8SHrzoj56lOissRe7q2AMbemQVM7JiZEXgKNy2DAXNRy6
hegCkobQkYORBP/QBWVRQmlauMAsviYVI09QZ6o1hWbwi0TPqsmF/BfZxeM2
mpeIM65XigCvkkczrqcd3Vm53OQzh+WmeHJAZDqHFiWJLXI3AdDS66cx0Zk/
hzgyz9iQ3dnvtqw0DevmWLEMGQ/PAI/uWmgWmqgP4xefdq+Kavdyf3tz+9lI
pV+r9FXa33xb/bb/ajbM871XldpMit9CdvulSqGp7e2u/uVJtxvpzefD6MlG
8iRSzzaeRk+ePH26vf3kSbfb7YavmRQtsTD7p0/mZRZxGsnImSnBQMTJOFRc
ReC/qHPI3xvSPu0ZGRds4vxgw/Dnjuxy9TZnyMPtr4lnXJ3Igo+kdUIGGNRI
XriF5y5dZhZ3IpY7dwzTVz5yV3HF2aiJzwBwYcw2NoaiMrpA6zLhaoyQg/Zy
Uluu8IPzgsgpCx3haH25Tm3/rfv7hTVS1tcA9pKfwfFEG/5JwqLapiwLx7Mt
90A8RT8zlMYiO72Bitu4g3w4Lx42StWiLXhVqJx3mJVdz8I7ieYo2wyPzCVL
oWqrtLCtDg0GFGwaBv654tXvHQY3CD71nRqMK4gmXuFQD/Es2CyOQFXBEMLU
O3V0BefCccVN4H3v0XZW03A2BRFGlRs6v+x/rmEBOPA9QAu4FNgMKoFFVCXO
BM9Yr3f8cy2LNOcsqWV8dQNT0hfCwdD4MFrale+06GJd1qp+LS+rCOC44Guq
JzNjMxwpTHBchgu8J9PZ3GKiBGYWp+zgrHVb34HiNBEN87H3c7LpuF7xihGr
aBhMEg/4aMKsIG4igFlxDTYHVDhDq6HDxwbeEaqI4EPFOF8IIa2bVZAOrAUa
rYPkOA7VzcDSFlpOmuYtrqjocPUBOGeVsoLyaKixNPJe1fQDaoFk+iJ3SaMu
6KELEjoxbQ9+HavZhaeFIS7FYqnEo0dg33tgmgExpavPfUAuE280FA4hz/mn
sGI9QlH4fQBDxYxKIkKLSFSkgNikcOJISGWwvvpVivKXPehoAJTrdpCsLwi3
ms7AuI4fEdLdkmwiGWfFUKGPFkuaaVB78AlUZ1BCIgMzAwYa0hocYMenfUzF
unXmzAic14LEdk26FaaSABM7ZkXkKr14z3TiCV6prkURV7q6N6Fih+ud6SaY
LMCnCKqwDXYmzzE4UJsR/xYP8R83UYIZ8kzJg97wlgh0kVg44/dMTNYmJtzE
EDjmr3BlHrrBoZ3KV5PH9vD2kkJlgZMOctdBNxoFyhEtIWv/tdUxSa/Aeko2
UV2Y2qLWEh/6McrgzAIgXO+Pucog2hubDk11GdUmDx7DpFJgJPs1zJIBdjdh
O0ZbHbKnWcFFLmm0thQ9JZAu55Rxw6HkD4/OBETGaOvGwGSYXzSrU5j13FqG
Ie0RDxPq8yh5rcoc81CDow1tPPdvhrXCOjwV6I4jzFMPYXtY21JlawiwwHRl
6NiyCRUaPnFOnzWahwG6VNeG2sFst5QEH6p6TmeV8bmKJNwNSn9Rw8KKFSXQ
Go3IKZbjtafJnsSyDC9X2wVz4hY4fGtq3IxhfG7OrR3hHRVexNFlCYl+yQix
pLTrsvRqEigTaCp0Zo/PVymXsXeuCawKgIrQassgS91kFHSqxh6Ogl4Oo+HB
8m/LnmLsOu4Up4jibD3XFHMhcmQi4DLwRSXZW8FAur4F+O6RUcBwyg/6tOPY
GkQj3xN0AaP9s7AX53lpoF861GJqzL9bgVwz82GzkfxVvFVM+wtlngw3Xk33
8ic3i9PX4/356eub8rfy3Yu8nLzRlzefXr/8So2oeeI03X9fU9JbZMhb25kU
BoNUQ8MMHAU06KylofOp2+3il/pm5r98zl9+v44MDi5445r3ojvciDeTrUg/
GW1HT5/98jxSwziJ9Ki7sbn1ZBu+4Te+7Z9Dm8fUGt+XzNX/aE+dQOv5/2f9
Aj9k5jdqpKvFZ4AgGoM2vX+YiZ+W6M8bHMNB/e7XfKXNqLvCZrTZtBnVzCor
SA6V+27COVnwRDBs24JKWb0JwZkrqBKg3L6TKtE+/CdN+k+a9J806X87mkSN
WDPFtxZiDVR1HNp3mab5+rA+Bo3nT4Zvxx8nB6Pzc7Uf/TG+eV++famOPp/d
mLL/ZGC67zfMy+HudX88pg6tVgkv7/dVV21++XxTfN6edt/98vrsxYvDF4f9
/Q8vLsfPonH0cabTV2+m20+frLXdtHC7+J5u8T31W+b1BEedJcWuY7EPyjdm
c2WOinkZoAhNx+YYS40PLofYRKfL/AppOQQiajkjGuPh5ZyKyJuOzbHgrG8O
AMfVHFjNFh6hC8Y6GAAgByA23NbdswhhP0RQjkDrQsgeRzo789jFJZgrGGdo
QQo+PHwkL2624wvQIQDremGB4y5bNQvVuAbdHfmiKCq4ITO5fnb08h1yNFrK
o1y+TEtTAYSsJQS9sOyRhjSCMBZMLRAkaQu1SAuFrqeuCjUqW4vJVi0g/Qqz
rFNWFk50xIoBhqK3KaaXcrLYUMApxGXbOc2oIIfOVZkWlFGIpsFoWZwep1ai
CDtrHOQIE+uGo2KUgQ3VV2zGKAWVcfzQ6elriesIaSCv0oJAqwQj16WA8GTU
imI9Y986DWIKOtAYqyNRZUyscBFAIqlPHHwNmI1LHAahFvZ4c/w0+I6t4QET
nYHPheo+kaO+LBfS8pU6fiA4KRs78rjU0SkhwH/DDA0H4eVxELGWvP2JsvP5
9d7grE2o1GIqjhUp1wIkNFWPBKt3fZvse3Rh6Cbcj0CXyRyrfVecdMi/3cSz
1cIPaMQdIX4L3kGjTxHH8xIzFcJdDscbhBBOVQ7Gm2ZVzXqZzTCZBinHjFHG
iYdZPzVW44RgBFuFulaLyiVXsLYe5YpV1ebs8gl3+CZv1NbeUi+b+jCMr4By
YWjcW0etuSWCyAx8uyNPTnvUTmADsDHcqT0DKyIyEPFu0q+6A0dKlhYeaIfj
rOe1xa4bEX0VdQtztVnt3H77Y7y5gxlEHjNW3B3QzbaFg7lcmoYycXIo4RLa
n52jAp2j0zmb+5EA6kT2gwd7zmO/3u+1GkcXo4pXBjvIdWtUZTK7u3diXcPh
QMBJ3oeKrFEjkWh4YdwubPp6NJQwbEeIddVaNQe00/d7cDDF+rAlsexr5Hum
DBicIgdDP3335mfZ7xl6NW4FVamRQbgidXKdEtv4F382st/jnGKUVAbEH5ex
DNPjQhNovW9ZvxxyvDD0yddmCOO3MEUb0jvr9autPbnyvj9egzP3kSOhdr2D
E7cFGA/25KH1flALhh/stvwp3Fp1CutFOTCI4fb2fKsf7Q52ITQKAqE9JZTN
wBc+byAK3LNCnARE1OJHlkJD7oPDM9H0uSddiM0F5PAc7Ea/7X28u8NUDpga
kx3dFEdUC3dZznnpR0BYJ2z6Wg9t0+d7L6jp+uFj3zBC2eXu4Wlks1e6VLkd
gRFCvn0JIglAiiGbrUsDEGab8knjRTPP7lnhoszxZH3VZRE1c48qoyHNWVuk
jZUkcsYRPXREY7jug125y8KPcdIUU3ckOoyyoMfPzvbZAYf5+ZYOI5EI7AWr
bKJq6OoqLldIhYG4lOOEz+DEN8Bfg0yBfAtYtN5zHmT2BlJrqfHuO0++A4mX
/UgunZWvIAQZZAE50MwBRHZmTuND8ChTZBAtMdTktACEbnqjTSj8k9fCF4lh
/bkUBO6j8nlUaIfB07QELP0WpWVmMCZDvmkvVz0gR8lmtjCrpIQwqrCw7w5A
o1cWDE5tESDwMOzWGmgQiwdzkdma7S5dOyYia9t0am4jv51LTFgvLWM8MOEK
TwX+DebOkD3KvtzzkBHDX71oZC6aDyNKwMJvUDqVvktxYbOeEVYN4p84Qse2
V49mglwqp+BVJe848HYUtylJGKQ/x0x/HsgSbiOq4lTFKSxHBRFWUBgDax16
CCgKI4Dzh9o8Pxsf4rZlhwCZGxhdB+Plzv3X8i9y4wJTo/jnPdRqKScPKoeN
Z8i3LqUdRJBhGFOp9LCqeg3EwvQZUz7XFg8j2TwuCVej5q1vdMA1EBk1Q4hY
5+lWgDSVUlIuBLj38l8w6nq91+GkLRB037ae5XVXNvZzr3/2GTNybXweLipt
Wi3bEO4Pnt6L+x930Kx3Zy+jX6SVqPA3mylnou+P8rYzDfI1dIR42sHRG04g
ERxKeLaehgZuh6tZdgK3i63HHobL18SFb0pfmgOxTsuJUTitGVxVEdzU4aKW
O7AYYa6vEz0tEJRZQ4uvw22rVaqp/w46N6XOokw9lnbWrsM6YZ0xoWwT6Mxh
QHiRMBlVA7XcZqA0OvbrPkgZ6xQqNWD/uGaEA4Jofps7SlK2KhlnhaGEX5SL
qvZK44awBLliLYG/IAS+vgiIdPXpeMEqEF4q2ffgHW1iRW5W1BkbpL4sJukw
5TSVDv4C9h6Xu5LYG5l+rKEJmAnkgrnWWRZd5tC3xZXXtoHDnQOz6kVb8EcE
8JvPM11+nhTzEgpZrTUh7GsMDlW2eWAfgvbHQQ8oG4FsjEfjG82Eb8JFYDcD
sh7unggHAhPJ2kIOfDZtsJRhzUY2J6hYtxFd8p+DkC74UIvogi8CI3oLA5Dl
PKeJFPbE+prE9dgB0/b7YtOBaa7NFZZOMZjPAoifKilpfiMRITDR4HzMc8Z5
6ODiBw3SmoCKuqh0NCrKCP5g6ZYrNAQIzeabRIMCyeF9oOmANOismgF8u06C
cPTEjN/7mj2UAR+WzoM4Me9ONYlCbQqDyDbp4GiHgsWAU5/OCINbcUPJKgeI
xRvZZZ0wYJOR3LgA2KxUACsOqm4FkEeQ6y6wl45nYYBGlcNgBqqyDyHPSvn8
pckDoFT2GYTIJxdDm4So0vV60lHuCJgn4mxlXB9I1cyqaAVqxnMjYrfUToDh
cfAQVr1ZA8vyJPzR4PfpkKbGJs2k+rGOo0Sl5VdRGDYCYdVbjYUMxBtnpWLs
9hIRfrLiXU5qlel8XE3o4teEJlBKR1TsHMRUAM9wFoQwvMHSUJLBe6/kqVPJ
4BL2KfHvkc0lfPtTveagIFOpRytJlkyhKXcUVhb1Q5Slq28oSNAwNtVwmP9u
xxa0Ar2EbGdjiEbijKZQIg+Mz7R9HrTlvCB8n3uv5HvyJmKVepzJlfvijmUK
dkzQnQ7yaLVlUzH1V/zRo3cuvBrS6gZXnqQ/SF2LT4RV5lzWLCnlusdhEgaT
Msla7KV02MtN6O04CEjfu6FoXx10DIHFC9u1jVJvFHFEglCvrOnq2QRl8Mh6
45BH7FoWcJofPTrT01lRBuejNnlF5Sep3DBuDlKhC/q7w34s+c8SK6i6z38B
ASW+/Gwu9fXnqsh0CYrXBa5SmMjG/bQjt7rSaKigCWkh+o16q4S0n5XpVJVp
tpAaEMacQK9WWLONVxCzbEJxd5AknsAsOR13Wi1gei8dQJsPXJARwAlGmVaJ
hEK4qAQUTcL0M0fl32Np5xFKBW9bMwZqn1AntyoVFunJSH6sLcqO3Oi2u90u
lWME+982zCAQuvo+PLy5WUHmzSkXxIQCn55oLiOpZRNJjZyIRX+6didgJj2j
SwlFsjFZKTBRh3NGbx+eUfkv8m+/X0B+ZIdShis/UVfaR3C694LyqbwdkL4o
k0M4FTB61C/ywmavDqgPCIlU/xFLdNAw8HFfsBJ3l2qV1CwHXF4VQisbsELr
RyaX9HfiJb732c21MMyXi6dZ1Hh4vnAuYYIYnwOU1TPwNYllJsy5vwnp6dZ9
CPZrV8Qtzd06g2nfW7nIBuYp7ZWR+2kOVRyahh1jSa+JMnziTohToFgKo0bt
NGZlMSsM8DTEPdZSzAThIYHawEXtOG6pLal1Z8exNVGK0pcWB4scgyatKUvY
k878lZLQFiNBtXMKFNbQochh09QsSpm0CHd3zGbHKG5CzAfH8bImW4ygFhr9
+ub8zD0/OJaPyfrITb9AD0uthI9YH7zon7V48tTS4DiCL6GdZhVCX0TG17vn
mUx0lt6oMpokMxp4Gkf+NTCdDziGh66/AREcEwByKhUsYeWiLDmzZUXZ8Mgv
mSuLMS4wwY67r2yAc5vlsuRamDko5WHalRkG8Mw408o5kCs+Xnym9uh+ynOd
ZULsB1vPITRLZZEN8nMuOYAOMT/7HcbMO8OvRhg1ffnC3pEVv/VJoCF7a1iQ
aJIC8V64yCyO3oZa11C1ysny7SDdKdQWBIf3tcou/ULbCwLxTOC8hnLrtmaB
3wMbzUXEEIDmqE2k9nRdofuxdDmn4Q+upiQxDU9o6BQoQU6wAoir/BzuDzhw
a9ct5ZS5Zj4apXGKtTQgNIosRrZUN/AvWyF7VN9QIez18VW4gfhQkT2Ne1qq
EuzZszn+Q/135HEG7uBSsFXelnf2/MEaTc2v0ixyONnpV191Dm7qfAqZnCCZ
qmmUMQ6zb1g+82tY25sppfCULFsElYFsUmkY/lSXYwC39OpLR8VzxUil1QT8
TYugsnhVjxAjOEdVzAqovcCJ6h89elmUl1zdgU4ZsgQzU9e5WT0VtyQd2RNy
1XgsA2Tl67oIaTW87mIJDFqv6M7xCJnB1Mk3OBoQPASOy+vUgKQRjOlXNrHz
yGxwK1VxKkDwgSTWEK2R5mOg6kLKkRqW5KtUcqQyLFnJUmDgiYVStLBMb4o0
l+tUB5oLrFBPaJa2cTmekYYnAjPuEM+qVbaeoC3DrjvBNIBuyRpFgnjW+qra
XYmcUBlWWnGOP5w9RsNmmZqZ1WKPrSOmymFalZRsKEGzFGQamnMhLcw0TUmw
aDl2UzUtMMW/17xoVWZ0o2RQKd31CrcTLXQSXYRlcKU4FphWjYt68I/kCQkW
V0hWWmgWbBvPglnRs1agQQgxjwusAygPJTwDM1Ez7R35qIz+2qRQKGITwEB6
gw54V9L4Eukbdc017A0mHnGOdrto5DakFr0iAMtGOTWui0YkqfedwDYSf7JF
Jy1xcAnhaEVdVnW2ENpyLHiKwLeZFcXlfMbuhFGpzcRWV1dZqy4HGelVC8uC
mDNRoaKcit76DOgsPtIIaDPhlEP2pGsbWMShNxRAbnw6tJ8NyoI9gIACGxE9
h88hWfL29ss1RJBAvKWnIFQQxopFVntFOQzCEIOgS74ttdjLMFzYZUlBU3NJ
ECHKJ2JsdRGs+QfzRer5SZeFk/3Xg2jMdqiitH4VEUiOnhdyLHz9kLUb6Dc6
bDSkKBRvWLAKLWOY+Qr7OWiqJEyzpA3aqt//1q94HyPZg6r1XEqKrgRuqNXt
OBx3roI4MBlWta+HIzOIXKZZNseimYQA4Cvn02b14JBoVcYTlqHWe62Qcih5
rcGNAk/YxIwvWnx4wQQUqVxlCwP7RL/2W6Ha8SsJFta4017NXH0pAgQgIfzX
ahHru60dm2Wc/vtLI+UzpGGmdNFuy+99Vj6WUv6r+3hF/y/cs3+x/wpu+gU2
/HfZr3XQA0vn7/e+Bn1AX77bK9vJ6vHv1sf/Appvy37QS/AeZY6yRzdQfpzk
wU6mFaLAbkjFcWtekOWwI3sQ7Wcgv3iFwE0mK0FsNpAQe6rhJfBMCUdkEfPn
Anttu8zfmMEH4jtyOSY+72vJ98HKwqZ1cB1i1R2kTPX5tV1S0KKeLoCdfmws
Y8wy4hGdncLOj9U8nzfB3y3EGaCRSXwBwAWsA3EO0G5IW+J8/sTPphA5WWJX
LNnt6uEciwIDhwlj60khYY6FGQcBNET1miEWEut9ooAFQg2uX1Jcw2C1mnq2
3CGmBncrVWxTTPSUjOCc6QCKCiKrDtryYaCQ0iJOsZQmVMtIKwA1BVyPjGyu
SvO0MFS/AxWaGfV/pqZQBtkGNNMgwO/nBqDsVCeYXV/nKBFCTSWirzGnnJ2X
V+SesXLiz7WyLAYzB9BAUrT5CllTO4dsReVT1UQGkcmIRLsI9Ra5S5Qc7eLM
/ixABFeqriVZ79xY51RjNIYTRpUr2IgbVpGB2bK9HzBUcD2KXCPYvm6cJn+g
k4CoUxZTfIIwsPGQQw4LuLsqj45nYYi1owaRqRaZzw8DlzEd5wUXGRoV5eXj
LwUqDNba2OGyFJjnUjrXiM2I5AzOO25haIwRng9iisLJJFYJAqYN6+r1Hicg
Z4XhOowUAOCrqwM9IX9BpS6Z+9X2wtbpTuMqgLyAY4FMLTWxwpBuM6OKSIrl
G+fMkLSfFhIhELifpUOuI5tjqZRpUSHqwUUueIWqLZ3aLjnPPtboU5lkS40n
K3WBB7hdvkBjD2jdCNhDsaN2BKy44RKceyIKBxBXx0bjoWModIBC/oFYJzAo
MPatSIJdf/z2p2X/Jtp/V6S+solWVAgfgeUmOcSQu+VYleYhBMqsjmtFVyob
ui+qxYyCyW3oYOiYu1AZuTX5Ylq14Gfj09pLlB4zrJV5hvKc/yZI0cS4OEpf
j/4TcMQtZ8lH396DXlnErlp/JNdBxiAah9pD18jtLX4R4WlFB/J2zfcMyxUk
o3nqJ42gEFJcK1s8Y51wXOCIkeCICbwt0Fvoh7EOCpfkudURz3zrmPyBL/w8
L7UyBcCH7cGUozm5wUMvBnRRw255B49UANBtdcQvwa7N0btFCaKaG1fPl90R
z4OhGcNObIvpbsCLYdWzAgADBH/siI2ufx3RdKE0fW+vct0nvgC5K7VA/GZe
c5cBi/EyrY7Y8BAC0IeZpidheiBLGIGwIM7EVkbb8Ad/CcC6fnvrv2uiD2Q6
woE2qidh1RFIW9MRG/7W1HzpMB72cTJklFBO5BlopDxqACsGOZfKpjgdmK4l
AzWsOWJLQQ92art32oq6T3MJhrGyIieunN1JlXtHFzhPwbtVIyHEkRtvW0wm
+j6cU5lvZsPTfNeqER1X0K3RZGpWJz6xCA/KfTIY1VvgDOtwqZdd1j4DCbl/
OQkJgX4bqGFOTwgSOwOHberBoUJR8UlwFXyWjnAGVOKVECKMrKkTJY7+JuQI
yIvN6mZ0yVhvI/W5mQCrxX5bl7nNP83XyD+KQBIbmeYQ18NFmLOLbR4cM1Av
NgYRAtCELXdf86g3BwzARh8QBxQX9srXJazXJKyVC3Bp//VUqjGQNSQcSIvA
iBR46mfz6nGQQ4jSptg8Nh2K/ISaREVZ4RWEajlcFsf/Im9/guDxiOZF7i34
/o49jY2gKo4cBe0Nm6Ok/Bsb3bs7uzSYBY4kDEjG71rcwfLg/bMoKApOlbJM
g+sH2RVzOZ+xqkJEFARfjt3uAKiD0F7fxKUyqIHSZopXe2fysZqljzlXAJ4B
nNDjjc6GeF2Yakfyb5QvPQikF8EcdqRevJkMX8Vpp9PBKWxAL52OrQAEz/ry
483pEqXiAteh9oGdtgW6ZeAIf29xNej1+OiUZxfoeY25+V/+7Pz8xJaf2QzX
wNmwLvwrF/asZHiamtVX8CArhxAQPoVzOHFveofKmZKt+XjVUOIi85/vVCAO
qsZPwkysNlI5oIHAxEuX15n42GGRR3jy3Q0yBDvN7Q/uwEMgaP9YmipJi7bs
bfZcLCumwDJt2Tt4e9yWuoo7rTbZFnw+q9gXkQOEYcIhjy7HIjtiqaufjZjq
SiEZ0PmVzooZh4LS86js+raBy31mQYOqcQSlB0m/w0dK3i3/BJ5Ycw96heu9
iPtvIjJKULmyLFgnKhWOKKN9KsmC6vZIxRp1iKA2oS3eS+N4oMJhOp3OK0KU
1uBLPV/1RX5feVfK5oVirHAyGDwOzDDGG+wKXz8YieqyjgV1p8EADyei0vEk
B512YfOWL1epkb5KDcqQdb2f0qpTgjiLTevNwD5HOrVT/oEQHQEl8TW2bVou
tNe5BGcAAQU7TUK8sqDUxoSqQzBaiP3qyWmRFxWFFqCMDwk3DIX+gI4Za8BL
DzV69AVmGqVOmS4jrGwf/RnQ3p71HnuHhrPJOKwugrQGttYpDaOeGg/ckGlF
0cTxRE8ZpWr7hnHgQWIHCzBk0pTTfNyWB7q8RH1Lax+aibZJrPlHsxinZCJz
6idALFJdjSITp1UVgbk7BRsWoCZBABQ/yVMdz0sHynIlJOTtT4Z/aRaXoLjJ
CdpsglQOyoDLmnJ5JwgOKzHA159fsimhFXGQJ+lVmsytMcFgnYYh0dWymKaY
+zCSh7pC595MVRP3jAvOBx1xmlbp2FkwnCxhB0+xEBzaTy1wKjjyucwytWDh
0GeBIJdp6kEwaJPsF1k2T4LyAY3GvOPXm1uddzMiJE79JYfYbYYhTFWezpgA
BNgi66xjcxLeZhCWaelxYXtOjbSZaX0y8vWhtWfhqpwu8nhSFjnFUIGWbWze
N7THVNh9XfHGiZDg50rK+nqQvFkM4TAc21/jc8S6TiHItGcMBPYWeYDBaBBV
rIgOzyp8VieYqaGZfJbsSFxOWjQXH7xBwamyCWvR/g7WTyzvGwT/gBVdWG9o
bTSo7WK3zqlNpbrb1uvDLmPKL4s1/trANSFzow18x0YAXr0MdFRhVJsILZji
zKX/Hs3zRCGtZeylEyxxoQwQFZ2OMZ8FYEiJFwwwMMM5rYMX1WjERu3zwcHp
ntzrnzE2K9d5DpQ6j67TqdGRjiuszHVANw6uxU7ogKaFBXWkGBZELIgONo1s
HPlLKU7BIUDkn4UjEjNCcXJVHuTU5hsnfcytqtdlQqMISiNpJV3KX5tLhGz9
zOqZO1g2kmNdM8u0mPcRPtPyF0Rg1FgK6p5XXJG5AosswpzS3J71YuQJBRD9
gEI8ekT1Wx19J6gvxdHAFZjjHaxXFAxPqJCBGGLjqcnkf39l2CApNwAg7GW+
TqvcQ228Gg4Kspdw0A1iFx9rsuH9hkQRfXfnOAbAK6TBZYOaSv5ytsNELJQC
GxQw4S+cVc5c0vn1FPw0YM+zSbAtThMvFFVhbiHwyxPoeuXqbzUiLHywxQlH
/Iglqd6G5ZyziV6mNfUATZeDiHMnYBoj6dEf5meZ6HxBhTHQ5OPrW2IpzuWC
kmF+BB9ScVVcklQBDKV/sg+ywlH/9BjNPr48JaY3WG4zjGx3jc5nCZ9aYp7Q
hYP22jmjneFJUKO0WZe00Vst6QzGZ4HL2BV4qiVzuAwSkDATXBUIbrfVJ/VT
zSFST/XSGrOiIgcE+AUh3MbmGkKLeJGSadQ31BG9Wo5bXKZRpsaoVCDLsIWL
RxXbzrWpUqw1KIJD5C/OCQkkJLBANh+uUCkEiZtBBb0giCMwyFN5k3XnEnax
HC0xsymbWephdyawh0bYPiueOAMColH9PjSlZZBsbkEOT6NRPUhqCavJlu96
Uzi9CBO1oJkZO6do0nt6FlS4LGEN78yhfxyvo9VA7RB7s0UyVMUdCDc7zmiL
RDzXmqxkoE3ADlOSC+uCSmzmHwvUFjZs1ZqOg2rX8vansPg1ZVIyWHQ1A6+6
P+RyPS9qGhQYC2WD1rfaaKNyMh2v31KRbTmeK4h41ZjgbJnaIFjXzg2tY066
tXcFogmCmIUmMYSDJTyoPmCpDG7CXM72Zx9biVEMeUIX+jrNMgF+nBrEsyEJ
ApbApxty4tXu0UkPkoccnfTu7mSvrNI403Kj+3hjg+wuCAuAo733TvYGUG5M
3t7uvesNas9vhg87qwABP3YePaKcOj0bmBHy+pq2e5VSNm52BpQ601cQccwk
i4InyFNV0/dSqwzKdYw7tLocjDvQ5jBABlL3NM7Dt7S3MM+0zXkCI1nF4knc
maF549SfUDgS7ppWiHfwRAFgZM61AWeKfhGkhMfunigrGHDGPCAJLTRUgEHc
zLK0iq5SfW3lIiBmjabhQWodwVz2ZFm7/wT8WGhKofrZ9tVWM0x/zylRQjTo
CplVCTcSZj8JfUsWIlFAUvaUHXnrucZ0HmRD0Ka1HLm5ItFGrDn4HnKirDRQ
1UmsVYvDeEwKw1xKKUGFdCDYyTkbbfnKRtg7mB5XRrmSMuvj0K2DieCewFvC
HBmct4KzZPgYVRugnCPsaWTPGnHlmqsMcQalTSzBqa8gCO5mBhHmtg8TFKwW
3lNlC8MvOQ9rfQDhQTyGDUxboaicBGueAa6AfVpPn/z2wgZyzlRpMCN+JPc4
As76llcEvDbD3jBGOsU7vfw+DG9FAB3FR68KoBOSQujacqX3LpJ9RN7W1sHh
w4uSIU1ocIMs9iE+lQtyUHKQRoYGZs1gHDqm8qLLtqF76o4yzIVinFAVDimp
ZTBgAuHDG4JkOH+AFZUNm1na9bxRaPNKnflo2QAsWAWi3EGo+WHWKwfMoLir
jCMVLrDKSVjEtVY4t1Z2NRDjCe9C5VvBQ8DqQyb1FCKSVJIgOhF3AUwjaoq2
E+rNFfr9jhq9gEZt9DYqtY4wGosSa86ChFrh2roxwSJ0LHnhE8wn1ZYBaOSl
CxJnkXIvZPOR5n2sVRwOlQtA/AX51HCYSSEJT7WqczUapVnKQkIUeitR4Ku7
K+EvKnZD1UusGxY+Qc+I/SO7DHeK+EhK3VlbIUmVY1/tHp8I6cSIJ+sbLcsl
yTCGj2WIeCS7AlHeCvgQJuCQjDZDsSEw59IwEVGHmVU4EyZKAKDmQ89efHkm
10ss/QjJ7kpl5qVuBRJNu3a33KnnUGmQYoKruE7QTHswaDC0VqW6xmmQisyt
OIM+yzSRmZSaEsqMGEakjCnilF0U+JROxEwtskIl5EYZ9A57DcqBLOMASrfJ
s8UMEut4kzUbuWwuWevrMnW7NjtQPSQcC8FJsLXhdcZm4bbtWK0I247k6XxY
Bb8R8AqZAvtRfPJdyOqVa6TgXFOnTuZ2JKgiJRhUm/UAgXe1oDdrVW++eaqh
0P19pvW7DtrGGwDP1W2sSNiBVt3Q4bMja2vaWXK+v0Sf3D9gG7BRcqUKdruz
tLD2ejED2y0Ej4JsCvn+jjnRqVyH91o8jEPIFMpjWazhdr4OHPm8dYFPGIzR
XvW12VN3cDCwFAgI2cEShwrqBX9jeYDPrkYg3HUeGAz7dP9XjqVWxO0fsX0M
5GKcJt7ctTenR4fyXA8p5pc7W7MNQeT53+lL3Dj5d4AdW24k7/nv7/LESqT2
G/H3KPiv9uG+/5Yf+rv4u7xOE9/NuTWABDx7aSz1pcKxkKvfPQAf6hGDXM7n
G63EauYf6IfawlJuugda8eV/5d8frAj84FgAOOweWFnLlgXqB1ux7gp8YM+G
4nPtuxWLvLoVDAWxD4QZRHDZ01ra1d6r1j2tWIEAW1kqa4YtYVjAw2OxcsT9
rTCk6dvrQjvwd9lrhjK5RB7fGAth1/iBvSASyn39PWdXl6V/wLdSq0P1rVZE
FEWUNQSQEGgUSW9kb8dXeEK6cAoubCVud8jtoZN/WcNYmLW7ZsxW8Lhc3+xu
dqONzZZLCR84xWyEC5jBrJl/fWWtKIrUsnar9WZxl5YgsQfsY6TbpCHQydor
RtgKikrpCMODAvSu8P65tsc2cvzdBcmTDnFI1PNXH0UMrUHsWNNdwQGotBi2
qojx0jaO5lcHkBCU3Wk9KDZpowLyQP5u15yJGt1QkxTsGwL1+japni6DTJt1
TjTJmhZ5WV1EpKsUgNAJDIQaFsnCoYLdaQliNYc6yE2S5uGeL5WH/ieaflhR
HH6M6OtOUY4fY7WPx3xWHvPzWF7in6ioy7zMd8AytoNCm9lRcbVDj+3ghnN9
nrTKsKgJpRmtpbCQ61Df19XxwceogBtXx8j10ciXXJFr/8RV0H96/E+JHpnH
lK5yzdU9ueeJzTVbowRGD9/7miJEPIF5BmVP3GhIOfBVUmYYiIUVVf7Pv/Wi
Tyr6+jv/242ef45+f7T+r//aWf1L69E/rYVVWtZyX1cR+va9otVSl1Dbj3NF
Q9ET9958jhvwzcGSUo9bBW/U+ga9BQSAsJ36cvOCNhq3DchaifBgEBifFNSr
gQop4Jipz3BFaxInO+BnN9z3d/zX77Xx18oErT4+Mqg+Q1VdbDWh3/1+oowP
MkGjKo+rO7Q8aNqVfTQ+wUjDSawqPrRymRp7hb9BOsja8vNQMD1jO8jO2G4k
Z2zXcjMGr/sAz3CMtdJHD2/KGjmBzGc8RyvuV3iG3Va5BtYsil9lx+FKVyUl
23Xb6YnrD28q1zj69p66YkgrphFQgfpS1asiLQ3p+6eMjLk25+VaSQ9M+b5J
3Vdd6U/czQfXZOVBcn3Sm6uO0p9fHs9a93JURX/wXLjslXA9oHJZW66ZdPwd
B8W/+c3rQRXRViweUtzao9D3f9wa/YnlgbpZ7bCIVttWz/qeJaKqW9/NtGSz
XtePvWmrev0DjnXzXIVn+8/vBIr3P7wJWHH226vNhWm/cRZdadp/7BmjzD1s
ePjBCfrBQaHFNpVKbFOxwzZVHmxTrUF/R5Gzt6nanmX931whquP4jQWiOo3f
eIjqMK4ih1Ziqj2efh9jrHPUH3zjB4gM1Vv8rketBLX8LP5Sv35Y+fB7L18o
xn3vrQwEgHuYTY1dLjfgf25ciuxbZCC4HbWDz8pFcORVlpGAvGoC4TWRd/7I
5kVVP6sqXzTEbBS0a4TBVSz8vS4ir3yuMt96jAsC/h4s7e/3z3nz3z3n1XNp
c2LMti9d2HbFCr99x4Mqjj8gwXEqzn8A4+ArtPJwBkUgv0FfgoqP3xS9bXnH
HyEWrvbjD6sdq4vK+wLrq5UJrqC+PELiiM27VSsU7E1bL3bkmTaVfK/jqijN
apNWL8vkFT1ARnKwKNkWKGqyHjPqgBfN4BiqrDNKb3TiKrkZBHogRBW/D+yg
jCin/BacPAKyUEBvGFyJFiXwQwW2xvVUVS0wevnKumh6exp1N6PNp2fd7g7+
71OrI/cBm/7C+rEsPgAjqKE4I6PjIHcSwPbIPgWxcnJYasVJrilm3xebDBLY
v+h0qW7cAcQQpyq7z2QIgS12PQCfOVMpF/acIzC4npj9Mk06VOEQnhinVxoT
mbw5/80lXXhGVaemQS0j2/7Rb8dUU4RwVq6M3q9yLVmzQZwWpQybg5uwduN/
cyG1jF990XQE4r4Ybbe2JFDqGLzcCCaDE8cWHV84qlmTj7aZwXJ1K9olFRc+
+u2Y7FVxeUXVqXGGtVrUqTFQgpq+w296vb1+7/rtyxfjeNB/W+zv9rpHuze9
k73JwbuXJx8/vHpxqV7dXCevJ7/QWzf41tO911efj4/29p8k8WH343b3qjc9
H11ufOkPZ283Rq+TxatPL968PxiOXcnXPz1oSLlYH/Sgv5cOFm+zN2lc/HZa
lPv97nz/a+/m4MtB9/Ds49bR7uXTo6/Xz4+/hIP+TS2ePnn36pfFVX+xP/nj
Xbfb3b/5+lG/m3b3P0/2B9n26S+Xi9/Oh0n87x80JTGNGwN/u/ey/7Z78vLk
Mhmcvpvtn+1tHJ1tvDh5lx2+e//+04fzl5k637hJPmThwN+8O9re/7z35v3J
y9eqWuyqpKq23hxsflJ7n/Th5uTt3rPJi+li9v5T1xfYhfu20aEM82Ec8w6l
kHNFfywwmyeB0ethoNHKO4qV6cgHupR1+oeKo9sDaYftXZlL7XKRdFpYwvLX
Cp9znfV5YLmtVTNf/n25RPn/0srk31VmHCx531lSXDBL/K4K4UG7D5XdbpT5
7q4S1+6t800AtDXHcmk5f6wY+7+/+LY/WvfE/3LyPRsvfpS+eflp7+Ts7enA
DPKT7bg/eDqYvvyS9Ks/kq236X7/TanO38Jzs3jroFKb77cHebcDDcAX8MPk
0+b7edLfmMVbhxufPgzgpa/J+SD87Wty/uaPT+eH3UF6nX788P5SDL7MhoPp
y/zT+XZ3/8PhxsfpLPtIPRbJ65Pr+Gtxtb95k316lWRxup3pVy+r+NVNtj89
vBqevknEfv/N7OOHt+nRl72tw6+D68Mvb68PdntmMH3/BKZxcBZvHXzpbR7u
Xl4f9K9TlZ/MBl+K9PDs3fWns3FXHOz2qk9ng+2Pabd7cP62u3++t3Vw9rE6
3H27efjl3cbhLjZ4A0NOXr38qhaDp3rx5jr58OZ6uHWYCWgtmb406vxkkrx6
P/r06mX3IyzkFD6/HMWb7+fxZtZVHz7NkteXsB6LTx8Ou/E0+5K8gjXIu2Yw
PZzAcM+3TPrx/LCrzp/PoeF4+n7yqb99+fHDyQQXbfP5PN46WXw8z+bJ64P0
KDepGJ6/fPJh6032cfP54hN8+WXvevSha2B7P26dzIabT6DXrXiadT+dbkPv
G8PXb9PR+64Z5MlMfML93rv++OXll4Pp26/75++6n768qw6/xE+OTjcmH6eH
l/vn76cHu3uLg69vN+h7nGI27A+ewjm4/PThRVfBivevUxzR5kkWvz4pBl+K
xX7/zRf16uVsmA6enm9sPB+97XzO348Xsycful8/Xi3EIhsuXoz3PvfPf+u9
T/YOXo5ff3k9eHc5udkz5S9bx2+vP5dfbw7LxW6y8ez559+Sy37x+fLmfHc4
mu69fR+JN72NaHaZv+jRyd+7mVFdKrqQO7IXQ8gseyBdvhMXTEfgt8s08fTZ
5b91seaWpSzn/bHS3mad+2wS9/HZErxrfD0oiI1RNi86G63/YM5jpYr/5Dz/
23CeQHVvDMWVyggexAHxMm/xMju1NtRS/99ganQ8vLq/tvu6KI7e3kx/+VD0
5+dP1OaLo4P+5qfjX94vvr78+GVjfHL129eTZPTh85i92t4CsJZvPnk5uHxW
6Y/zl08XH0bvX/zx5vnZ698G5/N3z/vdg+0/slfZZL+62Xy39h/IToFD/ic7
/f8RO52+fyI+nR+OoNdVPcav32TAbs836GF4NqFO7IJ/Fbji+WH344eTjXgB
h+fwavjhhfn04QReRqb9EM8W38O0H+LZYhXThrMxzF+MFGwb9H55MhhuPj9+
92FSHb2cXL3dev/h8NXe4u3l80Px9usb9W53cq4/zF6dnxc3nzbebJ7+P+1d
W3OiyhZ+719h7fNwMlWjxUWTuKfOgxdUEDGgAvKS4qZyEQzgBXed/36qu0HR
mMTMbe+Zk6epmtAtLOj1rbV69ffRq5HW1aYqZcIvcmOp0nGyZTUVGI3T9xah
yT4JJFerKV1NEYNOfyhL7IjwVUue1MR9UxDUTixRu3Dck6oDf+LMxEozZWzG
GayowZbvMbbTAY4ul2eSy23pO9liFX0R6l0rkWgm8KXBjiVIV6iXx+uHYDJq
P7GN2X062xuRQ3fGrkFQexUsCP7NcOK0q+pLKXkzvMhBGIUXh7bCgnMuMrhh
Ktc8uqAvRhcZEznqrERkzmd9hS/U9H6pqOLSX35EpFB7I1JAeiGP2Smjq2OA
TFL4Cog+u/IEp/HNXPEQ9Dskrap/nN5HMQKg/r4IgPzZae13x+HQmSqWbwRi
YtKyoy9l14KOe+kvrBMYbSAY1dTFlnXDnbA300F7SoDhuLHlW9yT1YUIx5LC
uOkPIXS2SH/g+g4/FndaW0ymY3MnOAQhtKeUMJ4QaML2xIFATkxVIWLd1R0b
NEkzaG5MagJvO9FULtDkegZc0v4SYoIcMqdUPTF78kWkKwLd+XUAXsi3uK25
lD0Ul7gTctCdVOEt8sokHSpsIrQ7ntAiF8KeofixSAjulBTGIjFoN7ZgkLLx
ewcJLc7iW5xvd2UXqLS0L1p14CKj7q1uh7BU9HpdgyK3RlcmNAXdLZ19D4tB
l92B6Z7zBinpC90pyeMiazJVOFdrkb7mnhRf4WBPU7YohNC68tbqzh0wdGHo
RC7sTv2ItSMYdywWulJ1hn5izVSi0g8dz6rpK4sjeX5m+URAlPVIrIKgrRhR
Ou+wS4u5Fwf9ROlsGbpmsC7rR/csr5pRmXDbw2ZCsJx+bzwSqSYNvcmDz8xb
14IXRpAvuD0dMW8clQEKYOImTr5BcuSFOJe+yLGqerEOexTozSnYbnAz7g/P
fb971dW8gE/mJWQiLyDT7buR6fYNZDpY9hFGEj8hPa092178nrVO8gIoPEsL
szt4oYHs+QvMLnpv4SAbhtvI/jCnU+NhPXKmu45Mtqu1p2bf209CqqsNXE/2
hCrLBFxSrdJ0S7gfcLdxg5HTam/9FFVtY925m7X6q03XcYeOFQ292bTc5Dot
8Y8Ta/6ji7hujnI5yAGIctP0IrrtLqGb4J6CG3gfuk2dc3ADBXTzNGXna1SH
0BRphrMvDqYu7lRtQH97h2zS9TcwrWEDzp8q4hocs0xhYwQwm+ysjADCx+ou
c+Cppggbc4kghZyppFWECwDx4lvgAkC8GLrMc7hwTuDiDqVvXTmYqtLGdNAr
Ruk+4BV/b9KybzrwMVaEPmJv3wOfMOvcDtDHI6w0nHVqisKJliysFHXRld0O
I7Tlneglke3Lm4Fn6WNlFcnLZCgwfgcY3ooQ2uJ+QAjDIUP2hUBoSrJWE5gF
aaosoSkcKbnWUiSSreVZK92rr7Qe96BTmsZPuD6QPEFiAxJBolcddZdzMWpY
E+FxVuZjTm7wtQYtlimh5/tdfbQjleHSMkxpv1Go9XBmJoDsE/bjfhdYj3eT
3oZv+WOGIL2+I9L7Ceksk5b4BiS2nwGUnmTnRcgv52r3+qp0U3CK/6l9wkdt
jtoVRYX786tJ4lMOlrWLid3xl85J/X4wVhY3cj/w8gfj5TdUaGs/JT/7gOIf
CcUHVOWVxAf2iKtXvgGPwSHr/Eo8Bl+RbZ7gMTjPNt+LxwAB8lfiMcz7gKtS
0NRHdD9MFjRTmOfBrCtPEp/liPsJeFeSeAH0wbuSxAugD65G/RdAH7wrab4A
+uBq1H8B9MHVqF8Efas1SYdxuomkBtgM7paEMrzlmwG7cFzT8wLfUGlP7u6W
Xt/f25647I8bnGgMaj1KMRqt4YLmV806r9CLeYsB/ppxF1bV1xvbd1Vxj4R4
58HANfXdInjm+A51JwK0y/hnkTgGxxU501VGlPSr5cF/Y7X2/g2MN3QrQ6z3
w/sZSl9ERvp7IOMFOHQvgV3szMkDNH1+Y1bj0qzU5Vmpq2c1L81KX56V/oUy
2n9c/Xb+av3WmSrSLEePGaomdrawwlrcoARoX1TpeDzaN2Wymu2Frb/0crsO
OGz90QirYk2xFla3niLbjApwswzRbq5J+QHa8aT8YDDi6oDvXRjonAxMnw10
uHo+DpwMTE8G7p8NTLm6qpL1irHQ7jRd7d52BfBU3Tw9rcUHc8cuO/66RkTy
fcMmb9vErfCo1g2pta6vWs7AnFL8uF9Xpali9n3JnaRNSRY4FRCU0VG52rbb
eKmWiln1KqUDdWHphv508Okn5IWlG+qQ8d0VEKHAb1AgwneC5/hzGRtevKfx
6+kqSRCfDjqQ1yetXwrE/Sd6khsnRJz9mfYGPjCAM+KCzBk6A41p02zT+wJb
bw8sFVhvKLfRfcFGh43SM5ZHU199bG9eDZj1KwATWvrb8bKY1WKxkgoSU4W8
i/Orslvyld3Hj43AK4HEuwJI1IU/TV9OycBpFsXV1RG6TX9K1hewtyjP8azu
ZK2pmm8GPqF3/bWW4owLvJlyjV/flgMzsdJgy31CN1KllzYm4x07GVGU97RY
jqz5bCin/KCnD5e3G33NWPR0FUri/cbac9TQ8D3iDjyl6laqrRp+295Oh9sW
Nx4t2T7Rmr/h1I/tGc+/4YOaEJZaQKyAsFdDz0+sIB9WL/gwSEMDWWhsRAlv
HQ9JYa1KN3F+hwbQn+XL9Dd8GbL0Izxp9H292Qs1uqs7LvRXOi4+fN63+7wu
86rPc21FiDW5TsCewZdaBcGzzr2APLqvN6tLsQPyfsjr2iGbC9Y/bQcEhX7A
3evtgFy9UperD1ZNDPtNlQ+arQYX2OBBehQbkcFafIOZdrwBoe+Jxjh6bNw3
n1zRaonL8r69Y3bxnm8GI0s2/V5ICjFV64xW+6jtArn9lns892JHnZR/H1za
Z3QKEanfYOeXe0Yo43twjZn0+7PeNRjitRvdD7d4tVs03upgw5Z+xAH+T3SN
kFR258RQY6SMf7wMn+rDGf5QZ8i+3gmmq8JeV2qBSjcX5hI+wvNAEJxvlr8S
CJ5UHPLmr6wrvbYxlnJVVwUCd6fnv0iiRytMRkAfd7QLswXQMCYtLayevD/0
mnVhyCl78DU9jHa6y68d/tGgzIY2phjdqE2kcqC1BzHVZIDLeIu9zVr3G3E/
9XxLNOqL2i7abKR23Y/dub+39Oo2NleTMhsq1eV9f1ttvVQ1fsn96ahDCkvx
5Fk1lH1wwnV8FO6ykGM7eEGy4AWxCAUiY0ZE0r9BKfi3OQ6U/BbHgT4Oov4/
npwJfomTM/8nB1GLxdnjTuKhmIBl578goSYjTey8IJudOY3tOdaSRVpkCUIL
LK8G50LSLRmwUCfVUywohlW9fn1UeSuYJqoXkIKk340U5htIkdn126sMv5Kf
vC6eHaAQ9Vk8uwOD/bfEs4NX41nf7jVXMORUack3afHi7hjIvNDZ7hhZryz7
t+UBTy+8od+QNz27W3t4CDYRbYX1/rhMzqtDduT6TaBEZk83y9yDEuyHI205
cJgR22/cLlVhNJV3wbjNa2nHaDzM/ajVeKnl8FhkXKG9j1xdKk5KN/mCrdag
es8asmRnCk3JueQR5D06bCuRdGHV57x5MLtGNcpfZ+VvozCYY0ndk3X/7P9/
RHxovbHq0U086uvfcN3T5rK+1lIyuwYu6w4JQRmwgZUaVC3gFRwjQYegKx3i
pJDfRkvbt3uNYhhUg2EQ+JqWZDghPu8qLYBJxSjKMHtyanbrew1Olt2VSnVI
rfMVRb2ZWLnfPBC12+rEdXYjMwmpTUgM1No2qY3VR+uh7vjt5r3+wKx8oATD
cCPOxUkv3fLEY/NppD/NB3dClLjdgB0v5ZC7lZJJ5Mr3L569yVe9vraOoJ8r
tx4XNxTdQ5RfSP8ar+1qYW2fdSwdpV7RxwmpuX6Dmtlvkzx+cEn8w7gkfqX6
4e+bl34wOvzNjA4zsRKNV7dhz+f3XZpidrcPxH3U0GeLpbuXrK04drfzCdkK
LVIHXield7X+SldrM29mt5x+zSHat71Gsp1MpVvysec3lZbJubXHq5LfMwjL
EtxTjgQopAtT3QzfMMfBws507f8dH2gqPTs9b849S6kPMForwOg6yGbGLUg3
uj/HOxV/vLQVf73DWBtUzUeLoudvcdokEH1qReO4KsnedwzZKw5uAjgc/qho
2cH9cly9coUxEa5jsbQSfAgnzp7jy9kzxidUmzpqgMYtV0dO2NafpaMydWlk
2oEeOeELPBL/+lepBVkXB5BAXveLI280OwpLbDCL9IPGzwt2HW/DU6FT2EK3
0IM5otgqZyrVR+JR2G2ml5CQoI1FRyuAgdLGKFhAX0F8Lj8Un+gmFfW+oU4m
KNCvVkpCWBQrzyWmSzFW+Y0rpdHaSRCX6SyMgGVvbD9cHXSB/HBbjpzYK+VC
9PBYNO8snSQTuxPC58rmN3/9daKo/t8sq2tBVjHJnq9Rc13RvujWe3q8KLcW
WMqdR/d82cSFs2WYuyxeG0snSdCXARsAnyuBZ8q1SBIdEieVcxXvSgkZG9sQ
K9UjIwWQ7fVMCRyN+QyOgt2Z1rYNNUVhegrb7ZEsNZwFmg/Vu5AmG6xylbaL
EG4bw888uyEnzu/WsJMtlPfFPG25jTJxcvyv6ax0qPQOsgw7fyen7xDLrh8F
RnPb05VSz5kvyo04XkdILQ4rwg5PRVuPb+VK42Ol89z2WP38knh5Bf8N5Brm
eHCSQO1jK9PczrRQM0eqx8+/rVUUhrO4AtpsuwzZkq1snWQ5BrTVDRat/VSy
A2QTKBxbjiG5u+3MA5RRLPVAn9uHTy9cJ/lraDWglHFhmefmq1ZKCjsYMSUm
2DhRGKDBLNKGf4VrlQ1K9vH6TCI8mwj2k/ow/Ezh+Qk/TCE9ckEVE35B4ChM
mTlFbDdTjyK4AwcF4OdQVBRZD88LJRPhpluZzfIugEdi/8pknyb8RKETsAtK
7Vn0H/+JWZZb49y3gG0+pw8dROEYpxNkv5rYEZROgwMbx4FIgu1UeLEgV4iV
x1ZFfdRcTRFtPs7hSwtsC4mXHdvRSg3TC8ItXELIqi+r1+FfRmrLHu7qYJlx
B9/x59IQitJhYm782cKnhOt6HoXrVQzgYppBbbV8bcC/Q8m23BqHzPZzoTv5
5Gk/IzXe5LAcklK8RnrW2CscrQS3WpGEdoxJyeOipmgF/A9JO8+LuXIBAA==
-->
</rfc>