c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
821a7f4570d964109203be70b85bc781c76519a1
ietf-wimse-ect/draft-nennemann-wimse-execution-context-00.xml
Christian Nennemann 821a7f4570 Add ledger-optional operational modes (point-to-point, deferred, full) 
ECTs can now be deployed without a centralized ledger. Three modes
are defined: point-to-point (agents pass parent ECTs inline via HTTP
headers), deferred ledger (collect ECTs in-flight, submit later), and
full ledger (immediate append, RECOMMENDED for regulated environments).

DAG validation is generalized to work against an "ECT store" which
can be either a ledger or the set of inline parent ECTs received in
the request.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-24 20:59:49 +01:00

3449 lines
148 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="wimse-compatible-claims"><name>WIMSE-Compatible 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 Claims</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 Claims</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 Claims</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>Operational Claims</name>
<t>The following claims provide additional operational context:</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>
</dl>
</section>
<section anchor="witness-claims"><name>Witness Claims</name>
<dl>
<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 Claims</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>Extension Claims</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="witness-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.ietf-oauth-transaction-tokens-for-agents'> <front> <title>*** BROKEN REFERENCE ***</title> <author> <organization/> </author> <date/> </front> </reference>
</references>
</references>
<?line 1744?>
<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.ietf-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+W963LbVpYw+h9PgWF+NNlDSKIuvjDdPZ8sybEylq2R5Lgz
PSkNSEAUYhJgA6BktuOp7yHOA5xnOY9ynuSs674AoKSku6u+qpPqTmwQ2Je1
1173SxRFQZ3V83Qc9k4+p9NVnRV5eFTkdfq5Dq+KT2lehTdFGR5nVV1mk1Wd
JuHhLM3rbBp+LMpPN/PivuoF8WRSpncwyMfTs8uTsDVUL5jGdToryvU4rOok
SIppHi9g1qSMb+ooT/M8XcR5Ht1niyqNUv0+mvL30c5OUK0mi6yq4Gm9XsKn
pydXr4N8tZik5ThIYPhxACvYC+IyjWEllzBEmdXrXnAP65yVxWqp6+sFn9I1
PE3GQRhGoZktlNnoKX41L+IkzBLcbr2mp7Hs/V73zk9XSVaHdRlnc/r7tFgs
51mcT1P6a5nOVvMYQVetqzpdVEEQr+rboqT54f9heLOazxkiR7clwBo+Dt8p
VOiNopzFefa3GBcKm8+TdJnmuLTwIq3SuJzepiW9CJ9k83GYpfXN/zKA3UrS
IMiLcgHf36U478Xro+cHowP7x+f2jy/tH1/IH18ePNvVP45GO/jH0+h4C2eR
Q8MldDyudqtoWRZ1MS3m4yDI8pvGKvYODnTkF89e7ukk+7sjHS3PdIosogOI
9Ezwjcvz09evT8a0d8VlOvw0PC+LZDWloz2VL8LXJYAZj4/w+uQuLddFnoZ9
HmbQ43HicpbW4/C2rpfVeHu7WmY3N+lWVmwD5lbbeJhVLU+jeFKs6u0CRrrL
0vttGoDwMbyJ5xWiwMmH6PA0Ojy68ld5wXiBy+uffBiEuzu7+9ujZy9ehsVN
WN+m4cmqLJYpoMJ5XAI+LfC04zzRn4+KVT7N5uE8Xmf5LEyK+zy8jctFkWcV
IFu5mqdVCIPHZZ3dZNMsnocZIPh8ngEQp7DnQ/vDqfvD4bTeAIh0VUbz9PNW
iiuL4T/b6TzbBgTfNot39o/Pop1n0WiPHlqkx38iROnxxj3q5pqg+JADvGCI
18eH0e7o6PXFaORD9Qr/G+6OhjBEkuL3r9MkLWGPFt7VEKerQ/g2PJmn07oE
mE3hhSlQhepb99llNsvjGrCp6obI/f39Vjq9Kbdmxd02YF0JG9imtcDytqe3
8bJOy+h0G8iX/uVwewmTR6NRB6psgNKHrcut8HVRJASb43I1Cw+TRZYjWaYd
wetnp69Pj6PTUx8cx1kJe4HrBqcx2t9+drB98uFX4heg0CIuP6V1BfgT3mQ5
UDZGJph9hV9VYf8sg9nD09NfhThJVm7Lsjy0GQHaHESjg3882hy/vzh89Bbu
bu8eHOzjvpNsltWwVRiE4Qx/BlTI5hldFCQhOI2FSQXAhod9nOe33CGe2r9D
u9EI/rf/jwcG0KWz44vHwDF6vv18/4CwIE2yKWwySe+yaYqHfnzxGzbJA/oH
/jzawTP/x+/x/fnJu6uTtydnJ1cXP/pbfQ8c9Cqdp4u0Ltfh5TKdIjWkvXdv
CkZGMskfGG5QwYfVdgE/dNH+Dds5mherJHxHjBD2sFiCBAI0/DXsJtELbThp
Nc3qmhhsVgN+ATHyGG2BM0RACPIqJm4X1SS5PemlCHCYuSq8H0QRSDMTJCrT
OgiubrMK2MqU7jicOqA5nPpGQbF/cnRVDYZwLCBT1fAEt1EXdC4fVZwyjBhI
ydlqXmfhJQlF4Ul+lwHJFXJCgtogcPdMty1xBNGWMIZjGmErSJ0BtwDZYXEh
SCJ3IDyE03K9rItZGS9vYQB4CuiDGBRXn6w8GAAzSMthuCzm2XQdpii6TFOB
xTSrmJEgElqBD8RbmDyMp2VRVQFLK3XBAMbXFqtcUAyW9GrNgErw6Fl0bsEp
EODeZ/VtW1QNp/MYRCPc+PeX79+FH9MJn0bY//7j1SBgYWsIRwAnWbkYDtuJ
JyggtKTTEI4MZMi8hv8HSOEJ+okr5cI7t3EdVqvlsihrd/sgBZkptgKC+aoC
eMDBIR/CYabrKcAzJOADoTz8bhCaWXDuMl0CiUV44XEEKuhOsxSgXRKLNkdy
F89XvB2QwWAZsB9YVxpPb80RBcsC9sLnhOIPzAsHRODcAHKDzx9Prwb4XWBe
OSdMMb+fw++rCk8PcbwCqhRWIC/ggwUIH3P6uIlr2SLDW484eRjm6X345urq
PLxNY0A24CTpPBkG5o5FcseGIV5FuoEJsx28yQh9nIzgHM+LfFYBdgfpZ1Qh
DE7x0OYOgIIE5wGX6jYnaj5ZZXPCwMm8mH6ikw3kZAHgcNWABABc86IOJ3Bt
6yqd3yD+wRQ13MOhe/wI1kAwCrS98Eal7WqLicsiS5I56CLfoMRpxHP4+zfh
WQFgYdoHlOc3kwwzZfjlS4eK8vWrEgFA/WKyqmqj6pFWRiSFUaq+Ba1xdvsE
BDGvBG0EAbDTbugoKlQSpimSBPljqMpR0FquqzrBspX+3hb3ZslV6KwZDh4R
v4AHpVCgEA54HoLgCbKag6m63MjsyMXyiDYRMR1xkBPP8E1xn94hUWzpx4R/
qcWVOEngGlcOOY2nU2BvdTwB8aleA1z+PS/ucUn3t0UIAhYSKyQQoLGw0mbG
whNLg3ukOfcxsqQc0I7+KoQAn8ZLwMI0GQKDhd9SgoKjiZfpX1dAgxhZ7tMS
72udVXDhkhbNCIlmwHYvDHF0uQkg4rRMYwTnfA0fLefFGg+iyItFsaqYMTGN
DKYF0CsQDw1T8DR5vH7E8suMCAKh9xL0F3uHLEJXQFToiqR0iHkqpMCh0ZZB
MKEknk74B1L/A+oe3BWjpAKq4ZtTWMVoF0QIARwgXja7jcoMWOThqcssJnDq
KdI9WADR1Wm85EOGTcEAxGnwnBFEqPtPZXX4DG4LIBRd4N68mFW9ARxeNqct
wrc8DRI/EcHz2ZZuiZWi40NQ9kJQBFWlg704yiHsRjcAw01J0gIdDHaOwyG6
1BmwjTpeLDt5XGYtLfM1QYMYEB4ACnr8+VBWB4eh14EZDiMyDBXDXYKv+5cp
o/ZotDXa6aeDgdnNmVWxXht14tRRsawmZ5UtGPLLF1X8nK0CHyl9Tq4IQWKO
lQIRKKTyoagjW0YGUa1uEFWICxciKyC/R6JVIWVnqVaPGCcCdRkBYK+c2dqx
aFHvHS3qwmpRiH+sMMFm8L8bMdDqWQRkmBtnvo0BJoA7M8QnIgj0A26FN41y
8NEVHcYdf0VnA7c1nuO92yTpuoJsqIIs0XFPLqV7LuSOJk7DWbyEa1Hfp0BB
OyhlnjxEFmUKh7ArSfmWBTm7KDlUJo3wPlCjDFAajpueiACL8zWppYhOaQK7
P6xkbUQM4WNmRZvtbl+/DoWziMUUvmlL40iglEAA1mSIQrgUEu/KO5iaJZJA
pfIYNEzgVXlWLfAz5SC0Z4d8C5FxxaogrqpViUiHpwnCBLAwmG4RXqI4jh/h
GZcpSP5FSceDUAQpCXcrVhtkIGUBbICxysrFsrNASB6Q1NGDp+TLTEIwzAmx
TgiYA/Cj4yI5ECQJ5nJV2CMDOzzLKr1lf0uTHo0KA9L35h1GI1jkFaoufx6G
wEyA753zQf84xEFByMKb8X5VA+0L/3OrFwS7MOm7ApUV5D2JA3eCigCgW9Rm
c/QmcZtZJ4IVThO5meg+ihZwPHs8edec3qESgIBxfCKaAhjPYhmKKriEspjP
JzFIrEYZwxEAWkAHgEIIfYP5TlQcLiaId3LR4OUCiHy1gsWjTOEolqj+wvsg
kXnWAys6MjrzMKSVppMVkx/Eb6GEOAJjgpFh2qqng7cgJ/K8yFhiPH087TZE
mNMOaVBiW2WU3tHN5JuOzw0/htW58jjzt2oKBL3MCrkrl1PgXvTpIYpQUwHQ
BqpoJYpuOwCZAQYha55h/8sXoJIR/+3r1wF8Cxqfo/CRLoO4a/S8NZMtBAR8
ncSzCFAvY6sIjyDYDTd1+onRzcoT8AljbMSqMX9xKoofrpaohyXlhiobOQv5
9JcvTPoy+yGPdJj7+ho6EYC3GHUMP0V7UcQv8Ecu40PFkCTI+YoWPE+TGRxh
sZTfWZwkkkXrcEyPEX0r66CT5I9Jry1v4mkaelIufC2jmxfwY9KubuD2sPSN
7B6uMwoGlcEEfAi3E3S1BLU+AhWdvFGGGsoSqdcKSsJ1vJJ4B6Lw34kvyf3S
lxdxDpSB9gn4VKIilhQorYQojYHAWN0aI5/37hEIujgPwGqe3aRoTkjdNxCl
L1Ix9N9mS6QKF/YKHFmVIOjUhx0ehDR7ClJAh6EDtgh4saiCiWyXDtOK4sMO
WiZ30rJ+Yd+qmQulgBEBtIB9c2QHVtNuKtoAmnWnsg1YcAMKDrxH3Lx2rzFc
+aPGMES/nU9KawI2kpevtATI94H+VkMjbxGnga/RUzIM7Y1lmjRD91hOUy5A
ccKXgkm6LnKWpBnvyITbtFOJ+uxs06y0Cpqbo7NEXAdCkrBQ6ihMTBS9KzIM
iIoWbEcTiR+gQ78ay4oqiiTbVakDIGIvrmGRKfGUNkNjekqZIWwkBhGZCixj
5a2uFQ08zYMNa2teIW5GBg/s4EamKKYk0STE1tJqCteO9Bz9tDUxCYSAiahf
kPpsXmXefRMDmqCLeu2o6aifkbFTtRw5qRqvMmAhHEyO0hsAAgmkGCp5S+SW
xAE6XiZ8ECMaTx8LljAtRvrCrwUTENeQCFuS6arpyNyQNaF2SdIBuc6QiWWs
+RAd/AQAvyfFqHf24fKqN+T/hu/e058vTv7jw+nFyTH++fLN4du35g+BvHH5
5v2Ht8f2T/bLo/dnZyfvjvljeBp6j4Le2eGPPb4evffnV6fv3x2+7bXuK6E0
y9BExEF4JpBXgTla/ObV0fn/83+P9kFy/5eL10e7o9FLkFb4Ly9Gz/fhL/dA
rXm2IoeD5L+SQApybxqXJLKhSB8vUVlDyzZg/i05leG+ATR//xeEzE/j8A+T
6XK0/yd5gBv2HirMvIcEs/aT1scMxI5HHdMYaHrPG5D213v4o/d3hbvz8A//
BiJnGkajF//2p6DJK+EAFswxVlUHcQUOSYL5OBijoOCYhFQJHPKlZDuuMlbS
4jttlXJrRcqvSFJiXwAJ2I5QjfI/TYucdopIAqpARlzdCuDC0QD5VwsSQkAh
qEQnQzWBdPmC9ASkbMdqsz8Um/131mbPc7ER30pzxnZPwNok1t0jQqFhCGQT
hqb1DpAAGxJTFxWNJPgHRE1eScP98eWLhLIYw2nCfLXlByHtPTTmEd8FBN/W
ZAuyBLvL6YA6NMljb0nc0uNf4tYjvG6gki8Wq5qsKPOCrF5414h1tE4TAIWW
r5QOz6jTQ0Y5FDhbAr3vg4KPfTdMIALzkRGYGWaOqmbmprOBBxs3C4qJAZcY
/HCEHDcDU20wlrOtnKdluXtqxThinkjuzTX5XWWFSQMfYhYwN4uJ7lyO1Z2N
7u5E5N2L4H/LAu0zYszBVx2A/nUFUmc0T+9SDOHyZVu8XSSfHtPE3iYKgPey
9vE+zjfYeNcituHp3sbIoc0mM9AD0VRDXBgUCfYJohFEApwAo/kPX7+ivc2R
lxEQWY3sk1cG0CqTCENM1qGMTteetV81ftUYwlSpVcuKpCHhJl2DoSPYxkmS
yWYa9irksgyMQ9co5mpcX75pK1MkpvN3jtM7uOo2sW1y5bg66SNuGoIBmVi6
8Qx27mOaqiP93mkYLzjsMfwz0Xz35x97A3fyDg+hM7ODgiLqLEsSUGF2lETi
qiqmGQlVjCpkGMIViMRN3+CbiLayJFoAeQ6i22LZVMzusphlqgdcTx38x3c+
NfmgK3W62CA2PyTpRI9IjkbEr4vAqty+muk4i5hIb3At0SFfGEWfDGpicLPm
tMKo91npGefQZmSO2h3nCa5kgCpCWCzpvp7XdrnAq2+z/BO+5tmtkM6oycr4
BRyDFfF2uhYnxr57hl5kUTE4VEBACGDCK8nUZuNpzON1WgZqiCYZWkFKPxnR
OmbDD41BvwCw/+d//gfwcZplcNnq4F+jX/3Pvwa/qJn0Lc3W15s5CDf+8wt+
hJ9djUP/4vU53nK8vV0n23Tw258HPfebc/6Gr9rDVwY/+k1b2rjsDT/c/WbI
odYkcLPyz6F3wIPwL2Sjw9ilnwQK8BlGQVoxBnU/N4gCNHDQ8nxw8z/+VSBX
qvB8Zfc9/er/cNixHGbQzshefO3b6Cdg6B2qUMayGxsRYsfU1vM++k3Lg3sV
fBmH39xks4juWsURaX800fN6+z2GSnupel/FLOv6gFbqdhLy6oagDIVuVOH3
H1ULDzgSwFj/8RcZTwiHIz4PxQLHxK8SjUUEH9eQ6XJFFjIahPwm4xiCb77x
pINzlEIrEBIc8SAi0bSCzR6SYGkjd6rH7bcmcANtBJZnGbueY8KGkb9/b0Jk
wt6nDFAcRCcYCVS9kNRbY29ifr2awCURdm33BbMXC2sy+R3C6WrLnacHIl5P
7Ew0LsZF2W10wAomUSu6kQJPjx1BcOBNQINO0tD1xJuwJBEzaNUk9gJDDkP1
gvsLP/cXbowx8xk6fG8XYd+DGTx3YDagdcDYsO4pL8B+aJXmtCHpMrQ+Arum
+A+i0ov4EzthyeAuMjpdyFxiXGbk9MDRanTuBRzSyOJHXJaZmS1DGR/1PvKf
twKuqha7o1cuZEo6W/W4wfz8x1cYX9mKpBkjZfgDSm2W3Rz+yX3Tia4Zw5vn
V0b/OVSWVeE54UetODAeHo+l9CUh1PuTP3nExXFDGBJD+3rDW7+sQRSBAXoi
3sGIaXZn7W592edA1EmyGLAWb3ygVxz+BJvg+CuWHgZjlINR18DQHtefSfIG
GxfZiScgzpxIpi32T+Im+76/G8aVGH3ZtIxMTu+Gh5uTYSwrs05w3Gei8YXW
yIBuSdHf0RFGNBNRSzafsJ+H9SWXJZAGtMlC8Zov8JdvHC8YE7UNHyAgOmM5
XZocyB2PvZdNqgJ+cGk/OABFycZ+ofUfo3svYVvxXHRU2Dp8wkN5P4Rq4UPK
YvRlZJFMyIkSCD59+ebnAjQHcXwxTjUpLA2HWB4LGbD02ZAQuY0/V6AQfoFj
JAqDGWqXuwfPekN8Uq+X+MSmi/3rz/c1/4QkHH7igIU4gosUZUk02t3rBV/9
68ErkothFiqbOfkco/6CdwOmR81azZpi59bUgMpAvUHnAFXI31AzGLYwRQN3
30UYN9PEMDw1ehTrDDSIeqQIJuakX3z9KqsjmKEhCPA/9Q6xl4Mu1YPXLtcL
DGRHJ7SuAzTWdGu2NQzf4LAIzjeXey/28e8Ho91BCxnImknykjhV4O86Kho5
TO4MYQ1MHJXpEq6OmlXgGBuQNUwsJUrfPGF8lrA3f5VVtxw+EjKBZp6Asgwm
CFZDsnPCuyZixDLbqfEKkIM8pC8cvk9QQwwHZOo4+gbrVwFBbxiLCKxywMJw
eF8uMOf1nM7rg+i9QmhKUgvnRfEpXC2FUIpzxhsaI/8M7jUMfngzARBH7HSB
i3lfqz/c3stlvCaJQ65jFU4KDYqOUHOFwSjqyxUTRYD0IpiawegP2ltpcWL5
iY7sLLzUpp2hY27PtKvoohHjWR5geOqatKAgyNgm5hzfZY0W6Pflh4tTOUy2
vJn8kaMr5CQZ3FAZW47PsRhZUczQMKTr8OJ/GxX1DyQNRywN/2n7D7DN2z/9
N02ZVU060KtWE7ysLBzKSnw5Et7Anai/onMn8M7PiCR2K8iiUaQS8AyVBMFl
jVkvdqRSXRyvIlPRXoJIOHYSD4s1BLpReCrzbFJS+CpxWCdYVTwXKHSRyZN2
qY7Wwjm1LcyHbd4zZ3toOQFpLia/X8cBir+XrdLZEoMW+9XAB8OrdBqjwM3+
XLSDIukihCe3GkcpodiaVlU8UyspsXmx67Cg2YNnugtxTDnszBiZ+B6Lmd8G
K1IEcwaPjDtXF3iKptcl5t1kpGlkqKfHmMQDz38P//s96UlovmOzPeh2GaL6
738/JmeemODx4OgqME3MWcwSiY7syRS2jOHDn2uVoGVTSgdqY1r7HYtRbZOc
ccv7IqMRFGVjJlgLceg+RsEtq1WIkuAVICCT9Dae3+iJ8Y3cMhtnNxTuXL6w
qeBdm8cfazb4wT/sWZqvuyQ35XbxDRL9OPy5IPk2jGu7a3KKsC0TydegA1i6
E8eYbBfPdlmcFVXI5noXqDJPHBkTaCYhpcrHzjEZY50J+nHiA3RZShDjXM6d
7o0slpI8COUdHGUY8Nv/9ZeeoWApC0BbsHextuFSevJm93scIbktppL/+gmT
H07QgqqsjWO2BKk42gJUf/QxW1sveaMrpa20AQLnaS4BhcCnST3B4xrYYDbj
unL8jhRo4AoJCw2wl0HYgMxXG8ezqIwR/hTTSTk6MIY4CJjF89c00+kxLbYH
z3pG+sKz0HgW+z3dzZqstKU6eHA4TtWOJ2i3nMQoDmBQBm1HLxJSDRiBYu3p
4sNL/+///r/wOhGptvUA5BbxGliSCQ11koWLAA+CWIPsvlst4Kimx7B1jefI
FilawpkpmuUA9aR7mqCIqhKFOlFjvTEmOGQYVoUwnLiWZaHghInWeDh0Kepb
tTRyRAqdgEQ68gu+c3aSzmIUKIDJPLoNeCcTgxPtyOEOHTK2UHaSQvEI4ZwO
8F+jg3CR5eSKZ6JB2+EA+DkmdskelqAGw5HlCXlUMZ0hVpGG/Y0xKDdkkZxi
0hXKyp8AS8QTP0UXEWIHLHSLRSJPEOrlk5te2H8HYHmVwnjpwDJthJWaWQjx
Jy7nE+g2T6cyzhgK3EJndYpSejpfBytQR+ioJaT/5zrrZNUUxrzKM9DnPbuY
pEizES/88OH02Nq1SJTD0hJWDmbwEPyStOZsibHwGSRXYl0qUxJ12IF+C2pn
2IOF9cJbVInnAN8ECCk6PSoKwWfHHl8BBxP4hPTS0gCOwjRJdT+SuRPTFaQ5
GfclVI9NbEQ2RLxta/dGFEf09WVxK+6KhEsREQ8J0SAU3LNm0hII6RgM43IO
gqgt1UFBNJiLS4w3k7uCgQkqaQiPlrfoKfrHx8a7SWVscr0arakMQoruciLv
0MlO+VpVOJsXE3LeCZTJHw2rLlNrYKlbepizWzOAnBZRCWfnj6AdMSj6hjZI
2SSxjsV7IKRAOkF7BKUUnmWVhYyzRzwqdG8mStsVnN8qlTOfK6ycrxXEkmuc
mL0hvCx4DFwQma7hDm8CDqKXJNNpnDWpug50JIwMI3VDk6UgPNBG+4mk1BPq
dA26Ix4jm1wk2jO9ruKbtF5juNs0nk8pfeI6KVCe7g0o6B8z42tXyUCmiPI7
xxbAGWIVnCTs6cZ6IVzVW0ZfAB09QWS9K7KEdJL5nNMODGvmd/qHWIdB6WKZ
ztAQUNJ9UsTFajOAAEEAPLEBv0PVNioCJAbonjsc3xGfiBQ5sR8Y3O462xS/
UmYvzh0ioJEtC9GBhJMYMeouK1bVfG0zO3BKXFMeposlCki0OKBcnHSCmBGW
RSFrIzjkRXMRDk04O/xRBULUd0zGoQ5RCQ3ToCElXH5Y/QbS9Wh+NpCuJVYC
2oyvDm5qjASPhlKSqFBk3jXGXWEymURvGYm2N51nFNN9jRkVgE6MujTa9d2o
h/4T+Nu1JpA8tCo4YoBUY0Ve7K5wJjhczIOVF0X+chAwMxZBhfCxZqqH4Q/u
6+VashkiXWCkP6DvByXijOKneBJEBKwMwZpHj7KZ7lI0hl51rRgzX6ZpmkjQ
HTlRMN+eNZ/YzT3CG0cXn7LFeHhmwA8MfxOD2MPJTfZlkYNDsUNUNerCk9Rz
t7a0NDzdZtARjSG+QUL5nnuQJHs7syLKS5Qrboy/FlFYzoPEd2tmiFGPrNA5
wdIyJ8JT5CxbQ8LQi+4YmtgOCqBGJidmTrlTITsrjAAD/6AhVcCq1xbY09ze
VEfSVaUglmXzCLR7ln787cNVsNs3Z7bkUhPXt6tFnF8jqUnvN56fTfvFt3m+
n1fJjMjYhMROXb0wYru/1tZEFzc6Cnte4ECzeQvUSgtp3pBXKbXNrIKROwhu
c898S6zSg+aRy60XHls+alczqqncaflbX3KTCR2AU4JEL7FeljA5tEIX2WGT
E20DpXRrW2RZRdZqcpQbi32KutaYP+DbvYiTdKOEJ/ZBDE4KU6y3owyYJWjW
4dhoKOEIfkytz9I1nZZuj9XxOPs7eCCqlndk/fYUHEb7Mlm+cKCBiMpDP4ev
MLo9GavNkTTTnbaIkeH96VktCkM4l3FDlXGxS1KDS0yG4R18K1F2gLR1NmWN
yi0ZQ8hjPZS8cIwnt2J+uimToa2gLmLQzLCwSr629WlmGLhelE4khIht788P
ty/SWTEMj1LQIofhnw+Pzt4OA0zXXlU1XLeqmBOlqQaaymIdtRuCgJ2sEBMN
7DC3hjOAjBsiWRxjfuOpyeYwEgZy6chkeTwiaWjGjc0KcX0gJq8wcILcJbKd
KBKiANCWNJ6r24azLqm8CRUqXF6DMnm7WcnyEznxXWPAxClpvKFROjhpI+zh
e5FxuI2RsD/bX5XzCBCrABBG+ELPkWGq2zjaPXg2zvcn/zH78fbs5uPH+G30
19nnH8r/eB2//6/rq89VebR/Wu38MKpeT47vj2aznlQdge9pXY6j0aKzFUUB
sGk5hZWI9quxLGgYOXx3GL4jmfxUSzcCdN/gqIdm1Asjr4iaIIvumR3svdjv
yfOD0S6t70G/phkh4PoEDok0PwH/mKPSFKOYXuQoKjgbZdGceFiyaTZkUygV
LusGnMgklcaflO5dvjnEKXV/Z8cHQ3o20vIu9Ln1GEmdCUC5u5TtH2V8HxbA
juuqjSVwLQAdfzO6MVobfGsUJBKdlww8BjpemiiipaI7Cgv4Z7hkVeXYG7pX
daXXpsL4DKqusA79TzVXK5T9GkWSPJmkKhb5TSapAPh3YEboP0bJZSAEw82f
NdTCTYx9Gqlwgtjdgn7ivhyLOo0c9HpRNfZM5Ap0brUmmgSRVenuUxRE0qwy
1E2BMuaU4WmvG/rB83TGtd8yGTcITMGB68TkGWwCupMBImHoEsGLJkWSoQn/
RXUUrUJX0K2M2FI3nObQrY2YRYpr09NIgoBCDq/RUPcI1sgrHcreIfn7zt5y
+CLhs2ggbIwwUB6G2Y2zbXUscyqERZN7fmBRRB4AnCfrxhIPu72Mp75Lz0mw
QC3Uc+6p/8rxI/BCJPsiYf8SJl9oEF7t4ZM6DeTofPksdU0JTBIZQG25ka0t
uijXrYsMLoIrmpa12kOMgZY8b9+GCqIqnGe0UHJFSF7qtIgkriWr1H7+mssQ
CRHWmgZDZyC1qJN3zvVXSJwIx1dVDd8gQ8p6SrJSizhwhcoqTcmco4fM73MI
KeGPKspOOQ+3khPSy6zb9o9QlWFDZ1gSLKZY+GYaI3b6dS+45A78ONOoSqqX
hLImGVcjTajl4pCMG3g3UvQQVAVsxTke3AV5FaT+gDGmV1LcWlYvpJaQ0z9d
3YBMxFfkyM1KMPfE1WbtZXGfXis7bdyaV0UxT+Oc4CxGKVOAy2phGWthj6RE
sLJv7GB8DVrLQO/JZk5JimOEPgAih/y6gZ07FFlVHfONF0pyg6ypY/ekXdcl
G4SFRDo446SGdLpZe2p/ygrOIb/O8mtWTK/rErSy3sCzed6UaRox4ePa5IRh
OaDF33wMSxeTlFNClBsjdzEyG2MZ3RaSs2UMF7UoSBg0idkqS9jbA0faBgOC
07d/bwBUYKHK8ArYAuzhgPilNMYa8AVrp2AhBsfJWmkaU8B2GhuwkrqVCxzv
JmpIbMtfxpRYJNTjPg966edljxTlb4nqOQ4h9UkIFfI0CnHngcpqyCUpC1KJ
pSBXNll1yY1dGVuNsztxQtnAUS/bx/ERySN7EUlA8TD+PUX7iGXYjFFwDBBV
pWEOraq5oTdSIeahIK2WvByIu154AFUZIp+kM7WMTkcOFL1g7zWZCMRiT4Fr
xmZfmRJZCcYSEKgkfWDoVJDFb9ArUNmweVTcyipV2QdWJPyALxmi45aJSyAF
95rivDfrHagJwMjBKkfTB8di2Imt/xA9E3VPoIwIWBCtQj4WT1ghR5CQB/cu
lTzTCq7qUAg3x9bC6BhrGxjfgSdDunOENvudxoUv93dePgsm6zoV2wZ+QpG7
ufBK4K317aZFB+0BD0JKfK06gCMvsy0xcN2tNCQLFTyMVscgjiXhwUfiaKbr
IiG1TSE9c+MFvMBEOcJmODCGrI03RKBwpIra/UX/XE1+1fsYOPHw++rnUlvY
OBw9f76782x/dLBDD5HCmIfP5SH6l2Hc5zd78YvJ7jRKRul+tH9z8Cx6Ge9M
oulesp8e3DyLn09ewND4xb3EMu9MRtPdZC9K4e3o2fMXL6N4Mk2i9GZntLu3
f4BPJC6aPzg42Elf7O/sROnuy0m0P0r2o/j56Fm0v//s2cHBPvyyM+rJQsXP
NkbFCwsUg1QGfCiNa+vfQ5I7Dv/yEy8KLWVjx7fCDAHtysrZdnvK6KxJeuwY
bM2vaoLdCG4e0ZxPxDYuO4CxizpHsH/A6zQq7fhRI0qnDYUmUb3cHeTtUbwT
7/58/bm4PljsfHjx5urVq3ev3h29/fOrT7Pn0Sz6cZlm332/OHi2LyjSUqgJ
gJ7eaw5D1E94Yxd3Qq4WXzHEjxdpghWL+DtP63LPJjJnE93tb+0arLIKEJ5r
sDmgi/ww26K7lNEIWfpPjTh6NAFGSKkkkt678+dylZ1w+m9CNwnlyhTO+vKN
WzdLEmEb6S/61Wuk5p2mZzU2E49uf97M/Ak4FmA02lHxulVXWZkUm5MlHscd
Q6xmmY16xHLcHy811cLPqAjcIATOzlCdmIaRqHXRNLFk4aumjRA91jUqchix
zkocasdZkYT93hbIj9PbGCNJOd3uUPOpKqk0Hm/MpdKQX9pJuwi17tpUmnZC
6luJUIFbF9krKSwpSUzWg+9OrsLteJkJUY0oQpAOanu0NQreFFU9DuU3DrFx
EDToyL9K19/fTr6bZltbWxg7vbXVWdjYf++c3uvItnJeQlUXXmplWMlyvAwr
zRwjtx5iBOMtoj9p9M0wRJZxKfuL/BcmpN4NzJFTGwbm640nxHg5p5uAzk+q
HsTR3GxFCDA/bs3YoHj0KOpanxTH+piwLA1aw+Tix9YGQktWBywkAj7eZQmn
7ktENJk4SAgQw6kpK4ZWtS9fXJGcbg4oKOgEERiR/5AqtrgvkvAVmNVKWieJ
V060kcBXo+m5/opG5gbNkE8bE6ZgSFSXEZmuMvomksNABpRxvIzs+A6WTMqq
aqmNwOrfVYHvJKWkMww2+cFUWiMHilcskWjoe2lMJFUESJOMw4dK+0jkaapx
UYGtuEY6TpdeFjb1MiTMqglrgVcS9DZVxZPIEVRkW/XShoFTQzrB4pqmQmnO
s3igth50pEGMWIHUA2bVFIV2EE0AZcVNJCXBjSNLHNzWSqWRMQhzC2KqDohG
A1u9fIb6S01ZrF6oOcZ+BeagB2QHlHddtdXgUpZTHSqA70ZCXIX9TAxPNi8A
hQFcT9BdOtLyGt0CBx9PUoSX5iSjXzKgnDjUxtMeQ/sGr2QRpplYJ2wIv5ql
CMN55YG7K4vgnmYtOrCLxBe4GiEwziUw5yjOVwrJaFru6F7LUZCSbpWMxrFV
dbrUQr5XfKOxY4yE4XFIBAdmOQnbNh7UiycNXds7lzbpu4F/bm1lYNQk1EuV
Pf5cyI+BNpme/CDBgRA6J8ZLHTwsvdFaNfCV6+kOjThiDf8cESIJthLSRuVx
8XaPuR1aK35SbMBuoExgcwsko1MTF5ljcaQhxfe7h2/dDTQA77Yv+OTEvjX9
yRbN9HrQ93JFyNRiMigs2g0sd3CJtxTW5aSUVZ48CCdMCr5KFyAQYv1yIUeC
H04kO1exL/2JTKSPZEzOKJ7dRlI0RyASJrWoaYDlfKWhK6QszFaljRnniPG6
mKdkaw/7Ts27cbi3E4rracDBUld8GEPiMETaeanj8L8lKgYWE/4BRMdsntCf
uV4HzXWNc12buf5bY03M5BKexXmednk0gi8/f4sZC6Y49mwFkgeQNDKbZlOs
trqq0D0nkOZTIne0anrc6ARjV478d9kimS3iMpubbj2MKBJd4Vce7stZpYr/
rjeMUHMwlHqsNIhdQTdesUE3lXrlzJniTIKhAw3X6sCxfbThMRsmAfa1LTeI
GIHNOxzBwWHGarmiwedw9UOypAuJdVHpdxWTCCUjXDSXWsrUtAxO63ngIhxY
gtEIWxx3AYPi8BsmAJrCD8wDbOmOSht2bIEpnY0MNjLklLprbIzHc4LxeJsw
qxtcZn0AjwUJMOMJOBLNifptBu6h9J7lWlyVZWWGju6iFa6HiOZYSDS2wYUC
nsytFDbY5JqQvGkxtz+jouK2dB1mI3BK9BTw7NyV48TQh2KA8bYxkcYgAq/i
WVEKkXcfEk/i4Kw4vKGOi+JhCTndIJNqzIgZlJlhyjwTfn3TEmdNeEnTYLis
0lVSoCZsyttW5n47TN5oDlLdw34X3KxydjeZ0HUQnftU/hb+dU23f9hJ+wZY
9WN72742drgTvI/xBNhDwNUdNAMNPrsEwSMcjR1hg1Pi0JN3Ywfd0vRCXNNW
jeUt8A8gFAzGAlKgYQDDsizKfk9FGF8A6A0CZ9Jdc+CW4JH1WLmbQ3PJGcQu
qYyYME5OYfJO4OwfneXO0rpvPhgwczYUC7F7NZ9rBzx/6W5cPd4BYsnjsBf+
a7hpQOJOf6LpmVF1HtTTpvOiG+Wi+XDbG4dHRC1NOhLI8iSAlTGa3KgM+SKr
cZFY9BxFpT/iPewPKAKJwsb/iGh/TVTXP9ElRuM5KCcjSJZl659F/PmaugXA
29dmWoCMzIPFUnCjLCrpI6QGXWhzlJWYpFH6RVrFfcDpbGzax1CcIDCfU+R4
BVK6uUZ2d9wz8Zo2aA6wcvfYtTXdNm2Q5ic8h43JL1voQ+kP8NjNK11bOos/
Z4sVaLgCpOYpuRvqwHO74rGPc/j7H/8Y2t010AtB3P4iy3X9+rpwBn5X9xYn
SfP2/JY7Bujs37MW6rUPp4mAG/BuwxnJ20/HPwdi/LNFKo6JcK1rvjVD7WsN
LnFuiLqWMZo2bqtggPAIgxhcuhizXrgBGPK7hsjEINI4ZLYufOZqreH7/g9q
KPlBTL/SjZzSB3SWnLo9lChws31Hy4R1TuVYWrY4qKZeL8kXbrvqEO2pbimf
FDleJd0dsypItWeT55gEUORZPMcKuFr4E4026ecaBSOKzwYyV5SYUpjKiBti
YkSoxtYujXsWNO+Zr46MduAfBoZoZaTW0ZuwcIKPtbo0T1DtOo5Ka8SVwMio
G52XzI+bgzL+VQEHPhjV0/BsFos01wxeT7BKbV5bikI+TqfqEnJTtnD/4MYN
fPnGs1mywcN94VzllGYBNFF2K2vwqD0bR+jZOAIvWoEsHM16XcD9xMCz2caL
Bp7P1ACWX7TFm4ZCmdZSyBy2awvQ4BmBWoY6IFpuXe8GWxt+aDQwoBpOaq+2
pXcwc6VR9EfU8NYAVHiuawCSpanMEbclYZGZ6syGVbvqkahgZvxU6gC2hnZU
rzj8lBf3+dCk8YXNsj9Su9fxwjeKNqNGdYFLSe/c0oJ+dSE2GdFyrA1MT5Dl
c3MEDbiH2mvuYGtXdIEmCLW036YpUVYnDThNVZK/AwRPNu5qgwqlIi5rmDDb
7yoayuAqbMDtT+mO+Tsqhscqrm33Ynq0SDzxNOXmhqgJOiOj6WoYvj+6PDea
n0RK8hSTFba4CVdL1AHQVBI8b2BCN5JR7R7lKI0qXmKvaVc3fNEY2ikI6Y7n
1skRqxB8zxa3Rnloi6sWd2Cil8092JI1XtkSNcL+jktwmD6oxNNtoRdOeqZB
ODWGDH9DKT3hdgp0K/s5g7dqe8QV5UhKJOu34udBdZo6p/BRsVtSCqdoIqWx
HHFRAz/lI87mqzJle9dHLShhSo+If9a1yg8d6yIDwds7I69tj0EwAPiOdrY8
+FI8mcTXmghI5VR6hyjKjFTd0cj/3GZTmQIOuakQAcSEJycYxRUbLvs+gzYx
XuQxrm6LOdBnhwEbdi2wtWUsBkIhH5z2ZkVeHJrYY+s5dtjhDoi5Y3IMY7ww
NvLfQwYj+FDfTOSvbDtsmA7xLo52DaDYzSbOGwk061NEzZAtW0PHMjRkI/XQ
mFroiWtxGVAamIZ6UmnIdD6P2IeDM++ZmdumGknvda011qQ1DCU9tNuuhWMD
szkXBt60WBAFb7Y8w2+AWZxyMSmuoENRjdLG0nc0uQZ3Iy/RiozM9GC6LYdL
+04l+pwcSxsakg3dq5ZoKaYSm2fkYoMl2wjg1cTkALoOTtijWBFbUgz7czdb
6TUGLpD7b17AlqCSHM4bXK7KZVFxUj5pKVrsy42J46QwE8BsblbT/2vaR9qA
ziEnSrPU7YTeUkuWeVERcWIZDzfSIl4VZpMgSLyCt7YgjOvGtgkGJkSP/S/E
GGiA/Z29sA9KxCRLgKANUE3D792irbbkC6Y32zQAWD09ZilPRhsF/Q+5zQrX
AU2R4HYlQt6V5KLxAoFoT4pkrauWqAQQlqgWMcCZ9Ueho9jKmZP1Apusx1ZG
czDdCEMKwZWLaAGDy89PFhOrwNoUxGGjbfOQAt5OhwRvLYubLY1ETq4BZdEC
dP0zdnRRsggK/QbNm8QUifu6Bu4OHzGuqR2SRXoWBvsip1sZ3RzLIPwjYnCV
4sS6ALVzCaXjr9nswn/eAhk9/Jc/tiRyz/LC97DfO2WUQZXVSkpsN7IDgrCE
dhSRzvGgq2sjkvftS4POKUBTus0mZGIzUpex1r2ViplWFApUKEfIAQBawCSb
ikz6iY0qaFKx33imy8ZiPuSkAjSqgfYaQDUnwGMjmxVMgAO4Nr+2ju4BQ0zo
if1DZ73dUNODMZ8010iBztSqlqR7XikcDDy/lmcOlIZtOHbPe+loF8bqL+M1
l2CFaFjqLJcSQXD34djQZAV/ugZ6irO1D8zBLUBWeHWLSvZ2LMmmrC5AeaAC
nEQvgSY2VyR1QVUyR6opBTYFS/igtuA9nZWKdHYdAA9lZFee2BmxBQ2ResUE
aqmENAY0k1PdzI4ZkXLxq9IL0VRIMSUym3M6Mqq/QXiIfmEW2yg8td993irt
yigtgMZYlBKkU/J69DlpoghJVpVtWWFz0AAy+6a9NYQRm8Nn6bWRejeuS+p1
4YTk4IpnRa9jjj8153jIt7B5Gm8rTTg0xFgxQ6v6EP7lSVKt90+niPuTsWDz
0D7mNMzXuoezjCvP+Wtkdwz90exF/GahOycraT5Uvd95DTz1XzbJz92C808P
krb2KnqtlaKs3deQK+uzkyASJ1rJ89t4DkLDV59iMO/0HnZ6azq31lANWKYx
uzr0NQG9sx06wFiiA0i2Z8Ff94GrSeeVvILCRDuUbCxSvMrvVpZHUeaabKtb
BAp3VNkLu809o74nrTm11zfIUxww7uZ/n5FF3U//ZjVEIhwlJI9LaehlxDjq
otWFmf1eVIiE5XiBGpc4RtHXS5QXa8zGIh1wKAEPrHF05DynmFSbhe9BwPio
yQiyDjgTCtd8W9x7gYExhSdWxRyDA0VPaOAIFttll4TneaZP6YjE0W6Omf5A
EKX6Xu7hE0wBpC1dkEA31M5bpIa6y3Tq7QYJiEcV5pIs9HV0PDwQIeyE54OY
/a4Ip/BVKQlTFredsg5XbVXSFCEOnDAniW12O+rSWcjttvEDSiAQGySesRmX
6WoMWv+GlGOyhmW1BvJSm5kjjBKOGv0AHW8OHVdeaENA2SQ78KmT2Oy2vk/x
3w7e6XegY5axjWhyw46AIkThSVziRhNuLu6UyhVHi6kk3BgGbrChH0Hw1qQg
0xXoQAfa6TtK0deK+6xx41Lmpk4H44B/CkxdAq5ECaN8RwUPw2YJUIwhwUhp
wH90WcEDLtdJ9Md0aguk0DVdJgZI7iNRqyYlm6a5242DKhx1NSuNx00bwQ1R
ZUUzmerpMKeYh9FFTd3pqzq6LaZO9XAJUs7cslqYBol70zQTaRVgbgdDSxrK
Vkq8MMytO+RXgtqJVjeD1jXyG+E0h7Wzqt8sXWHCl7BzBddhaYY7w5vOpZY7
4BQ3E61e8IDpsRp+2nYYjJkUVTvvuuuBy8ckRghdMHhRpMOX0K5EHkuFcId4
6S+K6x714grDrmdF6qFGN3O8ctIoa9ldeV1cYFzRQI7TKWMQ54FnmOOCwR6g
jWOTq0JIEg8or1ST/o5djJa+gIRTrJZzdijPIyr11VEsjrxPAkGXocExNY5T
2Ij9lDqJeRIRneG3ISZ5tdiNJZUdofdARZyoeAMFW7tdyxu7deOMOQjFGx+i
hCZS3N0WhAiM0fLKxgnLVVAjauqvEHeBRY0DuxTGrde4Rx+vKLethVMEDA+f
OPi3af90yigbk2tAmNG0uDYgm1UdGQWunVFMYNLPVR0bZJmrua6MCWLVbAw4
D3zL8wrgJp2Gwo3iGMJkLFEfBu4ddSi8SifCllFkc/shU/Gc8iaeIkgFmpk+
amapfKhSjqBombXdpW9edcBG8bUrpvHK6CrbzYSbNrMVGKkJZDnOTuGGFW5c
OizQ9nRu1qsMbDdmX97jPtLKIEAWWMNyTMKMm8kYuJmM82JGYSAGaiZRSOZE
861jX8B+uiDNWiMpogIQvRCTRvMChlt3+WoPf6QkeKdxNc5cDanIE5YqE2bo
16LCrOGM0oVBwriFAath4Jbi4yVWlPNAqVqyFuvENR1yM809dBJ1kPNhgR2+
pBf6w7n5gVMcPWTxNiYxEzy8REIcOls0NfvG4XuOirQODD5vG3nBofzqD+Hb
TiFzVE5dQh38PAGXKGkbRYyeLWo3eJ3lTBoY0RJlHRSWQVwu4EiLXJKlHOGD
s8FgvRx2pB3MiuLTakleFvZUtBehNdZMuBCKDRiGQAVtQlmKWQZGA7hVsClY
4rSz6p43l8oCWnzLnjdHAhQ2mgFOHwQAnZCqdpCxEKPtqU4VYZ3TqYLKn5GM
RqzzLC0/YW4RaHnkxG+vAi6vwp4DHLCAo7TebvVOCGz+GPMmyn5KVlO/4Aoy
qJVlH0LrTnIslXVpct8Cqv+scj39SBUP9EqbkvzaoqNZ7oA/vdbj7o3D/V1O
9ocDvv61Cf+0I/nq6RURppq0/lCNAASV1AnAOH32MeBHmkT7Pvv+9Ye/nY7e
ZafV1tbWHwxL/v7j5Z+kVoPaqK+VmcIAGD/IhcYdXPNy/3u7O7vPop3daHf/
anQw3t8d7422YNP/KaOS8vuELw7gi0Z6u/ArPjkxWHhH7aS2U1qQblyScL2I
C5IcNqeGiy++zc0ZSUTK4cgIblwZ9u2JDgM9qKE9j4E048aGZ5lkuSQg8KHx
oySF1lR7dEpvfCu+vTW6LuMZWk9MwAku3xjCNBJJS3bU1LNTWyxO081ReY5w
FtdBa4G6P9slyw+p8RubOGui4rcAOCmFW7txkNU6n96CoKCxbpKaFLQBjgNq
bRUGWCIrIukGhZQj4odfvgGOGWHxzEpb81aistrkBLfMyx21zgvpC3hlwQo7
ibS3xT2LHkozW73Fcb/dYg/jBjBvucvu2CwNCvmdgjQP4ycrXaRjVChW8yQw
MritltioJORbxSbpuhBIUfZjoCXsmn3fpPx/o4I+H6EDNsTXeDJBu68Wdw+4
mJdqMae5s4MhKQsOh/KFUZbcAmwAoZGJbgeOr0y7z9KEiPFxSvGxl8dvj6h2
ATIBEvmRe/ErCb9SFTf1PYuId+m8WJL4YwPU+jjEYBgcnpoe9RUKnpo2bgsA
3BIi0CV0wRqocBhqN+MyRdWdgjcAPeI5hQ+aMpC28VpgWzJ/+fL6+DDaHR29
vhiNnIjA0WhrtNNPOfjny5eTD9HZ8QX8LgsIPNE+KaarhSQ6eYqUu3N1puNh
GdBoHxofdHiDkMBq89Y+di+HrXCdb3ItYXw9IUoEfAv5PeaeAGNBe7V2vJDk
rWsXaNeIcgE1Mh8T+on3wFamIcu8V/M/VDeEaKLhq7B/hIrRd9wcuWgvadcu
SRfpL83In9cgJK7mqS5pWpBjQ5v5VNd3e+IseHhJR2H/CkNB6G+t5ey1lrPr
L0daSVxjEcNrtFCaBdGTKRapRTea6Yzw6IKOw/6rVQbcrXtF+60V7fkrmuDH
14LR1zHGbsbkWKVV8a9WH9Zz27yqN5TOdyE35AzuDrbxbazqoLWqfX9VMp6u
S5djlikXT+C0eTn8g6kvHxo5Cy4C3AEtYLJNDq5tGT5azMpof5e93rZAafiX
TV9zbZ6/xpEtz/OTJ7lIjaCoSuZTlVweInQ99aCISOpWTBAGwTUS6KaaaH1f
2QqoKddQYkHROshfmXYmrtXIfIqeRjKkkDCAPxEOhIoZVLJeJYZEy56hQ8Vk
cvLRL/josSUYpdOy5YWORcz29J5IUn5CcJpX1Ks2LwKiyjRp9SlbLlnJK1PS
1sSL8k0ItFXMHCQb4WAXnrE3CI7ZwBaHTsFeOjfcAg2g/Q2MMTVMkfVLICy7
mzrJbOhq90pxve0xGeeiGSzbrFXTS7lwCXfDvI1Lr2K0aj+BUwOgTwUJBk6b
e8+0mSeunZtVeNfgJrV+DEnvbyLe6Dz8Bf5/Fxha229S09Y7e6Aatkhc6639
sN9NdlpvHoT9BikYhH8hPLMVbRP/rt0kcSRcky+agwlYUhlwA8/MoIzTc73x
mjGD+EYWgxWI9uRvIb3SIqq5YKzcOuH83Mm05ubq3AOBQy4jTeUmJ4gUsOXb
atsl1FrZgGai8lgZC3RRoxS2MUhwfwmjbffRvYVxefh8smZ/9QC/11qtIFvC
8qJ5USz963qT5aQi0yEM+Z75tYM7SvTSypxyAV6vYnV6qJQoBj1TFQEXqkZ3
9CQ7NZlAknTMergWOofHhKwxKXsrbDI7Y5GiYW8MQiW1QnapqDoSQwqRJqWw
0YKEvUFFuUXzG/ntMM9Bczo9HYdXaOdjoUvEt1iT4aapOrhvTBGSh6VZM8vh
aXR4dIUTwdVBMXe0OwZ8rguMc51SwC2VXY+XPEXGnb/RRZbNbiMynIBEzI1T
KMiU3dniU+2gdA9MvT8Ojb9fQOddEtO4pqDKeOhBJT2wCospRfkYN7rDGOy8
5BEA9Mun2GLpqow5k8NXCm7MC7W8oMTTesgl1Js2j6hfVQu2pXebiIW5YSVg
i7Zd/CpQnZA264wmcSGNiyzcmgYO7MANWfyCjsis8unSuG34hhu9Bv5L8c5G
hsKHXBnUFcafIInrtn69FC5xlhYyVgzXJ9cEK5Z4H5fBTcDC3yGCE/hlHeYU
DEj2HliHx24I70zNuc142vv6K2nZ2enr0+Po9PTrV7leaovw2ZHinrZE0p0g
LVE2wHgZ58bgTMxDAqzVOW75P1/14/cXhw0Cw7fcW/sptpaeSsMJITsPU6m3
QpvQgy2w5SZIyC/hiwSNYbR8Jk62fq2pVI338kKqipgSeO4t1oreVFglq0iv
QlpPjl8DoiGHOnTYxbWmWZm4zde8atnar5WaajWqqWG9P1P9BT6eEfNEfHys
gu4kzj9ZvYIMwCZYquouovuET5p1dL1P/FbRjUq6o4Odg1Yl3dHBaORX0sVy
uPGzyfNo+iJ5GWEtXCqJG2lN3J14MuWhpZBussefRJPn0xfRS/giSuCLyFTR
hSe/spDuy5ftQroZ9eXT236tlWi8YrpPMdnv9X7SSrdcMNYp+WK7GP49tXa9
I2F11CJ0VKCDSE+nu+CMY5zvqhI/fkK5+4a93UN3p6SsWzC+ZXO3xQfpEtjK
i42L07wdAS1hyIEgUlqOKBPX2aIgIFJ5rAAp5rjA3na96mu+v6bYEJMQFI/y
YoHNDIAGZRU1BzsqqAEaa8wsSszNj1aEMFbCNnc3ZSWFr2NtHRKcrDe2U8n1
hAZsaGxDfR2xwTSIHjflgwIp8Pk8ztFV9XTxYDnHUF782EgE+BfP5PRE2xzV
c69+gzigkbxcEb4y0gD/tWEjfFwauKSatE8QBTaIJXE5K6RjrjFZ0t9aQHnU
FnfO3XifYIfbHYbdFjnDcLS1r65J/uqLKJvXdMlNEVFwEzRsrepROxyj8LWi
tCO2yZBPsVR6Pjxzt9SBZx6ooMS65Xlcwp1I51QUskLy4nTRoYIQiGgoCOBB
Twr4hJVRbm4o3T7pIuBLIPyIqJ1KdRkaXYtO4gHx55hUSsMNGy4hVM/gAv8O
C0Gy0kY0RjNXdUSHPtE+4vDnQuMEuUqFdIzhCmBanatqeKziJCm5jK92mOFy
1OZ9pwoXrkwbheDmqPLA3sHBrvpUrm6RqFIk1bxZwqvm3+IplXIVDyXNQyQn
Cs9iNN8h0eSY3n7GP8uXoFSbstbNWgSALlKTjAtQer0oOeKv4mozTp9CFB6R
ywCtzyq1kKBZiXs8onkBODi6J5yJqRECNU0hsublORUTP9agORBOKG5kiXIo
aWjR89GcsVhqoBuFmqxtoIlG99lYERNcuHbCJ9S6oQYRtI5mS7ZDPjCZvpQ6
JQ8DCtiI5zgLLFZioduVevnoL7EJ0aH2MAptAHH45ZvN/Y0CG3fV7FHlKhkm
ZVjamztdtgLqX44FJjNjJPZaX3EwF5uR6krPjsomhOEhqeSKAZge3EDCKfpH
NWiUgxJxJMYlWYHUo6hSjlJsZI8DDJ2+tdqHEq4B1cAOtNGm2CSYymFAC4fW
F5JA48ZPOzE0dHEQJLQU73h0Bmv6iCvjn040/LnViRUNduR2p4h+E5Io71ND
v23pPogROWnVKARLhmKamtsEaplwHUG7YZlGojbqkazRdWxTcpmE0A0HAQmv
PJr9JFbJNBs1xLRuvxyIsqpVTwwWOS272m26ZOxhsCFI0mn9RNUcvO4KTswT
NggSz7obceQ0k9MecSXFs2uPMdu4lw20sOA3xT3aZIddE25u82azuzEbcczR
g1za17Zpa/V4428ws8QLqff0ziWW1Vc6HLul2E1FEDuDRUXtiEdHZZrcN7rn
UUgCLtNZJHcikmxIBB3c0iW2QPZbAB46XduICzndANuN4rhLETNARhOPUIWW
UJk2PR7kA4L85pZ3tfaf8o7faX0XdPU+bzbAc6AmENMJA7dJHYzHbJTi/dJa
is3IGPJFo+yLLfnifWjrrSLxkk+vncl6YZ+8URIkgiYU9UuhagHUBIVAM6he
gtZmtEZtR0d21C9Rr1PC6G61y97h7+AhEky3UirIOqAJpOJyuaichapWJ6Yf
XXTXBZxzCw/ux0w1UgxeDANTw15DoZw4SD/KqcO7wbzArT7hxB2zD8O/1YQk
mu4caDXmDtJBt0yDnkwtd4urChvJkXCntlGWN/OYqm6IaV3NfOjtc3MZ5hyS
VnI35naTRS6g5dMwgizFz3d0EWATOqntEjJsnCW8xrFLhxpMFG9h5dxQJF2m
GpU8AxlhGCh0ZNuqTJMi0MJCpZweYjVuqdgZ3/v5YecgDeLdwYKLlXB/tq6l
lsxOyoLSjriSlYn/EbHIVNY2lkaSo4yERfrKIo2REwLv5fSK2hXSg0bSGllg
C4n1R+ViHk858+vfQepkxztZIGZoDCH7NLq+5CNqhAwSM9uT2fxKJJ4FZ3bT
Yc4j/4Wq8xS1VJ82orJt9u1O4oT7ZlUrzjcIN0f6ho1IX8cn6hQbM1sb64+N
+DVpOLjkhq7M4YY2XkElK+q0QH7PGccjmgQFdzeSD8PeOMlhReDYfWGuL4Wk
xXnOtWtrrmVE6SCMsgZSIpGb+ixuoq2glhbMccXjWsWz33lislwLDPlsNzCy
RWBsOQcJe9cgTvNDIEzCev90NiyWhqFt3KxFVucUvsMweWcmJ5wEKyo4RfTE
Mmbr52D2QWB6rm6aoaM2nlcH75EaeNSUlv3dz7pa1gy41NFDBXMoLf2mcxXu
Ch4oiZRSSwlJcqVb7dRGCkxtJFxKV70+FGad8twUDTvPJmXMuiaMaUrPm+AM
saNt2Jgmb1BW5yHpwEjl7lg1D5SnsGhQ3VJ6gm3LSXpoo/bYQeRWMYOLx9VE
mdZSp07OEaIZWevWSq5uQTztNo5FSOlV4C+r3NTNMOUyqrHJC3FraohZEvjK
fO6dAHqV2FKokzpl3qibTWqSiqmbjRQylfRBss6iu1YrZFCqpBSQWaduObm2
jde227EhvLI7IapsKuNq9lrVktKj3JLwYiLmkuJkVYhtwAT1ieD2QF47EjW0
Sxa+igPcDrUgU4xZzSb0c7JkTC11BBXy6qhC6YU8QIGE+8KJcZ6wDGsyBu0F
dXCJkWMLc4bwNMVclqy4jXIqecXclKOjDwIGC9uIlbMswfqR5waqvqpO65mm
tqlchMsrjXVti9OedZ6A3sMER7Q/IMO8entJAiT+F/hvzpNUWpSRAmwN+KkR
WyA1fjFdVcv94qEX0wL0ny+n0fFWltY3EVd0qnarSH/9+nUYmIVaAyAmq2hZ
eadif8jJ+mdcQc3yl0o66u3vYiyMcXLmbDvKOQAedeIcZMBJxmKu0ZIFnTFp
N4flAZS5GDmLjIrXbOh4e7lNcOnbRRN0B2OlLEC0U9T/P0XU31QMbeIqBmax
jSXQ+ty/zkTY2DEKCpPjvnimgmWeUHkLLs2mRnMTdoQY1XfNLlTaUE23OvSF
iI33ymt4koQKySJ1pfa6/DOLDox4KGdZI6VUzOvk0hk7iMSWRcGGanikmwmk
a5YGDqnhGpdwk0SCrU2pavy1w1CChrUAozroMDbkeFA/7FvCe7IXGkGvxI69
3B4Y69+U3NgM+FX/tlhxc68kxmJnlM4IMuRtRRrkud2j07JCilugIPEmLhMK
ZDIG7zOKGQTu8ebyjEq7oJZk9FLGcwaa5CWStdRh6JWfNQc6hzQytnVm8ZMP
SwyBW6FYU4vXnsE/bIsIkqCMXFwCsFzLI47NmUDVCmlunt6bUsIYc4S1juil
ZZyVahx0Zbe4NRwdo9/hzKtcqLKSUzq3TGmpXF/H6cptdJ6Vlh4MHDrvq4VA
9XvuwmwPu/laK4Hh+npBR5FGCcCQHDuCyGsyyHGb7CA4VEtTy04L1IVaSQCS
e3UbbQFnWDNXkG1kXpvyDD4nLLrKPbqWOMdTO5fkC60xQEZjw/rmIIFK1QGx
L1pywVBem9wr0bgciAJQzvgG0jUTgYmvoKPcaG56TLJKS0nqyokMwseyIrt0
pY9t3X0cfjB1nDtNI9YQSnrMI6bQLVNDxU80PVOAZ+19I9uFF7UUkFwvqq9C
pbZsExwc/f2qxtr4Ew6TBRQcU0t29taopUYrM7itKo0Thpp1ks4mygiIG0wF
DMiWCKEyr7SKBVbkR7heMoumS7xJJxBivqpj48aCE/uMsQ1AVQOOVf6cLbjQ
wGjBeU44IHyMnLPEBh1CFxEAJ5e7B88GXHYgcJsZPtbhIGx3OAg2djho9av6
lgNOpaOBtDBA76a0zMJyWKaDQVs0FKzFZntAPPAGkcRPV43Z6OH5KfNYFKc1
6882YycQm5oPVbvsgm0q4FRfIMfahpMx3QHuYzbSYoGmVYn0BYtp5EL7qMqY
9aOYkgKfUkUIE64cHqKDJp6uTSqGuJVtPHOfNIkhh0YNGKbNHj5bwZHtEec3
YKNLQc3C+CLysmz3n59XyUwzCh9i6yaVEreCzkXduXjA3l2dc36Znhs1rIgf
72QXPNDJLugsp9QujCRbrZax02uXvcPK1Jux5N4mqBSC8ALMMclmmHJLqw38
1SIWOdOL1dBl9rYZlvJLDckWU41ChEycHZ39WBexoAw4UYUyOKz3ozkvUiOq
eiZRigvCV121eNOaeMNBQMjmmhVJEFHwXamVFXSutFHNG7RzU9ObC5sp7210
1MZW39jUA5CJAhS4cZ5aPumkFo0Oc2QkmWM/G/Kt5yQjFFRNk1A8kEoJqdfz
G0s0bcZra0HgJpfc4JIMzraAegi0U93uqIeZUl62yAja+4MW+bMlj2tKXk25
moeUiAFgwHExY5dms2I3gO31ZGehU6eaGxmF+zsvnwHnxmOhDrOVJJSzzv39
5ft37iV0PkS5kokWq1jFTXAQkp5UsQkLhJOCsmUFuiZldkARJSSKT9sBJcje
0Nd7IhHgah+Vw8yp6y73aOSSziS9HLpqFhqZ+uSxGrKthqlcQ5tSQRG/dhOu
l3ymfeu5Gji1p7gimca3kUnemHwdz3exquEdWkd3/XhOa9gQw+8noDyFYAfd
NWdsQXKGEvvSyfGO+C++d/KtizGkLzaHpKNSSxCqmx5Li/RgmGv8O7cW6cFg
/NcBSZMiATmSB1pZjHnSRV3qNUPaWQFKKLxUOgV9zetUzQmXr/4Z/AIkPBVp
xKQujWJt8fT++enpwOLVWZbDNf2bhpPg3qOF8+zrRslB3kolqd/OoK3RFVW3
pJCD8Xyy4OpyP7W1JZ4rQCqU9MTkrKF0cOhwPW61zRxJEtgoKc5nKzSeuHgr
cyPS+dMaQqLeBHdiZ/ggBREtSbhuGWd3sXgqNL8zTlem6n/54v5qb3yQqHeB
GQ51jUORNmdpXLUpbgnCSV2csz8nzhUsqJgfx5twcC72nltgJjSSRhQojY0a
GzLxyk2M7TBAL2KGZJ8yS7j+DWWi3fmFPQVH20Q+aNokhu4pMhwoCdU5xsdC
l/1zBcU8pRYSQeuEMR015nBfb2mpdQKzjzToPh653NSryhhRXRQGge4TTBTY
vuUgkkjYgK2VIL4gqb+Et/6QOvmpm05tCcac4sYiuAaXmD6LREGF30Fw4txd
8is62QtGg+IcUcmC1aytmLwTi61NV1ajAoHhEiUjQ0BNRnsChqhgWlHKFtFx
sMNJvUViATCgQm9MRHFVLhXt+/53CS4QqinkYRC0LE9VipGYpH8Z/UeUUbbI
WEM8gy5QbyrW6KeiUwonvCl5yuRfFE2udsSCOqnbk1UdcC6hjqcrdVmB9gSk
fofqgDGwOJQejm2+c6P0fYnlJAnmk3X4VyDd7K/jjGtdcOAfrJq01fKrd8yx
HGGzbJMvZCRProzW4MNcFZeW1ypnzp6+wOut8U14evjusEsmwcT3OLxaL1ME
QsYBthxVltkaFzYLu3ReUgOIjV8lzoeqbBpotIqdoOrp1+uGMxoXB4ycVpHH
i3QcjLV5PC/mcjWp3R/9vgtBYKqfmQYLFb6G3RSC4P1SUKzrx5Oci080Anrx
hReTrP7WqXoWh99/lNAt+dul05tLKheBLOHVLtKahPSFSQEDwL0CGfzZ/qqc
RykuIU0EPSlTjG8NwYYtLOgawN5zZPkJLrujkHHRlynzkQ2BzSakWYvR6Amj
YQFxm3iGSJLt0Rlm5yt1gHqlbPAFD2uC4NAeoljUOR4QwxEMquB37RetA9UG
GJJilE2dOsFGuZBA+ZUYbLhuMmb16h3yKxkGh5byOPwCl3IWz2AKtuj0q4Fs
OgxfZ3NHp3J/OcNZ6gKI0Q2+Q5iKR2rfCVig45zrBUraJqKuYOo8ZcJ9syqJ
cTbWdHRbYlw+4OK7NM+xLh8gFvqr/leuf9/CJiunSghW6H2iL9+fnb1/hzeE
/bkEYKpoKi/w+g6JM22YKgiOgI8LHyG+Rm+enly9JhpCmuQb1iRfU3Evl5SA
MMpaZuTSjq+/kcKIwko1pwyNebNGwRlP/Ap9Xlgp/Fx9e31c3UDW9Q49sbK4
dS/opEL8plKaVjFuuH3Ulg9/hFkBPoTpl+5NMLtqXYkhaI63db2MeB9fucon
0hW23jchx5LmPwRyEguccVmvHqnAH9OJtObk6R+j0L/wewxH/cuxFdPxGaPK
kUEVeHZhZPRfgl/GURSN6d/OH8fwA1D1BF42mSentszGL4Rs8J9GlSocD3No
4Bfu9f3ET1SFgZ9ZR96mz4kBPfghEGb4RbplN6asHvkUkPEXVakvVkAoulfL
zL71re3jYAY51icX3DfhCYNotqMd5ESfnKov9wnDGLNrx2KunN8eHEj1bHyP
hE7SY9/IE/2SFFkTteWPoKo5vPiehdVfPQQuAh5Ulb283nKOWr89ZVTCLwTS
9QKxwhARTjfpL6qBO5LbssEbxnUT4c0Qr9KpNQc5o2gItzeC4Z3Sloguo5F1
j/XZ40uhSINrqhhBYDg83T57K+HjP5inj4/TmS6LZMNNSn09j2fuaJ3Kd9dw
pKw2BrvQp08YDlnIL+TmYsPpezYveve6afaDDzGfjlJj5aGm022g65RAJ7bd
5u35gXUU5VHUf2Ie6d1XRrBuMQEbgyLdUjcP3gsMkeeAii5+0Ie1D3pY6X+1
5Ip6VjdQQwuoox7Xs1I41RP8l4vXRy9Gu88o8Y0TYzJS0I1fUHiUWQ6QVWIy
tE4A9z+Ms5jiOb902DSr1XRKuuBjBMsEsXWNwo1oHiWeHT188Dbdx+yxYx1S
fU0Pj2axzkURt3nMhvO32HdhRGshBW30MxQkkkSGX4eCG2b4/yEOStk5+ECL
zdmi46QYSBnIJ5FRLXTyi1OLR8LaKlMoBxHqSbQd1T00TsPS9I+8IAo3e8IY
FhWb6OKi4yZcAEwCIIVcPwSNMfwSCoIwMmtiafLHHsWFCPZydNpHzdFR4aX7
/SuNAoTTnd5mGJOIBtVW2B/+Cvuh9hU2XDD4tfGCxsiDDkETIndTrHLxGmKb
BbELGDMT1mDDYDKNvwM95j4tgx7mBmQSCUD677+JX4LK2lOHDRsNoxmOn9I1
vAYzzFOvdGHvXlPE7HhwgXVIJ7IOXfeBqZIEL8CdnKVi1E2pRtbC1lMD+Wc5
X1WR74oKTPJFoy+B6vFeTZn3qIOGu1s7cvtPPk/5smmsdo98DsRPu4+ZIixf
PHu5B0fgdgnYOLI5UDTFMwWgoGMzWf8QM7EHtgsd/uRwdaUa4p1wnCKaUJ1z
+1SibOqGNXnqZJsIMHd5JpEmWFljHOqhx9wHhyoy38bzGyRW8NNiq4eBrni4
FHwi/spqheEZ2ZSiqdAWnC4omjrmYU1jcrIDzNcBdjMBdaZPuVG8dnGnmtrc
MUYZVjUlbMlO6MUBpn3KJio/3DN0tuN6ASjQzBb7CbgOQEmR83nRKn88VDw0
VYmog7SXW2uzXsiArUHsdAhUokQC3sxSgwn6428RWP2bOI9gnEHIkU8g2c6I
htMPWT5QtCvJcxDY2DlMwDo+/G7LBOe7efSa7op9HrJ8WmuTQdSXHceZVpjj
oPBt2jyZjUzkDMbLMdO2He0tekkhy/qerEfYTE6yl0o4iRmuZSyvq3GZUMrx
PyAaDXsdxAFzmxM4b2zoxKG2ZIqWIoMOhQjUF7zV41gdp4oV3bOq+5bybWy/
7VLVAlcaOXWxIo4K+voVs7aWMYXa+minNj8pJG2yN6fcHBzRmW/p1ec8YjrQ
A/3j+t44FIF4rRZEoSoJDYkja4rFLEDMlNaBxUxpOySLg5kDWGi1ju1XQkOq
lKLgMr6wXoErXGfEaMvnwVUDTCSlXWwTE9XLyOGOdMf5ao87toG3nxMob/Ha
2QtBfvsF3AKO17KF2anKnqR2GqjCJalQ/abCCBJIRAUmTBMslUaGnHspKR2V
TYgwGzJxPFTwMXXWxA234RpMuNgibw5jbjhMYczpet1HQlkZ5kioUAMeuvFD
tTBQgw416juzGPItVtT0ZwH438dSlpJHXuXMVhLjl3ELTZzWTXIn0fczWAf6
jYGOYVx3Oz4Qs3zx+cZgDC7pgJ1CfAs4WfWNMivVcYX1mlr7Qf8J9w7dt5z8
j15vNF5LkqKbAGCb7NWm/0I2vZ7Wn3sDCot2V2gdXLAoL01HCSuO2EElYlOG
idyi5Rqx3NxpSx6abEnpQ78n/X4ZSbLKoYoUbk3F+sM/+1wXwFWGPwLfY6FK
vUJCXYONqQ196kYSXhFZNdGTQ6/DJoc1hedcG+d8V0itnPd/ukVn0Y+hOdoD
qgsg3dt1O1KKAxBtzdm3Dmwk2scBivSE0k6crb4KSIKYq6JE2qvrW6GV0oQp
4QI3DwvD6NFGI12EWS0g7uBQnKxcRFqvx6zxW6qTAAoJ3L9WFgwdDzNdP22K
Gwpb54xEEzu9lq7EE9R/D3C/ShF5QGwbbOBQ7juwv/fnJ++uTt6enJ1cXfyo
+oEs0m3oJO6mQOu4qhogWfJOddkknay47iJlsBY5uowZ2hQTZtudVkj90UmF
gVF1jOnm8boaW72hlfIdiLsasC0i5Hsob/VbM1DAWUAR14rFcD9ur4BeThPm
W8n7YkZuREMGlMj7Le2p233eLPftBej4fWgdkPjnQa58ZKkcMD1fW7dUEkhJ
HCD7NTFILQisZacouL/doEpLzgSmsab660kPbpxx2kmF+Jeg+9CZavgRAAyW
Vi8TabOG8Q42tskHAU3VbhYiQZGcyish/WWZzp1M01cYdMpSBu7MvSKcSr5B
aHuFtMQAZGJHaeK67f2m2+EmboHnKm5IzaqsETfX5N1aaZY0CKaul7O8wPpk
GtbRapmmxyZHbSJ2fnvvNmC/znYlca7dtI33b6smsxUqsG3aQo9ktrr9SXGw
y6PTq6uwf7miaP4jmtP0FBsyPyQBYSptNikjawMdQ8LNA24ye1TTrK4j91dH
dY4b+rspBlmbVdTWtU5nXvG6CVZOHWamJO7iVdYCQF7yPUCvKhe8pY0FlIa+
rCv3IupmUo0VpMvv30LJhKfSpmG/w5mo2jxV4MXgPU7Cda6KW+DfXEE6OF5A
x4q1Cktsy/tTlQsntpZ4ngsgB45YBIFbWQWviQ9TGc8hlzOwdpMFSIpYmZ9r
iNh6mCRhs0BGCfYc2UaWQE69NOw8bOh4kzVrgmyFDRz1zog6VL+DmNDc6WJq
y+hjHzwCNiY+ig1FM5u74cWx913osMUmZc0DN8FfNubLlBRB4QBuHAbOWqGS
Im7DPobx4r599mRU+hApQV1EKbWpdTDWGhRoCF69IuLACfbhDUuDUW5RHTgI
JAUG3UB1Y0EiZO43HMSDgOpQk9hGs9qeUkDxY2J51QoPueqEW+DyAkAgWbMb
ZU8mB6z2bsqFOGzh496RFMCga3xUpgmLVhvYweb3nSKM4guLJ6gnVisxfkkQ
qSoOQw2gk+Cfgd53O06721dxE2jB5z6h7C2Rd2pI6RstWhnDgy01nREmoRr0
/cerbeprxiFaTvCWcJ+hJKSYhphEoGy3MhJzxODDwXZ+n83vpBzkRmM2xW4D
Ivvfdb9+yPHa7MLA9ZGi7E+IoY14aaSp5xEnVsI+hdfhVbb1bfmYvMSCIZdl
4KaSFJ8/5AIAQ65FNXSMWdxUT1IB9BM/K2CL2n8iGXDKAz5cSYUy47UmCrUV
xVopev8w7bdP6Xqh6bxIvTOw1ecPpmW1I7iaHES/GApIW9i281yaETSye/rC
5Mhig9do2M5Q4A1zRRwjPcJKDnDHKH547Y8raqGSchlAvzer1z9ZO6mmQ+6w
Q2UftGP4hk7nS/nM99LgT5qcYmOcLxRqEgraiWqR1w4WpKYxnCE10atZDQW2
861KfCznTtYi8KPJ41gkLD5vpzfpGAHOHb03il3SoCKc4LlzKLxmF+HQrT66
GLjHuUjegmy9J01N6cqUo5PAcd+sJyWW5H1T1Ea0Iyas0uIQLbMJC1R39JuR
eDFyU1PlEdaCVOSna0TebgA3Y3R3UqWU8N2QzxqEzYxWgpKHzuNHUldtrqpJ
YkXDE0X+W2WrWiD1IEMJZ6raaEwqRUCeDo+KjpH4R6AuzzPOWNR1U0UBave7
pOhANmHgqWN0XHPDB9FoZ4HC4RTt3QJw369k40J5k25seEZUBgkK2b9xFqye
F0u+Mx5YMwC2+5iaIfkxWR4ksRmr5LSKBDF7MYWCgv737y9PJOGJlByWrCU+
1CsPBMSbywf5CUtZxxrgQhT5bL7muusrxMOkI6cPVX13uZh3wgZspZAmMRQd
Xba8ESb7U4IliUkunLbYa2tUe9ucBO7kcokmkY36iVP7WDSIxSJGY1xFVc+M
Muf1uXB7xBBtuYNPsM5B2dX40WgQmBsa1KYDEHW9wplJv/sWEOs2S+84FtwM
r4UPAidVoUE8FmnMDdJMx8+OJp8m7orjCC5sgw8MOII7fKQbpBcCG0LA/4IB
sEnW7ig8en2BAYh1OBph5IjbktKK+W6jJLWBDE2XjL72YMIwtCOPArsck62N
lgEwo/I7jrgajtcTD1d88iE8O77A4MyntF3qa5umAYOkZSpxEiUOTyNuHIol
FTW8RcPrzeSHpxjeif1OtsLRLkHrsZ5MfkemX1pNVnx+1ey10jnxPgzDjRht
xyUz7drM8WC7pgeaNeGUZ9nr02OAHILaMZkrwIhao3f4LqvY9sZ97ziC8IF2
Nh1NzHRMnBab0jjQ7eo+w2K3maiNRFWrb42LUh2hJYXtN/0gzSHZWjtibGC5
35gXwpEKN+HVfRFx3q3patUtiUvzB6lkX4mUEJqu8ezU5miSPKkcy5a2bRhz
gQvkBxJA32xJA0IwdgshyUBasKypT7efAsM/feLuLCRVR3EE8m0k7by1mwhN
d84doR/rftPufk4hr2Z73Q1wnvZVswdO+yuRW4pWE5ydZ/ujVhMcePjcb4Iz
incne9P9JEoPbp5F2MMmiifThDrhcFsbbf0uTXAmo+kuNsKJqBMOfQDvp5F5
H578yiY4OoPbBOcmBXn2GgsTYL4kwsbrf+N3tpFu8/TaNWe0/boONyaXGYF9
G0eAReN8f/Ifsx9vz24+fozfRn+dff6h/I/X8fvrq89VebR/Wu38MKpeT47v
j2YzHsRkQDuDvD2Kd+Ldn68/F9cHi50PL95cvXr17tW7o7d/fvVp9jyaRT8u
0+y77xcHz/YdGEhINB7a/i49bgYo4xwSKWdwVnuceD5kQOShqlYYBzV076Hj
k8A7yKZSDcnBCvdSzfbXX4EGWj6O/Y0PHkL8B3s/Ido/60L7Zx7aM9IfANo+
i59H2LmpicU7u/90tN9to73pMsO9XH51z6eR3/NJOsI4vZBNm5qnXIsGMr54
+WRcvCLrPqZbIHNrtHDd2tqKdqiPa/uWN7qpyqu7Yb8BmQHP43Cm3XFnH3YS
fLW186H0YN5oM8IFR2Qc3tSw3Rb2vXd7vwSxbdSkLdvzpNFeWFtAYxIn8ryR
173cdMN++LI1+zjT9UE5OtJmwN137qnfNa9e53eYt4f9SH8j1+HL9+wG8Hci
ndTgMt1EzmXa864fX76bg4gattF9bX4w8q5fPJrsTvfghiCi4b927L/knw6u
s6mv8Gbe09km/il366FbRC94qSQ6lZxVdLe3Nfo/iHWZa49YvYvtm0BG/o7b
1aJY/Hdgto9pT0Jq/5Mn4TPq9lG5woLYHSi9u9OB0i92PJRmhH4eR5MXU+km
2GgOuLP/T0fpDo7SbH/ts5QnXZNGG0HKzMDSG0kMGs713d4/B93xFOFsorvd
rQaC7YEObKntFVrD/g4Eax39k3Cs9dWT0IxsKV0I1iWyvPBFFkavF5No+jJh
tGq0q9zZOfinI9heG8HavdN/NYrt+ihGI1FPRIDarxPkH0Wzhkizf7C75+HW
fth/hYf092CUc8pPwiXn/UewiHtsijgRLWZltL/bgU57ow50ejny0ImR6eU0
SnZSRiKSZSOLTTvP/unotN9GJwLGtWzxGssF3ZD77FeiVKP5KY/qyMH/ICbd
xTgv1qMfb94XH3f/vDw6OPvrizefvvvbu897yduXd6/i/erDzyfPs3+vd+7P
/3Pq07WDsM8GMBVXz6h1RGnE1l+LjpvR5RG83PzhIwj6mG520IGZByMfMxkv
d5IoHd0wPjI7tYi58/yfjpkHbcwU1FDc/NUoue+jpEFxOVwhdH9XQ94nH6NX
WRfWz+7ojWQKTY3bf40jrasbjXrwxU+/XR10GsnadrGksI3JJyD1rLAvyRRz
ThuunGHTla/vhdLvaqh/sCMQCWATR9zQyxZyz0z+K5WEyLjxAb0StOp9dvQd
2urUcTfpFBs13abE1v3inlaKdzlv96vA07qpavfrB2G/geqD8C8EMNueLPlJ
bE45+VskAolONecQdcnFo8QLLP+UlmvTf8tx6HPp7vnciXjA+hZPu9MUYMIR
Tzg2xXcZz4zTv9h0tGiY7cWBEJiuLWQxYF+bYAFG13CbQ+0EI256390QyACK
UTPtJ2fME3tj2x7WFjqgsb4vso1RLNbIQK5aTGXiOPiOxrCC21QIm3trNNrD
dhthsENWVV2jM4cQInT++S/EDvdBC11DDymDPpeA1X/6fDqOJ3KAj+cZXAZA
gnVrwu3GhC1MNkiPJfQGDvfEX9Fsv3ya2b6jA71x4zy5Z33ji9/esh51gC67
yQvfbsKMcZRGN7sxM0RWBCxn3Hnx97WsvxmlcPOmxMf2nyy0eYfiMUZmLO6o
uw+pro139zYJd4b7qMqAE1+b47Dtpn+rlCeZ4x4Hc1oKSmzWfWFa6Hqd0Slo
zuJ8QJdC8xgM8vvVwP3O6dpSgTZmE2cohuBw+ikv7hGROARoY9QAOzApbUCa
2nN6NxIVXA2VDNAsy6x0cq/jeUABzUVHg0ckOWIo5W7dbkNTSbk06ZbFTTv7
3OQo5Yn98Zy6gEpGpJMZHj6SGd4qZxZoObOskmzx4P8DaYUbXqk8AQA=
-->
</rfc>
Reference in New Issue View Git Blame Copy Permalink