c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
47f5f97c9046517b3f785a6b5b911b40bd7cec97
ietf-wimse-ect/draft-nennemann-wimse-ect-00.xml
Christian Nennemann 47f5f97c90 Rename draft to draft-nennemann-wimse-ect-00 
Shorter, cleaner name matching the companion spec naming convention.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-25 16:57:24 +01:00

2904 lines
124 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-ect-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="25"/>
<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 91?>
<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 signed, structured records of task
execution order 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 and integrate with WIMSE Workload Identity Tokens (WIT)
using the same signing model and cryptographic primitives.
Policy evaluation and compensation extensions are defined in
<xref target="I-D.nennemann-wimse-ect-pol"/>. 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 113?>
<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 record
what was done or in what order.</t>
<t>Regulated environments increasingly deploy autonomous agents that
coordinate across organizational boundaries. Domains such as
healthcare, finance, and logistics require structured, auditable
records of automated decision-making and execution.
<xref target="_table-regulatory"/> in the appendix illustrates how ECTs relate
to specific regulatory frameworks.</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 and in what order.</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, producing Output Z."</t>
<t>No standard mechanism exists to cryptographically order and
link task execution across a multi-agent workflow.</t>
<t>No mechanism exists to reconstruct the complete execution
history of a distributed workflow for audit purposes.</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>Integration with the WIMSE identity framework
(<xref target="wimse-integration"/>)</t>
<t>An HTTP header for ECT transport (<xref target="http-header"/>)</t>
<t>Audit ledger interface requirements (<xref target="ledger-interface"/>)</t>
<t>Policy evaluation and compensation extensions are defined
separately in <xref target="I-D.nennemann-wimse-ect-pol"/></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. They do not
independently verify that the claimed execution actually occurred
as described 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.</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>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>Maintaining structured execution records</t>
<t>Linking actions to their predecessors with cryptographic assurance</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, |
| inputs/outputs hashed" |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| Optional: Audit Ledger (Immutable Record) |
| "ECTs MAY be appended to an 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>In WIMSE deployments, the ECT "iss" claim <bcp14>SHOULD</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 associated
with the agent's WIT.</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
Execution-Context header is carried alongside WIMSE identity
headers:</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>
Execution-Context: <ECT recording what A did>
]]></artwork></figure>
<t>When a Workload Proof Token (WPT) is available per
<xref target="I-D.ietf-wimse-s2s-protocol"/>, agents <bcp14>SHOULD</bcp14> include it
alongside the WIT and ECT. ECT verification does not depend
on the presence of a WPT; the ECT is independently verifiable
via the WIT public key.</t>
<t>The receiving agent (Agent B) verifies in order:</t>
<t><list style="numbers" type="1">
<t>WIT (WIMSE layer): Verifies Agent A's identity within the
trust domain. WPT verification, if present, per
<xref target="I-D.ietf-wimse-s2s-protocol"/>.</t>
<t>ECT (this extension): Records what Agent A did and what
precedent tasks exist.</t>
<t>Ledger (if deployed): 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. A URI identifying the issuer of the
ECT. In WIMSE deployments, this <bcp14>SHOULD</bcp14> be the workload's
SPIFFE ID in the format <spanx style="verb">spiffe://&lt;trust-domain&gt;/&lt;path&gt;</spanx>,
matching the "sub" claim of the agent's WIT. Non-WIMSE
deployments <bcp14>MAY</bcp14> use other URI schemes (e.g., HTTPS URLs or
URN:UUID identifiers).</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="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>
</dl>
</section>
<section anchor="compensation-claims"><name>Compensation and Rollback</name>
<t>Compensation and rollback extensions are defined in
<xref target="I-D.nennemann-wimse-ect-pol"/>. 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 ECT store.</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>SHOULD</bcp14> use reverse domain notation (e.g.,
"com.example.custom_field") to avoid collisions between
independently developed extensions. 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>
<t>The following extension keys are defined by this specification
for common use cases. Because these keys are documented here,
they use short names without reverse domain prefixes:</t>
<t><list style="symbols">
<t>"exec_time_ms": Integer. Execution duration in milliseconds.</t>
<t>"regulated_domain": String. Regulatory domain (e.g.,
"medtech", "finance", "military").</t>
<t>"model_version": String. AI/ML model version.</t>
<t>"witnessed_by": Array of StringOrURI. Identifiers of
third-party entities that the issuer claims observed the
task. Note: this is self-asserted; for verifiable witness
attestation, witnesses should submit independent signed ECTs.</t>
<t>"inp_classification": String. Data sensitivity classification
(e.g., "public", "confidential", "restricted").</t>
</list></t>
<t>Additional extension keys for policy evaluation and compensation
are defined in <xref target="I-D.nennemann-wimse-ect-pol"/>.</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",
"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": [],
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"ext": {
"exec_time_ms": 245,
"regulated_domain": "medtech",
"model_version": "clinical-reasoning-v4.2"
}
}
]]></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
header:</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...
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 is performed against the ECT store — either an
audit ledger or the set of parent ECTs received inline.</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>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):
// 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>Perform DAG validation per <xref target="dag-validation"/>.</t>
<t>If all checks pass and an audit ledger is deployed, the ECT
<bcp14>SHOULD</bcp14> be appended to the ledger.</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
ECT store, 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 is 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, ect_store):
// 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 DAG (against ECT store 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; record if store is available
if ect_store is not null:
ect_store.append(payload)
return accept
]]></sourcecode></figure>
</section>
</section>
<section anchor="ledger-interface"><name>Audit Ledger Interface</name>
<t>ECTs <bcp14>MAY</bcp14> be recorded in an immutable audit ledger for compliance
verification and post-hoc analysis. A ledger is <bcp14>RECOMMENDED</bcp14> for
regulated environments but is not required for point-to-point
operation. This specification 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>
<t>When an audit ledger is deployed, the 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 ECT 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="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., claiming an action was performed when it was not).</t>
<t>ECTs do not independently verify that:</t>
<t><list style="symbols">
<t>The claimed execution actually occurred as described</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"
extension key (carried in "ext") to include independent
third-party observers at critical decision points. However,
this value is self-asserted by the ECT issuer: the listed
witnesses do not co-sign the ECT and there is no cryptographic
evidence within a single ECT that the witnesses actually
observed the task. An issuing agent could list witnesses that
did not participate.</t>
<t>To strengthen witness attestation beyond self-assertion, witnesses
<bcp14>SHOULD</bcp14> submit their own independent signed ECTs referencing the
observed task's "jti" in the "par" array. Auditors can then
cross-check the "witnessed_by" extension against independent
witness ECTs in the ECT store.</t>
</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>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.</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" extension
key in "ext" 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>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.
Extension keys in "ext" (<xref target="extension-claims"/>) deserve particular
attention: human-readable values risk exposing sensitive operational
details. See <xref target="extension-claims"/> for guidance on using
structured identifiers.</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; 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>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>ext</c>
<c>Extension Object</c>
<c>IETF</c>
<c><xref target="extension-claims"/></c>
</texttable>
<t>Policy evaluation claims and the ECT Policy Decision Values
registry are defined in
<xref target="I-D.nennemann-wimse-ect-pol"/>.</t>
</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>
</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="I-D.nennemann-wimse-ect-pol" target="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect-pol/">
<front>
<title>Policy Evaluation and Compensation Extensions for Execution Context Tokens</title>
<author fullname="Christian Nennemann">
<organization></organization>
</author>
<date />
</front>
</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 1230?>
<section numbered="false" 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 numbered="false" 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
Agent B (Code Generator):
jti: task-002 par: [task-001]
exec_act: implement_module
Agent C (Test Agent):
jti: task-003 par: [task-002]
exec_act: execute_test_suite
Agent D (Build Agent):
jti: task-004 par: [task-003]
exec_act: build_release_artifact
Human Release Manager:
jti: task-005 par: [task-004]
exec_act: approve_release
ext: {witnessed_by: [...]} (extension metadata)
]]></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 numbered="false" 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>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 numbered="false" anchor="cross-organization-financial-trading"><name>Cross-Organization Financial Trading</name>
<t>In a cross-organization trading workflow, an investment bank's
agents coordinate with an external credit rating agency. The
agents operate in separate trust domains with a federation
relationship. The DAG records that independent assessments from
both organizations were completed before trade execution.</t>
<figure title="Cross-Organization Trading Workflow" anchor="fig-finance"><artwork><![CDATA[
Trust Domain: bank.example
Agent A1 (Portfolio Risk):
jti: task-001 par: []
iss: spiffe://bank.example/agent/risk
exec_act: analyze_portfolio_risk
Trust Domain: ratings.example (external)
Agent B1 (Credit Rating):
jti: task-002 par: []
iss: spiffe://ratings.example/agent/credit
exec_act: assess_credit_rating
Trust Domain: bank.example
Agent A2 (Compliance):
jti: task-003 par: [task-001, task-002]
iss: spiffe://bank.example/agent/compliance
exec_act: verify_trade_compliance
Agent A3 (Execution):
jti: task-004 par: [task-003]
iss: spiffe://bank.example/agent/execution
exec_act: execute_trade
]]></artwork></figure>
<t>The resulting DAG:</t>
<figure title="Cross-Organization DAG" anchor="fig-finance-dag"><artwork><![CDATA[
task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating)
[bank.example] [ratings.example]
\ /
v v
task-003 (verify_trade_compliance)
[bank.example]
|
v
task-004 (execute_trade)
[bank.example]
]]></artwork></figure>
<t>Task 003 has two parents from different trust domains,
demonstrating cross-organizational fan-in. The compliance agent
verifies both parent ECTs — one signed by a local key and one by
a federated key from the rating agency's trust domain.</t>
<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 numbered="false" anchor="compensation-and-rollback"><name>Compensation and Rollback</name>
<t>Compensation and rollback use cases are described in
<xref target="I-D.nennemann-wimse-ect-pol"/>. The core
ECT mechanism supports compensation through the "par" claim,
which links a remediation ECT to the original task.</t>
</section>
<section numbered="false" 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
Agent B (Customs):
jti: task-002 par: [task-001]
exec_act: validate_customs
Agent C (Safety):
jti: task-003 par: [task-001]
exec_act: verify_cargo_safety
Agent D (Payment):
jti: task-004 par: [task-002, task-003]
exec_act: authorize_payment
System (Commitment):
jti: task-005 par: [task-004]
exec_act: commit_shipment
]]></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 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?" 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 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."</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,
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"). 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
under what constraints), 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). 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").</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>If an audit ledger is deployed, append verified ECTs to it.</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",
"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": [],
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
}
]]></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",
"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"]
}
]]></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",
"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": [],
"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",
"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"]
}
]]></sourcecode></figure>
<t>Task 3 (Autonomous Test Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "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"]
}
]]></sourcecode></figure>
<t>Task 4 (Build Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "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"],
"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",
"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"],
"ext": {
"witnessed_by": [
"spiffe://meddev.example/audit/qa-observer-1"
]
}
}
]]></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.
The "ext" object in task 5 carries witness metadata via
the "witnessed_by" extension key.</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]
]]></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",
"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"
]
}
]]></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:
H4sIAAAAAAAAA82963bbVrIu+h9PgU3/CNWLoERZsh2mu9eWZTlWL8tWS3LS
2Z0MLZCEKMQkwQZAyWzHa5yHOA+wn2U/ynmSU19VzRsIynZW/9geiS2RwLzU
rFnzq+tMkiSq83qWDePOyYdsvKrzYhEfF4s6+1DHV8X7bFHFN0UZv8irusxH
qzqbxEfTbFHn4/jHonx/Myvuq06UjkZldkeN/Hh6dnkSbzTVicZpnU2Lcj2M
q3oSTYrxIp1Tr5MyvamTRbZYZPN0sUju83mVJdm4Tvb2omo1mudVRe3U6yU9
fHpy9TJarOajrBxGE2pwGFGfj6O0zFLq+5I6LfN63YnuaWTTslgtzYg60fts
TZ9OhlEcJ3FmxzeW8fGneGtWpJM4n2CC9Zo/TXW292a28ulqktdxXab5jH8f
F/PlLE8X44x/LbPpapaCWNW6qrN5FUXpqr4tSu6f/o/jm9VsJjQ4vi2JuvRy
/MbQgZ8oymm6yP+ZYqA0+cUkW2YLDC2+yKosLce3WckP0iv5bBjnWX3zPy0p
+5MsihZFOaf37zL0e/Hy+Onh4ND9+NT9+K378Zn++O3hk33z42Cwhx9Pkxd9
9KLLhCG0fFztV8myLOpiXMyGUZQvbhqjeHx4aFp+9uTbx6aTg/2BaW2Rmy7y
hBcgMWtin2hhmSX6A0EMS58Xs3y8jk/u0tmKyRiniwnx5JwIWckHJx9q+pl+
Ej7ftgk60m5aTrN6GN/W9bIa7u4SD6bEA+P3WckE6NOS7RJv725naxrjLrfF
/BvfpLMq498df+BP8ln+uDw/ffnyJJwv74AsPi+LyWrMszhVssUvS2oLPCzT
vMvKdbHI4q40s9M+v2qZ39xk/bzApKpdcHRV66dJOipW9W5BLd3l2X3bpE7e
JUenydHxVTjKC9kcGF735N1OvL+3f7A7ePLs27i4ievbLD5ZlcUyo/mepyVt
qjlYHgunXx8Xq8U4n8WzdJ0vpvGkuF/Et2k5LxZ5RTuuXM2yKsZal3V+k4/z
dBbntJazWU6cNKY5H7kvTv0vjsb1FkJkqzKZZR/6GUaW0j+72SzfpV2+awfv
zR+fJXtPksHj1pUlJhlunaOZXJMU7xZEL2ri5YujZH9w/PJiMAipeoV/4/1B
j5qYZHj/ZTbJSpqjo3fVQ3d1TO/GJzNix5JoNqYHxiQaq+/8zy7z6SKtiZu2
sP79/X0/G9+U/Wlxt0tcV9IEdnksNLzd8W26rLMyOd0lGW5+OdpdUufJYPBF
/M9Uete/7Mcvi2LCtHlRrqbx0WSeL3Aa8Yzo8bPTl6cvktPTkBwv8pLmQjKH
VmNwsPvkcPfk3VfyF7HQPC3fZ3VF/BPf5AsS78JM1PsKb1Vx9yyn3uPT069i
nEle7uqwArYZENscJoPDfz3bvHh7cfTZXbi/u394eIB5T/JpXtNUqRGhM/1M
rJDPct4oECHoxtGkImLTh13083v2kHQd7qH9ZED/HfzriUFy6ezFxefIMXi6
+/TgkLkgm+RjmuQku8vHGRb9xcXvmKQ0GC7402QPa/6vn+Pb85M3VyevT85O
ri5+Cqf6lk6/q2yWzbO6XMeXy2wMachzb58UtQwxKS/Y06CiF6vdgr74sgON
p3M8K1aT+A2jAT6I6bAlGf6SZjMxG9rCiWqc1zWjjLwm/iJhFKCNAj0kJAjo
LOfTLqn5rDYPbfs+IfYVVEGPRklCaG4EeTKuo+jqNq/oRBnz9qYFJw6nBd8K
jbsnx1fVTo9WhDClAomoLnhJfjRw0p7BJEXOVrM6jy8ZFMYni7ucpK1KEgaq
O5E/Xd5oEw96b4BRtGnBZpR5DfaJz2lwMSGxOwJPcUUCPZv0YsgubpxOSpH7
zENp9T5ysJg+zkrmMwds6U3qJE7HZVFVMhIiqBAyosfmq4VyEXX9fC0EmWB1
RSnYoEekRLzP69tNSB6PZymhJkzwL5dv38Q/ZiOhetz9y49XO5GAyh6Rmlas
8pk4zhbpCBhgA4XHtDSElRc1/R95hPDQPD1zm9ZxtVouCzopvekT0LFd9COm
7aoietAC4ahBM+P1mABnPC3T5S3JwqPvdxy50XeZLUmKgrOY3gbQj3MaLIgN
mEIvE5WZJlvoZpnvx1Oiw6oCicFwFUkHXmZ8MCcQMJMVLNfLuuAx0diWZT7P
sfuqfqTwOAvh8diHx5mDx6Rl6YbAQKOPHx+A4Z8+EQ8cxYvsPnp1dXUe32Yp
GOomz2aTXmS3U6LbqRdj12nbfLhg02IBMBUmdTorFtOKGJm4FGjYspU0bdkd
o0xj2j+3C5bZo1U+YyYczYrxe17cSBeX0BDtKtrtRP1FUccj2qF1lc1uwILU
RU1brudzABYlUqYiVTa+MZiaaMlyZJ5PJjNSux4BV1oQTr8/is8KIrpIOBIy
v1s62C5joX9DG/v0yex34v5itKpqq9WyAsrSQ1a2viUFeXr7GfZijjCPRKRY
kKyw359f7RDZeTa8FBVUgXEGqaA/xkYPjDaG62uJNGwjam+LezvkKvbGTAuf
jm/jgj4ojRCiBZ7FBC8JkcVuH5jhJnZGNInIfsqTSESUeMyJNXxV3Ge0zXub
pgDmv8zxSjqZ0E6unNiK0vGYDrE6HRFIqtdEl/9YFPcY0v1tEROMgryCjKBN
JqqZbUvEcHQPuXOf4vihnmgTEEPwZyyMaXQXVpz5cp4eG5dZitnP1kTG5axY
g27FopgXKxXUItVISlNbhNmcGPdtDNgtfA6XJI9oAi+KOVO2WhHd0yoiOs3q
2zHtsJ4iv6zH/DErptiSY0jcf6xIGnqHTE+EKwRy5J03GOCc5zIhyQ0Bk8zT
9yAXGrRU7RPf8LuJ23bELPmCFzpdQn7mH+J8NluxRqAMxJKgzEAsnMbmdIi3
7d32U98/1GNzqDOjB2c0U1b5Iav4qWm6jEdZfZ8Ri7Wwkj/DTb7RLjzON4v4
nRx2blBKUGEdep7WP5/oSRLyzlGl/ZMI5m9VfG+1s3z61NPtpRYyemcTfSyy
bMKn6ojOR1pGWinuno+58i6bqFiODApJCUzThiUFbo7XzDbieSnz8Brw+Rec
XFFaVasSTIcVI4lK+5i6m8eXgCV4CetYZhmNuOQlAKWILzFbVVDBMWVBYiSr
5Dg2G0pnFilOIFg4eHAlwoNDliG2qyDwl7iD6MdLwochiVMWzvRSh02o9Fle
KUzO/5lNOtwqNcjv22eEVWiQV4QZ4r/10AidLNgrb1c1Aej4f/U7UbRPnbwp
ANKwgycenZkKPOGAoDw4C/S4z1m+eM/QxINjBu/FcxxOwiWWA2glHku/bd2B
LgsRBbwt+CjNSPg47kevtPa8JSEWArRremFIIBhtuSqXRcUscGJwQDECr+kG
on6LmZVZQXOA+PQ8iZRAOXJnprCwNMPIOxutplMjlGBfonGiBVl9Xnvzaoiy
PF6lA1L6hYKUYsWxwpsrYfA5Gq1TgmBlkt3xbhQhi8/pWOenMDofiAhtqjEB
3zIvdH9cjklv41ePloRgxkqgLdIOmhAf5Vt0HVZ1dmJB3XH340cgPfnt06cd
epfQrgd2GcSBkSzGVV4DIejtSTpNCHbmovRJC6eKftE3738ncK3stGKbOIea
EeGVuxelpaPgZBeL5/GVQ5V4FcptIg/oS0zEWTaZZiUj8fImJQTjSaUK78kD
iX1AXv7dUJrmUWXLFGfXbO0J5m24WtDjTTGbCbpAUwWxI22eyi44PqTdSFh0
AlTLNOQFtmCvAQb5yDA0ZpbGQMHqSfwffKzoNjIP09BIErDUJbYpATQnDBfi
rMKBnVe31lQRPHtMmAD9ENiY5TcZNKbMfwKce5GpufI2X0KOXDhOP3Z+lqgV
73vHC8TxmA7xFl2OpkgMM6+ikU6XVQQftWzboJ7s0tPXaB4qEKhFIi2t2QyS
3mkSTUWCSLNuVSaI426yEna2iQAdb7fSzj5uNMOo2HuldIYsZd0myotwpJck
JekoAdsS2uNDhd6GvbcXu40pomcKIz/jPSJvWuGhaJStC/qK9U7mOzZENVVx
VQ+8adqRVlFzcryW2FckLyasqovOlHEvIvuC7diLWFgWYiqQBc9xxOBbqzli
+1U3uUCzKvMIxKeIbyMRgTvmyXCb/npb+SWTWuuC0zSsY464hK0EaxkLn3kb
zVhgUIwZlpBmBuW3GtMGowfZtKovy2F7k9I6wx209vQIJnzNVh/RJ5TUNfYi
sRFRdgFkRTOB6FNjioyUvSPUQNTyMLerNgTpPtVlFikLASGPRSOCUhCvonPw
CnqKCQ4hHCF3WAsWerDgQ+jl/LsIsvdEx3tWCjpn7y6vOj35N37zln++OPnr
u9OLkxf4+fLV0evX9odIn7h89fbd6xfuJ/fm8duzs5M3L+Rl+jQOPoo6Z0c/
dYS/O2/Pr07fvjl63dnYcMyTgm9Z4hOwZbxYRW7F6J3nx+f/538PDkh4/4+L
l8f7g8G3hCrkl2eDpwf0yz2JW+mtWNBCyq8MFqHFpKztMdxOl7C80y4krqhu
2bdFG4ao+Ye/gzK/DOM/jsbLwcGf9QNMOPjQ0Cz4kGm2+cnGy0LElo9aurHU
DD5vUDoc79FPwe+G7t6Hf/x3AqFZnAye/fufo+ZhRwswF5G/qlqkIx1xDJqH
0RAQwFOCjRLGVDWGJnMy0hG8xZjSk62oCLxiRCP2SqyWj4KBzblbHJVjMEm8
IkZnTGsRsx5JxPw0XCjuBN4r1ZcA6TPEFhSM6SGaXhi74pHaFb93dkXpSwyN
DnVZ+yITaxv8ugdDUU8AMopFrAWTgWbMp7KqT4y0H4CEMpKGifbjRw0rsJad
iRyMG7Za1p5ja4puKB+TrIZNFgoso7PXDL7M+rL6n2A/9Ujuz1dsKYA1gslO
m4mF+8ZyESUYdfHqWF22JzwFrLiBrENDOL0c2oKjLTY0MaEJgQTHjh364TMH
QtYy5zeVw2B20CyiqUdBV35fnjFObHF+R0s2ctF/pC2RuqQmDDzqzfIfKwJr
ySy7yxDEEkJC8DTDOrECBZMoiAjLOuS2dLHFlrRWtAOS36awtttJ5qQlwdpG
S08NLQvxFsAsoNENxEfyA+HeWEjhESKvcWjJyIha5SSBf5lAuLTOm010QzWv
pzXiFypjy/G1UNY9wXw9Dw+mk0muk2lYaXC2CTGOfFOQr8F8fLSpnDC6lfc8
j1d01W5Y2mbh9TW2z1hvmQZsdGjnM5p5yGkGxXc7p3E6l1Cv+G8saf2vf+rs
+J1v2oX9nj0WVICxLBnXUe84/0lZLsY522GEVdhUghEoUOV38CTYVofEA2B7
eXJbLJv6zF2eCpJ5wCLdIvVDm3Tz9PEhnM8NagWDIBULB84iMH5dRE6FDbUz
z4YsonGLxZkXWeIzRHQTVdUE5QxMhVWX8zIwV0G7tEtN5FLXV6jrePMy9sQk
fp0vxBo7FvAmW4aaX0KC0UlVFWXVYqVzlg/mdRtdFZ/BH6VwWzyDSheaO/aZ
iJCtJJ6l66yMjE2V4aihE39lUWoqtg5ug78hCv7Xf/0XjWuc57SD6ujfkq/+
82/Rb8Ya+Jp765rtthNv/fMbXsJrV8M43E1diaAa7u7Wk11ezd0POx3/nXN5
R/bPw/sAL/2uKW0d9pYv7n435aCAKN0clDgKFngn/jubpRCN8ItSgV5DXJND
BNDLA5/pPKt7DXLLH4FWu4ql4tu0uoV9tW22/5fT7u1STqBh7CMgYkCLd0Q6
7NghMBk6vNEIb0NzEaAkOjX8T56hq/PfoQLtq+jjMH50k08T3muVxJj8yYYB
m90fnJLMClXnk1oifXfGynhQVGb6zuyeyo0q/suPRqFV77c1euMbbU8Fh4dE
e2qNEiFYKfhXNMN+tNlKEIh31AlyaEjnm1z8hY8eBUf+eZFDMH985J35BMDw
IU2WECs2gvXxV583clonLdRtdxBZG5dntaWW//LWusPjzvuc+B12Rdoj9Dtr
itb2IofwakSSUs9gNy/qvZg768M3oNMV/Ns0VR2oU/irnkQfUe8dQnMdtcSo
yojwCDs9QI1NKlqDsoV8py881LfT9yfIkxiZUBZHPg58UEzRQBQKcFrnY5q1
5o7ZtCjp4XncDUhJn3uk3OFhULs07LE2bF90amnWQLXS6Y90NPMWZOE9T9+L
m5GN1YrHZZOqm3vK5n+s/kbMhBleDjd4WcKtZ2MkGgwVqYd74yjkfi+0X153
43SiQciPzxFNteFRH0Jq/BEwzR1FR39GaF1zmPIkyFyGKAaa8uTPgQzxTPJW
kvAQX8lUL+t0DFQC0SGUbIWgikDhW7sj7ZGF5JLQw2fgXs8AK+VekQcENOrI
EVbY+YqFAk1KbL+BOujcgnJURWJrE5eo2hZTnPDf2a2TQ/hsGBFz9pkbJMve
Q96x4PC+YFMiaZbfOVNdV9dsR1tgI4Mo/taleaWxJIKOdobxD+ZRXcYWNRQM
iHUMNDCGKcHUSQu/0XkS1y41O+EzZO+L6xJ06IbubRqbRiYrxyhvGh/3vZgO
YnQ5Zr1aDTTGbgHXpDkvaWQitrIJtXu0FDsoKKukmoiLSFRDPiLFJcrvs8K3
zQzyUkTYx0eeS0zE/ZYXwJmtQW3+aRWplEuDh21YNl64dC8ckl7oImDgI0A4
4yVNLZ2pSk7EoFekqeCL2JgRIVuteQAAQo44Foa6BT8++rWgJVS/mXBh8+zh
5gBZU5WE7uSyUlRl0a8V6b8fidAsZJGEdLl/+KTTwyf1eolP1P9FpPy3X+9r
+QqHG30lEQtpQhsiySfJYP9xJ/oUShQZkcoSO1CdzMmHFOoaxAl1D0OCsZ2q
Md2EQVeW6g1Rj+ASeCV0J/cRjo7Zt50N24+FOD61aqOoW9yI8VsxTexKP+PY
OoyOaQZjVDpbZcEidhakOnboscv1HEG70MvMOEhBz/rTfi9+hWZBzleXj58d
4PfDwf7OBjOwyVQDaiS4J61Mq7Dp2DwB5hrqOCmzJW0fY0WiZWxQ1h7jGR92
zRXGZxNx7a/y6lbiR2I5nuRYBMpDRljVY2MqPWtDRhyaGlvXA3vLY37DQ0RM
NXA4MVPL0jdAkYFOZoc5UcwDQ/MhwrDr9ZTX652q+SpsStaoZ0XxPl4tVbwy
Y4zroGmiqOO9htERO5MIcSyeHdqY93UiqNjbl8t0zcejbscqHhUmsDSBsYIa
w/EYAGiF1kGYUjMq90GjLg/uEY5r16gMs2lSaek3sB0bVjFhs/kiQoDemnXD
KMrF/Oct3WUNE/fb8t3FKQfd0L9mGddm7cTsaLxYsZ7j29BtbgHBSI5/Z0az
WVgArVbW8WHwn1bF/yMfmokcmn/e/SOR/PbP/9kzANIMqlOtRgY+q5XMx6uI
sVkkBkh7Q2QdD0BbtgbmW41vM/gXzD4nBHVJX7yuxPD97uLN8N07jNjpMsDZ
dOZtJybckoQyU3b+hUS+unVeW7Hk58ucWu5WOzY7gSn8PBunGKl4ZWGWhWhh
hmTfmoaSE2GyqkqnxmjL2qpapkTd6NBnDVXDO26szUv2mboCGNCIExhhljl9
ZF21mWWBCGACNi/WkXJYGFIkFNDnf6D//sAaHqyJrNXROsxysOMf/jBkjx6w
vAI6ZleRWQsBT4rR2LzN0ZpZvMCOUpCvkzL7tLaWPuazeEN74ljBNhBooZ+B
lya6C7x5nwJO5bUBOhruQht8lN2msxuzYrJH+nbi4ovCzPUNl5vbNnl8WYv6
RX/EvTRbB+jKdK1cmt5AKKfxrwUj1lihnXPaaPAYcGELscxMPPDqBi9mYvQK
AN4c7xyYduThQJJpzJQG9XrLZM2MNkzIg+1mWEZopQtdd943OlgORWeW93hU
aCBP//z3jpUdmQCUPs1d7YQYSkefbH9OQhh31bzz8y8I0T5BjIg5emISD+P3
ylQSM0FiBI5mZ3pml3Rl42wxASYnCUkJA6RzlBUOLNeOizwT36K6UvxoA/8Q
5xaWMz6MmaZTZ0lAe46VEdjMQZfIJEAbvjqvb3NPpy94sB36rGPREdbCRKW4
93lv1mxfLo2/Cc1J2mg6gsV1lOK4RhgaT8dsJEgNamGUmY1PD/1//8//i+0U
qnBmF8kYBGnEVjrpwBVgE1BqiN03qzkt1fgFTd0EdeRzIiqJrdtcYSUPh6Qn
79MJIKQ58Y0nNbXhlhO14vfiSqbaoT51WAA2SPrE4vCmqEWicDwrtS8roGGJ
8kDooR1l0xQHfvahCfM2p0HP5Goq4xl5p0MLBlbJzigRS0jrdIi/BofxPF+w
P16EBk8HCIwQFZJbdA5LUnBpyRYTZBTc5ohMNrBD3J8pKR9sHBgjNQRY9j1x
ibrj4eJg7qCBqrYdgJXOYnTTibtviCzPM2ov29EDSQI8rSWIGX/kn3xK3ebq
VNY3xOFXcGhnQNHZbB2tSF3gpYZjhUbza523HtUMeaazYsR+odUi/8cqaxjb
fNGmhwPTi5fVP2hp7IwSFNAwKkNJAIazl7n4wTn4TLhOIRq075SFPbIYxKPa
ofF2YuOIrfwhiE/aG2JX1oYXb5LBZAyJ3ximfRxRoFye4uh7s61cgJmVCBCB
F3xKQtiqKfRXajrS0L37W1JqdZi3ULhnxB0TOgbgbKo4it8aQjwuZmkE/oIt
BHuDVBna73nljCCyBhxcBcEDH+BEJU7kDrfvZGvZ19PRxtvmUMlQTWHMJ6td
aA3RNnIB0dSZYvBNE8THR9i8oabgALlicD/XqxXiEyS6F73JxPCETGiPbW9p
+azhshwmOWNiFoDAlAeLbFyNktVS056szJrswXVcGXH+4jUx37a9galq8o0J
T2al0BujRnUh8jW2Af16GrngO8UsHZUT16RlQXCJcUKjJ7PrKr3J6jWiz8bp
bMyZBteTAsiWOZJERzYU0hrJgeMJSFpcPrSyKAAxiTtmYp2YGO9WSEnswp+A
cHdFPmENcjbjwF13SMoz3SNkZxsJVWZI1+HTa7Q2REQhDiYibZgG/Y4M7q+Y
kAh4PffOXg/IMPz3gkKwLX2HnYEimQh6u548Uuw+a81gIym1dJcXq8paRDNj
dD1axNl8CaTCY6NNKOkZCGOJy6LQoTEZFkVzDB57QntSZAbFwyAT20Sl++gF
YvdPbQTkx0cI5k9sSORntpOJL3UhlIHF2ATLR15EmHFdYgqI7yZSZMRYqi1K
KgEnK3KFleU1XJzbt2Poo8ezFuijS24PzCvCXiIc4w6eS6zhaAhU9ORgVc4S
omRB2l6CBzoOvXaq2zTZP3wyXByM/jr96fbs5scf09fJP6Yffij/+jJ9+/P1
1YeqPD44rfZ+GFQvRy/uj6fTjuYQ0vs8Ls9g5ral2/hE2Kwc00iUUYy3CgDi
6M1R/IZ3zKmpOUPUfYVWj2yrF8z95dpuYh10x87g8bODjn5+ONjn8T1on7Mt
gPto6Tzvl/2KRPks4zSaCgU2oDt4E5WNw9a1ybbeYJIj0IrAq5BODN2y9L0R
C5evjtClmd/Zi8MefzYwyZr8ulKUpQay8IF37zIp61Cm93ExrlH4YoNLaD8Q
O/5udhO2tvzWSF5WrMFAyFInSMAAWxp27+jeDOr54N0L2n+jdPyetqmfgeE2
6cYbpXnjv5PvLMq4CcSPPJgfz0lI3aaIhUo54EdiaaBzkWxfdhhlfseHt4cu
OJQls+FqgchQXOsQtEoDzR8q8GvEJxHrc2C8Jj4y2t0mZLAkAFbQXxzx4NQL
V/7tCGBKxbL15hf8qSRSsfErMQgCTCeCUdxkD5kSN3ZDpEqrplusFvAW1mKs
NF1r68zj+XRRiA43B47X05LNq/a8rGy25gQaNdNJ3f89r7AD3sGJXPlbHIK5
rDITGUdj0ioiIhU7xIF9q5+viNDza06D7+zYo7tlII2sggliNBk7OgYFxxV8
RrISPeJiBIsJrQ/rLneZgusq/2fWM9Fw7PWhZtgLZM9qGXFxw+FqHZgYzOq5
4O8Y7dKbB3vfPqG1qmF9N6gcrUUEU/nQp3HTqesB5s80eBhxBGrVIvj0YQHr
AVTnJnmZI2nGZHewBlj1N2P3DG/QIn4BvkV5CUjGecERszFOnMqzYUpnri2N
QKfmYDHogZBrfrG6xREhXOOf5R7L0CLc5B80oJOx3s/XEAg/X8+rzlBQR1b2
Ped6PFmpHk2vz3MwD1ItJzRvasGmtf58LT1QI1Y4e7lUJtTTHt90ciKRCoef
5nfjxzkCadJyTQchWudYnJ+vMQMagN/00enu2WstPKFf8xv3EqiL8YzW9MJR
ux35NDDa8jZvxPRa861nxdetrnG+E6NWEpoKITabfWY3CeRvSbT5jgWTc7TH
Okqc4RwmrB5tM3hOxljNJmrbDKw96qkVg07CB9TP1zQw2oW2sI5HJ8aSFdix
zu8gnsNHodMa/YJdQaxBFIubXEPH8TvtWzjgaCJYlujIRSo3OB2zXH42OTEK
D7vPJSGK9+nYpPPiBFFfanPf5b4hKvBIqUxs+oERRTTcYtoUE+iYUDBS8gSw
wcL28PNGDePW05qeHjx9ur/35GBwuMcf4gS2Hz7VD6GNULuHh3vZs4O9vSTb
/3aUHAwmB0n6dPAkOTh48uTw8IC+2RtQ03jjXp3Se6PBeH/yOMkObg6TJ0+f
fZuko/EkyW72BvuPDw7xSUf7Va1uiPWEsCF+uq5hcXPaJOwXw/jvv0gfFvoM
Pwu2W7E2N2nwm9/I6+N0L93/9fpDcX0433v37NXV8+dvnr85fv235++nT5Np
8tMyy7//y/zwyYFOFxJ4GH9kM7JMBTJLRNb+waHYqJ0scqLIiRl5hAWGJ086
ZoETMdERGyV3B/19wOtPDf8+suLAlsbDH7DkuXKa5+Z/FPvxRFc2H/jjIz8d
WEOXmwFX+tZLnN4auxjmspjCEbWfRu1ebxbCicR6MRjsffq0peqNgSViItdT
zW9DtaDcWX9QL+nHSxMCEkZ6RL4xT6JGFLdKM+pNV9iPWgrPmzofYG1d2Zxl
Pj6X1EcxibudPoGa8W0KD5oESB6ZULdKS0GlW8PcTLxV9XC4WzMUy6+QZMPT
NOBNZEv0/clVvJsuc5UECfs/eDl2B/1B9Kqo6mGs3/FQ+p4QiVpi37L1X25H
34/zfr8P32y/vznc4CHYLOihjVA37SYIdTPReGy6wHoK19mQt6bzRCKeOECc
yxxYR71vUFOa9yL79lb6ClfNmI81fFgXZtJjc2+EaMO1rKXhgs8ynmp2NgJS
nZZZaUztCOb+3NhglK4jAfXETXf5RPIf1I9rbdFLVWNtSrOob77+xHx/eoMc
bEMjvHnDBcDCkDZwox2tZzsWWzBxRGnpq3tJM8uMySpqOqpMRY3ZzJBhYjwD
1ohee+UyIm1Q2wmrhtkIR1OTseEO/qZCGeUKAxRllEPZYJj7wWZ5szkrqMfA
EvCtlnbVrA0sIa3cQ1mJ6i/jlWCDlm+Mp1kFPGsiG/mIExzHBIRYNckppm4M
o4htGfnqUCEKbeZq9yIuBsfkgNe5KB+uTGINg0BIwlgRQ05jnvETYEw+aFYa
nxnkIXuD7CrVkTEjguaOxOwlcFWhptA161AfZ99ilouIXESB11wXO+QM414S
lsoX2MUC1by1voCfU/ehxyt2upqJQ231XDK9b4jSUUdhZF9jdlWdLU0ZnSth
fJSmVG/GUDy07G8Rm7Qx8KnPqhF3qkk9HKnEaVRdE4gT+hj4NGIg1lMK8eu6
Sx1h85umr2XHyAN19HqR5YJSeKzGLyQlblzsuxm9SAb4YzmmVa3kXKgGm2Ao
dZebZnOStlXt4sZ5P0QucEDDKU3UoAh2cV6w894XAs6kww3IbLvKQ5453XKr
vuC4yrAPvy8sJOYja4F3zLbjhKgv47TEjUScrBaTB+mEGN2rbE6oh3SXt7pr
lT88NzU2N9PO70gD8WMTrjhlZ7WaQZuObjWVmUpQ3MByhgJp3AQrWFNSq61D
WNzBdTHLOJ8t7npZ7cP48V6sOvdOnxu4ksXosSBmCShDHcb/KT/0aTDxHwkf
5bMJ/yxpRNzXNfq6tn39p/H72841HU70OTc8biEEid/Bi2tj0KcrOqDpEOWS
bKQvxjBfoLCvUlpWiW3ohN4rFB6SWovw2R+Hz4pjM5+nZT5b+47IWIueNGoA
dXWtMsP/GxbHnZ6WTJHocjuCdr4i5uUK5OozYwGOZJ6e3ehbeOwAxgk5rRi/
vXQFBcARqB/oSVHvzDKGd40EJ12CjcRqkDWsRL1+U4mE0IFLAr0Utax5FKLr
PLAPDrlQlEu4hr9WIlvHNOJz/+C04YiAws6ZHIsNPcjThRAsmrm9LN0klCSN
b7hIuK3FVfqld+AKZxe4renDQ320gR+sd6Wp/i+rbDUpoDjYCieV5RTvuLBQ
TVNU3HvRzWohLlvrVyWs0iWyERwd19fMR73WXbSD1JXd3fiSzqJ4MPTOHwmB
grf1xjXSN+FkaLxPq8kd9Omc2BkqbYitiRhlWZRdDianQy08Ejo7kdfnvl04
twXYZGrknbcL2U7DD1/nLJbRN/tiOcNBmvmTN9ppVnftCzsiri0PQwSTamyK
L4cj95232H4spEnvjv8t3tYgy6s/c/ciuloJ/mXdZShkbaS07qGQbo+H8TFv
IBsAEnflSC5T2Am4dtQ8rzFIVKrC4fknYKHuDjvSKtIk6ANi32veiOGC0owC
1tEWNKhu4888/XDNldzo6WvbLVFG+0HGCiYqh6f5iDZc1sY1x3mJSIAyLMyh
NnOJXhJ7Ngx7UWRfr1ZjYM7IbQc3OynXfc0TtAtY+XNsm5qZNk+Q+2c2p4np
N304Dro7WHb7SNuUztIP+XxFqoESqblK/oRa+NyNeBjyHL7/059iN7sGe4HE
m2/kCzN+8zi2db7QZ83c0smkuXt+zx4jdg732QbrbS5OkwG38N2WNdKnv5z/
PIrJ146ppFa7b5YI1UBjmGhI+3MrnDsa8DBu7FblAJX1ljGkXA1iK6DysLYT
+XjsG6MhVop/RC37ILVC4rfdH4yG+YNavPQ2IA4XMb0sCq5+DAgmirHJZ23t
ylNRqdOXYN/1kivJuSqnLHuqWw4fxMll8gLyKspucJEIVjXwxtHGztMZ6q+Y
shPQdrMPNfzY7M8jMVeUiKHKtMWmrqWnvMIs1N9s7LOouc9CgDrYoz9CDMXp
DPT5SRo408epq80VNAqxp+RY2BFZ2LLVYzdG4xuNCv9V7Ftri+0ReGO9oqRo
o0bKonYShcNxvCQ4nKaSP/eD7x3/+Cgw9ogK7D9wbvBGMyVX1Z/KqcB1oPWG
+WxR4JNnnbeZcEmnn2ZBbzeO0YzBGqkaI7xcup5KprUWr6LpunwgrBEBdWgF
MHn5Rl3RP39o1KLjlDpj6HOZUMTJzRwsVcw2GuBU6LYGIAkl60xqSUp4OVc5
iavNJDQF5bb9TBPWN5r2wHgav18U9wstTyiECbOwtHKM53pulAw6ZAcoDSW7
83Pgw2QvMSLwcJxVxKyg4Gy7BA2607oKpx/296m7Jy0kNMnm27oE5madCEEA
IrvviMEnW2e1JVzIIFxROqi3bypuyvIqTcAvmu63SY++1yrGXo1OW1hTvZPj
TK5Rgv3XaxnGjF789vjyXJiX9romSUkXoxXqksarJbA8Jx49bXBCO5NxtpQ5
URpJlarBb+bbP2s07dUo8NtrSb6i98UG0yhO5Hg1yMb+tjkHl6EUZKmYJIxv
JOPCFufnM93l9Ug0MTeSsyxiU1BPMw2qlTl1LF8JuHGNb6RypBUHZGvk5Xdq
ILcp6bJUYmrUPBmTt2BtCRL5EEYupvlshcghvP6jyR+wmSbqlvItlz3P3iRE
COYuzOtKIjINiL6DvX5AX46a0rBZE/xpTyqzhziWilXWwSB8ne1CYbz+wiYE
kDCRzplGaSWmrG54QNtgJnaUVbfFjOSzdwDb41pp67IWdlRCPtjtzYrN39xx
cKwvUBZVqs4vPCNUnGLDuJzGgBks8MnniAQqjDWpYUzCXhzsW0KJf0Kt3hpm
0WUrR8/zXfc0xB5hMCKTNVWTM/Sz2SwREzfapiPlXI/Rpv7PcrRZFBrv0DFx
Khl8krbEEXQSIRhWshFri2T4W9DCI3Lpm34hHMeG1I1amzaOc/EIbTdgmgio
SDeCfWBWTKeaSN8oXB7HJwzXTZJj5EVESZAvMC7vRMtiTQ+SrWvPrlJjTeOl
NQg09yJgUZJyVlS8UQXvbBStEM8XISLIzqAcicuF8X1hLkfLxmiJdZqFJDdw
sPc47hKgHuUT2tw7UFnwPk5oWipJckEhdeu4BnbijwXoaCODqPtu4Yrkm3Zs
5ZbN3GiZjEYVy7hIbo2KybpZ2iONaQpIUlIVSkUJ/aShWpELuxaDmV2SdlZh
THzle+EioZIN4VVyqquOSWxTgCQLpLk20Y2WwNwAsc5Itt1oxnv5mpgVRpDr
X1Hn0kgG0mm3KJ98UmvExjXCiDx91VjVBNgKJOoqWnVI1a7MDmnDSzyKvs0Y
jLVHJY28LcYH+blPSDX+H3/awKWB/UE2YbdzKlwDxc3hBbGeuAYJMsCaoBgV
a11dW2DadQ/ttHZB+sJtPmJDk8Ue1mb1WtP4HSCIDDQF8YgAG/Rky4J2+l5M
CzAsuHcCA15jMO8WDIQbJQo6DaLaFZC2cdgoM9ACXNtvN5buAXNEHIDfnjfe
dqqZhbGvNMfIAbV8gQZjXBkpLQx9fq2feVTqbdKxvd9LD2NbG7a21xyCg5I0
1ClXro44yZSWDYYb+umaJCl621wwj7eIWenRPtcRaRmSyz+YE4Tm6iB6xddV
c0Qa2GjwKeQlwVNNV2PzEy9Un54zvdL37QsgTVkEJx17LW5QQ7GfGgKdoODX
2VonnXOxgJYeIbzkUS3jLmEJfLuL1gVo9ukhtXCC9CH8ZQJeOLqs277eBvNp
KxsETZGJTxiNTf9dCZAvYkZsOi0HuXYaRBafXTCGOBGj8DS7tthv67gkQZc7
ZHdNOi06LX38udnHQxb27d0EU2nSoQHm1BhrQHT8923Y7hdrmJVnQ1ZoWGXN
oM5yyZ8NOxUvA/9oB6duHYaEXRMI4Xz1fCyzG9qLcgjs/IFjyJ5AX2JgbfUa
tVr3WwnfALECACzVj0LMipBjjVTJb0wcgue7b3ijNs3LziwtMNZMdccZdCU/
KLDoBjjFq4O0BUlIkGRQavLUXoXy8dHG5ScaG6SRYn5YAcFzV5M7AOoaWm+q
aQcj5OzroqqT22JMv6SzdZVLyp5D+b6W5V2E07wXDdgyNxc0KRNKNLRfwyOy
V9za4KMwptPJzgWzaeowIFaDpEDEt48UBPnXbdYYrc/iVSuHdkCQCklQyKmr
opY6uggHzjkO2NRz6QWXGQk5KsS5RBzFJmNp3n9i46cM3tQYJswa8fR+TcIH
lalQ+1WbqDSuls4jb4IVwsZxI9wwfiteTwPxDYs4y6oEbzCLz4uJmMPYJcbZ
8WrKDCNDdJBaakvqecLLXdR+uIJcfWEigHCpHVvhU9zkVNTFQqPI3P15sYTJ
0XjFrWBKyBG+I3g34qpDpH9tjsFkAlpvADYkrIzpTAwrcgmHGQWMfRxPxBYW
tYWetuaGBn2p9tJyl5oY+org9pFFYTvk1DNGQXKzlDFmeXVHOElPr1Ik6p9l
5XtEppaZ2Og2RzHKLOnFfonyzeYmy2YljMjF1el1hAWb97UUaZmTYos7Vwpc
5KcVpGK+zR7tcSiECVOoTOi1mlrdzXuVeX4cPO/fH0Ejma5IXmswCptuHx8e
7puUBlwgR6TTYtVhLEMt36VjDiKUat/SD3yNXF4bASb2zsW4m8vX+uaOXFog
t0E0jLmRKfCvMV1BEripgsLuOu82F+SawKFQFnO++F57RQJIyTXra9TL5BqP
rmNOnwrrr1uIXIzC1Ww2hA71UFA+KrlpY2qsEdhQa00V3strt5OVfSK3GaV6
B2dKOQY18gF9XaFICAmSfCkpSw90Zh7KvCiiiLdEOkMvNFgNi2y5z0euS0N2
0BFnB+HL13CUGW+SlzkE09/MfvfJu4UqSC8yEVHam7GWmCIEUt1GYNi9lOBB
WUuTUeeVBAiK3XIMratzC6GLm5ctB8Cs1GDCMSctCQu5+zCUl3QExqCP3zT8
0xgkUj9Klc0TuVxSShJ0x1yfpKmYWy9CslWKv+AypNi/DElf4+xjLeYttbyr
RkBkLZUdVrikHdlVJqrctPBFFynppGXff809Ss2Ho7Z7lMRBjLuXp1gKiTpP
zMDcavS24ZlGUWWXVoesuihI+4q7piRwvpBMHU42tRVtF150spdkp0l0kG6o
vZTXeuu9XNAqwAlgzFyTGzGn2gyU1g1glZNyqA5oGLwil1anzDMuEr+SpjGs
GiDcuAvUXtRlb6/wovitr811Ytgs8vMETZbgkdTW8cpO8Z7BSL0m+KKaiWrC
oBdtsyVqG3FSMQGzbDGtb6VUDHOMl0YY621poRzxkguNEViTC2ubHr4lzbBZ
j9KblwQ3CL7wI4q1ilcs4B5H2FiiZBcR5yNoWswma3kZhUY78xnITFfruIQB
niJa34YXw5zTuQEkitiWSkWIoHBvPc3lYuI0tBXRVYDasFZ7s+xE8ZnIYgah
qN1H9KEN70pbOdd947YacyeeXkIXL2fpWG7fwP2H7oJC7zK8IdfU4Ze4dAJf
9GzuTlT5K0esOCxwM7HNGEYBZI39tIeqKw/id+JBLxQkbGAuOU/bUVfcQF3o
Soooe1e2+V0d6c0ikr/A6D+omS8WmgUHoywWpqSPuey3Ur6109CD1RrpfZ3T
KI5bSrqb2pd+VXdxVsPivJm/1lahd1sl3kgVOGcvCSttNkpFhWUiI68nL2kj
LM9tomq8OmK47VFh2/YeWmIEgniAz8QCxN2KA72zZfykLedpRzxdD3lN2Nxy
0zoKfwQPeMQk2WK2tsUBfNdYZF1jGEpb3AKONy/cmKNmZvmoTAUyUps2KNuq
pLHUVXiwVO6FlBQ7YigLEaTFgZUPzdEo6fqNQnVVwwd7mPje3LqIXNk5rcvh
FTET8Gwi2vzAAJPDjWAsfpSO6NXCWk6twZSU6NTdHWGtqlrrPeJapv4KkFyQ
745Np567m9OhMpsmxOlQkV9gQQqP8q2HaiMFqYwLYZ35bvWrjZh/l6/lMtJ1
dirxWKmV+UT+KRbkhskgNLSalYPUGZc4g0Lyy8IrIBS04lwjetzMUvbBSvGT
gjUqO5pt7OdZEySGrbhhUgHSJlwJTupUaWwESlVzeJs2a47n1nJxplicuQlE
L7uarOTGosw3CrSlCBAXn6WLJF8k1G5ylk8QR3NuqRqCcR4P1GuTUyw3tFgl
2dxaa+oA8XNStFVOs6vXl6xP4F86HBfSSWWCU7i+YVhyO3rgtq3P3QLQi9zl
zFaPz10lPj8DIRbX8Jk40N35UmlC9cH+wLvTG8rMjBXZGjVRYDBZZLRhcokT
siYUZecJseSCr21LJChb6lkYvhZV5vXlLtOl6wZtblNQyYKKo9AI3sv1eqov
s7KZ4LDYxd0J3ca9L64NviVe06JtJM9CyiuLW954xFXEJXKBwsP3ZzUvVLBH
H99RzwwGsONsChoY0XoacwqOVT17/JjaCXgHkoiaZpEnUiSmh3YMDXuaL9CO
huaaSscNFQnaRQTTEBN9S6SprbGSzFi9t2irRCEeqfsDT0cpGbB0LnVvi5Vk
gU5SeLbZuEtA7rbiAifnbo5+5W+GswwYXqXl5B4C0tqnzooJF4/tvro8Y9cE
MsAI4NJOZtyO54RoaqXtNy7NbhQUIyVHKxS5uDq88g5lQKsV4Au2qSN/bxMK
aKYyTmsNCfINBXxJDkchkWam5XVN6CSSguDV4oeWaV4aNd/HaOlGc1JXO0iF
1QAVBa+KibxQwTLjoYqTmBabiMMapylhCwu+rEDkyfMwZREFwfyBuWTn2drG
TtL4OlFLLI6WMVGjI1PkJaviplr9kdErN8wqJEU4dYaYPAjP8e63NlVfG24i
eyt3eOIVYVSPhiY5Zdvlx7OVdGLV1Ur1VXvEkZqr9p5ULQtOLAiV14rx1sHN
cjYa6kx2IG8zBUayBT0NQ8nP52W2qam0GYmj+HNm4jaF5cdNdXoYv7Nxq9t0
VbVtGvvHFvNH3Gr+YMMq68ShKf7MrEC+SQict/RgpehD91tqnE5jl82H1t+u
aiQHjGyB+yGXXRNrq9HPpayGeilUR7BGVC7zwMqaaiGEM0QsWBouQbJyoWz+
glMSuOySnM1R9EAIlUr3VZ1aMzQt4QcUDCIxG3VJmpfFh3zO9YnjwVxC0NEg
vYwjs0SGkgpKvk4Gt40gEYF2Q+Tths+meMSbKR7R1hSPjRROKfNkUjo0hwOp
+JVJ4XBOmxZMqGyM/PN1zAYKhvq89+T8PDo/1RsoCUeb4DtXgo1JbEvlVzJ/
Xxq4rAqvGgAbxresjE2PuE+l3hqJEjrQIHBQq2yhwpDd5nqliCuVwBXhlCGu
jKEcVzGuynS8VjnP2ptRfSQjuMsqRE/ibneEps0kxn507NKmw5xk3hScPyvb
UG86semPv64m07nm/Tx0zq8X49uyWHAFO64gbmauFuw3V+c7fglOydhJP5/c
HT2Q3B2JKGjYi/wrOLTovUy1WqZelRbx7phTXoz4vvjxJsGeYnvHDknq6W2m
4blROFpwkde9BvH7p7/L6jUHqL3QXmw0hiIcmNGS7C5KiCNlRGwj1pWZZ/xs
uSxxiqpBxUIAwpz51YxaDetNvpEgCUjqZoUMMAqe1djuqHWkjXBmUsttULMp
5iiHcaOSEko8IauJmIkdjJJLbuyRvFLzRgY6W0dmSOjbKHPJLB6pKzkLaj0h
jXI7XzvTgdR9kJoPnLTtIshj1HNVt1lfruOTzDRhF7kiE9VSNjLYbcBrLTfM
y00rWlmeiEHLJSe9lilRg8GXloBkw2rk1ZWkA5BLS3qb0HsRQNMvElncRIex
VH8U2xWhlYJUxY2qo2y6eiTYfLzpEDYFmk8+LDnM2Rbel8VccL0WKVsgAb0M
Z458/QrWpS7nh+g1HiLlGmqUQY54e6w1v+CrWsqadl3s1I4X+w3WmtmUOvYQ
JU78fpl09RyN1KWR5l7UuExJfGBSrhc5oa7crknn6KplYNJye3MUG/caAiVc
tTleTlc3boexoMIVDybAFmKNiD6fcWYc61YFqZAZX47tXUimj89wEQWGr+Ep
uLL6nOCYwR8a6qqFTlx4e/f89HTHMcFZvqA99U9X2ahOk7n32aetx7w+Jf41
vwdTAcvwVT/SXWLKsm9ce+pdr91y0ctG4fidoLA7H/tI60wX0xVMHD6TodhY
UOHRQtxu68bBy3zXkohtJJ9HAIYLwbS3K5JyqLQ3Yboqk3BARobdJGExUqsy
i22wVDqLdLFR+TnLWjctc7KNt+BKquDkdtqos0DDmMBwR5zybpwsRgm1ergf
r+Rr6im/lqhmQ9/LtSdpHbFXyKUSOKTN9gJTGFXQSslohYsGb8txVSFEgpk3
EWuQNVt1eeIK1U1glnf/j6Nn6VVjleLaL1czs39dGXjZwN0ww03d3rphlTN3
og2ThSnSNls7nKxKi6jyzlIrpIuMLwxh/By9ZeiEMta47N4LNZK4IQF0rKeR
0h5xVoVtz4zUl0ImupELAxgLvaXFkRY72BR5N0a0ENQ2vtV1/A+SGuLQYXa2
A47ChTU2T2MaNIzomRz8ImKRkb3fia6MgWzENqvTJ0ixeSSl6FtOqTMIxPgK
l05oHfrUhBwg4s5gNDXy4Xx3Dxkd2b8HGq3hCovIeHpdB1XHvL1uOA0xODot
eBQoTIxq3lphSwZzuRrV/pdhEkYUXdg4Qu86T6SmLUipNBeWt355giKSjPkC
2uCBZ6O8/s4LFEzlmkdT4oodQZs3nMZhKnVP03T4DRvNR4TbqGOpjEgNtJWy
DIpYXrbHlWHQkHwYzpZQNRukZq6hMisMVRNczPJUscVm60Kz85XxhTVuYBnG
AddE0ZFbRDW6SrAI32NnWAXvbT7ofGku+oShMvH2/SbchNd542pIZLCbWnIe
8KnC+sTeuYqhnKVT6kJ0/G61o5OO45e4sMkeKf43Z+ilLkjs3OAZ5lQsqXsm
EtTAA4GJcWaCBCGJWA5rXfqbVcmnbmNMx7cl7h8lXnxjKiD3Yrgu/qetiNxH
0tWpEQQrOCL4TdIh377BDhHXHhOYDz59QMZ3xGfQlq5I4SQQoCcGn2D85OnJ
1UuWIX4FW65FG4gSlLLl7xJfdnz6nRImKFdrZMyrNdAZX2cM9wfpGuyFYjdP
F6Pb0XHhLg5730YnapVC8qSRNBulP2n3caY6vqReiT7M6ZeNGG2Z1caW6BEs
8Qv7fmremtqgnACXfwnlNFAsX0hN/cZtz9L95yT0b/Kc0NH88sJhQXwmrHJs
WYU+u7A3PPwW/TZMkmTIf3s/DukLkuoTetjokl75dfoUzEb/ANS5u6I+ob3Y
gF76WlSgXa7vyKfJgy+SlKVvtBqU1IT0kPGDrxpFBE8xNGKg/0o/Me+1X8kj
LRjdhR58K5Dqq5sAw//mbsfQWy/CgW8g4N84EYOTIPRDk4SxhQsrZGCcbxRs
N/dyaUwFl7eWh16Y8Lwf5ECzLPWV95eQ+pgkXN8OAOYdnCDITaBdQYdIwvcf
fKLJiKTOJn/qsGuh86kRju3KvPm3S9xl7hYFemQu9ha2BNwW91GAytzBYkBZ
vojbYyLFXFFlkVZS9tsWIql7d1x9h/YnKzNIz3gH50lkM4LdQdW4tCQO7qHR
gD4OPUBF0sic8M2LkPUKgsZFWeLl8aPYYVsbjVAUh2cpeS1QyhgcyP3EbgY9
NsR58QICk22CB51zoyzCJWmmNkywqfoWjMIq/iJjV/3li9fHVhy0r/Qph37p
axN5rSpu6nvhNb6jhIWkKxvSRbM7vejo1BhIcdcBHNhSBdnVs75l5mAVxSd1
ZLKAEEZfrKa3sE+zkY19EDT78FYLGypY6aKCyT5+fPniKNkfHL+8GAy8Oi2D
QX+w183EaPzx48m75OzFBX2vA4h8GGOPAFs40hQN9mdu8ruxgJY05jLIkHQA
RkjVEjvUEZGKeIemgprLcNYT1kHVM2aeZG9vwNUV0hK3ASj+4svuYP+hN659
ol2DDSNt+XncPUYFxu9ZK8NFcM2m913TprOwCwsPr+fs6zZNH8fdK+i7/NtG
s483mt0Pm5Wtnl3Ds3ddrfLaNvwi7j5fIcynveWDjZYfhy2P8PK1cso1LB83
UBeiV6wfXigHnXFYZ9ls/XCj9YOwdeG8zLTP39HHH31fJL3c7/d/+RRLRoac
GaQPpThjdoIcPb0QIakms7E5Hh7anJ1P1lPD+YR+gWoVauKHZ06yNb7CFK6I
b27tadQhIxp+S9ckrEltX+Wwg0kmrzG0YUrHhsKcG2ASMm0+AwI8VDU3m1ci
akvcG8tlWWdrQ9WJ5qrxc2qQDoPMxBcBC0LEUoM7rd7ny6U4vsqMNXc1LDyK
ae9rSiMbPNDYhSsADlq0SrsXUg0j9a00LBA42AWNKoVLBwptYLpeprRFNARZ
hEZKBFMW0SN1y9lgVa9NUlkmtePFHEaKanCFmlHWIv9OVS52vePMP0Gqn9hI
LDnU1WJkGxFLr1GwYqi7TeAg9OU3+v8usnKl25QcG888NlFLvhjYeOog7rZv
6Y0nD+NuY3vuxH9n3nPx9pNfwltEJmmikl42n8cdxFHgF6yZZSNT9rDceMyG
P4bJnJYrbDYMX4PpmNduOgmQ8AqDiTKNMP2agwRVLe9rYosDS9bagfY8daK7
KCQkGJ+P1pKKzJFOR2r81YDCWVEswz2IS6Bmhi17G95LqZPQDM7oh74NuZit
eW+VgSsaKGRLZmOgfUWUsMJ691qw6m6ShnksTMjPnexDNhVRA2UiVsk6C60T
UWzkp8pSNlRCwnG1JI6SMiF45hLDpZyjfe7fgoYjgtYf4tNTUkKRECwnvWIG
9d2X6Tgz9p4bW6H+YQhlezk6TY6Or9ARDPkEmQb7Q2LIuoDlYsxx1ax5pkvp
Ai4twJCYfckJ2/QJhskF8Vxsp5jduYCqFlH1QNcHQxFAYitn0gVcLryFWDi+
2Wd6W8caGGkzvbTakCftXb8cmMV+dz95JH7J15IhjuWqTIHsHsCp4w23PejP
cNAISRbkRAdiVp72KF28/6aKbFgV3xBv0lKClMgxdYjbslOb2zdeG8Etb5uM
lnzhrkkJfeUm2M5V4Parb3snn9GDNDfUhQ9gL1eVHPkQ7hHfrO1PWQ91d9m4
YgFQwpMeikT9AuRDpoa5CocWUmEqyf/zoqxvSPss4gviKa3J8QBUjRFnOIzt
HV1+w3pJF5hTMrUdyALu/2d2vTS9XfNDjUHKClSmOZf+umOH/JyGfCzrdcFP
t4x4/+ERN3oxN5Fxo81h85pcy3fX8mJz0O2U3QdONxKuZYybcHrQi31g/QV0
9uouhMPW2kDMF9feU254dFBb81zL6LZA8i8Yk3O4hEOysABjCg9suZ3Q3vq1
KShUPASQWY5slPXQC0s2gE07y+3EsWOTbtv6gtf+7s/sl/Z6I39v8NEvXmmS
n7dWKeE/u34Vk7uHnrxzTzqItWV5d/xWwxm0Vk35rfXTzR4PPFCHLh/qp2Vh
UYf6gcWlpeP1hFEFs0N2Un1fmOLRgnPdTa6B1O1Foflp85Qg6X7DqMgvQi2o
Q1L6tCwSoSlIW//uHVzYgyqb6qwEmKNjGTjABFzj29E6slJfg6ctMg8OlG+q
ZgHbrwJGZ6cvT18kp6efPg1Dv2cITj3XZ+0jSnaNKabkkwf9mhB1TnzQfBtB
U742ILjhxduLowZaEcgQjP0Uyb5jvQlTMczDkOe1Ah0asMlNBuKdZJz5dJpM
yvyOi+cq0nG3VbbeEt0OIbZfEe0MmeqZllz1L78jeoxQLc84Wc0NWavgUk5r
8HI5vGzA60Xi5Jzli/cVq6cSZ4NXOP9Z3O2aZjGTNGemAcDiopgjjJ2ICMfT
GPEVCnO2KsIMp2b2BYeevJB0y4Ba8sheXqaAA5BGcvVsYZtW3T7AOqTmRq6A
lDQc4plhw4R2UYCtzmdEfXPQf5ENbUlvXJd42beacVph9fXmMluRShITK89c
dsn3DH6BqazZpAjwcVpOi2u5rNCzlZ1LHNEX2Mn2LWRoWMxsXIwJSoqiS94/
jEp0yTY6+KypTJb72ix/IO0dS6msd0xp3VIMks8JPs9m2YzdRuwhgVldTVcc
mIlFwS4FJVksC0iWRHBsJbP+fPMtKSZ6POkNFNy6uaoMZPMKPKC5XsNpAb2N
+PYbXB8m2hwXtDG1b02LnuarYP/XItdCChwncpGJUwPTbd97tGvDSy5je8nl
FmeMuRUzLce3OXIDsa020u/wLclVrijv0vair83bs2cKKGL1ZL5RRgTSasl1
TXO5m1FkJiw52P0mD46OEtrVUQcJ9LkG5vNR++8aechFuPI6yFYxtUTo+KTH
qIdZFhhFO5zihoINrj06SOnZ+KqYZhptl631XsOFHX2CW8GSRuCn9Spoam8j
RiIKjpq38O/H+/099faefBiLm9a47zocNMjev/ZV5ETGZ0++fUwU9m+V3dqy
XS9kCYoLkHN7bWfdI9Qt2nHl/vCV54M0bkMNbfSiGk35oYWUqmVPtgl6tizP
oCVCpZ+pOixvWdMxa4oTHkc2cmNu09kNDm/6at7vIJ8Ua8epHhodTMdhViIr
gwM/0cOck5ZTadbWQecYi9k6QnnAtCTMCRuSjF2Dl23x9RRJfgSlAMB0Jvzg
Duqt2Gs3g6zK2JuOH57Jzjy7s3uRiJSSE9QXxaavj0PWvAo2rswDx/yZxHCm
ON9FpslldlzRCKHut6BMF9CU2tmJJamIjoUpI7SuYNYdVzgFx27k8tT47s6j
7/s24d0vMWWKyqDCXL4Y16bSIyzKXpirMVkJ8NuVSwjh+LdJKchNE3e0q5bv
eEktJMDqNHbUKtRyHSWRfYqxDPVxAwOYf7yQTfBMr9Oy0WHdnNDi9sDb/An7
APodyXXx4CrvnKp938n+2nzaF4MFhpN4ADiRrJpPn1CLZJly7mrISCZCSn2e
pup/PJa65mBQ2XdXHxaJ7OwO4Z7r+5nZhCSOVvOVXH8nqRVp4gLXUKoGHmjT
cOVcQsLqGvMtCSA8Wi9STlMrqqzSi8qCvGjWL2icifCmEF2qZtnURDfYJrvF
mgQp+YO8a2WzDlumgf0M6xw4hzaS43o2Ys6J1SXfycUVcNVGvVLYUpV2QoWA
Dy4MpgiVC6zd4wDP0rk58Sq50djUQqicF8VOyObBRHKRhhuTlCsnXh+JiVYm
h5wVgaZDwR7tS8Ko3S4JFyrDols1cIMDTdKefzWCjvE72OHDXoj+96kas6Xl
1UIOiomNYvULrZ3WTQGmaeukIy4QMU7CConSm/l1KB4IiYNig2FAICMcGy2j
Xi+NKLQqVNSVjbVtT+HyAKmRxaHs6URP3MjPiveugkQuhXZyPa4/dHY4h9gf
XOTKQ5ah6mEkI98ptCkBUqt2sD2/XIOD7X51W795iJi93+1oGWRhgLzyxBrn
JsvNtn8Lz0iiVBn/RKeUIBwTH6viMdqa70+9cVRWWMGtp7hWjmJJ+YnPBRSf
73d2uBhWZG5CkoFqATlc+i3I2pu15rh40430Zga+TRtenUYwDwSHHHgAfp26
vlUJF7lQpc9iThgiEMyVoIgDwQ40xRlT4yIxENyO8TsuDjbPceneRtEHJryc
h2GVEKmg7AJQNYfWK8B6pdGu3bdE0Su+V4Xg086Wc8V/hub39vzkzdXJ65Oz
k6uLnwwM10H6VV41pNbAS4u2JVXZ9yRNstFKzCJcsKlYIABeqM2ZUGIOE2/E
HQfn58gwqnG91n26roYOnm9ctB2pPYv4KGG2eqhM03e2oUiKXiTiF6qtOQOR
3Da5tdLnzT1nYQ5gVKKwwnc8p/ZkgKZv3kdqkZeuEpIkXA9OTMBBKGnCs7UL
vZ1EWseOhHXNx5px/hlNknPcN+vW2hsk7PVnJvsA7zXXOGuVL/JN1L7oIg/C
fAYhy0YAXV8EG7I3rORukIC72oxQ01RAqVylieyl8VLJnniOVEvBBpiZv0Wk
rNkWqPUcssQSZORaafK6qyJtpiOFmqOwUHMIaI3SxGewiZisjcyap5xdE7Fe
uChgcjBWs406ymbZdKlt/lH0QEHnltQ6z+5Fh6Y3Xa0Tw5WcY7+Ss8zfeUjF
DBa52s1xIDI3SnNrlN/l8enVVdy9XHEO+zH3aWsN9+Sk42N9vO7p2beq6i1y
DIJbGtxmXajGeV0n/reeCptGoR7NqqUkEZtR1C59QO57l3EzrSJnHBRJ4g/e
ICQi5KXsA0SOiz2aJxZx1bVlXfkb0UwmM0l3vPnDXaiF3+TG+G5LwLTRqtlA
zrl2qaB0u1X8aBy7BXnhZAAtI4Z1V7RqG4vDdTG9jFI+83wCeXQcm0ve+9FL
PofZ29KT6n3OfjEnfIcwGnHFO8su42KBWhw8IqGn9l5ExADpcR431K/RWpQ0
gpy41IX/lmc8mGbxDBuq+TxyF24278VjuueVNWuYml7tpJPk8zbO6Iv7xFRA
s1ltLpmN8Y0kf05y2nxIRnXIUe537CI1FiQITyqreMcQCnWRwPoYMK9T+7kJ
Gb3hyR0vt0kmnKo6cosaIpHHS2o+9DO1rVGH+brbiPbdidhjxAiOe3UxzSYe
EfcL36LLNrpFDWOGjtlPM2fDAII8bBVL74T48fGxln7kHQ1XvKCsLSfD9uc9
E6sJiB9B0dPbTGx+rdEOeiYzUHOddszWd+1sRpsXN2rfoOaYb29Z0nPJet+0
sNM3pitmmxXfhnS1C3STSvqZf8ennDo9Lb9g6+OzYGp4lNQGI4mEYdn97zWZ
dqutmJOfiWvD99ofP5KEZyl+ivGxWht2iARN7BCt8X8sdYVoniZ8pfWSOC+N
vifVB6XIPCe49+Ktl8j1udY/drRXqnoLztQNw+XdTGFP9MEFP81WQk2rLpee
4eWdzzlfi/rxbjcNquC4ejphRU/CUCjSv+X6Or0k2l3z3ttM4BcKNK7EpZEc
yuW8D17AIFDDXZQrVdWKOK/DrOkLM0dNOW1d9iS4qYGQy5AoztkTtYT/kej/
zqAuwZqjtYJuGAteKMqR1fHuDRiCPFyxaDv00YCweKS3GyHfVutaoOmNCy6Q
IChVMIIBufq/GuHW6sZngqLdV+tRmU+G8auitvCKD0KD2HowXE4E1NzxdxZ1
wo9sqraB1soC7OtsZPhuIbfwX3s5H40l31JJKYqbtZSYSgHzDT9TNMlVSbLl
k2K9I7vrFJ5qjp3MZgi959pmfXKsKFv9A4k2hNRNSGWd5VIrx4ybA0D5Jo4l
ZyGKGQGrjiy85oQPk8HeHACNr65Rgoc+Fu8i7ltx/rps85xlArY/m4fRC72P
97jSFhasmWi7xcfdSPJPWfvXkloozLpRl1ZEva1NG3Vxb7NW72BFQ9Cthg8E
FWlJkErF2rD6RvMKcL5VgPTQxRQaTV6NixX4sO3ebajb/nBHGcf0e2H81lcP
p4+rqIu6cxxOz/jEp5M6KK167WLTaE8ul1uDL6+CPEiD4ufzFKauiqtgW4Uq
CAWJGmEsxOQll9wr27J7LIpH5pRcwcMRtxwmjp5Zx/qOGOs2z+4k59w2b2rw
RV6+V0N4zLNUsgxsqldLdtdvhkCSjXnhYmCQKkh7+NhMkB+IXCKm/EUNIKp8
fxAfv7yAm7uOBwNkVvp5Rw5q+4HJxg7Riy1aMTHPO0gMDSSwf75BvfIPADlv
wqAcX8sIEksw4pN38dmLC+rji8KcuyYsekdIsmGu8OKPjk4TyQ5DdLDJazRB
SLbzo1NkniIkqB8P9plan4uBDiOgf9uIQwrPq2Y4UmvHB9SMZBO5CGfb7dr2
8WB49APB0ejyLH95+oIoB1J7BmlDMJbW8JTe5ZXYvyRRBHNukLqRjrCZNGDa
RLeI2/Ko2xagRToIsnZMR5tMVG2Edvks5WfFepvbZl88IHPkgrITzffcioP1
gXhgwE18dV8kEi/zcI6jCSXSAJFKUUJsb3QSB68ETiwmlWddMpFDQymtiPNA
E/UlTOnXClCczie+4nwYdxgZMDbu0FGMTxr3nfJXuG0cflE0nqQJodFkf2//
SbK334k+cUANd3du7uMLuwIWp7dtAK5aAvokDTX+lpOe7fSkT0D3h99SBFKU
8gJA/jAePH26v/fkYHC4xx8C7tsPn+qHAP/U9OHhXvbsYG8vyfa/HSUHg8lB
kj4dPEkODp48OTw8oG/2BtL0vcx/NBjvTx5nB8nNYfokefrs271kNJ5kyc3e
YP/xweETfNLRblWvoLduMgKa16hVhxwkTFWegb6BKDAZvCl0hSnfpgmtynBx
MPrr9Kfbs5sff0xfJ/+Yfvih/OvL9O311YeqPD44rfZ+GFQvRy/uj6dTadGW
x/IaeX2c7qX7v15/KK4P53vvnr26ev78zfM3x6//9vz99GkyTX5aZvn3f5kf
Pjmwa2nCzwKvJC2wvbgXoTA9nz89ezl4U8x4JmwDdwbhJhFq4etZo7HID3GF
mG13RRK08cSTNp548rU8sf8v4AkbnidxdAFDfBlf/mIW68GY8n6/n+xxYPkm
Fzby1vTR/bjbGJxkivoibX/YmrnNiMkkth5pavRWxR8DTtiyty2d26Vw3/ux
eFHqYkhNQvdi0kjuNJnZQw3SHgS5zTan92FupIHRmBq5AgBgiUm7bGfK1veQ
tIoEsN8prNLBaH/8mFgBy4m/9txf+icUVsKWN4dJ+mT0NCEuHCTElzeJx5eD
Tcbcllj5f7vI4kXeD9PMAS/+GwsdLtgXrTEUnqRc4WKalmXe32tZ5md7X7vM
+/+CZW7mxIYC6It47ZeA9I8JZbttGWTk/w7Sb9Dxi6jPelcb3dvk/rMnX0v3
x/8Cum/mGX815fcblD9o1in4HfT2KPcZSrOU3VUpm8ynZXKw30Lyx4MWkn87
+FqSH/wLSN6etP3VZH/c+WWrwLpYD366eVv8uP+35fHh2T+evXr//T/ffHg8
ef3t3fP0oHr368nT/D/qvfvz/zUOBdZh3G0tB2FPz69dzu3L85l1/Rx2OmxZ
0MPBVy/o4b9gQRu59V+9kge6kvBbDeOP4hYIavhTQ5ottn3fQJfc/UeamJL9
yaDD7yD34NNWbOYll3jVW4CehmzZ0XoOuNBsjLqUDYNcr+kcMc+xqQ0mfvOD
a4H5XwD5lgoYD6Tc2zKzLp451/DjQxuwZ1LwrSvvLk+jh25G4JtDW1HqF9Z1
cFj1M8Ud9MEvqfCgj35pmQd9fHuth19Ul5I6HerqbZa5yCsJUUUB0axcG6eR
74eRW0NMtQ3G2Kib9mWbh5174lpG21LhwFjivOynz1SNiOzFcAz0xbaq/AI3
puafmfIi4pYJzUuRNmB4byoXV3paxeOhy7I5CbNW/lLkWz2ITjdg0zwiuyWq
sCW/RncBX7kh13c1smzadSdNuOVMXHCBn3n6c9RMhm3yaBxwYtSVYvPmj+bF
epZnJPuS7kM7gJhgvdHhbqPDDfZtpL260wbfwkyz/DIzzUN50u1nSvDG506U
/Tal51mo9NwMMuLyMUvzgy+BCLIlSBEfPR0/S2gH7Ce0J/YSb0/sP4DKQLHg
PJHDwR/G/kOgvPHs421QIsI54Z0R3vWo6nG+d1enB/mI7Oj3kuOZmUzMpWWa
8L6OB+ovuPBd9rUcjd8vinssmbhKt3pXxNDLIY7vK/VzI+MLmxGjmZbFammS
NfLSS8dKZ3wTOzacDZe3odT5wtgFJO9vs9JeZLM2ipvNhDQbKb2YuC/Py4Ke
1ZwLL1ks/kyy2EZ52ciUl80rTSCL/n993C3ovgABAA==
-->
</rfc>
Reference in New Issue View Git Blame Copy Permalink