Christian Nennemann
56f2ce669c
Both drafts now live in workspace/drafts/ as siblings:
drafts/
├── act/ (ACT -01, native to parent repo)
│ ├── draft-nennemann-act-01.md kramdown-rfc source
│ ├── draft-nennemann-act-01.{xml,txt,html,pdf}
│ ├── .refcache/ bibxml cache
│ └── build.sh
├── ietf-wimse-ect/ (ECT -02, submodule, PDF added)
│ └── ...
└── README-pdf.md PDF toolchain docs
ACT kramdown-rfc conversion:
- full YAML frontmatter (title, author, refs)
- section structure matches kramdown-rfc conventions
- {{REF}} citation syntax, auto-numbered sections
- references auto-built from normative/informative blocks
- removed manual TOC (kramdown-rfc generates)
- builds cleanly: 133K XML, 89K TXT, 208K HTML, 167K PDF
PDF toolchain:
- xml2rfc --pdf via weasyprint<60 + pydyf<0.10 injected into xml2rfc pipx venv
- both build.sh scripts now produce PDF as Step 4
- README-pdf.md documents the setup for new machines
Submodule: bump ietf-wimse-ect pointer for build.sh PDF step
2742 lines
130 KiB
XML
2742 lines
130 KiB
XML
<?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 " ">
|
||
<!ENTITY zwsp "​">
|
||
<!ENTITY nbhy "‑">
|
||
<!ENTITY wj "⁠">
|
||
|
||
]>
|
||
|
||
|
||
<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="April" day="12"/>
|
||
|
||
<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" < "internal" < "confidential" < "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 < 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 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 1701?>
|
||
|
||
<section numbered="false" anchor="appendix-a-complete-json-schema"><name>Appendix A: Complete JSON Schema</name>
|
||
|
||
<t>The normative JSON Schema for ACT Phase 1 and Phase 2 tokens is
|
||
available at [TODO: reference implementation repository].</t>
|
||
|
||
</section>
|
||
<section numbered="false" anchor="appendix-b-test-vectors"><name>Appendix B: Test Vectors</name>
|
||
|
||
<section numbered="false" anchor="b1-valid-phase-1-act-root-mandate-tier-1-pre-shared-key"><name>B.1. Valid Phase 1 ACT — Root Mandate (Tier 1, Pre-Shared Key)</name>
|
||
|
||
<figure><artwork><![CDATA[
|
||
[TODO: include encoded test vector with signing key, payload,
|
||
and expected JWS Compact Serialization]
|
||
]]></artwork></figure>
|
||
|
||
</section>
|
||
<section numbered="false" anchor="b2-valid-phase-2-act-completed-execution"><name>B.2. Valid Phase 2 ACT — Completed Execution</name>
|
||
|
||
<figure><artwork><![CDATA[
|
||
[TODO: include encoded test vector demonstrating Phase 1 -> Phase 2
|
||
transition with re-signature by target agent]
|
||
]]></artwork></figure>
|
||
|
||
</section>
|
||
<section numbered="false" anchor="b3-valid-phase-2-act-fan-in-multiple-parents"><name>B.3. Valid Phase 2 ACT — Fan-in (Multiple Parents)</name>
|
||
|
||
<figure><artwork><![CDATA[
|
||
[TODO: demonstrate pred with two predecessor jti values from parallel
|
||
workflow branches]
|
||
]]></artwork></figure>
|
||
|
||
</section>
|
||
<section numbered="false" anchor="b4-invalid-act-delegation-depth-exceeded"><name>B.4. Invalid ACT — Delegation Depth Exceeded</name>
|
||
|
||
<figure><artwork><![CDATA[
|
||
[TODO: demonstrate del.depth > del.max_depth rejection]
|
||
]]></artwork></figure>
|
||
|
||
</section>
|
||
<section numbered="false" anchor="b5-invalid-act-capability-escalation"><name>B.5. Invalid ACT — Capability Escalation</name>
|
||
|
||
<figure><artwork><![CDATA[
|
||
[TODO: demonstrate rejection when delegated cap contains action
|
||
not present in parent ACT]
|
||
]]></artwork></figure>
|
||
|
||
</section>
|
||
<section numbered="false" anchor="b6-invalid-act-execact-mismatch"><name>B.6. Invalid ACT — exec_act Mismatch</name>
|
||
|
||
<figure><artwork><![CDATA[
|
||
[TODO: demonstrate rejection when exec_act does not match any
|
||
cap.action in the Phase 1 claims]
|
||
]]></artwork></figure>
|
||
|
||
</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+2963IbR5Yu+j+fIg8dOwzIKIikRMmmpqc3BFISbV3YItWa
|
||
nh6HmKhKAGkWqtCVBVIwzYn9EPsB9rPsR9lPcmJd8lYAKdkz58SJONM/2iJZ
|
||
lZXXlevyrW9lWSZa05b6UO6MZrpq5biuWv25lef1pa5kbzQ+7+8INZk0+gqe
|
||
GZ/viFy1elY360Np20IUdV6phT6URaOmbVbpqtILVVWZyttsd0/Y1WRhrDV1
|
||
1a6X+lCeHJ+/ENVqMdHNoShUqw/F1aF8JFSj1aHcOTse74hLvb6um+JQSJlJ
|
||
hf1Sq3ZeN+ZX1Zq6wt/rzzpfwU9S5Xm9qlo1MaVp1/jHHz+e43+PRi/xv4Uu
|
||
9YzeFdQUNi6klHK6KksawnjeGNsaVcm3bhj4RN3MVMXfPpQnVaGXuiqgW++1
|
||
1arJ57rBB/VCmfJQGt1O/7ufiWGhhajqZqFac6Xhu+9fjJ8e7B2Efz4N//w+
|
||
/PMH/uf3u4/cAz/s7e26fx482T8UwlTTbtO7u/7NJz88gn+eZEfDsDLXZmF1
|
||
pvP2EDvtNsCxn9BkE1g5rRt5ZGzbmMmq1YXEnWJy+bFuLqdlfW13qB3VzHR7
|
||
KOdtu7SHDx8WqlVto/JL3QxhRoZ1M3tY1PnD7k7x/XmI7VjdGG1hXNQ/KU+q
|
||
VjeVbrMjeHNzq/kGst19fAX3ldzf3X+CP4YVh/9lX1zxb/gL0OvM5qZtM1hk
|
||
0+q8XTVaGivzVdPoqi3X0lRy9OH81ePvZe/9i7E8LkxbN9jIP1Z6pftStfJK
|
||
N3ACZLa/P5TntZzovF5oWCG5WtaVXK4mpclxfw3le60K3Vhsws7rVVnIldWy
|
||
ndMLdHZkXeVaKmvNrNLFkNf4jg67LVDDRGRtoyqrcvhY1uIKZ9O6yfCc2XRL
|
||
nIdH483gNsDoRJ6tbasXf2wHfEV3ft+O+IoGs90nv2+HvCh1C+d7IF+6WVZq
|
||
yZ9aNvXUlDqdNBKko1hgyVN6UPZGo9M+zuE7eEDuD3f/0NRtdOH3TdTG6yCp
|
||
02lxR+mes9Osfh3IkZuVuS7NZ9Vk82JJc23yLIjddIpe0bPyyP8dZqit87qU
|
||
vVdHPEVum4Wn/tBc3d+x3zdx97eV7e5+zeaqm9mh5CngydML0xRq5s6uocYz
|
||
f8d1dpg8G5+cn/tdhZN1QvMlgxh/r/O6Kf7Y2fxSh37ftH2ptc2Jy3Yff2H7
|
||
HVObQrp98uPH8y0H0eSgDBzKkfzx7N1b+VFPWLeJJ493mLvb0sO7ff5U89lc
|
||
4aSpiX24f7D7w3Dv0cEPT9NxHED3Tk6zk+fjbudOTg/5azhnLGX9Mbg27Tz+
|
||
S/a8XlVF52r+qq492X003H/89OnBxhQ/+sIUnzbqUtn5QJ7BIT+D2ax0iZ1O
|
||
B5P+SY7kC9BJyvh8j+fKVHKsynxVruga+atuzNSoSan/8LQ/2X083N1/+uTp
|
||
794+p6o1pZDyzfg0Ozs9HqcDelMXuvST7RflbKlzM+WbensHF/BmTi8u+b2h
|
||
qR/a+NWHsDWyvb1sv7Mo4ZfvTo/fjk6y0cvjt+dn2dnRT2kH3y115Y68lWdH
|
||
P23vTb3UlTLDmWnnqwl0g37hLsPlup27s0x9mKrS6rulFn1WSPl69Pbly/ej
|
||
01dpt16ravayUcu5PKrz1UJX7T1TVapqlsO2yJIuwq9n0Mbv6Bd8F3cYnLf9
|
||
0ZYVxZnap33WG+2P+n5Vt3eO+5PXi4dqXy2b+hdQUEf7o6/v1Mu6npXw9/H7
|
||
44+jk7Q/40Zfj06+ZpqKOrfDvNHXymB3vr4D9A2Ykg/n714ev+3MyKqtX+rq
|
||
a7qwMHlT23raRsukVm09079n87xxrQgpPz4aZ0cnR2mPjnSuq7ZRpflVF/IE
|
||
LCwzNbqxsnd0cmT78mrvLn3p+vp6eP0IBcP5+4eFKbK8bvTD9HTtZ7tPvyAW
|
||
zpZ1U60H8g1IvKOTo+yn4791dOK5loUpDi/1Wr7R7bwu5NXu8Okd3XqUZ3k+
|
||
i6YNurbA17JLve50cO8LvXtdV7NSrwfyyHXv4/HztHvQtWs9cV37Col1bx+v
|
||
9aQ7iV+awVbrUg/kO+ziu/ejzhqbmWlVCZKkwU6pEqxoUxoNFs0ob2UP3uoP
|
||
5Hs9W5V0e/SOP/Tx4w/3Dw4ebx+HXjVZqT8P9aqpl2qoVw91aR42evbQv/iw
|
||
/uVrBoO79Ria0aqSp6opjYITIqQ8/jA66Yzo+IMcNbBRc6NKvLLL0szcaLYO
|
||
4/HDvSff//AHhkEvbgxj+2V3zzBOjsdP9h/tPu7cerowuSploa9MriUc1WvV
|
||
aPl//sf/lGfuh9JMtczXeanlsqlzba22A2hQUov7u7tPvhu9Odo73N/dO7j7
|
||
tBqdD/N5urn2Du4eyMnxWIgsy6SaWFBcWyHO58bKgsWXLPTUVNqioXynM2sg
|
||
lbS6nGZwRStT6UL8+PE8myirC0meFNnOVStztQTTmZqD3S1NdVXTOZJ8v8t6
|
||
KlUFDqW6qhf1yoIWTv4qmDLTWmiG/FIGZimvK+i7qVo7iH1Sy6a+0pWqcj2Q
|
||
NToLZvNWNvofK9NoGJwdyFbZS7nQrQLNfSBVVYB3Sy5ra7BP/+d//E8Bv1xV
|
||
IDNt6jHDx+/ymIELQ0lrQLYItJhxkXGNh3JUydH4XE70zFRWKouPgtOh84WF
|
||
qmAZ4UsCTXDslpWmamupZKsWS91k+sqg4yz0pUErhfwZMNc4fyKvF8tSt9ri
|
||
LMLYB1Itwe1mqpnMm/WyrVFJMLmcKzvXFhbDVMtVa7EL9ap1/5alqS7htbaW
|
||
y0YXGjZt3WCrVl4ZJZUsTKNzMAAUDNvkEhsXvaPRy/4QJ4BXw8qq7hj3Z7q5
|
||
AgdBVcvrurksa1VIHCV4I001bZRtmxV6YmjdqlriDC1Vo6t8DWYUHjhQiifK
|
||
mlzWTjoO5Xmzsq0wVk7quoXds1zqAnu9bHRm56rRhbzUaxqqsXK1nDWq0KhX
|
||
t7U8/elE1o340t1Kg4TzpHl5p3Uj4MK2Wez/VCXv8KkuuI+wfxoScjCBuAf9
|
||
z0JXV6apK9zFUpXmUvtPwXLPdKUbVWbLVbOsLS+/O2Bi2ZiFAd/mM3z448mb
|
||
s2N5h6NS9o7H531xc3OHt/P2Fr4Ju3dSwm5g14dEzZznBcbs1jBza5hN0PTq
|
||
bllow1Tcp0Ivy3qNgxySmFqYoii1EN/AldDUxSon9/NoU1rAIckbrfAIrnnx
|
||
tVQ4+zKdfYGdUQ3KE+5SNZOLVdmazLZ6iXsQ3bLyeq7BW1kV5soUK1XyjleN
|
||
FoW3eKdNvZB15WYeDmtVt3PdDOX5XFsdtQd9bLVsr2tRgNu0guvNVFYvVYPb
|
||
DU+tATmWCK9DIfaG8sGD5Ng8eHAor5UNZ14udbMwLfQJDqpuQBzTn3HqBnAf
|
||
rKpCN/IaJXQsTGHXTdbyeo57iL7Trv8sxD5+OJF3+GVooTBF9HmVtytVlmtZ
|
||
1AMyv+Eh+CiJlQHsmGKVw3Tj6yxiYAq4R2plVSkbTde9nZulbGtoYdkYJ3D+
|
||
LMTxZ5y9mUyMQitVUTTa4pTYdAbhE8bW1O5QnM+3mswdNyOdhA1f3+0t3jem
|
||
0FZ6wdSV5iBfvItSTlZtkH9KsCTZKgZx19x/UO89or5rd95Wk1UrfGfoQxti
|
||
V6ZiV/bOTk9evDh+eHZ68v64P/yDqsP13ORzt0raikndzjeWyd2kg46eIelm
|
||
ReUiuksES/BOhyd6XVe8O3ncbQ1xBDNdS2XXi4VuG5MLkNUKFRWaeIibyR3u
|
||
/Q70B5oAzVw2elrqvLW0V+HX2CORqwakySH+yt27d2o7kX4D6kejpxouMW0H
|
||
oqOhpKpP0HYk2vx0ZIOyk5fKLKyAdkncgnUJYgjGAOIpufPxnF4F/5GurnRZ
|
||
L+lqgcvSqUWwsZOLJr1gpL9g+Mi3cy2+4paR921h0JHEF24Z+cVbRnAX7V2X
|
||
zDffwHmflHohz1rV4g4UYvxVN3ZbF2otpyqH8xxpFqaagXCARg/5cyinaI+S
|
||
QOjs1LqRCrbNAkQAnjLRgsoii3qhUDPgvb7Rp0Zjn+VET+uGlL+paWwrFtpa
|
||
NcM4m/6cz1U108VQnlRyic5QVBSNlQutKiu1gV1yKERP9d116m5QWNJ61Xb0
|
||
xVTSQf9XhWnJUGmUKe0ARDgOHKTPculic1mp1roBeQRSGtanqUtZV+X6GahY
|
||
ojfpJ6MEiV4vW9y+S9W062/tXRJqQJcrzD9aQHK+mmSqKjK7rC+1dBHnfM3W
|
||
CXxbFQaOM8xbEWt32AJJBTyzuPiVbmHLwcYB7cvW5RUKPFAs13KhLmmzphol
|
||
NE16fd2ss7bODEgH3Gi0xmA3laYiE7G9rt0C5KoiiwHNrZw0X5hlPK0muLUF
|
||
njpQOFCLoX0AUqaC6zWrp9kE5AQ4W9xWwG9dzw0ZoFcGFDGhZF6ClcvKr1wq
|
||
OMxO+0VXCdl41G+/MaBFNA3mzvQhI5DO1xHqwvJlrUorRCYfPHi5h5//V93U
|
||
GyKb5wLUC5jiNx/OwGziY4QDh88KCfo/z7LFO9Oi7cBnyG8QvgmbrTaDkM5q
|
||
GHLH9slMx7tHdqw47NKGPbiBm3A91p+XeMMV7v6wcH/E08Om1BV5E5IDlXWu
|
||
65laWtfHR9jHU60b2ExLrZvoXoBOHnVuCev6JGQs7v3yweWaoyqlqjusspWl
|
||
Q5XKAGwdT7g7INFNyr197G65rEJ8hdPv6qbQjalm0OGPQdmGjQyKcFlqCCxM
|
||
GlXlYJfCVE9VlZkqHGMw0DuzbWBg9KFyDbquG+S0VG2rKzZgFVizWjU0AtfV
|
||
A+zqVtmPhw0FYtB+R+NzK421Kw1aM6ygM0NkYaZ4o7cyluKht9EqTNZSVfA2
|
||
yDaTm6WqWjmvy4IPFH4B1wZa/9YyzAEOs+v3E+w3e8jqZu2kbdJV+jYfB2lX
|
||
U3C10c4jdwKbzihgNvQxcCbKmxv4z+3tQIK37gQcc+AWh26XWu7ty5sb9OzB
|
||
E7Be3p0FFz37ym5v/ZLQN2hfqaIwPNVlPePz4ffQUxzgh0gqwaBAU6PpxXAR
|
||
DdCulsu6aeXCzPiWBtMMprcrlWOx5vs0aTQJce2sC5g6OkUkzd7WVcaiDDow
|
||
rcuyvsb1aXAXliY3gGiB1uqptHm91IcwjiNQj8ncheguaP4n3POJnqsrsG1q
|
||
OMq5QZhLWc9MPhSZfK+XpUKDqbMp8U5AIVfDV1E7IHdiQScw+qht6wa0AZ7Z
|
||
aKlLXcx0g0+Tn3tNhwTkVKO9/tq1BSI1Sr4Z/Q3QNbCV3LQtNNwKxi6stCvQ
|
||
9628uWFc1e0tfh6vTfZY9OHzp+4iklVdZbA7/NdnK9WoqtUad6Nt4TotQSOA
|
||
CZQ9q+HjNzfxO/4rWiZNFcbmK8TSkfK8ZJeATN1JIHdq2J19Wvf3qT1KP+sC
|
||
ZZcQDx6MRqd324ruDHqrJ1wIKSaP1UaYLmgQTMaiRhPHn8m7hDRp7ZGFALMb
|
||
XxJgjaby20trL8mfCfhs1IhXPEltJe392CkRuKSAjwOFfQaHpI0t2zPvpIL+
|
||
K6/G11MY3TNpWnQmVR3/XmYicKAq8bTg1eHWEyfOTVVeKgtn88EDNjnG5/cZ
|
||
FncvhbjTWI5W5YsONLF1zb7OwnbTJTamC993ExbpQqaSiWuQ5ZiILXVU+tOn
|
||
0KVFffLt6WJA98Tob6AqkEFbSDhmMwt3Bj1PYDC8RFezBbl8kslC9Sy1DoJn
|
||
HteJcDe0RneA7WidXqA8DHIm3Bj3CQiQBhuyoE+DC4YhuR8tD5ePO3nNFCOD
|
||
zmN5cMbuZfTdv0YTZl94KQd+AwPagHx3en7y7u3oNeubfgsUkWMaehKc0+Jt
|
||
DYEbuE3ouwlMErE/94ElBYEltwMlnTtbTeA+aj1oUlUAg3wmG4ZJfjVEUnzz
|
||
zTew4bk3dznQlrXFK/JMX6G/IA9vLN1fnV4MYGZWpVWhF6BX1ovFqkKfh3Du
|
||
PHBylGRcS7jh0TKsp7Hrsbvn4MwKu1S55uWxq4nVBBGypl0piIxQVKIkAdPW
|
||
skXnp+/kUDiEA9ut4NtRjbFg9E6dGgkzvrLoy4kCUuG2xEM21Q1vsJsbwHFd
|
||
2Yxev70lx7xdLRbok5YTXdbXclrnKyugs6BE4BS5o49HDQ/T6ORUPpQAjYIb
|
||
1sGk6PwED+dWdBQNUluxBSHl3E5rB1mFxbqu8b61hzQLectBLIj+kUpBXrts
|
||
Xi9j3xf0/Dlcu6Z9eKRaBSpe65Gwgtzu8E6YvIFc1K25wisWVGRpV82VXqOl
|
||
sVw29WezUK0u13J/sLu7K+6AGrFlSOb+FEdW1Z0rVwP2O0dVd3jXJZ3cNezI
|
||
LWF36s95ubJobYCb48eP5w9/fAdSct7UqxmqlL2qdoNHbZPGL4Izoj/wrlNV
|
||
eRUSZjtbzpXVwQKVFCRAB0e623tvKHDYp0jEsqnrKdj94UrrEZCxj6q5YDW5
|
||
u2VldBXRlgKtFpVU8gFS9DADb41g25LdoA6mJfGYPItknPbPpBOPWgg9TnYf
|
||
aZtwrUUjBqccXe8JPk7e3CQ/04ZPH/GzSlpvKe5G0uH3LZjisW22RJOPXK9K
|
||
nr8efeck/q+8SWFnN5qmcm9397+BQaIz8pte0ZHd/W8E6fG/FTwnrC/BxISO
|
||
PddVPpdXj+UE/rFQzeVQnrTpnhSkOKbX7j9W2tJhI5kGFhN4rMu1c7kvG1OB
|
||
fVn6vQNrKmcGRo2LiacLxQA7wr0da8CwBM0kXMcoTdsGQQfpvDvPB4WdU9Vd
|
||
CbKFMxe14bWROS/FgLQTHoWuchA4QUcz1ZVqjGKzFK6OjKyBpoDTt2GmwE0G
|
||
WSADyf86GAj41/e7j/b7UpVwAa67GpUzYlDnzXAV4VRnCrAbwrYqv6QtGYFj
|
||
Qfh6CC2rmdFfwdlxhXsRAvgUnvdaIOoUdaWza7XGQHxysYHN39SLZQse1Zmx
|
||
raZrpC7tAMEKeV1NzWzVRHuSz2Z0spW1mm9NComKIKAt7jGOJecl3AktRdsy
|
||
1bQyYDsoWshBWDQheYjhQyRDaePwFa9aUFxVUSQCTmwTcLBrg5DbFBoeIIFW
|
||
PcudrqhjMAS0RYgNtx2T6ZAKE5vAKsLPNI1aZ1eqBHfOBSAcLiicIhuFERTy
|
||
qIKENDloYXR3C+dBevCALaR7sj0sB+2+IsXCXeCgOYAGKPTnVleFt8M2v4Ii
|
||
TFXyQuUtdsr1v6cqgd42XSQzAAPG60Be8DJ+ytvP7q28rq702vkrqtbttDRa
|
||
DF67DHLSJIgqWHGKac9Wxs69swM6eqUFXk0RzmfLBqTIGQIpGwzW4YWMQlLQ
|
||
yPG+IOkEYSd4LJVSdGe19bIu69kab7uOUAhX7+H9ywVOI7taaKEqnvdthjeB
|
||
NSBi7tTBsARemonkPkzscud7UtVajs5ca7w/eUcK2pFDOZKFbpWB69gNG11D
|
||
PgprbAgngutZ3Nw4PxGEUcGSI0Fhb29x234xjYQ37f1ZG7RfXx2dunC8tuK4
|
||
2D842PshcgqjFo+S+Pun3x9kuarqCuKQeBVBasEAoWBByXAz2g18ugub/DgT
|
||
g4gmUm3q6RSDKXSP55FQukexA5XOWEHXDXrsvSrXU6WZoQ/NxTblpKnBbCLL
|
||
heK/Oq8tZnH1E3nRqGvpR+lHWODFGAsZoYqFYXWMty7YAXFTHcETnJLOoP66
|
||
RBZezS8lk2zIn6BM0deccwJhG6Be4PciS4K+J3ujk/d9sVRrcHzQ2fSuBSvH
|
||
786OP52ZWbVHmh4DnGJjXNxtjDupMTezebneKjwOBTk78FKKAArbLh/yebJH
|
||
H7YSnJfVgi0QkgiAO1hVrVnoAbZDnducbkF2e/xJngMX/LErDuTBeoGTJWt1
|
||
swh+x6E48cOhextvUvq7PMW+71MQoq2pH6J3z2Hvy7NX7z68PpLuDwTUOHnv
|
||
OiZiCTlFtIW7vmkw7P4K+xmPC5wMsOL8orFnhdymozgUQVHTGB6H13AXvebh
|
||
BG4rk7r09VjMofyIkU0PUxMJRuhe3AHv6xg643B0bLL6tgA+4VySwcEH8zFr
|
||
6tXyW/sVSMbkWohvAodo8YHMUlXsxxDOiWEcANFGbjLpIQ9h52NACBVw71gt
|
||
18L5FVllLFVDbc3rawp7+PNkUZmKpRH8DZClFHqGv3oJGFR7RqTxbWLZe3SH
|
||
rd57Mz7ty/O6LrMPVssXEA+kGMsdL9zcuLSj29vI1ssBBN9mZPoL1D8AokHA
|
||
NhBUr1+/kfPatqSAXELUhgMyqFOjnzxAugQI7ez96RgslNIOIdcpSjJyCqn1
|
||
QK892hMoruqmJbcRbl68M1lJhwvHo7SqOsRL8G2QkKh7gbEQ1KTOEYi0MfAs
|
||
TCn6w+C6DbAwHUtYdIQuqWa2Ym8w7JKlwlA1bIRrAlfZVdkitrDR7aoh51/3
|
||
FjUWItNwiikOZgETqBF4ANMEsxx7HwHwuFQthINwrnFKwW8CAbByGmOjBmAy
|
||
sMBCiSwVy7w97AX7O4IIQgkbYR/rkgBbPT2cDQckaDyYai3C3PUHDvwBBwBC
|
||
ZeBtozMBBxGMkYVuNSQUXOkynnXhAq0luw7B0vGrRUoqzIN1UfQlWSfaXDm4
|
||
BHiHtW0H6Ie+UqXBUaFkjkapqoLfZmiZGzGMM8QtBm7GAnQ8QNQw4sm3xmQd
|
||
cODi7NUo2z94EiHAUT3SjUNaIXIz2jCKMXVwMkSj7bKuLF2HMLoMRDuNnTYR
|
||
9DW6rmgCTbtCJ0glVuB/mxHSmi03uui8oKXVhK0I+0UXrPzxX0XaMbdb4/ep
|
||
H4NU/MFA34xPv7WJYcGgRhAbLoAcY9YXdRGukbbG1fVH/ZlbN8HLMAm6Dvu6
|
||
L0bj84xX9QL7i78hXelCvjo/P5Vz9slHl/DNDSR9ZPSXzH/w9pZWK0Jhsozd
|
||
yGzEb71YVXRxjFWJ1yKK181nb242Eidvb6WuYI3IRnP5EvVUsGIEUnOuqqKe
|
||
Tum2iFCx2GH0B9RTj/hKIdMiQKYHUitwV9UtmnQlRjyuarxYIwfI1A0GpTZu
|
||
OAGdj6XqZGXKFjAjqXhV0SH0gG2ChYrW4Tp5MLjvIocZOqNBshTBoQbIo8ap
|
||
AsJ31jdNUhlEWORcdCkbLI/dcMBpJmifD72+FMmZTu8YyL4m4GkNLCrolPPf
|
||
F9uFaCJeUHbpjUlhu3tRo1pRT91HB3dJXb8kVoO2KIK8Te4qJz8W6rNZrMBb
|
||
ba5MqWd6Wy8ECEb9WTe5sdqJlbSfPELVtrBvwIyKxI1gOwT31xolyETllwi1
|
||
qK+hU1otZJBiHg2HYw8TWrOTOo2ge+iMc9jxGrbqUlcQeOXgBsgk55SD/VFe
|
||
+XyDZelX09JVBEYgZNuomQaNHs00d5hAj1d41dIpcfsAQ3sR5gzhs2gutVk+
|
||
N2UhAeYxQI8GGE+8dpiT1UFkJc7HyEsoLdxVFMTdapq46CELFL8bcpI2cnR6
|
||
wilCgM1yyq6Hi6PsoYsQ9vs68v3E+FES1LjfhWuZc+hok9vOLo+RsXGXhL/Z
|
||
5aSs80s4aFNT0aU38Ls07Db/Nkx6qRtBd034Ht1vIWIOWxEJE+gCYtkc0rvh
|
||
Ez7pmi1I/IsVIjx1c+PzxG9vKRhjeeeHrBKwzdaQ04QoZmoEvD+k8lboRG80
|
||
rj6cbHw78r/BcfAaGZ1Q2C9WhHfyuvIYrSg1jY4kbNkIzTzFk7dt72LyEHqD
|
||
VCmnpg1IIBzYIe1qP3gBPafdxbks6EOuJ7CJSR7ygtYNneECzWH9WaGvpK40
|
||
ylBE1XtzqZG9i9YUFxQMC2lrOGR3VYc+hLahaXbb9KIkuH6E4Ed80irn7Dgw
|
||
z+8T4zi8IMNJeY52CPzda824sy1AmnH5ICCDBox16jTpRbDz9HQKWQqRFi3u
|
||
uwASeQ7fhJiDF+ss1AQfJBCj3mRCDR5WTxV6KD+AihopnwyCc60ORHpSWDQH
|
||
bYkvSrJDSJ6TFwgOe5gVdBXJegJsAtFxizpPWUVDeRREPJ4But4ZSIoaiJfB
|
||
0XoSKqSB5BB9pVkdxpGQRKX1jLL/sCV8jBHJLV+ry3qJGXzwR9O4vYOu9wGE
|
||
Lxo9WXvsajULK/+tdb204KNoTU7uAd6c0AGIXsQegwhD2YEVCXFSMdrdokIS
|
||
f8brSNRpAgUihN8FDo0Vi5UDnWdO1i70om7Wg9QThe69jRwTRgnAooLaCi2h
|
||
/F4zxB1moG58Hl18AJpVxQHrSUhrwygSb8AYxDiQVrXGEoIxpNGJBM3KickV
|
||
YHMmGlJtQKeLBlbWM0SzI8CQZTaxUMi7+S9ESCfjvy+Dn8KRaSR+ChBJWd2A
|
||
s4Kd3+BliBwWUzzgrQsXOlSM8yBQvCdxK0QJiW0dZZ6BIDo9Qfy/zed6gf4i
|
||
MHfJukCRy6FGwZlbqimGQAJyj5NimxYtOLlqM3AXMGBo5pNEZus3StQSHccJ
|
||
ZHQUZAeQsGYRgf1JksH4nrIYFQzOOxY/dAFUiQo+8LsRfbLb5TTKXIozhMyV
|
||
OPAevGQw/tH+6NA7oVL91FR5uSruEsF0sMWFS/26kFOjy8L1H5biHMZAUq+j
|
||
guPoMAynrIj9HJHe7RUaF0uJMOVxJBp6QfNgVy7SdofGnfgr3EDolhCYuEJ4
|
||
e+hc5KqtvMQn/UluuxSEwoseMPFTABo5ucfT8J4terRJ3Swkk97WoJ6BXpVq
|
||
7Bgv9lYXGHfUNQ3Z86ixkTNqmydgA9bZdQeM9kff2uAQgHym9ITy+SN4DMwE
|
||
vUFHNWz1kHylQAMPaFjcgaSfgailvhSgPiB6CRsLzUhV2WtwJewY9tbxFCVJ
|
||
wpz/QQ+Qq+rPO96X4dZVcFvSt7Ul39idZ2rKu2+UvRSUc0xJuZEx+OcdlrDH
|
||
IOmWjbFavgtWbF3Jj3zFkYe9R3Q8A8nEO30hojfr5M0pqPeYr+Ux6EwYdHND
|
||
bEIAW64K4Uh8bm6Y4wcFNTjUOSWck1uIptHdw57toQPLd+rcAE4k34Duno5x
|
||
uT46IO6EA59UPGMxfHewLRYtzhjqplD/bnUlV5W6UqZEMQZXyYIT/9DR7cYH
|
||
kRsDioG//rZcNlslI55IY30SKDiA4Picg369h/pxlHDRF3GqRu/mpjW62bu9
|
||
7R9G149sampYuYWC/8Apcis0BlRCY6EDdFERiAx6Zl1IqZIu8Hyp10tlGjpE
|
||
ABMChAAeVbNgX8IWj4mzIp2U5gNgwUUFS6YbFwxkhTgSqJicHlGUYCoJjI9e
|
||
hCYwrO18t3yU2WvQ6FJfKfIZwVTCdAwxw8B/UzhfkhOZHNYF4YWC1jmI6w0f
|
||
rM9kEZgS6u8+uuLiHHavAdLdSkqVYfAZ4pfI6HKaUqJf1dM0WwhHGBKGtqUL
|
||
baYEyfsSukUnodvnNIbUKAzURjExXPBNtwXfQ2/fnaPzYjQ+/9ZSxrmHS3GG
|
||
CcXSAJwQbxFyONMCwILV1wGh5MbkNVXYn1k9nfZFQvXhbfhn0OeFqcAnNrjL
|
||
nYdZTpiwTslhgJJWpb98LUchutw03Zi6d12CpeSNp8CEgd9iydzNfPFpFkJ8
|
||
jBMJ0qXayCtw6kcne0KkieH3hWbxbupE+UF8QzJADA/3rlQ6AceI8KZF8gnj
|
||
FMsJ6QA+PRyC8NZlx+Zzltghkuu0hUFAPqBkY1zjwOM66W8uv5Rx5tSLTSxs
|
||
pB2HT7OPR9ntlyw/xLQeMafHVrfrYAu1h8PIJVxDtIES5Z191cRCVG3yDkFo
|
||
SnTFD1qdC/MZHCvJ9YWMDxxM34yUWAN3rqp0vbLl+hAP+8VHt24nfFVecJiE
|
||
X0sSc8bnz0iXjkMrWx4fjc+HzJ+p2eZHV48z2AGhSHndbT53SiasIzqPGCfn
|
||
0566Ge4idhA4JxqrsccoaHjCcPsP5VvKwfcoFDylnADUoBSpbGTQYKjkGVnR
|
||
QVkMWDjhGL68y9Q73g1kMWTUpRxPKrkOrtDapTu2YqgoEGRhDiG5gNDKBTvy
|
||
GjfyDkijnQH9F8Qo/Pv98V8+nLw/PoJ/n70avX7t/yH4CVr08K/w5vjdmzfH
|
||
b4/oZRDLya/EzpvR33bIDtxxiTY7XhPxGDgCAMKmMqQbanRjQUjN5o2ZkNn7
|
||
fHz6v//XHiSn/l/vX4z39/YgMZF++H7vKWaqzrWj2IBLm36EGUeImkJWDYUO
|
||
9CXQ8VkMM9s53AIgGAGb9XeYmZ8P5T9N8uXe43/mX8CAk1+6OUt+iXO2+ZuN
|
||
l2kSt/xqy2f8bCa/78x02t/R35Kf3bxHv/ynPyPiLtv7/s//LDwuGiHQVQz4
|
||
9Fx4rO6ipGGBap3uRFerIHeSDfgKTC9xzk/bcQa4pzfzu4DQjG9mB23HHiby
|
||
ja9P7jHqupXT/yJTm4ATlYuMdOQyMB79PmYl7EkXobetE/t3diLwLRm8ksDF
|
||
8HXkbo55iYC9FAKCqJPdyvCGXT1yjvIR87uRjw753bDbrI4HLcC7ZZxyHOW9
|
||
hIATKVfkfYftEXjkKGEH4XmWcPlD+cHqQkwoPNTWbFFsYY0C/by91rpixi60
|
||
K5y2RePp5IPQGO7lyHExMBfjgN2q0O/PrsumrtvoguVEIAx01w1xc7gdDIYB
|
||
qnKE16k0wa7Yn0Ub28dGbSdLTWOTBlicwDeD0eIHD5DnDk0wGgupOfUUZfZC
|
||
VWpGnqqOsrZCUo9aaAsmgbEEcw3qNCNzErcQ3msN6t0Ixu8m2PfIEBwE7pO+
|
||
S7qnP0H+BVwvJ0dW0G8e9SmPl9eIhsCe94bzrZ2UcJerSw+jL19cm+JC4M08
|
||
QKceTS0Z6pRSr0pgd8Q2YTPglQcDe+1woELw8ZujZbQFKUp65SafB/AGEuEH
|
||
sVrha/YZ50fxdQue04l1eyhCGSJ3E8C7QahUAK2jtB38tvIZ+c7PCUZ5pCzI
|
||
Bw+cSbgpUaSZhmvMTNlbBrjjC+jAJ5W3F5gvTm0DzDzyrXq3F9NwyeQlET69
|
||
J+8Qq4maBfefHyWZlPi2Cy9B7BeWLQZwy2ZVapaj2ECjKfjD8GuCXvkBBMDN
|
||
dVNDfBg/4LCaPvVWTjRyNVFkkdNbndzvkr04Pxhotf5q8IeCaf14N3ZdrLKH
|
||
/vL5agG5GPh5iBq2IRcRVxgJXiPYCLP3qdSVRlAXWh9HOwYEE7AnvSeJtcSE
|
||
PMSbYPGHhvxmTDQGYrxCG4eCDNbWucHRRZcavPgKBnQH2SpONyCzge8I/Iv+
|
||
+qUPRpD+yPrpXc/rGG7jBoGKsXuH6CJGG1FdypDlwAajiYeks8Yud/BNkq9o
|
||
st4yS8h1g0oDCF/Qq5Fr5bwzcewUD7ZEyNwwLTlVJlo1uvEeASCX9YARlxZl
|
||
EnQRgYVyjXsx6jPdi3aOcRGU9vIOXwaIS/15aWiHi96F/ry8wK2G8DVHDbV3
|
||
AK4GwuBNAQLhLjLZuzCqvegTpnvV1gsiJMX0gLbOOsCDIdJp6waFI3hZfEb9
|
||
ismABe76jDwV0JTX6OjaDwncC7Umogjw9y8WujCY4hufyv3DDekmxIctwMh4
|
||
TpH3dot/g3wpHawkaxUBKUm8m6PCB1si6UcmIFsV/tNkc0VSZX8o3zHNSElx
|
||
2momL0y1/ASKGeIAH9aNvKhXLf8mxWQCFxkcaIphdRU42YtUdzx1wbkUG979
|
||
oXiUDiSKRnsEAzOYJdpfEuvuUTmwhIapPxSPfdM0P61lfCOElVeW58oOxQEU
|
||
Z8qc2pPQJZJMQ5njdPbkCApyaPqXUewadGkfwlny5gApU4HeBNOOEDBULyZm
|
||
k3b5u417eOCSitKNI1zELNWvvdgFq7PmLCF37I0XFZRVksYnTRvtFEq4oavE
|
||
RiSY4OFq9HJVoBIqEpgsh2XwszvEBeuDM+EU/HmHrGZkYwXKVgP3+p93BLJP
|
||
YOiLpGyYNIaK4QwdxtPeICERu4OdkIrfYxDHVunauzDWXvTpEqPgWnRf1Y2Z
|
||
AQQrTJ51/cDLgJRpdO4UuhxynqOPSzP9JsKpgIQGuAIvrJm5YCqnuGIX/FJu
|
||
bpP4tnBAMBM/2Gjk84L+481WFbGNwKqHEyG4q4dIZoLGQSr/koGAY36xbNeD
|
||
6N5LeshUOmkeR5igYDAO5dE24pT4TeG6TK7Cu1YgxGpVMjDC4XOyLvAfpEAc
|
||
N3raq/7sbgOEBx9gF+URgzsAToY/Z/QzIiFBHaTrxrLShCAg8Cc7jBupgXxf
|
||
QVg5xmw60QOuBI2zZA3xDQBQz2eGIahOvlHgBtRC/Pu//7uQ8u8ndGLccY02
|
||
zc/Muo//+y35ARezR0v7CQNj0V+v8Ifvso3/fSfoZflm9PZodH4ctfclfZWf
|
||
6q2qoPTQr8YhD481FRLAcG4jRce1kPyy78Z1Z2e3j/481qAS10/6HGaLu4sW
|
||
HBt0Vw6kuyMRylqkL7GM4lxo6u4n/BTM9O+baLhT3x/Frd+jgrg5TmYYf3UW
|
||
72iHUuJkG9DJ/E79T53lnmM167t8QZciuDWP8vfNzOjt+NW798dH4XP+NH8X
|
||
ol1dhqa7m4XTxDY4xYCw7lXrzXC0bjt1x4hL7gBdtnEqoX/szIlM4R49uL1l
|
||
1f7Hj2dyzAQ2Z5zm4tKEy5LUbTQyISb448czsfVhjDxWdkUqrIeyRQkf3u8A
|
||
aR2CAxCYz03yBdOLX+GvGT42Pqdf8rPYCTa6D1HsyF9sXYkbIeWOKmc7UDjl
|
||
bP/gyQ5QXe606yX8RuXtd79ct/S7S1Pg71B9V1AtJ+OyZTvilqb+wQNVzh48
|
||
ADWSnND9Qyb/oCIz4fZR5Qy8WvPFhvUhEvJF7JNfo+9vb4fyuDg6G8keR+b7
|
||
zBy3++gpFhQQXQ0W1LeY+atYodvLLiAxookzykGjarQ1EN7P6SFT6AwUgkqX
|
||
BCK9tEN55ti+wyis7L2Cng7Eq7NH3z8eyFdnB3v7fek89M6KIXcPTjgtX/LE
|
||
TlVXegcdV+162ZlHR/jpFwWt2ECRQJuNUmEgoANMSgjkIofrpSk6DY6q2OD1
|
||
hHismYGWDKARcr2JeAY7eAyLaW9EWQYm/FL9Y6Uxxxw1tUZrrP7huINDq/vJ
|
||
uvROfzqJWoK+/MvwYPcHkWuq5kOhtNViAhHnNjTzKG3m6OQobUYAKyd4HqeN
|
||
Ipo5TuS74LJRh78+eXM5HA6/gS29d0Gew88HOcyXC1H0D7d3exA6KqOOEpeH
|
||
UygYrlfQOUfFLvFIufh+NEtQcxlXF4v8Ugz0wYOCFnFLpx5tdgoTMmDspI6J
|
||
VHnudo2MPVuX7msgVT6eyzHaMF2NAKU0xfTPYs4cehq6aqzdIgiiDZcQrrm+
|
||
RcbOUJDwZuuQYCnokwa8z+HmVmMvMfGQ0NY5WxGw++itdxQPiCAd5iXxFNvV
|
||
5Hf0N/WzqLwdCi/mPSMEu3JzHwSFiwUNBvyiWnVPJH4RKFIKyn03S4DY9aAY
|
||
DLbuYJ+4mhs9SzxKvQu7moBt9JGTaGP9N7AvgWMOm1alreP2+UkP6IQPcWMO
|
||
5i58D8mlxA7TgZdUiplhYpctGZoNg8MFM8bSKx7wSxkNpkGzPXbKYagUwy8X
|
||
alXQNBrVdqbxxPmfwIlEl/nb1UI3Jj8CGRJd+NiA/twVtcfe6cXwrnscZG0t
|
||
7veGoQ+MSXKdCyz4vKADv7SmK5rlhw8nR9RTqCsO+kZl/rEC24jng6h1QcpB
|
||
7AizeuMYXwAqt55FAcNdjnqh44xBCiasXxU5bNJUFOaNoVMP+kUqEsLRv96Q
|
||
UjyetOvBlIIzxPgX4CTArgFvYTWzvOf83kI6BOtDOOTPrArKtLby4pfWXAia
|
||
qwpLt9TJl+huVfZy8y7kHJCuBy51/m2oTvDLnUN5gzrpDjuKQU1ygOZPS9XC
|
||
GflU1FBDAVUpKXcAl/3JanQXXpl2Da80mohZdOGe4kjApwn+3Xn7D/PSIGtG
|
||
BlQvVba7555Hb622n1S7cyj3nj7d333y+OkB1PK9dSpaJi+4lxedLcditDMB
|
||
Xh5hvABK1W0/C8RaxBm5kFmNBHyrEpBVuJXAs68zIV0diqpumXCQbuOdvF4M
|
||
9WcFzQ/97PGs9cPViUz7lMdC/CO2RQMkn+scc2XZV9QBmoOb/6I76xfJLn1X
|
||
oSG/Q8FKgI04fm1SgJEcjfHQ8NdovcARmXzOBsWOfXJATe5SOhEvjjSpAJ60
|
||
GgruKeA2uNIOXA0gVM85BH0PeyHt9XY1bk7hlIaRxkBJTZQCznWenIo4b8rq
|
||
VVFXa0RZeDZs9J3mW5hgsGth23W6lshdEofunGtnqUfuuapG9hoybQiEEPDq
|
||
9RQ/REI/V12ZPeLLBl0xAbVGp5oj5Bz8WqP31YE4Ei2kG0BxYTOOdsWEDQ6f
|
||
gWlNFHEoamnrDRGRK7Cl/o4n9Ibt4x36Np16VQydkCBRzceZtpz7oJcyJGn4
|
||
BVN8QtEHLTEt7ieY2E8Qn/XtSLmzUJ+5dWhpL/oLHop0w31aqM8dicTP3+J/
|
||
bwd3jea6Ma0e0qnF7y0WGtYX/vzlUZGDH9pBmiAaRPplIeXPTpaNaAEhhd56
|
||
C5eqlJHYHz1/+wIikECGS+simCUPCT3+RAQEFaz9g57cGe5Ev+iL8G8p/yRH
|
||
r09fjeAx+sdDeXTy8uRcPpQ72Q78/6cd2adubRcFbi9hPqkTth4PWPvtiKMZ
|
||
io+mLHJQq/0jxpI4AR5Fx9WQkBENEUUbFLQ0EIvtBOWUwZ7y3fuQFogkJOtD
|
||
COuP3v4tPkYYxbVRTGrAMpbwoxC6DwfHstbteExCO9/aJOzb0SfjxH4E6HTT
|
||
I6KWBnL09ihKaKSeC8C0xc04VdThzgv+pp+GKKnp0oPxUN3BKEicAMVAX0TZ
|
||
U52EdeBxAeDlgDkO0KtPBwcwNmTnM2/SoSzra90AJTYIRlkCPxXUm1FNA38Q
|
||
mJGflQZIhXp4/zBFU3/gyeIwx9w9s6rojwhf5lZI8702VeF0TB9Y72hm94Xd
|
||
NySZfyxoPI7R5BNSKV+p8tO0bkDcsSTAu9TO4bpkF+1wqdBK3fmZlRb/ZqOn
|
||
cPR9aXn+vVcKoNi2u7IeXmd7+492Ys0GF/Zia4cuJE2WF/qDbSqC8Fc2d9UB
|
||
4Ml28+DDck1uHPeFEDQCIF9crSOkpHcP6oMHhS47a3G0DcYwkB5J5YOcmHkB
|
||
OCqPDfNZw3FYiA4gWQhDeTKVEB+6IBYl1KaFT8ziY9Iy8gRtpqQpdINfFHrZ
|
||
zi/kn+QubrfpqkGccVopAqJKAc3YM0M93DrdFDOH6aZ8ckBk+oAWkcTWlR8A
|
||
WOnpbix0GfYh9ixcbHjdud89cto0zJu/imV88fAIcOvuxG6hufqX2fN/Pbqq
|
||
26PL1wf7B0+nyvzampdmvP+X9qfXL5eTqjp+2ar9ov4pvm5/aQ00dXCwq79/
|
||
vLub6f0fJtnjveJxpp7uPckeP37y5ODg8ePd3d3d+DVr0BMLo3/yeNWUGdNI
|
||
Zt5NCQ4iJuNQeZtB/CK9IX/uaPu0ZuRccMT50YLhn4dyl6u3eUceLn+innF1
|
||
Igc+ki4IGWFQM3nhJ54/6ZlZ/I7Y/Li/MEPlI38Ut+yNRH0GgAtjtrExVJUx
|
||
BJrqhNsxQh7ay6S2XOEHxwWZUw46wtn6skdt/3335wvnpEznANaSn8H+ZHvh
|
||
ScKiuqbcFY57Wx6DeopxZiiNRX56CxW3cQV5c17c75RKsi14Vqicd8zKrpfx
|
||
mUR3lGuGe+bJUqjaKk1sf0idAQObuoH/3PLq13aDG4SY+mEC44qyibcE1GM8
|
||
CzaLPVBt1IWYeidFVzAXji9uAu+HiLb3msajqUkwqsrS/uX4c4IF4MT3CC3g
|
||
KbAZVAKTqBocCe6x0ej024RFmjlLEsZX3zElQyEcTI2Ps6V9+U6HLtZNUvVr
|
||
c1pFBMeFWFNKZsZuODKYYLtM1nhOFsuVw0QJZBYndnC2ul3sQDFNRMd9HOKc
|
||
7DpOK14xYhUdg0URAB9dmBXkTUQwK67B5oEK5+g19PjYKDpCFRFCqhjzhRDS
|
||
ulsF6Y3zQKN3kALHsbkZedpiz0nXvcUVFT2uPgLnbDNWUB+NLZYO71ViH1AL
|
||
pNPXlSeNuqCHLkjpRNoe/HWulhdBFsa4FIelEg8egH/vnmFGwpSOPn8DuEyC
|
||
01B4hDzzT2HFeoSi8PsAhsoZlUSCFpGoKAGxSeHVkVjKYH31K4P6l9vo6ACU
|
||
PddJtheEn03vYOzhjwjp7kt2kczKeqIwRoslzTSYPfgEmjOoIZGDmQEDHW0N
|
||
NrC/p0NORc8Fc5YEzusDsV1XbsVUEuBiR1ZErtKL50wXQeA16lrUeavbOwkV
|
||
h1zvTHfBZBE+RVCFbfAzhRuDE7UZ8e/wEP/PDZRghjxSiqB3oiUCQyQOzvg1
|
||
A5PJwIQfGALHwhFu7X0nOPZThWry2B6eXjKoHHDSQ+6GGEajRDmSJeTtv3Y2
|
||
JtkVWE/JEdXF1BZJS7zpZ6iD8xUA6Xr/WKkSsr2x6dhVV1Jt8ugxJJUCJ9mz
|
||
mCUD/G7CfRh9dXg9LWsuckm9daXoiUC6WRHjhkfJv313LiAzRrswBpJh/qLZ
|
||
nELWc+cZBtoj7ibU51HyWjUV8lBDoA19PHcvhvPCejwV2I5T5KmHtD2sbanK
|
||
HQRYIF0ZBrYcoUInJs70WdNVnKBLdW2oHWS7JRJ8qOq5WLY2cBVJOBtEf5Fg
|
||
YcWWEmidRuQCy/G63eR2YtPEh2vgkzlxCTy+1Vg/YuifH3P/UIRARVBxdNMA
|
||
0S85ITaMdt00wUwCYwJdhd7t8enKcBl7H5rAqgBoCG33DLLWTU5Bb2ocYy/o
|
||
5TgbHjz/ruwp5q7jSjFFFLP1XFPOhajwEoGQQSgqydEKBtKNHcD3mJwClik/
|
||
6KdDf61BNvIdSRfQ2z8Ke/GRlw76ZUgtGmv/wwbkjl1Nuo1UL/NH9WK8Vvbx
|
||
ZO/l4rh6/Hl99mr2enX26nPzU/PhedXMf9SXn//11YtfqRG1Kryl+x9rSgaP
|
||
DEVrh/PaYpJq7JiBrYAOnR0TB592d3fxl/rzMvzyB/7l19vIEOCCN655LXYn
|
||
e/l+8SjTj6cH2ZOn3/+QqUleZHq6u7f/6PEB/Ibf+HJ8Dn0eC+d833BX/2dH
|
||
6gR6z/8/Gxf4XW5+q6a6XX8CCKK16NP7T3Px0xT9cYdj3Kmfw5xv9RntbvEZ
|
||
7Xd9RolbZYvIoXLfXTgnK54Ihh04UCmbNzE4c4tUApTbV0olWof/kkn/JZP+
|
||
Syb9/04mUSPOTfGlidgBUx279lWuaT4+bI9B49XjyV9mf5u/mX78qF5n/5h9
|
||
/mvzlxfq3afzz7YZPz6xu3/dsy8mR9fj2Yw+6KxKePn1WO2q/V8+fa4/HSx2
|
||
P3z/6vz587fP345f/8vzy9nTbJb9banNyx8XB08e7wz8sHC5+Jw+4nMalizY
|
||
CV46S8pdx2IfxDfmuDKn9aqJUIR26DjGjA3J5ZCb6G2ZZ0DLIRBRy4xojIeX
|
||
Kyoib4eOY8F73zwAjqs5sJktAkIXnHXQAUAOQG64q7vnEMKhi2AcgdWFkD3O
|
||
dPbusYtLcFcwztCBFEJ6+FRefD7IL8CGAKzrhQOOe7ZqVqpxDnYP5fO6buGE
|
||
LGXv/N2LD3ij0VS+q+QL09gWIGR9IeiFzYg00AhCX5BaICJpi61IB4VOqati
|
||
i8rVYnJVC8i+QpZ1YmVhoiM2DDAVfUA5vcTJ4lIBF5CX7ca0pIIculKNqYlR
|
||
iIbBaFkcHlMrUYadcw5yhokLw1ExysiHGio2Y5aCKjl/6OzslcR5BBrIK1MT
|
||
aJVg5LoRkJ6MVlGulxxbp04swAaaYXUkqoyJFS4iSCR9EzufALNxiuMk1Npt
|
||
b86fhtixczwg0RnEXKjuEwXqm2Yt3b2S4geinbJ3KE8bnZ0RAvwnZGh4Ex8e
|
||
DxHry5tviJ0vzPceszahUYtUHFso1yIkNFWPBK93ukzuPTowdBLuRqDLYoXV
|
||
vlsmHQpvd/FsSfoB9XgoxE/RO+j0qfN81SBTIZzluL9RCuFCVeC86VbVTMts
|
||
xmQaZBwzRhkHHrN+aqzGCckIrgp1UovKkys4X4/yxaqSMXs+4SGf5L1k7p30
|
||
ctSHcX4FlAtD514Prea+iDIz8O2hfH82onYiH4DL4TZuD2zJyEDEuzW/6iFs
|
||
Kdk4eKDrjveeJ5OdOhFDFXUHc3Wsdn69wzbeP0QGkYeMFfcbdH/g4GCeS9MS
|
||
EyenEm6g/Tk4KjA4ulixux8FoC7kOHpw5CP2vfGo39m6mFW8NdlB9pxTlcXs
|
||
0fF7FxqOOwJB8jFUZM06RKLxgfGrsB/q0RBh2KEQPdXfNgb0049HsDFFb9KX
|
||
WPY1C18mBgymyMHUz/B5+60cjyy9mvejqtR4QfgidbJHxDbhxW+tHI+YU4xI
|
||
ZUD98YxlSI8LTaD3vu/icnjjxalPoTZDnL+FFG0o71zUL5l7CuV9fb4GM/dR
|
||
ICE53tGOewQYD47koff+JEmGPznqh134aNsuTItyYBLDzc3HR+Ps6OQIUqMg
|
||
ETpIQtlNfOH9BqrAHTPEJCAiyR/ZSA25Cw7PQjNwT/oUmwvg8Dw5yn46/tvt
|
||
LVI5IDUmB7opjyhJd9nkvAw9IKwTNn2tJ67pj8fPqel083FsGKHs8ujtWebY
|
||
Kz1V7lBghlBoX4JKApBiYLP1NAAx21QgjRddnt3z2meZ4876VTd11uUeVVYD
|
||
zdlAmM5MkjjjjB7aojkc95MjecTKj/XaFEt3FDqMsqDHz89fcwAO+fk2NiOJ
|
||
CPwKVtlE09DXVdyskAod8ZTjhM9g4hu4XyOmQD4FrFof+wgyRwOpNWND+C6I
|
||
70jj5TiSp7MKFYSAQRaQA10OIPIzM40PwaNsXUK2xERT0AIQuuaztrHyT1GL
|
||
UCSG7edGELiPyudRoR0GT9MUsPZbN+4ygz5Zik0HveoePUp22cKckRLDqOLC
|
||
vocAjd5aMNi4IkAQYThKGugIi3u5yFzNdk/XjkRkA0en5hfyy1xiwkVpGeOB
|
||
hCs8FPhvNHaG7BH78ihARiz/6nmHuWg1yYiAhd8gOpWxp7hwrGeEVYP8J87Q
|
||
ce2l2UzApXIGUVWKjsPdjuo2kYQB/Tky/QUgS7yMaIpTFae4HBVkWEFhDKx1
|
||
GCCgqIwAzh9q83xrQ4rbI9cFYG5gdB30lz8efi2/k3sXSI0Sng9Qqw1OHjQO
|
||
O89QbF1K14mIYRipVEZYVT0BsbB8RsrnZPIwky3gknA2kmh95wNcA5FRM4SI
|
||
9ZFuBUhTKSVxIcC5l3/CrOveaMikLZB0P3CR5Z4vG/tpND7/hIxce58m61bb
|
||
ft81hOuDu/fi7sc9NOvD+Yvse+k0KvybY8qZ67uzvN1II76GoRBPhth7ywQS
|
||
0aaEZ1MaGjgdvmbZezhd7D0OMFw+Jj59U4bSHIh12iRGYVozOKoiOqmTdcId
|
||
WE+R6+u9XtQIykzQ4j04bUmlmvTvYHMTdRYx9TjZmRyHHmGdkVC2C3TmNCA8
|
||
SEhG1UEtDxgojYH9NAYpc22gUgN+H+eMcECQze+4oySxVcm8rC0RfhEXVfJK
|
||
54SwBrllLuF+QQh8OgmIdA10vOAViA+VHAfwjra5ojAr2owdUd/UczMxTFPp
|
||
4S/g7/HclXS9kevHOZrgMgEumGtdltllBd92uPJkGTjdOXKrXgwE/4gAfvtp
|
||
qZtP83rVQCGrnS6EfYfBoco1D9eHoPXx0ANiI5Cd/mh8o0v4JnwGdjch6/7P
|
||
k+BAYCJ5WyiAz64N1jKc28hxgoqey+iS/xSldMEPSUYX/CJyovcxAVmuKhpI
|
||
7XZsqEmc5g7YQVgXRwemuTZXXDrFIp8FCD/VEGl+h4gQLtFof6wqxnno6OBH
|
||
DdKcgIm6bnU2rZsM/sHaLVdoiBCa3TdJBkWaw18jSwe0Qe/VjODbqQjC3tNl
|
||
/NdQs4cY8GHqAogTeXfaeRZbU5hEtk8bR3sULCacBjojTG7FBSWvHCAWP8td
|
||
tgmjazKTexcAm5UKYMVR1a0I8gh63QV+ZRiuMECjykk0AtW6h/DOMrz/THEP
|
||
KJVjBjHyyefQFjGqtJeSjvKH4PJEnK3M0460XVZFp1AznhsRu432Cgz3g7uw
|
||
7c0ELMuDCFuD36dNaqwjzaT6sf5GyRp3X2Vx2gikVT/qTGSk3ngvFWO3N4Tw
|
||
4y3vMqlVqatZO6eDnyhNYJROqdg5qKkAnmEWhDi9wclQ0sFHL+WZN8ngEI6J
|
||
+Ped4xK++SatOSjIVRrQSpI1U2jKb4WtRf0QZenrGwpSNKyjGo757w5dQSuw
|
||
S8h3NoNsJGY0hRJ54Hym5QugLR8F4fM8ein/StFErFKPI7nyv7hlnYIDE3Sm
|
||
Ix6tgewapuGIP3jwwadXA61udORJ+wPqWnwirjLnWbOklL2AwyQMJjHJOuyl
|
||
9NjLffjaaZSQfvyZsn119GFILF67T7ss9U4RRxQIaWVNX88mKoNH3huPPOLQ
|
||
soDd/ODBuV4s6ybaH8ngFZWfpHLDuDgohS7o30OOY8l/klhB1f/8HSgo+eUn
|
||
e6mvP7V1qRswvC5wlmIiG/+nQ/loV1oNFTSBFmLcqbdKSPtlYxaqMeVaakAY
|
||
M4FeUlhzgEcQWTahuDtoEo9hlEzHbdo1DO+FB2jzhosYAbxiVGpVSCiEi0ZA
|
||
3RVM33JW/h2edu6hVPC2c2Og9Ql1cttGYZGekvTHZFIO5d7uYHd3l8oxgv/v
|
||
AEYQKV3jkB7eXayIeXPBBTGhwGcQmptIatlFUuNNxKo/Hbv34CY9p0MJRbKR
|
||
rBQuUY9zxmgf7lH5J/n3ny+AH9mjlOHIz9WVDhmc/r2ofCovB9AXlXICuwJ6
|
||
j/ZFVTv26kj6gJJI9R+xRAd1Ax8PBStxdalWSeI54PKqkFrZgRW6ODKFpL8S
|
||
L/G1z+7vxGm+XDzNocbj/YVjiQliAgcom2cQaxKblzBzfxPS08/7BPzXvoib
|
||
qfw8g2s/eLnIBxYk7ZWVr00FVRy6jh3rRK/NSnziVogzkFgKs0bdMJZNvawt
|
||
3GmIe0woZqL0kMhs4KJ2nLc0kNS69+O4mih1E0qLg0eOQZPOlSXcTuf7lUho
|
||
66mg2jk1KmsYUOS0aWoWtUyahNtbvmZnqG5Czgfn8bIlW0+hFhr99ceP5/75
|
||
k1P5kLyP3PRzjLAkJXxE7+T5+LzPg6eWTk4z+CW0061CGIrIhHr3PJK5Ls1n
|
||
1WTzYkkdN3kWXgPX+Qnn8NDxt6CCIwEgU6lgCSufZcnMli2x4VFcslIOY1wj
|
||
wY4/r+yA84vlWXIdzByM8ph2ZYkJPEtmWvkI4oq3F++pYzqf8qMuSyFeR0vP
|
||
KTQbZZEt3udccgADYmH0h4yZ945fjTBq+uVzd0a2/G1MCg35W+OCRHMDwnvt
|
||
M7M4extqXUPVKq/LDyK6U6gtCAHva1Vehol2BwTymSB4DeXWXc2CsAYum4uE
|
||
IQDN0ZowbnddYfix8ZzT8A+upiSRhid2dArUIOdYAcRXfo7XBwK4yXEzTJlr
|
||
V9OpyQ3W0oDUKPIYuVLdcH+5CtnTdEGFcMcnVOEG4UNF9jSuaaMa8GcvV/gf
|
||
+v5QnpYQDm4Ee+VdeedwPzinqX0m7bqCnW1+DVXn4KSuFsDkBGSqtlPGOGbf
|
||
cPfMs7i2N0tKESRZuY4qAzlSaej+QjczALeM0qmj4rliqkw7h3jTOqos3qYZ
|
||
YgTnaOtlDbUXmKj+wYMXdXPJ1R1ol+GVYJfqurLbh+KnZChHQm7rj7sA2fi6
|
||
rmNZDa/7XAKL3is6c9xDvmBS8Q2BBgQPQeDy2ljQNKI+PWMXO/fMJbdSFaca
|
||
FB8gsYZsDVPNQKoLKadq0lCsUsmpKrFkJWuBUSQWStHCNP1Ym0r2qA40F1ih
|
||
L6Fb2uXlhIs03hHIuEN3VlLZeo6+DDfvBNMAuSUTiQT5rOmsulXJvFIZV1rx
|
||
gT8cPWbDlqVa2u1qj6sjppqJaRsiGyrQLQVMQysupIVM00SCRdNxZNSiRor/
|
||
YHnRrCzpRMmoUrr/KpxO9NBJDBE20ZHiXGCaNS7qwX+kSEg0uUKy0UKjYN94
|
||
GY2KnnUKDUKIuV/gHUB9qOAR2Lla6hDIR2P0WVdCoYpNAAMZHDoQXTH5Jco3
|
||
+jTXsLdIPOID7W7SKGxILQZDAKaNODWu604maYidwDLS/eSKTjrh4AnhaEY9
|
||
qzp7CF05FtxFENss6/pyteRwwrTRdu6qq6uyn+pBVgbTwl1BfDNRoaKKit4G
|
||
BnRWH6kHtJiwy4E96dolFnHqDSWQ20CH9q1FXXAEEFC4RsTI43NIl7y5+eUa
|
||
Mkgg3zJIECoI49QiZ72iHgZpiFHSJZ+WJPcyThf2LCnoam4IIkR8ItZVF8Ga
|
||
fzBelJ7/qpva6/69KBtzEJso/WciA80x3IWcC59uskEH/UabjbqUxeoNK1ax
|
||
ZwyZr/A7b7omCcss6ZK20vPff4bnMZMjqFrPpaToSOCCOtuO03FXKsoDk3FV
|
||
+zQdmUHk0pTlCotmEgKAj1ygzRrBJtGqyeesQ/VG/VhyKHmtIYwCTzhixud9
|
||
3rzgAspUpcq1hXWiv477sdnxjBQL59wZbL9cQykCBCAh/NdZEb2j/qFjGaf/
|
||
fdehfAYaZqKL9kt+57PyoZTy3/yPV/T/wj/7nfuv4KafY8O/yXHygRF4On++
|
||
8zX4BnwrfPbKfWR7/4/S/j+H5gdyHH0leo+Yo9zWjYwfr3lwkGmLKnAUS3Fc
|
||
mufkORzKEWT7WeAXbxG4yWIlys0GEeJ2NbwEkSnhhSxi/nxir2uX7ze+4CP1
|
||
HW85Fj5/Tcj3wcvCrnUIHWLVHZRM6fgGnhS0TukCOOjHzjLGLCMe0fsp3PjY
|
||
zAu8CeFsIc4AnUziFwBcwDzQzQHWDVlLzOdP99kCMicb/BRrdkd6ssKiwHDD
|
||
xLn1ZJDwjYWMgwAaonrNkAuJ9T5RwQKlBuevqK+hs1otwrU8pEsNzpZR7FMs
|
||
9IKc4Mx0AEUF8aqO2gppoEBpkRsspQnVMkwLoKbo1iMnm6/SvKgt1e9Ag2ZJ
|
||
3z9XCyiD7BKaqRMQ9/MdUG6oc2TX1xVqhFBTieRrzpSzq+aKwjNOT/w2Kcti
|
||
kTmAOmLQ5ytkYnZO2IvKu6qLDCKXEal2Gdot8ogkOfrF+fpzABGcqdRKctG5
|
||
ma6oxmgOO4wqV7ATN64iA6Nlfz9gqOB41JVGsH3qnKZ4oNeA6KOspgSCMPDx
|
||
UEAOC7j7Ko/+zsIUay8NMtuuy8APA4fRzKqaiwxN6+by4S81GgzO2zjkshTI
|
||
cyl9aMQxInmH86GfGOpjhvuDLkXhdRJnBMGlDfMa7B6vIJe15TqMlAAQqquD
|
||
PKF4Qasu+fZL1sLV6TZ5G0FeILBArpZErbBk2yypIpJi/cYHMyStp4NECATu
|
||
l2bCdWQrLJWyqFtEPfjMhWBQDaQ32yXz7GONPlVK9tQEsZIqPHDbVWt09oDV
|
||
jYA9VDuSLeDUDU9wHoQobECcHZeNh4GhOAAK/AO5LqBT4OzbQoKdPn7zzWZ8
|
||
E/2/W6ivHNGKiuEjMN2kh1gKt5yqxt6HQFmmuFYMpbKj+6JdLymZ3KUOxoG5
|
||
C1VSWJMPpjMLvrWB1l6i9lhircxz1OfCbyKKJsbFEX09xk8gELfJko+xvXuj
|
||
sohddfFIroOMSTQetYehkZsb/EWGuxUDyAdJ7BmmKyKjeRIGjaAQMlxbVzyj
|
||
RzguCMRICMRE0Rb4WhyHcQEKT/LcH4qnoXUkf+ADv6oarWwN8GG3MeV0RWHw
|
||
OIoBn0iwWyHAIxUAdPtD8X20aiuMbhFBVHfhUr7sofgh6pq1HMR2mO4OvBhm
|
||
vawBMEDwx6HY2w2vI5ou1qbv/KrsBeIL0LuMA+J3ec09AxbjZfpDsRcgBGAP
|
||
s0wvYnogJxhBsCDOxFVG2wsbfwPA2ru5Cb/rog+kmWJHO9WTsOoI0NYMxV44
|
||
NUksHfrDMU6GjBLKiSIDHcqjDrDipOJS2ZSnA8N1YiDBmiO2FOxgb7aHoK1I
|
||
Y5obMIytFTlx5txKqioEuiB4CtGtRITQjdx522EyMfbhg8p8MjuR5tt+InR8
|
||
QbdOk8ZuJz5xCA/iPjmZpi0wwzoc6s2QdWAgofAvk5AQ6LeDGmZ6QtDYGTjs
|
||
qAcnClXFx9FRCCwd8QioxCshRBhZkwolzv4m5Ajoi93qZnTI2G4j87lLgNXn
|
||
uK1nbgtP8zEKjyKQxGWmecT1ZB1zdrHPg3MG0mJjkCEATbhy90lEvdthADaG
|
||
hDiQuLBWoS5hWpMwKRfgaf/1QqoZiDUUHCiLwIkUReqXq/ZhxCFEtCmOx2ZI
|
||
mZ9Qk6huWjyCUC2Hy+KEv8ibbyB5PKNxUXgLfn/LkcZOUhVnjoL1hs3xdCDz
|
||
G2kVqHK5Vg6xJPj4PIsKgVN1LNu56SNGxUqulmyekOAEZZfztYcA5CCE1xex
|
||
qAxkIKpM8fL4XD5US/OQ+QFw3XEQD/eGe+JVbdtDyX8jjvQoeV5EYziUev3j
|
||
fPIyN8PhEIewB18ZDl3VH3g2lBzvDpekExe1ji0O/OhAYCgGtu3XFlSDr56+
|
||
O+PRRbZdZ2zhL390fGFgm8/sx3Pg/VYX4ZULt1dK3EHdiiu4eZVHBYhA2xwP
|
||
PLjboVqmZA8+Hi/UssjlFz4qEPuU3CEx+6rLTo7kHlzcjedyprvrbV1luNv9
|
||
qbEENa3cH/yGh+TP8am0bWHqgRztj3z+KtJe2YEcvfnL6UDqNh/2B+RPCBxW
|
||
eSgcB6jCgtMcPa8iB1/pU99asdCtwqOvqytd1ktO/6Tn0cANbcPN9omVC6rA
|
||
EZUbJJsOH2l4tcITuGPtHYgVrvEi7j6JeDmCmVWW0TxReXBEFr2mMixoYk9V
|
||
rtFuiOoRuoK91I97qhqaxWLVEoo0gSyNQqUX+XUlXYnBC1VX4fUueBwuwBxP
|
||
sC92fW/2qWcai2pNg9MddkSr83kFduzacZVvVqaRoTIN6o2prU9U6kQK5/Bo
|
||
oyX45MiO9gY/CKJ3IElCXW1HxYU+Ok9qBrBP8M0UdD/WRGdMSDoEoMV4r5Fc
|
||
1FXdUjoB6vVAsmEp3QfsylwDRnqiMYovkF2UPspyGaFkrzGGAe0du4hxCGJ4
|
||
P4zH5yIw68TVN6VupHR4EHo0LWUQ53O9YGSq+zb0AzcSB1XgEibr2FSzgXyj
|
||
m0u0sbQO6Zjoj8Q6fzSKmSG3mDc5AVZhdDvNbG7aNgMXtwG/FSAlQekT38gz
|
||
na8aD8TyZSPkzTeW/9ItKEG5knP000T0DcpCmJr4uwsEhDWY1Bv2L/mR0HN4
|
||
UhXmyhQr50CwWJthQnK1qRcG+Q4z+Va3GNBbqnbun/EJ+WAXLkxrZt5r4fUH
|
||
13nKf+B0fmqB6d8ozrIs1ZoVwsD8QGFSE4Av6Icc12W5KqKSAZ3GQrA3uFh9
|
||
RDMj9E36kkfpdlMPFqoySxYAEZ7IBejYhYSnGRRkmnqc2JE3HR0bbSAg702c
|
||
Dwtn5Wxd5fOmrihvCixr67je0AfT4udTYxsHQsqeLyMbakDyYjFsw3I+f3LP
|
||
0dV1BomlI2shmbeuItxFR6hiFXR4VuGzukB2hi7hLPmOuIS06E4+RICiXeVI
|
||
atHnDh5PLOkbJfyA51y4CGjSG7Rw8bM+kE3luQcu0sNhYuKUxbp+A7g1ga3R
|
||
JbtjIwCp3gQ3qjiTTcReS3HuKb+nq6pQKGsZb+kVS5woC0JFmxlyWABulO6C
|
||
E0zG8IHq6EU1nbIj++PJm7NjeTw+ZzxWpasKJHWVXZuF1ZnOW6zG9YZOHByL
|
||
wzjoTBMLJkg9qUlYkBzsOtY425doTSEIQOKflSNSM2J1chv3sXEc42SD+VkN
|
||
9kvsCEFtxLTS0/w6/hDy7/NVz7eDu0YqrGXmLi2++wiT6e4XRF0kVwram1dc
|
||
hbkFLyxCm0zl9no9DYIChH4kIR48oJqtXr4TvJdyZ+AIrPAMplUE4x0qZKSG
|
||
uBxqcvPfXQ02IuIG0IM7zNemrQK8JpjeYBQHDQdDH27ysQ4bnm8ghxj7M8e4
|
||
/2CERocN6iiFwzmIyVeI9hoMMBEOnDPOPNF8z0BsBnx4jvjaYTPxQFHl5T6C
|
||
vYKATqtVf6kR4SCDfSYZCT2WZG5b1nPO53pT1qRJmZ53iPkSkLpIBsSH/VYW
|
||
ulpTMQx084Sallh+c7OIZMyJENIorupL0irgQhm/fw26wrvx2Sm6ekJJSqQ0
|
||
2Gwzzmb3ja6WBe9aujzhEx7O68aMvoXHUV3Sbi3SztcSohnMyYIwsS/qlBA4
|
||
XEakI3wJbkv+dssaiPxUt4v0pbScxrJuKegAsUBIsXH8QugFrw25Q0NDQzFK
|
||
eG1xmqalmqFRgVeGK1Y8bdlfrm1rsL6giDZRODjvSSEhhQUYfLgqpRCkbkZV
|
||
86LEjcgJTyVNej4M7PM3+mLpaJpZ6+EQJlwPnVR9NjxxBAQ+o5p96D4rgWBu
|
||
TUFOq9E8KBKSavLf+68pHF6G5CzoWsaPUwbpHV8WVKysYAvv3CN+/F1Hs4HW
|
||
IX7NFcZQLX9A+NExiy0K8Upr8oyBNQErTMQWLuxUOLYfB84WLlXVuYujCtfy
|
||
5pu44DWxJ1kstFpCJD1sctmr6sSCAgeh7Mj6/gCLRHqdjudvo7C2nK0UZLlq
|
||
JDXblDYI0HVjQ4+Y127dWYEMgihPoSsMYWOJAKSPrlQGNCF/s/tzyKfEzIWq
|
||
oAN9bcpSQOwmgXV2NEHADwSKIa9eHb17PwLCkHfvR7e3ctS0Ji+13Nt9uLdH
|
||
fheEAsDWPv4gRydQYkze3Bx/GJ0kz+/HD3uvAIE9Dh88IB6dkUvGiO/6xNq9
|
||
MsTAzQGARpf6CrKMWWRRwgRFpxJ7zzhjUPYw19DZctDvyJrDpBig6+nshy9Z
|
||
bzG3tOM5gZ5su+JJ3Vmie+Ms7FDYEv6YtohxCEIBoGM+nAF7iv4iyAjP/TlR
|
||
TjFgljwQCX10VIAT3C5L02ZXRl87vQiEWadpeJBaRwCX21nO1z+H2BW6Uqhm
|
||
tnu1303NP/ZGlBAduUJuVcKKxIwncTzJwSJqIGI3HLzrVRopPMiHoG1/M1tz
|
||
C7lGrjnhHnhQtjqoUhHrzOI4B5NSLzdoJKh4DiQ4+QCjK1nZSXUH1+PWzFYy
|
||
ZkPuuQsqEcQT7paYF4O5KpgZI+SluqTkCqFOU7fX6FZOwmOILWgcmQTTXUHi
|
||
2+clZJW7b9ioSLUI0SlXDH4jYJh8AwQPYjBcMtoWQ+V9NOclYAk4jvXk8U/P
|
||
XfLmUjUWWfAzecxZby6evCXJtZvqhnnRBs/05vvQvS1Jc5QTvS1pTkhKmxvI
|
||
rRG7TI4RbZvMg8eE1w3DmNDhBsz1MSaVi3AQIUiHlYGvZnAOnVJJ0U3f0B21
|
||
RhnaQnlNaArHktRdMOAC4c0bA2OYM8CpypbdLIOUKwp9Xsa7jzYdwIJNIOIL
|
||
QssPma48GINyrUrOTrjAyiZx4dakWG5SajVS4wnjQiVbIULA5kMp9QKykFRR
|
||
ICIRVwFcI2qBvhP6mi/u+xV1eQGB2vnatNE6wwwsItNcRiRa8dz6PsEkDJ14
|
||
4R3MO9VR/3e46CKyLDLuhew+0j2PSZXh2LgAlF/EoYbdLGpJGKptH1fTqSkN
|
||
KwlZHKFEhS8NUcK/qMANVSxxoVf4Cb6MeD/yy/BHERNJdJ3JDEmqFvvy6PS9
|
||
kF6NeNzb67tbkhxj+FiJKEfyK5DkbeEeQtINyQgzVBsidy51E1F0yKbC7Jeo
|
||
AYCZD18O6stT2Wuw3CMQ3DXKrhrdjzSaQXK2/K7n9GjQYqKj2CM4ptsY1Bma
|
||
q0Zd4zDIROZWvEOfdZrMzhtNJDJThg4pa+vccIgCn9KFWKp1WauCwigno7ej
|
||
juTAK+MNlGuT5+slkOkElzU7uRx/rIt12dSvzQHUAAPH4m8SfG14nLFZOG2H
|
||
zirCtjN5tpq00d8IbIWXAsdRAuEuMHlVGiU419FJxdyhBFOkAYdqtwYg3F19
|
||
+JrzqnffPNNQ3P4u1/rtEH3jHVDn9ja2kHSgVzcO+BzKZE6HGwH3FxiT+09Y
|
||
hijsLjjsztrCzqv1Eny3kDAKuilw/J0yuanswXt97sZbYAflvqx3cDlfRYF8
|
||
XrooJgzO6GD6OsbUQ+wMTAWCQA6xrKGCGsFfmB64Z7ejDm6H93SGY7r/b/Yl
|
||
Kdz2n7F8DN5ibCae3J0fz969lR/1hPJ8+WM7riHINv+NfokLJ38DqLG7jeQd
|
||
//tNvncaqfuN+C2L/pf8cNf/Nh/6Tfwmr00RPvPROUCiO3ujL+lUYV8o1O8f
|
||
gB/SLEEu4fOFVnK1DA+MY2thg4/unlZCyV/5271VgO/tC4CF/QNb69eyQn1v
|
||
Ky5cgQ8cu/R7rne3ZZK3t4LpH+6BmDUEp90kVKujl/07WnEKAbayUcoMW8JU
|
||
gPv74vSIu1thGNOX54VW4Dc56qYvefKOL/SF8Gr8wHGU/eR//TV7VzdNeCC0
|
||
ktSe+lIrIssyYgoBJAQ6RcxnOToMVZ1QLpxBCFuJm0MKe+jiTzuY/7JzS3la
|
||
gWM+etwjsZwXH1QO535iVQXSrDyaTLXy3/5+/u7o3WGwZLtog0YvawsZMut/
|
||
+3mYdPr5oTyHyud/1TmUO9ve2W++kc+He0Ni4kmwX+DPQrIQvm1kz3Gjp8zq
|
||
/e0NA+SI++780k5JgMCcvMJekTxwNKrIoMhK1AAVMrCRkVLuTiTLz67cjXw+
|
||
3E/Hse/HMfZwpVBe8z/S6zQHx81a9s8+JSliuMcRJsDKTmWdeASP7hoB06P0
|
||
PIjrlNK0vjz7oa9EEUAdwkyvSAD90hpnHCdpjMK70l0+Y9xdjHMEByt0NJKw
|
||
R2jaH3Mltt/V0cCW9s8ycQCFgn5xPw42+xFx7ESOsd/TB/8lgsFFzHZq2fU+
|
||
iY7zKXib4m4+2eymv1feGIsh2/9IF31jEc1+iynTa4inD911FYNoXXlV188g
|
||
P8ZABe6d+GdcluJuOTIGOfIGfA2qjN/sYQ7vScIvfce2Pb+uO9TYUUEAH0SL
|
||
KwFAdA/NCU2uh6FASucYGbERM43Fbuz1x+wiV1IAC1i8reOQhQ8OO4THUJ6t
|
||
DGHbgC+80Ij3Wzi4dVlfZ41BrgSmzBgCFYrDHhxC8xvxjd7NTRJXuWU/7xik
|
||
23uPi4vmF7v+CvBSmPKmC8bubZ/iTYBJgtfbFg+IYv8iwWUxf3aMH8NJqooN
|
||
NmdOwBbBbc8edw+n9dxkiKZiFE6UC3Y9rwFADbdrAOJxbx2bBEUo3By5qCr+
|
||
F/iFQFqLDttbuoYUfAluBjf3j4byFaAQRh6FQH6hd6nrJqzKV07+16IUhoxz
|
||
c5EMehnCpHN6GeOg6BFpPIxkY28tm7qe2iFwyWdgu3cSbJBUl1xXfVdUoIOq
|
||
udRrEdUCcXl+vAxQCiHlmufpezx08JoIDkdwwXvkMvAdbVYxpYZMCMUGMGZk
|
||
G2POfYSqITuSiQgdoBeASeBawNmjdsFwAvUjO+GkIy5IRGHYY96ayMSH/Pkh
|
||
XuNq/Rxia8dUpQdkC16h2GYJAiJSj03FX4WiScBbwyR/EVGRSM2vyGghfohl
|
||
7CVxNhX6GGewaJUuROvrfJN+mANbLBwhom6+U4elL6PP9ZJwRCfH5y+oxwP5
|
||
DhINybFI2xZGCed61tSrpRVwmKYQ9HZnA7FxcFPxbPi0rkF0tSajJRWw9ceh
|
||
xfIN5Vo6fg83S4h9AEe6pYSYBPU7FP83onBIObMOAQA=
|
||
|
||
-->
|
||
|
||
</rfc>
|
||
|