c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
907e823a4d033715db31b32e5d96e248c1bc5e14
ietf-wimse-ect/draft-nennemann-wimse-execution-context-00.xml
Christian Nennemann 907e823a4d Move use cases section to appendix 
Use cases (medtech SDLC, financial trading, logistics) are
motivating examples, not protocol definition. Moving them to
the appendix keeps the normative body focused on format,
transport, validation, and security.

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

2865 lines
122 KiB
XML
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.5) -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc ipr="trust200902" docName="draft-nennemann-wimse-execution-context-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
<front>
<title abbrev="WIMSE Execution Context">Execution Context Tokens for Distributed Agentic Workflows</title>
<author fullname="Christian Nennemann">
<organization>Independent Researcher</organization>
<address>
<email>ietf@nennemann.de</email>
</address>
</author>
<date year="2026" month="February" day="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="financial-trading-workflow"><name>Financial Trading Workflow</name>
<t>In a financial trading workflow, agents perform risk assessment,
compliance verification, and trade execution. The DAG structure
records that compliance checks were evaluated before trade
execution.</t>
<figure title="Financial Trading Workflow" anchor="fig-finance"><artwork><![CDATA[
Agent A (Risk Assessment):
jti: task-001 par: []
exec_act: calculate_risk_exposure
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
Agent C (Execution):
jti: task-003 par: [task-002]
exec_act: execute_trade
]]></artwork></figure>
<t>This can contribute to compliance with:</t>
<t><list style="symbols">
<t><xref target="MIFID-II"/>: ECTs provide cryptographic records of the execution
sequence that can support transaction audit requirements.</t>
<t><xref target="DORA"/> Article 12: ECTs contribute to ICT activity logging.</t>
<t><xref target="EU-AI-ACT"/> Article 12: Logging of decisions made by AI-driven
systems.</t>
</list></t>
</section>
<section 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/aKoXQYmyZDtMd68tS3KsXpatluSk
szsZWiAJUYhJgg2AltmO1zgPcR5gP8t+lPMkp76qmjcQlO2s/NgeiS2RwLzU
rFnzq+tMkiSq83qWDePO6YdsvKrzYhEfF4s6+1DH18W7bFHFt0UZn+RVXeaj
VZ1N4qNptqjzcfxDUb67nRX3VSdKR6Mye0+N/HB2fnUabzTVicZpnU2Lcj2M
q3oSTYrxIp1Tr5Myva2TRbZYZPN0sUju83mVJZl5PxnL+8neXlStRvO8qujT
er2kV89Or19Ei9V8lJXDaELNDyMaweMoLbOURnJFTZR5ve5E9zTOaVmslmZ8
nehdtqZPJ8MojpPY9hZrb/wp3poV6STOJ5huveZPU537vZm7fLqa5HVcl2k+
49/HxXw5y9PFOONfy2y6mqUgXbWu6mxeRVG6qu+Kkvun/+P4djWbCUWO70qi
Nb0cvzZU4SeKcpou8n+lGChNfjHJltkCQ4svsypLy/FdVvKD9Eo+G8Z5Vt/+
T0vY/iSLokVRzun99xn6vXxx/PRwcOh+fOp+/Mb9+Ex//Obwyb75cTDYw49n
yUkfveiiYQgtH1f7VbIsi7oYF7NhFOWL28YoHh8empafPfnmsenkYH9gWlvk
pos84QVIzJrYJ5oMNK6TJfoDQQyDXxSzfLyOT9+nsxWTMU4XE+LQORGykg9O
P9T0M/0kXL9tS3Sk3bScZvUwvqvrZTXc3SUeTIkHxu+ykgnQpyXbJU7f3cLk
MsZdbov5N75NZ1XGvzv+wJ/ks/xxdXH24sVpOF/eAVl8URaT1ZhncaZki1+U
1BZ4WKb5PivXxSKLu9LMTvv8qmV+e5v18wKTqnbB0VWtnybpqFjVuwW19D7P
7tsmdfo2OTpLjo6vw1FeyubA8Lqnb3fi/b39g93Bk2ffxMVtXN9l8emqLJYZ
zfciLWlTzcHyWDj9+rhYLcb5LJ6l63wxjSfF/SK+S8t5scgr2nHlapZVMda6
rPPbfJynszintZzNcuKkMc35yH1x5n9xNK63ECJblcks+9DPMLKU/tnNZvku
7fJdO3hv/vgs2XuSDB63riwxyXDrHM3kmqR4uyB6URMvTo6S/cHxi8vBIKTq
Nf6N9wc9amKS4f0X2SQraY6O3lUP3dUxvRufzogdS6LZmB4Yk2isvvU/u8qn
i7QmbtrC+vf39/1sfFv2p8X7XeK6kiawy2Oh4e2O79JlnZXJ2S7JcPPL0e6S
Ok8Ggy/if6bS2/5VP35RFBOmzUm5msZHk3m+wNnEM6LHz89enJ0kZ2chOU7y
kuZCModWY3Cw++Rw9/TtV/IXsdA8Ld9ldUX8E9/mCxLvwkzU+wpvVXH3PKfe
47Ozr2KcSV7u6rACthkQ2xwmg8Pfn21O3lwefXYX7u/uHx4eYN6TfJrXNFVq
ROhMPxMr5LOcNwpECLpxNKmI2PRhF/38lj0kXYd7aD8Z0H8Hvz8xSC6dn1x+
jhyDp7tPDw6ZC7JJPqZJTrL3+TjDop9c/oZJSoPhgj9N9rDmv/8c31ycvr4+
fXV6fnp9+WM41Td0+l1ns2ye1eU6vlpmY0hDnnv7pKhliEl5wZ4GFb1Y7Rb0
xZcdaDyd41mxmsSvGQ3wQUyHLcnwFzSbidnQFk5U47yuGWXkNfEXCaMAbRTo
ISFBQGc5n3ZJzWe1eWjb9wmxr6AKejRKEkJzI8iTcR1F13d5RSfKmLc3LThx
OC34VqDcPT2+rnZ6tCKEKRVIRHXBS/KDgZP2DCYpcr6a1Xl8xaAwPl28z0na
qiRhoLoT+dPljTbxgPgGGEWbFmxGmddgn/icBhcTEntP4CmuSKBnk14M2cWN
00kpcp95KK3eRQ4W08dZyXzmgC29SZ3E6bgsqkpGQgQVQkb02Hy1UC6irp+v
hSATrK6oCBv0iJSI93l9twnJ4/EsJdSECf716s3r+IdsJFSPu3/94XonElDZ
I1LTilU+E8fZIh0BA2yg8JiWhrDyoqb/I48QHpqnZ+7SOq5Wy2VBJ6U3fQI6
tot+xLRdVUQPWiAcNWhmvB4T4IynZbq8I1l49N2OIzf6LrMlSVFwFtPbAPpx
ToMFsQFT6GWiMtNkC90s8/1wRnRYVSAxGK4i6cDLjA/mBAJmsoLlelkXPCYa
27LM5zl2X9WPFB5nITwe+/A4c/CYtCzdEBho9PHjAzD80yfigaN4kd1HL6+v
L+K7LAVD3ebZbNKL7HZKdDv1Yuw6bZsPF2xaLACmwqROZ8ViWhEjE5cCDVu2
kqYtu2OUaUz7527BMnu0ymfMhKNZMX7Hixvp4hIaol1Fu52ovyjqeEQ7tK6y
2S1YkLqoacv1fA7AokTKVKTYxrcGUxMtWY7M88lkRmrXI+BKC8Lp90fxeUFE
FwlHQuY3SwfbZSz0b2hjnz6Z/U7cX4xWVW21WlZAWXrIytZ3pCBP7z7DXswR
5pGIFAuSFfb7i+sdIjvPhpeigiowziAV9MfY6IHRxnB9LZGGbUTtXXFvh1zF
3php4dPxXVzQB6URQrTAs5jgJSGy2O0DM9zEzogmEdlPeRKJiBKPObGGL4v7
jLZ5b9MUwPyXOV5JJxPayZUTW1E6HtMhVqcjAkn1mujyH4viHkO6vytiglGQ
V5ARtMlENbNtiRiO7iF37lMcP9QTbQJiCP6MhTGN7tKKM1/O02PjMksx+9ma
yLicFWvQrVgU82KlglqkGklpaoswmxPjvo0Bu4XP4ZLkEU3gpJgzZasV0T2t
IqLTrL4b0w7rKfLLeswfs2KKLTmGxP3niqShd8j0RLhCIEfeeYMBznkuE5Lc
EDDJPH0HcqFBS9U+8Q2/m7htR8ySL3ih0yXkZ/4hzmezFWsEykAsCcoMxMJp
bE6HeNvebT/1/UM9Noc6M3pwRjNllR+yip+apst4lNX3GbFYCyv5M9zkG+3C
43yziN/KYecGpQQV1qHnaf3ziZ4kIe8cVdo/iWD+VsX3VjvLp0893V5qIaN3
NtHHIssmfKqO6HykZaSV4u75mCvfZxMVy5FBISmBadqwpMDN8ZrZRjwvZR5e
Az7/gpMrSqtqVYLpsGIkUWkfU3fz+AqwBC9hHcssoxGXvASgFPElZqsKKjim
LEiMZJUcx2ZD6cwixQkECwcPrkR4cMgyxHYVBP4SdxD9eEn4MCRxysKZXuqw
QZU+yyuFyfm/skmHW6UG+X37jLAKDfKaMEP89x4aoZMFe+XNqiYAHf+vfieK
9qmT1wVAGnbwxKMzU4EnHBCUB2eBHvc5yxfvGJp4cMzgvXiOw0m4xHIArcRj
6betO9BlIaKAtwUfpRkJH8f96JXWnrckxEKAdk0vDAkEoy1X5bKomAVODQ4o
RuA13UDUbzGzMitoDhCfnieREihH7swUFpZmGHlno9V0aoQS7Es0TrQgq89r
b14NUZbHq3RASr9QkFKsOFZ4cyUMPkejdUoQrEyy97wbRcjiczrW+SmMzgci
QptqTMC3zAvdH1dj0tv41aMlIZixEmiLtIMmxEf5Fl2HVZ2dWFB33P34EUhP
fvv0aYfeJbTrgV0GcWAki3GV10AIenuSThOCnbkofdLCmaJf9M373wlcKzut
2CbOoWZEeOXuRWnpKDjZxeJ5fO1QJV6FcpvIA/oSE3GWTaZZyUi8vE0JwXhS
qcJ78kBiH5CXfzOUpnlU2TLF2TVbe4J5G64W9HhbzGaCLtBUQexIm6eyC44P
aTcSFp0A1TINeYEt2GuAQT4yDI2ZpTFQsHoS/wcfK7qNzMM0NJIELHWJbUoA
zQnDhTircGDn1Z01VQTPHhMmQD8ENmb5bQaNKfOfAOdeZmquvMuXkCOXjtOP
nZ8lasX73vECcTymQ7xFl6MpEsPMq2ik02UVwUct2zaoJ7v09DWahwoEapFI
S2s2g6R3mkRTkSDSrFuVCeK426yEnW0iQMfbrbSzjxvNMCr2XimdIUtZt4ny
IhzpJUlJOkrAtoT2+FCht2Hv7cVuY4romcLIz3iPyJtWeCgaZeuCvmK9k/mO
DVFNVVzVA2+adqRV1JwcryX2FcmLCavqojNl3IvIvmA79iIWloWYCmTBcxwx
+NZqjth+1W0u0KzKPALxKeLbSETgjnky3Ka/3lZ+yaTWuuA0DeuYIy5hK8Fa
xsJn3kYzFhgUY4YlpJlB+a3GtMHoQTat6sty2N6mtM5wB609PYIJX7PVR/QJ
JXWNvUhsRJRdAFnRTCD61JgiI2XvCDUQtTzM7aoNQbpPdZlFykJAyGPRiKAU
xKvoHLyCnmKCQwhHyHusBQs9WPAh9HL+XQTZO6LjPSsFnfO3V9ednvwbv37D
P1+e/u3t2eXpCX6+enn06pX9IdInrl6+efvqxP3k3jx+c35++vpEXqZP4+Cj
qHN+9GNH+Lvz5uL67M3ro1edjQ3HPCn4liU+AVvGi1XkVozeeX588X/+9+CA
hPf/uHxxvD8YfEOoQn55Nnh6QL/ck7iV3ooFLaT8ymARWkzK2h7D7XQJyzvt
QuKK6o59W7RhiJp//Aco8/Mw/tNovBwc/EU/wISDDw3Ngg+ZZpufbLwsRGz5
qKUbS83g8walw/Ee/Rj8bujuffinfycQmsXJ4Nm//yVqHna0AHMR+auqRTrS
EcegeRgNAQE8JdgoYUxVY2gyJyMdwVuMKT3ZiorAK0Y0Yq/EavkoGNicu8VR
OQaTxCtidMa0FjHrkUTMT8OF4k7gvVJ9CZA+Q2xBwZgeounE2BWP1K74nbMr
Sl9iaHSoy9oXmVjb4Nc9GIp6ApBRLGItmAw0Yz6VVX1ipP0AJJSRNEy0Hz9q
WIG17EzkYNyw1bL2HFtTdEP5mGQ1bLJQYBmdvWLwZdaX1f8E+6lHcn++YksB
rBFMdtpMLNw3losowaiLV8fqsj3hKWDFDWQdGsLp5dAWHG2xoYkJTQgkOHbs
0A+fORCyljn/UDkMZgfNIpp6FHTl9+UZ48QW53e0ZCMX/UfaEqlLasLAo94s
/7kisJbMsvcZglhCSAieZlgnVqBgEgURYVmH3JYuttiS1op2QPK7FNZ2O8mc
tCRY22jpqaFlId4CmAU0uoH4SH4g3BsLKTxC5DUOLRkZUaucJPAvEwiX1nmz
iW6o5vW0RvxCZWw5vhbKuieYr+fhwXQyyXUyDSsNzjYhxpFvCvI1mI+PNpUT
Rrfynufxiq7bDUvbLLy+xvYZ6y3TgI0O7XxGMw85zaD4bucsTucS+BX/nSWt
//WPnR2/8027sN+zx4IKMJYl4zrqHec/KcvFOGc7jLAKm0owAgWq/A6eBNvq
kHgAbC9P7oplU595n6eCZB6wSLdI/dAm3Tx9fAjnc4NawSBIxcKBswiMXxeR
U2FD7cyzIYto3GJx5kWW+AwR3URVNUE5A1Nh1eW8DMxV0C7tUhO51PUV6jre
vIw9MYlf5Quxxo4FvMmWoeaXkGB0UlVFWbVY6Zzlg3ndRlfF5/BHKdwWz6DS
heaOfSYiZCuJZ+k6KyNjU2U4aujEX1mUmoqtg9vgb4iC//Vf/0XjGuc57aA6
+rfkq//8W/SrsQa+4t66ZrvtxFv//IqX8Nr1MA53U1ciqIa7u/Vkl1dz98NO
x3/nQt6R/fPwPsBLv2lKW4e95Yv3v5lyUECUbg5KHAULvBP/g81SiEb4WalA
ryGuySEC6OWBz3Se1b0GueWPQKtdxVLxXVrdwb7aNtv/y2n3Zikn0DD2ERAx
oMU7Ih127BCYDB3eaIS3obkIUBKdGv4nz9DV+e9QgfZV9HEYP7rNpwnvtUpi
TP5sg4LN7g9OSWaFqvNJLZG+O2NlPCgqM31ndk/lRhX/9Qej0Kr32xq98Y22
p4LDQ6I9tUaJEKwU/CuaYT/abCUIxDvqBDk0pPNtLv7CR4+CI/+iyCGYPz7y
znwCYPiQJkuIFRvB+virzxs5rZMW6rY7iKyNy7PaUst/fWPd4XHnXU78Drsi
7RH6nTVFa3uRQ3g1IkmpZ7CbF/VezJ314Q+g0zX82zRVHahT+KueRB9R7x1C
cx21xKjKiPAIOz1AjU0qWoOyhXxnJx7q2+n7E+RJjEwoiyMfBz4opmggCgU4
rfMxzVpzx2xalPTwPO4GpKTPPVLu8DCoXRr2WBu2Lzq1NGugWun0BzqaeQuy
8J6n78TNyMZqxeOySdXNPWXzP1Z/I2bCDC+HG7ws4dazMRINhorUw71xFHK/
l9ovr7txOtEg5MfniKba8KgPITX+BJjmjqKjvyC0rjlMeRJkLkMUA0158pdA
hngmeStJeIgvZapXdToGKoHoEEq2QlBFoPCtvSftkYXkktDDZ+BezwAr5V6R
BwQ06sgRVtj5moUCTUpsv4E66NyCclRFYmsTl6jaFlOc8N/arZND+GwYEXP2
mRsky95D3rHg8L5gUyJplr93prqurtmOtsBGBlH8rUvzWmNJBB3tDOPvzaO6
jC1qKBgQ6xhoYAxTgqmTFn6r8ySuXWp2wmfI3hfXJejQDd3bNDaNTFaOUd40
Pu57MR3E6HLMerUaaIzdAq5Jc17SyERsZRNq92gpdlBQVkk1EReRqIZ8RIpL
lN9nhW+bGeSFiLCPjzyXmIj7LS+AM1uD2vzTKlIplwYP27BsvHDlXjgkvdBF
wMBHgHDGK5paOlOVnIhBr0hTwRexMSNCtlrzAACEHHEsDHULfnz0S0FLqH4z
4cLm2cPNAbKmKgndyWWlqMqiXyrSfz8SoVnIIiXpav/wSaeHT+r1Ep+4/KB/
++W+lq9wuNFXErGQJrQhknySDPYfd6JPoUSREakssQPVyZx+SKGuQZxQ9zAk
GNupGtNNGHRlqd4Q9QgugVdCd3If4eiYfdvZsP1YiOMzqzaKusWNGL8V08Su
9DOOrcPomGYwRqWzVRYsYmdBqmOHHrtazxG0C73MjIMU9Kw/7ffil2gW5Hx5
9fjZAX4/HOzvbDADm0w1oEaCe9LKtAqbjs0TYK6hjpMyW9L2MVYkWsYGZe0x
nvFh11xhfDYR1/4qr+4kfiSW40mORaA8ZIRVPTam0rM2ZMShqbF1PbC3POY3
PETEVAOHEzO1LH0DFBnoZHaYE8U8MDQfIgy7Xk95vd6qmq/CpmSNelYU7+LV
UsUrM8a4DpomijreaxgdsTOJEMfi2aGNeV8ngoq9fblM13w86nas4lFhAksT
GCuoMRyPAYBWaB2EKTWjch806vLgHuG4do3KMJsmlZZ+A9uxYRUTNpsvIgTo
rVk3jKJczH/e0l3VMHG/Kd9ennHQDf1rlnFt1k7MjsaLFes5vg3d5hYQjOT4
d2Y0m4UF0GplHR8G/2lV/D/xoZnIofmX3T8Rye/+8p89AyDNoDrVamTgs1rJ
fLyKGJtFYoC0N0TW8QC0ZWtgvtX4LoN/wexzQlBX9MWrSgzfby9fD9++xYid
LgOcTWfedmLCLUkoM2XnX0jk6zvntRVLfr7MqeVutWOzE5jCz7NxipGKVxZm
WYgWZkj2rWkoOREmq6p0aoy2rK2qZUrUjQ591lA1vOPG2rxkn6krgAGNOIER
ZpnTR9ZVm1kWiAAmYPNiHSmHhSFFQgF9/kf674+s4cGayFodrcMsBzv+8Y9D
9ugByyugY3YVmbUQ8KQYjc3bHK2ZxQvsKAX5OimzT2tr6WM+ize0J44VbAOB
FvoZeGmiu8Cb9yngVF4boKPhLrTBR9ldOrs1KyZ7pG8nLr4ozFzfcLm5bZPH
l7WoX/RH3EuzdYCuTNfKpekthHIa/1IwYo0V2jmnjQaPARe2EMvMxAOvbvBi
JkavAODN8c6BaUceDiSZxkxpUK+3TNbMaMOEPNhuhmWEVrrQded9o4PlUHRm
eY9HhQby9E//6FjZkQlA6dPc1U6IoXT0yfbnJIRxV807P/2MEO1TxIiYoycm
8TB+p0wlMRMkRuBodqZndklXNs4WE2BykpCUMEA6R1nhwHLtuMgz8S2qK8WP
NvAPcW5hOePDmGk6dZYEtOdYGYHNHHSJTAK04avz+jb3dHbCg+3QZx2LjrAW
JirFvc97s2b7cmn8TWhO0kbTESyuoxTHNcLQeDpmI0FqUAujzGx8euj/+3/+
X2ynUIUzu0jGIEgjttJJB64Am4BSQ+y+Xs1pqcYnNHUT1JHPiagktu5yhZU8
HJKevE8ngJDmxDee1NSGW07Uit+LK5lqh/rUYQHYIOkTi8ObohaJwvGs1L6s
gIYlygOhh3aUTVMc+NmHJszbnAY9k6upjGfknQ4tGFglO6NELCGt0yH+GhzG
83zB/ngRGjwdIDBCVEhu0TksScGlJVtMkFFwlyMy2cAOcX+mpHywcWCM1BBg
2XfEJeqOh4uDuYMGqtp2AFY6i9FtJ+6+JrI8z6i9bEcPJAnwtJYgZvyRf/Ip
dZurU1nfEIdfwaGdAUVns3W0InWBlxqOFRrNL3XeelQz5JnOihH7hVaL/J+r
rGFs80WbHg5ML15W/6ClsTNKUEDDqAwlARjOXuXiB+fgM+E6hWjQvlMW9shi
EI9qh8bbiY0jtvKHID5pb4hdWRtevEkGkzEkfmOY9nFEgXKxiqPvzLZyAWZW
IkAEXvIpCWGrptBfqOlIQ/fu70ip1WHeQeGeEXdM6BiAs6niKH5rCPG4mKUR
+Au2EOwNUmVov+eVM4LIGnBwFQQPfIATlTiRO9y+la1lX09HG2+bQyVDNYUx
n6x2oTVE28gFRFNnisE3TRAfH2HzhpqCA+SKwf1cr1aIT5DoXvQmE8MTMqE9
tr2l5bOGy3KY5IyJWQACUx4ssnE1SlZLTXuyMmuyB9dxZcT5izfEfNv2Bqaq
yTcmPJmVQm+MGtWFyNfYBvTraeSC7xSzdFRO3JCWBcElxgmNnsxuqvQ2q9eI
PhunszFnGtxMCiBb5kgSHdlQSGskB44nIGlx+dDKogDEJO6YiXViYrw7ISWx
C38Cwr0v8glrkLMZB+66Q1Ke6R4hO9tIqDJDug6fXqO1ISIKcTARacM06Hdk
cH/FhETA64V39npAhuG/FxSCbek77AwUyUTQ2/XkkWL3WWsGG0mppfd5saqs
RTQzRtejRZzNl0AqPDbahJKegTCWuCwKHRqTYVE0x+CxJ7QnRWZQPAwysU1U
uo9OELt/ZiMgPz5CMH9iQyI/s51MfKkLoQwsxiZYPvIiwozrElNAfDeRIiPG
Um1RUgk4WZErrCxv4OLcvh1DHz2etUAfXXJ7YF4R9hLhGHfwXGINR0OgoicH
q3KWECUL0vYSPNBx6LVT3aXJ/uGT4eJg9Lfpj3fntz/8kL5K/jn98H35txfp
m59urj9U5fHBWbX3/aB6MTq5P55OO5pDSO/zuDyDmduWbuMTYbNyTCNRRjHe
KgCIo9dH8WveMWem5gxR9yVaPbKtXjL3l2u7iXXQHTuDx88OOvr54WCfx/eg
fc62AO6jpfO8X/YrEuWzjNNoKhTYgO7gTVQ2DlvXJtt6g0mOQCsCr0I6MXTL
0ndGLFy9PEKXZn7nJ4c9/mxgkjX5daUoSw1k4QPvvs+krEOZ3sfFuEbhiw0u
of1A7Pib2U3Y2vJbI3lZsQYDIUudIAEDbGnYvaN7M6jng3cvaf+N0vE72qZ+
BobbpBtvlOaN/06+syjjJhA/8mB+PCchdZciFirlgB+JpYHORbJ92WGU+S0f
3h664FCWzIarBSJDca1D0CoNNH+owK8Rn0Ssz4HxmvjIaHebkMGSAFhBf3HE
g1MvXPk3I4ApFcvWm1/wp5JIxcavxCAIMJ0IRnGTPWRK3NgNkSqtmm6xWsBb
WIux0nStrTOP59NFITrcHDheT0s2r9rzsrLZmhNo1Ewndf/3vMIOeAcncuVv
cQjmsspMZByNSauIiFTsEAf2rX6+IkLPbzgNvrNjj+6WgTSyCiaI0WTs6BgU
HFfwGclK9IiLESwmtD6su7zPFFxX+b+ynomGY68PNcNeIHtWy4iLWw5X68DE
YFbPBX/HaJfePNj75gmtVQ3ru0HlaC0imMqHPo2bTl0PMH+mwcOII1CrFsGn
DwtYD6A6N8nLHEkzJruDNcCqvxm7Z3iDFvEL8C3KS0AyzguOmI1x4lSeDVM6
c21pBDo1B4tBD4Rc84vVHY4I4Rr/LPdYhhbhNv+gAZ2M9X66gUD46WZedYaC
OrKy7znX48lK9Wh6fZ6DeZBqOaF5Uws2rfWnG+mBGrHC2culMqGe9vimkxOJ
VDj8NL8bP84RSJOWazoI0TrH4vx0gxnQAPymj852z19p4Qn9mt+4l0BdjGe0
pheO2u3IZ4HRlrd5I6bXmm89K75udY3znRi1ktBUCLHZ7DO7TSB/S6LNtyyY
nKM91lHiDOcwYfVom8FzMsZqNlHbZmDtUU+tGHQSPqB+uqGB0S60hXU8OjGW
rMCOdf4e4jl8FDqt0S/YFcQaRLG4zTV0HL/TvoUDjiaCZYmOXKRyg9Mxy+Vn
kxOj8LD7XBKieJ+OTTovThD1pTb3Xe4bogKPlMrEph8YUUTDLaZNMYGOCQUj
JU8AGyxsDz9v1DBuPa3p6cHTp/t7Tw4Gh3v8IU5g++FT/RDaCLV7eLiXPTvY
20uy/W9GycFgcpCkTwdPkoODJ08ODw/om70BNY037tUpvTcajPcnj5Ps4PYw
efL02TdJOhpPkux2b7D/+OAQn3S0X9XqhlhPCBvip5saFjenTcJ+MYz/8bP0
YaHP8LNguxVrc5MGv/mNvDpO99L9X24+FDeH8723z15eP3/++vnr41d/f/5u
+jSZJj8us/y7v84PnxzodCGBh/FHNiPLVCCzRGTtHxyKjdrJIieKnJiRR1hg
ePKkYxY4ERMdsVHy/qC/D3j9qeHfR1Yc2NJ4+AOWvFBO89z8j2I/nuja5gN/
fOSnA2vocjPgSt96gdNbYxfDXBZTOKL206jd681COJFYLwaDvU+ftlS9MbBE
TOR6qvltqBaUO+sP6iX9cGVCQMJIj8g35knUiOJWaUa96Qr7UUvheVPnA6yt
K5uzzMfnkvooJnG30ydQM75L4UGTAMkjE+pWaSmodGuYm4m3qh4Od2uGYvkV
kmx4mga8iWyJvju9jnfTZa6SIGH/By/H7qA/iF4WVT2M9TseSt8TIlFL7Fu2
/uvd6Ltx3u/34Zvt9zeHGzwEmwU9tBHqpt0EoW4mGo9NF1hP4Tob8tZ0nkjE
EweIc5kD66j3DWpK815k395KX+GqGfOxhg/rwkx6bO6NEG24lrU0XPBZxlPN
zkZAqtMyK42pHcHcnxsbjNJ1JKCeuOl9PpH8B/XjWlv0UtVYm9Is6puvPzHf
n90iB9vQCG/ecgGwMKQN3GhH69mOxRZMHFFa+upe0swyY7KKmo4qU1FjNjNk
mBjPgDWi1165jEgb1HbCqmE2wtHUZGy4g/9QoYxyhQGKMsqhbDDMfW+zvNmc
FdRjYAn4Rku7atYGlpBW7qGsRPWX8UqwQcs3xtOsAp41kY18xAmOYwJCrJrk
FFM3hlHEtox8dagQhTZztXsRF4NjcsDrXJQPVyaxhkEgJGGsiCGnMc/4CTAm
HzQrjc8M8pC9QXaV6siYEUFzR2L2EriqUFPomnWoj7NvMctFRC6iwGuuix1y
hnEvCUvlC+xigWreWl/Cz6n70OMVO13NxKG2ei6Z3jdE6aijMLKvMbuqzpam
jM61MD5KU6o3YygeWva3iE3aGPjUZ9WIO9WkHo5U4jSqrgnECX0MfBoxEOsp
hfh13aWOsPlt09eyY+SBOnq9yHJBKTxW4xeSEjcu9t2MXiQD/LEc06pWci5U
g00wlLrLTbM5SduqdnHjvB8iFzig4ZQmalAEuzgv2HnvCwFn0uEGZLZd5SHP
nG65VV9wXGXYh98XFhLzkbXAO2bbcULUl3Fa4kYiTlaLyYN0QozudTYn1EO6
yxvdtcofnpsam5tp53ekgfixCVecsrNazaBNR7eaykwlKG5gOUOBNG6CFawp
qdXWISzu4LqYZZzPFne9rPZh/HgvVp17p88NXMti9FgQswSUoQ7j/5Qf+jSY
+E+Ej/LZhH+WNCLu6wZ93di+/tP4/W3nmg4n+pwbHrcQgsRv4cW1MejTFR3Q
dIhySTbSF2OYL1DYVyktq8Q2dELvFQoPSa1F+OyPw2fFsZnP0zKfrX1HZKxF
Txo1gLq6Vpnh/w2L405PS6ZIdLkdQTtfEfNyBXL1mbEARzJPz270LTx2AOOE
nFaM3164ggLgCNQP9KSod2YZw7tGgpMuwUZiNcgaVqJe/1CJhNCBSwK9FLWs
eRSi6zywDw65UJRLuIa/ViJbxzTiC//gtOGIgMLOmRyLDT3I04UQLJq5vSzd
JJQkjW+5SLitxVX6pXfgCmcXuK3pw0N9tIEfrHelqf4vq2w1KaA42AonleUU
77iwUE1TVNx70e1qIS5b61clrNIlshEcHdc3zEe91l20g9SV3d34is6ieDD0
zh8JgYK39dY10jfhZGi8T6vJHfTpnNgZKm2IrYkYZVmUXQ4mp0MtPBI6O5HX
575dOLcF2GRq5J23C9lOww/f5CyW0Tf7YjnDQZr5szfaaVZ37Qs7Iq4tD0ME
k2psii+HI/edt9h+LKRJ747/Ld7WIMurv3D3IrpaCf5l3WUoZG2ktO6hkG6P
h/ExbyAbABJ35UguU9gJuHbUPK8xSFSqwuH5Z2Ch7g470irSJOgDYt8b3ojh
gtKMAtbRFjSobuPPPP1ww5Xc6Okb2y1RRvtBxgomKoen+Yg2XNbGNcd5iUiA
MizMoTZziV4SezYMe1FkX69WY2DOyG0HNzsp133DE7QLWPlzbJuamTZPkPtn
NqeJ6Td9OA66O1h2+0jblM7TD/l8RaqBEqm5Sv6EWvjcjXgY8hy+//OfYze7
BnuBxJtv5AszfvM4tnW+0GfN3NLJpLl7fsseI3YO99kG620uTpMBt/DdljXS
p7+c/zyKydeOqaRWu2+WCNVAY5hoSPsLK5w7GvAwbuxW5QCV9ZYxpFwNYiug
8rC2E/l47A9GQ6wU/4ha9kFqhcRvut8bDfN7tXjpbUAcLmJ6WRRc/RgQTBRj
k8/a2pWnolKnL8C+6yVXknNVTln2VHccPoiTy+QF5FWU3eIiEaxq4I2jjZ2n
M9RfMWUnoO1mH2r4sdmfR2KuKBFDlWmLTV1LT3mFWai/2dhnUXOfhQB1sEd/
hBiK0xno85M0cKaPU1ebK2gUYk/JsbAjsrBlq8dujMY3GhX+q9i31hbbI/DG
ekVJ0UaNlEXtJAqH43hJcDhNJX/ue987/vFRYOwRFdh/4MLgjWZKrqo/lVOB
60DrDfPZosAnzzpvM+GSTj/Ngt5uHKMZgzVSNUZ4uXQ9lUxrLV5F03X5QFgj
AurQCmDy8o26on9+36hFxyl1xtDnMqGIk5s5WKqYbTTAqdBtDUASStaZ1JKU
8HKuchJXm0loCspt+5kmrG807YHxNH63KO4XWp5QCBNmYWnlGM/13CgZdMgO
UBpK9t7PgQ+TvcSIwMNxVhGzgoKz7RI06E7rKpx+2N+n7p60kNAkm2/rEpib
dSIEAYjsfk8MPtk6qy3hQgbhitJBvf2h4qYsr9IE/KLpfpv06DutYuzV6LSF
NdU7Oc7kGiXYf72WYczoxW+Ory6EeWmva5KUdDFaoS5pvFoCy3Pi0dMGJ7Qz
GWdLmROlkVSpGvxmvv2zRtNejQK/vZbkK3pfbDCN4kSOV4Ns7G+ac3AZSkGW
iknC+INkXNji/Hymu7weiSbmRnKWRWwK6mmmQbUyp47lKwE3rvGNVI604oBs
jbz8Vg3kNiVdlkpMjZonY/IWrC1BIh/CyMU0n60QOYTXfzD5AzbTRN1SvuWy
59mbhAjB3IV5XUlEpgHRd7DXD+jLUVMaNmuCP+1JZfYQx1KxyjoYhK+zXSiM
11/YhAASJtI50yitxJTVDQ9oG8zEjrLqrpiRfPYOYHtcK21d1sKOSsgHu71d
sfmbOw6O9QXKokrV+YVnhIpTbBiX0xgwgwU++RyRQIWxJjWMSdiLg31LKPFP
qNVbwyy6bOXoeb7rnobYIwxGZLKmanKGfjabJWLiRtt0pFzoMdrU/1mONotC
4x06Js4kg0/SljiCTiIEw0o2Ym2RDH8LWnhELn3TL4Tj2JC6UWvTxnEuHqHt
BkwTARXpRrAPzIrpVBPpG4XL4/iU4bpJcoy8iCgJ8gXG5Z1oWazpQbJ17dlV
aqxpvLQGgeZeBCxKUs6Kijeq4J2NohXi+SJEBNkZlCNxuTC+L8zlaNkYLbFO
s5DkBg72HsddAtSjfEKbewcqC97HCU1LJUkuKKRuHdfATvyxAB1tZBB13y5c
kXzTjq3cspkbLZPRqGIZF8mtUTFZN0t7pDFNAUlKqkKpKKGfNFQrcmHXYjCz
S9LOKoyJr30vXCRUsiG8Sk511TGJbQqQZIE01ya61RKYGyDWGcm2G814L98Q
s8IIcvML6lwayUA67Rblk09qjdi4QRiRp68aq5oAW4FEXUWrDqnaldkhbXiJ
R9G3GYOx9qikkbfF+CA/9wmpxv/jzxu4NLA/yCbsds6Ea6C4Obwg1hPXIEEG
WBMUo2KtqxsLTLvuoZ3WLkhfuMtHbGiy2MParF5pGr8DBJGBpiAeEWCDnmxZ
0E7fiWkBhgX3TmDAawzm7YKBcKNEQadBVLsC0jYOG2UGWoAb++3G0j1gjogD
8NvzxttONbMw9pXmGDmgli/QYIwrI6WFoc9v9DOPSr1NOrb3e+VhbGvD1vaa
Q3BQkoY65crVESeZ0rLBcEM/3ZAkRW+bC+bxFjErPdrnOiItQ3L5B3OC0Fwd
RK/4um6OSAMbDT6FvCR4qulqbH7iherTc6ZX+r59AaQpi+CkY6/FDWoo9lND
oBMU/Dpb66RzLhbQ0iOElzyqZdwlLIFvd9G6AM0+PaQWTpA+hL9MwAtHl3Xb
19tgPm1lg6ApMvEJo7HpvysB8kXMiE2n5SDXToPI4rMLxhAnYhSeZjcW+20d
lyTocofsrkmnRaelj780+3jIwr69m2AqTTo0wJwaYw2Ijv+xDdv9bA2z8mzI
Cg2rrBnUeS75s2Gn4mXgH+3g1K3DkLBrAiGcr56PZXZDe1EOgZ0/cAzZE+hL
DKytXqNW634r4RsgVgCApfpRiFkRcqyRKvmtiUPwfPcNb9SmedmZpQXGmqnu
OIOu5AcFFt0Ap3h1kLYgCQmSDEpNntmrUD4+2rj8RGODNFLMDysgeO5qcgdA
XUPrTTXtYIScfV1UdXJXjOmXdLaucknZcyjf17K8i3Ca96IBW+bmgiZlQomG
9mt4RPaKWxt8FMZ0Otm5YDZNHQbEapAUiPj2kYIg/7rNGqP1Wbxq5dAOCFIh
CQo5dVXUUkcX4cA5xwGbei694DIjIUeFOJeIo9hkLM37T2z8lMGbGsOEWSOe
3q9J+KAyFWq/ahOVxtXSeeRNsELYOG6EG8ZvxOtpIL5hEWdZleANZvF5MRFz
GLvEODteTZlhZIgOUkttST1PeLmL2g9XkKsvTAQQLrVjK3yKm5yKulhoFJm7
Py+WMDkar7gVTAk5wncE70ZcdYj0r80xmExA6w3AhoSVMZ2JYUUu4TCjgLGP
44nYwqK20LPW3NCgL9VeWu5SE0NfEdw+sihsh5x6xihIbpYyxiyv7ggn6elV
ikT986x8h8jUMhMb3eYoRpklvdgvUb7Z3GTZrIQRubg6vY6wYPO+liItc1Js
cedKgYv8tIJUzLfZoz0OhTBhCpUJvVZTq7t5rzLPj4Pn/fsjaCTTFclrDUZh
0+3jw8N9k9KAC+SIdFqsOoxlqOW7dMxBhFLtW/qBr5HLayPAxN65GHdz+Vrf
3JFLC+Q2iIYxNzIF/jWmK0gCN1VQ2F3n3eaCXBM4FMpizhffa69IACm5Zn2N
eplc49F1zOlTYf11C5GLUbiazYbQoR4KykclN21MjTUCG2qtqcJ7ee12srJP
5DajVO/gTCnHoEY+oK9rFAkhQZIvJWXpgc7MQ5kXRRTxlkhn6IUGq2GRLff5
yHVpyA464uwgfPkKjjLjTfIyh2D6m9nvPnm3UAXpRSYiSnsz1hJThECq2wgM
u5cSPChraTLqvJIAQbFbjqF1dW4hdHHzsuUAmJUaTDjmpCVhIXcfhvKSjsAY
9PGbhn8ag0TqR6myeSKXS0pJgu6Y65M0FXPrRUi2SvEXXIYU+5ch6WucfazF
vKWWd9UIiKylssMKl7Qju8pElZsWvugiJZ207PuvuUep+XDUdo+SOIhx9/IU
SyFR54kZmFuN3jY80yiq7NLqkFUXBWlfcdeUBM4XkqnDyaa2ou3Ci072kuw0
iQ7SDbWX8lpvvZcLWgU4AYyZa3Ij5lSbgdK6AaxyUg7VAQ2DV+TS6pR5xkXi
V9I0hlUDhBt3gdqLuuztFV4Uv/W1uU4Mm0V+nqDJEjyS2jpe2SneMxip1wRf
VDNRTRj0om22RG0jTiomYJYtpvWdlIphjvHSCGO9LS2UI15yoTECa3JhbdPD
t6QZNutRevOS4AbBF35EsVbxigXc4wgbS5TsIuJ8BE2L2WQtL6PQaGc+A5np
ah2XMMBTROub8GKYCzo3gEQR21KpCBEU7q2nuVxMnIa2IroKUBvWam+WnSg+
E1nMIBS1+4g+tOFdaSvnum/cVmPuxNNL6OLlLB3L7Ru4/9BdUOhdhjfkmjr8
EpdO4Iuezd2JKn/liBWHBW4mthnDKICssZ/2UHXlQfxOPOiFgoQNzCXnaTvq
ihuoC11JEWXvyja/qyO9WUTyFxj9BzXzxUKz4GCUxcKU9DGX/VbKt3YaerBa
I72vcxrFcUtJd1P70q/qLs5qWJw389faKvRuq8QbqQLn7CVhpc1GqaiwTGTk
9eQlbYTluU1UjVdHDLc9Kmzb3kNLjEAQD/CZWIC4W3Ggd7aMn7TlPO2Ip+sh
rwmbW25bR+GP4AGPmCRbzNa2OIDvGousawxDaYtbwPHmhRtz1MwsH5WpQEZq
0wZlW5U0lroKD5bKvZSSYkcMZSGCtDiw8qE5GiVdv1Gormr4YA8T35tbF5Er
O6d1ObwiZgKeTUSbHxhgcrgRjMWP0hG9WljLqTWYkhKdursjrFVVa71HXMvU
XwGSC/LdsenUc3dzOlRm04Q4HSryCyxI4VG+9VBtpCCVcSGsM9+tfr0R8+/y
tVxGus5OJR4rtTKfyD/FgtwwGYSGVrNykDrjEmdQSH5ZeAWEglaca0SP21nK
PlgpflKwRmVHs439PGuCxLAVt0wqQNqEK8FJnSqNjUCpag5v02bN8dxaLs4U
izM3gehlV5OV3FiU+UaBthQB4uLzdJHki4TaTc7zCeJoLixVQzDO44F6bXKK
5YYWqySbW2tNHSB+Toq2yml2/eqK9Qn8S4fjQjqpTHAK1zcMS25HD9y29blb
AHqRu5zZ6vG5q8TnZyDE4ho+Fwe6O18qTag+2B94d3pDmZmxIlujJgoMJouM
NkwucULWhKLsPCGWXPC1bYkEZUs9C8PXosq8utplunTdoM1tCipZUHEUGsE7
uV5P9WVWNhMcFru4O6HbuPfFtcG3xGtatI3kWUh5ZXHLG4+4irhELlB4+P6s
5oUK9ujjO+qZwQB2nE1BAyNaT2NOwbGqZ48fUzsB70ASUdMs8kSKxPTQjqFh
T/MF2tHQXFPpuKEiQbuIYBpiom+JNLU1VpIZq/cWbZUoxCN1f+DpKCUDls6l
7l2xkizQSQrPNht3CcjdVVzg5MLN0a/8zXCWAcPLtJzcQ0Ba+9R5MeHisd2X
V+fsmkAGGAFc2smM2/GcEE2ttP3GpdmNgmKk5GiFIhdXh1feogxotQJ8wTZ1
5O9tQgHNVMZprSFBvqGAL8nhKCTSzLS8rgmdRFIQvFr80DLNS6Pm+xgt3WhO
6moHqbAaoKLgVTGRFypYZjxUcRLTYhNxWOM0JWxhwZcViDx5HqYsoiCYPzCX
7Dxb29hJGl8naonF0TImanRkirxgVdxUqz8yeuWGWYWkCKfOEJMH4Tne/dam
6mvDTWRv5Q5PvCKM6tHQJKdsu/x4tpJOrLpaqb5qjzhSc9Xek6plwYkFofJa
Md46uFnORkOdyw7kbabASLagp2Eo+fm8zDY1lTYjcRR/zkzcprD8sKlOD+O3
Nm51m66qtk1j/9hi/ohbzR9sWGWdODTFn5sVyDcJgfOWHqwUfeh+S43Taeyy
+dD6m1WN5ICRLXA/5LJrYm01+rmU1VAvheoI1ojKZR5YWVMthHCGiAVLwyVI
Vi6UzU84JYHLLsnZHEUPhFCpdF/VqTVD0xJ+QMEgErNRl6R5WXzI51yfOB7M
JQQdDdLLODJLZCipoOTrZHDbCBIRaDdE3m74bIpHvJniEW1N8dhI4ZQyTyal
Q3M4kIpfmRQO57RpwYTKxsg/X8dsoGCoz3tPzs+jizO9gZJwtAm+cyXYmMS2
VH4l8/elgcuq8KoBsGF8y8rY9Ij7VOqtkSihAw0CB7XKFioM2W2uV4q4Uglc
EU4Z4toYynEV46pMx2uV86y9GdVHMoK7rEL0JO52R2jaTGLsR8cubTrMSeZN
wfmzsg31phOb/vjLajKda97PQ+f8ejG+K4sFV7DjCuJm5mrBfn19seOX4JSM
nfTzyd3RA8ndkYiChr3Iv4JDi97LVKtl6lVpEe+OOeXFiO+LH28S7Cm2d+yQ
pJ7eZRqeG4WjBRd53WsQv3/6u6xec4DaC+3FRmMowoEZLcnuooQ4UkbENmJd
mXnGz5bLEqeoGlQsBCDMmV/NqNWw3uQbCZKApG5WyACj4FmN7Y5aR9oIZya1
3AY1m2KOchg3KimhxBOymoiZ2MEoueTGHskrNW9koLN1ZIaEvo0yl8zikbqS
s6DWE9Iot/O1Mx1I3Qep+cBJ2y6CPEY9V3Wb9eU6PslME3aRKzJRLWUjg90G
vNZyw7zctKKV5YkYtFxy0muZEjUYfGkJSDasRl5dSToAubSktwm9FwE0/SKR
xW10GEv1R7FdEVopSFXcqDrKpqtHgs3Hmw5hU6D59MOSw5xt4X1ZzAXXa5Gy
BRLQy3DmyNevYF3qcn6IXuMhUq6hRhnkiLfHWvMLvqqlrGnXxU7teLHfYK2Z
TaljD1HixO+XSVfP0UhdGmnuRY3LlMQHJuV6kRPqyu2adI6uWgYmLbc3R7Fx
ryFQwlWb4+V0deN2GAsqXPFgAmwh1ojo8xlnxrFuVZAKmfHl2N6FZPr4DBdR
YPganoIrqy8Ijhn8oaGuWujEhbd3L87OdhwTnOcL2lP/cpWN6jSZe5992nrM
61PiX/N7MBWwDF/1I90lpiz7xrWn3vXaLRe9bBSO3wkKu/Oxj7TOdDFdwcTh
MxmKjQUVHi3E7bZuHLzMdy2J2EbyeQRguBBMe7ciKYdKexOmqzIJB2Rk2E0S
FiO1KrPYBkuls0gXG5Wfs6x10zIn23gLrqQKTm6njToLNIwJDHfEKe/GyWKU
UKuH+/FKvqae8muJajb0vVx7ktYRe4VcKoFD2mwvMIVRBa2UjFa4aPC2HFcV
QiSYeROxBlmzVZcnrlDdBGZ59/84epZeNVYprv1iNTP715WBlw3cDTPc1O2t
G1Y5cyfaMFmYIm2ztcPJqrSIKu8stUK6yPjCEMbP0VuGTihjjcvuvVAjiRsS
QMd6GintEWdV2PbMSH0pZKIbuTCAsdBbWhxpsYNNkXdrRAtBbeNbXcf/JKkh
Dh1mZzvgKFxYY/M0pkHDiJ7JwS8iFhnZ+63oyhjIRmyzOn2CFJtHUoq+5ZQ6
h0CMr3HphNahT03IASLuDEZTIx/Od/eQ0ZH9e6DRGq6wiIyn13VQdczb64bT
EIOj04JHgcLEqOatFbZkMFerUe1/GSZhRNGljSP0rvNEatqClEpzYXnrl6co
IsmYL6ANHng2yutvvUDBVK55NCWu2BG0ecNpHKZS9zRNh9+w0XxEuI06lsqI
1EBbKcugiOVVe1wZBg3Jh+FsCVWzQWrmGiqzwlA1wcUsTxVbbLYuNLtYGV9Y
4waWYRxwTRQduUVUo6sEi/A9doZV8N7mg86X5qJPGCoTb99vwk14nTeuhkQG
u6kl5wGfKqxP7J2rGMp5OqUuRMfvVjs66Th+gQub7JHif3OOXuqCxM4tnmFO
xZK6ZyJBDTwQmBhnJkgQkojlsNalv12VfOo2xnR8V+L+UeLF16YCci+G6+J/
2orIfSRdnRlBsIIjgt8kHfLNa+wQce0xgfng0wdkfEd8Bm3pihROAgF6YvAJ
xk+enV6/YBniV7DlWrSBKEEpW/4u8WXHp98oYYJytUbGvFwDnfF1xnB/kK7B
Xih283Qxuh0dF+7isPdtdKJWKSRPGkmzUfqTdh9nquNL6pXow5x+1YjRlllt
bIkewRK/sO+n5q2pDcoJcPldKKeBYvlCauo3bnuW7j8noX+V54SO5pcThwXx
mbDKsWUV+uzS3vDwa/TrMEmSIf/t/TikL0iqT+hho0t65dfpUzAb/QNQ5+6K
+oT2YgN66WtRgXa5viOfJg++SFKWvtFqUFIT0kPGD75qFBE8xdCIgf5L/cS8
134lj7RgdBd68I1Aqq9uAgz/q7sdQ2+9CAe+gYB/5UQMToLQD00SxhYurJCB
cbFRsN3cy6UxFVzeWh46MeF538uBZlnqK+8vIfUxSbi+HQDMWzhBkJtAu4IO
kYTvP/hEkxFJnU3+3GHXQudTIxzblXnzb5d4n7lbFOiRudhb2BJwV9xHASpz
B4sBZfkibo+JFHNFlUVaSdlvW4ik7t1x9S3an6zMID3jHZwnkc0IdgdV49KS
OLiHRgP6OPQAFUkjc8I3L0LWKwgaF2WJl8ePYodtbTRCURyepeS1QCljcCD3
E7sZ9NgQ58ULCEy2CR50zo2yCJekmdowwabqWzAKq/hJxq76q5NXx1YctK/0
GYd+6WsTea0qbut74TW+o4SFpCsb0kWzO73o6MwYSHHXARzYUgXZ1bO+Y+Zg
FcUndWSygBBGX6ymd7BPs5GNfRA0+/BWCxsqWOmigsk+fnxxcpTsD45fXA4G
Xp2WwaA/2OtmYjT++PH0bXJ+cknf6wAiH8bYI8AWjjRFg/2Zm/xuLKAljbkM
MiQdgBFStcQOdUSkIt6hqaDmMpz1hHVQ9YyZJ9nbG3B1hbTEbQCKv/iyO9h/
6I0bn2g3YMNIW34ed49RgfE71spwEVyz6X3XtOks7MLCw5s5+7pN08dx9xr6
Lv+20ezjjWb3w2Zlq2c38OzdVKu8tg2fxN3nK4T5tLd8sNHy47DlEV6+UU65
geXjFupC9JL1w0vloHMO6yybrR9utH4Qti6cl5n2+Tv6+KPvi6SX+/3+z59i
yciQM4P0oRRnzE6Qo6cXIiTVZDY2x8NDm7PzyXpqOJ/QL1CtQk388MxJtsZX
mMIV8c2tPY06ZETDb+mahDWp7ascdjDJ5DWGNkzp2FCYcwNMQqbNZ0CAh6rm
ZvNKRG2Je2O5LOtsbag60Vw1fk4N0mGQmfgiYEGIWGpwp9W7fLkUx1eZseau
hoVHMe19TWlkgwcau3QFwEGLVml3ItUwUt9KwwKBg13QqFK4dKDQBqbrZUpb
REOQRWikRDBlET1St5wNVvXaJJVlUjtezGGkqAZXqBllLfLvVOVi1zvO/BOk
+omNxJJDXS1GthGx9BoFK4a62wQOQl9+pf/fR1audJuSY+OZxyZqyRcDG08d
xN32Lb3x5GHcbWzPnfgfzHsu3n7yc3iLyCRNVNLL5vO4gzgK/II1s2xkyh6W
G4/Z8McwmdNyhc2G4WswHfPaTScBEl5hMFGmEaZfc5CgquV9TWxxYMlaO9Ce
p050F4WEBOPz0VpSkTnS6UiNvxpQOCuKZbgHcQnUzLBlb8N7KXUSmsEZ/dC3
IRezNe+tMnBFA4VsyWwMtK+IElZY714LVt1N0jCPhQn5uZN9yKYiaqBMxCpZ
Z6F1IoqN/FRZyoZKSDiulsRRUiYEz1xiuJRztM/9W9BwRND6Q3x2RkooEoLl
pFfMoL77Mh1nxt5zayvUPwyhbC9HZ8nR8TU6giGfINNgf0gMWRewXIw5rpo1
z3QpXcClBRgSsy85YZs+wTC5IJ6L7RSz9y6gqkVUPdD1wVAEkNjKmXQBlwtv
IRaOb/aZ3tWxBkbaTC+tNuRJe9cv8OkLvoMMQSvXZSpF3T6PTm/tS7W+ZCRi
zwBQU8qRCYLtUFVsLIg8/grvAOFTjJrz9lvbwRQZhYUJ4LWmZQDkfBWlzh3L
3HDkGm6AwkteNjvKL4eF7tJhTPQmU99ogArNCL8eEWotGS+P30FCa8X5byBC
JkogpOVGOiOitzOHVUm/VICcn704O0nOzj59Gob+gVCIey6C2pe8bEJW2SsL
ny5sKCcHCGtcukgd/9SU/XXy5vKosatlawVjP0NS3FhvjNO9/rBoeKUCgQZs
cvhwMtDEkCFwlkxK0st5+CIR3K1urbeptm+67VepOoVfPTiS0/nld6mOEdLg
KfHV3JC1Ci6vs4qhy3VjRbcXiTNgli/eVQzjxB+NVzhPUNxSGo48k3RApgGE
6qKYI9yTiAgD7Rh+SFp+xC1vBYwsgGb2BSd4vNDNpkywl/yoNEDhfclpsQUg
WjFwIGoIDkau0IonbEzrk2FTqhRgq4sZUZ9Y5MuFypLeuCnxsi9HOP2m+g1C
xFRukQSeypMhV3wf1xcIkC1yKS2nhd7A7umUF+Jv/wJ9cr8Xt2uW1n9snPdR
dMX7h+WpLtlGB59VKWW5b8zyB6LPsZQKP8eU1nzL4OwiLYkVshmbV9mSCPOT
qngcwIRFwS4FJUcFvSJoThImsZXM+vMNkXSAq0DWSu3curnSB2TzEqHRXK9h
3AO+Ib79A67ZEdTDhR9MjUjToocQNbr8lyLXhGP2p15mYvzDdNv3Hu3a8DK4
2F4Gt8VoaW6PS8vxXY4cGmyrjTQVfEtylSsvu/SW6GvzW+yZAopYPMk3L4hA
Wi25/l8ud5iJzITGg91v8kXoKKFdHXWQaJprACtjmn/XCB0uVpPXQVS3ybl/
l63pMephlgXGgw6ngiCx2bVHsJWeja+LaaZRKdla7/9a2NEnuD0naQRIWeub
psA1fIlRcNS8gR8s3u/vqVfk9MNY3BnGzN3h4Bq2krevIif8PHvyzWOisH/7
4taW7Xohm0ZM5ZwDZzvrHqG+x44ri4WvPFu9Ma9rCJAX/WPKdCykpCN7fExw
oGV5VugjVMSYqmEfJVeGsVlTnPA4shFDfpfObnF401fzfgd5V1g7DonWKDo6
DgnL5mMO+kfkSTbn5L5UmrX1gtkXOVtHKKOVlqRwQ9eSsWuQny1SnCIZpqq5
WLDOhB/cQV0Cez1dkH0Ue9Pxw5jY6G13di8SkVJyIicppRs2cQ7t8Co9uHRo
jo0xCZRMcb6zR5Mw7LiiEUJC70CZ7i0pttTOTizB93QsTBmh8Rf5YscVGMCx
G7l8Dr7j7ui7vk0M9UuxmOILqMSUL8a1qYgGy4sXDmZUOwF+u3JZFxxkmzd+
e1WlHS+pCai+Z3c1anppWntJZJ9iLEN93MAA5h8vtAk80+u0bHRYASa0uD3w
Nn/CtrJ+R2LCPbjKO6dq33eyvzaf9sVggeEkHgBOJPr80yfk7C9TzvEKGclE
EqhvwFTHhioz0+JEsu+uPywS2dkdwj039zOzCUkcreYruSZKQpDTxAV4oKQD
PDWm4cqZToXVNTZSAqV5tF5EiYYgV1mlF/oE+YOsX9A4E+FNIbpUl7EpPG6w
TXaLNVlI8mx418pmHbZMo+KbpIVzaCM5rmdlf06sLnkB/u3uJm8zdVSlnVDB
McoFdBShciGiexzgWTo3J14lN3+anOHKWRvthGy8eCQF592YpKwv8fpITBky
OcR2CzQdCvZoXxJG7XZJuKAPFt0aMjc40CS3+CXEdYzfwl4V9kL0v0/V6CMt
rxZyUExstJdfkOisbgowTe8kHXGByEoSVkgo3MxDQZEtSBwU5QoDZxjhWK+y
Woc18saqUFFXNta2PYUi21JLhkM+04meuJGfPepdmYaYY+3kZlx/6Oxwrp0/
uMiVUStD1cNIRr57Y1MCpFbtYLtXuQYH2/3qtn7zEDF7v9vRcqHCAHnliTXO
4ZMbIP8enpFEqTL+kU4pQTgmjkzFo7OuNAO6qTeOXggrHfUU18pRLKHx8YWA
4ov9zg4XjYnMjSEyUC20hMtxBVl7s9ZYcG+6kVYw51tnYf1sOL3lpngGqQT8
OnV9pxIu2rilfTvmhCECQQ8Jkp0JdqApziwYF4mB4HaM33IRnXmOy6k2kqOZ
8HIehtn0UmnUBWpprplXqPBao8K6b4ii13z/AMGnnS3niv8Mze/Nxenr69NX
p+en15c/Ghiug/SrIWromYGXFm1LSp9vcZ1ko5WYRbiwSbFAoKhQmzMGJGcE
1K0gsxGwhkj8GtfQ3Kfraujg+caFtJEGqRIfJcxWD5Uz+dY2FElyeCL209qa
MxDxaJPAKn3e3AcU5spEJRKQv+U5tQfNNn1YPlKLvLDukCThenAALw5CSaeb
rV2I2iTSek8krGs+1oyR3GiSnAu6Wd/RVlq31wSZKF2811zjrFW+yDdR+6KL
PAjjfoUsG4EmfRFsiHK2krtBAu5qM5JDU2akwosmfJbmLkXZE8+RkiTYADPz
t4iU/9kCtZ4X9Z0jyMi10uR1V23VTEcKmkZhQdMQ0Bqlic9gE1lUG5mFu+Jx
prNeuChgcjBWs416o2bZdKltnH70QOHTlhQUz+5Fh6Y3Xa2nwBVPY7/iqczf
eRLEDBa5GqdxIDI3SthqNMzV8dn1ddy9WnGu5zH3aWty9uSk42N9vO7p2beq
6i1yDIJbGtxmXajGeV0n/reeCptGoR7NqqUk25lR1C7MVu5FlnEzrTw/hEgS
f/AGIREhr2QfIMJS7NE8sYirEy3ryt+IZjKZSU7hzR/uQi2QJDcrd1sCC41W
zQZyzklJBaXbreJ7re0W5IWTAbSMGNZd0aqtz5rrx3mZV3zm+QTy6Dg2lyH3
oxd8DnMgWU+qXDn7xZzwHdzN4rJyll3GxQK12MkqIVr2/jD4yvU4jxvq12gt
ShpBTlx+wH/LMx5Ms3iGDdV8Hs0evPdarnYTs4apfdNOOknSbOOMvrhPTKUg
/950TfpgfCNJUpOcNh+SthxylHvQukghAwnCk8oq3jGEQl0ksD4GzOvUfm5C
Rm94csfLAZAJp6qO3CHXPvJ4Sc2HfkajNeowX3cbUXE7EXuMGMFxry72z8Tt
4B7OO3TZRreoYczQMfvpmGwYgDPUVnvzTogfHh9riTTe0ce4aJ5R1paTYfvz
nonVBI6OoOhp1X+bh2a0g57JoNGcgB2z9V07m1GZxa3aN6g55ts7lvRc2tk3
Lez0jemK2WbFt4Zc7wLdpJKm4d+FJ6dOT9OUbR1pFkwNj5LaYCThJixP/Z0m
nW21FXOSIHFt+F7740eSGChFAjE+VmvDDpHIhB2itbCPpf4GzVPPuPbLlLx0
055U6ZJizJwI2ou3XrbU55rY2NFeSdeHy+ZxGSRTAI9rbaMwntlKqP3S5RIN
vLzzOec1UD/eLYBBtQhXdyKsfEcYCsWst1zztHEjeG8z0VUo0Lg6kkZyaC4F
f6BQuUANd6GkVB8q4rwOswsvzRw1Nat12ZOgojkhlyFRnKOMawmTIdH/rUFd
gjVHawXdMBacKMqR1fHqaw9BHq7ssR36aOBEPNJbQJCXpvnfaHqjEDwSaSRb
PBiQq5OpkSDjtloGTFC0+3I9KvPJMH5Z1BZe8UFoEFsPhsuJgJr3/J1FnfAj
m+pGoLWyAPs6G5lwW8gt/Nde9kJjLrdUHIniZs0RplLAfMPPFBdx1URsmZFY
75LtOoWnmmMnsxlC74O12VEcU8VW/0CiDSF1E1JZZ7nUlDDj5kAprli/5Gwd
MSNg1ZGt0pzwYTLYmwOg8RUPSvDQx+JdWHsnzl+XlZmzTMD2Z/MweqH38R5X
pMGCNRPStvi4G8mwKWv/WnoGBQw36jeKqLc1HKMu7jfVLHdWNATdavhAULmR
BKlUdgyz1JtX5XL1bdJDF1NoNHk1Llbgw7b7aaFu+8MdZRz76oW7Wl89nD6u
8iTqM3HYKeMTn07qoLTqtYuqoT25XMIssVVH8KrLK4qfz1OYuiquFmsVqiAU
JGqEsRCTl1yaqmyLgrcoHhkGclUFR6ZxOCV6Zh3rW2Ksuzx7L7mZtnlTqyry
8iIawmOepRKNa1MiWrIgfjUEkqylSxcDg5Qa2sPHZoL8QOQSluQvagDRl/uD
+PjFJdzcdTwYIAPJj893UNsP4DN2iF5s0YqJDdxBAlUggf3zDeqVfwDIeRMG
5fhaRhCAjRGfvo3PTy6pjy8KB+ya8MEdIcmGucKLPzo6SySLAlF0Jv/HBCHZ
zo/OkKGFkKB+PNhnan0uVjCMFPx1Iw4pPK+a4UitHR9QMxJ17yIBbbdr28eD
YYQPBBGiy/P8xdkJUQ6k9gzShmAsreEpfZ9XYv+SgGrMuUHqRtjuZnCtaRPd
Im7Lo25bgBbpIIhuNx1tMlG1Edrls5SfPeZtbhul/IDMkYt8TjUvaisO1gfi
gQE38fV9kUi8zMPRliaUSANEKkUJsb35RBy8EjixmFSedclEDg2lBBnfdy0J
rRKm9EsFKE7nE18FPIw7jAwYG/MV1sONewH5K9zKC78oGk/ShNBosr+3/yTZ
2+9Enzighru7MPdWhV0Bi9Pb1RIG4OHurloC+iQNd7nJXU4OtNOTPgHdH35L
EUhRygsA+cN48PTp/t6Tg8HhHn8IuG8/fKofAvxT04eHe9mzg729JNv/ZpQc
DCYHSfp08CQ5OHjy5PDwgL7ZG0jT9zL/0WC8P3mcHSS3h+mT5Omzb/aS0XiS
Jbd7g/3HB4dP8ElHu1W9gt66zQho3qCmE2L1MVV5BvoGosBk8KYgDKZ8lya0
KsPFwehv0x/vzm9/+CF9lfxz+uH78m8v0jc31x+q8vjgrNr7flC9GJ3cH0+n
0qItI+M18uo43Uv3f7n5UNwczvfePnt5/fz56+evj1/9/fm76dNkmvy4zPLv
/jo/fHJg19KEnwVeSb6zXfE/QmF6Pn969nLwppjxTNgG7tZAxX1q4etZo7HI
D3GFmG13RRK08cSTNp548rU8sf878IQNz5M4uoAhvowvfzaLJekSuFINUrGR
VNLv95M9zizZ5MJGfoc+uh93G4OTjCpfpO0PWzMcGTGZBLAjTSHcqvhjwAlb
9ralPbpUx3s/Fi9KXQypSXxcTBpJUCaDEdU4ICwHQQ6gzX17mBtpYDSmvvKY
MiQAWGLSk9qZsvU9JHchUeI3Cqt0MNofPyZWwHLirz33l/4JhZWw5e1hkj4Z
PU2ICwcJ8eVt4vHlYJMxtyUg/d8usniR98N0TMCL/8ZChwv2RWsMhScpV7jA
oWWZ9/dalvnZ3tcu8/7vsMzN3LFQAH0Rr/0ckP4xoWy3LYPM1d9A+g06fhH1
We9qo3ub3H/25Gvp/vh3oPtmPt5XU36/QfmDZj7vb6C3R7nPUJql7K5K2WQ+
LZOD/RaSPx60kPybwdeS/OB3IHl7cuNXk/1x5+etAutyPfjx9k3xw/7fl8eH
5/989vLdd/96/eHx5NU375+nB9XbX06f5v9R791f/K9xKLAO425r2rQ9Pb92
Obcvz2fW9XPY6bBlQQ8HX72gh7/DgjZyUL96JQ90JeG3GsYfxS0Q1LqmhiK5
xnb7voEuufvPNDGlrZNBh99B7sGnrdjMSy7xqhwAPQ3ZsqN5z7j4Z4z6bQ2D
XK/pHDHPsakNJn7zg2uB+V8A+ZZM8QdSU205RhfPnGv48aEN2DOpqtaV9z5P
o4cqiPMNe60o9Qvznx1W/UwStD74JZnQ+uiXpkPr49tzon9WXUry2dXV20wH
zysJUUWhvaxcG6eR74eR6vomK50xNuoLfdnmYeeeuJbRtmQCG0ucl/30mezq
yF6gxEBfbKvKL3Bjav6ZScMXt0xoXoq0AcN7U7ngzdMqHg9dls1pmLXy1yLf
6kF0ugGb5hHZLVGFLfk1ugu4NL1cc9PIsmnXnSSTlZM9mQv8i65/AksEV183
eTQOODHqSlFm86crq+NZnnfw8SynHUBMsN7ocLfR4Qb7BomeO95pg29hpll+
mZlmlC7eNXCCNdu1nynBG587UfbblJ5nodJzO8iIy8cszQ++BCLIliBFfPR0
/CyhHbCf0J7YS7w9sf8AKgPFgvNEDgd/GPsPgfLGs4+3QYkI54R3RnjXCKrH
+d5dMRzkI7Kj30sNZmYyMZeWacK69mG+4vbk6Efx0fjdorjHkomrdKt3RQy9
HOL4rlI/NzK+sBkxmmlZrJYmWSMvvXSsdMY3FmPD2XB5G0qdL4xdQPL+NitS
RTZro7jdTEizkdKLifvyoizoWc258JLF4s8ki22UYYxMGca80gSy6P8HbtpI
1/T7AAA=
-->
</rfc>
Reference in New Issue View Git Blame Copy Permalink