c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
102a120d6505acc280d45fe1f058b0d7a9fb3f80
ietf-wimse-ect/draft-nennemann-wimse-execution-context-00.xml
Christian Nennemann 102a120d65 Merge tid into jti and make policy claims optional 
- Eliminate the "tid" claim; "jti" now serves as both token ID (for
  replay detection) and task ID (for DAG parent references in "par")
- Make "pol" and "pol_decision" OPTIONAL (must be paired when present)
- Regulated deployments SHOULD still include policy claims
- Reduces required ECT-specific claims to just "exec_act" and "par"
- Remove "tid" from IANA JWT Claims registration
- Update all examples, pseudocode, and DAG validation rules

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-24 22:39:46 +01:00

3462 lines
149 KiB
XML
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.5) -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc ipr="trust200902" docName="draft-nennemann-wimse-execution-context-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
<front>
<title abbrev="WIMSE Execution Context">Execution Context Tokens for Distributed Agentic Workflows</title>
<author fullname="Christian Nennemann">
<organization>Independent Researcher</organization>
<address>
<email>ietf@nennemann.de</email>
</address>
</author>
<date year="2026" month="February" day="24"/>
<area>Security</area>
<workgroup>WIMSE</workgroup>
<keyword>execution context</keyword> <keyword>workload identity</keyword> <keyword>agentic workflows</keyword> <keyword>audit trail</keyword> <keyword>compliance</keyword> <keyword>regulated systems</keyword>
<abstract>
<?line 85?>
<t>This document defines Execution Context Tokens (ECTs), an extension
to the Workload Identity in Multi System Environments (WIMSE)
architecture for distributed agentic workflows in regulated
environments. ECTs provide cryptographic proof of task execution
order, policy enforcement decisions, and compliance state across
agent-to-agent communication. By extending WIMSE Workload Identity
Tokens with execution context claims in JSON Web Token (JWT)
format, this specification enables regulated systems to maintain
structured audit trails that support compliance verification.
ECTs use a directed acyclic graph (DAG) structure to represent task
dependencies, record policy evaluation outcomes at each decision
point, and integrate with WIMSE Workload Identity Tokens (WIT) and
Workload Proof Tokens (WPT) using the same signing model and
cryptographic primitives. A new HTTP header field,
Execution-Context, is defined for transporting ECTs alongside
existing WIMSE headers. ECTs are a technical building block that
supports, but does not by itself constitute, compliance with
regulatory frameworks.</t>
</abstract>
</front>
<middle>
<?line 106?>
<section anchor="introduction"><name>Introduction</name>
<section anchor="motivation"><name>Motivation</name>
<t>The Workload Identity in Multi System Environments (WIMSE)
framework <xref target="I-D.ietf-wimse-arch"/> provides robust workload
authentication through Workload Identity Tokens (WIT) and Workload
Proof Tokens (WPT). The WIMSE service-to-service protocol
<xref target="I-D.ietf-wimse-s2s-protocol"/> defines how workloads authenticate
each other across call chains using the Workload-Identity and
Workload-Proof-Token HTTP headers.</t>
<t>However, workload identity alone does not address execution
accountability. Knowing who performed an action does not prove
what was done, what policy was applied, or whether compliance
requirements were satisfied at each decision point.</t>
<t>Regulated environments increasingly deploy autonomous agents that
coordinate across organizational boundaries. Multiple regulatory
frameworks motivate the need for structured execution records:</t>
<t><list style="symbols">
<t>The EU Artificial Intelligence Act <xref target="EU-AI-ACT"/> Article 12
requires high-risk AI systems to be designed with capabilities
enabling automatic recording of events ("logs") while the
system is operating.</t>
<t>The U.S. FDA 21 CFR Part 11 <xref target="FDA-21CFR11"/> requires
computer-generated, timestamped audit trails that independently
record the date, time, operator identity, and actions taken
(Section 11.10(e)).</t>
<t>The Markets in Financial Instruments Directive (MiFID II)
<xref target="MIFID-II"/> requires firms to maintain records of transactions
and orders that are sufficient to enable supervisory authorities
to monitor compliance.</t>
<t>The Digital Operational Resilience Act (DORA) <xref target="DORA"/> Article 12
requires financial entities to have logging policies that record
ICT activities and anomalies.</t>
</list></t>
<t>This document defines an extension to the WIMSE architecture that
addresses the gap between workload identity and execution
accountability. WIMSE authenticates agents; this extension records
what they did, in what order, and what policy was evaluated.</t>
<t>As identified in <xref target="I-D.ni-wimse-ai-agent-identity"/>, call context
in agentic workflows needs to be visible and preserved. ECTs
provide a mechanism to address this requirement with cryptographic
assurances.</t>
</section>
<section anchor="problem-statement"><name>Problem Statement</name>
<t>Three core gaps exist in current approaches to regulated agentic
systems:</t>
<t><list style="numbers" type="1">
<t>WIMSE authenticates agents but does not record what they
actually did. A WIT proves "Agent A is authorized" but not
"Agent A executed Task X, under Policy Y, producing Output Z."</t>
<t>No standard mechanism exists to record policy evaluation
outcomes at each decision point in a multi-agent workflow.</t>
<t>No mechanism exists to cryptographically link compensation and
rollback decisions to original actions.</t>
</list></t>
<t>Existing observability tools such as distributed tracing
<xref target="OPENTELEMETRY"/> provide visibility for debugging and monitoring
but do not provide cryptographic assurances. Tracing data is not
cryptographically signed, not tamper-evident, and not designed for
regulatory audit scenarios.</t>
</section>
<section anchor="scope-and-applicability"><name>Scope and Applicability</name>
<t>This document defines:</t>
<t><list style="symbols">
<t>The Execution Context Token (ECT) format (<xref target="ect-format"/>)</t>
<t>DAG structure for task dependency ordering (<xref target="dag-validation"/>)</t>
<t>Policy checkpoint recording (<xref target="policy-claims"/>)</t>
<t>Integration with the WIMSE identity framework
(<xref target="wimse-integration"/>)</t>
<t>An HTTP header for ECT transport (<xref target="http-header"/>)</t>
<t>Operational modes including ledger-optional deployment
(<xref target="operational-modes"/>)</t>
<t>Audit ledger interface requirements (<xref target="ledger-interface"/>)</t>
</list></t>
<t>The following are out of scope and are handled by WIMSE:</t>
<t><list style="symbols">
<t>Workload authentication and identity provisioning</t>
<t>Key distribution and management</t>
<t>Trust domain establishment and management</t>
<t>Credential lifecycle management</t>
</list></t>
</section>
<section anchor="relationship-to-regulatory-compliance"><name>Relationship to Regulatory Compliance</name>
<t>ECTs are a technical mechanism that can support compliance programs
by providing structured, cryptographically signed execution
records. ECTs do not by themselves constitute compliance with any
regulatory framework referenced in this document.</t>
<t>Compliance with each referenced regulation requires organizational
controls, policies, procedures, validation, and governance measures
beyond the scope of this specification. The regulatory references
in this document are intended to motivate the design requirements,
not to claim that implementing ECTs satisfies these regulations.</t>
<t>ECTs provide evidence of claimed execution ordering and policy
evaluation. They do not independently verify that the claimed
execution actually occurred as described, that the policy
evaluation was correct, or that the agent faithfully performed the
stated action. The trustworthiness of ECT claims depends on the
trustworthiness of the signing agent and the integrity of the
broader deployment environment.</t>
</section>
</section>
<section anchor="conventions-and-definitions"><name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
<?line -18?>
<t>The following terms are used in this document:</t>
<dl>
<dt>Agent:</dt>
<dd>
<t>An autonomous workload, as defined by WIMSE
<xref target="I-D.ietf-wimse-arch"/>, that executes tasks within a workflow.</t>
</dd>
<dt>Task:</dt>
<dd>
<t>A discrete unit of agent work that consumes inputs and produces
outputs.</t>
</dd>
<dt>Directed Acyclic Graph (DAG):</dt>
<dd>
<t>A graph structure representing task dependency ordering where
edges are directed and no cycles exist.</t>
</dd>
<dt>Execution Context Token (ECT):</dt>
<dd>
<t>A JSON Web Token <xref target="RFC7519"/> defined by this specification that
records task execution details and policy evaluation outcomes.</t>
</dd>
<dt>Audit Ledger:</dt>
<dd>
<t>An append-only, immutable log of all ECTs within a workflow or
set of workflows, used for regulatory audit and compliance
verification.</t>
</dd>
<dt>Policy Checkpoint:</dt>
<dd>
<t>A point in a workflow where a policy evaluation outcome is
recorded within an ECT.</t>
</dd>
<dt>Workload Identity Token (WIT):</dt>
<dd>
<t>A WIMSE credential proving a workload's identity within a trust
domain.</t>
</dd>
<dt>Workload Proof Token (WPT):</dt>
<dd>
<t>A WIMSE proof-of-possession token used for request-level
authentication.</t>
</dd>
<dt>Trust Domain:</dt>
<dd>
<t>A WIMSE concept representing an organizational boundary with a
shared identity issuer, corresponding to a SPIFFE <xref target="SPIFFE"/>
trust domain.</t>
</dd>
<dt>Witness:</dt>
<dd>
<t>A third-party entity that observes and attests to the execution
of a task, providing additional accountability.</t>
</dd>
</dl>
</section>
<section anchor="wimse-integration"><name>WIMSE Architecture Integration</name>
<section anchor="wimse-foundation"><name>WIMSE Foundation</name>
<t>The WIMSE architecture <xref target="I-D.ietf-wimse-arch"/> defines:</t>
<t><list style="symbols">
<t>Workload Identity Tokens (WIT) that prove a workload's identity
within a trust domain ("I am Agent X in trust domain Y")</t>
<t>Workload Proof Tokens (WPT) that prove possession of the private
key associated with a WIT ("I control the key for Agent X")</t>
<t>Multi-hop authentication via the service-to-service protocol
<xref target="I-D.ietf-wimse-s2s-protocol"/></t>
</list></t>
<t>The following execution accountability needs are complementary to
the WIMSE scope and are not addressed by workload identity alone:</t>
<t><list style="symbols">
<t>Recording what agents actually do with their authenticated
identity</t>
<t>Recording policy evaluation outcomes at each hop</t>
<t>Maintaining structured execution records</t>
<t>Linking compensation or rollback actions to original tasks</t>
</list></t>
</section>
<section anchor="extension-model"><name>Extension Model</name>
<t>ECTs extend WIMSE by adding an execution accountability layer
between the identity layer and the application layer:</t>
<figure title="WIMSE Extension Architecture Layers" anchor="fig-layers"><artwork type="ascii-art"><![CDATA[
+--------------------------------------------------+
| WIMSE Layer (Identity) |
| WIT: "I am Agent X (spiffe://td/agent/x)" |
| WPT: "I prove I control the key for Agent X" |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| ECT Layer (Execution Accountability) [This Spec]|
| ECT: "Task executed, dependencies met, |
| policy evaluated, outcome recorded" |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| Ledger Layer (Immutable Record) |
| "All ECTs appended to audit ledger" |
+--------------------------------------------------+
]]></artwork></figure>
<t>This extension reuses the WIMSE signing model, extends JWT claims
using standard JWT extensibility <xref target="RFC7519"/>, and maintains WIMSE
concepts including trust domains and workload identifiers.</t>
</section>
<section anchor="integration-points"><name>Integration Points</name>
<t>An ECT integrates with the WIMSE identity framework through the
following mechanisms:</t>
<t><list style="symbols">
<t>The ECT JOSE header "kid" parameter <bcp14>MUST</bcp14> reference the public
key identifier from the agent's WIT.</t>
<t>The ECT "iss" claim <bcp14>MUST</bcp14> use the WIMSE workload identifier
format (a SPIFFE ID <xref target="SPIFFE"/>).</t>
<t>The ECT <bcp14>MUST</bcp14> be signed with the same private key used to
generate the agent's WPT.</t>
<t>The ECT signing algorithm (JOSE header "alg" parameter) <bcp14>MUST</bcp14>
match the algorithm used in the corresponding WIT.</t>
</list></t>
<t>When an agent makes an HTTP request to another agent, the three
tokens are carried in their respective HTTP header fields:</t>
<figure title="HTTP Header Stacking" anchor="fig-http-headers"><artwork type="ascii-art"><![CDATA[
HTTP Request from Agent A to Agent B:
Workload-Identity: <WIT for Agent A>
Workload-Proof-Token: <WPT proving A controls key>
Execution-Context: <ECT recording what A did>
]]></artwork></figure>
<t>The receiving agent (Agent B) verifies in order:</t>
<t><list style="numbers" type="1">
<t>WIT and WPT (WIMSE layer): Proves who Agent A is and that the
request is authentic.</t>
<t>ECT (this extension): Records what Agent A did, what policy was
evaluated, and what precedent tasks exist.</t>
<t>Ledger: Appends the verified ECT to the audit ledger.</t>
</list></t>
</section>
</section>
<section anchor="ect-format"><name>Execution Context Token Format</name>
<t>An Execution Context Token is a JSON Web Token (JWT) <xref target="RFC7519"/>
signed as a JSON Web Signature (JWS) <xref target="RFC7515"/> using the Compact
Serialization. JWS JSON Serialization <bcp14>MUST NOT</bcp14> be used for ECTs.</t>
<section anchor="jose-header"><name>JOSE Header</name>
<t>The ECT JOSE header <bcp14>MUST</bcp14> contain the following parameters:</t>
<figure title="ECT JOSE Header Example" anchor="fig-header"><sourcecode type="json"><![CDATA[
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
"kid": "agent-a-key-id-123"
}
]]></sourcecode></figure>
<dl>
<dt>alg:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. The digital signature algorithm used to sign the ECT.
<bcp14>MUST</bcp14> match the algorithm in the corresponding WIT.
Implementations <bcp14>MUST</bcp14> support ES256 <xref target="RFC7518"/>. The "alg"
value <bcp14>MUST NOT</bcp14> be "none". Symmetric algorithms (e.g., HS256,
HS384, HS512) <bcp14>MUST NOT</bcp14> be used, as ECTs require asymmetric
signatures for non-repudiation.</t>
</dd>
<dt>typ:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. <bcp14>MUST</bcp14> be set to "wimse-exec+jwt" to distinguish ECTs
from other JWT types, consistent with the WIMSE convention for
type parameter values.</t>
</dd>
<dt>kid:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. The key identifier referencing the public key from
the agent's WIT <xref target="RFC7517"/>. Used by verifiers to look up the
correct public key for signature verification.</t>
</dd>
</dl>
</section>
<section anchor="jwt-claims"><name>JWT Claims</name>
<t>The ECT payload contains both WIMSE-compatible standard JWT claims
and execution context claims defined by this specification.</t>
<section anchor="standard-jwt-claims"><name>Standard JWT Claims</name>
<t>The following standard JWT claims <xref target="RFC7519"/> <bcp14>MUST</bcp14> be present in
every ECT:</t>
<dl>
<dt>iss:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. StringOrURI. The issuer of the ECT, which <bcp14>MUST</bcp14> be
the workload's SPIFFE ID in the format
<spanx style="verb">spiffe://&lt;trust-domain&gt;/&lt;path&gt;</spanx>. This <bcp14>MUST</bcp14> match the "sub"
claim of the agent's WIT.</t>
</dd>
<dt>sub:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. StringOrURI. The subject of the ECT. When present,
<bcp14>MUST</bcp14> equal the "iss" claim. This claim is included for
compatibility with JWT libraries and frameworks that expect a
"sub" claim to be present.</t>
</dd>
<dt>aud:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. StringOrURI or array of StringOrURI. The intended
recipient(s) of the ECT. Because ECTs serve as both inter-agent
messages and audit records, the "aud" claim <bcp14>SHOULD</bcp14> contain the
identifiers of all entities that will verify the ECT. In
practice this means:
</t>
<t><list style="symbols">
<t><strong>Point-to-point delivery</strong>: when an ECT is sent from one
agent to a single next agent, "aud" contains that agent's
workload identity. The receiving agent verifies the ECT and
forwards it to the ledger on behalf of the issuer.</t>
<t><strong>Direct-to-ledger submission</strong>: when an ECT is submitted
directly to the audit ledger (e.g., after a join or at
workflow completion), "aud" contains the ledger's identity.</t>
<t><strong>Multi-audience</strong>: when an ECT must be verified by both the
next agent and the ledger independently, "aud" <bcp14>MUST</bcp14> be an
array containing both identifiers (e.g.,
["spiffe://example.com/agent/next",
"spiffe://example.com/system/ledger"]). Each verifier checks
that its own identity appears in the array.</t>
</list></t>
<t>In multi-parent (join) scenarios where a task depends on ECTs
from multiple parent agents, the joining agent creates a new ECT
with the parent task IDs in "par". The "aud" of this new ECT
is set according to the rules above based on where the ECT will
be delivered — it is independent of the "aud" values in the
parent ECTs.</t>
</dd>
<dt>iat:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. NumericDate. The time at which the ECT was issued.
The ECT records a completed action, so the "iat" value reflects
when the record was created, not when task execution began.</t>
</dd>
<dt>exp:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. NumericDate. The expiration time of the ECT.
Implementations <bcp14>SHOULD</bcp14> set this to 5 to 15 minutes after "iat"
to limit the replay window while allowing for reasonable clock
skew and processing time.</t>
</dd>
</dl>
<t>The standard JWT "nbf" (Not Before) claim is not used in ECTs
because ECTs record completed actions and are valid immediately
upon issuance.</t>
<dl>
<dt>jti:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. String. A globally unique identifier for both the
ECT and the task it records, in UUID format <xref target="RFC9562"/>. Since
each ECT represents exactly one task, "jti" serves as both the
token identifier (for replay detection) and the task identifier
(for DAG parent references in "par"). Receivers <bcp14>MUST</bcp14> reject
ECTs whose "jti" has already been seen within the expiration
window. When "wid" is present, uniqueness is scoped to the
workflow; when "wid" is absent, uniqueness <bcp14>MUST</bcp14> be enforced
globally across the ECT store.</t>
</dd>
</dl>
</section>
<section anchor="exec-claims"><name>Execution Context</name>
<t>The following claims are defined by this specification:</t>
<dl>
<dt>wid:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A workflow identifier that groups related
ECTs into a single workflow. When present, <bcp14>MUST</bcp14> be a UUID
<xref target="RFC9562"/>.</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 the "jti"
value of a previously verified ECT. An empty array indicates
a root task with no dependencies. A workflow <bcp14>MAY</bcp14> contain
multiple root tasks.</t>
</dd>
</dl>
</section>
<section anchor="policy-claims"><name>Policy Evaluation</name>
<t>The following claims record policy evaluation outcomes:</t>
<dl>
<dt>pol:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The identifier of the policy rule that was
evaluated for this task (e.g.,
"clinical_data_access_policy_v1"). <bcp14>MUST</bcp14> be present when
"pol_decision" is present.</t>
</dd>
<dt>pol_decision:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The result of the policy evaluation. When
present, <bcp14>MUST</bcp14> be one of the values registered in the ECT Policy
Decision Values registry (<xref target="pol-decision-registry"/>). <bcp14>MUST</bcp14> be
present when "pol" is present. 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 recorded 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>
<t>When "pol" and "pol_decision" are absent, the ECT records task
execution without a policy checkpoint. Regulated deployments
<bcp14>SHOULD</bcp14> include policy claims on all ECTs to maintain complete
audit trails.</t>
</dd>
<dt>pol_enforcer:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. StringOrURI. The identity of the entity (system or
person) that evaluated the policy decision. When present,
<bcp14>SHOULD</bcp14> use SPIFFE ID format.</t>
</dd>
<dt>pol_timestamp:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. NumericDate. The time at which the policy decision
was made. When present, <bcp14>MUST</bcp14> be equal to or earlier than the
"iat" claim.</t>
</dd>
</dl>
<t>This specification intentionally defines only the recording of
policy evaluation outcomes. The mechanisms by which policies are
defined, distributed to agents, and evaluated are out of scope.
The "pol" claim is an opaque identifier referencing an external
policy; the semantics and enforcement of that policy are
determined by the deployment environment. Implementations may
use any policy engine or framework (e.g., OPA/Rego, Cedar, XACML,
or custom solutions) provided that the evaluation outcome is
faithfully recorded in the ECT claims defined above.</t>
</section>
<section anchor="data-integrity-claims"><name>Data Integrity</name>
<t>The following claims provide integrity verification for task
inputs and outputs without revealing the data itself:</t>
<dl>
<dt>inp_hash:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A cryptographic hash of the input data,
formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The
hash algorithm identifier <bcp14>MUST</bcp14> be a lowercase value from the
IANA Named Information Hash Algorithm Registry (e.g., "sha-256",
"sha-384", "sha-512"). Implementations <bcp14>MUST</bcp14> support "sha-256"
and <bcp14>SHOULD</bcp14> use "sha-256" unless a stronger algorithm is
required. Implementations <bcp14>MUST NOT</bcp14> accept hash algorithms
weaker than SHA-256 (e.g., MD5, SHA-1). The hash <bcp14>MUST</bcp14> be
computed over the raw octets of the input data.</t>
</dd>
<dt>out_hash:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A cryptographic hash of the output data,
using the same format and algorithm requirements as "inp_hash".</t>
</dd>
<dt>inp_classification:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The data sensitivity classification of the
input (e.g., "public", "confidential", "restricted").</t>
</dd>
</dl>
</section>
<section anchor="operational-claims"><name>Task Metadata</name>
<t>The following claims provide additional context about task
execution:</t>
<dl>
<dt>exec_time_ms:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Integer. The execution duration of the task in
milliseconds. <bcp14>MUST</bcp14> be a non-negative integer.</t>
</dd>
<dt>regulated_domain:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The regulatory domain applicable to this
task. Values <bcp14>MUST</bcp14> be registered in the ECT Regulated Domain
Values registry (<xref target="regulated-domain-registry"/>).</t>
</dd>
<dt>model_version:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The version identifier of the AI or ML model
used to perform the task, if applicable.</t>
</dd>
<dt>witnessed_by:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Array of StringOrURI. Identifiers of third-party
entities that the issuing agent claims observed or attested to
the execution of this task. When present, each element <bcp14>SHOULD</bcp14>
use SPIFFE ID format. Note that this claim is self-asserted by
the ECT issuer; witnesses listed here do not co-sign this ECT.
For stronger assurance, witnesses <bcp14>SHOULD</bcp14> submit independent
signed ECTs to the ledger attesting to their observation (see
<xref target="witness-attestation-model"/>). In regulated environments,
implementations <bcp14>SHOULD</bcp14> use witness attestation for critical
decision points to mitigate the risk of single-agent false
claims. See also <xref target="self-assertion-limitation"/> for the security
implications of self-asserted witness claims.</t>
</dd>
</dl>
</section>
<section anchor="compensation-claims"><name>Compensation and Rollback</name>
<dl>
<dt>compensation_required:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Boolean. Indicates whether this task is a
compensation or rollback action for a previous task.</t>
</dd>
<dt>compensation_reason:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A human-readable reason for the compensation
action. <bcp14>MUST</bcp14> be present if "compensation_required" is true.
Values <bcp14>SHOULD</bcp14> use structured identifiers (e.g.,
"policy_violation_in_parent_trade") rather than free-form text
to minimize the risk of embedding sensitive information. See
<xref target="data-minimization"/> for privacy guidance.
If "compensation_reason" is present, "compensation_required"
<bcp14>MUST</bcp14> be true.</t>
</dd>
</dl>
<t>Note: compensation ECTs reference historical parent tasks via the
"par" claim. The referenced parent ECTs may have passed their own
"exp" time; ECT expiration applies to the verification window of
the ECT itself, not to its validity as a parent reference in the
ledger.</t>
</section>
<section anchor="extension-claims"><name>Extensions</name>
<dl>
<dt>ext:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Object. An extension object for domain-specific
claims not defined by this specification. Implementations
that do not understand extension claims <bcp14>MUST</bcp14> ignore them.</t>
</dd>
</dl>
<t>To avoid key collisions between different domains, extension
key names <bcp14>MUST</bcp14> use reverse domain notation (e.g.,
"com.example.custom_field"). Implementations <bcp14>MUST NOT</bcp14> use
unqualified key names within the "ext" object. To prevent
abuse and excessive token size, the serialized JSON
representation of the "ext" object <bcp14>SHOULD NOT</bcp14> exceed 4096
bytes, and the JSON nesting depth within the "ext" object
<bcp14>SHOULD NOT</bcp14> exceed 5 levels. Implementations <bcp14>SHOULD</bcp14> reject
ECTs whose "ext" claim exceeds these limits.</t>
</section>
</section>
<section anchor="complete-ect-example"><name>Complete ECT Example</name>
<t>The following is a complete ECT payload example:</t>
<figure title="Complete ECT Payload Example" anchor="fig-full-ect"><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://example.com/agent/clinical",
"sub": "spiffe://example.com/agent/clinical",
"aud": "spiffe://example.com/agent/safety",
"iat": 1772064150,
"exp": 1772064750,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"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 "jti" 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 an ECT with the same
"jti" 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 ECT's "jti". If a cycle is detected,
the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Parent Policy Decision: If any parent ECT contains a
"pol_decision" of "rejected" or "pending_human_review", the
current ECT'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. This rule only applies when the parent ECT
contains policy claims.</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.jti, ect.wid):
return error("ECT 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.jti, 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_jti, 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_jti:
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_jti, 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", "exec_act", "par") are
present and well-formed.</t>
<t>If "pol" or "pol_decision" is present, verify that both are
present and that "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", "exec_act", "par"]:
if claim not in payload:
return reject("Missing required claim: " + claim)
// Validate policy claims (optional, but must be paired)
if "pol" in payload or "pol_decision" in payload:
if "pol" not in payload or "pol_decision" not in payload:
return reject("pol and pol_decision must both be present")
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 "jti" 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 "jti" 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,
"ect_jti": "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 "jti" 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):
jti: task-001 par: []
exec_act: review_requirements_spec
pol: spec_review_policy_v2 pol_decision: approved
Agent B (Code Generator):
jti: task-002 par: [task-001]
exec_act: implement_module
pol: coding_standards_v3 pol_decision: approved
Agent C (Test Agent):
jti: task-003 par: [task-002]
exec_act: execute_test_suite
pol: test_coverage_policy_v1 pol_decision: approved
Agent D (Build Agent):
jti: task-004 par: [task-003]
exec_act: build_release_artifact
pol: build_validation_v2 pol_decision: approved
Human Release Manager:
jti: 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):
jti: task-001 par: []
exec_act: calculate_risk_exposure
pol: risk_limits_policy_v2 pol_decision: approved
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
pol: compliance_check_v1 pol_decision: approved
Agent C (Execution):
jti: 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": "550e8400-e29b-41d4-a716-446655440099",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"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):
jti: task-001 par: []
exec_act: plan_route
pol: route_policy_v1 pol_decision: approved
Agent B (Customs):
jti: task-002 par: [task-001]
exec_act: validate_customs
pol: customs_policy_v2 pol_decision: approved
Agent C (Safety):
jti: task-003 par: [task-001]
exec_act: verify_cargo_safety
pol: safety_policy_v1 pol_decision: approved
Agent D (Payment):
jti: task-004 par: [task-002, task-003]
exec_act: authorize_payment
pol: payment_policy_v3 pol_decision: approved
System (Commitment):
jti: 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 "jti" 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>exec_act</c>
<c>Action/Task Type</c>
<c>IETF</c>
<c><xref target="exec-claims"/></c>
<c>par</c>
<c>Parent Task Identifiers</c>
<c>IETF</c>
<c><xref target="exec-claims"/></c>
<c>pol</c>
<c>Policy Rule Identifier</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_decision</c>
<c>Policy Decision Result</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_enforcer</c>
<c>Policy Enforcer Identity</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_timestamp</c>
<c>Policy Decision Timestamp</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>inp_hash</c>
<c>Input Data Hash</c>
<c>IETF</c>
<c><xref target="data-integrity-claims"/></c>
<c>out_hash</c>
<c>Output Data Hash</c>
<c>IETF</c>
<c><xref target="data-integrity-claims"/></c>
<c>inp_classification</c>
<c>Input Data Classification</c>
<c>IETF</c>
<c><xref target="data-integrity-claims"/></c>
<c>exec_time_ms</c>
<c>Execution Time (ms)</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>witnessed_by</c>
<c>Witness Identities</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>regulated_domain</c>
<c>Regulatory Domain</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>model_version</c>
<c>AI/ML Model Version</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>compensation_required</c>
<c>Compensation Flag</c>
<c>IETF</c>
<c><xref target="compensation-claims"/></c>
<c>compensation_reason</c>
<c>Compensation Reason</c>
<c>IETF</c>
<c><xref target="compensation-claims"/></c>
<c>ext</c>
<c>Extension Object</c>
<c>IETF</c>
<c><xref target="extension-claims"/></c>
</texttable>
</section>
<section anchor="pol-decision-registry"><name>ECT Policy Decision Values Registry</name>
<t>This document establishes the "ECT Policy Decision Values"
registry under the "JSON Web Token (JWT)" group. Registration
policy is Specification Required per <xref target="RFC8126"/>.</t>
<t>The initial contents of the registry are:</t>
<texttable title="ECT Policy Decision Values" anchor="_table-pol-decision">
<ttcol align='center'>Value</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='center'>Change Controller</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>approved</c>
<c>Policy evaluation succeeded</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>rejected</c>
<c>Policy evaluation failed</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pending_human_review</c>
<c>Awaiting human judgment</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
</texttable>
</section>
<section anchor="regulated-domain-registry"><name>ECT Regulated Domain Values Registry</name>
<t>This document establishes the "ECT Regulated Domain Values"
registry under the "JSON Web Token (JWT)" group. Registration
policy is Specification Required per <xref target="RFC8126"/>.</t>
<t>The initial contents of the registry are:</t>
<texttable title="ECT Regulated Domain Values" anchor="_table-regulated-domain">
<ttcol align='center'>Value</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='center'>Change Controller</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>medtech</c>
<c>Medical technology and devices</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>finance</c>
<c>Financial services and trading</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>military</c>
<c>Military and defense</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
</texttable>
</section>
</section>
</middle>
<back>
<references title='References' anchor="sec-combined-references">
<references title='Normative References' anchor="sec-normative-references">
<reference anchor="RFC7515">
<front>
<title>JSON Web Signature (JWS)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
<date month="May" year="2015"/>
<abstract>
<t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7515"/>
<seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>
<reference anchor="RFC7517">
<front>
<title>JSON Web Key (JWK)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<date month="May" year="2015"/>
<abstract>
<t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7517"/>
<seriesInfo name="DOI" value="10.17487/RFC7517"/>
</reference>
<reference anchor="RFC7519">
<front>
<title>JSON Web Token (JWT)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
<date month="May" year="2015"/>
<abstract>
<t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7519"/>
<seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>
<reference anchor="RFC7518">
<front>
<title>JSON Web Algorithms (JWA)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<date month="May" year="2015"/>
<abstract>
<t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7518"/>
<seriesInfo name="DOI" value="10.17487/RFC7518"/>
</reference>
<reference anchor="RFC9562">
<front>
<title>Universally Unique IDentifiers (UUIDs)</title>
<author fullname="K. Davis" initials="K." surname="Davis"/>
<author fullname="B. Peabody" initials="B." surname="Peabody"/>
<author fullname="P. Leach" initials="P." surname="Leach"/>
<date month="May" year="2024"/>
<abstract>
<t>This specification defines UUIDs (Universally Unique IDentifiers) --
also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform
Resource Name namespace for UUIDs. A UUID is 128 bits long and is
intended to guarantee uniqueness across space and time. UUIDs were
originally used in the Apollo Network Computing System (NCS), later
in the Open Software Foundation's (OSF's) Distributed Computing
Environment (DCE), and then in Microsoft Windows platforms.</t>
<t>This specification is derived from the OSF DCE specification with the
kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have
been incorporated into this document. This document obsoletes RFC
4122.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9562"/>
<seriesInfo name="DOI" value="10.17487/RFC9562"/>
</reference>
<reference anchor="RFC9110">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="I-D.ietf-wimse-arch">
<front>
<title>Workload Identity in a Multi System Environment (WIMSE) Architecture</title>
<author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
<organization>CyberArk</organization>
</author>
<author fullname="Yaroslav Rosomakho" initials="Y." surname="Rosomakho">
<organization>Zscaler</organization>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>University of Applied Sciences Bonn-Rhein-Sieg</organization>
</author>
<date day="30" month="September" year="2025"/>
<abstract>
<t> The increasing prevalence of cloud computing and micro service
architectures has led to the rise of complex software functions being
built and deployed as workloads, where a workload is defined as a
running instance of software executing for a specific purpose. This
document discusses an architecture for designing and standardizing
protocols and payloads for conveying workload identity and security
context information.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-wimse-arch-06"/>
</reference>
<reference anchor="I-D.ietf-wimse-s2s-protocol">
<front>
<title>WIMSE Workload-to-Workload Authentication</title>
<author fullname="Brian Campbell" initials="B." surname="Campbell">
<organization>Ping Identity</organization>
</author>
<author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
<organization>CyberArk</organization>
</author>
<author fullname="Arndt Schwenkschuster" initials="A." surname="Schwenkschuster">
<organization>SPIRL</organization>
</author>
<author fullname="Yaron Sheffer" initials="Y." surname="Sheffer">
<organization>Intuit</organization>
</author>
<date day="16" month="October" year="2025"/>
<abstract>
<t> The WIMSE architecture defines authentication and authorization for
software workloads in a variety of runtime environments, from the
most basic ones up to complex multi-service, multi-cloud, multi-
tenant deployments. This document defines the simplest, atomic unit
of this architecture: the protocol between two workloads that need to
verify each other&#x27;s identity in order to communicate securely. The
scope of this protocol is a single HTTP request-and-response pair.
To address the needs of different setups, we propose two protocols,
one at the application level and one that makes use of trusted TLS
transport. These two protocols are compatible, in the sense that a
single call chain can have some calls use one protocol and some use
the other. Workload A can call Workload B with mutual TLS
authentication, while the next call from Workload B to Workload C
would be authenticated at the application level.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-wimse-s2s-protocol-07"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
</references>
<references title='Informative References' anchor="sec-informative-references">
<reference anchor="RFC3552">
<front>
<title>Guidelines for Writing RFC Text on Security Considerations</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="B. Korver" initials="B." surname="Korver"/>
<date month="July" year="2003"/>
<abstract>
<t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="72"/>
<seriesInfo name="RFC" value="3552"/>
<seriesInfo name="DOI" value="10.17487/RFC3552"/>
</reference>
<reference anchor="RFC8693">
<front>
<title>OAuth 2.0 Token Exchange</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="A. Nadalin" initials="A." surname="Nadalin"/>
<author fullname="B. Campbell" initials="B." role="editor" surname="Campbell"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="C. Mortimore" initials="C." surname="Mortimore"/>
<date month="January" year="2020"/>
<abstract>
<t>This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8693"/>
<seriesInfo name="DOI" value="10.17487/RFC8693"/>
</reference>
<reference anchor="RFC9421">
<front>
<title>HTTP Message Signatures</title>
<author fullname="A. Backman" initials="A." role="editor" surname="Backman"/>
<author fullname="J. Richer" initials="J." role="editor" surname="Richer"/>
<author fullname="M. Sporny" initials="M." surname="Sporny"/>
<date month="February" year="2024"/>
<abstract>
<t>This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9421"/>
<seriesInfo name="DOI" value="10.17487/RFC9421"/>
</reference>
<reference anchor="I-D.ni-wimse-ai-agent-identity">
<front>
<title>WIMSE Applicability for AI Agents</title>
<author fullname="Ni Yuan" initials="N." surname="Yuan">
<organization>Huawei</organization>
</author>
<author fullname="Peter Chunchi Liu" initials="P. C." surname="Liu">
<organization>Huawei</organization>
</author>
<date day="20" month="October" year="2025"/>
<abstract>
<t> This document discusses WIMSE applicability to Agentic AI, so as to
establish independent identities and credential management mechanisms
for AI agents.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ni-wimse-ai-agent-identity-01"/>
</reference>
<reference anchor="SPIFFE" target="https://spiffe.io/docs/latest/spiffe-about/overview/">
<front>
<title>Secure Production Identity Framework for Everyone (SPIFFE)</title>
<author >
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="EU-AI-ACT" target="https://eur-lex.europa.eu/eli/reg/2024/1689">
<front>
<title>Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2024" month="June" day="13"/>
</front>
</reference>
<reference anchor="FDA-21CFR11" target="https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11">
<front>
<title>Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures</title>
<author >
<organization>U.S. Food and Drug Administration</organization>
</author>
<date />
</front>
</reference>
<reference anchor="MIFID-II" target="https://eur-lex.europa.eu/eli/dir/2014/65">
<front>
<title>Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2014" month="May" day="15"/>
</front>
</reference>
<reference anchor="DORA" target="https://eur-lex.europa.eu/eli/reg/2022/2554">
<front>
<title>Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2022" month="December" day="14"/>
</front>
</reference>
<reference anchor="EU-MDR" target="https://eur-lex.europa.eu/eli/reg/2017/745">
<front>
<title>Regulation (EU) 2017/745 on medical devices (MDR)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2017" month="April" day="05"/>
</front>
</reference>
<reference anchor="OPENTELEMETRY" target="https://opentelemetry.io/docs/specs/otel/">
<front>
<title>OpenTelemetry Specification</title>
<author >
<organization>Cloud Native Computing Foundation</organization>
</author>
<date />
</front>
</reference>
<reference anchor="I-D.ietf-scitt-architecture">
<front>
<title>An Architecture for Trustworthy and Transparent Digital Supply Chains</title>
<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
<organization>Fraunhofer SIT</organization>
</author>
<author fullname="Antoine Delignat-Lavaud" initials="A." surname="Delignat-Lavaud">
<organization>Microsoft Research</organization>
</author>
<author fullname="Cedric Fournet" initials="C." surname="Fournet">
<organization>Microsoft Research</organization>
</author>
<author fullname="Yogesh Deshpande" initials="Y." surname="Deshpande">
<organization>ARM</organization>
</author>
<author fullname="Steve Lasker" initials="S." surname="Lasker">
</author>
<date day="10" month="October" year="2025"/>
<abstract>
<t> Traceability in supply chains is a growing security concern. While
verifiable data structures have addressed specific issues, such as
equivocation over digital certificates, they lack a universal
architecture for all supply chains. This document defines such an
architecture for single-issuer signed statement transparency. It
ensures extensibility, interoperability between different
transparency services, and compliance with various auditing
procedures and regulatory requirements.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-scitt-architecture-22"/>
</reference>
<reference anchor="I-D.ietf-oauth-transaction-tokens">
<front>
<title>Transaction Tokens</title>
<author fullname="Atul Tulshibagwale" initials="A." surname="Tulshibagwale">
<organization>SGNL</organization>
</author>
<author fullname="George Fletcher" initials="G." surname="Fletcher">
<organization>Practical Identity LLC</organization>
</author>
<author fullname="Pieter Kasselman" initials="P." surname="Kasselman">
<organization>Defakto Security</organization>
</author>
<date day="24" month="January" year="2026"/>
<abstract>
<t> Transaction Tokens (Txn-Tokens) are designed to maintain and
propagate user identity and authorization context across workloads
within a trusted domain during the processing of external requests,
such as API calls. They ensure that this context is preserved
throughout the call chain, even when new transactions are initiated
internally, thereby enhancing security and consistency in complex,
multi-service architectures.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-oauth-transaction-tokens-07"/>
</reference>
<reference anchor="I-D.oauth-transaction-tokens-for-agents">
<front>
<title>Transaction Tokens For Agents</title>
<author fullname="Ashay Raut" initials="A." surname="Raut">
<organization>Amazon</organization>
</author>
<date day="10" month="February" year="2026"/>
<abstract>
<t> This document specifies an extension to the OAuth Transaction Tokens
framework (https://drafts.oauth.net/oauth-transaction-tokens/draft-
ietf-oauth-transaction-tokens.html) to support agent context
propagation within Transaction Tokens for agent-based workloads. The
extension defines two new context fields: &#x27;actor&#x27; and &#x27;principal&#x27;.
The &#x27;actor&#x27; field identifies the agent performing the action, while
the &#x27;principal&#x27; field identifies the human or system entity that
initiated the agent&#x27;s action. For autonomous agents operating
independently, the &#x27;principal&#x27; field MAY be omitted. These
additional context fields enable services within the call graph to
make more granular access control decisions, thereby enhancing
security.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-oauth-transaction-tokens-for-agents-04"/>
</reference>
</references>
</references>
<?line 1747?>
<section numbered="false" anchor="related-work"><name>Related Work</name>
<section numbered="false" anchor="wimse-workload-identity"><name>WIMSE Workload Identity</name>
<t>The WIMSE architecture <xref target="I-D.ietf-wimse-arch"/> and service-to-
service protocol <xref target="I-D.ietf-wimse-s2s-protocol"/> provide the
identity foundation upon which ECTs are built. WIT/WPT answer
"who is this agent?" and "does it control the claimed key?" while
ECTs record "what did this agent do?" and "what policy was
evaluated?" Together they form an identity-plus-accountability
framework for regulated agentic systems.</t>
</section>
<section numbered="false" anchor="oauth-20-token-exchange-and-the-act-claim"><name>OAuth 2.0 Token Exchange and the "act" Claim</name>
<t><xref target="RFC8693"/> defines the OAuth 2.0 Token Exchange protocol and
registers the "act" (Actor) claim in the JWT Claims registry.
The "act" claim creates nested JSON objects representing a
delegation chain: "who is acting on behalf of whom." While
the nesting superficially resembles a chain, it is strictly
linear (each "act" object contains at most one nested "act"),
represents authorization delegation rather than task execution,
and carries no task identifiers, policy decisions, or
input/output integrity data. The "act" chain cannot represent
branching (fan-out) or convergence (fan-in) and therefore
cannot form a DAG.</t>
<t>ECTs intentionally use the distinct claim name "exec_act" for the
action/task type to avoid collision with the "act" claim. The
two concepts are orthogonal: "act" records "who authorized whom,"
ECTs record "what was done, in what order, with what policy
outcomes."</t>
</section>
<section numbered="false" anchor="transaction-tokens"><name>Transaction Tokens</name>
<t>OAuth Transaction Tokens <xref target="I-D.ietf-oauth-transaction-tokens"/>
propagate authorization context across workload call chains.
The Txn-Token "req_wl" claim accumulates a comma-separated list
of workloads that requested replacement tokens, which is the
closest existing mechanism to call-chain recording.</t>
<t>However, "req_wl" cannot form a DAG because:</t>
<t><list style="symbols">
<t>It is linear: a comma-separated string with no branching or
merging representation. When a workload fans out to multiple
downstream services, each receives the same "req_wl" value and
the branching is invisible.</t>
<t>It is incomplete: only workloads that request a replacement
token from the Transaction Token Service appear in "req_wl";
workloads that forward the token unchanged are not recorded.</t>
<t>It carries no task-level granularity, no parent references,
no policy evaluation outcomes, and no execution content.</t>
</list></t>
<t>Extensions for agentic use cases
(<xref target="I-D.oauth-transaction-tokens-for-agents"/>) add agent
identity and constraints ("agentic_ctx") but no execution
ordering or DAG structure.</t>
<t>ECTs and Transaction Tokens are complementary: a Txn-Token
propagates authorization context ("this request is authorized
for scope X on behalf of user Y"), while an ECT records
execution accountability ("task T was performed, depending on
tasks P1 and P2, with policy Z evaluated and approved"). An
agent request could carry both a Txn-Token for authorization
and an ECT for execution recording. The WPT "tth" claim
defined in <xref target="I-D.ietf-wimse-s2s-protocol"/> can hash-bind a
WPT to a co-present Txn-Token; a similar binding mechanism
for ECTs is a potential future extension.</t>
</section>
<section numbered="false" anchor="distributed-tracing-opentelemetry"><name>Distributed Tracing (OpenTelemetry)</name>
<t>OpenTelemetry <xref target="OPENTELEMETRY"/> and similar distributed tracing
systems provide observability for debugging and monitoring. ECTs
differ in several important ways: ECTs are cryptographically
signed per-task with the agent's private key; ECTs are
tamper-evident through JWS signatures; ECTs enforce DAG validation
rules; and ECTs are designed for regulatory audit rather than
operational monitoring. OpenTelemetry data is typically controlled
by the platform operator and can be modified or deleted without
detection. ECTs and distributed traces are complementary: traces
provide observability while ECTs provide signed execution records.
ECTs may reference OpenTelemetry trace identifiers in the "ext"
claim for correlation.</t>
</section>
<section numbered="false" anchor="blockchain-and-distributed-ledgers"><name>Blockchain and Distributed Ledgers</name>
<t>Both ECTs and blockchain systems provide immutable records. This
specification intentionally defines only the ECT token format and
is agnostic to the storage mechanism. ECTs can be stored in
append-only logs, databases with cryptographic commitments,
blockchain networks, or any storage providing the required
properties defined in <xref target="ledger-interface"/>.</t>
</section>
<section numbered="false" anchor="scitt-supply-chain-integrity-transparency-and-trust"><name>SCITT (Supply Chain Integrity, Transparency, and Trust)</name>
<t>The SCITT architecture <xref target="I-D.ietf-scitt-architecture"/> defines a
framework for creating transparent and auditable supply chain
records through Transparency Services, Signed Statements, and
Receipts. ECTs and SCITT are naturally complementary: the ECT
"wid" (Workflow Identifier) claim can serve as a correlation
identifier referenced in SCITT Signed Statements, linking a
complete ECT audit trail to a supply chain transparency record.
For example, in a regulated manufacturing workflow, each agent
step produces an ECT (recording what was done, by whom, under
what policy), while the overall workflow identified by "wid" is
registered as a SCITT Signed Statement on a Transparency Service.
This enables auditors to verify both the individual execution
steps (via ECT DAG validation) and the end-to-end supply chain
integrity (via SCITT Receipts) using the "wid" as the shared
correlation point. The "ext" claim in ECTs (<xref target="exec-claims"/>)
can carry SCITT-specific metadata such as Transparency Service
identifiers or Receipt references for tighter integration.</t>
</section>
<section numbered="false" anchor="w3c-verifiable-credentials"><name>W3C Verifiable Credentials</name>
<t>W3C Verifiable Credentials represent claims about subjects (e.g.,
identity, qualifications). ECTs represent execution records of
actions (what happened, in what order, under what policy). While
both use JWT/JWS as a serialization format, their semantics and
use cases are distinct.</t>
</section>
</section>
<section numbered="false" anchor="implementation-guidance"><name>Implementation Guidance</name>
<section numbered="false" anchor="minimal-implementation"><name>Minimal Implementation</name>
<t>A minimal conforming implementation needs to:</t>
<t><list style="numbers" type="1">
<t>Create JWTs with all required claims ("iss", "aud", "iat",
"exp", "jti", "exec_act", "par") and policy claims ("pol",
"pol_decision") when policy evaluation was performed.</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": "550e8400-e29b-41d4-a716-446655440001",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"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": "550e8400-e29b-41d4-a716-446655440002",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"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": "a1b2c3d4-0001-0000-0000-000000000001",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"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": "a1b2c3d4-0001-0000-0000-000000000002",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"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": "a1b2c3d4-0001-0000-0000-000000000003",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"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": "a1b2c3d4-0001-0000-0000-000000000004",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"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": "a1b2c3d4-0001-0000-0000-000000000005",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"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": "f1e2d3c4-0004-0000-0000-000000000004",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"exec_act": "execute_trade",
"par": [
"f1e2d3c4-0002-0000-0000-000000000002",
"f1e2d3c4-0003-0000-0000-000000000003"
],
"pol": "trade_execution_policy_v3",
"pol_decision": "approved",
"regulated_domain": "finance"
}
]]></sourcecode></figure>
<t>The "par" array with two entries records that both compliance
checking and liquidity verification were completed before trade
execution.</t>
</section>
</section>
<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>
<t>The author thanks the WIMSE working group for their foundational
work on workload identity in multi-system environments. The
concepts of Workload Identity Tokens and Workload Proof Tokens
provide the identity foundation upon which execution context
tracing is built.</t>
</section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+W963LbZpYo+h9PgaF/hOwhKFGWbIfu9GxZkmNlLEstyXFn
MikNSEIUYhJgA6BktuOp8xDnAfaz7Ec5T3LW9bsAoCSns6t21U51JzYIfJf1
rW/dL1EUBVVazZNR2Dn6lExWVZpn4UGeVcmnKrzMPyZZGV7nRXiYllWRjldV
Mg33Z0lWpZPwQ158vJ7nd2UniMfjIrmFQT4cn1wchY2hOsEkrpJZXqxHYVlN
g2k+yeIFzDot4usqypIsSxZxlkV36aJMokS/jyb8fbS9HZSr8SItS3harZfw
6fHR5esgWy3GSTEKpjD8KIAVPA3iIolhJRcwRJFW605wB+ucFflqqevrBB+T
NTydjoIwjEIzWyiz0VP8ap7H0zCd4narNT2NZe93und+upqmVVgVcTqnv0/y
xXKextkkob8WyWw1jxF05bqskkUZBPGquskLmh/+H4bXq/mcIXJwUwCs4ePw
nUKF3siLWZyl/4hxobD5bJoskwyXFp4nZRIXk5ukoBfhk3Q+CtOkuv4fBrCD
aRIEWV4s4PvbBOc9f33wfG+4Z//43P7xW/vHF/LHb/ee7egfh8Nt/ONxdDjA
WeTQcAktj8udMloWeZVP8vkoCNLsuraKp3t7OvKLZ98+1Ul2d4Y6WpbqFGlE
BxDpmeAbF2fHr18fjWjvist0+El4VuTT1YSO9li+CF8XAGY8PsLro9ukWOdZ
EnZ5mF6Hx4mLWVKNwpuqWpajra1ymV5fJ4M03wLMLbfwMMtKnkbxOF9VWzmM
dJsmd1s0AOFjeB3PS0SBo/fR/nG0f3Dpr/Kc8QKX1z163wt3tnd2t4bPXnwb
5tdhdZOER6siXyaACmdxAfi0wNOOs6n+fJCvskk6D+fxOs1m4TS/y8KbuFjk
WVoCshWreVKGMHhcVOl1OknjeZgCgs/nKQBxAnvetz8cuz/sT6oNgEhWRTRP
Pg0SXFkM/9lK5ukWIPiWWbyzf3wWbT+Lhk/poUV6/CdClB5t3KNurg6K9xnA
C4Z4fbgf7QwPXp8Phz5UL/G/4c6wD0NME/z+dTJNCtijhXfZx+mqEL4Nj+bJ
pCoAZhN4YQJUoXzpPrtIZ1lcATaV7RC5u7sbJJPrYjDLb7cA6wrYwBatBZa3
NbmJl1VSRMdbQL70L/tbS5g8Gg5bUGUDlN4PLgbh6zyfEmwOi9Us3J8u0gzJ
Mu0IXj85fn18GB0f++A4TAvYC1w3OI3h7tazva2j91+JX4BCi7j4mFQl4E94
nWZA2RiZYPYVflWG3ZMUZg+Pj78KcaZpsSXL8tBmCGizFw33/ni0OTw933/w
Fu5s7ezt7eK+p+ksrWCrMAjDGf4MqJDOU7ooSEJwGguTEoAND7s4z++5Qzy1
f4d2oiH8b/ePBwbQpZPD84fAMXy+9Xx3j7AgmaYT2OQ0uU0nCR764fnv2CQP
6B/482gbz/yP3+Pp2dG7y6O3RydHl+c/+Vs9BQ56mcyTRVIV6/BimUyQGtLe
2zcFIyOZ5A8MNyjhw3Irhx/aaP+G7RzM89U0fEeMEPawWIIEAjT8Nexmqhfa
cNJyklYVMdi0AvwCYuQx2hxniIAQZGVM3C6qSHLTlzb9HgH6MkOFV4MoAkFm
jPRkUgXB5U1aAkeZ0PWGAwcMhwPfKCN2jw4uy14fTgTEqQqe4A6qnI7kg0pS
hgcDFTlZzas0vCB5KDzKblOgtkJJSEbrBe526aJNHRm0IYfhmEbOChJnwAHg
OSwuBCHkFuSGcFKsl1U+K+LlDQwATwFzEHni8qMVBQPgA0nRD5f5PJ2swwSl
lkkisJikJfMQxD8r64FkC5OH8aTIyzJgQaXKGcD42mKVCXbBkl6tGVBTPHWW
mhtwCgS4d2l105RSw8k8BqkIN/7Dxem78EMy5tMIuz98uOwFLGf14QjgJEsX
uWE78Rhlg4ZgGsKRgfiYVfD/AIk7QX/qCrjwzk1cheVqucyLyt0+CEBmikFA
MF+VAA84OGRBOMxkPQF4hgR8oJH73/dCMwvOXSRLoK4ILzyOQGXcSZoAtAvi
zuZIbuP5ircD4hcsA/YD60riyY05omCZw174nFDygXnhgAicG0Bu8PnD8WUP
vwvMK2eEKeb3M/h9VeLpIY6XQJDCEkQFfLAAuWNOH9dxLV2keOERJ/fDLLkL
31xenoU3SQzIBkwkmU/7gbljkdyxfohXkW7glDkO3mSEPk5GcI7neTYrAbuD
5BNqDwaneGhzB0A3gvOAS3WTESEfr9I5YeB4nk8+0skGcrIAcLhqQAIArlle
hWO4tlWZzK8R/2CKCu5h3z1+BGsgGAWKXnitgnY5YOKySKfTOaghT1DYNJI5
/P1JeJIDWJjsAeX53STDTBl+/tyinXz5okQAUD8fr8rKaHmkkBFJYZSqbkBh
nN08AkHMK0ETQQDstBs6ihL1g0mCJEH+GKpeFDSW62pNsGylvzf5nVlyGTpr
hoNHxM/hQSEUKIQDnocgc4KY5mCqLjcyO3KxPKJNRExHHOTEM3yT3yW3SBQb
qjHhX2JxJZ5O4RqXDjmNJxPgbFU8BsmpWgNc/j3L73BJdzd5CLIVEiskEKCs
sL5mxsITS4I7pDl3MbKkDNCO/iqEAJ/GS8DCZNoH3gq/JQQFRwkvkr+vgAYx
stwlBd7XKi3hwk0bNCMkmgHbPTfE0eUmgIiTIokRnPM1fLSc52s8iDzLF/mq
ZMbENDKY5ECvQDI0TMFT4vH6EbcvUiIIhN5LUF3sHbIIXQJRoSuS0CFmiZAC
h0ZbBsGEkng64R8I/PdoenBXjH4KqIZvTmAVwx2QHgRwgHjp7CYqUmCR+8cu
sxjDqSdI92ABRFcn8ZIPGTYFAxCnwXNGEKHaP5HV4TO4LYBQdIE783xWdnpw
eOmctgjf8jRI/ET6zmYD3RLrQ4f7oOeFoAOqNgd7cfRC2I1uAIabkJAF6hfs
HIdDdKlSYBtVvFi28rjUGlnma4IGMSA8AJTx+PO+rA4OQ68DMxxGZBgqhrsE
X3cvEkbt4XAw3O4mvZ7ZzYnVrl4bTeLY0a6sEmf1LBjy82fV+ZytAh8pfE6u
CEFijpUCESik7aGoI1tGBlGurhFViAvnIisgv0eiVSJlZ4FWjxgnAk0ZAWCv
nNnaoShQp44CdW4VKMQ/1pVgM/jfjRhoVSwCMsyNM9/EABPAnRniExEE+gG3
wptGEfjgkg7jlr+is4HbGs/x3m2SdF1BNlRBlui4J5fSPRdyRxMn4SxewrWo
7hKgoC2UMpveRxZlCoewK0l5yYKcXZQcKpNGeB+oUQooDcdNT0SAxfnq1FJE
p2QKu98vZW1EDOFjZkWbTW5fvvSFs4ixFL5pSuNIoJRAANakiEK4FBLviluY
miWSQKXyGJRL4FVZWi7wM+UgtGeHfAuRccWqIC7LVYFIh6cJwgSwMJhuEV6g
OI4f4RkXCUj+eUHHg1AEKQl3KwYbZCBFDmyAscrKxbKzQEgekNThvafky0xC
MMwJsToImAPwo+MiORAkCeZyZdgh2zo8S0u9Zf9Iph0aFQak7807jEawyEtU
Xf7WD4GZAN8744P+qY+DgpCFN+N0VQHtC/9j0AmCHZj0XY7KCvKeqQN3gooA
oF3UZkv0JnGbWSeCFU4TuZnoPooWcDxPefK2Ob1DJQAB4/hINAUwnsUyFFVw
CUU+n49jkFiNMoYjALSADgCFEPoG8x2pOJyPEe/kosHLORD5cgWLR5nCUSxR
/YX3QSLzDAdWdGR05mFIK03GKyY/iN9CCXEExgQjwzRVTwdvQU7keZGxxHj6
eNpNiDCn7dOgxLaKKLmlm8k3HZ8bfgyrc+Vx5m/lBAh6keZyVy4mwL3o030U
oSYCoA1U0UoU7XYAMgP0QtY8w+7nz0AlI/7bly89+BY0PkfhI10GcdfoeWsm
WwgI+HoazyJAvZQNIjyCYDfc1MlHRjcrT8AnjLERq8b8xbEofrhaoh6WlBuq
bOQs5NOfPzPpS+2HPNJ+5utr6D8A3mLUMfwUTUURv8AfuYwPFUOSIOcrWvA8
mc7gCPOl/M7iJJEsWodjdYzoW1kHnSR/THptcR1PktCTcuFrGd28gB+TdnUN
t4elb2T3cJ1RMCgNJuBDuJ2gq01R6yNQ0ckbZaimLJF6raAkXMcriXcgCv+d
+JLcL315EWdAGWifgE8FKmLTHKWVEKUxEBjLG2Pf8949AEEX5wFYzdPrBM0J
ifsGovR5Ijb+m3SJVOHcXoEDqxIErfqww4OQZk9ACmgxdMAWAS8WZTCW7dJh
WlG830LL5E5a1i/sWzVzoRQwIoAWsG+O7MBq2nVFG0CzblW2AQuuQcGB94ib
V+41hit/UBuG6LfzSWGtv0by8pWWAPk+0N+yb+Qt4jTwNTpJ+qG9sUyTZugZ
y2jKBShO+FIwTtZ5xpI04x1Zb+t2KlGfnW2alZZBfXN0lojrQEimLJQ6ChMT
Re+K9AOiojnb0UTiB+jQr8ayoooiyXZl4gCI2ItrWGRKPKHN0JieUmYIG4lB
RKYCy1h5q2tFA0/zYMPamleIm5HBAzu4kSnyCUk0U2JrSTmBa0d6jn7amJgE
QsBE1C9IfTavMu++jgFN0Du9dtR01M/I2KlajpxUhVcZsBAOJkPpDQCBBFIM
lbwl8kjiAC0vEz6IEY2njwVLmBYjfeHXgjGIa0iELcl01XRkbsiaULsk6YC8
ZsjEUtZ8iA5+BIDfkWLUOXl/cdnp83/Dd6f05/Ojv74/Pj86xD9fvNl/+9b8
IZA3Lt6cvn97aP9kvzw4PTk5enfIH8PT0HsUdE72f+rw9eicnl0en77bf9tp
3FdCaZahiYiD8EwgLwNztPjNq4Oz//U/h7sguf/L+euDneHwW5BW+C8vhs93
4S93QK15tjyDg+S/kkAKcm8SFySyoUgfL1FZQ8s2YP4N+ZPhvgE0//QzQuaX
Ufjn8WQ53P2LPMANew8VZt5DglnzSeNjBmLLo5ZpDDS95zVI++vd/8n7u8Ld
efjnfwORMwmj4Yt/+0tQ55VwAAvmGKuyhbgChyTBfBSMUFBwTEKqBPb5UrId
VxkrafGttkq5tSLllyQpsS+ABGxHqEb5n6ZFTjtBJAFVICWubgVw4WiA/KsF
CSGgEJSik6GaQLp8TnoCUrZDtdnvi83+e2uz57nYiG+lOWO7J2BtEuvuEKHQ
MASyCUPTegdIgA2JqYuKRhL8PaImr6Tm/vj8WaJYjOF0yny14Qch7T005hHf
BQTfVmQLsgS7zemAOjTJY29J3NLjX+LWI7xuoJIvFquKrCjznKxeeNeIdTRO
EwCFlq+EDs+o031GORQ4GwK974OCj303TCAC84ERmBlmjqpm5qazgQcbNwuK
iQGXGPxwhAw3A1NtMJazrZynZbl7YsU4Yp5I7s01+aa0wqSBDzELmJvFRHcu
x+rORnd3IvLuRfC/ZY72GTHm4KsOQP++Aqkzmie3CUZv+bIt3i6STw9pYm8T
OcB7Wfl4H2cbbLxrEdvwdG9i5NBmkynogWiqIS4MigT7BNEIIrFNgNH8hy9f
0N7myMsIiLRC9skrA2gV0wijS9ahjE7XnrVfNX5VGL1UqlXLiqQh4SZdg74j
2MbTaSqbqdmrkMsyMPZdo5ircX1+0lSmSEzn7xx/d3DZbmLb5MpxddIH3DQE
AzKxtOMZ7NzHNFVHup3jMF5wxGP4N6L57s8/dXru5C0eQmdmBwVF1FkWJKDC
7CiJxGWZT1ISqhhVyDCEKxCJm77BNxFtZUm0APIcRDf5sq6Y3aYxy1T3uJ5a
+I/vfKrzQVfqdLFBbH5I0okekRyNiF/lgVW5fTXTcRYxkd7gWqJDPjeKPhnU
xOBmzWm5Ue/TwjPOoc3IHLU7ziNcyQBVhLBY0n09r+lygVffptlHfM2zWyGd
UZOV8Qs4Bivi7XQtjox99wS9yKJicKiAgBDAhFeSqc3G05jH66QI1BBNMrSC
lH4yonXMhh8ag34BYP/3f/834OMkTeGyVcG/Rl/9z78Gv6mZ9C3N1tWb2Qs3
/vMbfoSfXY5C/+J1OdRytLVVTbfo4Lc+9TruN2f8DV+1+68MfvS7trRx2Rt+
uP3dkEOtSeBm5Z9974B74c9ko8OwpV8ECvAZBkBaMQZ1PzeIAjRw0PJ8cPM/
/lUgV6rwfGX3Hf3q/3DYsRxm0M7IXnztm+gnYOjsq1DGshsbEWLH1NbxPvpd
y4N7FXwehU+u01lEd63kYLTvTOC83n6PodJeys4XMcu6PqCVup2EvLohKH2h
G2X4wwfVwgOOBDDWf/xFxhPC4YjPfbHAMfErRWMRwcc1ZLpckYWMGiG/TjmG
4MkTTzo4Qym0BCHBEQ8iEk1L2Ow+CZY2cqd82H5rAjfQRmB5lrHrOSZsGPmH
UxMiE3Y+poDiIDrBSKDqhaTeGnsT8+vVGC6JsGu7L5g9X1iTyTcIp8uBO08H
RLyO2JloXIyLsttogRVMolZ0IwUeHzqCYM+bgAYdJ6HriTdhSSJm0KpJ7AWG
HIbqBfcXfuYv3Bhj5jN0+N4swq4HM3juwKxH64CxYd0TXoD90CrNSU3SZWh9
AHZN8R9EpRfxR3bCksFdZHS6kJnEuMzI6YGjVejcCzikkcWPuChSM1uKMj7q
feQ/bwRclQ12R6+cy5R0tupxg/n5j68wtLIRSTNCyvBnlNosu9n/i/umE10z
gjfPLo3+s68sq8Rzwo8acWA8PB5L4UtCqPdP/+IRF8cNYUgM7esNb/2iAlEE
BuiIeAcjJumttbt1ZZ89USfJYsBavPGBXnL4E2yC469YeuiNUA5GXQNDe1x/
JskbbFxkJ56AOHUimQbsn8RNdn1/N4wr4fmyaRmZnN41DzfnwVhWZp3guM+p
xhdaIwO6JUV/R0cY0UxELdn8lP08rC+5LIE0oE0Witd8gT8/cbxgTNQ2fICA
aI3ldGlyIHc89l42WQr4wYX9YA8UJRv7hdZ/jO69gG3Fc9FRYevwCQ/l/RCq
hQ8pi9GXkUUyISdKIPj0+cmvOWgO4vhinKpTWBoOsTwWMmDpsyEhcht/LUEh
/AzHSBQGk9Mudvaedfr4pFov8YnNFPvXX+8q/glJOPzEAQtxBBcpSqfRcOdp
J/jiXw9ekVwMs1DZzNGnGPUXvBswPWrWatYUO7dmBZQG6jU6B6hC/oaKwTDA
7AzcfRth3EwTw/DY6FGsM9Ag6pEimJiTfvHli6yOYIaGIMD/xDvETga6VAde
u1gvMIYdndC6DtBYk8Fs0A/f4LAIzjcXT1/s4t/3hju9BjKQNZPkJXGqwN91
VDRymLQZwhqYOCqSJVwdNavAMdYga5hYQpS+fsL4bMre/FVa3nD4SMgEmnkC
yjKYG1j2yc4J75qIEctsJ8YrQA7ykL5w+D5BDTEckKnl6GusXwUEvWEsIrDK
AQvD4X25wJzXczqv96L3CqEpSC2c5/nHcLUUQinOGW9ojPwzuFcz+OHNBEAc
sNMFLuZdpf5wey+X8ZokDrmOZTjONSg6Qs0VBqOoL1dMFAHSi2CqB6Pfa2+l
xT1B3mMH5WXWbQwt83pmXUUVjRZPswBDU9ekAQVByvYw5+guKrQ+nxbvz4/l
INnqZtJGDi6Ri6RwO2VsOTrHWmTFMEO/kKbDi/9l1NM/kyQcsST8l60/AyBv
/vJfNGVa1mlAp1yN8aKyYCgr8WVIeAN3or6K1p3AO78igtitIHtGcUrA01fy
Axc1Zp3YkUh1cbyKVMV6CSDhuElEB9YO6DbhqczTcUGhq8RdnUBV8VqgwEXm
TtqlOllz59QGmAZbv2PO9tBqApJcTD6/lgMUXy9bpNMlBix2y54PhlfJJEZh
m325aANFskXITi41jlBCkTUpy3imFlJi8WLTYSGzA890F+KUcliZMTDxHRYT
vw1UpOjlFB4ZV64u8BjNrkvMuUlJy0hRR48xdwee/wn+9yfSkdB0xyZ70OtS
RPU//WlEjjwxv+PB0VVgepixiCXSHNmSKWQZQ4c/VSo9y6aUBlTGrPYNi1BN
c5xxyfviohESZWMmUAtx6C5GoS2tVICSwBUgHuPkJp5f64nxjRyYjbMLCncu
X9gM8LbN448VG/vgH/YqzddtUptyuvgaCX4c/pqTbBvGld01OUTYjomkq9cC
LN2JY0i2i2ebLM6K6mN9vQtUl8eOfAn0kpBSZWPnmIyhzgT8OLEBuiwliHEm
5073RhZLCR6E8g6OMgz47f/8uWMoWMLCzwD2LpY2XEpH3mx/j6Mjt8RM8p+/
YOLDEVpPla1xvJYgFUdagNqP/mVr5yVPdKm0lTZA4DzOJJgQeDSpJnhcPRvI
ZtxWjs+RggxcAWGhwfUyCBuP+WrjeBaVMbqf4jkpPwfGEOcAs3f+mmY6PqTF
duBZx0heeBYay2K/p7tZkYW2UOcODscZ2vEYbZbjGEUBDMig7ehFQqoBI1Cc
PV18eOn/+3/+X7xORKptGQC5RbwGlmJCQ51k4SK8gxBWI7vvVgs4qskhbF1j
OdJFglZwZopmOUA96Z5OUTxVaUIdqLHeGBMY0g/LXBhOXMmyUGjC/Go8HLoU
1Y1aGTkahU5Aohz5Bd8xO05mMQoTwGQe3Aa8k4qxiXbkcIcW+VooO0mgeIRw
Tnv4r+FeuEgzcsMz0aDtcPD7HJO6ZA9LUIHhyLIpeVMxlSFWkYZ9jTEoNmSN
nGDCFcrJHwFLxAs/QfcQYgcsdMAikScIdbLxdSfsvgOwvEpgvKRnmTbCSk0s
hPhjl/MJdOunUxpHDAVtoaM6QQk9ma+DFagidNQSzv9rlbayagphns3zMTlh
VlkKSr1nHIN9O6RNmAMbbvBYXUYLa3//HuQrMX2RxIeFJ0hUvkjZv01uGcY6
ESRQj4+J2GMWErsvO7DeTqhez9JdAjuAnSV2+Wzo8KZJxWkavdoyXdMcfYCx
rHKtbFiaoQhIAs+JSyKxFWMiimmBBPzd3YDCLMu8QWV+DtgxBTaA7pqSkgfY
JVl5WEzUCPFLZTxQk+C+p6UR9uQMKKYKCQ863KZCcQLL3F7y1TKfx+PG18pU
JPsVOas5aEloUrpQVjnFCT150mYP+fwEL6+vhVhhX+R7igW5T30AkeiOdbKG
OExIaNi2c7TEa6j4C16CuTgD6QBAmHLEIhNOUxOdLWcl1CR3qcXKgGLwrgD5
Nt0N3KqktGm0MymczholmAvjZUOTKyDcyMbciczSETpxBRocEi42fEjMZXJV
xtdJtcags0k8n1ASw9U0R8mWMBJIRzJi0CrlQPaEkjR7+OFksQzNNOzoxjoh
IN4NgxLQhZ4g4G7zdErawXzOwf+GSfI73X0shKAUqkhmqI4XdLYKRCz3QkCE
C1OD377K/SUBEsNkzxze6wgyJP47ERh4LV2Xl4oiCRN6c560Urx9xlJCwQ8w
0m2ar8r52jP+4ZKyMFksUVKhtcEl5MwPjBkJizyXpREYsry+Bgc9T/Z/UskM
FQ+T9qdDlHKPJHLnyHqnPz/x49s33KQHE6XhJi2xGk/7Tbq88dBTgxV4NBRZ
RJ8hO6uxskotjFTCqIx42ZnMUwquvsLUBsAoxl4a7ep2SGhZV+eRMuGn8NaV
Zni4NG5A6zc/3bcR+AAAXNuEF3f7gSdrXHjkJfKZSFMOEqfGtifHBCMcahrM
j+7rxVryEiJdbqQ/oBcndOwN7vZp896eURJOKWZKlhNjGQjWNzqUv3SboPnz
sm2fmOsySZKphNkpWxN9J3azjfB2E5Gh/DAenlnXPcNfxyDscDqTfVmk31D2
WFaoAY+tR5lQppECJ14/SidnncNHAzgTZwq8TBLEShZx4chG8KXvgR9bS0KM
qmKJvgcWiDnPnQJjryWHUeM2ROnR0A2Kj8bocbFiym0N2RdRWhOpgE+gywQB
JJq5pQGOMKtyf+wI6SwdtG4fMMJu3xzQkitJXN2sFnF2hTQsudt4WDarF9/m
WX5dTWdEH8ckWeoWhLe27885I6uGsGMFTjSdN0DNuljM84a8SqlaZnWIzMFm
m1rmG1qVyuCR8+cMO4LHB3t9KMDahx+lfIisU9X0F7kS9nBwg5gfY2Iibd4R
yXeaJmij0JEmihYhdjTzKRPnPLPhn26OrsrmFIJoM5GF1IkIVjxoDDT6tJAu
+VtXkqnJogdCRYkCLlvqDAF3CKSCq8WQKJtD1cIaRFlgl7WapOraYh+jY9bm
D5g4LeJpslEwE6MmRlOBblDMU5VVmACw4smWTomf8IOAfelH83+JHljFlNPV
g3vCgHlHNtCAotloXyYtGVAvEAm37ycd5sYgQdZ1cyT1/KwBMXzGbaP6Yczp
Mq6pXe59kVzmArN3eAcvJSwQrmGVTlgNdGvcEPJYlyovHAPgrXSebEq9aGrV
ixjUSawEk61tQZ0ZRtrnhRO6IRLu6dn+FtysvB8eJKD69sO/7R+cvO0HSJtX
oGcswjKf0/Use5p7Yz3LG6KWnTQWw30cHl7zXpBFRqSwQ0zIPDbpJ5+foBgT
mXyUB0QxzQ2y+Suut8ZkQAZOOL7E4BvaA2QyiefqYOL8UCrEQtUUl1egPN5s
Vor8lFN815hbcUoar2+iTTi9JOzge5FxDY6QRz3bXRXzCDAqB9hF+ELHEfLK
mzja2Xs2ynbHf539dHNy/eFD/Db6++zTj8VfX8en/3l1+aksDnaPy+0fh+Xr
8eHdwWzWkfoo8D2ty3GJWjy26hcANikmsBIR1zXqBs04++/2w3ektxxrfUmA
7hscdd+Mem7kMVGlZNEds4OnL3Y78nxvuEPru9cDa0YIuJKCQxvNT8AK56hM
x6jK5BlacJ2NsvpC7Hi6aTbkuCg2L6sanMiAlsQfleBdvNnHKXV/J4d7fXo2
1EI09LmVN6UiBqDcbcJ17Ir4LsxBsqjKJpbAfQB0/N3oxmht8K1WOkksPmSO
MtDxEloRLRXdUe7BP8MlK0vHPrBZDaBrU2IkCdWBIG7sfKpZZaHs1yjb5HMl
dTrPrlNJWsC/AxdCTzcKYT2hFBR3eZJUMU32+Ymbvfs4KuFE2qtflYqLMo0w
YslIzA7IPq8WZW3fRKuSwtg/TTrLqnD3Koo0qaAp6vBAFjPKR7VXDr32WTLj
InWpjBsEpjzC1dRkRWzWv0y+igTNS7wxGkHJKEV3ABcDX4jmpCtoV7is2MVJ
GUHYpnGZRYoz1tO6goACJK/QOPcA5sgrLRrxPnkoT95ysCXhtGhPbLQxUO6H
6bWz7QHasShpAyA4Xtcm32/3eB777kUn0QMFVs/RqL40x6choidngUzZ14VJ
IBoMWHmYog4MORRf7EpcYwoTPN56Uxxke5MuynUxI/uK4AImRaUWIT1d9gK+
DBVEZThPaaHkFpH82EkeSXxNWqot/zWXQxISq7UV+s5Aat0nT6HrO5F4FTb1
lDU/JUPKem3SQotJcJHMMknIoCXzRPw+h7ISZrCaf+zUJ/QqSiE1TNv9EAhV
GTZ0hmU9FQvwTGLEO7/+BqsV8ONMozupbhOKkGTqjDSxl+tTMm4g1iforShz
2IpzPLgL8nBIHQRT8rSU+tqyeiGkhJz+6eoGZCKmlQe1qh7huaZHfH7iauCW
cLpPr5Rl1u7OqzyfJ3FG0BbrnCkHZpXGlJXGBxI02Dhh7IF8GRrLQH/OZm5I
em6Edn0id/y6gaA7VBDaTOpGcMs1sp+W3ZMxoCpWycCSQAdznESVVsdvR41w
ac4Z7VdpdsV69BUon9Ok0/Nsv9dFkkRM2LhIOuFZBsjxDx/PksU44QQV5bjI
PYxcxrhGd4ZkaRnDRTAKWQY1YbZKp+x/giNtggHB6fs+NgAqsFBleAVsCfdw
QDxlGvEN+IKVXLAshOP2LTWpKmCzkg2hSdw6Co6/FdUfrlO1jCnNSWjIXRZ0
kk/LDmnBL4n2Oc5KrmhnaJGnNYiDEfRRQzRJIZC6MDk518klQI51xyxmdycG
MhvG6uYeleSxkb/YK4gxyD6un1LkkRjHTVZCzvFIVB2Hea9q3IbeSKWa+4LF
GtJwIKEDwgOo2hH5R52pZXQ6bKDoOXvSSfMXnwUF0BmvRWlKdU0xroGAJGkM
faeSLX6DfpHShu+jWlaUiUo1sCLhB3y9EBEHJkaC9NYrijffrFWgnA8jB6sM
LRrserATO97ADgZkCJQR9XKiUsjH4jHr2QgS8ibfJuLuLOGS9oVwc4wvjI4x
v4HxnnjSoTtHaLPwaVz4cnf722fBeF0lYrLATyiCOBNeCby1utm06KA54F5I
CbhlC3DkZXGfus5TGpKFCh5Gq3QQx5Iw5QMxrNFFkdDeuhyeurELXoCkHGE9
LBnD50YbomE4akbdHqJdrsZf9T4Gcdz/vnr61MQ1CofPn+9sP9sd7m3TQ6Qt
5uFzeYgOLxh3b287ebG7vR0lO9+Oo93hdDeKnw+fRbu7z57t7e3CL9tDGBq/
uJOY6u3xcLIzfRolu9d70bPnL76N4vFkGiXX28Odp7t7+KQj84rjcIRaEtY9
BiELGEoSV9ZhibRzFP78C8+B9qyR4yliyo72bGVROx3lWNaUO3IMxeZXNZRu
hB6PaMAdsSXKDmCslw5Ed/d4nUb/HD1o8Wg1eNAkqkS7g7w9iLfjnV+vPuVX
e4vt9y/eXL569e7Vu4O3f3v1cfY8mkU/LZP0+x8We8925cQb2i8B0FNSzWGI
nghv7OBOyJ/ja3D48SKZYiEk/s5Tj9yziczZRLe7gx2DJFafwXMNNseKkXF7
S1SRIhoib/6lFp6PhroICY8E6HtX+ExuphOl/yR0c1suTT2uz0/cclySX1vL
qtGvXiNxbjUQq0mYmG3z83pCUcABAsPhtkrLjXLNynPY6CuhPu4YYuJKbYAF
Vvn+cKEZHH6iRuDGy3DShyqvNIwEw4viiJUQX9UNeuiCr1Avw0B41slQjU3z
adjtDEAQnNzEGKTKWXz7mqZVSgHzeGOKlnpBaCfN2ta6a1PA2onUb+RXBW65
Za9SsWQ6MZUOvj+6DLfiZSo0MiKnDR3U1nAwDN7kZTUK5Tda5MBB0KAlrStZ
/3Az/n6SDgYDDMseDFrrJfvvndF7LUlczkuoucJLjcQtWY6XuKUJaeRORIxg
vEX0JwW9HuHIwiollZGXwViU3KgXObV+YL7eeEKMl3O6Ceh0paJEHCjORoEA
0+7WjA2KRw+irvUccf6fRBYnhcbDYc7yQ2vDyLEqYJkP8PE2nXJFAAm2NgFj
S7FymmplaP76/NmVrenmgKaBrgqBEfktqRCM+yLJUoFZrRPgZdxuhYGvBupz
WReNKwnq0aQSU4XuQRl4qkqJiXRTxZFchTKgjOMlese3sGTSOlXdrMVsf1MG
vnOWctkweuZHU8CNvB1eDUaioafS6kiKE5BKGIf3VQySoFY6CbJluhFzsKs2
BSusK1hImFWl1bqxJLdtKrYncTCokTbKsPUDpzT1FGt2msKnGc/igdp67pEG
MWIFUmaYdUyUwUE0AZQVn45UGjfuJnGsW6OTxvogzC2Iqeggav+2KPoM1ZGK
kmO9KHYKkzEH3SOznrzr6p8Gl9KMylsBfDcS4jLspmJHsikHKAzgeoL2ipSW
1+gWOK55nCC8NNUZvYdBx8QKdhja13gl8zBJxcxgswPUykQYzisP3F1ZBPdU
ZFFmXSQ+x9UIgXEugTlHcZFSKEjdEEf3Wo6CtG2rM9SOraySpdYHvuQbjT1o
JJaSQzE42tPJAx8nGjFrNSWSnRwjOVdM6VY3SUuEIzFqktGleB9/LuTHQJts
SH6kZ08JnYm2Md4Ylt5orRqVymV6bcSEtdBzJIrk7UqMHlXdxds94gZr9aA9
NemqaogXPbBpC5IoqvmQzLE4dJJSB9zDt34BGoB32xV8coL56l5fi2Z6Peh7
uSJkMzHxfxbtepY7uMRb6vVyvssqm94LJ8w1vkwWIBBiWXQhR4IfTpA8F8cv
/Ikkvz7URMwZhcrbeIf6CETCpMQ1DbCcrzRkhpSF2aqw4egcjF7l84RM52HX
KaU3Cp9uh+Ij6g1ogEs+jD5xGCLtvNRR+F8SjQOLCf8MomM6n9KfuQwIzXWF
c12Zuf5LI0LM5BIXxumjdnk0gi8/v8QYclNze7YCyQNIGtk/0wkWcV2V2MFL
IM2nRL5j1fS4fwpGmBz477JpMV3ERTpfu2HQocZA+AWNu3JWieK/67Yi1Oz1
pcwrDWJX0I5XbJlNpAw6c6Y4lcglGmEDju2iSY7ZMAmwr20VQ8QI7AniCA4O
M1ZDFA0+h6sfkklcSKyiEsz6TckUQhbOVfu4UU1Fq+DYuXvuwZ6lFxLpqgGU
oxosKEJD864Yee+NCQSEaQ+Is3Cr7cQGOxspckJtO1rCAW00oBMKSNTXDWtT
cz598pBbX4iwF8fMEYNBLR8Nf9PCrSwwM4xwE404QVMx3ppJNBqhdpqUgbDZ
dh5qTjYZz0UWo0hgCpNSW7VJ5rHnppSGz86LhAMUeEaFz215PUwY4LTtCSDt
mSsUihEQZQrjieOVYfiAV5UtL4RjuA+JwXE8VhxeU0NI8buEnBiQSsVohATl
YJhS1IStTxqysQksqRsTl2WymuaoVpsSvKUhFo7EYNQQqUBivwuuVxk7oUxg
P8jhXSrRC/+6IlLSbyWkPaxMsrVlXxs5rA7ex9AC7HPgKiKaKQefXYAUEw5H
juTCIY/o5bu2gw70SHFNA6ADtK4BSBi9kYAUCCLAsCjyoktSH4hDvjDR6QXO
nDvmvC3xJMOyckqHfpOHiP1UKTF0nJtyCGwkaPids9pZUnXNBz1m9Ib64UVZ
zefan89fuZt0gISb2Pso7IT/Gm4akDjdX2h6Znqt5/S46bx4RrmvPtyejsID
Ir0mcQn0AhLmihjNd1QpfZFWuEisy45i13d4nbs9Cj2i6PjvEOuviIT7B7rE
+DsH42QEiYtu/LOIP11RQwN4+8pMC5CRebCeC26UxS59hESlDWsO0gIzWAq/
jqx4Fjjrjq3+GIMTBOZzCnUvQeI3t8jujjs6XtEGzQGW7h7btqbbpg3S/ITm
sDH5ZYDulW4Pj9280ralk/hTuliBtixAqp+Su6EWPLcrHvk4h79/911od1dD
LwRx84s00/Xr68Jg+F3dWzyd1m/P77ljgM7+PWugXvNw6gi4Ae82nJG8/Xj8
cyDGP1uk4nAJ11LnW0bUVldjEmeGpmulpUnttgoGCIswiMHVlTEniHuUIbtz
Jflv1GiikcdsqfjEBWXD0+6PanT5UczI0iudUiB0lowaUhQovLOtSCuZtU7l
WG0GHG9TrZfkILeNf4j2lDeU9ooMr5QGlGkZJNpWyvNZAiiyNJ5jkV6tTYoG
oORTheIVRWQDmcsLzP1LZMQN4TIioGP3mdo9C+r3zFdthtvwDwNDNDxSEelN
WDjBx1pw6ieoNiJHPTbSSmAE3o1+TWbH9UEZ/8qAoyGaOWksFWkiHrw+xUK6
WWUpCrk/ncJQyE3ZWv6jG0zw+Yln/2TjifvCmYop9RptojiX1nhSefaS0LOX
BF4IA1lL6iXFgPuJsWizvRiNRZ+oRy2/aOtL9YUyraXWOmzX1sjBMwIVD/VJ
tAK7nhK2XPxY67FAZabU9m2rA2H2Ta0ukaj0jQGoNl7bAEgJuRITd07hsghU
Cjcsm4WZRJ0z4ydSqrAxtKPGxeHHLL/LpBkHA8avTCTlhR0Hfa2u9B4luMBS
klu3+qFfAInNT7Qca0/TE2Tx3BxBDe6htsPbG+yIKlAHoVYf3DQliuqkTSeJ
CvK3gODTjbvaoImphMvqKsz2TUlDGVyFDbgtNN0xv6F6fawu2440po2MBBJP
Eu6/iDqlMzKawfrh6cHFGSMv3HUJouQpxivswhOulqgCoNkleF7DhHYkoxJD
ylFqhcZEI2sWYHxRG9qpWemO55bzEQsTfM/Wu1oFa4urFndgom/re7CVdbzq
KmrQ/YYrhZhWrcTTbT0aTveiQTgZhoyIfamQ4TYzdIsPOoM3SpDEJSV/SpDr
S/EZoWZOzV34qNjFKfVdNCXTWKG49oKf6xGn81WRsEXgg6rKpkKK+HpdC3/f
sVQyELy9M/LaDh4EA4DvcHvgwZeCzCT01oRFKqfSO0ShZ6TpDof+5zZ/ytSZ
yEwhCyAmPDmr/SUbHLo+gzbhX+R9Lm/yOdBnhwEbdi2wtdU2ekIh7532ekUe
IZrYY+sZNgHiJo2ZY74MY7wwNuTfQwYj+FBrT+SvbIesmSHxLg53DKDYZSeO
IIlB65J9rO8Yl/pSGoLyqYgmS4Qn1adM5vOIPT44NrAUDHikTC+yZ21Ihe57
3YGoykXb6PRrcxDJcfbjaNx83/5mYxquEhjTmTD7unGDqH29gxt+s0c7497E
WBSIwiKlK6fv4HIN/Ua2ogUa+cor1ly/Pxx17Tuz6HNyaG3or9Z3r+VUq0sV
2AskE9svmVEAB8cmQ9B1rMIexXzZkHjYj7zZO6ChdIHQCvMCdjjVfGna4HJV
LPOSqxuQRqP1y9zQOs4cMxHQ5hbW/c6mG6aNCO1zFjhL6E7sLnWYmeclETKW
B3EjDUJXYroJgsSr32tr3Ljuc5unYCL92O9DTIQG2N1+GnZB4RinUyB+PVTp
8Hu3Bq2tYoPp3DabAFZPj1kilNGGQfd9ZlPedUBT87hZWJF3JQlrvEAg8ON8
uq6n+8ZcWhngzLqm0FzsTM0ZfYHN6GODpDmYdoQh5eHSRbSAweXnY4tVV2Bt
avywVbZ+SMG1JBc3pH1rhNxslCSKcwUoi9aiq1+xQY2SUFD+N2jpJNJIvNkV
SALwEeOamixZ/GfBsSsyvZXnzbH0wu8Qg8sEJ9YFqE1M6DF/zSYa/vMA5Pnw
X75rSO+elYbvYbdzzCiD6q2VqtjGZAcEwQptLiLJ40GXV0Z879qXeq1TgFZ1
k47JHGckNGPZeysFQK3YFKgAj5ADADSASfYXmfQjG2DQ/GK/8cyctcW8z0hd
qBU37dSAak6Ax0aWLJgAB3Blfm0c3T1Gm9BTEfrOetuhpgdjPqmvkeKlqfMu
aQK8UjgYeH4lzxwo9ZtwbJ/3wtFEjINAxqsvwQrcsNRZJt084e7DsaF5C/50
BfQUZ2semINbgKzw6oAqELcsyea1LkDRoJqiRC+BJtZXJKVOVYpHqik1QwVL
+KAG8J7OSnVH2w6AhzJyLk/sjNiAhkjIYi61VEL6HJrJqRRoy4xIufhVae1o
6syYqp/1OR151t8gPER/NIt4FBbbbT9vlYxllAZAY6yzCZIsOUi6nHWRhyTX
yrasYNqrAZl94t4awohN57PkykjIG9fF5fdoQvKFxbO80zLHX+pz3OeH2DyN
t5U6HGoir5isVdUIf94kAf9izNf8ro8KNdu1Luok5ep4/qTsi6E/msWJz6xW
eKOrbXa54IuW4FzGOJgAUIrumKW0id61dZqv/E20fPmoXcIn2nDOfCprRdne
poV1HBs7n7r3CU+mpPdn1wXsSvftov0vGxan5NebiVTfTgP4qA90NRzNuiAl
wMaJ5PL8UJ6/0/D+xzgAWp2hrd6nVpSvqS8sd5ld7fvaitKVFj1lJJETpH+w
cqL7wNUk81JeQYGnGWY3Ek1DdQyrb6C4dUW24gGBwh1V9sLRBJ6TwpMonXL3
G2Q+DqZ3W1afkIfAT2ZnVUmiPyVckYuBKMHAGPO80fia/XhUSoV1DYEaV5ZG
rPcy/sW6tLHMCBxKwANrjCHFAlC8ri0n4EHAuNzJqLMOOOkL13yT33lBkzGF
bpb5HAMnRZep4QjWOGYXi+dIp0/piCRuwBwz/YEgSpXc3MMnmAJIG/oqga6v
zc5IVXaX6ZQ5DqYgwpWYZ7PQ19GRck/0tJO6AKrAuzycwFeF5IZZ3HbqU1w2
1V1T+zlwQsAk7tttYkxnIbfbhkMogUBskFjPesyqq9VoBR9S4Mm6l1Ya5Eyd
fQ4wgjqqtWB0vFN0XFmuPRhlkxyQQM3bZjfVXYL/dms6yXegBxexjfZyQ7KA
IkThUVzgRqfMaJwKxeI4MgWca8PADTb0IwjemmxrugIt6EA7fUd1BrTJgVMy
yhQcYRzwT4GpS8AlMGGU76meZ1gvfoohMRjRA/ifUFlVDV2NSYKU5niB1Ben
y8QAyXwk4q9W9WASbjDkRndRRNqsMB5E7b2HNWGxHnCptgSYU8zd6HKHkc7y
sopu8olTtF0CuFO31BlmfOLeNAVHujOY28HQkh6+pRIvDAFsD4eWgH+i1fWA
fo2KRzjNYe1sjqjX3zBRXdgshAvK1EPB4U3nUssdcArOieVB8IDpsRqnmrYi
jCcVc0DWdtcDl49JyBO6lPCiSFM1oV1TeSyF2R3ipb8ornvUiws7u54iKcQa
Xc/xyklvsmV7wXtx6XHxBjlOp2JDnAWe8ZDrNHuANo5aLoAhCU6gYFMrgFt2
mVr6AhJOvlrO2UE+j6hYWUsBP/KmCQRdhgbHVDtOYSP2U2re5klEdIYvQ0yA
a7AbSypb0hKAijgZAwYKtmS+VpV2a/kZkxWKNz5ECU2kpr6tfREYw+qljaGW
q6CG3sRfIe4Ca0kHdimMW69xjz5eUd5fA6cIGB4+cWB03UbrVK82ZuGAMKNu
Fa5BNi1bsi1cW6iY6UwxaTY0k/Ww4uI4tgayREfCeeBbnpcDN+n0cK7VAREm
Y4l6P3DvqFsUUKQTYcsosrktqKkCUHEdTxCkAs1UH9UzeN6XXPi2aXp3l755
1QEb7teumMYro6tsNxNu2swgMFITyHKcucN9QtyYfVigbaPtLRW7lNgG2L68
x5qUMgiQBdawHJNM5GZ5Bm6W5zyfUViLgZpJopI5UYF0bCDYwhikWWvIRVQA
ohdiQm2Ww3DrNt/z/k+U7+/0CseZyz5Vq8Kaa8IM/aJamFGdUio1SBg3MGDZ
D9xigrzEkjw3lMYma7FOadOUONW8TCeJCTkf1hLiS3quP5yZHzj900MWb2MS
A8LDS2THvrNFU3VwFJ5ylKd1svB520gSTnNQnw3fdgoBpCr2Errh51C4RMkU
14wBoyo3sJ/lTBoY0RJlHRSWQVzO4UjzTBLJHOGDM+VgvRxGpU3j8vzjakme
IPamNBehxeJM+BOKDRhWIdHdvBSzDIxuIKmJ9GoJ/jhuLR/ozaWygJYSs+fN
kQ255ygEAUAnpNIkZNDETAQqtkVY5zQIoTpuJKMR6zxJio+YdwVaHgUlNFcB
l1dhzwEbWIJSup03WlYENreOeRNlhk1XE7+qDDKolWUfQuuOMqz3dWHyAgMq
9q1yPf1IxR30SptOCNoZpV7ZgT+90uPujMLdHU6ln1Bo4leUTwilFd1V+lAx
h1rxh4km9N9XPwFBJTUUdHV3VJRCE4xP0x9ev//H8fBdelwOBoM/G5b8w4eL
v0hZCrWjXykzhQEwHpKryju45tVF6Oxs7zyLtneind3L4d5od2f0dDiATf+H
jErK7yO+2IMvaqn/wq/45MRg4R21k/ZPKVO6cUlQ9iJISHLYnDYvsQVNbs5I
IlIOR3pwr9Cwa0+0H+hB9e159KT/OfaYSyUDaAoCHxo/ClJoTdlKp8rIS/E/
rtG9Gs/QemICaHD5xhCmkVVqZKyoTap2tZwkm6MMHeEsroLGAnV/tjmZHyLk
95Nx1kTlewFwUsy3cuM6y3U2uQFBQWP3JG0raAIcB9QyMgywqayIpBsUUg6I
H35+AhwzwiqgpXZDLkVltbkWbkWbW+pWGNIX8MqCFXYSaW/yOxY9lGY22rnj
ftvFHsYNYN5yl92xWRoU8jsBaR7Gn650kY5RIV/Np4GRwW3tx1rRJN8qNk7W
uUCKMkMDrdZXb7UnvR5q7RL4CB2wcT3sMVp+tYx/wBXLVIs5zpwd9ElZcDiU
L4yy5BZgqwyNtHRbf3xh2n2STIkYHyYU73tx+PaA6jogEyCRH7kXvzLlV8r8
urpjEfE2medLEn9swF0Xh+j1g/1j5SFYGgVzpjml3hZHuCFEoEvogjVQ4TDU
BtJFgqo7BZgAesRzW+8ba1nafneB7YL9+fPrw/1oZ3jw+nw4dCIch8PBcLub
cDDT589H76OTw3P4XRYQeKL9NJ+sFpID5ilS7s7V4Y+HZUCj7X980OENQgKr
/XK72DAetsK118n9hfkChCgR8C3k95hLA4wl4FLo1N5E0tquXKBdIcoF1Dt+
ROgn/gNbtYcs816rhlAdEaKJhq/C7gEqRt9zP+q8uaQduyRdpL80I39egZC4
mie6pElOrg3toVRe3T4VZ8H9SzoIu5cYrkJ/ayznaWM5O/5ymIwkV1iv8Qot
lGZB9GSC1XbR1Wd6YDy4oMOw+2qVAndrX9FuY0VP/RWN8eMrweirGGNRY3L+
0qr4V6sP67ltXtUbSnQ8lxtyAncHOyfXVrXXWNWuvyoZT9elyzHLlIsncNq8
HP7BVMgPjZwFFwHugBZ32SIX15YMHy1mRbS7w555W4s1/HnT11y36O9xZEsX
/eJJLlI/KSqn84lKLvcRuo56UEQkdatJCIPg+hF0U032ga9sBdQLrS+xrWgd
5K8EBz1zhv0UnadkSCFhAH8iHAgVM6jovkoM076NILStG/joF3z02ImNUo3Z
8kLHImZ7ek8kKT9ZOslKag+c5QFRZZq0/Jgul6zkFQlpa+JFeRICbRUzB8lG
ONi5Z+wNgkM2sMWhU3WYzg23QANozwljTA0TZP0S2MvuplYyG7ravVJcb3tM
xrmgCMs2a9X0ktL2fEDPg1f6WrWfwO1IRsUaejYfxzdtZlPXzs0qvGtwkzpI
hqR3NxFvdB7+Bv+/DQyt7dapaeOdp6AaNkhc463dsNtOdhpv7oXdGinohT8T
ntnivVP/rl1P40i4Jl80BxOwLjTgBp6ZQRmnzX3tNWMG8Y0sBisQ7cnfQnql
RVRzwVi5ddITuIFsxf3suYsDh4VGmudum4jobbUNHyqt+kAzUemwlAW6qFbP
2xgkuEOG0ba76N7C2EF8Pl6zv7qH32tBWpAtYXnRPM+X/nW9TjNSkekQ+nzP
/DLJLdWIaWVOKQWvPbQ6PVRKdBr/kIsHF6pGd/QkO/WqQJJ0zHq4FjqHh4Ss
ESl7K+ztO2ORomZvDEIltUJ2qTo8EkMK+SalsNZEhb1BeTGg+Y38tp9loDkd
H4/CS7TzsdAl4lusyX2TRB3c16ZAy/3SrJll/zjaP7jEieDqoJg73BkBPlc5
xuJOKCiYisjHS54i5Wbr6CJLZzcRGU5AIubWLxQIy+5s8am2ULp7pt4dhcbf
L6DzLolpJpRT1UD0oJIeWIb5hCKRjBvdYQx2XvIIAPplE+xwdVnEnJniKwXX
5oVKXlDiaT3kEo5Om0fUL8sF29LbTcTC3LDcsUXbNn4VmCZBuFlnNIkLqV1k
4dY0sK3cX5fFz+mIzCofL43b7n640SvgvxSTbWQofMhFUF1h/BGSuG7r66Vw
iQW1kLFiuD65IlixxPuwDG4CFv4JEZzAL+swp2BA8vSedXjshvDO1OPbjKed
L19Jy06OXx8fRsfHX77I9VJbhM+OFPe0qZPuBGmJsgHGyzgzBmdiHhIErs5x
y//5qh+enu/XCAzfcm/tx9i0dSKdM4Ts3E+l3gptQg+2wJbbOCG/hC+maAyj
5TNxsqV6W6vCm/KA7i3WsuVUdSYtSa9CWk+OXwOiPoc6tNjFtd5bMXW733kl
wbVNLjU6q1Waw1qIpjIOfDwj5on4+FCx4HGcfbR6BRmATbBU2V4v+BGf1EsG
e5/4HbprRYOHe9t7jaLBw73h8GuLBn8rJYClZvD0KRYLjp9F4+eTF9G328Od
aJpcb0emYDA8adYMTqnLoV7eKy2349UNfowF/mnnFy3qy7VxneI2tv3kP1NW
2IMwa5cWP6Mc/T0K7PbSOo6tva2y/egRJfpr5nMPe53quW6R+4YJ3dZZJJy2
RSZr96CO7AEtoc9xHVJFjwgNlxSjmB7SYKw8KNa1wF5evblrvo6mohJTBJR2
snyBDRiApKQldSs7yKkjGyvALBnMzY9WIjBGvyazNhU0hU1j5R+Sg6xztVVn
9WQAUOms49SVAkyb7VGd3edIUM/mcYaep8dz++UcY3PxY8Pg8S+eBemRpjaq
RF/+Du6ugblcy740zJ3/WjP5PczcL6j87iM4+wYpIy5muXQ7NhZI+lsDKA+a
1s64k/IjzGo7/bDdwGb4h7Zl1jXJX32JY/OaLrhLI8phgoaNVT1oVmMUvlKU
dqQwGfIxhkfPJWfulvrjzAOVe1hVPIsLuBPJnOpflkhenP4/VK8CEQ35Oh40
xbOzbsllxKShKl0EfAlkGZGcEyl+Q6NrfU08IP6cmmricP2ahwe1LbjA32DN
S9bBiMZoYqyOWGv4CeTk11zD/riIhvS64fpkWjusrDmg4um04IrF2huHK2+b
950aYbgybW6Cm6PCCE/39nbURXJ5g0SVAqPm9QJjFf8WT6hqrTgcaR4iOVF4
EqM1Dokmh+h2U/5ZvgQd2VTwrpdKAHSRimlca9NrjskBfCUXw3EaJ6IsiFwG
aH1aqsEDrUTcdBKtBcDB0dvgTEwtHKjRC5E1L7UqH/uhA/WBcELxCkvQQkFD
i9qO1onFUuPWKHJkbeNGNFjPhn6YWMG1Ew2hxgq1b6CxM12yWfGeyfSlxKnu
GFD8RTzHWWCxEtrcLErMR3+B7ZP2tftSaOOBw89PNndmCmwYVb27lqszmCxl
aU3v9AcLqPc81tJMjc3Xa9rFsVlsFapKPTuq6hCG+6RhKwZgRnINCSfo7tQY
UI4xxJEYl2QFUi6jTDjosJZAAzB0WgOb3rzAmilVQjt/iomBqRzGp3CkfC45
MW44tBMSQxcHQUJL8Y5HZ7CWjLg07uapRjM3WsOi/Y286BSgbyIM5X1qNLgl
XRExwCYpazVvye5LU3P7Qq2IriNoHy/T2dQGMZJxuYptFjCTELrhICDhlUcr
noQeme6nhphWzZcD0T21KIvBIqfZWLPBmIzdDzbEPDrtqqjYhNdIwglhwqZG
4ih3A4icNnja3a6g8HTtjmY7CbO9FRb8Jr9DE2u/bcLNDepsQjkmQI44GJCr
GNsGc43udPwNJop4EfKeGrnEDgJKh2O36rwpWGJnsKiovfzoqLhR335W7/tH
EQa4TGeR3ENJEjARdHBLl9iTmd0sH8TCu+/0myMuBNRnc4s77q/EDJDRxCNU
oSVUpsGQB/mAIL+5WV+lPbO843ea9gUt9R8arfscqAnEdMLAba8H4zEbpfC9
pJJaODKGfFGrSmMr0ngf2sKySLzk0ytnsk7YJeeSxHygRUTdTKhaADVBIdAM
qpegsRmtx+vV1JZSOEFIep0SRnerbeYLfwf3kWC6lVIq1wFNIMWli0XpLFS1
OrHk6KLbLuCcu5Vwg2gq4WLwoh+Ycv0a2eSENfpBSy3OCuYFbsELJ4yYXRL+
rSYk0QzrQAtPt5AOumUaw2TK1ltcVdhIyoM7tQ2avJ7HVOhDLOVqtUPnnZua
MOcIs4K7RDfbQ3J9L5+GEWQpHL6lYQJbxEltlwhg4/vgNY5cOlRjongLS+eG
IukyxbLkGcgI/UChI9tWZZoUgQYWKuX0EKt2S8VseOqne52BNIh3B+tBlsL9
2ViWWDI7LnLKIuJCWyacR8QiU0TcGA5JjjISFukriyRGTgi811Y+tuXuajlo
ZFDNJXQflYt5POFErn8HqZP96GSBmKExhMzN6MmSj6hBM0jMbB5mayqReBac
2euGKYz8l4KOsZJK20ZUtk3I3Umc6N20bITtBuHmwN2wFrjruDidWmhmayP9
sRaOJk0Sl9yKljlc34YfqGRFTSXIjTnj8EKTb+DuRtJb2LkmKakIHLsvTN2l
CLM4y7i0bsU51ZTdwShrICUSuSkJ4+bNCmppjR5XPK5UPPvGE5PlWmAEZ7NX
k607YytISBS7xmSaHwJhEtaZp7NhLTeMVOO+NLI6py4fRr07MznRIVjEwanx
J5YxW7IHkwkC0y120wwtpfu8Mn0PlOijdrrsvn7W1p2nx9WV7qvRQ1nm162r
cFdwTxWmhLpnSM4q3WqnHFNgyjHhUtrKCaIw6xQPp+DWeTouYtY1YUxTZd/E
WogdbcPGNBeDkjT3SQdGKnfLqnmgPIVFg/KGsg1sK1HSQ2ul0fYit8gaXDwu
dsq0lrqLcsoPzchatxaadev1aRd0rJFKrwJ/WWWmVIep0FGOTJqHW8ZDzJLA
V+Zz7wTQScSWQp3UqUJHjXsSkyNMjXukzqpkA5J1Fr2vWpSDMh+lZs06cavd
NW28trOQjciV3QlRZVMZ7ceUxKVsJ7dgvZiIueI5WRViG/9ALTG4E5LXeUUN
7ZJUr+IAt3DNyRRjVrMJ/ZykF1PpHUGFvDoqUXohQTGQ6F04MU77lWFNAqC9
oA4uMXIMMAXItI0B4XXFDaATNzC4recDxv7aAJSTdIrlLc8MVH1VndYzSWz/
vAiXVxjr2oCzmHWegN7DfEW0PyDDvHx7QQIk/hf4b8aTlFozkuJlDfip51wg
JYgx+1SrEeOh55Mc9J/Px9HhIE2q64iLSJU7ZaS/fvnSD8xCrQEQc0+06r3T
TyDk3PsTLtpm+UspzQN3dzC0xfgsM7YdZRzPjjpxBjLgOGUx12jJgs6Yg5vB
8gDKXCudRUbFazZ0vL3YIrh07aIJur2RUhYg2gnq/x8j6swqhjbx/AKz2MKq
a11u1WcCZuwYOUW9cQtAU2Azm1K1Cq4Gp0ZzE0WEGNV1zS5UeVFNtzr0uYiN
d8preJIp1blF6kqNgflnFh0Y8VDOskZKKdLXyqVTdhCJLYtiB9XwSDcTSNcs
CRxSwyU44SaJBFuZStr4a4uhBA1rAQZp0GFsSNmgHt43hPdkLzSCXoG9hrmx
MZbcKbiHG/Cr7k2+4j5m0xjrq1F2IsiQNyVpkGd2j05DDalVgYLEm7iYUlyS
MXifUAggcI83FydUqQW1JKOXMp4z0CTNkKylDkMv/SQ40DmkBbMtg4ufvF9i
RNsKxZpKnPAM/n5TRJB8Y+TiEk/lWh5xbE7sKVdIc7PkzlQ6xhAiLK9EL2Hh
HzUOurJb3BiOjtFv5uYVS1RZyansWyS0VC6X43QSNzrPSqsdBg6d99VCbMni
Lsy265uvtfgYrq8TtNSFlHgKSZkjiLwmg9wBW1qDfbU0Ney0QF2o0wUguVcq
0taXhjVzgdtaIrWptuBzwrytwqRriXM8tXPJpdCSAWQ0NqxvDhKoFBEQ+6Il
FwzltUmlEo3LgSgA5YRvIF0zEZj4CjrKjaaaxySrNJSkthTHIHwoybFNV/rQ
1N1H4XtTZrrVNGINoaTHPGAKHZiSKH7e6IkCPG3uG9kuvKiVfeR6UbkUqu5l
W/Tg6KerCkv3jznqFVBwRG3k2VujlhottOB25TROGOpLSjqbKCMgbjAVMCBb
IoSKrNSiFNgwAOF6wSyaLvEmnUCI+aqKjRsLTuwTxjYAVQ049PhTuuC6AcMF
py3hgFh4Czhngf1DhC4iAI4udvae9biKQOD2bXyoAUPYbMAQbGzA0GjN9ZLj
R6XhgnRYQO+mdAfD6lamwUJTNBSsxVZNQDzwBpHET1eN2ej+2THzWBSnNYnP
tpEnEJsSDmWzioLteeAUUyDH2oaTMc0L7mI20mK9pVWB9AVrY2RC+6homPWj
mAoBHxNFCBN9HO6jgyaerE1mhbiVbXhylzSJPkc69Rim9RZDg+DAtsPze83R
paC+aHwReVm2OdGvq+lMEwTvY+smMxK3gs5F3bl4wN5dnnG6mJ4b9dOIH27a
F9zTtC9orY7UrHMkWy2XsdNWmL3DytTroeHeJqiygfACTBlJZ5hBS6sN/NUi
FjnTi9XQZfa2VZfyS42wFlONQoRMnC1NDFkXsaAMOO+EEjKs96M+L1IjKmIm
QYcLwlddtXjT6njDQUDI5uoFRhBR8F0pfRW0rrRWbBy0c1NynOuUKe+tNQ/H
rubYcwSQiQIUuEegWj7ppBa1zoJkJJljux3yrWckI+RUwJNQPJDCB4nX3hwr
Lm3Ga2tB4H6e3MuTDM62vnsItFPd7qiHmcpctmYI2vuDBvmzVZYrykVNuDiH
VHwBYMBxMWOXvrpiN4DtdWRnoVMam/sshbvb3z4Dzl1J8zpU/1ItUVKGP1yc
vnMvofMhypVMtFjFyq+DvZD0pJJNWCCc5JT8KtA1GbA9iighUXzSDChB9oa+
3iMJ6Fb7qBxmRg2GuR0lV5Em6WXfVbPQyNQlj1WfbTVM5WralAqK+LWbP73k
M+1az1XPKSXFBcY0vo1M8sbk63i+81UF79A6MPqyX/Mi9SRLYUNIvp9P8hiC
HbSXkLE10BlK7Esnxzviv/jeybcuxpCu2BymLYVXglDd9FgppAPDXOHfufNJ
Bwbjv/ZImhQJyJE80MpizJMu6lIrHNLOclBC4aXCqSFsXqfiTLh89c/gFyDh
qUgjJnXpiWvrtXfPjo97Fq9O0gyu6T80nAT3Hi2cZ182Sg7yViI5+nYG7QKv
qDqQugzG88mCq8v91NY29VwBUnCkIyZnDaWDQ4frcaNd8EiSwD5OcTZbofHE
xVuZm+qxetMaQqLeBHdiZ/ggARFtOuUyZJysxeKp0PzWOF2Zqvv5s/urvfHB
VL0LzHCoqR2KtBlL46pNcccSztHiFPw5ca5gQbX5ON6Eg3OxNd4CE5uRNKJA
aWzU2C+KV25ibPsBehFTJPuUKMLlbCix7Nav0yk42iTyQd0m0XdPkeFAOaXO
MT4UuuyfKyjmCfW/CBonjNmlMYf7ektLrBOYfaRB+/HI5aZWWsaI6qIwCHQf
YaLAtmgHkUTCBmzpA/EFSTklvPX71GhQ3XRqSzDmFDcWwTW4xPRZJAoq/A6C
E6ficjtVm4xgNChO+ZSkVk3Cisk7sRhsurIaFQgMlygZGQIqMtoTMEQF0wJR
tiaOgx1OJi0SC4AB1W1jIoqrcqlo1/e/S3CBUE0hD72gYXkqE4zEJP3L6D+i
jLJFxhriGXSBelOxLQDVkFI44U3JEib/omhy8SIW1EndHq+qgFMDdTxdqcsK
tGUhtWNUB4yBxb60mGzynWul70usDkkwH6/DvwPpZn8dJ1DrggP/YNWkrZZf
vWOO5Qj7gpv0HyN5Sslonw9zkVtaXqOCOnv6Aq+dx5PweP/dfptMgnnscXi5
XiYIhJQDbDmqLLUlK2xSdeG8pAYQG79KnA9V2STQaBU7QdnRr9c1ZzQuDhg5
rSKLF8koGHHrYXXHXqzGlfuj3+ohCEwxM9PTocTXsIFDEJxKdfDWH48yriVR
C+jFF16M0+qlU8QsDn/4IKFb8rcLp3WYFCICWcIrRaQlBukLk9EFgHsFMviz
3VUxjxJcQjIV9KTEL741BBu2sKBrAFvjkeUnuGiPQsZFXyTMRzYENpuQZq0t
oyeMhgXEbeIZIkk2R2eYna3UAepVpsEXPKwJgn17iGJR53hADEcwqILfNV+0
DlQbYEiKUTpxyv4a5UIC5VdisOEyyJikq3fIL0wY7FvK4/ALXMpJPIMp2KLT
LXuy6TB8nc4dncr95QRnqXIgRtf4DmEqHql9J2CBjlOoFyhpm4i6nKnzhAn3
9aogxllb08FNgXH5gIvvkizDMnuAWOiv+h+Z/n2AfV2OlRCs0PtEX56enJy+
wxvC/lwCMBUolRd4ffvEmTZMFQQHwMeFjxBfozePjy5fEw0hTfINa5KvqVaX
S0pAGGUtM3Jpx5ffSWFEYaUSUobGvFmj4Iwnfok+Lyz8faa+vS6urifreoee
WFncuhO0UiF+UylNo7Y23D7qGog/wqwAH8L0C/cmmF01rkQfNMebqlpGvI8v
XLQT6Qpb7+uQY0nzD4GcxAKnXKWrQyrwh2QsnUN5+oco9G/8HsNR/3JoxXR8
xqhyYFAFnp0bGf234LdRFEUj+rfzxxH8AFR9Ci+bzJNjWzXjN0I2+E+t6BSO
ZxJk4GdWeLcoi4S4yb0fApWFX6QzN31z7OgO938KmPWb6sfnK7j17atlzt34
1vZYMIMc6pNz7mnwiEE0ddEOcqRPjtUx+4hhjA21ZTGXzm/3DqRKM75HEiQp
pW/kiX5JWqkJwfJHUD0bXjxlyfOrh8BFwIOytDfRW85B47fHjEr4hUC6WiBW
GIrAuSPdRdlzR3LbKXjDuD4fRHNxER1b285jRjHMUFob0e0ywuuhPnt4IAod
uKKKDgSK/eOtk7cSD/6jefrwOK35r0gH3CzT1/N45o7Wqk23DUfaZ22wc336
iOGQJ/xGfiu2hJ6yvdC723U7HnyICXKU6yoPNT9uA6GmjDgx1tZv0I+sdCjT
of4Q80jvv1L2dYOq26AS6c66efBOYKg2R0i0EfgurL3XwUr8qyVXvLPCvlpO
QL/02JgVq6ne37+cvz54Mdx5RplsnOmSksZtHH3CdMxygLQS16B1Arj/MFZh
itv81mKkLFeTCSl3DxEtE5XWNgo3inmQgLZ02cHbdBezC46VQnUe3T+axToX
RdzmLhvO32LfuZGVhRQ00c9QkEgyE74OBTfM8H8hDkpZOPhAi8HZouAk6UuZ
xkeRUS1E8ptTK0fi1EpTyAYR6lG0HfU3tDbD0vSPvCCKH3vEGBYV6+jiouMm
XABMAiCFXN8DrSv8Ekp2MDKrVsn0uw4Fegj2crjZB026UQGm/f1LDeuD053c
pBhkiBbSRhwf/gr7ofYSNv4v+NoAQGO1QQ+fiXm7zleZuAGxDYIo+sZuhDXS
MDpMA+pAMblLiqCDwf6puPZJof03cTRQ2XnqgGHDWzRl8WOyhtdghnnilRbs
3GnOlx0PLrAO6YTKoS8+MFWM4AW4k7NErLQJ1bBa2HpnIAMt56sy8n1Lgcmm
qPUNUMXcq/lyikpluDPYltt/9GnCl02DrzvkRCB+2n7MFDL54tm3T+EI3Cr+
G0c2B4q2daYAFEVsJuvuY2p1z3ayw58crq5UQ9wNjpdDM6QzbsFKlE39qibx
nIwNASYjzyR0BEtljEI99Jj71FDF5Jt4fo3ECn5aDDoYuYqHS9Ek4oAsVxhv
kU4oPAqNu8mCwqNjHtY0QifFfr4OsNsIqDRdSnbitYt/1NTOjjFssKwoA0t2
Qi/2MI9TNlH68Zuhsx3XrE+RY7YYT8CJ/QWFwmd5ozxxX/HQVA3CPgaBlyxr
01jIIq1R6XQIVHNEItjMUoMxOthvEFjd6ziLYJxeyKFMINnOiIbTD2nWU7Qr
yBUQ2GA4zKg63P9+YKLt3cR4zV/FPgxpNqm0ryEqwI4nTCvAcZT3Fm2e7EAm
FAYD4Jhpm8BkB72k0GR1R+YgbPYm6UgFnMQM1zKS19VaTCjlOBQQjfqdFuKA
ycpTOG9suMSxs2RbliKADoUI1Lk76HDwjVNliu5Z2X5L+TY233apao4rjZy6
VRGH+Xz5gmlYy5hiZ320UyOeFHo26ZgTbjCO6My39PJTFjEd6ID+cXVnPIRA
vFYLolClxHrEkbWtYlofpj7rwGJ3tF2WxWPMESm0WseYK7EeZUJhbSlfWK8A
Fa4zYrTl8+AyACY00i62jonqNuT4RbrjfLVHLdvA288ZkTd47eyFIEf8Am4B
B2DZwulUBU9yNQ1U4ZKUqIJTpQOJDKKKEaZJlUojfU6mlByN0mY4mA2ZwBwq
yJg4a+Km3XANxlwMkTeHQTQcdzDi/Lv2I6E0C3MkVHkBD904lhoYqFGEGsad
Wgx5iRUv/VkA/nexlI3kkVcZs5WpcbS4lSOOqzq5k3D6GawDHcFAxzBQuxnw
h2m7+HxjdAXXaMBOHr5Jm8z0RpmV6rXCek0t/KDL927TlUNXLCfyowcbDdGS
cOgG89v+d5VpjZBOribVp06PQpzdxVlnFazHS7lRmoojthCI2JRUIhdnsUYE
N9fZUoY6R1LS0O1Iu2DGj7R0CCKFTlMd/fBvPsMFSBXhT8DyWJ5SD48Q1mBj
mgLMRnZFoqgmErLvNb/kEKXwjOvcnO0IlZWj/g+3Hiz6JDTfukc5/tL8Xbcj
ZTUAx9acSevARiJ3HKBIuyZtktloeYDUhxkqCqOdqroRMin9kaZcrOZ+ORi9
02ijizBDBSQdHIoTj/NIa++YNb6kmgegi8DVa2S00PEwv/VToLgfsXW0SGSw
0wbpUrw63VOA+2WCyAMSW28Dc3Lfgf2dnh29uzx6e3RydHn+k6oGski315K4
jgItsaoagGS8O4Vfp8l4xSURKRs1z9D9y9Cm+C7bibREwo8OJwxyqmJMHY/X
5ciqDI307UBcz4BtESHffTmoL81AAWf0RFzGFUP3uPMBeixNyG4p74sVuRbZ
GFBS7kvaU7srvF6J2wu28VvEOiDxz4Pc8shNOfh5vrYupmkg5W2A4lfEG7VW
r5aQokD9Zu8oLR8TmJ6X6nsnFbh2xkkrFeJfgvZDZ6rhe/MZLI02I9IBDWMX
bJySDwKaqtnHQwIcOS1XwvOLIpk7WaOvMICUBQzcmXtFOC18g7z2CmmJAcjY
jlLHdduWTbfD/dUCz+1bE5hVTyNGrom4ldIs6d1LDSlnWY61xjREo9HNTI9N
jtpE3/z+tmrAeZ3tShJcs58a798WNGYDVGA7qIUeyWw04pNCXxcHx5eXYfdi
RZH5BzSnaffVZ35IssFEOmBSdtUGOoaEmwfcZPEoJ2lVRe6vjtYc11R3U9ix
MquorJuczrzkdROsnBLJTEncxauYBYC84HuAHlKuRUsbCyilfFmV7kXUzSQa
90eX37+FktVOVUfDbotjUBV5Ko6LgXicUOtcFbf2vrmCdHC8gJYVa0WV2Fbe
p4oVTpws8TwXQA4csaABd5kKXhMfppKcfS5NYE0mCxASsWg+1wOxtS1JuGaB
jJLlOUqNjICcRmnYeVhT78ZrVgLZABs4mp0RdagWBzGhudNg1Fa4xxZ1BGxM
YhTziWYpt8OL4+jb0GHA1mTN6TaBXDZ+y5QHQeEAbhwGwVqhkqJnwy6G5OK+
ffZktPkQKUGVRwl1kHUw1toSaAhevSJizwnc4Q1L70/uHh04CCTFAt2gc2M8
ImTu1vzDvYBKRJPYRrPadk9A8WNieeUKD7lshVvg8gJAIFmzGzFP1gYsxG5K
fzhs4cPTAylmQdf4oEimLFptYAeb33cKKoobLB6jiliuxO4lAaGqOPQ1GE4C
eXp63+04zUZc+XWgtZi7hLI3RN6pV6Rvr2hk//YGajUjTEIN6IcPl1vUcozD
rZxALOE+fUkuMb0qiUDZRmIk5oithwPn/BaY30tpx412bIrDBkT2v2t/fZ9j
r9l7gesjHdmfEMMU8dJIv80DTpKEfQqvw6tsa9XyMXlJAn0uscD9HinWvs/J
/H3HgMWN7jo9N9zQDEaR/vx5LdqfquO018czCtKAWnki3XBqA95fRoXS4rUg
CrUIxUIpemEx57dLuXqh6aJIfTCwbeePpv20I+maBES/EgqIZ9iC80waC9RS
e7rCFcm6g/eu30xPYKhwORwjbsJK9nDHKK94rYxLaoeScA1Av8+q1wtZu6Im
fe6WQzUftPv3hq7lS/nM9+jgT5qZYgOczxVqEgfaipuR19oVxKwRnCE1xKtY
bwU+9VJFRBaMx2vRENA8cigiGZ+302d0hADn7twb5TRpNhGO8dw5Dl5Ti3Do
Rk9cjNrjRCRvQbbYk+altKXJ0UnguG/W4yKdjsI3eWVkQeLaKl720Yo7ZQns
ln4zIjKGbWqePMJakIp8erWw2w3gZoxuz6iU+r0bklmDsJ7OSlDy0Hn0QN6q
TVQ1GaxopKKwf6udlQskN2RZ4TRVG4pJdQjIK+KR3RFyiwj063nK6Yq6bion
QK17lxQayDYPPHUMjatveC8abi9QmpygbVwA7vugbFAob9INDE+JyiBBIVs5
zoKl82JJdsYDq0e/th9TPR4/JlOFZDVjiZxGhSDmR6ZKUND94fTiSLKdSCti
UVyCQ73aQEDtuXaQn62UtqwBLkSezeZrLrq+QjyctiT0oW3AXS4mnbCxWymk
yQpFp5itbYSZ/pRdSXKVC6cBe3iNLcA2GoE7uVyiDWWjQuMUPhaVY7GI0XpX
Uskzo/15PSvcfi9EW27hEyxyULQ1cTQqByaGBpXp5kMdrHBmUghfAmLdpMkt
B4Kb4bXqQeDkKdSIxyKJudmZ6d7Z0rDTxGhxzMG5bdaBwUlwhw90g/RCYMMN
+F8wADa82hmGB6/PMWCxCodDjDJx20tavcBteqRGk77peNHVfkoYtnbgUWCX
Y7J50jIAZlR+9xBXJfL62+GKj96HJ4fnMMejWih1teVSj0HSsK04WRL7xxE3
AcV6ihoKo7H1ZvL9YwwHxd4lg3C4Q9B6qL+S313pt0bDFJ9f1fumtE68C8Nw
U0XbPclMuzZz3Nt66Z7GSzjlSfr6+BAgh6B2bOwKMKLW6Em+TUs21nEPO444
vKc1TUtDMh0Tp8UGMw502zrJsGhoJmoiUdnoQeOiVEsYSm57R99Lc0gY13YY
G1juE/NCOFThJry8yyNOujUdqtpFd+n8IGXsS5ESQtMBnh3gHHmSTUvHFKY9
G0Zc3QL5gUTP19vLgBCMrUJIMuBuI8CK8Ymf/8I/feTWLCRVR3EE8m0krbm1
lQhNd8bdnR/qZNPsZE4hsmZ77c1sHvdVvZ9N8yuRW/JGQ5vtZ7vDRkMbePj8
axvaaBt3aWgzHk52sKlNRF1tsIFNNJ5Mk+h627a0aTa0uU5APL3CIgOY+4hb
9XrZ+F1qpBE8vXbF2Wlf163G5CUj7G7iCJBilO2O/zr76ebk+sOH+G3099mn
H4u/vo5Pry4/lcXB7nG5/eOwfD0+vDuYzXgQk83sDPL2IN6Od369+pRf7S22
3794c/nq1btX7w7e/u3Vx9nzaBb9tEzS739Y7D3bdWAgEdF4Brs79Lgem4xz
SJCcQUHtV+K5jwEv+6opYQhU371Wjk8CrxSbSjUaB6vVS2Xar8foGpY9jMy1
D+7D43vbMiEWP2vD4mdfi8U7fwAWmwYw3Gblq9sxDf12TNKsxek6bDrIPAbL
a7j14ttHo9YlGesxeQJZT61Z6mAwiLapY2rz0tb6lsqrO2G3Bpkez+PwjZ1R
a8dzEku1ifK+dDveaALCBUdk693UGt3W3L1z27IEse2hpM3Rs2mtka82W8b8
SuRIQ69PuOk7ff/dqXdMptuAUm6kbXfbr9Bjv6vfpNbvMKUOO3/+Tp4QD8c7
k6eAv4gG+K9t+y/5x+cJfJeu96L42fh5hD3NIrhM15FzmYbN27SpIe9mztDa
X/0xV+W+S0EveDkeOpWAPrp9Ohj+H8RYzC1GJN3xW8ejDPpPIKqPOI/CUf+T
R6EnKtJRscLS0y0YurPdgqEvtr8WQ3f+AAytt4H2Cf6jrkmt/x5lQGDNimkM
2sHV7dP/PdiLhwKgjm53BjV8eQr6o6WFl2hJ+ifwpXGSj0KZxlePwhqyQ7Th
S5t88OLZ1+LL0z8AX5otwb8aY3Z8jKGRqDcgAOHrhOAHsaYmP+zu7Tz1UGU3
7L5CmP8zCOIc2qNQw3n/AaTgXpPCu6PFrIh2d1qw4+mwBTu+HX4tduz+AdjR
3gr+qzGk1tOTR3VkyD+II7ZxqfP18Kfr0/zDzt+WB3snf3/x5uP3/3j36en0
7be3r+Ld8v2vR8/Tf6+2787+Y+JTnb2wy6YdFfVOqCNCYUS+r8Wuzaf/AJpt
/vABfHtITdlrQbS94Vcj2t4fgGhy0opqX41huz6GGYyVsxIy9E+1jX30qXj1
X2H97FzdSETQJrb19zjS6q/RsANf/PL7NSOn3altakq6y4iM11J1CbtnTDCR
suZz6Ned1PpeKF2Z+voHOwLdaFbe45qKspBrY5I6qXBByuX56ZWgUZWypTvO
oFXd2ySPb1T66uJR+4tPtZ65yxfbXwWO004k21/fC7s1VO+FPxPAbBOt6S9i
TcnIMSCxNXSqGQdfS4IZZRNgkaKkWJsuUY7nmQtMz+eOax6rMDzuilLoBMfy
4NgUuWRcCE6XXdN3oWZfFkt3YHqLkPLMTiHBAowb4WZ82q9E/Mm+XTyQARSj
Ztr1zGjqT0e2ianN4KexfsjTjfEZVt8mnyLm53CEd0v7UsFtKtfMHSBqTUzb
7RHYx6ksr9DrQAgROv/8J2KH+6CBrqGHlEGXC5XqP10+Hcdl1sPH8xQuAyDB
ujHhVm3CBiYbpMdCbz2HGeKvaF9ePs6+3NL23PgbHt0ovfbF7++TjgJ3mwnh
hW9CuB4mcC8mxGV2HyNS/b4+6R6MPT7HfMJdxs59emLt3aebRC/DTFQ+p/7s
Brq2x/HvlcEku9ljSE4fO4kJustN31avHTdFd1kUDgjHNeDe4LJfgtpv1611
/GljNsODfNf7k49Zfod4waEnG73V7Dij+HbppM4pyEgjcDWU1q6ZgGnh5AfH
84Aib/OWroJIQcQEyC2i3S6akhZoUgLz62aGtEmmyab2xzNqPSlZe072cvhA
9nKjhlagNbTSUjKag/8fYlNbU1s8AQA=
-->
</rfc>
Reference in New Issue View Git Blame Copy Permalink