c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f9357fdf88fc2a0d4079e80516294e8ce4257296
ietf-wimse-ect/draft-nennemann-wimse-execution-context-00.xml

3472 lines
149 KiB
XML
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.5) -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc ipr="trust200902" docName="draft-nennemann-wimse-execution-context-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
<front>
<title abbrev="WIMSE Execution Context">Execution Context Tokens for Distributed Agentic Workflows</title>
<author fullname="Christian Nennemann">
<organization>Independent Researcher</organization>
<address>
<email>ietf@nennemann.de</email>
</address>
</author>
<date year="2026" month="February" day="24"/>
<area>Security</area>
<workgroup>WIMSE</workgroup>
<keyword>execution context</keyword> <keyword>workload identity</keyword> <keyword>agentic workflows</keyword> <keyword>audit trail</keyword> <keyword>compliance</keyword> <keyword>regulated systems</keyword>
<abstract>
<?line 85?>
<t>This document defines Execution Context Tokens (ECTs), an extension
to the Workload Identity in Multi System Environments (WIMSE)
architecture for distributed agentic workflows in regulated
environments. ECTs provide cryptographic proof of task execution
order, policy enforcement decisions, and compliance state across
agent-to-agent communication. By extending WIMSE Workload Identity
Tokens with execution context claims in JSON Web Token (JWT)
format, this specification enables regulated systems to maintain
structured audit trails that support compliance verification.
ECTs use a directed acyclic graph (DAG) structure to represent task
dependencies, record policy evaluation outcomes at each decision
point, and integrate with WIMSE Workload Identity Tokens (WIT) and
Workload Proof Tokens (WPT) using the same signing model and
cryptographic primitives. A new HTTP header field,
Execution-Context, is defined for transporting ECTs alongside
existing WIMSE headers. ECTs are a technical building block that
supports, but does not by itself constitute, compliance with
regulatory frameworks.</t>
</abstract>
</front>
<middle>
<?line 106?>
<section anchor="introduction"><name>Introduction</name>
<section anchor="motivation"><name>Motivation</name>
<t>The Workload Identity in Multi System Environments (WIMSE)
framework <xref target="I-D.ietf-wimse-arch"/> provides robust workload
authentication through Workload Identity Tokens (WIT) and Workload
Proof Tokens (WPT). The WIMSE service-to-service protocol
<xref target="I-D.ietf-wimse-s2s-protocol"/> defines how workloads authenticate
each other across call chains using the Workload-Identity and
Workload-Proof-Token HTTP headers.</t>
<t>However, workload identity alone does not address execution
accountability. Knowing who performed an action does not prove
what was done, what policy was applied, or whether compliance
requirements were satisfied at each decision point.</t>
<t>Regulated environments increasingly deploy autonomous agents that
coordinate across organizational boundaries. Multiple regulatory
frameworks motivate the need for structured execution records:</t>
<t><list style="symbols">
<t>The EU Artificial Intelligence Act <xref target="EU-AI-ACT"/> Article 12
requires high-risk AI systems to be designed with capabilities
enabling automatic recording of events ("logs") while the
system is operating.</t>
<t>The U.S. FDA 21 CFR Part 11 <xref target="FDA-21CFR11"/> requires
computer-generated, timestamped audit trails that independently
record the date, time, operator identity, and actions taken
(Section 11.10(e)).</t>
<t>The Markets in Financial Instruments Directive (MiFID II)
<xref target="MIFID-II"/> requires firms to maintain records of transactions
and orders that are sufficient to enable supervisory authorities
to monitor compliance.</t>
<t>The Digital Operational Resilience Act (DORA) <xref target="DORA"/> Article 12
requires financial entities to have logging policies that record
ICT activities and anomalies.</t>
</list></t>
<t>This document defines an extension to the WIMSE architecture that
addresses the gap between workload identity and execution
accountability. WIMSE authenticates agents; this extension records
what they did, in what order, and what policy was evaluated.</t>
<t>As identified in <xref target="I-D.ni-wimse-ai-agent-identity"/>, call context
in agentic workflows needs to be visible and preserved. ECTs
provide a mechanism to address this requirement with cryptographic
assurances.</t>
</section>
<section anchor="problem-statement"><name>Problem Statement</name>
<t>Three core gaps exist in current approaches to regulated agentic
systems:</t>
<t><list style="numbers" type="1">
<t>WIMSE authenticates agents but does not record what they
actually did. A WIT proves "Agent A is authorized" but not
"Agent A executed Task X, under Policy Y, producing Output Z."</t>
<t>No standard mechanism exists to record policy evaluation
outcomes at each decision point in a multi-agent workflow.</t>
<t>No mechanism exists to cryptographically link compensation and
rollback decisions to original actions.</t>
</list></t>
<t>Existing observability tools such as distributed tracing
<xref target="OPENTELEMETRY"/> provide visibility for debugging and monitoring
but do not provide cryptographic assurances. Tracing data is not
cryptographically signed, not tamper-evident, and not designed for
regulatory audit scenarios.</t>
</section>
<section anchor="scope-and-applicability"><name>Scope and Applicability</name>
<t>This document defines:</t>
<t><list style="symbols">
<t>The Execution Context Token (ECT) format (<xref target="ect-format"/>)</t>
<t>DAG structure for task dependency ordering (<xref target="dag-validation"/>)</t>
<t>Policy checkpoint recording (<xref target="policy-claims"/>)</t>
<t>Integration with the WIMSE identity framework
(<xref target="wimse-integration"/>)</t>
<t>An HTTP header for ECT transport (<xref target="http-header"/>)</t>
<t>Operational modes including ledger-optional deployment
(<xref target="operational-modes"/>)</t>
<t>Audit ledger interface requirements (<xref target="ledger-interface"/>)</t>
</list></t>
<t>The following are out of scope and are handled by WIMSE:</t>
<t><list style="symbols">
<t>Workload authentication and identity provisioning</t>
<t>Key distribution and management</t>
<t>Trust domain establishment and management</t>
<t>Credential lifecycle management</t>
</list></t>
</section>
<section anchor="relationship-to-regulatory-compliance"><name>Relationship to Regulatory Compliance</name>
<t>ECTs are a technical mechanism that can support compliance programs
by providing structured, cryptographically signed execution
records. ECTs do not by themselves constitute compliance with any
regulatory framework referenced in this document.</t>
<t>Compliance with each referenced regulation requires organizational
controls, policies, procedures, validation, and governance measures
beyond the scope of this specification. The regulatory references
in this document are intended to motivate the design requirements,
not to claim that implementing ECTs satisfies these regulations.</t>
<t>ECTs provide evidence of claimed execution ordering and policy
evaluation. They do not independently verify that the claimed
execution actually occurred as described, that the policy
evaluation was correct, or that the agent faithfully performed the
stated action. The trustworthiness of ECT claims depends on the
trustworthiness of the signing agent and the integrity of the
broader deployment environment.</t>
</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>The following terms are used in this document:</t>
<dl>
<dt>Agent:</dt>
<dd>
<t>An autonomous workload, as defined by WIMSE
<xref target="I-D.ietf-wimse-arch"/>, that executes tasks within a workflow.</t>
</dd>
<dt>Task:</dt>
<dd>
<t>A discrete unit of agent work that consumes inputs and produces
outputs.</t>
</dd>
<dt>Directed Acyclic Graph (DAG):</dt>
<dd>
<t>A graph structure representing task dependency ordering where
edges are directed and no cycles exist.</t>
</dd>
<dt>Execution Context Token (ECT):</dt>
<dd>
<t>A JSON Web Token <xref target="RFC7519"/> defined by this specification that
records task execution details and policy evaluation outcomes.</t>
</dd>
<dt>Audit Ledger:</dt>
<dd>
<t>An append-only, immutable log of all ECTs within a workflow or
set of workflows, used for regulatory audit and compliance
verification.</t>
</dd>
<dt>Policy Checkpoint:</dt>
<dd>
<t>A point in a workflow where a policy evaluation outcome is
recorded within an ECT.</t>
</dd>
<dt>Workload Identity Token (WIT):</dt>
<dd>
<t>A WIMSE credential proving a workload's identity within a trust
domain.</t>
</dd>
<dt>Workload Proof Token (WPT):</dt>
<dd>
<t>A WIMSE proof-of-possession token used for request-level
authentication.</t>
</dd>
<dt>Trust Domain:</dt>
<dd>
<t>A WIMSE concept representing an organizational boundary with a
shared identity issuer, corresponding to a SPIFFE <xref target="SPIFFE"/>
trust domain.</t>
</dd>
<dt>Witness:</dt>
<dd>
<t>A third-party entity that observes and attests to the execution
of a task, providing additional accountability.</t>
</dd>
</dl>
</section>
<section anchor="wimse-integration"><name>WIMSE Architecture Integration</name>
<section anchor="wimse-foundation"><name>WIMSE Foundation</name>
<t>The WIMSE architecture <xref target="I-D.ietf-wimse-arch"/> defines:</t>
<t><list style="symbols">
<t>Workload Identity Tokens (WIT) that prove a workload's identity
within a trust domain ("I am Agent X in trust domain Y")</t>
<t>Workload Proof Tokens (WPT) that prove possession of the private
key associated with a WIT ("I control the key for Agent X")</t>
<t>Multi-hop authentication via the service-to-service protocol
<xref target="I-D.ietf-wimse-s2s-protocol"/></t>
</list></t>
<t>The following execution accountability needs are complementary to
the WIMSE scope and are not addressed by workload identity alone:</t>
<t><list style="symbols">
<t>Recording what agents actually do with their authenticated
identity</t>
<t>Recording policy evaluation outcomes at each hop</t>
<t>Maintaining structured execution records</t>
<t>Linking compensation or rollback actions to original tasks</t>
</list></t>
</section>
<section anchor="extension-model"><name>Extension Model</name>
<t>ECTs extend WIMSE by adding an execution accountability layer
between the identity layer and the application layer:</t>
<figure title="WIMSE Extension Architecture Layers" anchor="fig-layers"><artwork type="ascii-art"><![CDATA[
+--------------------------------------------------+
| WIMSE Layer (Identity) |
| WIT: "I am Agent X (spiffe://td/agent/x)" |
| WPT: "I prove I control the key for Agent X" |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| ECT Layer (Execution Accountability) [This Spec]|
| ECT: "Task executed, dependencies met, |
| policy evaluated, outcome recorded" |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| Ledger Layer (Immutable Record) |
| "All ECTs appended to audit ledger" |
+--------------------------------------------------+
]]></artwork></figure>
<t>This extension reuses the WIMSE signing model, extends JWT claims
using standard JWT extensibility <xref target="RFC7519"/>, and maintains WIMSE
concepts including trust domains and workload identifiers.</t>
</section>
<section anchor="integration-points"><name>Integration Points</name>
<t>An ECT integrates with the WIMSE identity framework through the
following mechanisms:</t>
<t><list style="symbols">
<t>The ECT JOSE header "kid" parameter <bcp14>MUST</bcp14> reference the public
key identifier from the agent's WIT.</t>
<t>The ECT "iss" claim <bcp14>MUST</bcp14> use the WIMSE workload identifier
format (a SPIFFE ID <xref target="SPIFFE"/>).</t>
<t>The ECT <bcp14>MUST</bcp14> be signed with the same private key used to
generate the agent's WPT.</t>
<t>The ECT signing algorithm (JOSE header "alg" parameter) <bcp14>MUST</bcp14>
match the algorithm used in the corresponding WIT.</t>
</list></t>
<t>When an agent makes an HTTP request to another agent, the three
tokens are carried in their respective HTTP header fields:</t>
<figure title="HTTP Header Stacking" anchor="fig-http-headers"><artwork type="ascii-art"><![CDATA[
HTTP Request from Agent A to Agent B:
Workload-Identity: <WIT for Agent A>
Workload-Proof-Token: <WPT proving A controls key>
Execution-Context: <ECT recording what A did>
]]></artwork></figure>
<t>The receiving agent (Agent B) verifies in order:</t>
<t><list style="numbers" type="1">
<t>WIT and WPT (WIMSE layer): Proves who Agent A is and that the
request is authentic.</t>
<t>ECT (this extension): Records what Agent A did, what policy was
evaluated, and what precedent tasks exist.</t>
<t>Ledger: Appends the verified ECT to the audit ledger.</t>
</list></t>
</section>
</section>
<section anchor="ect-format"><name>Execution Context Token Format</name>
<t>An Execution Context Token is a JSON Web Token (JWT) <xref target="RFC7519"/>
signed as a JSON Web Signature (JWS) <xref target="RFC7515"/> using the Compact
Serialization. JWS JSON Serialization <bcp14>MUST NOT</bcp14> be used for ECTs.</t>
<section anchor="jose-header"><name>JOSE Header</name>
<t>The ECT JOSE header <bcp14>MUST</bcp14> contain the following parameters:</t>
<figure title="ECT JOSE Header Example" anchor="fig-header"><sourcecode type="json"><![CDATA[
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
"kid": "agent-a-key-id-123"
}
]]></sourcecode></figure>
<dl>
<dt>alg:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. The digital signature algorithm used to sign the ECT.
<bcp14>MUST</bcp14> match the algorithm in the corresponding WIT.
Implementations <bcp14>MUST</bcp14> support ES256 <xref target="RFC7518"/>. The "alg"
value <bcp14>MUST NOT</bcp14> be "none". Symmetric algorithms (e.g., HS256,
HS384, HS512) <bcp14>MUST NOT</bcp14> be used, as ECTs require asymmetric
signatures for non-repudiation.</t>
</dd>
<dt>typ:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. <bcp14>MUST</bcp14> be set to "wimse-exec+jwt" to distinguish ECTs
from other JWT types, consistent with the WIMSE convention for
type parameter values.</t>
</dd>
<dt>kid:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. The key identifier referencing the public key from
the agent's WIT <xref target="RFC7517"/>. Used by verifiers to look up the
correct public key for signature verification.</t>
</dd>
</dl>
</section>
<section anchor="jwt-claims"><name>JWT Claims</name>
<t>The ECT payload contains both WIMSE-compatible standard JWT claims
and execution context claims defined by this specification.</t>
<section anchor="standard-jwt-claims"><name>Standard JWT Claims</name>
<t>The following standard JWT claims <xref target="RFC7519"/> <bcp14>MUST</bcp14> be present in
every ECT:</t>
<dl>
<dt>iss:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. StringOrURI. The issuer of the ECT, which <bcp14>MUST</bcp14> be
the workload's SPIFFE ID in the format
<spanx style="verb">spiffe://&lt;trust-domain&gt;/&lt;path&gt;</spanx>. This <bcp14>MUST</bcp14> match the "sub"
claim of the agent's WIT.</t>
</dd>
<dt>sub:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. StringOrURI. The subject of the ECT. When present,
<bcp14>MUST</bcp14> equal the "iss" claim. This claim is included for
compatibility with JWT libraries and frameworks that expect a
"sub" claim to be present.</t>
</dd>
<dt>aud:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. StringOrURI or array of StringOrURI. The intended
recipient(s) of the ECT. Because ECTs serve as both inter-agent
messages and audit records, the "aud" claim <bcp14>SHOULD</bcp14> contain the
identifiers of all entities that will verify the ECT. In
practice this means:
</t>
<t><list style="symbols">
<t><strong>Point-to-point delivery</strong>: when an ECT is sent from one
agent to a single next agent, "aud" contains that agent's
workload identity. The receiving agent verifies the ECT and
forwards it to the ledger on behalf of the issuer.</t>
<t><strong>Direct-to-ledger submission</strong>: when an ECT is submitted
directly to the audit ledger (e.g., after a join or at
workflow completion), "aud" contains the ledger's identity.</t>
<t><strong>Multi-audience</strong>: when an ECT must be verified by both the
next agent and the ledger independently, "aud" <bcp14>MUST</bcp14> be an
array containing both identifiers (e.g.,
["spiffe://example.com/agent/next",
"spiffe://example.com/system/ledger"]). Each verifier checks
that its own identity appears in the array.</t>
</list></t>
<t>In multi-parent (join) scenarios where a task depends on ECTs
from multiple parent agents, the joining agent creates a new ECT
with the parent task IDs in "par". The "aud" of this new ECT
is set according to the rules above based on where the ECT will
be delivered — it is independent of the "aud" values in the
parent ECTs.</t>
</dd>
<dt>iat:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. NumericDate. The time at which the ECT was issued.
The ECT records a completed action, so the "iat" value reflects
when the record was created, not when task execution began.</t>
</dd>
<dt>exp:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. NumericDate. The expiration time of the ECT.
Implementations <bcp14>SHOULD</bcp14> set this to 5 to 15 minutes after "iat"
to limit the replay window while allowing for reasonable clock
skew and processing time.</t>
</dd>
</dl>
<t>The standard JWT "nbf" (Not Before) claim is not used in ECTs
because ECTs record completed actions and are valid immediately
upon issuance.</t>
<dl>
<dt>jti:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. String. A unique identifier for the ECT in UUID
format <xref target="RFC9562"/>. Used for replay detection: receivers <bcp14>MUST</bcp14>
reject ECTs whose "jti" has already been seen within the
expiration window. The "jti" value <bcp14>MUST</bcp14> be unique across all
ECTs issued by the same agent.</t>
</dd>
</dl>
</section>
<section anchor="exec-claims"><name>Execution Context</name>
<t>The following claims are defined by this specification:</t>
<dl>
<dt>wid:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A workflow identifier that groups related
ECTs into a single workflow. When present, <bcp14>MUST</bcp14> be a UUID
<xref target="RFC9562"/>. When absent, the "tid" uniqueness requirement
applies globally across the entire ledger.</t>
</dd>
<dt>tid:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. String. A globally unique task identifier in UUID
format <xref target="RFC9562"/>. Each task <bcp14>MUST</bcp14> have a unique "tid" value.
When "wid" is present, uniqueness is scoped to the workflow;
when "wid" is absent, uniqueness <bcp14>MUST</bcp14> be enforced globally
across the ledger.</t>
</dd>
<dt>exec_act:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. String. The action or task type identifier describing
what the agent performed (e.g., "process_payment",
"validate_safety", "calculate_dosage"). Note: this claim is
intentionally named "exec_act" rather than "act" to avoid
collision with the "act" (Actor) claim registered by
<xref target="RFC8693"/>.</t>
</dd>
<dt>par:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. Array of strings. Parent task identifiers
representing DAG dependencies. Each element <bcp14>MUST</bcp14> be a valid
"tid" from a previously executed task. An empty array indicates
a root task with no dependencies. A workflow <bcp14>MAY</bcp14> contain
multiple root tasks.</t>
</dd>
</dl>
</section>
<section anchor="policy-claims"><name>Policy Evaluation</name>
<t>The following claims record policy evaluation outcomes:</t>
<dl>
<dt>pol:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. String. The identifier of the policy rule that was
evaluated for this task (e.g.,
"clinical_data_access_policy_v1").</t>
</dd>
<dt>pol_decision:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. String. The result of the policy evaluation. <bcp14>MUST</bcp14>
be one of the values registered in the ECT Policy Decision
Values registry (<xref target="pol-decision-registry"/>). Initial values
are:
</t>
<t><list style="symbols">
<t>"approved": The policy evaluation succeeded and the task
was authorized to proceed.</t>
<t>"rejected": The policy evaluation failed. A "rejected" ECT
<bcp14>MUST</bcp14> still be appended to the audit ledger for accountability.
An ECT with "pol_decision" of "rejected" <bcp14>MAY</bcp14> appear as a
parent in the "par" array of a subsequent ECT, but only for
compensation, rollback, or remediation tasks. Agents <bcp14>MUST
NOT</bcp14> proceed with normal workflow execution based on a parent
ECT whose "pol_decision" is "rejected".</t>
<t>"pending_human_review": The policy evaluation requires human
judgment before proceeding. Agents <bcp14>MUST NOT</bcp14> proceed with
dependent tasks until a subsequent ECT from a human reviewer
records an "approved" decision referencing this task as a
parent.</t>
</list></t>
</dd>
<dt>pol_enforcer:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. StringOrURI. The identity of the entity (system or
person) that evaluated the policy decision. When present,
<bcp14>SHOULD</bcp14> use SPIFFE ID format.</t>
</dd>
<dt>pol_timestamp:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. NumericDate. The time at which the policy decision
was made. When present, <bcp14>MUST</bcp14> be equal to or earlier than the
"iat" claim.</t>
</dd>
</dl>
<t>This specification intentionally defines only the recording of
policy evaluation outcomes. The mechanisms by which policies are
defined, distributed to agents, and evaluated are out of scope.
The "pol" claim is an opaque identifier referencing an external
policy; the semantics and enforcement of that policy are
determined by the deployment environment. Implementations may
use any policy engine or framework (e.g., OPA/Rego, Cedar, XACML,
or custom solutions) provided that the evaluation outcome is
faithfully recorded in the ECT claims defined above.</t>
</section>
<section anchor="data-integrity-claims"><name>Data Integrity</name>
<t>The following claims provide integrity verification for task
inputs and outputs without revealing the data itself:</t>
<dl>
<dt>inp_hash:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A cryptographic hash of the input data,
formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The
hash algorithm identifier <bcp14>MUST</bcp14> be a lowercase value from the
IANA Named Information Hash Algorithm Registry (e.g., "sha-256",
"sha-384", "sha-512"). Implementations <bcp14>MUST</bcp14> support "sha-256"
and <bcp14>SHOULD</bcp14> use "sha-256" unless a stronger algorithm is
required. Implementations <bcp14>MUST NOT</bcp14> accept hash algorithms
weaker than SHA-256 (e.g., MD5, SHA-1). The hash <bcp14>MUST</bcp14> be
computed over the raw octets of the input data.</t>
</dd>
<dt>out_hash:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A cryptographic hash of the output data,
using the same format and algorithm requirements as "inp_hash".</t>
</dd>
<dt>inp_classification:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The data sensitivity classification of the
input (e.g., "public", "confidential", "restricted").</t>
</dd>
</dl>
</section>
<section anchor="operational-claims"><name>Task Metadata</name>
<t>The following claims provide additional context about task
execution:</t>
<dl>
<dt>exec_time_ms:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Integer. The execution duration of the task in
milliseconds. <bcp14>MUST</bcp14> be a non-negative integer.</t>
</dd>
<dt>regulated_domain:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The regulatory domain applicable to this
task. Values <bcp14>MUST</bcp14> be registered in the ECT Regulated Domain
Values registry (<xref target="regulated-domain-registry"/>).</t>
</dd>
<dt>model_version:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The version identifier of the AI or ML model
used to perform the task, if applicable.</t>
</dd>
<dt>witnessed_by:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Array of StringOrURI. Identifiers of third-party
entities that the issuing agent claims observed or attested to
the execution of this task. When present, each element <bcp14>SHOULD</bcp14>
use SPIFFE ID format. Note that this claim is self-asserted by
the ECT issuer; witnesses listed here do not co-sign this ECT.
For stronger assurance, witnesses <bcp14>SHOULD</bcp14> submit independent
signed ECTs to the ledger attesting to their observation (see
<xref target="witness-attestation-model"/>). In regulated environments,
implementations <bcp14>SHOULD</bcp14> use witness attestation for critical
decision points to mitigate the risk of single-agent false
claims. See also <xref target="self-assertion-limitation"/> for the security
implications of self-asserted witness claims.</t>
</dd>
</dl>
</section>
<section anchor="compensation-claims"><name>Compensation and Rollback</name>
<dl>
<dt>compensation_required:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Boolean. Indicates whether this task is a
compensation or rollback action for a previous task.</t>
</dd>
<dt>compensation_reason:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A human-readable reason for the compensation
action. <bcp14>MUST</bcp14> be present if "compensation_required" is true.
Values <bcp14>SHOULD</bcp14> use structured identifiers (e.g.,
"policy_violation_in_parent_trade") rather than free-form text
to minimize the risk of embedding sensitive information. See
<xref target="data-minimization"/> for privacy guidance.
If "compensation_reason" is present, "compensation_required"
<bcp14>MUST</bcp14> be true.</t>
</dd>
</dl>
<t>Note: compensation ECTs reference historical parent tasks via the
"par" claim. The referenced parent ECTs may have passed their own
"exp" time; ECT expiration applies to the verification window of
the ECT itself, not to its validity as a parent reference in the
ledger.</t>
</section>
<section anchor="extension-claims"><name>Extensions</name>
<dl>
<dt>ext:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Object. An extension object for domain-specific
claims not defined by this specification. Implementations
that do not understand extension claims <bcp14>MUST</bcp14> ignore them.</t>
</dd>
</dl>
<t>To avoid key collisions between different domains, extension
key names <bcp14>MUST</bcp14> use reverse domain notation (e.g.,
"com.example.custom_field"). Implementations <bcp14>MUST NOT</bcp14> use
unqualified key names within the "ext" object. To prevent
abuse and excessive token size, the serialized JSON
representation of the "ext" object <bcp14>SHOULD NOT</bcp14> exceed 4096
bytes, and the JSON nesting depth within the "ext" object
<bcp14>SHOULD NOT</bcp14> exceed 5 levels. Implementations <bcp14>SHOULD</bcp14> reject
ECTs whose "ext" claim exceeds these limits.</t>
</section>
</section>
<section anchor="complete-ect-example"><name>Complete ECT Example</name>
<t>The following is a complete ECT payload example:</t>
<figure title="Complete ECT Payload Example" anchor="fig-full-ect"><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://example.com/agent/clinical",
"sub": "spiffe://example.com/agent/clinical",
"aud": "spiffe://example.com/agent/safety",
"iat": 1772064150,
"exp": 1772064750,
"jti": "7f3a8b2c-d1e4-4f56-9a0b-c3d4e5f6a7b8",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"tid": "550e8400-e29b-41d4-a716-446655440001",
"exec_act": "recommend_treatment",
"par": [],
"pol": "clinical_reasoning_policy_v2",
"pol_decision": "approved",
"pol_enforcer": "spiffe://example.com/policy/clinical-engine",
"pol_timestamp": 1772064145,
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"inp_classification": "confidential",
"exec_time_ms": 245,
"regulated_domain": "medtech",
"model_version": "clinical-reasoning-v4.2",
"witnessed_by": [
"spiffe://example.com/audit/observer-1"
]
}
]]></sourcecode></figure>
</section>
</section>
<section anchor="http-header"><name>HTTP Header Transport</name>
<section anchor="execution-context-header-field"><name>Execution-Context Header Field</name>
<t>This specification defines the Execution-Context HTTP header field
<xref target="RFC9110"/> for transporting ECTs between agents.</t>
<t>The header field value is the ECT in JWS Compact Serialization
format <xref target="RFC7515"/>. The value consists of three Base64url-encoded
parts separated by period (".") characters.</t>
<t>An agent sending a request to another agent includes the
Execution-Context header alongside the WIMSE Workload-Identity
and Workload-Proof-Token headers:</t>
<figure title="HTTP Request with ECT Header" anchor="fig-http-example"><artwork><![CDATA[
GET /api/safety-check HTTP/1.1
Host: safety-agent.example.com
Workload-Identity: eyJhbGci...WIT...
Workload-Proof-Token: eyJhbGci...WPT...
Execution-Context: eyJhbGci...ECT...
]]></artwork></figure>
<t>When multiple parent tasks contribute context to a single request,
multiple Execution-Context header field lines <bcp14>MAY</bcp14> be included, each
carrying a separate ECT in JWS Compact Serialization format.</t>
<t>When a receiver processes multiple Execution-Context headers, it
<bcp14>MUST</bcp14> individually verify each ECT per the procedure in
<xref target="verification"/>. If any single ECT fails verification, the
receiver <bcp14>MUST</bcp14> reject the entire request. The set of verified
parent task IDs across all received ECTs represents the complete
set of parent dependencies available for the receiving agent's
subsequent ECT.</t>
</section>
</section>
<section anchor="dag-validation"><name>DAG Validation</name>
<section anchor="overview"><name>Overview</name>
<t>ECTs form a Directed Acyclic Graph (DAG) where each task
references its parent tasks via the "par" claim. This structure
provides a cryptographically signed record of execution ordering,
enabling auditors to reconstruct the complete workflow and verify
that required predecessor tasks were recorded before dependent
tasks.</t>
<t>DAG validation can be performed against an audit ledger (when
available) or against parent ECTs received inline via
Execution-Context headers (in point-to-point mode per
<xref target="operational-modes"/>). The validation rules below use the term
"ECT store" to refer to either the ledger or the set of inline
parent ECTs available to the verifier.</t>
</section>
<section anchor="validation-rules"><name>Validation Rules</name>
<t>When receiving and verifying an ECT, implementations <bcp14>MUST</bcp14> perform
the following DAG validation steps:</t>
<t><list style="numbers" type="1">
<t>Task ID Uniqueness: The "tid" claim <bcp14>MUST</bcp14> be unique within the
applicable scope (the workflow identified by "wid", or the
entire ECT store if "wid" is absent). If a task with the same
"tid" already exists, the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Parent Existence: Every task identifier listed in the "par"
array <bcp14>MUST</bcp14> correspond to a task that is available in the ECT
store (either previously recorded in the ledger or received
inline as a verified parent ECT). If any parent task is not
found, the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Temporal Ordering: The "iat" value of every parent task <bcp14>MUST
NOT</bcp14> be greater than the "iat" value of the current task plus a
configurable clock skew tolerance (<bcp14>RECOMMENDED</bcp14>: 30 seconds).
That is, for each parent: <spanx style="verb">parent.iat &lt; child.iat +
clock_skew_tolerance</spanx>. The tolerance accounts for clock skew
between agents; it does not guarantee strict causal ordering
from timestamps alone. Causal ordering is primarily enforced
by the DAG structure (parent existence in the ECT store), not by
timestamps. If any parent task violates this constraint, the
ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Acyclicity: Following the chain of parent references <bcp14>MUST NOT</bcp14>
lead back to the current task's "tid". If a cycle is detected,
the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Parent Policy Decision: If any parent task has a "pol_decision"
of "rejected" or "pending_human_review", the current task's
"exec_act" <bcp14>MUST</bcp14> indicate a compensation, rollback, remediation,
or human review action. Implementations <bcp14>MUST NOT</bcp14> accept an ECT
representing normal workflow continuation when a parent's
"pol_decision" is not "approved", unless the current ECT has
"compensation_required" set to true.</t>
<t>Trust Domain Consistency: Parent tasks <bcp14>SHOULD</bcp14> belong to the
same trust domain or to a trust domain with which a federation
relationship has been established.</t>
</list></t>
</section>
<section anchor="dag-validation-algorithm"><name>DAG Validation Algorithm</name>
<t>The following pseudocode describes the DAG validation procedure:</t>
<figure title="DAG Validation Pseudocode" anchor="fig-dag-validation"><sourcecode type="pseudocode"><![CDATA[
function validate_dag(ect, ect_store, clock_skew_tolerance):
// ect_store: ledger or local cache of verified ECTs
// Step 1: Uniqueness check
if ect_store.contains(ect.tid, ect.wid):
return error("Task ID already exists")
// Step 2: Parent existence and temporal ordering
for parent_id in ect.par:
parent = ect_store.get(parent_id)
if parent is null:
return error("Parent task not found: " + parent_id)
if parent.iat >= ect.iat + clock_skew_tolerance:
return error("Parent task not earlier than current")
// Step 3: Cycle detection (with traversal limit)
visited = set()
result = has_cycle(ect.tid, ect.par, ect_store, visited,
max_ancestor_limit)
if result is error or result is true:
return error("Circular dependency or depth limit exceeded")
return success
function has_cycle(target_tid, parent_ids, ect_store,
visited, max_depth):
if visited.size() >= max_depth:
return error("Maximum ancestor traversal limit exceeded")
for parent_id in parent_ids:
if parent_id == target_tid:
return true
if parent_id in visited:
continue
visited.add(parent_id)
parent = ect_store.get(parent_id)
if parent is not null:
result = has_cycle(target_tid, parent.par, ect_store,
visited, max_depth)
if result is error or result is true:
return result
return false
]]></sourcecode></figure>
<t>The cycle detection traverses the ancestor graph rooted at the
current task's parents. The complexity is O(V) where V is the
number of ancestor nodes reachable from the current task's parent
references. For typical workflows with shallow DAGs, this is
efficient. To prevent denial-of-service via extremely deep or
wide DAGs, implementations <bcp14>SHOULD</bcp14> enforce a maximum ancestor
traversal limit (<bcp14>RECOMMENDED</bcp14>: 10000 nodes). If the limit is
reached before cycle detection completes, the ECT <bcp14>SHOULD</bcp14> be
rejected. Implementations <bcp14>SHOULD</bcp14> cache cycle detection results
for previously verified tasks to avoid redundant traversals.</t>
</section>
</section>
<section anchor="verification"><name>Signature and Token Verification</name>
<section anchor="verification-procedure"><name>Verification Procedure</name>
<t>When an agent receives an ECT, it <bcp14>MUST</bcp14> perform the following
verification steps in order:</t>
<t><list style="numbers" type="1">
<t>Parse the JWS Compact Serialization to extract the JOSE header,
payload, and signature components per <xref target="RFC7515"/>.</t>
<t>Verify that the "typ" header parameter is "wimse-exec+jwt".</t>
<t>Verify that the "alg" header parameter is not "none" and is
not a symmetric algorithm.</t>
<t>Verify the "kid" header parameter references a known, valid
public key from a WIT within the trust domain.</t>
<t>Retrieve the public key identified by "kid" and verify the JWS
signature per <xref target="RFC7515"/> Section 5.2.</t>
<t>Verify that the signing key identified by "kid" has not been
revoked within the trust domain. Implementations <bcp14>MUST</bcp14> check
the key's revocation status using the trust domain's key
lifecycle mechanism (e.g., certificate revocation list, OCSP,
or SPIFFE trust bundle updates).</t>
<t>Verify the "alg" header parameter matches the algorithm in the
corresponding WIT.</t>
<t>Verify the "iss" claim matches the "sub" claim of the WIT
associated with the "kid" public key.</t>
<t>Verify the "aud" claim contains the verifier's own workload
identity. When "aud" is an array, it is sufficient that the
verifier's identity appears as one element; the presence of
other audience values does not cause verification failure.
When the verifier is the audit ledger, the ledger's own
identity <bcp14>MUST</bcp14> appear in "aud".</t>
<t>Verify the "exp" claim indicates the ECT has not expired.</t>
<t>Verify the "iat" claim is not unreasonably far in the past
(implementation-specific threshold, <bcp14>RECOMMENDED</bcp14> maximum of
15 minutes) and is not unreasonably far in the future
(<bcp14>RECOMMENDED</bcp14>: no more than 30 seconds ahead of the
verifier's current time, to account for clock skew).</t>
<t>Verify all required claims ("jti", "tid", "exec_act", "par",
"pol", "pol_decision") are present and well-formed.</t>
<t>Verify "pol_decision" is one of "approved", "rejected", or
"pending_human_review".</t>
<t>Perform DAG validation per <xref target="dag-validation"/>.</t>
<t>If all checks pass and an audit ledger is available, the ECT
<bcp14>SHOULD</bcp14> be appended to the audit ledger. In point-to-point
mode (<xref target="operational-modes"/>), the verified ECT is retained
locally by the receiving agent.</t>
</list></t>
<t>If any verification step fails, the ECT <bcp14>MUST</bcp14> be rejected and the
failure <bcp14>MUST</bcp14> be logged for audit purposes. Error messages
<bcp14>SHOULD NOT</bcp14> reveal whether specific parent task IDs exist in the
ledger, to prevent information disclosure.</t>
<t>When ECT verification fails during HTTP request processing, the
receiving agent <bcp14>SHOULD</bcp14> respond with HTTP 403 (Forbidden) if the
WIT and WPT are valid but the ECT is invalid, and HTTP 401
(Unauthorized) if the ECT signature verification fails. The
response body <bcp14>SHOULD</bcp14> include a generic error indicator without
revealing which specific verification step failed. The receiving
agent <bcp14>MUST NOT</bcp14> process the requested action when ECT verification
fails.</t>
</section>
<section anchor="verification-pseudocode"><name>Verification Pseudocode</name>
<figure title="ECT Verification Pseudocode" anchor="fig-verification"><sourcecode type="pseudocode"><![CDATA[
function verify_ect(ect_jws, verifier_id,
trust_domain_keys, ledger):
// Parse JWS
(header, payload, signature) = parse_jws(ect_jws)
// Verify header
if header.typ != "wimse-exec+jwt":
return reject("Invalid typ parameter")
if header.alg == "none" or is_symmetric(header.alg):
return reject("Prohibited algorithm")
// Look up public key
public_key = trust_domain_keys.get(header.kid)
if public_key is null:
return reject("Unknown key identifier")
// Verify signature
if not verify_jws_signature(header, payload,
signature, public_key):
return reject("Invalid signature")
// Verify key not revoked
if is_key_revoked(header.kid, trust_domain_keys):
return reject("Signing key has been revoked")
// Verify algorithm alignment
wit = get_wit_for_key(header.kid)
if header.alg != wit.alg:
return reject("Algorithm mismatch with WIT")
// Verify issuer matches WIT subject
if payload.iss != wit.sub:
return reject("Issuer does not match WIT subject")
// Verify audience
if verifier_id not in payload.aud:
return reject("ECT not intended for this recipient")
// Verify not expired
if payload.exp < current_time():
return reject("ECT has expired")
// Verify iat freshness (not too old, not in the future)
if payload.iat < current_time() - max_age_threshold:
return reject("ECT issued too long ago")
if payload.iat > current_time() + clock_skew_tolerance:
return reject("ECT issued in the future")
// Verify required claims
for claim in ["jti", "tid", "exec_act", "par",
"pol", "pol_decision"]:
if claim not in payload:
return reject("Missing required claim: " + claim)
// Validate pol_decision value
if payload.pol_decision not in
["approved", "rejected", "pending_human_review"]:
return reject("Invalid pol_decision value")
// Validate DAG (against ledger or inline parent ECTs)
result = validate_dag(payload, ect_store,
clock_skew_tolerance)
if result is error:
return reject("DAG validation failed")
// All checks passed
if ledger is available:
ledger.append(payload)
else:
// Point-to-point mode: retain locally
local_ect_cache.store(payload)
return accept
]]></sourcecode></figure>
</section>
</section>
<section anchor="operational-modes"><name>Operational Modes</name>
<t>ECTs can be deployed in three operational modes depending on the
availability and requirements of the deployment environment. All
modes use the same ECT format and verification procedure; they
differ in how parent ECTs are resolved during DAG validation and
where verified ECTs are stored.</t>
<section anchor="point-to-point-mode"><name>Point-to-Point Mode</name>
<t>In point-to-point mode, agents pass parent ECTs directly to
downstream agents via multiple Execution-Context HTTP headers.
No centralized ledger is required. The receiving agent verifies
each parent ECT independently and validates the DAG against the
set of ECTs received in the request.</t>
<t>This mode is suitable for:</t>
<t><list style="symbols">
<t>Cross-organizational workflows where no shared ledger exists</t>
<t>Lightweight deployments where infrastructure is constrained</t>
<t>Early adoption scenarios before ledger infrastructure is
available</t>
</list></t>
<t>Limitations of point-to-point mode:</t>
<t><list style="symbols">
<t>No persistent audit trail unless agents independently retain
ECTs</t>
<t>Global replay detection relies solely on "jti" caches at each
agent; there is no centralized "tid" uniqueness check</t>
<t>The parent ECT chain grows with each hop, increasing HTTP
header size</t>
<t>Post-hoc audit reconstruction requires collecting ECTs from
multiple agents</t>
</list></t>
<t>Agents operating in point-to-point mode <bcp14>MUST</bcp14> retain verified
parent ECTs for at least the duration of the workflow to support
DAG validation of downstream requests. Agents <bcp14>SHOULD</bcp14> persist
ECTs locally for audit purposes even when no centralized ledger
is available.</t>
</section>
<section anchor="deferred-ledger-mode"><name>Deferred Ledger Mode</name>
<t>In deferred ledger mode, agents create and verify ECTs in-flight
using point-to-point delivery, and submit collected ECTs to an
audit ledger after the workflow completes or at periodic intervals.</t>
<t>This mode decouples real-time workflow execution from ledger
availability. DAG validation during execution uses inline parent
ECTs; full DAG validation against the complete workflow is
performed at ledger submission time.</t>
<t>Agents <bcp14>MUST</bcp14> include all collected ECTs when submitting to the
ledger. The ledger <bcp14>MUST</bcp14> re-validate the complete DAG upon
submission.</t>
</section>
<section anchor="full-ledger-mode"><name>Full Ledger Mode</name>
<t>In full ledger mode, every verified ECT is immediately appended
to an audit ledger. DAG validation is performed against the
ledger, which serves as the authoritative ECT store. This is
the <bcp14>RECOMMENDED</bcp14> mode for regulated environments where persistent,
centralized audit trails are required.</t>
</section>
</section>
<section anchor="ledger-interface"><name>Audit Ledger Interface</name>
<section anchor="overview-1"><name>Overview</name>
<t>Use of an audit ledger is <bcp14>RECOMMENDED</bcp14> for regulated environments
and any deployment requiring persistent, centralized audit trails.
ECTs are designed to be recorded in an immutable audit ledger for
compliance verification and post-hoc analysis. This specification
defines the logical interface for the ledger but does not mandate
a specific storage technology. Implementations <bcp14>MAY</bcp14> use
append-only logs, databases with cryptographic commitment schemes,
distributed ledgers, or any storage mechanism that provides the
required properties.</t>
</section>
<section anchor="required-properties"><name>Required Properties</name>
<t>An audit ledger implementation <bcp14>MUST</bcp14> provide:</t>
<t><list style="numbers" type="1">
<t>Append-only semantics: Once an ECT is recorded, it <bcp14>MUST NOT</bcp14> be
modified or deleted.</t>
<t>Ordering: The ledger <bcp14>MUST</bcp14> maintain a total ordering of ECT
entries via a monotonically increasing sequence number.</t>
<t>Lookup by task ID: The ledger <bcp14>MUST</bcp14> support efficient retrieval
of ECT entries by "tid" value.</t>
<t>Integrity verification: The ledger <bcp14>SHOULD</bcp14> provide a mechanism
to verify that no entries have been tampered with (e.g.,
hash chains or Merkle trees).</t>
</list></t>
<t>The ledger <bcp14>SHOULD</bcp14> be maintained by an entity independent of the
workflow agents to reduce the risk of collusion.</t>
</section>
<section anchor="ledger-entry-structure"><name>Ledger Entry Structure</name>
<t>Each ledger entry is a logical record containing:</t>
<figure title="Ledger Entry Example" anchor="fig-ledger-entry"><sourcecode type="json"><![CDATA[
{
"ledger_sequence": 42,
"task_id": "550e8400-e29b-41d4-a716-446655440001",
"agent_id": "spiffe://example.com/agent/clinical",
"action": "recommend_treatment",
"parents": [],
"ect_jws": "eyJhbGciOiJFUzI1NiIs...<complete JWS>",
"signature_verified": true,
"verification_timestamp": "2026-02-24T15:42:31.000Z",
"stored_timestamp": "2026-02-24T15:42:31.050Z"
}
]]></sourcecode></figure>
<t>The "ect_jws" field contains the full JWS Compact Serialization
and is the authoritative record. The other fields ("agent_id",
"action", "parents") are convenience indexes derived from the
ECT payload; if they disagree with the JWS payload, the JWS
payload takes precedence. Implementations <bcp14>SHOULD</bcp14> validate that
convenience index fields match the corresponding values in the
JWS payload at write time to prevent desynchronization between
the authoritative JWS and the indexed fields.</t>
</section>
</section>
<section anchor="use-cases"><name>Use Cases</name>
<t>This section describes representative use cases demonstrating how
ECTs provide execution records in regulated environments. These
examples demonstrate ECT mechanics; production deployments would
include additional domain-specific requirements beyond the scope
of this specification.</t>
<t>Note: task identifiers in this section are abbreviated for
readability. In production, all "tid" values are required to be
UUIDs per <xref target="exec-claims"/>.</t>
<section anchor="medical-device-sdlc-workflow"><name>Medical Device SDLC Workflow</name>
<t>In a medical device software development lifecycle (SDLC),
AI agents assist across multiple phases from requirements
analysis through release approval. Regulatory frameworks
including <xref target="FDA-21CFR11"/> Section 11.10(e) and <xref target="EU-MDR"/> require
audit trails documenting the complete development process for
software used in medical devices.</t>
<figure title="Medical Device SDLC Workflow" anchor="fig-medtech-sdlc"><artwork><![CDATA[
Agent A (Spec Reviewer):
tid: task-001 par: []
exec_act: review_requirements_spec
pol: spec_review_policy_v2 pol_decision: approved
Agent B (Code Generator):
tid: task-002 par: [task-001]
exec_act: implement_module
pol: coding_standards_v3 pol_decision: approved
Agent C (Test Agent):
tid: task-003 par: [task-002]
exec_act: execute_test_suite
pol: test_coverage_policy_v1 pol_decision: approved
Agent D (Build Agent):
tid: task-004 par: [task-003]
exec_act: build_release_artifact
pol: build_validation_v2 pol_decision: approved
Human Release Manager:
tid: task-005 par: [task-004]
exec_act: approve_release
pol: release_approval_policy pol_decision: approved
pol_enforcer: spiffe://meddev.example/human/release-mgr-42
witnessed_by: [spiffe://meddev.example/audit/qa-observer-1]
]]></artwork></figure>
<t>ECTs record that requirements were reviewed before implementation
began, that tests were executed against the implemented code, that
the build artifact was validated, and that a human release manager
explicitly approved the release. The DAG structure ensures no
phase was skipped or reordered.</t>
<section anchor="fda-audit-with-dag-reconstruction"><name>FDA Audit with DAG Reconstruction</name>
<t>During a regulatory audit, an FDA reviewer requests evidence of
the development process for a specific software release. The
auditing authority retrieves all ECTs sharing the same workflow
identifier ("wid") from the audit ledger and reconstructs the
complete DAG:</t>
<figure title="Reconstructed DAG for FDA Audit" anchor="fig-fda-audit"><artwork><![CDATA[
task-001 (review_requirements_spec)
|
v
task-002 (implement_module)
|
v
task-003 (execute_test_suite)
|
v
task-004 (build_release_artifact)
|
v
task-005 (approve_release) [human, witnessed]
]]></artwork></figure>
<t>The reconstructed DAG provides cryptographic evidence that:</t>
<t><list style="symbols">
<t>Each phase was executed by an identified and authenticated agent.</t>
<t>Policy checkpoints were evaluated at every phase transition.</t>
<t>The execution sequence was maintained (no step was bypassed).</t>
<t>A human-in-the-loop approved the final release, with independent
witness attestation.</t>
<t>Timestamps and execution durations are recorded for each step.</t>
</list></t>
<t>This can contribute to compliance with:</t>
<t><list style="symbols">
<t><xref target="FDA-21CFR11"/> Section 11.10(e): Computer-generated audit trails
that record the date, time, and identity of the operator.</t>
<t><xref target="EU-MDR"/> Annex II: Technical documentation traceability for the
software development lifecycle.</t>
<t><xref target="EU-AI-ACT"/> Article 12: Automatic logging capabilities for
high-risk AI systems involved in the development process.</t>
<t><xref target="EU-AI-ACT"/> Article 14: ECTs can record evidence that human
oversight events occurred during the release process.</t>
</list></t>
</section>
</section>
<section anchor="financial-trading-workflow"><name>Financial Trading Workflow</name>
<t>In a financial trading workflow, agents perform risk assessment,
compliance verification, and trade execution. The DAG structure
records that compliance checks were evaluated before trade
execution.</t>
<figure title="Financial Trading Workflow" anchor="fig-finance"><artwork><![CDATA[
Agent A (Risk Assessment):
tid: task-001 par: []
exec_act: calculate_risk_exposure
pol: risk_limits_policy_v2 pol_decision: approved
Agent B (Compliance):
tid: task-002 par: [task-001]
exec_act: verify_compliance
pol: compliance_check_v1 pol_decision: approved
Agent C (Execution):
tid: task-003 par: [task-002]
exec_act: execute_trade
pol: execution_policy_v3 pol_decision: approved
]]></artwork></figure>
<t>This can contribute to compliance with:</t>
<t><list style="symbols">
<t><xref target="MIFID-II"/>: ECTs provide cryptographic records of the execution
sequence that can support transaction audit requirements.</t>
<t><xref target="DORA"/> Article 12: ECTs contribute to ICT activity logging.</t>
<t><xref target="EU-AI-ACT"/> Article 12: Logging of decisions made by AI-driven
systems.</t>
</list></t>
</section>
<section anchor="compensation-and-rollback"><name>Compensation and Rollback</name>
<t>When a compliance violation is discovered after execution, ECTs
provide a mechanism to record authorized compensation actions with
a cryptographic link to the original task:</t>
<figure title="Compensation ECT Example" anchor="fig-compensation"><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://bank.example/agent/operations",
"sub": "spiffe://bank.example/agent/operations",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772150550,
"exp": 1772151150,
"jti": "e4f5a6b7-c8d9-0123-ef01-234567890abc",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"tid": "550e8400-e29b-41d4-a716-446655440099",
"exec_act": "initiate_trade_rollback",
"par": ["550e8400-e29b-41d4-a716-446655440003"],
"pol": "compensation_policy_v1",
"pol_decision": "approved",
"pol_enforcer": "spiffe://bank.example/human/compliance-officer",
"compensation_required": true,
"compensation_reason": "policy_violation_in_parent_trade"
}
]]></sourcecode></figure>
<t>The "par" claim links the compensation action to the original
trade, creating an auditable chain from execution through
violation discovery to remediation.</t>
</section>
<section anchor="autonomous-logistics-coordination"><name>Autonomous Logistics Coordination</name>
<t>In a logistics workflow, multiple compliance checks complete
before shipment commitment. The DAG structure records that all
required checks were completed:</t>
<figure title="Logistics Workflow with Parallel Tasks" anchor="fig-logistics"><artwork><![CDATA[
Agent A (Route Planning):
tid: task-001 par: []
exec_act: plan_route
pol: route_policy_v1 pol_decision: approved
Agent B (Customs):
tid: task-002 par: [task-001]
exec_act: validate_customs
pol: customs_policy_v2 pol_decision: approved
Agent C (Safety):
tid: task-003 par: [task-001]
exec_act: verify_cargo_safety
pol: safety_policy_v1 pol_decision: approved
Agent D (Payment):
tid: task-004 par: [task-002, task-003]
exec_act: authorize_payment
pol: payment_policy_v3 pol_decision: approved
System (Commitment):
tid: task-005 par: [task-004]
exec_act: commit_shipment
pol: commitment_policy_v1 pol_decision: approved
]]></artwork></figure>
<t>Note that tasks 002 and 003 both depend only on task-001 and can
execute in parallel. Task 004 depends on both, demonstrating the
DAG's ability to represent parallel execution with a join point.</t>
</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>This section addresses security considerations following the
guidance in <xref target="RFC3552"/>.</t>
<section anchor="threat-model"><name>Threat Model</name>
<t>The following threat actors are considered:</t>
<t><list style="symbols">
<t>Malicious agent (insider threat): An agent within the trust
domain that intentionally creates false ECT claims.</t>
<t>Compromised agent (external attacker): An agent whose private
key has been obtained by an external attacker.</t>
<t>Ledger tamperer: An entity attempting to modify or delete ledger
entries after they have been recorded.</t>
<t>Time manipulator: An entity attempting to manipulate timestamps
to alter perceived execution ordering.</t>
</list></t>
</section>
<section anchor="self-assertion-limitation"><name>Self-Assertion Limitation</name>
<t>ECTs are self-asserted by the executing agent. The agent claims
what it did, and this claim is signed with its private key. A
compromised or malicious agent could create ECTs with false claims
(e.g., setting "pol_decision" to "approved" without actually
evaluating the policy).</t>
<t>ECTs do not independently verify that:</t>
<t><list style="symbols">
<t>The claimed execution actually occurred as described</t>
<t>The policy evaluation was correctly performed</t>
<t>The input/output hashes correspond to the actual data processed</t>
<t>The agent faithfully performed the stated action</t>
</list></t>
<t>The trustworthiness of ECT claims depends on the trustworthiness
of the signing agent. To mitigate single-agent false claims,
regulated environments <bcp14>SHOULD</bcp14> use the "witnessed_by" mechanism
to include independent third-party observers at critical decision
points. However, the "witnessed_by" claim is self-asserted by
the ECT issuer: the listed witnesses do not co-sign the ECT and
there is no cryptographic proof within a single ECT that the
witnesses actually observed the task. An issuing agent could
list witnesses that did not participate.</t>
<section anchor="witness-attestation-model"><name>Witness Attestation Model</name>
<t>To address the self-assertion limitation of the "witnessed_by"
claim, witnesses <bcp14>SHOULD</bcp14> submit their own independent signed ECTs
to the audit ledger attesting to the observed task. A witness
attestation ECT:</t>
<t><list style="symbols">
<t><bcp14>MUST</bcp14> set "iss" to the witness's own workload identity.</t>
<t><bcp14>MUST</bcp14> set "exec_act" to "witness_attestation" (or a domain-
specific equivalent).</t>
<t><bcp14>MUST</bcp14> include the observed task's "tid" in the "par" array,
linking the attestation to the original task.</t>
<t><bcp14>MUST</bcp14> set "pol_decision" to "approved" to indicate the witness
confirms the observation.</t>
</list></t>
<t>When a task's "witnessed_by" claim lists one or more witnesses,
auditors <bcp14>SHOULD</bcp14> verify that corresponding witness attestation
ECTs exist in the ledger for each listed witness. A mismatch
between the "witnessed_by" list and the set of independent witness
ECTs in the ledger <bcp14>SHOULD</bcp14> be flagged during audit review.</t>
<t>This model converts witness attestation from a self-asserted claim
to a cryptographically verifiable property of the ledger: the
witness independently signs their own ECT using their own key,
and the ledger records both the original task ECT and the witness
attestation ECTs.</t>
</section>
</section>
<section anchor="organizational-prerequisites"><name>Organizational Prerequisites</name>
<t>ECTs operate within a broader trust framework. The guarantees
provided by ECTs are only meaningful when the following
organizational controls are in place:</t>
<t><list style="symbols">
<t>Key management governance: Controls over who provisions agent
keys and how keys are protected.</t>
<t>Ledger integrity governance: The ledger is maintained by an
entity independent of the workflow agents.</t>
<t>Policy lifecycle management: Policy identifiers in ECTs map to
actual, validated policy rules.</t>
<t>Agent deployment governance: Agents are deployed and maintained
in a manner that preserves their integrity.</t>
</list></t>
</section>
<section anchor="signature-verification"><name>Signature Verification</name>
<t>ECTs <bcp14>MUST</bcp14> be signed with the agent's private key using JWS
<xref target="RFC7515"/>. The signature algorithm <bcp14>MUST</bcp14> match the algorithm
specified in the agent's WIT. Receivers <bcp14>MUST</bcp14> verify the ECT
signature against the WIT public key before processing any
claims. Receivers <bcp14>MUST</bcp14> verify that the signing key has not been
revoked within the trust domain (see step 6 in
<xref target="verification"/>).</t>
<t>If signature verification fails or if the signing key has been
revoked, the ECT <bcp14>MUST</bcp14> be rejected entirely and the failure <bcp14>MUST</bcp14>
be logged.</t>
<t>Implementations <bcp14>MUST</bcp14> use established JWS libraries and <bcp14>MUST NOT</bcp14>
implement custom signature verification.</t>
</section>
<section anchor="replay-attack-prevention"><name>Replay Attack Prevention</name>
<t>ECTs include short expiration times (<bcp14>RECOMMENDED</bcp14>: 5-15 minutes) to
limit the window for replay attacks. The "aud" claim restricts
replay to unintended recipients: an ECT intended for Agent B
will be rejected by Agent C. The "iat" claim enables receivers to
reject ECTs that are too old, even if not yet expired.</t>
<t>The DAG structure provides additional replay protection: an ECT
referencing parent tasks that already have a recorded child task
with the same action can be flagged as a potential replay.</t>
<t>Implementations <bcp14>MUST</bcp14> maintain a cache of recently-seen "jti"
values to detect replayed ECTs within the expiration window.
An ECT with a duplicate "jti" value <bcp14>MUST</bcp14> be rejected.</t>
</section>
<section anchor="man-in-the-middle-protection"><name>Man-in-the-Middle Protection</name>
<t>ECTs do not replace transport-layer security. ECTs <bcp14>MUST</bcp14> be
transmitted over TLS or mTLS connections. When used with the WIMSE
service-to-service protocol <xref target="I-D.ietf-wimse-s2s-protocol"/>,
transport security is already established. HTTP Message Signatures
<xref target="RFC9421"/> provide an alternative channel binding mechanism.</t>
<t>The defense-in-depth model provides:</t>
<t><list style="symbols">
<t>TLS/mTLS (transport layer): Prevents network-level tampering.</t>
<t>WIT/WPT (WIMSE identity layer): Proves agent identity and
request authorization.</t>
<t>ECT (execution accountability layer): Records what the agent did
and under what policy.</t>
</list></t>
</section>
<section anchor="key-compromise"><name>Key Compromise</name>
<t>If an agent's private key is compromised, an attacker can forge
ECTs that appear to originate from that agent. To mitigate this
risk:</t>
<t><list style="symbols">
<t>Implementations <bcp14>SHOULD</bcp14> use short-lived keys and rotate them
frequently (hours to days, not months).</t>
<t>Private keys <bcp14>SHOULD</bcp14> be stored in Hardware Security Modules (HSMs)
or equivalent secure key storage.</t>
<t>Trust domains <bcp14>MUST</bcp14> support rapid key revocation.</t>
<t>Upon suspected compromise, the trust domain <bcp14>MUST</bcp14> revoke the
compromised key and issue a new WIT with a fresh key pair.</t>
</list></t>
<t>ECTs signed with a compromised key that were recorded in the
ledger before revocation remain valid historical records but <bcp14>SHOULD</bcp14>
be flagged in the ledger as "signed with subsequently revoked key"
for audit purposes.</t>
</section>
<section anchor="collusion-and-false-claims"><name>Collusion and False Claims</name>
<t>A single malicious agent cannot forge parent task references
because DAG validation requires parent tasks to exist in the
ledger. However, multiple colluding agents could potentially
create a false execution history if they control the ledger.</t>
<t>Mitigations include:</t>
<t><list style="symbols">
<t>Independent ledger maintenance: The ledger <bcp14>SHOULD</bcp14> be maintained
by an entity independent of the workflow agents.</t>
<t>Witness attestation: Using the "witnessed_by" claim to include
independent third-party observers.</t>
<t>Cross-verification: Multiple independent ledger replicas can be
compared for consistency.</t>
<t>Out-of-band audit: External auditors periodically verify ledger
contents against expected workflow patterns.</t>
</list></t>
</section>
<section anchor="denial-of-service"><name>Denial of Service</name>
<t>ECT signature verification is computationally inexpensive
(approximately 1ms per ECT on modern hardware for ES256). DAG
validation complexity is O(V) where V is the number of ancestor
nodes reachable from the parent references; for typical shallow
DAGs this is efficient.</t>
<t>Implementations <bcp14>SHOULD</bcp14> apply rate limiting at the API layer to
prevent excessive ECT submissions. DAG validation <bcp14>SHOULD</bcp14> be
performed after signature verification to avoid wasting resources
on unsigned or incorrectly signed tokens.</t>
</section>
<section anchor="timestamp-accuracy"><name>Timestamp Accuracy</name>
<t>ECTs rely on timestamps ("iat", "exp") for temporal ordering.
Clock skew between agents can lead to incorrect ordering
judgments. Implementations <bcp14>SHOULD</bcp14> use synchronized time sources
(e.g., NTP) and <bcp14>SHOULD</bcp14> allow a configurable clock skew tolerance
(<bcp14>RECOMMENDED</bcp14>: 30 seconds).</t>
<t>Cross-organizational deployments where agents span multiple trust
domains with independent time sources <bcp14>MAY</bcp14> require a higher clock
skew tolerance. Deployments using trust domain federation <bcp14>SHOULD</bcp14>
document their configured clock skew tolerance value and <bcp14>SHOULD</bcp14>
ensure all participating trust domains agree on a common tolerance.</t>
<t>The temporal ordering check in DAG validation incorporates the
clock skew tolerance to account for minor clock differences
between agents.</t>
</section>
<section anchor="ect-size-constraints"><name>ECT Size Constraints</name>
<t>ECTs with many parent tasks or large extension objects can
increase HTTP header size. Implementations <bcp14>SHOULD</bcp14> limit the "par"
array to a maximum of 256 entries. Workflows requiring more
parent references <bcp14>SHOULD</bcp14> introduce intermediate aggregation
tasks. The "ext" object <bcp14>SHOULD NOT</bcp14> exceed 4096 bytes when
serialized as JSON and <bcp14>SHOULD NOT</bcp14> exceed a nesting depth of
5 levels (see also <xref target="extension-claims"/>).</t>
</section>
</section>
<section anchor="privacy-considerations"><name>Privacy Considerations</name>
<section anchor="data-exposure-in-ects"><name>Data Exposure in ECTs</name>
<t>ECTs necessarily reveal:</t>
<t><list style="symbols">
<t>Agent identities ("iss", "aud") for accountability purposes</t>
<t>Action descriptions ("exec_act") for audit trail completeness</t>
<t>Policy evaluation outcomes ("pol", "pol_decision") for
compliance verification</t>
<t>Timestamps ("iat", "exp") for temporal ordering</t>
</list></t>
<t>ECTs are designed to NOT reveal:</t>
<t><list style="symbols">
<t>Actual input or output data values (replaced with cryptographic
hashes via "inp_hash" and "out_hash")</t>
<t>Internal computation details or intermediate steps</t>
<t>Proprietary algorithms or intellectual property</t>
<t>Personally identifiable information (PII)</t>
</list></t>
</section>
<section anchor="data-minimization"><name>Data Minimization</name>
<t>Implementations <bcp14>SHOULD</bcp14> minimize the information included in ECTs.
The "exec_act" claim <bcp14>SHOULD</bcp14> use structured identifiers (e.g.,
"process_payment") rather than natural language descriptions.
The "pol" claim <bcp14>SHOULD</bcp14> reference policy identifiers rather than
embedding policy content.</t>
<t>The "compensation_reason" claim (<xref target="compensation-claims"/>)
deserves particular attention: because it is human-readable and
may describe the circumstances of a failure or policy violation,
it risks exposing sensitive operational details. Implementations
<bcp14>SHOULD</bcp14> use short, structured reason codes (e.g.,
"policy_violation_in_parent_trade") rather than free-form
natural language explanations. Implementers <bcp14>SHOULD</bcp14> review
"compensation_reason" values for potential information leakage
before deploying to production.</t>
</section>
<section anchor="storage-and-access-control"><name>Storage and Access Control</name>
<t>ECTs stored in audit ledgers <bcp14>SHOULD</bcp14> be access-controlled so that
only authorized auditors and regulators can read them.
Implementations <bcp14>SHOULD</bcp14> consider encryption at rest for ledger
storage containing sensitive regulatory data.</t>
<t>Full input and output data (corresponding to the hashes in ECTs)
<bcp14>SHOULD</bcp14> be stored separately from the ledger with additional access
controls, since auditors may need to verify hash correctness but
general access to the data values is not needed.</t>
</section>
<section anchor="regulatory-access"><name>Regulatory Access</name>
<t>ECTs are designed for interpretation by qualified human auditors
and regulators. ECTs provide structural records of execution
ordering and policy evaluation; they are not intended for public
disclosure.</t>
</section>
</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
in the "Media Types" registry maintained by IANA:</t>
<dl>
<dt>Type name:</dt>
<dd>
<t>application</t>
</dd>
<dt>Subtype name:</dt>
<dd>
<t>wimse-exec+jwt</t>
</dd>
<dt>Required parameters:</dt>
<dd>
<t>none</t>
</dd>
<dt>Optional parameters:</dt>
<dd>
<t>none</t>
</dd>
<dt>Encoding considerations:</dt>
<dd>
<t>8bit; an ECT is a JWT that is a JWS using the Compact
Serialization, which is a sequence of Base64url-encoded values
separated by period characters.</t>
</dd>
<dt>Security considerations:</dt>
<dd>
<t>See the Security Considerations section of this document.</t>
</dd>
<dt>Interoperability considerations:</dt>
<dd>
<t>none</t>
</dd>
<dt>Published specification:</dt>
<dd>
<t>This document</t>
</dd>
<dt>Applications that use this media type:</dt>
<dd>
<t>Applications that implement regulated agentic workflows requiring
execution context tracing and audit trails.</t>
</dd>
<dt>Additional information:</dt>
<dd>
<t>Magic number(s): none
File extension(s): none
Macintosh file type code(s): none</t>
</dd>
<dt>Person and email address to contact for further information:</dt>
<dd>
<t>Christian Nennemann, ietf@nennemann.de</t>
</dd>
<dt>Intended usage:</dt>
<dd>
<t>COMMON</t>
</dd>
<dt>Restrictions on usage:</dt>
<dd>
<t>none</t>
</dd>
<dt>Author:</dt>
<dd>
<t>Christian Nennemann</t>
</dd>
<dt>Change controller:</dt>
<dd>
<t>IETF</t>
</dd>
</dl>
</section>
<section anchor="header-registration"><name>HTTP Header Field Registration</name>
<t>This document requests registration of the following header field
in the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
maintained by IANA:</t>
<dl>
<dt>Field name:</dt>
<dd>
<t>Execution-Context</t>
</dd>
<dt>Status:</dt>
<dd>
<t>permanent</t>
</dd>
<dt>Specification document:</dt>
<dd>
<t>This document, <xref target="http-header"/></t>
</dd>
</dl>
</section>
<section anchor="claims-registration"><name>JWT Claims Registration</name>
<t>This document requests registration of the following claims in
the "JSON Web Token Claims" registry maintained by IANA:</t>
<texttable title="JWT Claims Registrations" anchor="_table-claims">
<ttcol align='center'>Claim Name</ttcol>
<ttcol align='left'>Claim Description</ttcol>
<ttcol align='center'>Change Controller</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>wid</c>
<c>Workflow Identifier</c>
<c>IETF</c>
<c><xref target="exec-claims"/></c>
<c>tid</c>
<c>Task Identifier</c>
<c>IETF</c>
<c><xref target="exec-claims"/></c>
<c>exec_act</c>
<c>Action/Task Type</c>
<c>IETF</c>
<c><xref target="exec-claims"/></c>
<c>par</c>
<c>Parent Task Identifiers</c>
<c>IETF</c>
<c><xref target="exec-claims"/></c>
<c>pol</c>
<c>Policy Rule Identifier</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_decision</c>
<c>Policy Decision Result</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_enforcer</c>
<c>Policy Enforcer Identity</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_timestamp</c>
<c>Policy Decision Timestamp</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>inp_hash</c>
<c>Input Data Hash</c>
<c>IETF</c>
<c><xref target="data-integrity-claims"/></c>
<c>out_hash</c>
<c>Output Data Hash</c>
<c>IETF</c>
<c><xref target="data-integrity-claims"/></c>
<c>inp_classification</c>
<c>Input Data Classification</c>
<c>IETF</c>
<c><xref target="data-integrity-claims"/></c>
<c>exec_time_ms</c>
<c>Execution Time (ms)</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>witnessed_by</c>
<c>Witness Identities</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>regulated_domain</c>
<c>Regulatory Domain</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>model_version</c>
<c>AI/ML Model Version</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>compensation_required</c>
<c>Compensation Flag</c>
<c>IETF</c>
<c><xref target="compensation-claims"/></c>
<c>compensation_reason</c>
<c>Compensation Reason</c>
<c>IETF</c>
<c><xref target="compensation-claims"/></c>
<c>ext</c>
<c>Extension Object</c>
<c>IETF</c>
<c><xref target="extension-claims"/></c>
</texttable>
</section>
<section anchor="pol-decision-registry"><name>ECT Policy Decision Values Registry</name>
<t>This document establishes the "ECT Policy Decision Values"
registry under the "JSON Web Token (JWT)" group. Registration
policy is Specification Required per <xref target="RFC8126"/>.</t>
<t>The initial contents of the registry are:</t>
<texttable title="ECT Policy Decision Values" anchor="_table-pol-decision">
<ttcol align='center'>Value</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='center'>Change Controller</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>approved</c>
<c>Policy evaluation succeeded</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>rejected</c>
<c>Policy evaluation failed</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pending_human_review</c>
<c>Awaiting human judgment</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
</texttable>
</section>
<section anchor="regulated-domain-registry"><name>ECT Regulated Domain Values Registry</name>
<t>This document establishes the "ECT Regulated Domain Values"
registry under the "JSON Web Token (JWT)" group. Registration
policy is Specification Required per <xref target="RFC8126"/>.</t>
<t>The initial contents of the registry are:</t>
<texttable title="ECT Regulated Domain Values" anchor="_table-regulated-domain">
<ttcol align='center'>Value</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='center'>Change Controller</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>medtech</c>
<c>Medical technology and devices</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>finance</c>
<c>Financial services and trading</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>military</c>
<c>Military and defense</c>
<c>IETF</c>
<c><xref target="operational-claims"/></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="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="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="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="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="I-D.ietf-wimse-arch">
<front>
<title>Workload Identity in a Multi System Environment (WIMSE) Architecture</title>
<author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
<organization>CyberArk</organization>
</author>
<author fullname="Yaroslav Rosomakho" initials="Y." surname="Rosomakho">
<organization>Zscaler</organization>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>University of Applied Sciences Bonn-Rhein-Sieg</organization>
</author>
<date day="30" month="September" year="2025"/>
<abstract>
<t> The increasing prevalence of cloud computing and micro service
architectures has led to the rise of complex software functions being
built and deployed as workloads, where a workload is defined as a
running instance of software executing for a specific purpose. This
document discusses an architecture for designing and standardizing
protocols and payloads for conveying workload identity and security
context information.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-wimse-arch-06"/>
</reference>
<reference anchor="I-D.ietf-wimse-s2s-protocol">
<front>
<title>WIMSE Workload-to-Workload Authentication</title>
<author fullname="Brian Campbell" initials="B." surname="Campbell">
<organization>Ping Identity</organization>
</author>
<author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
<organization>CyberArk</organization>
</author>
<author fullname="Arndt Schwenkschuster" initials="A." surname="Schwenkschuster">
<organization>SPIRL</organization>
</author>
<author fullname="Yaron Sheffer" initials="Y." surname="Sheffer">
<organization>Intuit</organization>
</author>
<date day="16" month="October" year="2025"/>
<abstract>
<t> The WIMSE architecture defines authentication and authorization for
software workloads in a variety of runtime environments, from the
most basic ones up to complex multi-service, multi-cloud, multi-
tenant deployments. This document defines the simplest, atomic unit
of this architecture: the protocol between two workloads that need to
verify each other&#x27;s identity in order to communicate securely. The
scope of this protocol is a single HTTP request-and-response pair.
To address the needs of different setups, we propose two protocols,
one at the application level and one that makes use of trusted TLS
transport. These two protocols are compatible, in the sense that a
single call chain can have some calls use one protocol and some use
the other. Workload A can call Workload B with mutual TLS
authentication, while the next call from Workload B to Workload C
would be authenticated at the application level.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-wimse-s2s-protocol-07"/>
</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>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
</references>
<references title='Informative References' anchor="sec-informative-references">
<reference anchor="RFC3552">
<front>
<title>Guidelines for Writing RFC Text on Security Considerations</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="B. Korver" initials="B." surname="Korver"/>
<date month="July" year="2003"/>
<abstract>
<t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. 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="72"/>
<seriesInfo name="RFC" value="3552"/>
<seriesInfo name="DOI" value="10.17487/RFC3552"/>
</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="RFC9421">
<front>
<title>HTTP Message Signatures</title>
<author fullname="A. Backman" initials="A." role="editor" surname="Backman"/>
<author fullname="J. Richer" initials="J." role="editor" surname="Richer"/>
<author fullname="M. Sporny" initials="M." surname="Sporny"/>
<date month="February" year="2024"/>
<abstract>
<t>This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9421"/>
<seriesInfo name="DOI" value="10.17487/RFC9421"/>
</reference>
<reference anchor="I-D.ni-wimse-ai-agent-identity">
<front>
<title>WIMSE Applicability for AI Agents</title>
<author fullname="Ni Yuan" initials="N." surname="Yuan">
<organization>Huawei</organization>
</author>
<author fullname="Peter Chunchi Liu" initials="P. C." surname="Liu">
<organization>Huawei</organization>
</author>
<date day="20" month="October" year="2025"/>
<abstract>
<t> This document discusses WIMSE applicability to Agentic AI, so as to
establish independent identities and credential management mechanisms
for AI agents.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ni-wimse-ai-agent-identity-01"/>
</reference>
<reference anchor="SPIFFE" target="https://spiffe.io/docs/latest/spiffe-about/overview/">
<front>
<title>Secure Production Identity Framework for Everyone (SPIFFE)</title>
<author >
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="EU-AI-ACT" target="https://eur-lex.europa.eu/eli/reg/2024/1689">
<front>
<title>Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2024" month="June" day="13"/>
</front>
</reference>
<reference anchor="FDA-21CFR11" target="https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11">
<front>
<title>Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures</title>
<author >
<organization>U.S. Food and Drug Administration</organization>
</author>
<date />
</front>
</reference>
<reference anchor="MIFID-II" target="https://eur-lex.europa.eu/eli/dir/2014/65">
<front>
<title>Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2014" month="May" day="15"/>
</front>
</reference>
<reference anchor="DORA" target="https://eur-lex.europa.eu/eli/reg/2022/2554">
<front>
<title>Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2022" month="December" day="14"/>
</front>
</reference>
<reference anchor="EU-MDR" target="https://eur-lex.europa.eu/eli/reg/2017/745">
<front>
<title>Regulation (EU) 2017/745 on medical devices (MDR)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2017" month="April" day="05"/>
</front>
</reference>
<reference anchor="OPENTELEMETRY" target="https://opentelemetry.io/docs/specs/otel/">
<front>
<title>OpenTelemetry Specification</title>
<author >
<organization>Cloud Native Computing Foundation</organization>
</author>
<date />
</front>
</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.ietf-oauth-transaction-tokens">
<front>
<title>Transaction Tokens</title>
<author fullname="Atul Tulshibagwale" initials="A." surname="Tulshibagwale">
<organization>SGNL</organization>
</author>
<author fullname="George Fletcher" initials="G." surname="Fletcher">
<organization>Practical Identity LLC</organization>
</author>
<author fullname="Pieter Kasselman" initials="P." surname="Kasselman">
<organization>Defakto Security</organization>
</author>
<date day="24" month="January" year="2026"/>
<abstract>
<t> Transaction Tokens (Txn-Tokens) are designed to maintain and
propagate user identity and authorization context across workloads
within a trusted domain during the processing of external requests,
such as API calls. They ensure that this context is preserved
throughout the call chain, even when new transactions are initiated
internally, thereby enhancing security and consistency in complex,
multi-service architectures.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-oauth-transaction-tokens-07"/>
</reference>
<reference anchor="I-D.oauth-transaction-tokens-for-agents">
<front>
<title>Transaction Tokens For Agents</title>
<author fullname="Ashay Raut" initials="A." surname="Raut">
<organization>Amazon</organization>
</author>
<date day="10" month="February" year="2026"/>
<abstract>
<t> This document specifies an extension to the OAuth Transaction Tokens
framework (https://drafts.oauth.net/oauth-transaction-tokens/draft-
ietf-oauth-transaction-tokens.html) to support agent context
propagation within Transaction Tokens for agent-based workloads. The
extension defines two new context fields: &#x27;actor&#x27; and &#x27;principal&#x27;.
The &#x27;actor&#x27; field identifies the agent performing the action, while
the &#x27;principal&#x27; field identifies the human or system entity that
initiated the agent&#x27;s action. For autonomous agents operating
independently, the &#x27;principal&#x27; field MAY be omitted. These
additional context fields enable services within the call graph to
make more granular access control decisions, thereby enhancing
security.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-oauth-transaction-tokens-for-agents-04"/>
</reference>
</references>
</references>
<?line 1743?>
<section numbered="false" anchor="related-work"><name>Related Work</name>
<section numbered="false" anchor="wimse-workload-identity"><name>WIMSE Workload Identity</name>
<t>The WIMSE architecture <xref target="I-D.ietf-wimse-arch"/> and service-to-
service protocol <xref target="I-D.ietf-wimse-s2s-protocol"/> provide the
identity foundation upon which ECTs are built. WIT/WPT answer
"who is this agent?" and "does it control the claimed key?" while
ECTs record "what did this agent do?" and "what policy was
evaluated?" Together they form an identity-plus-accountability
framework for regulated agentic systems.</t>
</section>
<section numbered="false" anchor="oauth-20-token-exchange-and-the-act-claim"><name>OAuth 2.0 Token Exchange and the "act" Claim</name>
<t><xref target="RFC8693"/> defines the OAuth 2.0 Token Exchange protocol and
registers the "act" (Actor) claim in the JWT Claims registry.
The "act" claim creates nested JSON objects representing a
delegation chain: "who is acting on behalf of whom." While
the nesting superficially resembles a chain, it is strictly
linear (each "act" object contains at most one nested "act"),
represents authorization delegation rather than task execution,
and carries no task identifiers, policy decisions, or
input/output integrity data. The "act" chain cannot represent
branching (fan-out) or convergence (fan-in) and therefore
cannot form a DAG.</t>
<t>ECTs intentionally use the distinct claim name "exec_act" for the
action/task type to avoid collision with the "act" claim. The
two concepts are orthogonal: "act" records "who authorized whom,"
ECTs record "what was done, in what order, with what policy
outcomes."</t>
</section>
<section numbered="false" anchor="transaction-tokens"><name>Transaction Tokens</name>
<t>OAuth Transaction Tokens <xref target="I-D.ietf-oauth-transaction-tokens"/>
propagate authorization context across workload call chains.
The Txn-Token "req_wl" claim accumulates a comma-separated list
of workloads that requested replacement tokens, which is the
closest existing mechanism to call-chain recording.</t>
<t>However, "req_wl" cannot form a DAG because:</t>
<t><list style="symbols">
<t>It is linear: a comma-separated string with no branching or
merging representation. When a workload fans out to multiple
downstream services, each receives the same "req_wl" value and
the branching is invisible.</t>
<t>It is incomplete: only workloads that request a replacement
token from the Transaction Token Service appear in "req_wl";
workloads that forward the token unchanged are not recorded.</t>
<t>It carries no task-level granularity, no parent references,
no policy evaluation outcomes, and no execution content.</t>
</list></t>
<t>Extensions for agentic use cases
(<xref target="I-D.oauth-transaction-tokens-for-agents"/>) add agent
identity and constraints ("agentic_ctx") but no execution
ordering or DAG structure.</t>
<t>ECTs and Transaction Tokens are complementary: a Txn-Token
propagates authorization context ("this request is authorized
for scope X on behalf of user Y"), while an ECT records
execution accountability ("task T was performed, depending on
tasks P1 and P2, with policy Z evaluated and approved"). An
agent request could carry both a Txn-Token for authorization
and an ECT for execution recording. The WPT "tth" claim
defined in <xref target="I-D.ietf-wimse-s2s-protocol"/> can hash-bind a
WPT to a co-present Txn-Token; a similar binding mechanism
for ECTs is a potential future extension.</t>
</section>
<section numbered="false" anchor="distributed-tracing-opentelemetry"><name>Distributed Tracing (OpenTelemetry)</name>
<t>OpenTelemetry <xref target="OPENTELEMETRY"/> and similar distributed tracing
systems provide observability for debugging and monitoring. ECTs
differ in several important ways: ECTs are cryptographically
signed per-task with the agent's private key; ECTs are
tamper-evident through JWS signatures; ECTs enforce DAG validation
rules; and ECTs are designed for regulatory audit rather than
operational monitoring. OpenTelemetry data is typically controlled
by the platform operator and can be modified or deleted without
detection. ECTs and distributed traces are complementary: traces
provide observability while ECTs provide signed execution records.
ECTs may reference OpenTelemetry trace identifiers in the "ext"
claim for correlation.</t>
</section>
<section numbered="false" anchor="blockchain-and-distributed-ledgers"><name>Blockchain and Distributed Ledgers</name>
<t>Both ECTs and blockchain systems provide immutable records. This
specification intentionally defines only the ECT token format and
is agnostic to the storage mechanism. ECTs can be stored in
append-only logs, databases with cryptographic commitments,
blockchain networks, or any storage providing the required
properties defined in <xref target="ledger-interface"/>.</t>
</section>
<section numbered="false" anchor="scitt-supply-chain-integrity-transparency-and-trust"><name>SCITT (Supply Chain Integrity, Transparency, and Trust)</name>
<t>The SCITT architecture <xref target="I-D.ietf-scitt-architecture"/> defines a
framework for creating transparent and auditable supply chain
records through Transparency Services, Signed Statements, and
Receipts. ECTs and SCITT are naturally complementary: the ECT
"wid" (Workflow Identifier) claim can serve as a correlation
identifier referenced in SCITT Signed Statements, linking a
complete ECT audit trail to a supply chain transparency record.
For example, in a regulated manufacturing workflow, each agent
step produces an ECT (recording what was done, by whom, under
what policy), while the overall workflow identified by "wid" is
registered as a SCITT Signed Statement on a Transparency Service.
This enables auditors to verify both the individual execution
steps (via ECT DAG validation) and the end-to-end supply chain
integrity (via SCITT Receipts) using the "wid" as the shared
correlation point. The "ext" claim in ECTs (<xref target="exec-claims"/>)
can carry SCITT-specific metadata such as Transparency Service
identifiers or Receipt references for tighter integration.</t>
</section>
<section numbered="false" anchor="w3c-verifiable-credentials"><name>W3C Verifiable Credentials</name>
<t>W3C Verifiable Credentials represent claims about subjects (e.g.,
identity, qualifications). ECTs represent execution records of
actions (what happened, in what order, under what policy). While
both use JWT/JWS as a serialization format, their semantics and
use cases are distinct.</t>
</section>
</section>
<section numbered="false" anchor="implementation-guidance"><name>Implementation Guidance</name>
<section numbered="false" anchor="minimal-implementation"><name>Minimal Implementation</name>
<t>A minimal conforming implementation needs to:</t>
<t><list style="numbers" type="1">
<t>Create JWTs with all required claims ("iss", "aud", "iat",
"exp", "jti", "tid", "exec_act", "par", "pol",
"pol_decision").</t>
<t>Sign ECTs with the agent's private key using an algorithm
matching the WIT (ES256 recommended).</t>
<t>Verify ECT signatures against WIT public keys.</t>
<t>Perform DAG validation (parent existence, temporal ordering,
cycle detection).</t>
<t>Store verified ECTs (append to audit ledger in full ledger
mode, or retain locally in point-to-point mode per
<xref target="operational-modes"/>).</t>
</list></t>
</section>
<section numbered="false" anchor="storage-recommendations"><name>Storage Recommendations</name>
<t><list style="symbols">
<t>Append-only log: Simplest approach; immutability by design.</t>
<t>Database with hash chains: Periodic cryptographic commitments
over batches of entries.</t>
<t>Distributed ledger: Maximum immutability guarantees for
cross-organizational audit.</t>
<t>Hybrid: Hot storage in a database, cold archive in immutable
storage.</t>
</list></t>
</section>
<section numbered="false" anchor="performance-considerations"><name>Performance Considerations</name>
<t><list style="symbols">
<t>ES256 signature verification: approximately 1ms per ECT on
modern hardware.</t>
<t>DAG validation: O(V) where V is the number of reachable ancestor
nodes (typically small for shallow workflows).</t>
<t>JSON serialization: sub-millisecond per ECT.</t>
<t>Total per-request overhead: approximately 5-10ms, acceptable
for regulated workflows where correctness is prioritized over
latency.</t>
</list></t>
</section>
<section numbered="false" anchor="interoperability"><name>Interoperability</name>
<t>Implementations are expected to use established JWT/JWS libraries
(JOSE) for token creation and verification. Custom cryptographic
implementations are strongly discouraged. Implementations are
expected to be tested against multiple JWT libraries to ensure
interoperability.</t>
</section>
</section>
<section numbered="false" anchor="regulatory-compliance-mapping"><name>Regulatory Compliance Mapping</name>
<t>The following table summarizes how ECTs can contribute to
compliance with various regulatory frameworks. ECTs are a
technical building block; achieving compliance requires
additional organizational measures beyond this specification.</t>
<texttable title="Regulatory Compliance Mapping" anchor="_table-regulatory">
<ttcol align='left'>Regulation</ttcol>
<ttcol align='left'>Requirement</ttcol>
<ttcol align='left'>ECT Contribution</ttcol>
<c>FDA 21 CFR Part 11</c>
<c>Audit trails recording date, time, operator, actions (11.10(e))</c>
<c>Cryptographic signatures and append-only ledger contribute to audit trail requirements</c>
<c>EU MDR</c>
<c>Technical documentation traceability (Annex II)</c>
<c>ECTs provide signed records of AI-assisted decision sequences</c>
<c>EU AI Act Art. 12</c>
<c>Automatic logging capabilities for high-risk AI</c>
<c>ECTs contribute cryptographic activity logging</c>
<c>EU AI Act Art. 14</c>
<c>Human oversight capability</c>
<c>ECTs can record evidence that human oversight events occurred</c>
<c>MiFID II</c>
<c>Transaction records for supervisory authorities</c>
<c>ECTs provide cryptographic execution sequence records</c>
<c>DORA Art. 12</c>
<c>ICT activity logging policies</c>
<c>ECT ledger contributes to ICT activity audit trail</c>
</texttable>
</section>
<section numbered="false" anchor="examples"><name>Examples</name>
<section numbered="false" anchor="example-1-simple-two-agent-workflow"><name>Example 1: Simple Two-Agent Workflow</name>
<t>Agent A executes a data retrieval task and sends the ECT to
Agent B:</t>
<t>ECT JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
"kid": "agent-a-key-2026-02"
}
]]></sourcecode></figure>
<t>ECT Payload:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://example.com/agent/data-retrieval",
"sub": "spiffe://example.com/agent/data-retrieval",
"aud": "spiffe://example.com/agent/validator",
"iat": 1772064150,
"exp": 1772064750,
"jti": "1a2b3c4d-e5f6-7890-abcd-ef0123456701",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"tid": "550e8400-e29b-41d4-a716-446655440001",
"exec_act": "fetch_patient_data",
"par": [],
"pol": "clinical_data_access_policy_v1",
"pol_decision": "approved",
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"exec_time_ms": 142,
"regulated_domain": "medtech"
}
]]></sourcecode></figure>
<t>Agent B receives the ECT, verifies it, executes a validation
task, and creates its own ECT:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://example.com/agent/validator",
"sub": "spiffe://example.com/agent/validator",
"aud": "spiffe://example.com/system/ledger",
"iat": 1772064160,
"exp": 1772064760,
"jti": "2b3c4d5e-f6a7-8901-bcde-f01234567802",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"tid": "550e8400-e29b-41d4-a716-446655440002",
"exec_act": "validate_safety",
"par": ["550e8400-e29b-41d4-a716-446655440001"],
"pol": "safety_validation_policy_v2",
"pol_decision": "approved",
"exec_time_ms": 89,
"regulated_domain": "medtech"
}
]]></sourcecode></figure>
<t>The resulting DAG:</t>
<figure><artwork><![CDATA[
task-...-0001 (fetch_patient_data)
|
v
task-...-0002 (validate_safety)
]]></artwork></figure>
</section>
<section numbered="false" anchor="example-2-medical-device-sdlc-with-release-approval"><name>Example 2: Medical Device SDLC with Release Approval</name>
<t>A multi-step medical device software lifecycle workflow with
autonomous agents and human release approval:</t>
<t>Task 1 (Spec Review Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/spec-reviewer",
"sub": "spiffe://meddev.example/agent/spec-reviewer",
"aud": "spiffe://meddev.example/agent/code-gen",
"iat": 1772064150,
"exp": 1772064750,
"jti": "3c4d5e6f-a7b8-9012-cdef-012345678903",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000001",
"exec_act": "review_requirements_spec",
"par": [],
"pol": "spec_review_policy_v2",
"pol_decision": "approved",
"regulated_domain": "medtech",
"model_version": "spec-review-v3.1",
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
}
]]></sourcecode></figure>
<t>Task 2 (Code Generation Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/code-gen",
"sub": "spiffe://meddev.example/agent/code-gen",
"aud": "spiffe://meddev.example/agent/test-runner",
"iat": 1772064200,
"exp": 1772064800,
"jti": "4d5e6f7a-b8c9-0123-def0-123456789004",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000002",
"exec_act": "implement_module",
"par": ["a1b2c3d4-0001-0000-0000-000000000001"],
"pol": "coding_standards_v3",
"pol_decision": "approved",
"regulated_domain": "medtech",
"model_version": "codegen-v2.4"
}
]]></sourcecode></figure>
<t>Task 3 (Autonomous Test Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/test-runner",
"sub": "spiffe://meddev.example/agent/test-runner",
"aud": "spiffe://meddev.example/agent/build",
"iat": 1772064260,
"exp": 1772064860,
"jti": "5e6f7a8b-c9d0-1234-ef01-234567890005",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000003",
"exec_act": "execute_test_suite",
"par": ["a1b2c3d4-0001-0000-0000-000000000002"],
"pol": "test_coverage_policy_v1",
"pol_decision": "approved",
"regulated_domain": "medtech",
"exec_time_ms": 4523
}
]]></sourcecode></figure>
<t>Task 4 (Build Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/build",
"sub": "spiffe://meddev.example/agent/build",
"aud": "spiffe://meddev.example/human/release-mgr-42",
"iat": 1772064310,
"exp": 1772064910,
"jti": "6f7a8b9c-d0e1-2345-f012-345678900006",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000004",
"exec_act": "build_release_artifact",
"par": ["a1b2c3d4-0001-0000-0000-000000000003"],
"pol": "build_validation_v2",
"pol_decision": "approved",
"regulated_domain": "medtech",
"out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
}
]]></sourcecode></figure>
<t>Task 5 (Human Release Manager Approval):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/human/release-mgr-42",
"sub": "spiffe://meddev.example/human/release-mgr-42",
"aud": "spiffe://meddev.example/system/ledger",
"iat": 1772064510,
"exp": 1772065110,
"jti": "7a8b9c0d-e1f2-3456-0123-456789000007",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"tid": "a1b2c3d4-0001-0000-0000-000000000005",
"exec_act": "approve_release",
"par": ["a1b2c3d4-0001-0000-0000-000000000004"],
"pol": "release_approval_policy",
"pol_decision": "approved",
"pol_enforcer": "spiffe://meddev.example/human/release-mgr-42",
"witnessed_by": [
"spiffe://meddev.example/audit/qa-observer-1"
],
"regulated_domain": "medtech"
}
]]></sourcecode></figure>
<t>The resulting DAG records the complete SDLC: spec review preceded
implementation, implementation preceded testing, testing preceded
build, and a human release manager approved the final release
with independent witness attestation.</t>
<figure><artwork><![CDATA[
task-...-0001 (review_requirements_spec)
|
v
task-...-0002 (implement_module)
|
v
task-...-0003 (execute_test_suite)
|
v
task-...-0004 (build_release_artifact)
|
v
task-...-0005 (approve_release) [human, witnessed]
]]></artwork></figure>
<t>An FDA auditor reconstructs this DAG by querying the audit ledger
for all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
verifying each signature. The DAG provides cryptographic evidence
that the SDLC followed the prescribed process with human oversight
at the release gate.</t>
</section>
<section numbered="false" anchor="example-3-parallel-execution-with-join"><name>Example 3: Parallel Execution with Join</name>
<t>A workflow where two tasks execute in parallel and a third task
depends on both:</t>
<figure><artwork><![CDATA[
task-...-0001 (assess_risk)
| \
v v
task-...-0002 task-...-0003
(check (verify
compliance) liquidity)
| /
v v
task-...-0004 (execute_trade)
]]></artwork></figure>
<t>Task 004 ECT payload:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://bank.example/agent/execution",
"sub": "spiffe://bank.example/agent/execution",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772064250,
"exp": 1772064850,
"jti": "8b9c0d1e-f2a3-4567-1234-567890000008",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"tid": "f1e2d3c4-0004-0000-0000-000000000004",
"exec_act": "execute_trade",
"par": [
"f1e2d3c4-0002-0000-0000-000000000002",
"f1e2d3c4-0003-0000-0000-000000000003"
],
"pol": "trade_execution_policy_v3",
"pol_decision": "approved",
"regulated_domain": "finance"
}
]]></sourcecode></figure>
<t>The "par" array with two entries records that both compliance
checking and liquidity verification were completed before trade
execution.</t>
</section>
</section>
<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>
<t>The author thanks the WIMSE working group for their foundational
work on workload identity in multi-system environments. The
concepts of Workload Identity Tokens and Workload Proof Tokens
provide the identity foundation upon which execution context
tracing is built.</t>
</section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+W963LbZpYo+h9PgaF/hOwhKFEXX5hOz5YlOVbGstWSHHcm
k9KAJEQhJgE2AEpmO57aD3Ee4DzLeZTzJHtdvwsASnK6u2qqdqo7sUHgu6xv
fet+iaIoqNJqnozCzvGnZLKq0jwLD/OsSj5V4WX+McnK8DovwqO0rIp0vKqS
aXgwS7IqnYQf8uLj9Ty/KztBPB4XyS0M8uHk9OI4bAzVCSZxlczyYj0Ky2oa
TPNJFi9g1mkRX1dRlmRZsoizLLpLF2USJfp9NOHvo+3toFyNF2lZwtNqvYRP
T44vXwXZajFOilEwheFHAaxgN4iLJIaVXMAQRVqtO8EdrHNW5Kulrq8TfEzW
8HQ6CsIwCs1socxGT/GreR5Pw3SK263W9DSWvd/p3vnpappWYVXE6Zz+PskX
y3kaZ5OE/loks9U8RtCV67JKFmUQxKvqJi9ofvh/GF6v5nOGyOFNAbCGj8O3
ChV6Iy9mcZb+LcaFwuazabJMMlxaeJ6USVxMbpKCXoRP0vkoTJPq+n8ZwA6m
SRBkebGA728TnPf81eGz/eG+/eMz+8cX9o/P5Y8v9p/u6B+Hw23840l0NMBZ
5NBwCS2Py50yWhZ5lU/y+SgI0uy6tord/X0d+fnTF7s6yd7OUEfLUp0ijegA
Ij0TfOPi7OTVq+MR7V1xmQ4/Cc+KfLqa0NGeyBfhqwLAjMdHeH18mxTrPEvC
Lg/T6/A4cTFLqlF4U1XLcrS1VS7T6+tkkOZbgLnlFh5mWcnTKB7nq2orh5Fu
0+RuiwYgfAyv43mJKHD8Pjo4iQ4OL/1VnjNe4PK6x+974c72zt7W8OnzF2F+
HVY3SXi8KvJlAqhwFheATws87Tib6s+H+SqbpPNwHq/TbBZO87ssvImLRZ6l
JSBbsZonZQiDx0WVXqeTNJ6HKSD4fJ4CECew5wP7w4n7w8Gk2gCIZFVE8+TT
IMGVxfCfrWSebgGCb5nFO/vHZ9H202i4Sw8t0uM/EaL0aOMedXN1ULzPAF4w
xKujg2hnePjqfDj0oXqJ/w13hn0YYprg96+SaVLAHi28yz5OV4XwbXg8TyZV
ATCbwAsToArlt+6zi3SWxRVgU9kOkbu7u0EyuS4Gs/x2C7CugA1s0VpgeVuT
m3hZJUV0sgXkS/9ysLWEyaPhsAVVNkDp/eBiEL7K8ynB5qhYzcKD6SLNkCzT
juD105NXJ0fRyYkPjqO0gL3AdYPTGO5tPd3fOn7/lfgFKLSIi49JVQL+hNdp
BpSNkQlmX+FXZdg9TWH28OTkqxBnmhZbsiwPbYaANvvRcP8fjzZH784PHryF
O1s7+/t7uO9pOksr2CoMwnCGPwMqpPOULgqSEJzGwqQEYMPDLs7ze+4QT+3f
oZ1oCP/b+8cDA+jS6dH5Q+AYPtt6trdPWJBM0wlscprcppMED/3o/Hdskgf0
D/xZtI1n/o/f47uz47eXx2+OT48vz3/yt/oOOOhlMk8WSVWsw4tlMkFqSHtv
3xSMjGSSPzDcoIQPy60cfmij/Ru2czjPV9PwLTFC2MNiCRII0PBXsJupXmjD
SctJWlXEYNMK8AuIkcdoc5whAkKQlTFxu6giyU1f2vR7BOjLDBVeDaIIBJkx
0pNJFQSXN2kJHGVC1xsOHDAcDnyjjNg9Prwse304ERCnKniCO6hyOpIPKkkZ
HgxU5HQ1r9LwguSh8Di7TYHaCiUhGa0XuNulizZ1ZNCGHIZjGjkrSJwBB4Dn
sLgQhJBbkBvCSbFeVvmsiJc3MAA8BcxB5InLj1YUDIAPJEU/XObzdLIOE5Ra
JonAYpKWzEMQ/6ysB5ItTB7GkyIvy4AFlSpnAONri1Um2AVLerlmQE3x1Flq
bsApEODepdVNU0oNJ/MYpCLc+A8X796GH5Ixn0bY/eHDZS9gOasPRwAnWbrI
DduJxygbNATTEI4MxMesgv8HSNwJ+lNXwIV3buIqLFfLZV5U7vZBADJTDAKC
+aoEeMDBIQvCYSbrCcAzJOADjTz4vheaWXDuIlkCdUV44XEEKuNO0gSgXRB3
NkdyG89XvB0Qv2AZsB9YVxJPbswRBcsc9sLnhJIPzAsHRODcAHKDzx9OLnv4
XWBeOSNMMb+fwe+rEk8PcbwEghSWICrggwXIHXP6uI5r6SLFC484eRBmyV34
+vLyLLxJYkA2YCLJfNoPzB2L5I71Q7yKdAOnzHHwJiP0cTKCczzPs1kJ2B0k
n1B7MDjFQ5s7ALoRnAdcqpuMCPl4lc4JA8fzfPKRTjaQkwWAw1UDEgBwzfIq
HMO1rcpkfo34B1NUcA/77vEjWAPBKFD0wmsVtMsBE5dFOp3OQQ15gsKmkczh
70/C0xzAwmQPKM/vJhlmyvDz5xbt5MsXJQKA+vl4VVZGyyOFjEgKo1R1Awrj
7OYRCGJeCZoIAmCn3dBRlKgfTBIkCfLHUPWioLFcV2uCZSv9vcnvzJLL0Fkz
HDwifg4PCqFAIRzwPASZE8Q0B1N1uZHZkYvlEW0iYjriICee4ev8LrlFothQ
jQn/Eosr8XQK17h0yGk8mQBnq+IxSE7VGuDy71l+h0u6u8lDkK2QWCGBAGWF
9TUzFp5YEtwhzbmLkSVlgHb0VyEE+DReAhYm0z7wVvgtISg4SniR/HUFNIiR
5S4p8L5WaQkXbtqgGSHRDNjuuSGOLjcBRJwUSYzgnK/ho+U8X+NB5Fm+yFcl
MyamkcEkB3oFkqFhCp4Sj9ePuH2REkEg9F6C6mLvkEXoEogKXZGEDjFLhBQ4
NNoyCCaUxNMJ/0Dgv0fTg7ti9FNANXxzAqsY7oD0IIADxEtnN1GRAos8OHGZ
xRhOPUG6BwsgujqJl3zIsCkYgDgNnjOCCNX+iawOn8FtAYSiC9yZ57Oy04PD
S+e0RfiWp0HiJ9J3NhvollgfOjoAPS8EHVC1OdiLoxfCbnQDMNyEhCxQv2Dn
OByiS5UC26jixbKVx6XWyDJfEzSIAeEBoIzHn/dldXAYeh2Y4TAiw1Ax3CX4
unuRMGoPh4Phdjfp9cxuTq129cpoEieOdmWVOKtnwZCfP6vO52wV+Ejhc3JF
CBJzrBSIQCFtD0Ud2TIyiHJ1jahCXDgXWQH5PRKtEik7C7R6xDgRaMoIAHvl
zNaORIF65yhQ51aBQvxjXQk2g//diIFWxSIgw9w4800MMAHcmSE+EUGgH3Ar
vGkUgQ8v6TBu+Ss6G7it8Rzv3SZJ1xVkQxVkiY57cindcyF3NHESzuIlXIvq
LgEK2kIps+l9ZFGmcAi7kpRvWZCzi5JDZdII7wM1SgGl4bjpiQiwOF+dWoro
lExh9welrI2IIXzMrGizye3Ll75wFjGWwjdNaRwJlBIIwJoUUQiXQuJdcQtT
s0QSqFQeg3IJvCpLywV+phyE9uyQbyEyrlgVxGW5KhDp8DRBmAAWBtMtwgsU
x/EjPOMiAck/L+h4EIogJeFuxWCDDKTIgQ0wVlm5WHYWCMkDkjq895R8mUkI
hjkhVgcBcwB+dFwkB4IkwVyuDDtkW4dnaam37G/JtEOjwoD0vXmH0QgWeYmq
y1/6ITAT4HtnfNA/9XFQELLwZrxbVUD7wv8YdIJgByZ9m6Oygrxn6sCdoCIA
aBe12RK9Sdxm1olghdNEbia6j6IFHM8uT942p3eoBCBgHB+JpgDGs1iGogou
ocjn83EMEqtRxnAEgBbQAaAQQt9gvmMVh/Mx4p1cNHg5ByJfrmDxKFM4iiWq
v/A+SGSe4cCKjozOPAxppcl4xeQH8VsoIY7AmGBkmKbq6eAtyIk8LzKWGE8f
T7sJEea0fRqU2FYRJbd0M/mm43PDj2F1rjzO/K2cAEEv0lzuysUEuBd9eoAi
1EQAtIEqWomi3Q5AZoBeyJpn2P38GahkxH/78qUH34LG5yh8pMsg7ho9b81k
CwEBX0/jWQSol7JBhEcQ7IabOvnI6GblCfiEMTZi1Zi/OBHFD1dL1MOSckOV
jZyFfPrzZyZ9qf2QRzrIfH0N/QfAW4w6hp+iqSjiF/gjl/GhYkgS5HxFC54n
0xkcYb6U31mcJJJF63CsjhF9K+ugk+SPSa8truNJEnpSLnwto5sX8GPSrq7h
9rD0jewerjMKBqXBBHwItxN0tSlqfQQqOnmjDNWUJVKvFZSE63gl8Q5E4b8T
X5L7pS8v4gwoA+0T8KlARWyao7QSojQGAmN5Y+x73ruHIOjiPACreXqdoDkh
cd9AlD5PxMZ/ky6RKpzbK3BoVYKgVR92eBDS7AlIAS2GDtgi4MWiDMayXTpM
K4r3W2iZ3EnL+oV9q2YulAJGBNAC9s2RHVhNu65oA2jWrco2YME1KDjwHnHz
yr3GcOUPa8MQ/XY+Kaz110hevtISIN8H+lv2jbxFnAa+RidJP7Q3lmnSDD1j
GU25AMUJXwrGyTrPWJJmvCPrbd1OJeqzs02z0jKob47OEnEdCMmUhVJHYWKi
6F2RfkBUNGc7mkj8AB361VhWVFEk2a5MHAARe3ENi0yJJ7QZGtNTygxhIzGI
yFRgGStvda1o4GkebFhb8wpxMzJ4YAc3MkU+IYlmSmwtKSdw7UjP0U8bE5NA
CJiI+gWpz+ZV5t3XMaAJeqfXjpqO+hkZO1XLkZOq8CoDFsLBZCi9ASCQQIqh
krdEHkkcoOVlwgcxovH0sWAJ02KkL/xaMAZxDYmwJZmumo7MDVkTapckHZDX
DJlYypoP0cGPAPA7Uow6p+8vLjt9/m/49h39+fz4z+9Pzo+P8M8Xrw/evDF/
COSNi9fv3r85sn+yXx6+Oz09fnvEH8PT0HsUdE4Pfurw9ei8O7s8eff24E2n
cV8JpVmGJiIOwjOBvAzM0eI3Lw/P/r//d7gHkvu/nL863BkOX4C0wn95Pny2
B3+5A2rNs+UZHCT/lQRSkHuTuCCRDUX6eInKGlq2AfNvyJ8M9w2g+YefETK/
jMI/jifL4d6f5AFu2HuoMPMeEsyaTxofMxBbHrVMY6DpPa9B2l/vwU/e3xXu
zsM//huInEkYDZ//25+COq+EA1gwx1iVLcQVOCQJ5qNghIKCYxJSJbDPl5Lt
uMpYSYtvtVXKrRUpvyRJiX0BJGA7QjXK/zQtctoJIgmoAilxdSuAC0cD5F8t
SAgBhaAUnQzVBNLlc9ITkLIdqc3+QGz231ubPc/FRnwrzRnbPQFrk1h3hwiF
hiGQTRia1jtAAmxITF1UNJLg7xE1eSU198fnzxLFYgynU+arDT8Iae+hMY/4
LiD4tiJbkCXYbU4H1KFJHntD4pYe/xK3HuF1A5V8sVhVZEWZ52T1wrtGrKNx
mgAotHwldHhGne4zyqHA2RDofR8UfOy7YQIRmA+NwMwwc1Q1MzedDTzYuFlQ
TAy4xOCHI2S4GZhqg7GcbeU8LcvdEyvGEfNEcm+uyTelFSYNfIhZwNwsJrpz
OVZ3Nrq7E5F3L4L/LXO0z4gxB191APrXFUid0Ty5TTB6y5dt8XaRfHpEE3ub
yAHey8rH+zjbYONdi9iGp3sTI4c2m0xBD0RTDXFhUCTYJ4hGEIltAozmP3z5
gvY2R15GQKQVsk9eGUCrmEYYXbIOZXS69qz9qvGrwuilUq1aViQNCTfpGvQd
wTaeTlPZTM1ehVyWgXHgGsVcjevzk6YyRWI6f+f4u4PLdhPbJleOq5M+4KYh
GJCJpR3PYOc+pqk60u2chPGCIx7DvxDNd3/+qdNzJ2/xEDozOygoos6yIAEV
ZkdJJC7LfJKSUMWoQoYhXIFI3PQNvoloK0uiBZDnILrJl3XF7DaNWaa6x/XU
wn9851OdD7pSp4sNYvNDkk70iORoRPwqD6zK7auZjrOIifQG1xId8rlR9Mmg
JgY3a07LjXqfFp5xDm1G5qjdcR7hSgaoIoTFku7reU2XC7z6Js0+4mue3Qrp
jJqsjF/AMVgRb6drcWzsu6foRRYVg0MFBIQAJrySTG02nsY8XidFoIZokqEV
pPSTEa1jNvzQGPQLAPu///u/AR8naQqXrQr+Nfrqf/41+E3NpG9otq7ezF64
8Z/f8CP87HIU+hevy6GWo62tarpFB7/1qddxvznjb/iq3X9l8KPftaWNy97w
w+3vhhxqTQI3K/8ceAfcC38mGx2GLf0iUIDPMADSijGo+7lBFKCBg5bng5v/
8a8CuVKF5yu77+hX/8Nhx3KYQTsje/G1b6KfgKFzoEIZy25sRIgdU1vH++h3
LQ/uVfB5FD65TmcR3bWSg9G+M4Hzevs9hkp7KTtfxCzr+oBW6nYS8uqGoPSF
bpThDx9UCw84EsBY//EXGU8IhyM+98UCx8SvFI1FBB/XkOlyRRYyaoT8OuUY
gidPPOngDKXQEoQERzyISDQtYbMHJFjayJ3yYfutCdxAG4HlWcau55iwYeQf
3pkQmbDzMQUUB9EJRgJVLyT11tibmF+vxnBJhF3bfcHs+cKaTL5BOF0O3Hk6
IOJ1xM5E42JclN1GC6xgErWiGynw5MgRBHveBDToOAldT7wJSxIxg1ZNYi8w
5DBUL7i/8DN/4cYYM5+hw/dmEXY9mMFzB2Y9WgeMDeue8ALsh1ZpTmqSLkPr
A7Briv8gKr2IP7ITlgzuIqPThcwkxmVGTg8crULnXsAhjSx+xEWRmtlSlPFR
7yP/eSPgqmywO3rlXKaks1WPG8zPf3yJoZWNSJoRUoY/otRm2c3Bn9w3neia
Ebx5dmn0nwNlWSWeE37UiAPj4fFYCl8SQr1/+iePuDhuCENiaF+veesXFYgi
MEBHxDsYMUlvrd2tK/vsiTpJFgPW4o0P9JLDn2ATHH/F0kNvhHIw6hoY2uP6
M0neYOMiO/EExKkTyTRg/yRusuv7u2FcCc+XTcvI5PSuebg5D8ayMusEx31O
Nb7QGhnQLSn6OzrCiGYiasnmp+znYX3JZQmkAW2yULziC/z5ieMFY6K24QME
RGssp0uTA7njsfeyyVLADy7sB/ugKNnYL7T+Y3TvBWwrnouOCluHT3go74dQ
LXxIWYy+jCySCTlRAsGnz09+zUFzEMcX41SdwtJwiOWxkAFLnw0Jkdv4awkK
4Wc4RqIwmJx2sbP/tNPHJ9V6iU9spti//npX8U9IwuEnDliII7hIUTqNhju7
neCLfz14RXIxzEJlM8efYtRf8G7A9KhZq1lT7NyaFVAaqNfoHKAK+RsqBsMA
szNw922EcTNNDMMTo0exzkCDqEeKYGJO+vmXL7I6ghkaggD/E+8QOxnoUh14
7WK9wBh2dELrOkBjTQazQT98jcMiOF9f7D7fw7/vD3d6DWQgaybJS+JUgb/r
qGjkMGkzhDUwcVQkS7g6alaBY6xB1jCxhCh9/YTx2ZS9+au0vOHwkZAJNPME
lGUwN7Dsk50T3jURI5bZToxXgBzkIX3h8H2CGmI4IFPL0ddYvwoIesNYRGCV
AxaGw/tygTmvZ3Re70XvFUJTkFo4z/OP4WophFKcM97QGPlncK9m8MObCYA4
ZKcLXMy7Sv3h9l4u4zVJHHIdy3Cca1B0hJorDEZRX66YKAKkF8FUD0a/195K
i3uCvMcOysus2xha5vXMuooqGi2eZgGGpq5JAwqClO1hztFdVGh9fle8Pz+R
g2Srm0kbObxELpLC7ZSx5egca5EVwwz9QpoOL/6XUU//SJJwxJLwn7b+CIC8
+dN/0ZRpWacBnXI1xovKgqGsxJch4Q3cifoqWncC7/yKCGK3guwZxSkBT1/J
D1zUmHViRyLVxfEqUhXrJYCE4yYRHVg7oNuEpzJPxwWFrhJ3dQJVxWuBAheZ
O2mX6mTNnVMbYBps/Y4520OrCUhyMfn8Wg5QfL1skU6XGLDYLXs+GF4mkxiF
bfblog0UyRYhO7nUOEIJRdakLOOZWkiJxYtNh4XMDjzTXYhTymFlxsDEd1hM
/DZQkaKXU3hkXLm6wBM0uy4x5yYlLSNFHT3G3B14/gf43x9IR0LTHZvsQa9L
EdX/8IcROfLE/I4HR1eB6WHGIpZIc2RLppBlDB3+VKn0LJtSGlAZs9o3LEI1
zXHGJe+Li0ZIlI2ZQC3EobsYhba0UgFKAleAeIyTm3h+rSfGN3JgNs4uKNy5
fGEzwNs2jz9WbOyDf9irNF+3SW3K6eJrJPhx+GtOsm0YV3bX5BBhOyaSrl4L
sHQnjiHZLp5tsjgrqo/19S5QXR478iXQS0JKlY2dYzKGOhPw48QG6LKUIMaZ
nDvdG1ksJXgQyjs4yjDgt//z546hYAkLPwPYu1jacCkdebP9PY6O3BIzyX/+
gokPx2g9VbbG8VqCVBxpAWo/+petnZc80aXSVtoAgfMkk2BC4NGkmuBx9Wwg
m3FbOT5HCjJwBYSFBtfLIGw85quN41lUxuh+iuek/BwYQ5wDzN75a5rp5IgW
24FnHSN54VloLIv9nu5mRRbaQp07OBxnaMdjtFmOYxQFMCCDtqMXCakGjEBx
9nTx4aX//3//P3idiFTbMgByi3gNLMWEhjrJwkV4ByGsRnbfrhZwVJMj2LrG
cqSLBK3gzBTNcoB60j2doniq0oQ6UGO9MSYwpB+WuTCcuJJlodCE+dV4OHQp
qhu1MnI0Cp2ARDnyC75jdpzMYhQmgMk8uA14JxVjE+3I4Q4t8rVQdpJA8Qjh
nPbxX8P9cJFm5IZnokHb4eD3OSZ1yR6WoALDkWVT8qZiKkOsIg37GmNQbMga
OcGEK5STPwKWiBd+gu4hxA5Y6IBFIk8Q6mTj607YfQtgeZnAeEnPMm2ElZpY
CPHHLucT6NZPpzSOGAraQkd1ghJ6Ml8HK1BF6KglnP/XKm1l1RTCvMpS0OU9
m5hkRrMBL3z//uTI2rRIlMOKElYGZvAQ/KZJxZkSI+EzSK7EslQkJOqw8/wG
VM6wAwvrhDeoDs8BvlMgpOjwKCn8np16fAUcTOAT0ktLAzjK0jjR/UjWTkxX
kOZk3JcwPTavEdkQ0bap2YP2D898AdzKuSLaUhjEfZIzSAN3rI40JEGCv+FY
zgkQmaW6J3j+c/GD8S4yVyIwkSQ1qdEyFT0+/9zYYjcujSGuU6EJlWFHIV1O
uB161ilJqwxn83xMHjsBLzmhYdVFYq0qVUP5cnZrBpBjIvLg7PwBfCPORN/Q
BimFJNaxeA+EDUggaI+gicKztLSQcfaIR4U+zakSdQXnt0rezOcKK+drBbEk
GE/N3hBeFjwGLohMV3B5NwEH0Usy6DS4mvRbBzoSO4bhuaFJTRDmZ0P8RETq
CFm6AoURj5HtLBLimVyV8XVSrTHGbRLPJ5QzcTXNUZDu9CjSHzPhK1e7QG6I
gjsHFMAZYtWbadjRjXVCuKM3jL4AOnqCyHqbp1NSRuZzzjUwPJnf6R5g3QUl
iEUyQ+2/oPukiIvVZQABggCYYQ1+B6pmlARIjMo9c1i9IzcRDXICPjCi3fWw
KX4lzFecO0RAIwMWogNJJTFi1G2ar8r52qZz4JS4pixMFkuUjGhxQLI40wQx
IyzyXNZGcMjy+iIcmnB68JNKgqjomDRDHaIU4iWRQsfWG/75iR9Pv4F8PZiY
DeRridV/NuOsg58aHMGjoYgk+hPZdY1VVzhMKmFbRpztTOYpBXNfYSoFoBSj
L412dTvsoOME/nalmSP3rQqOGaBVW5EXtCtsCQ4YE2DlRRG+HCRMjSlQoXyk
Keph+KP7erGWNIZIFxjpD+j0QXE4pcApngSRAatBsNrRoTSm2wStoJdtK8aU
l0mSTCXajrwnmGjPak/sJh3hraPLT2liPDxz33uGv45B5uGsJvuyCMGhGCHK
ChXhceL5WRsqGp5uPdqIxhCnIKF9xz1IErydWRHtJbwVN8Zfixws50Gyu7Ux
xKhEluiVYFGZM+ApZJZNIWHohXX0TVAHRU4joxP7ptyrkL0URnqBf9CCKmDV
qwssam5vqyPmqkYQy7J5BNo9iz7+9uEq2O2bM1tyjYmrm9Uizq6Q3CR3G8/P
5vvi2zzfr6vpjEjZmGROXb0wY7u/xtZEETcKCrtc4EDTeQPUSg9p3pBXKfXM
rHaROQhuk858E6zSg/qRy60XPls8aFQzeqncaflbV5KSCR2AW4I4L0FeljA5
tEIX2WKQE1UDRXRrWGR5RdZqkpNri32MrlabP+DbvYinyUYpT4yDGJUUJlhj
R5kwi8+swLHFUOIQ/GBan61rHi3dHqvgcdp3cE84Le/IOuwpKoz2ZdJ74UAD
EZf7fvJebhR7slKbI6nnOQ2IkeH96VgVCmM3l3FNj3GxS3KCC8yC4R18K+F1
gLRVOmF1yq0VQ8hjXZO8cAwkt6J+simFoamdLmJQy7CiSra2hWlmGLGeF04I
hIhu784Ots6TWd4PDxNQIfvhXw4OT9/0A8zTXpUVXLcynxOlKXuaw2I9tBui
f510EBMG7DC3mheALBsiXRxhYuOJSeP4/ATZc2TyOh4QMTTHxuaBuF4Pk0kY
OGHtEstOpAjPHohKEs/VUcN5llTQhKoSLq9AhbzZrGH5qZv4rjFb4pQ0Xt9o
HJymEXbwvci42EZI0Z/urYp5BBiVA+wifKHjCC/lTRzt7D8dZXvjP89+ujm9
/vAhfhP9dfbpx+LPr+J3/3l1+aksDvdOyu0fh+Wr8dHd4WzWkToj8D2ty3Et
Wjy2cigANikmsBLReTV6Bc0hB28PwrckkJ9onUaA7msc9cCMem4EFdERZNEd
s4Pd53sdeb4/3KH13evJNCMEXJHAoY3mJ2Acc9SYYpTR8wxlBGejLJcT85pu
mg35E4qDy6oGJzJEJfFHJXgXrw9wSt3f6dF+n54NtaALfW79RFJZAlDuNmGr
RxHfhTnw4apsYgncB0DH341ujNYG32oliEThJbOOgY6XGIpoqeiOUgL+GS5Z
WTrGhvZVXeq1KTEig+oprEP/U83OCmW/Rosk3yXpiXl2nUrwP/4duBB6jFFk
6QmloPjF06SKabLPT9ws2MdRCSdiXf2TVKSTaYSRsEaiTyP7vFqUtX0TrQKl
W+2IJi1kVbh7FQ2RVKsUlVMgixnlddorh97vLJlxsbdUxg0CU2bgamqyCzYB
3sn7kOBzidtFYyIJ0HQHRHcUlUJX0K6J2AI3nNzQroqYRYpT01NHgoACDa/Q
RPcA5sgrLZreAXn6Tt9w0CLhtKgfbI0wUO6H6bWz7QEaxSj5ASA4XtcmP2j3
HJ74bjonYQKVS89hpz4pxzfAaCbZFFP2GWEyhQbVVR6mqCNADsUXuxLXSsAE
j7feFAfZkKKLcl21yL4iuIBJUampwxhdyZv2baggKsN5Sgsl94LkmU7ySOJU
0lJt4q+4rJCQWK1R0HcGUis5edxcH4TEfXC8VFnz9zGkrPcjLbQoAxebLJOE
LDUyT8Tvc0goYYbqv055DrcyE1LDtN2ej1CVYUNnWBIbJljIZhIj3vl1LLiE
Dvw40yhJqn+EIiTZTSNNkOU6j4wbiPUJWv3LHLbiHA/ugjwFUk/AGMhLqVMt
qxdCSsjpn65uQCZiWnlYq44RnmuawecnrqpqCaf79EpZZu3uvMzzeRJnBG2x
OpmyWlbFSlnFeiDRgTV5Y+jiy9BYBvpFNnND0gojtO4TuePXDQTdochs6thm
vCCRa2Q/Lbsn1bkq2OIrJNDBHCfho9WB2lHjUppzZvhVml2x1nlVFaBydXqe
UfO6SJKICRsXGyc8ywA5/ubjWbIYJ5zooRwXuYeRyxjX6M6QLC1juAhGob+g
JsxW6ZT9OHCkTTAgOH0D9wZABRaqDK+ATbweDojHSSOnAV+wIgqWV3Dcp6Um
JwVshLGhKIlbj8DxW6L6w8b6ZUzpQkJD7rKgk3xadkgL/pZon+PqUaeD0CJP
axBHHeijhmiSQiD1VXJyUpPZlhzUpTHEOLsT95INB3VzeEpy/8hf7BXEWF4f
199RBI8YfU10f85xPVRlhnmvatyG3kjFl/uCrhrScCAueOEBVDWI/IzO1DI6
HTZQ9Jw90qT5izGeAtGMOb40Ja+mGB9AQJJ0gL5TERa/QYN/acPgUS0rykSl
GliR8AO+XoiIAxNrQHrrFcVtb9YqUM6HkYNVhhYNjq+wE1ufIDodqo5AGVEv
JyqFfCwes56NICGv7G0ieaMlXNK+EG6OlYXRMXY2MG4BTzp05whtNjuNC1/u
bb94GozXVSImC/yEInEz4ZXAW6ubTYsOmgPuh5TIWrYAR15mE2HgulBpSBYq
eBitdkEcS8J9D8V5TBdFQmTrcnjqxgB4gYZyhPXwXgxDG22IKuHoEzXni3a5
Gn/V+xgMcf/76sJSE9coHD57trP9dG+4v00PkbaYh8/kIfqMYdxn17vx8/HO
JJoOk71o73r/afQi3h5Hk93pXrJ//TR+Nn4OQ+MXdxKbvD0eTnamu1ECb0dP
nz1/EcXjyTRKrreHO7t7+/hE4pz5g/397eT53vZ2lOy8GEd7w+leFD8bPo32
9p4+3d/fg1+2hx1ZqLjQRqhWYcFhkMqAAyVxZV13SGxH4c+/8KLQADZyXCbM
CtBcrDxtp6MszlqaR44d1vyqltWN4OYRzflEbLqyAxhzp3MEe/u8TqOwjh40
kbRaSGgS1brdQd4cxtvxzq9Xn/Kr/cX2++evL1++fPvy7eGbv7z8OHsWzaKf
lkn6/Q+L/ad7giINdZkA6Gm15jBEsYQ3dnAn5EHxVT78eJFMsQIRf+fpU+7Z
ROZsotu9wY7BKqsA4bkGm4O0yL2yJbpLEQ2Rmf9Si4tHy16ElEoi4707fyZX
2QmPfxK6SSWXphDW5yduHSxJbK2ls+hXr5Cat1qU1YZM3Ln5eT2TJ2A3/3C4
reJ1o06yMim2EkuMjTuG2MRSG8mI5bU/XGjqhJ8hEbjxBZxtodouDSNR6KJp
YgnCl3ULIDqjK1TkMAKdlTjUe9N8GnY7A5AcJzcxRody+tyB5keVUjk83pgb
pWG8tJNmUWndtakc7YTINxKbArfOsVciWFKMmKwH3x9fhlvxMhWiGlHUHx3U
1nAwDF7nZTUK5TcOm3EQNGjJp0rWP9yMv5+kg8EA46EHg9ZCxf57Z/ReS/aU
8xKquvBSI2NKluNlTGkmGHnrECMYbxH9SaOvhxaydEvZXOSWMCYoN+ZGTq0f
mK83nhDj5ZxuAvo0qRoQR2izFSHAfLc1Y4Pi0YOoa11NHMZjQq00EA2ThR9a
GwgtaRWwkAj4eJtOORVfopzJxEFCgJhFTZkwtJd9/uwK43RzQDVB34bAiNyC
VIHFfZGEr8CsVtI0SbxyAokEvhohz/VUNNo2qIdx2jgvBcNUtRiR6UqjaSI5
DGRAGcfLsI5vYcmkpqp+WguW/qYMfN8nJZFhHMmPpnIauUe84odEQ99JjyGp
CkA6ZBzeV6pHokkTDXkKbAU10m7aNLKwrpEhYVYdWAu2kqC3qcqdBISgCtuo
f9YPnJrQUyyWaSqOZjyLB2rrGEcaxIgVSH1fVkpRaAfRBFBWnEBS4tv4p8Rv
ba1UGvSCMLcgpmp/aC6w1chnqL9UlJXqhY9jWFdgDrpHdkB511VYDS6lGdWV
AvhuJMRl2E3F8GRj/VEYwPUE7aUgLa/RLXBA8ThBeGmOMbobA8pxQz086TC0
r/FK5mGSil3ChuWrWYownFceuLuyCO7p1KL9ukh8jqsRAuNcAnOO4lOlSIu6
5Y7utRwFqedWyagdW1klSy3Me8k3Gpu/SIQdRzpwzJWTgG1jPL0Y0dC1qnOp
kq4b0+fWSgZGTUK9VM3jz4X8GGiT0cmP/+sJoXPCt9R9w9IbrVWDWbk+bt+I
I9akz4EekjAr0WpU7hZv94g7mzVCI8UG7Ma/BDZfQDI0NRGRORYHEVLMvnv4
1pFAA/Buu4JPTlhb3U1s0UyvB30vV4SMLCYrwqJdz3IHl3hLoVxONFll03vh
hEm+l8kCBEKsRy7kSPDDiU7nqvSFP5EJ4JEMyBnFqNsAifoIRMKktjQNsJyv
NCKFlIXZqrBx4BwFXuXzhGztYdepYTcKd7dDcSr1OAbqkg+jTxyGSDsvdRT+
lwS7wGLCP4LomM6n9Geuv0FzXeFcV2au/9IQEjO5RF1x3qZdHo3gy8/fYhaC
KXY9W4HkASSNDKbpBKunrkpsnSWQ5lMiZ7Nqety4BENSDv132RaZLuIinZvu
O4woEjThVxLuylkliv+un4tQs9eX+qo0iF1BO16xKTeR+uPMmeJU4pwDjcJq
wbE9tOExGyYB9pUtH4gYgc04HMHBYcZquaLB53D1Q7KhC4l1UembkkmEkhEu
gkstYipaBqfq3HMR9i3BqEUjjtqAQbH1NRMATeHH2wG2tAeb9Vu2wJTOBv0a
GXJC3TI2htk5MXa8TZjVjRmz1v+HQgCY8QQcYOYE9Nbj8VB6TzMtlsqyMkNH
d9GIwkNEcywkGrngQgFP5kYKFWxySkgetBjan1KRcFuKDjMMOMV5Anh25spx
YuhDMcB425hIY4iAV8EsL4TIuw+JJ3HMVRxeU/NE8a2EnEmQSnVlxAzKtjBl
mwm/njTEWRM8UjcYLstkNc1REzblaktzvx0mbzQHqdZhvwuuVxk7mkxUOojO
XSpnC/+6otvfb6V9PazisbVlXxs53Anex/AB7Ang6g6aVQafXYDgEQ5HjrDB
aW7oybu2gw40ZRDXNKiwXAX+AYSC3khACjQMYFgUedHtqAjjCwCdXuBMumMO
3BI8sh4rd3NoLrmB2BmVEhPGySkC3omH/c5Z7iypuuaDHjNnQ7EQu1fzuTaz
85fuhszjHSCWPAo74b+GmwYk7vQnmp4ZVetBPW46L2hRLpoPt91ReEjU0qQY
gSxPAlgRo8mNyoov0goXiUXMUVT6Du9ht0fxRRQN/h2i/RVRXf9Elxhk56Cc
jCCZk41/FvGnK6r+D29fmWkBMjIPFj/BjbKopI+QGrShzWFaYP5F4RddFfcB
p6ixaR8DbYLAfE4B4SVI6eYa2d1x+8Mr2qA5wNLdY9vWdNu0QZqf8Bw2Jr8M
0IfS7eGxm1fatnQaf0oXK9BwBUj1U3I31ILndsUjH+fw9+++C+3uauiFIG5+
kWa6fn1dOAO/q3uLp9P67fk9dwzQ2b9nDdRrHk4dATfg3YYzkrcfj38OxPhn
i1QcE+Fa13xrhtrXalzizBB1LUs0qd1WwQDhEQYxuBQxJrRwQy/kdzWRiUGk
4cVsXfjE1VfDd90f1VDyo5h+pbE4ZQXoLBl1byhQ4Gb7jpb9ap3KsbQMOKim
Wi/JC2675BDtKW8oRxQ5XindGtMySLQHk+eYBFBkaTzHirZayBONNsmnCgUj
CrsGMpcXmC2YyIgbYmJEqMZWLbV7FtTvma+ODLfhHwaGaGWk1tGbsHCCj7W6
1E9Q7TqOSmvElcDIqBudl8yP64My/pUBhzwY1dPwbBaLNI0MXp9i1dmsshSF
fJxOFSXkpmzh/tGNGPj8xLNZssHDfeFM5ZR6QTNRdktr8Kg8G0fo2TgCL06B
LBz1+lvA/cTAs9nGiwaeT9TQlV+0xZj6QpnWUpgctmsLyuAZgVqGOiBabl3v
Blsbfqw1JKCaTGqvtqV0MCGlVsRH1PDGAFRIrm0AkqWpbBG3GWGRmerGhmWz
ipGoYGb8ROr6NYZ2VK84/Jjld1nfZOiF9TI+UovX8cLXijCjRnWOS0lu3VKB
frUgNhnRcqwNTE+Q5XNzBDW4h9o7bn+wI7pAHYRaqm/TlCirkwacJCrJ3wKC
TzfuaoMKpSIua5gw2zclDWVwFTbg9pt0x/yGituximvbt5ieKxItPEm4WSFq
gs7IaLrqh+8OL86M5ieRkjzFeIUta8LVEnUANJUEz2qY0I5kVI9HOUqtKpfY
a5rVCp/XhnYKPLrjubVvxCoE37PFrVbu2eKqxR2Y6EV9D7YMjVeKRI2w33BZ
DdPXlHi6Ld7C+cw0CGe8kOGvL+Uk3M5/bqU+Z/BGvY64pNRHiWT9Vvw8qE5T
JxQ+KnZLSjEUzY80liMuVOAndMTpfFUkbO/6oEUiTDkR8c+6Vvm+Y11kIHh7
Z+S17S4IBgDf4fbAgy9Fkkl8rYl9VE6ld4jiy0jVHQ79z22SlCnKkJmqD0BM
eHKCUVyy4bLrM2gT40Ue4/ImnwN9dhiwYdcCW1uaoicU8t5pr1fkxaGJPbae
Yccc7miYOSbHMMYLY+P6PWQwgg/1wUT+yrbDmukQ7+JwxwCK3WzivJFAsy5F
1PTZstV3LEN9NlL3jamFnrgWlx5ld2mQJ5V6TObziH04OPOumblpqpGsXdda
Y01a/VCyPtvtWjg2MJszYeB1iwVR8HoLM/wGmMUJF4jiqjgUzyhtKX1Hk2tw
N/ISrcjITPdm0XK4tO9Uos/JsbShwVjfvWpTLa9UYDOMTGywZBsBvBqb1D7X
wQl7FCtiQ4phf+5mK73GwAVy/80L2OJTcr55g8tVscxLzrcnLUULeLkxcZzy
ZUKXzc2q+39NO0gbytnn/GeWup2gW2qxMs9LIk4s4+FGGsSrxDwRBIlXwNYW
eXHd2DbBwITosf+FGAMNsLe9G3ZBiRinUyBoPVTT8Hu3CKst44JZyzYNAFZP
j1nKk9GGQfd9ZpO9dUBT9LdZWZB3JZlmvEAg2uN8utZVS1QCCEtUWxjgzPqj
0FFszcypeIFNxWMrozmYdoQhheDSRbSAweWnHYuJVWBtityw0bZ+SAFvp0WC
t5bFzZZGIidXgLJoAbr6FTu0KFkEhX6D5k1iisR9XQF3h48Y19QOySI9C4Nd
kdOtjG6OpRd+hxhcJjixLkDtXELp+Gs2u/CfByCjh//yXUMi9ywvfA+7nRNG
GVRZraTEdiM7IAhLaEcR6RwPurwyInnXvtRrnQI0pZt0TCY2I3UZa90bqYBp
RaFAhXKEHACgAUyyqcikH9mogiYV+41nuqwt5n1GKkCtumenBlRzAjw2slnB
BDiAK/Nr4+juMcSEntjfd9bbDjU9GPNJfY0U6EytZ0m655XCwcDzK3nmQKnf
hGP7vBeOdmGs/jJefQlWiIalzjKp/gN3H44NTVbwpyugpzhb88Ac3AJkhVcH
VIK3ZUk2IXUBygMV1SR6CTSxviKp9amSOVJNKZopWMIHNYD3dFYqvNl2ADyU
kV15YmfEBjRE6hUTqKUS0ujPTE61MFtmRMrFr0pvQ1P4xJS9rM/pyKj+BuEh
+oVZbKPw1G77eau0K6M0ABpjoUmQTsnr0eV0iTwkWVW2ZYXNXg3I7Jv21hBG
bA6fJVdG6t24LqnBhROSgyue5Z2WOf5Un+M+38Lmabyt1OFQE2PFDK3qQ/jz
o6Ra759WEfcXY8HmoX3MqZmvdQ+nKVeT89fI7hj6o9mL+M1Cd05W0nyoer/z
GnjqnzfJz+2C8y/3krbmKjqNlaKs3dWQK+uzkyASJ1rJ89t4DkLDVx9jMG/1
HrZ6a1q3VlMNWKYxuzrwNQG9sy06wEiiA0i2Z8Ff94GrSealvILCRDOUbCRS
vMrvVpZHUeaKbKsDAoU7quyF3eaeUd+T1pxa6hvkKQ4Yd/shn5JF3c/wZjVE
IhwlJI8rZOhlxDjqvNFVmf1eVF+E5XiBGpctRtHXS4MXa8zG2htwKAEPrHF0
5DynmFSbY+9BwPioyQiyDjgTCtd8k995gYExhSeW+RyDA0VPqOEIFtBll4Tn
eaZP6YjE0W6Omf5AEKWyXe7hE0wBpA1dkEDX105apIa6y3Rq6AZTEI9KzCVZ
6OvoeLgnQtgJzwcx+20eTuCrQhKmLG47RRsum6qkKSwcOGFOEtvsdsils5Db
beMHlEAgNkg8Yz0u09UYtKwNKcdkDUsrDeSltjGHGCUc1fr7Od4cOq4s1wZ/
skl24FNnsNlNdZfgvx280+9AxyxiG9Hkhh0BRYjC47jAjU65WbhT/lYcLaY6
cG0YuMGGfgTBG5OCTFegBR1op28p+V4r6LPGjUuZmyocjAP+KTB1CbjIJIzy
PdUyDOtlPTGGBCOlAf/RZQUPuAQn0R/TeS2Q4tV0mRggmY9EjXKTbJrm7jUO
qnDU1awwHjdt7NZHlRXNZKqnw5xiHkYXNXWbL6voJp84FcElSDl1q2VhGiTu
TdNMpPS/uR0MLWkQWyrxwjC39pBfCWonWl0PWtfIb4TTHNbOqn69KIUJX8JO
FFxlpR7uDG86l1rugFOzTLR6wQOmx2r4adphMGZSVO2s7a4HLh+TGCF0weBF
kY5dQrum8liqfjvES39RXPeoF1cNdj0rUuo0up7jlZPGV8v2auriAuOKBnKc
ThmDOAs8wxwXAfYAbRybXBVCknhAeaU687fsYrT0BSScfLWcs0N5HlEFr5Ya
cOR9Egi6DA2OqXacwkbsp9QZzJOI6Ay/DTHJq8FuLKlsCb0HKuJExRso2Hrs
WrLYLQdnzEEo3vgQJTSRgu22IERgjJaXNk5YroIaURN/hbgLLFQc2KUwbr3C
Pfp4RbltDZwiYHj4xMG/dfunUxrZmFwDwoy6xbUG2bRsyShw7YxiApP+rOrY
IMtcxRVjTBCrZmPAeeBbnlcAN+k0CK4VxxAmY4l6P3DvqEPhVToRtowim9vf
mMriFNfxBEEq0Ez1UT1L5X2ZcARFw6ztLn3zqgM2iq9dMY1XRlfZbibctJlB
YKQmkOU4O4WbULhx6bBA26O5XoYysN2VfXmP+0IrgwBZYA3LMQkzbiZj4GYy
zvMZhYEYqJlEIZkTzbeOfQH744I0a42kiApA9EJMGs1yGG7d5qs9+ImS4J1G
1Dhz2acSTliITJihX2kKs4ZTShcGCeMGBiz7gVthj5dYUs4DpWrJWqwT13S8
TTX30EnUQc6HBXb4kp7rD2fmB05x9JDF25jETPDwEglx4GzRlOIbhe84KtI6
MPi8beQFh/KrP4RvO4XMUYl0CXXw8wRcoqRtETF6Nq/c4HWWM2lgREuUdVBY
BnE5hyPNM0mWcoQPzgaD9XLYkXYky/OPqyV5WdhT0VyEVlAz4UIoNmAYAhW0
CWUpZhkYDeAWuKZgiZPWmnreXCoLaH0te94cCZDbaAY4fRAAdEKq10HGQoy2
pwpUhHVO9wkqbkYyGrHO06T4iLlFoOWRE7+5Cri8CnsOcMC6jNJKu9EPIbD5
Y8ybKPsJ+92z6C+lVpBBrSz7EFp3nGERrAuT+xZQaWeV6+lHqnigV9qU2de2
G/VyB/zplR53ZxTu7XCyPxzw1dcm/NOO5KvHV0SYaNL6fTUCEFRSJwDj9NnH
gB9pEu279IdX7/92MnybnpSDweCPhiX/8OHiT1KrQW3UV8pMYQCMH+Qa4g6u
ebn/nZ3tnafR9k60s3c53B/t7Yx2hwPY9H/IqKT8PuKLffiilt4u/IpPTgwW
3lE7qe2UFqQblyRcL+KCJIfNqeHii29yc0YSkXI4MoIbUYZde6L9QA+qb8+j
J821sYFZKlkuUxD40PhRkEJrajk6pTe+Fd/eGl2X8QytJybgBJdvDGEaiaQl
OyrqwaktEyfJ5qg8RziLq6CxQN2f7Xzlh9T4zUqcNVFNWwCcVLit3DjIcp1N
bkBQ0Fg3SU0KmgDHAbW2CgNsKisi6QaFlEPih5+fAMeMsDRmqa12S1FZbXKC
W+blllrhhfQFvLJghZ1E2pv8jkUPpZmNXuG433axh3EDmLfcZXdslgaF/E5A
mofxpytdpGNUyFfzaWBkcFsQsVZJyLeKjZN1LpCi7MdAS9jV+7hJZf9acXw+
QgdsiK/xeIx2X63ZHnAZL9ViTjJnB31SFhwO5QujLLkF2NtBIxPd5hpfmHaf
JlMixkcJxcdeHL05pNoFyARI5Efuxa9M+ZUyv67uWES8Teb5ksQfG6DWxSF6
/eDgxPScL1Hw1LRxWwDghhCBLqEL1kCFw1C7ExcJqu4UvAHoEc8pfNAUeLTN
1ALbYvnz51dHB9HO8PDV+XDoRAQOh4Phdjfh4J/Pn4/fR6dH5/C7LCDwRPtp
PlktJNHJU6TcnaszHQ/LgEZ7y/igwxuEBFabsXaxGzlshct3k2sJ4+sJUSLg
W8jvMfcEGAvaq7WZhSRvXblAu0KUC6gx+YjQT7wHtjINWea9Uv6huiFEEw1f
ht1DVIy+52bHeXNJO3ZJukh/aUb+vAIhcTVPdEmTnBwb2qCnvLrdFWfB/Us6
DLuXGApCf2ssZ7exnB1/OdIl4gqLGF6hhdIsiJ5MsAQtutFMw4MHF3QUdl+u
UuBu7Svaa6xo11/RGD++Eoy+ijF2MybHKq2Kf7X6sJ7b5lW9pnS+c7khp3B3
sC1vbVX7jVXt+auS8XRduhyzTLl4AqfNy+EfTNn40MhZcBHgDmgBky1ycG3J
8NFiVkR7O+z1tgVKw583fc21ef4aR7Y8zy+e5CI1gqJyOp+o5HIfoeuoB0VE
UrdigjAIrpFAN9VE6/vKVkCNtvoSC4rWQf7KdCpxrUbmU/Q0kiGFhAH8iXAg
VMygSvQqMUy17Bk6VEwmJx/9go8e23xROi1bXuhYxGxP74kk5ScEJ1lJvWez
PCCqTJOWH9PlkpW8IiFtTbwoT0KgrWLmINkIBzv3jL1BcMQGtjh0SvHSueEW
aABtW2CMqWGCrF8CYdnd1EpmQ1e7V4rrbY/JOBfNYNlmrZpewoVLuMPlTVx4
9aBV+wmcGgBdKkjQc9rWe6bNbOrauVmFdw1uUuvHkPTuJuKNzsPf4P+3gaG1
3To1bbyzC6phg8Q13toLu+1kp/HmftitkYJe+DPhma1oO/Xv2vU0joRr8kVz
MAGLJQNu4JkZlHF6qNdeM2YQ38hisALRnvwtpFdaRDUXjJVbJ5yfu5NW3Cyd
WxtwyGWkqdzkBJECtnxbbReESisb0ExUHitlgS6qFbk2BgluG2G07S66tzAu
D5+P1+yv7uH3WqUVZEtYXjTP86V/Xa/TjFRkOoQ+3zO/dnBLiV5amVMuwOs9
rE4PlRLFoGeqIuBC1eiOnmSnJhNIko5ZD9dC5/CQkDUiZW+FjWNnLFLU7I1B
qKRWyC6VTEdiSCHSpBTWOouwNygvBjS/kd8Osgw0p5OTUXiJdj4WukR8izUZ
bpKog/vaFCG5X5o1sxycRAeHlzgRXB0Uc4c7I8DnKsc41wkF3FJl9XjJU6Tc
yRtdZOnsJiLDCUjE3A+FgkzZnS0+1RZKd8/Ue6PQ+PsFdN4lMf1ocqqMhx5U
0gPLMJ9QlI9xozuMwc5LHgFAv2yCnZMui5gzOXyl4Nq8UMkLSjyth1xCvWnz
iPpluWBberuJWJgb1gC2aNvGrwLVCWmzzmgSF1K7yMKtaWBbzr4ui5/TEZlV
Pl4at73ccKNXwH8p3tnIUPiQK4O6wvgjJHHd1tdL4RJnaSFjxXB9ckWwYon3
YRncBCz8HSI4gV/WYU7BgGT3nnV47IbwztSc24ynnS9fSctOT16dHEUnJ1++
yPVSW4TPjhT3tNOR7gRpibIBxss4MwZnYh4SYK3Occv/+aofvTs/qBEYvuXe
2k+wXfRE2kkI2bmfSr0R2oQebIEt9zZCfglfTNEYRstn4mTr17aWSjcl8Nxb
rLW8qbBKWpJehbSeHL8GRH0OdWixi2tNs2Lq9lTz6mRrD1bqlVWrpob1/kz1
F/h4RswT8fGhCrrjOPto9QoyAJtgqbK9iO4jPqnX0fU+8ds/1yrpDve39xuV
dIf7w6FfSRfL4cZPx8+iyfPpiwhr4VJJ3Ehr4m7H4wkPLYV0p7v8STR+Nnke
vYAvoil8EZkquvDkKwvpvnjRLKSbUrs9ve1XWonGK6b7GJP9bucXrXTLBWOd
ki+2OeHfU2vXOxJWRy1CRzk6iPR02gvOOMb5tvrwo0cUuq/Z2z10d0rKuqXi
GzZ3W3yQLoGtvFi7OPXbEdAS+hwIIqXliDJxnS0KAiKVxwqQYo4L7G3Xq77m
+2uKDTEJQfEoyxfYxgBoUFpSz6/DnPqascbMosTc/GhFCGMlbHJ3U1ZS+DrW
1iHByXpjW5VcT2jAJsU21NcRG0zT51FdPsiRAp/N4wxdVY8XD5ZzDOXFj41E
gH/xTE6PtM1RPffyd4gDGsnLFeFLIw3wX2s2woelgQuqSfsIUWCDWBIXs1ya
4RqTJf2tAZQHbXFn3Gj3EXa4nX7YbpEzDEe79uqa5K++iLJ5TRfc6xAFN0HD
xqoetMMxCl8pSjtimwz5GEul58Mzd0sdeOaBCkqsW57FBdyJZE5FIUskL04X
HSoIgYiGggAe9DiHT1gZ5Z6F0sSTLgK+BMKPiNqJVJeh0bXoJB4Qf45JpTRc
v+YSQvUMLvA3WAiSlTaiMZq5qiM69In2EYe/5honyFUqpGMMVwDT6lxlzWMV
T6cFl/HVDjNcjtq871ThwpVpixDcHFUe2N3f31GfyuUNElWKpJrXS3hV/Fs8
oVKu4qGkeYjkROFpjOY7JJoc09tN+Wf5EpRqU9a6XosA0EVqknEBSq/FJEf8
lVxtxmk/iMIjchmg9WmpFhI0K3HrRjQvAAdH94QzMTVCoHYpRNa8PKd87Mca
1AfCCcWNLFEOBQ0tej6aMxZLDXSjUJO1DTTR6D4bK2KCC9dO+IRaN9QggtbR
dMl2yHsm05cSp+RhQAEb8RxngcVKLHSzUi8f/QU2ITrQHkahDSAOPz/Z3N8o
sHFX9R5VrpJhUoalc7nTZSug1uRYYDI1RmKv9RUHc7EZqSr17KhsQhgekEqu
GIDpwTUknKB/VINGOSgRR2JckhVIPYoy4SjFWvY4wNBpR6tdJuEaUA3sQPtn
ik2CqRwGtHBofS4JNG78tBNDQxcHQUJL8Y5HZ7Cmj7g0/umphj83GqyiwY7c
7hTRb0IS5X1q17clvQUxIicpa4VgyVBMU3MTQC0TriNoNyzTH9RGPZI1uopt
Si6TELrhICDhlUezn8QqmR6ihphWzZcDUVa16onBIqdlV7NNl4zdDzYESTpN
n6iag9ddwYl5wtZA4ll3I46cZnLaI66geHbtMWb78bKBFhb8Or9Dm2y/bcLN
bd5sdjdmI444epBL+9o2bY0eb/wNZpZ4IfWe3rnEsvpKh2O3FLupCGJnsKio
HfHoqEz/+lr3PApJwGU6i+RORJINiaCDW7rEzsbsl/kgJuEDp2sbcSGgPpsb
xXGXImaAjCYeoQotoTJtejzIBwT5zS3vKu085R2/0/ouaGtpXm+A50BNIKYT
Bm6TOhiP2SjF+yWVFJuRMeSLWtkXW/LF+9DWW0XiJZ9eOZN1wi55oyRIBE0o
6pdC1QKoCQqBZlC9BI3NaI3alkbrqF+iXqeE0d1qm73D38F9JJhupVSQdUAT
SMXlYlE6C1WtTkw/uui2CzjnFh7cZplqpBi86Aemhr2GQjlxkH6UU4t3g3mB
W33CiTtmH4Z/qwlJNN050GrMLaSDbpkGPZla7hZXFTaSI+FObaMsr+cxVd0Q
07qa+dDb5+YyzDkkreBey80mi1xAy6dhBFmKn2/pIsAmdFLbJWTYOEt4jSOX
DtWYKN7C0rmhSLpMNSp5BjJCP1DoyLZVmSZFoIGFSjk9xKrdUrEzvvPzw85A
GsS7gwUXS+H+bF1LLJkdFzmlHXElKxP/I2KRqaxtLI0kRxkJi/SVRRIjJwTe
y+kVlSukB7WkNbLA5hLrj8rFPJ5w5te/g9TJjneyQMzQGEL2aXR9yUfU5hgk
ZrYns/mVSDwLzuymw5xH/gtV58krqT5tRGXbytudxAn3TctGnG8Qbo70DWuR
vo5P1Ck2ZrY20h9r8WvSanDJDV2Zw/VtvIJKVtRpgfyeM45HNAkK7m4kH4a9
cZLDisCx+8JcXwpJi7OMa9dWXMuI0kEYZQ2kRCI39VncRFtBLS2Y44rHlYpn
33hislwLDPlsNjCyRWBsOQcJe9cgTvNDIEzCev90NiyWhqFt3KxFVucUvsMw
eWcmJ5wEKyo4RfTEMmbr52D2QWB6rm6aoaU2nlcH74EaeNSUlv3dT9ta1vS4
1NF9BXMoLf26dRXuCu4piZRQSwlJcqVb7dRGCkxtJFxKW70+FGad8twUDTtP
x0XMuiaMaUrPm+AMsaNt2Jgmb1BW5wHpwEjlblk1D5SnsGhQ3lB6gm3ISXpo
rfbYfuRWMYOLx9VEmdZSj07OEaIZWevWSq5uQTztJY5FSOlV4C+rzNTNMOUy
ypHJC3FraohZEvjKfO6dAHqV2FKokzpl3qibTWKSiqmbjRQylfRBss6iu1Yr
ZFCqpBSQWSduObmmjde227EhvLI7IapsKuNq9lrVktKj3JLwYiLmkuJkVYht
wAT1ieD2QF47EjW0Sxa+igPcCDUnU4xZzSb0c7JkTC11BBXy6qhE6YU8QIGE
+8KJcZ6wDGsyBu0FdXCJkWOAOUN4mmIum664jXIiecXclKOlDwIGC9uIldN0
ivUjzwxUfVWd1jNJbFO5CJdXGOvagNOedZ6A3sMER7Q/IMO8fHNBAiT+F/hv
xpOUWpSRAmwN+KkRWyA1fjFdVcv94qHnkxz0n88n0dEgTarriCs6lTtlpL9+
+dIPzEKtARCTVbSsvFOxP+Rk/VOuoGb5Sykd9fZ2MBbGODkzth1lHACPOnEG
MuA4ZTHXaMmCzpi0m8HyAMpcjJxFRsVrNnS8udgiuHTtogm6vZFSFiDaCer/
HyPqbyqGNnEVA7PYwhJoXe5fZyJs7Bg5hclxXzxTwTKbUnkLLs2mRnMTdoQY
1XXNLlTaUE23OvS5iI13ymt4kikVkkXqSu11+WcWHRjxUM6yRkqpmNfKpVN2
EIkti4IN1fBINxNI1ywJHFLDNS7hJokEW5lS1fhri6EEDWsBRnXQYWzI8aBO
2DeE92QvNIJegR17uT0w1r8puLEZ8KvuTb7i5l7TGIudUTojyJA3JWmQZ3aP
TssKKW6BgsTruJhSIJMxeJ9SzCBwj9cXp1TaBbUko5cynjPQJC+RrKUOQy/9
rDnQOaSRsa0zi5+8X2II3ArFmkq89gz+flNEkARl5OISgOVaHnFszgQqV0hz
s+TOlBLGmCOsdUQvLeO0UOOgK7vFjeHoGP0OZ17lQpWVnNK5RUJL5fo6Tj9u
o/OstPRg4NB5Xy0Eqt9xF2Z72M3XWgkM19cJWoo0SgCG5NgRRF6RQe6QLa3B
gVqaGnZaoC7USgKQ3KvbaAs4w5q5gmwt89qUZ/A5Yd5W7tG1xDme2rkkX2iN
ATIaG9Y3BwlUqg6IfdGSC4by2uReicblQBSAcso3kK6ZCEx8BR3lRnPTY5JV
GkpSW05kED6UFdmmK31o6u6j8L2p49xqGrGGUNJjHjCFDkwNFT/R9FQBnjb3
jWwXXtRSQHK9qL4KldqyTXBw9HerCmvjjzlMFlBwRM3Y2VujlhqtzOC2qjRO
GGrWSTqbKCMgbjAVMCBbIoSKrNQqFliRH+F6wSyaLvEmnUCI+aqKjRsLTuwT
xjYAVQ04VvlTuuBCA8MF5znhgPAxcs4CG3QIXUQAHF/s7D/tcdmBwG1m+FCH
g7DZ4SDY2OGg0a/qWw44lY4G0sIAvZvSMgvLYZkOBk3RULAWm+0B8cAbRBI/
XTVmowdnJ8xjUZzWrD/bjJ1AbGo+lM2yC7apgFN9gRxrG07GdAe4i9lIiwWa
VgXSFyymkQntoypj1o9iSgp8TBQhTLhyeIAOmniyNqkY4la28cxd0iT6HBrV
Y5jWe/gMgkPbI85vwEaXgpqF8UXkZdnuP7+upjPNKLyPrZtUStwKOhd15+IB
e3t5xvllem7UsCJ+uJNdcE8nu6C1nFKzMJJstVzGTq9d9g4rU6/HknuboFII
wgswxySdYcotrTbwV4tY5EwvVkOX2dtmWMovNSRbTDUKETJxtnT2Y13EgjLg
RBXK4LDej/q8SI2o6plEKS4IX3XV4k2r4w0HASGbq1ckQUTBd6VWVtC60lo1
b9DOTU1vLmymvLfWURtbfWNTD0AmClDgxnlq+aSTWtQ6zJGRZI79bMi3npGM
kFM1TULxQColJF7PbyzRtBmvrQWBm1xyg0syONsC6iHQTnW7ox5mSnnZIiNo
7w8a5M+WPK4oeTXhah5SIgaAAcfFjF2azYrdALbXkZ2FTp1qbmQU7m2/eAqc
G4+FOsyWklDOOvcPF+/eupfQ+RDlSiZarGLl18F+SHpSySYsEE5yypYV6JqU
2R5FlJAoPmkGlCB7Q1/vsUSAq31UDjOjrrvco5FLOpP0cuCqWWhk6pLHqs+2
GqZyNW1KBUX82k24XvKZdq3nqufUnuKKZBrfRiZ5Y/J1PN/5qoJ3aB3t9eM5
rWFDDL+fgPIYgh2015yxBckZSuxLJ8c74r/43sm3LsaQrtgcpi2VWoJQ3fRY
WqQDw1zh37m1SAcG47/2SJoUCciRPNDKYsyTLupSrxnSznJQQuGlwinoa16n
ak64fPXP4Bcg4alIIyZ1aRRri6d3z05OehavTtMMrunfNJwE9x4tnGdfNkoO
8lYiSf12Bm2Nrqg6kEIOxvPJgqvL/dTWNvVcAVKhpCMmZw2lg0OH63GjbeZI
ksBGSXE2W6HxxMVbmRuRzp/WEBL1JrgTO8MHCYho0ynXLePsLhZPhea3xunK
VN3Pn91f7Y0PpupdYIZDXeNQpM1YGldtiluCcFIX5+zPiXMFCyrmx/EmHJyL
vecWmAmNpBEFSmOjxoZMvHITY9sP0IuYItmnzBKuf0OZaLd+YU/B0SaRD+o2
ib57igwHSkJ1jvGh0GX/XEExT6iFRNA4YUxHjTnc11taYp3A7CMN2o9HLjf1
qjJGVBeFQaD7CBMFtm85iCQSNmBrJYgvSOov4a0/oE5+6qZTW4Ixp7ixCK7B
JabPIlFQ4XcQnDh3l/yKTvaC0aA4R1SyYDVrKybvxGKw6cpqVCAwXKJkZAio
yGhPwBAVTCtK2SI6DnY4qbdILAAGVOiNiSiuyqWiXd//LsEFQjWFPPSChuWp
TDASk/Qvo/+IMsoWGWuIZ9AF6k3FGv1UdErhhDclS5j8i6LJ1Y5YUCd1e7yq
As4l1PF0pS4r0J6A1O9QHTAGFgfSw7HJd66Vvi+xnCTBfLwO/wqkm/11nHGt
Cw78g1WTtlp+9Y45liNslm3yhYzkyZXRanyYq+LS8hrlzNnTF3i9NZ6EJwdv
D9pkEkx8j8PL9TJBIKQcYMtRZamtcWGzsAvnJTWA2PhV4nyoyiaBRqvYCcqO
fr2uOaNxccDIaRVZvEhGwUibx/NiLlbjyv3R77sQBKb6mWmwUOJr2E0hCN4t
BcXafjzOuPhELaAXX3g+TqtvnapncfjDBwndkr9dOL25pHIRyBJe7SKtSUhf
mBQwANxLkMGf7q2KeZTgEpKpoCdlivGtIdiwhQVdA9h7jiw/wUV7FDIu+iJh
PrIhsNmENGsxGj1hNCwgbhPPEEmyOTrD7GylDlCvlA2+4GFNEBzYQxSLOscD
YjiCQRX8rvmidaDaAENSjNKJUyfYKBcSKL8Sgw3XTcasXr1DfiXD4MBSHodf
4FJO4xlMwRadbtmTTYfhq3Tu6FTuL6c4S5UDMbrGdwhT8UjtOwELdJxzvUBJ
20TU5UydJ0y4r1cFMc7amg5vCozLB1x8m2QZ1uUDxEJ/1f/K9O8DbLJyooRg
hd4n+vLd6em7t3hD2J9LAKaKpvICr++AONOGqYLgEPi48BHia/TmyfHlK6Ih
pEm+Zk3yFRX3ckkJCKOsZUYu7fjyOymMKKxUc8rQmNdrFJzxxC/R54WVws/U
t9fF1fVkXW/REyuLW3eCVirEbyqlaRTjhttHbfnwR5gV4EOYfuHeBLOrxpXo
g+Z4U1XLiPfxhat8Il1h630dcixp/kMgJ7HAKZf16pAK/CEZS2tOnv4hCv0b
v8dw1L8cWTEdnzGqHBpUgWfnRkb/LfhtFEXRiP7t/HEEPwBVn8LLJvPkxJbZ
+I2QDf5Tq1KF42EODfzCvb4f+YmqMPAz68hb9DkxoHs/BMIMv0i37NqU5QOf
AjL+pir1+QoIRftqmdk3vrV9HMwgR/rknPsmPGIQzXa0gxzrkxP15T5iGGN2
bVnMpfPbvQOpno3vkdBJeuxreaJfkiJrorb8EVQ1hxffsbD61UPgIuBBWdrL
6y3nsPHbY0Yl/EIgXS0QKwwR4XST7qLsuSO5LRu8YVw3Ed4M8SqdWHPQY0Yx
/FNaE9GFNPLukT57eCCKNriiqhEEioOTrdM3EkL+o3n68DitKbNIOtzE1Ffz
eOaO1qqAtw1HCmttsHN9+ojhkI38Rq4uNp6+YxOjd7frpj/4EHPqKD1WHmpK
3QbaTkl0Yt+t36AfWU9RPkU9KOaR3n9lBusGI7BxKNIxdfPgncAQeg6qaOMJ
XVh7r4PV/ldLrqpn9QM1toBK6nE+K4lTTcF/OX91+Hy485SS3zg5JiUl3fgG
hU+Z5QBpJUZD6wRw/8O4iymg81uLXbNcTSakDz5EtEwgW9so3IzmQQLa0scH
b9NdzF471iPV33T/aBbrXBRxG8hsOH+LfedGvBZS0EQ/Q0EiSWb4OhTcMMP/
hTgopefgAy04ZwuPk3IgpSAfRUa12MlvTj0eCW0rTbEcRKhH0XZU+dBADUvT
P/KCKOTsEWNYVKyji4uOm3ABMAmAFHINETTI8EsoDMLIrI0l0+86FBsi2MsR
ah80T0cFmPb3LzUSEE53cpNiXCIaVRuhf/gr7IdaWNiQweBrYwaNoQedgiZM
7jpfZeI5xFYLYhswpiasw4YBZRqDB7rMXVIEHcwPSCUagHTgfxPfBJW2py4b
NiJGsxw/Jmt4DWaYJ175ws6dponZ8eAC65BOdB267wNTKQlegDs5S8Swm1Cd
rIWtqQYy0HK+KiPfHRWYBIxabwLV5b26Mu9QDw13Btty+48/Tfiyabx2h/wO
xE/bj5miLJ8/fbELR+B2Ctg4sjlQNMczBaDAYzNZ9wCzsXu2Ex3+5HB1pRri
oXAcI5pUnXELVaJs6oo1uepknwgwf3km0SZYXWMU6qHH3AuHqjLfxPNrJFbw
02LQwWBXPFwKQBGfZbnCEI10QhFVaA9OFhRRHfOwpjk52QLm6wA7moBK06X8
KF67uFRNfe4YIw3LipK2ZCf0Yg9TP2UTpR/yGTrbcT0BFGxmC/4EXAugoOj5
LG+UQO4rHprKRNRF2suvtZkvZMTWQHY6BCpTIkFvZqnBGH3yNwis7nWcRTBO
L+ToJ5BsZ0TD6Yc06ynaFeQ9CGz8HCZhHR18PzAB+m4uvaa8Yq+HNJtU2mgQ
dWbHeaZV5jgwfIs2T6YjEz2DMXPMtG1Xe4teUsyyuiMLEjaUkwymAk5ihmsZ
yetqYCaUcnwQiEb9TgtxwPzmKZw3NnXicFsyR0uhQYdCBOoPHnQ4XsepZEX3
rGy/pXwbm2+7VDXHlUZObayII4O+fMHMrWVM4bY+2qndT4pJmwzOCTcIR3Tm
W3r5KYuYDnRA/7i6M05FIF6rBVGoUsJD4siaYzETELOldWAxVdouyeJk5iAW
Wq1j/5XwkDKhSLiUL6xX5ArXGTHa8nlw5QATTWkXW8dE9TRyyCPdcb7ao5Zt
4O3nJMobvHb2QpDvfgG3gGO2bHF2qrQn6Z0GqnBJSlTBqTiCBBNRkQnTCEul
kT7nX0paR2mTIsyGTCwPFX1MnDVx0224BmMuuMibw7gbDlUYccpe+5FQZoY5
EirWgIdufFENDNTAQ438Ti2GfItVNf1ZAP53sZSm5JFXGbOVqfHNuMUmTqo6
uZMI/BmsA33HQMcwtrsZI4iZvvh8Y0AGl3XAbiG+FZws+0aZlQq5wnpNvf2g
y/du05VD7y3n/qPTG23XkqPoxv/bHnuVab+QTq4m1adOj6Ki3cVZ/xasx8vS
UZqKI7YQiNhUYSKvaLFGBDfX2VKGOkdS0tDtSLtfxo+0dAgiRVtTrf7wLz7D
BUgV4U/A8lieUqeQENZgY2ZDl5qRhJdEUU3wZN9rsMlRTeEZl8Y52xEqK0f9
H27NWXRjaIp2j8oCSPN23Y5U4gAcW3PyrQMbCfZxgCItobQRZ6OtAlIfZqgo
jHaq6kbIpPRgmnJ9m/vlYHRoo40uwqQWkHRwKM5VziMt12PW+C2VSQBdBK5e
IwmGjof5rZ81xf2ErW9GgomdVkuX4gjqvgO4XyaIPCCx9TYwJ/cd2N+7s+O3
l8dvjk+PL89/UtVAFun2cxJvU6BlXFUDkCR5p7jsNBmvuOwiJbDmGXqMGdoU
Ema7nZZI+NFHhXFRVYzZ5vG6HFmVoZHxHYi3GrAtIuS7L231WzNQwElAEZeK
xWg/7q6ATk4T5VvK+2JFrgVDBpTH+y3tqd17Xq/27cXn+G1oHZD450GefOSm
HC89X1uv1DSQijhA8SvijVoPWKtOUWx/sz+VVpwJTF9NddeTClw746SVCvEv
QfuhM9XwAwAYLI1WJtJlDcMdbGiTDwKaqtkrRGIiOZNXIvqLIpk7iaYvMeaU
BQzcmXtFOJN8g7z2EmmJAcjYjlLHddv6TbfDPdwCz1NcE5hVTyNGrrm7ldIs
6Q9MTS9nWY7lyTSqo9ExTY9NjtoE7Pz+1m3AeZ3tSt5cs2cb798WTWYDVGC7
tIUeyWw0+5PaYBeHJ5eXYfdiRcH8hzSnaSnWZ35IssFEumxSQtYGOoaEmwfc
ZPEoJ2lVRe6vjtYc11R3UwuyMquorGedzrzkdROsnDLMTEncxauYBYC84HuA
TlWud0sbCygLfVmV7kXUzSQaKkiX37+FkghPlU3DbosvURV5KsCLsXucg+tc
Fbe+v7mCdHC8gJYVaxGW2Fb3pyIXTmgt8TwXQA4csQYCd7IKXhEfpiqefa5m
YE0mCxASsTA/lxCx5TBJuGaBjPLrObCNjICceWnYeVhT78ZrVgLZABs4mp0R
dah8BzGhudPE1FbRxzZ4BGzMexTziSY2t8OLQ+/b0GHA1mRNAzexXzbky1QU
QeEAbhzGzVqhkgJuwy5G8eK+ffZktPkQKUGVRwl1qXUw1toSaAhevSJiz4n1
4Q1Lf1HuUB04CCT1Bd04dWM8ImTu1vzDvYDKUJPYRrPallJA8WNieeUKD7ls
hVvg8gJAIFmzG2RP1gYs9m6qhThs4cPuodS/oGt8WCRTFq02sIPN7zs1GMUN
Fo9RRSxXYveSGFJVHPoaPyexPz2973acZrOv/DrQes9dQtkbIu/Uj9K3VzQS
hnsDtZoRJqEG9MOHyy1qa8YRWk7slnCfvuSjmH6YRKBsszISc8TWw7F2fpvN
76Ua5EY7NoVuAyL737W/fsDh2uy9wPWRjuxPiJGNeGmkp+ch51XCPoXX4VW2
5W35mLy8gj5XZeCekhSe3+f8/z6Xouo7dizuqSeZAPqJnxQwoO6fSAac6oD3
F1KhxHgtiUJdRbFUit4/zPrtUrZeaBovUusM7PT5o+lY7QiuJgXRr4UC0hZ2
7TyTXgS15J6uMDky1uA16jcTFHjDXBDHSI+wkn3cMYofXvfjkjqoJFwF0G/N
6rVP1kaqSZ8b7FDVB20YvqHR+VI+8x00+JPmptgQ53OFmkSCtqJa5HWDBalp
BGdIPfQqVkOB7XyrEh/LueO1CPxo7TgSCYvP22lNOkKAc0PvjWKX9KcIx3ju
HAmvyUU4dKONLsbtcSqStyBb7kkzU9oS5egkcNzX63GBFXlf55UR7YgJq7TY
R6PslAWqW/rNSLwYuKmZ8ghrQSpy0dUCbzeAmzG6PadSKvhuSGcNwnpCK0HJ
Q+fRA5mrNlXV5LCizYkC/62yVS6QepChhBNVbTAmVSIgJ4dHRUdI/CNQl+cp
JyzquqmgAHX7XVJwIJsw8NQxOK6+4f1ouL1A4XCCpm4BuO9SsmGhvEk3NDwl
KoMEhUzfOAsWz4sl3RkPrB7/2n5M9Yj8mCwPkteMRXIaNYKYvZg6QUH3h3cX
x5LvREoOS9YSHupVBwLizdWD/HyltGUNcCHybDZfc9n1FeLhtCWlD1V9d7mY
dsK2a6WQJi8UfVy2uhHm+lN+JYlJLpwG7LA1qr3tTQJ3crlEk8hG/cQpfSwa
xGIRozGupKJnRpnz2ly4LWKIttzCJ1jmoGjr+2g0CEwNDSrTAIiaXuHMpN99
C4h1kya3HApuhte6B4GTqVAjHosk5v5opuFnS49PE3LFIQTntr8HxhrBHT7U
DdILgY0e4H/BANgja2cYHr46x/jDKhwOMWjE7UhpxXy3T5LaQPqmSUZXWzBh
FNqhR4FdjsnWRssAmFH5DUdcDcdriYcrPn4fnh6dY2zmY7oudbVLU49B0jCV
OHkSBycR9w3Fiooa2aLR9WbygxOM7sR2J4NwuEPQeqglk9+Q6bdGjxWfX9Vb
rbROvAfDcB9G23DJTLs2c9zbremeXk045Wn66uQIIIegdkzmCjCi1ugYvk1L
tr1x2zsOILynm01LDzMdE6fFnjQOdNuaz7DYbSZqIlHZaFvjolRLVElu203f
S3NIttaGGBtY7hPzQjhU4Sa8vMsjTrs1Ta3aJXHp/SCF7EuREkLTNJ792RxI
kk1Lx7KlXRtGXN8C+YHEz9c70oAQjM1CSDKQDixratPtZ8DwTx+5OQtJ1VEc
gXwbSTdvbSZC051xQ+iHmt80m59TxKvZXnv/m8d9VW+B0/xK5Ja80QNn++ne
sNEDBx4+83vgDOOd8e5kbxol+9dPI2xhE8XjyZQa4XBXG+38Lj1wxsPJDvbB
iagRDn0A7yeReR+efGUPHJ3B7YFznYA8e4V1CTBdEmHjtb/xG9tIs3l67YoT
2r6uwY1JZUZg38QRYNEo2xv/efbTzen1hw/xm+ivs08/Fn9+Fb+7uvxUFod7
J+X2j8Py1fjo7nA240FMArQzyJvDeDve+fXqU361v9h+//z15cuXb1++PXzz
l5cfZ8+iWfTTMkm//2Gx/3TPgYFEROOh7e3Q43psMs4hQXIGZ7XFiec+BkTu
q2qFIVB99x46Pgm8g2wq1WgcLHAvxWy//grU0PJh7K99cB/i39v6CdH+aRva
P/XQnpF+H9D2afwswsZNdSze3vmno/1OE+1Nkxlu5fLVLZ+GfssnaQjjtEI2
XWoecy1qyPj8xaNx8ZKs+5htgcyt1sF1MBhE29TGtXnLa81U5dWdsFuDTI/n
cTjTzqi1DTsJvtrZ+UBaMG+0GeGCIzIOb+rXbuv63rmtX4LY9mnSju3ZtNZd
WDtAYw4n8ryh17zcNMO+/7LV2zjT9UE5OtJewO137rHf1a9e63eYtoftSH8n
1+HL9/Qa8HcsjdTgMl1HzmXa9a4fX77r/Yj6tdF9rX8w9K5fPBzvTHbhhiCi
4b+27b/knxaus6mt8Gbe09ol/jF3675bRC94WSQ6lZxVdLs7GP4PYl3m2iNW
72D3JpCRv+dutSgW/x2Y7WPao5Da/+RR+Iy6fVSssB52C0rvbLeg9PNtD6UZ
oZ/F0fj5RJoJ1noDbu/901G6haPUu1/7LOVR16TWRZCSMrDyxjQGDefqdvef
g+54inA20e3OoIZgu6ADW2p7idawvwPBGkf/KBxrfPUoNCNbShuCtYksz32R
hdHr+TiavJgyWtW6VW5v7//TEWy3iWDN1ulfjWI7PorRSNQSEaD2dYL8g2hW
E2n29nd2PdzaC7sv8ZD+HoxyTvlRuOS8/wAWcYtNESeixayI9nZa0Gl32IJO
L4YeOjEyvZhE0+2EkYhk2chi0/bTfzo67TXRiYBxJVu8wmpB1+Q++0qUqvU+
5VEdOfgfxKTbGOf5evjT9bv8w85flof7p399/vrj9397+2l3+ubF7ct4r3z/
6/Gz9N+r7buz/5j4dG0/7LIBTMXVU+ocURix9WvRcTO6PICXmz98AEEf0s32
WzBzf+hjJuPl9jRKhteMj8xOLWJuP/unY+Z+EzMFNRQ3vxol93yUNCguhyuE
7u/qx/voY/QK68L62R29kUyhqXHrr3GkZXWjYQe++OX3q4NOH1nbLZYUthH5
BKScFbYlmWC6ac2V06+78vW9UNpd9fUPdgQiAWziiGt62ULumUl9pYoQKfc9
oFeCRrnPlrZDg1Ydd5NOsVHTrUts7S/uaqF4l/O2vwo8rZ2qtr++H3ZrqN4L
fyaA2e5k01/E5pSRv0UikOhUMw5RlzQ8yrnA6k9JsTbttxyHPlfuns+diAcs
b/G4O00BJhzxhGNTfJfxzDjti01Di5rZXhwIgWnaQhYD9rUJFmB0DXc51EYw
4qb33Q2BDKAYNdN2csY8sTuy3WFtnQMa64c83RjFYo0M5KrFLCaOg2/pCyu4
TXWwubVGrTtsuxEGG2SV5RU6cwghQuef/0TscB800DX0kDLocgVY/afLp+N4
Inv4eJ7CZQAkWDcm3KpN2MBkg/RYQa/ncE/8Fc32y8eZ7Vsa0Bs3zqNb1te+
+P0d61EHaLObPPftJswYh0l0vRMzQ2RFwHLG7ed/X8f662ECN29CfGzv0UKb
dygeY2TG4o66c5/qWnt3d5NwZ7iPqgw48ZU5Dttt+vdKeZI07nEwp6OgxGbd
5aaDrtcYnYLmLM4HdCk0j8Egv18M3G+crh0VaGM2cYZiCA4mH7P8DhGJQ4A2
Rg2wA5PSBqSnPWd2I1HB1VC1AE2wTAsn7TqeBxTQnLf0d0SSI4ZSbtbt9jOV
bEuTaZlfNxPPTY5SNrU/nlETUEmGdJLCwweSwhvVzAKtZpaWkige/B/A/bGJ
czwBAA==
-->
</rfc>
Reference in New Issue View Git Blame Copy Permalink