c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ddc1e3c6c0ec1cdeff25c4c5448939dcf3234417
ietf-wimse-ect/draft-nennemann-wimse-execution-context-00.xml
Christian Nennemann ddc1e3c6c0 Split policy/compensation into companion spec, slim down base ECT 
Move all policy evaluation (pol, pol_decision, pol_enforcer) and
compensation claims to I-D.nennemann-wimse-ect-policy-compensation.
Base spec now focuses on execution ordering, DAG structure, and
audit trail. All examples, diagrams, and prose updated accordingly.

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

2864 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-policy-compensation"/>. 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. Multiple regulatory
frameworks — including <xref target="EU-AI-ACT"/>, <xref target="FDA-21CFR11"/>, <xref target="MIFID-II"/>,
and <xref target="DORA"/> — require structured, auditable records of automated
decision-making and execution (see <xref target="_table-regulatory"/> for a
detailed mapping).</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-policy-compensation"/></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-policy-compensation"/>. 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-policy-compensation"/>.</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="use-cases"><name>Use Cases</name>
<t>This section describes representative use cases demonstrating how
ECTs provide execution records in regulated environments. These
examples demonstrate ECT mechanics; production deployments would
include additional domain-specific requirements beyond the scope
of this specification.</t>
<t>Note: task identifiers in this section are abbreviated for
readability. In production, all "jti" values are required to be
UUIDs per <xref target="exec-claims"/>.</t>
<section anchor="medical-device-sdlc-workflow"><name>Medical Device SDLC Workflow</name>
<t>In a medical device software development lifecycle (SDLC),
AI agents assist across multiple phases from requirements
analysis through release approval. Regulatory frameworks
including <xref target="FDA-21CFR11"/> Section 11.10(e) and <xref target="EU-MDR"/> require
audit trails documenting the complete development process for
software used in medical devices.</t>
<figure title="Medical Device SDLC Workflow" anchor="fig-medtech-sdlc"><artwork><![CDATA[
Agent A (Spec Reviewer):
jti: task-001 par: []
exec_act: review_requirements_spec
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 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 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 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-policy-compensation"/>. The core
ECT mechanism supports compensation through the "par" claim,
which links a remediation ECT to the original task.</t>
</section>
<section anchor="autonomous-logistics-coordination"><name>Autonomous Logistics Coordination</name>
<t>In a logistics workflow, multiple compliance checks complete
before shipment commitment. The DAG structure records that all
required checks were completed:</t>
<figure title="Logistics Workflow with Parallel Tasks" anchor="fig-logistics"><artwork><![CDATA[
Agent A (Route Planning):
jti: task-001 par: []
exec_act: plan_route
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 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-policy-compensation"/>.</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-policy-compensation" target="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect-policy-compensation/">
<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 1395?>
<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:
H4sIAAAAAAAAA82963rTWLYo+l9PMbf50XYvy4lDApTp7rVDCEV6EUiTUHTt
rvqyZFuxVdiWW5IT3BTrOw9xHmA/y36U8yRnXOdFkgPUqh+brwoSW5qXMccc
90scx1GVVYt0ZDqnH9PJpsrylTnJV1X6sTJX+Yd0VZqbvDDPs7IqsvGmSqfm
eJauqmxi3ufFh5tFfld2omQ8LtJbGOT92fnlqWkM1YkmSZXO8mI7MmU1jab5
ZJUsYdZpkdxU8SpdrdJlslrFd9myTONU348n/H68vx+Vm/EyK0v4tNqu4dWz
06sX0WqzHKfFKJrC8KMIVvAwSoo0gZVcwhBFVm070R2sc1bkm7WurxN9SLfw
6XQUGRMbO5uR2ehTfGuRJ1OTTXG71ZY+TWTvd7p3/nQzzSpTFUm2oN8n+XK9
yJLVJKVfi3S2WSQIunJbVumyjKJkU83zguaH/4252SwWDJGTeQGwhpfNa4UK
PZEXs2SV/SvBhcLmV9N0na5waeZtWqZJMZmnBT0Ir2SLkcnS6uZ/WsAOpmkU
rfJiCe/fpjjv2xcnj4+GR+7Hx+7H79yPT+TH744eHeiPw+E+/ngWPx/gLHJo
uISWj8uDMl4XeZVP8sUoirLVTW0VD4+OdOQnj757qJMcHgx1tFWmU2QxHUCs
Z2KfqCPQpIrX+SKbbGM8C8BihhsBSBH+gh4wp7fJYkNfm2Q1BYx1zwMiV/Az
/MS3YNcV6fC4STFLq5GZV9W6HO3tAU4mgBOTD2lBABnAEe4B5u/tQPr2Ne/R
2ITf5iZZlCn97vAH/8RfxJ/Li7MXL07D/dMNSc1FkU83E9rVmYDVvChgLMRx
3vZtWmzzVWq6PEyvfb/lOru5SQdZjpss9xDjy0o+jZNxvqn2chjpNkvv2jZ1
+i4+PouPT67CVb7ly4PL656+65mD/YPDveGjJ9+Z/MZU89Scbop8ncJ+L5IC
Lt0SrwQepHx9km9Wk2xhFsk2W83MNL9bmXlSLPNVVsKNLDaLtDR49kWV3WST
LFmYDM52scgA0yaw52P3xZn/xfGk2gGIdFPEi/TjIMWVJfDPXrrI9oAK7NnF
e/vHz+L9R/HwYevJAtKMdu5RN1cHxbsVwAuGePH8OD4Ynrx4OxyGUL3Cf83B
sA9DTFN8/0U6TQvYo4N32cfpKgPvmtMFoGcBMJvAAxMgneVT/7PLbLZKKsCm
HVfh7u5ukE5uisEsv90DrCtgA3u0Flje3mSerKu0iM/2gMbrL8d7a5g8Hg6/
Cv8JSu8GlwPzIs+nBJvnxWZmjqfLbIW8i3YEj5+fvTh7Hp+dheB4nhWwF6BJ
cBrDw71HR3un774RvwCFlknxIa1KwB9zk62A/DMywewbfKs03fMMZjdnZ9+E
ONOs2JNlBWgzBLQ5iodHvz/aPH/z9viLt/Bg7+Do6BD3Pc1mWQVbhUEYzvAz
oEK2yOiiIAnBaRxMSgA2fNjFeX7LHeKpwzt0EA/hv8PfHxhAl86fv/0SOIaP
9x4fHhEWpNNsApucprfZJMVDf/72N2ySBwwP/HG8j2f+++/xzcXp66vTV6fn
p1dvfwy3+gY40VW6SJdpVWzN5TqdIDWkvbdvCkZGMskvWG5QwovlXg5ffB1D
o+2cLPLN1LwmaYEYMzBfoOEvYDdTvdBW3CgnWVWRFJJVgF9AjAJpJMcZYiAE
wFeJ28UV8W59aNf3MaAvSx3waBTHIO2NkZ5Mqii6mmclcJQJXW84cMBwOPCd
gnT39OSq7PXhREDmFMEiqnI6kvcqbloeDFTkfLOoMnNJQqM5Xd1mQG2FkpAg
24v87dJFm3qCekNYxTGtMBql3oADwHNYnAFJ7RaEK1MCQU+nfYO0iwYHTsl0
n3AoKT9ETmyGj9OC8MwJvvAmTGKSSZGXJa8EAMqAjOCx5WYlWARTP9syQKZ4
uqxCNOARCRDvsmreFNnNZJGAFIUb/Ovlm9fmfTpmqJvuX99f9SIWOvsAajix
0kdik66SMcoADSndwNGALL2q4P/IA4Qn7cMz86Qy5Wa9zoFTetsHQcdOMYgI
tpsS4AEHhKwGh5lsJyDtmVmRrOdAC4+/7zlw49xFugYqiphF8FaBf5LBYhHY
KKbAywBlgskOuFnke38GcNiUCGJEuBKoAx0zfrAEIWDBJ1hs11VOa4K1rYts
meHtKweRiMtpKC77oqrDalgg7IEvBC40+vTpG8T0z58BJ47NKr2LXl5dXZh5
miCC3WTpYtqP7PWK5Xr1Dd5CmYuYDV5iPBDcGoE+WeSrWQmIDViL0rFFMx7a
oj+uOjFwn+YrouHjTbYgpBwv8skHOuxIDhukI7hlcPvhNFZ5ZcZwY6syXdwg
SsIUFVzBvo8ReEiRIBkowuZGZWyALdGVZTadLkBNe4ByphXK4fcH5jyHQ2CK
B0TnN1MLO6Xh86hpb58/6/2H25CPN2VltWBSWIma8ElXc1CoZ/MvoBthiD4S
gaIBtMN+f3HVA7DTbugoSlQNJilSCfnRqN4YNZbra5WwbCW98/zOLrk03prh
4JPJ3OTwQaFECQ54YUDcBAnNuHuhy43tjmATkf2UNhEzafGQE8/wZX6XwrXv
N00HhH+pw5VkOoWbXToyFiWTCTC1KhmD0FRtAS7/scrvcEl389yAWIX0C2kG
XDpW1exYTJajO6RDdwmyI5gJLgEgBH1GxBlW99aSN5/uw2OTIk1w94stgHG9
yLcIt3yVL/ONEG6mckC1YSyQ4RxZ920SeFuILxdAn2ADhI1rUDIcyjv8K83/
9//8vzj3YkPX69Mnq/19/tyHXz3FhT9QuR1+ixCrPn1C4RGOHgcq0n9ugKx6
3KrPVBopu8+4cGdLYn5TYAFIqeJl8gFXgGM6rtIt0xSmoPdjtwGYDulLAm8D
U1gALJfJeg2v9wa7hAGf1xvl9YTvAesmAAtapCU9NUvWZpxWdylgWgtG+ett
oo9M4V0APcunzAPdogQ8jEHwPKBBNhUGE6LQcSnzAyWmb4Wq7zTP4NHxLRPD
GrzTFEpWaTolZjsGtgmHgmeG0xP3K27TqVDnSIWTBGRsuLeg1y3xNb1NtC9B
BToDYosBQ4uSstwUSI7xwgJhhesM0y3NJUor+BKeYwGHDzChI0BIAcfA3Yre
auDIixyoSVoyl9Z7JTuLRHwAaXF470mE/IOPwdhTYKkYsAPgR0dCPBGoKtFo
eKlDdlj4LCtFes7+lU47NCoMSO/bZxhVYJFXIEqYv/dxEGAwiPlvNhXI1eZ/
DTpRdACTvM5RdsOLPPXgTFCgDQcApcVZ+Y/mXGSrDySxePdJxUCzRKrAWGIx
AE7iIc/bNh3CZcUXm64FcdQUaJDDfpwVzp64Kl7yQAjWWfjmkui23hTrvCQU
OFVxIB8jrskFgnlzkO3KDbAMJKnecCj5w/PAkQKdybFORmEehgTydLyZzZTE
oNkJ1okj8OnT2eurofDl4SrwSZ4X9aYETxxPuHkSKrbjoFUCElURp7d0G/s0
PX4O3J2ewtX58gjDppyAPFxkudyPywmoc/Tq8RoEmYkAaAe1QwWJOPoOFYg0
oJ5hYdx0P31CAZB/+/y5B++CEOzJwCTLISJZ0VdwDQEBb0+TWQzSaDYVqRFH
OBOhGOem++8IrqWdlg0B5sAwTLwy9yKPdBwweDaEnlw54RJfRZ035gfkJQIi
cIZZWpCAXtwkk9SnSiW+xw/E9gF++TdL2LCPMl0nqAssth5h/lpxm4XKm3yx
YKEDh84BPeEylRYB8EO4nVNkeyDsEkzpwK0MWJMRiYUozAnFceGI+rH5D2Iz
cq30YVgqUAaiwoBGBcqf0xw1MJOWyIqzcm4tGsGzJ8DxcR6QQRbZTYqKVeo/
gZj8NhWr5jxbI1156zD/xLlrolY1wGM3SJ4nwNRbVD7YIiDQsozGsl0SbXyZ
ZNeF9WiZcGNVSIRAwIgAWjjDBVJ+p2DU9QsAzbZVxwAMvEkLNMcR46782ws3
/aQ2DAnL3iuFs3cJKteFvwhZfAFUE1gLohgIgcRk4G00C/eNu6hMimboC1jR
lEsQQPGhaJxuc/iK1FPCO7JX1TV20Rq8bdqVllF9c3SWeM+AfkxJo2dVKqVZ
mBYG17MfEfHM2aLAB54hy8FvrUKJN6e8yVhUK1MPQMRVfFMKE+AJbYbG9M/b
0jPe1FYOHLZh/XuAJWRM2PJaiAc2hrGCQj4hMQUUNtSJywlcMHiQLLDyMjPf
mwTOGb1GW0+9IMBXJB+zmiGgrvAuAhoBZFcoacFOkBSKzYVXSk4UGCBqeZjG
FVMDT5/IMTPVRQLBj0VjEK2Q3LIqQifo6SvIlJCl3OJZEBFEQz8SwYx+Z0L2
AeB4RyJ/5/zd5VWnz/+a12/o57enf3t39vb0Of58+fL41Sv7QyRPXL588+7V
c/eTe/Pkzfn56evn/DJ8aoKPos758Y8dxu/Om4urszevj191GheOcJLlXeIA
IOiS/FhG7sTgnWcnF//nfw8PgZj/j7cvTg6Gw+9AyuBfngwfH8Ivd0BuebZ8
BQfJv5LwCDJqmpASSOJ3skYDPdxCwIpyTi4wuDAAzT/+AyHz88j8aTxZDw//
Ih/ghoMPFWbBhwSz5ieNlxmILR+1TGOhGXxeg3S43uMfg98V7t6Hf/p3EEpT
Ew+f/PtfojqzgwNYMsnflC3UEVgcCdGjaIQigacbq1JGUFX7k3JGYMk7bCx9
vooikZck4bBZE0/Ll4pRVqdpkVVOEEnMBhCdZFwrQQtLAuSH5aI+D8J8KfoT
ivgphijkJOMjaXqu5sdjMT9+78yPPBfbI50UZs2QBKxd4tgdIhTMhIKNyCbW
0EmCpyGuLOoUSd73iIi8kpol99MniU6wBp8pM8aGSZe0aWMV/5oywso7AoOl
tVckjOn5rnFvMd6nPtD95YZtCIt8RmCHy0TEvXFcAAmSwuh0rG7bZ5xC2bEh
aYf2cng5NBlHO0xrbFljALFcO3HSD/EcJLIWOf9QOhnMLppINMzI0pU/l2ej
YxOdP9GabF/wH2hPoD6JSQMf9Xb5zw0Ia/EivU0xFiYUCRGnSax7ThMHm8gB
COsqxLZktcPEtBVpB0E+T9AobzeZgdaERjg4ehhonbNTAc0EEgQBeMQ/gNxr
GBQeILIKmRavDKBVTGN0Q4NQzqPTZWNdUazwSYVhDqXadnytlHRRRL6+Jw8m
02kmm6lZbZC3MTCOfdOQr9F8etBUVki65fc8x1h01W5o2mX49TW4Lxh1CQZk
hGjHM9h5iGkqxXc7ZyZZcvyY+TtRWv/rHzs9f/Kmudif2UNBETDWBcl1MDvy
f1Ce80lGdhlGFTKd4ApEUKV38ElEW1kSLYAMl/E8X9f1mdssYUnmHkN1C9UP
TdV17uOLcD42iFUMCSlbPJAXIeJXeeRU2lA780zLTBp3GKLpkDmMg0k3QFVM
Us7glFv1OSsC8xVqm/aoAVziIQt1HW9fal+MzatsxbbWCQtvfGVg+DVSMOBU
ZV6ULVY7ZwkhXLdBWeYc3VYibrMDUeACe8d7xiRkJ4gXyTYtIrWxkjiqcKKv
rJSasO2DxqBvAIL/9V//BeuaZBncoCr6t/ib//xb9KtaB1/RbF29bj2z88+v
+BK+djUy4W3qcqDVaG+vmu7Rae597HX8dy74Hb4/998DfOk3bWnnsnd8cfub
IYcKiMDNiRLHwQH3zD/ITIVBCz8LFOA1DH9yEgHq5YFrdZlW/Rq4+Q+LVnsi
S5l5Us7R3tq22//LYfdmzRxoZHwJCBDQyjtMHXp2CQSGDl00kLdRc2FBiXVq
dEt5hq/OfwcKcK+iTyPz4CabxXTXSg5F+bONLdbbH3BJQoWy81ksk757Y6Me
FaGZvs+7L3SjNH99rwqtOMmtERy/kfGEcHiSaF+sUUwESxH+RZopPReXz+pY
cqhR55uM3YgPHgQs/yLPkDB/euDxfBDA8EPYLEiseBFsKED5ZaOn9d2iuu0Y
kbVxeVZcGPmvb6yX3HQ+ZIDvaGeEOwK/k6ZobS/MhDdjoJTCg92+YPZ86awP
f0A4XaHbG7YqC3UKf9nnICWYvQPSXEcsMaIyYhSF3R6KGk0oWgOzFfnOnntS
X2/gb5A2MdaIFwc+io8QmaImUYiA07ofHdaaOxazvICHl6YbgBI+90DZo2XA
uLDsiQxsX3RqaVqTannS98Ca6QoS8V4mH9jtSMZrkcf5kor3e0buADz9RiiF
Li9D73hRoJvPhk7UECoSx3eDFdK8b2VeOnd1QsEi+MdnGHTVcLSPkGr8CcU0
x4qO/4IRePVl8pMI5iKUYlBTnv4loCGeid5SElriS97qZZVMUCpB0sGQbBVB
RQJFX9staI9EJNcgPXxB3OurYCXYy/QABI0qcoBldL4iogCbYttvoA46NyGz
qohtbewiFdtighz+qb06GRKfhhExw4VHKsmSN5FuLGL4gGVTAGma3TpTXVfO
rCcjkJGBFX/r4rySEBOWjnoj84M+KsfYooYiAuI5BhoYiSnB1kELv5F9Atau
JcnhC2AfsCsT4dAN3d2wNglgFowR3FSf9x2bDgxOOSG9Wgw0ardAV6XyS1gZ
k610CuMer9kOipAVUE3ZZcSqIbFIdpHS+6Tw7TKDvGAS9umB5yJjcr/jBcTM
1tg3n1tFQuWS4GEbvY0vXLoXjkAvdIEx6CPAqMdL2FqyEJUcgAGv8FDBF0bN
iEhbrXkABQhmcUQM5Qp+evBLDkcofjTGwjrvoeFQZE2EEjrOZamo0KJfStB/
PwGgichiZtPlwdGjTh8/qbZr/MSlGf3bL3cVf4XMDb7iCIYkhgsRZ9N4ePCw
E30OKQqvSGiJXahs5vRjguoakhOYHg0JajsVY7pGS5cW6jVSD+hCXgm5yQOM
Wsfdt/GG3WzBmDOrNrK6RYOo34pgYk/6CYXc4eoIZmiMShabNDjEzgpUxw48
drldYmwv6mW6DlDQ08Fs0DcvcVgE58vLh08O8fej4UGvgQxkMiVpUkN3klJH
RZuOTScgrIGJ4yJdw/VRKxIcYw2ylo2nxOzqJ4yfTdnVv8nKOceTGGZPzBZR
ysPEsrJPxlR41oaQOGlqYl0P5D039IYnERHUEMMBmVqOviYUqeikN8yRYloY
Dh9KGPa8HtN5vRM1X4hNQRr1Is8/mM1ayCshxqQKhgaIOtyrGR3xZgIgTtiz
AxfzropZKvbu5TrZEnuU61iaca7xp+RYhsGQPQYCtIjWYZhVLXj3XqMuLe4B
sms3KC+zblJpmTewHSuqaHRttoowbm9LumEUZWz+847uskIT95vi3dszCsKB
f/UYt3p2bHZUL5YRPr5Lus2sQDBm9u/MaDZZC4VWS+uIGfynVfH/REwzZqb5
l70/Acjnf/nPvgqQuqhOuRmr+CxWMl9exZibVayCtLdE0vFQ0OargfstJ/MU
/Qt6z0GCuoQvXpVs+H739vXo3TtcsdNlUM4GnrcbmOiWBCkzIedfCOSrufPa
siU/W2cwcrfs2SQGgvCzdJLgStkri2ZZJC2EkORbk4hzAExalslMjbakrYpl
itWNDnxWUzU8dmNtXnzPxBVAAg07gTH6MoOPrKs2tSgQoTCBNi/SkTK0MCSY
dwCf/xH++yNpeGhNJK0OzmGRITr+8Y8j8uihLC8CHaEr06wVC08io5F5m4I4
U7PCGyVCvmxK72llLX2EZ6ahPVHsYJsQaEU/FS812gtx8y5BcSqrVNCR8Be4
4ON0nixu9MT4jgzsxtkXhTuXN1yKb9vm8cuK1S/4w+6lxTaQrnRqwdLkBoly
Yn7JSWI1Ito5p40Ek6Fc2AIs3YknvLrFs5kYZ0UBvL7eJcq0Y08OBJpGSKlS
r3dM1sxow4Y8sV2XpUQrWcm5072RxVKEOqG8h6MMA376p390LO1IWUAZwN7F
TohL6ciT7c9xSOOemHd++hkjt08xRkRZjwHyMPkgSMUxE0BG0NHsTM/kki6V
ptEGCJxAJDksEPgoKRx4XD0Xica+RXGl+NEGPhNfarixDMJqF19tHM+hMsY7
UxAmJhjgGL46L2/TTGfPabEd+KxjpSM8C41Kce/T3azIvlyovwmH4+zSZIwW
13GC7BrD0mg7epGQasAI41QvPjxEwdFVTYXTW8RrYEnDWOokCxcBGwSlGtl9
vVnCUU2ew9Y1qCNbAlCBbM0zEStpOUA96Z5OUYRUjq+e1MSGX07Fit83JW+1
A3PKslCwwdxQPBy6FNU8tfGtMD6fgIQp8gOhh3aczhJk+OnHupjX3AY8k4mp
jHbkcYcWGVgoO0mJeIRwTkf41/DILLMV+eOZaNB2UAIDiQpzYGQPa1Bw4chW
U0w0mGcYqaxiB7s/E1A+yDgwwYwRlGU/AJaIOx5dHIQdsFDRtgNhpbMa33RM
9zWA5VkK46U9YUgc8GktQYT4Y5/zCXTrp1Na3xCFX6FDO0UpOl1sow2oC3TU
6FiB1fxSZa2smkSe2SIfk19os8r+uUlrxjaftAlzIHjRsfqMFtZOUoIINCSV
YWUBEmcvM/aDU/AZY52IaKh9J0TsMbmBPaodWG/HqCO29JfAPmlviV0+Gzq8
aYomY6T4tWXaxzEqlGpeHH+v18oFmFmKgCTwLXFJJLZiCv0Fho4kdO9uDkqt
LHOOCvcCsGMKbACdTSVF9VtDiIfFRI0Qv9AWgncDVBm471npjCB8BhRchYQH
fYBToTiRY25P+WrZ15Nx421lKikWZZgQZ7UHLSHbShcwujoVGbxpgvj0AC9v
qCk4gVxkcD8lrFXEB5HojvUmjeEJkdCybe9oiddQdQ+8BAsxz9IBgDDliUU2
rkbAaqFpOSuhJnlwHVZGlOZ4Dci3627gViUnR8OVSSn01ihRXRj5amyAv3Aj
F3wnMktH6MQ1aFlIuNg4IdGT6XWZ3KTVFqPPJsliQpkH19McJVvCSCAd6YhB
q5QD2RNK0uzygZPFOhFT09GNdQwg3pxBCehCnyDgbvNsShrkYkGBu45J8jPd
Y0ziVgpVpDNUmQs6WwUi1vMgIMKFqcHvWOX+kgCJAa8XHu/1BBkS/72gELyW
vsNORZGUCb09T1op3j5rzSAjKYx0m+Wb0lpEUzW6Hq9MulyjpEJrg0vI6RoY
xmKKPJelERhWeX0NHnqi9iSSGSoeNhFKhyjlHj3HWP4zGwH56QEG98c2JPIL
10njS10IZWAx1uD5yIsIU9clbgHjuwEUKSCWaIucWkA5jFSoZX2NLs7d1zH0
0eOzVtDHKWk8RF4m9hzhaDr4XGwNRyOUih4dbopFDJDMQduL8YGOk1475TyJ
D44ejVaH47/Nfpyf37x/n7yK/zn7+EPxtxfJm5+urz6WxcnhWbn/w7B8MX5+
dzKbdSS1EN6ndXkGM3ct3cUHwKbFBFYiiKLeKhQgjl8fm9d0Y860dA1A9yWO
emxHfUvYX2ztJZZFd+wOHj457MjnR8MDWt+99jk7AmIfHJ3n/bJfASlfpJRW
U2IdDtQdvI3yxSHr2nTXbGiSA6EVA69COJHoliYflCxcvjzGKXV/58+P+vTZ
UHM46XWBKFENTNZHefc25eoPRXJn8kmF9TEaWAL3AdDxN6Mbo7XFt1qOs8ga
JAhZ6AQJGYiWiu4duZtBGSB89y3cv3Ey+QDX1E+ecJe08Uahb/yeadGsnGtg
fuSJ/WYJRGueYGxUQgFAHFuDOhjQ+nWHpM6nxMw9aYNCW1IbvhaQEJFznUQt
1EHyi3L8NSLORPodImJdXlJtrylCWJCg7CC/OGCiky/EhDdjFK6ETFvvfk6f
cqIVGcNilSgQCZlQstvsPtNi43ZEosRK+sVmhd7Dio2XOrWMTjifzVY563RL
lOuFe5K51fLP0mZzTlHDJjhJOEDfqweB7yCHLv0rj4S6KFONlIM1SfERppId
QJOB1dc3AOjlNWXLd3qWlbcspJZlMMWYTZIlHcIixuXEM0mpHlMNg9UUzod0
mdtUhO0y+1fa1+g48gLBMOQVsrybV5zfUPhaB00OenouGNzguPDm4f53j+Cs
KrTGq5SOo0UgtpIQAOsGLuwJ0F8Y8CiiiNSyhRDKwyy8B6I7DUnHHPEwmu1B
GmE5aMbyKW7AIX6FvItVKZBSLnOKoDXIgUrPpsmTubEkIh2GQwtCHwG5pRfL
ObIMxhqft3soA4dwk32UAE+S/X66RoLw0/Wy7IxYCkmLgedsN9ON6NXw+jJD
5MFUzCnsG0awaa8/XfMMMIgl1l5ulYZ+WnYOnBQTq5AZckGgFH9cYmBNUmyB
MeLoFJvz0zXuABbgD318tnf+SupVyNf0xh0H7uJ6xlt44bjdrnwWGHHpmtdi
fK0517Pqy1WXuN+pqpkgXYUiN5mBFjcx0t8CYPOUCJNzvBtZJfJ0ChsWD7cu
npIzNoup2DoD6494btnAExPD+ukaFga30Nbj8eBEsmWJ6Fhlt0iew0dRx1V9
g1xDpFHkq5tMQsnxd7i36JCDjeCxRMcucrmG6bjL9ReTF6OQ+X1rkiJ7p040
/Rc5ivha6/cw8w1VgcdKaGTdT4xRRqMdpk82kU5ASsaUPRbo0AJ3//OqptHo
SQVPDx8/Pth/dDg82qcPkSPbDx/Lh6itwLhHR/vpk8P9/Tg9+G4cHw6nh3Hy
ePgoPjx89Ojo6BC+2R/C0PjGnTit98fDycH0YZwe3hzFjx4/+S5OxpNpnN7s
Dw8eHh7hJx2ZV7S+EZ4vEh/Ar+sKLXJO20T7xsj842eew4pGoy8K462yOA2p
8p0/yKuTZD85+OX6Y359tNx/9+Tl1bNnr5+9Pnn192cfZo/jWfzjOs2+/+vy
6NGhbBcp8sh8IjMzbwVpGJOwg8MjtmE72uRIkyM7/AgREI++dPSAYzbhARrF
t4eDAxS/P9f8/5g1h2iqEQABSl4IpnlhAA+MH290ZfOHPz3w04cltLkekCVv
vUBuLrGNYa6LFpqo/LRr93q9fk7E1o3hcF+KWTSL5aiYwiZ04XL+GKIlZc46
hGWX3l9qiEgYCRL5xj6OKhE5locRb7uoBVh74VldJ0QxtyptjjOx0zXMkU9N
tzMAIWcyT9DDxgGUxxoKV0pFqWRnGJzGY5X3h8PVQ7X8Qks2fE0C4pi2RN+f
Xpm9ZJ0JJYjJP0LHsTccDKOXeVmNjHxHSxl4RCRqiY1Lt3+dj7+fZIPBAH23
g0FzucFDaNOAhxqhcDJNEAqn0Xpk2sDzZKyzIXF15wpHRFEAOZVFsI583+Am
MO9H9u2d8GWsWhAeS3ixHMy0T+bgCKMRt3yWigVfRDzR/GyEpDg100JN8Rjs
/aW1odG6iljIB2y6zaacHyF+XmurXouaa1OeWb3z9SnC+7MbzNFWGOGbN1RH
LAx5Q2y0q/Vsy2wrBowoLHzlLknmmZq0orojSytwLBYKhql6DqyRvfLKa0Qy
oIwTFh+zEZBa2rHmLv5DidWaS1wgK6cU6oaGux9sFjiZu4L6DUQB30iFWMnq
wCOEk7sva1H8aXQSZPDyjfWwqwBnNfKRWBzLdQRAJKuavKJ1ZkiK2JWxLw4X
gFAzl7sfUU05Agd6pfPi/kom1nCIEhMjVkQiqJpv/AQZzRdNC/WpIT0kb5E9
pSpSMyPC3IGYvAiumNQMdc8q1M/J95hmTCJXUeBVl8MOMUPdT4xS2QpvMYtq
3lm/RT+o3EMPV+x2JVMHxuq7ZHvfUCWrjsLIv9ruyipda9mdK0Z8rHAp3o4R
e3DJH8M2azUAik+rFpcqST8UyURpVl0N1Al9EMSNSBDrC4TodbmlDrDZTd0X
01N6II5gL/KcpRRaq/qNuCSOi43X1TNlQH8txbyKFZ0K2+AlGHH55rpZHaht
Wbm4croPkQsskHBLjSpkws7ODXLu+0TAmXhoAN5tV3DIM7dbbJUXHFYp+tD7
jEJsTrIWeodsPUdEfRonJXE4ImWzmt4LJ4zhvUqXIPWALvNGbq3gh+fGxstN
sPMnkkB9o+GMM3Jmi5m07ggX05lWjqIB1gusq0ZDkMI1AzXbOozZXVzli5Ty
3UzXy3ofmYf7RnTw3oAGuOLD6BMhJgrISx2Z/+QfBrAY8yeQj7LFlH7mNCOa
6xrnurZz/afGBdjJJV2O9Tu3PBohFBKfopfXxqjPNsCggYlSQTbQHw2aM7A+
sECaT4ls7CC9l1ioiEs0ok//JHyWHZ/ZMimyxdZ3VBopilKrGdSVs0oV/xsW
yF5fSqpw9LldQTteAfJSIXPxqREBx2Sfvr3oO3DsEI0VzK1IfnvhCg4gRmDZ
QY+KejxLDfMSKQ66BBmRxUCrqASz/qFkCiEL5wR7roVZ0SpY17nnHhxRYSmX
kI3+XI58ncCKL3zGacMVURR2zmbDNvYgjxeJYF7P/SXqxqEmibmhWuO2dlfh
l+ZBVzm5yG3NH1rqg4b8YL0vdfV/XaabaY6Kg62AUlpM8diFFdUkhcW9F91s
VuzStX5XkFW6ADYQRyfVNeFRv/UW9TC1ZW/PXAIvMsORx384RAq9sTdukIGG
m+HgAzhNmmAAfKI3EtgAWgMwiiIvuhRsDkwtZAmdXuTNeWAPzl0BMqEqvfNu
Idlt6OHrjMgyzk2+WsqA4GH+7K12llZd+0KPybXFYSTBoBprDedw5b5zF68f
EWnQu82/mV0DEr36C03PpKsV4F83XYr1sJVKyx0K4fZwZE7oAtkAEdNlllwk
aCeg2lLLrMJFYiUrZJ5/Rlmo2yNHWwmaBHwA6HtNFzE8UNhRgDoyggTdNf4s
k4/XVPkNnr620wJkZB7MaMGNMvPUj+DCpW1Yc5IVGClQhIU7xIbO0U1s30ZD
XxTZ18vNBGXOyF0Htzuu+n1NG7QHWPp7bNuabps2SPMTmsPG5JsBOhK6PTx2
+0jbls6Tj9lyA6qBAKl+Sv6GWvDcrXgU4hx+/+c/G7e7GnohiJtvZCtdvz6O
1zpbybO6t2Q6rd+e33LHAJ3De9ZAvebh1BFwB97tOCN5+uvxz4MYf+2Qiku+
+2aJUA1Uw0SN2l9Y4tyRgIhJ7bYKBgitt4jB5Www9gJVHtJ2Il8e+4NqiKXI
P6yWfeRaIuZN9wfVMH8Qi5c0HaJwEp1llVPRZBTBWDHWfNfWqTwVFSZ9gei7
XVOlOVcVlWhPOafwQuRcmjeQlVF6g/1I8FQD7xxc7CxZYH0WLUuB2m76sUI/
N/n3gMzlBcZYpTJiXdcSLi9iFtbrrN2zqH7PQgF1uA9/GBgip5OgT0/Cwgk+
Tl2tn6AqxJ6SY8WOyIotOz14Exy8MSjjX0m+trbYHxZvrJcUFG2sobKqHEWh
cB0vSQ65KefX/eB7yz89CIw9rAL7D1yovFFP2RX1p3QqcBVovWG+WxT46Enn
rSdkAveTLOndxjHYMaJGIsYIL9euL5RpK8WtYLsuXwjPCAR11ArQ5OUbdVn/
/KFWq45S7tTQ5zKlAJPrOVqimDUGoFTptgGQEnJWGtea5PBzqoJiymaSmgjl
dvxUEtobQ3vCeGI+rPK7lZQvZMCEWVpSWcZzRddKCh2RQxSWkt76OfJhMhgb
EWg5ziqiJ8hytj2CGtzhXBnTjwYHMN2jFhBqMvquKVHmJp0IgwKYdt8Cgk93
7mpHOJFKuKx0wGx/KGkoi6uwAb/Wuj8mPPpBqh57NTxt4U3xVk5S7saE9l9v
ZDRm9M2bk8sLRl6465JExVOMN1i31GzWKMtTYtLjGia0IxllUylHqSVdigbf
zMd/Uhvaq2Hgj9eSnAXvsw2mVrzI4WqQrf1dfQ8ugynIYtEkjT9wRoat6U88
3eX9cLQxDZIRLSJTUF8yEcqNch2LVyzcuMEbqR5JSQHbEpn5VAzkNmWdj4pN
jZJHo3kN1pbAkRBhZGOSLTYYSYSvv9f8ApuJIm4p33LZ9+xNDIRg74y8rmQi
wQDgO9wfBPClKCoJq9XgUMup9A5RbBWprMNh+DrZhcJ4/pVNGABiwpMTjJKS
TVndkEHb4CZylJXzfAH02WPAll0LbF1WQ08o5L3T3mzI/E0TB2x9hWVTuUr9
yjNCmQQvjMt5DJDBCj7ZEiODcrUm1YxJeBeHBxZQ7J8Qq7eEXXTJytH3fNd9
CcHHsBimyZLKSRn86WIRs4kbxwaWciFstK7/Ex2tF5HGd4BNnHGGH6c1UUQd
RxCGlW7Y2sIVAKzQQity6Z1+oRyHhjCNWJsa7Jw9QrsNmBoRFclFsA8s8tlM
Eu1rhc6NOSVxXZMgIy9CioOAUcalm2hRrO5BsnXwyVWq1jQ6WpVAMy9CFktW
LvKSLirLO42iFuz5AokIaWdQrsTlyvi+MJfDZWO22DpNRJIGONx/aLogUI+z
KVzuHqos+D5yaDgqToLBwuvWcY2yE33Mgo4MMoy671auqL6OYyu7NHOneTMS
dczrAro1zqfbeumPxMAWMIlJVCghJfCThG5FLiybDWb2SNpRhWTiK98LFzGU
bIivgFNcdQRimyLEWSL1s4lupERmQ4h1RrLdRjO6y9eArGgEuf4F62AqZQCd
dofySZxaIjauMazI01fVqsaCLYtEXZFWnaRqT6YH2vAaH8W5dQ1q7RFKw2+z
8YF/HoCkav7HnxtyaWB/4EvY7Zwx1qDi5uQFtp64AUFkQGuCyKh41uW1FUy7
7qFe6xSgL8yzMRmarOxhbVavJM3fCQSRiqYIPABAA55kWZBJP7BpAQ0L7p3A
gFdbzLsVCcK1EgadGlDtCfDYyGwEGeAAru23jaO7xxxhAuG37623HWp6MPaV
+hopwJYabpCMyyuFg4HPr+UzD0r9Jhzb5730ZGxrw5bx6ktwoiQsdUaVrSNK
QoVjQ8MN/HQNlBRnax6Yh1uArPDogOqMtCzJ5ScsQYSm6iHSKeyqviIJdFT5
FOkliKeSzkbmJzqoATyns8L37QfAQ1kJjif2RmxAQ2Q/MQQ6QkGvk7WOJ6di
Ai0zIvHiR6XMO4clUDcYqRtQn9OT1MINwofoL2PhhaLLuu3nrTKfjNIAaIKZ
+iCjkem/ywHzuSGJTbblRK5eDcjsswvWYGI2Cs/Sayv77VwXJ/DShOSuSWZ5
p2WOv9TnuM/CvnuaYCt1ONSEOTHGqhBt/rFLtvvZGmb52RAValZZXdR5xvm1
4aTsZaAf7eLErUMiYVcDIZyvntgyuaG9KIfAzh84hiwH+hoDa6vXqNW63wr4
mhDLAoCF+nEos2IIskSqZDcah+D57mveqKZ52ZmlWYzVrfacQZfzhwKLbiCn
eHWSdkgSHCQZlKI8s61TPj1oNEuR2CCJFPPDCkA8dzW7A0FdQu212nawQsrO
zssqnucT+CVZbMuMU/qclO9rWV7jnHo7NZQtM23oJEjI0dF+jY/Idsq1wUdh
TKejnStC08TJgHgaQAUi6k6Sg8i/bbPGSP0Wr5o5agcgUmGSFObclVFLnV0M
B84oDljrvfSD5kcMjhLjXCKKYuO11Puj2PgplTclhgl3jfH1fs3Ce5WpUPsV
mygPLpbOY2+DJYaRV9mkHJk37PVUEV9RxFlWOXiDUHyZT9kcRi4xyp4XU2YY
GSKLlFJcXO8Tvdx55YcrcGsMjQDCXnhkhU+w81Ne5SuJInNt9wyHycF62a2g
JeZAvgPxbkxViUD/aq5BMwWtNwAvJFoZkwUbVrhJh64CjX0UT0QWFrGFnrXm
jgZzifbS0nuNDX150J1kldsJKRWNpCDuRKXGLK8uCSXxSQdGgP55WnzAyNQi
ZRtdcxXj1IKe7ZdY3lkbYNYrZUQurk66GOZk3pdSpUUGii32ZMkXi00pFaaw
ppY5wfsBhAduUEw5OVpVthRLqwsr8LObblOXxQOPLDlWhOKq5/ldrSlMvTx2
0JrX1FrzXmEiUCSRu/7YrJHKiUzKp9LzQRbp6jndYVZJZDVQl8hRS5oL8yLr
7Xii9nY8USQpMLXEbdtKQ8FGbZXGY3TC0C6ZjiZT17bwbOXtoE8WGA9pOQ3K
EhTqoBJh0r76IvwiBJIvci7duJ9TN25z+fzVCYVuI15E0dmKENpv2G3K/Ka6
41QVyocjcuhM0l0cotePjs9szfQSY2Y0wtbFSs8JEchH4IM1Ug5jtBBvAVQn
YWoN6JEswgwq1zQz8htmBh0yrQ9gOBwM97spm/uoq+b587fwvSwgCnoXa0KZ
DUrSgFR/52o7wMOyoNFCJLVe5wOOfdeaml0svA1bwXherAoKdx496oQo8f7+
kCx3SYGZJvCVLbSAWhO8ce0D7RpRTjqxmGeme4LRPd+jHQWB1Bj6wA2tk4VT
WM5yDeR/gylEPPSJ6V6hAYp+awz7sDHsQTislBS/xtyu63IDursO/Nx0n2Ez
4R0jHzZGfhiOTJ2IrwVTrhP0glAL8pcbYHrY3Iww6Jx6nhX10Y8aox+GozPm
pTo+fQcff7JZddfjLbw8GAx+/oyZYzb9a5lWCYoUvUD+k2SbuJwuJir/3XcR
OyrSiazqBz8LAeNwZ8Ik6z8OxYOIqgZJdx3uyUFv2daXfryzfRWVBMAlfo3C
iwnSRiFMBYtU2J9qNirmk5s5gV4vL7ebK7BmEYX8LbYK1anIQfScmOrCoEUA
JhW7XOURUQ2atPyQrdcslhQpyRcSCPfAwN0XcZk4Kg721gWXIyyi52xVTUy9
7wy1n8cBBJq2Z0vpdyojSOwgA4E0qhQh2B6TGY5/JxtqtVXhJC1dEx1s3RKk
6ivDjvzaPRQ03fMqiPsiI+XZu61zfIalYwAYScexJKe7i7igRoOl9m8jS0O6
dSrReOYh3oX6lW88dWi67de38eQRKKPhVeyZfxCeuSTR6c9hNto0iYWq80Xz
MAGwB3EDz8yijIbPFI3HrNgeKgUWKxDtKX2Yyq04RLUXjOUxz8HMpRYr1zqE
WeZA6qQ7IcjKwDieJ+F1VznbufHz8ZZVWkoRPubrB1phDOPHixz7tfj3DZOL
F4qWfb4onozI9jYyznipuLQyLyY5qFaq+dAqhojaaUOvcaHaBxpbRHr5UdhO
MGyxSID8EhcfUezGBstYzpjXpVq7kll4ZJRWCt2kKi5IzcjrFnTg1GIZa+aZ
A5rfCgjHq1X60Zydgexv216qfJBofNUkTbzOtuz0u19csrNoc29zDLiPctTw
ALtPUDtuQDJ0XVFtm2TNU2Rc+zfCzr6zeUzCOohc0lsZnTb54tYZn1pI1T1T
H46YAE0Slb9DLGfcgrlzyhCdzStDDq7StldUr5VH2d28KHe+oNx27Ml1VSQc
HBBKnTf2gUoeUOpna8Zr+A9tPqF+R7jBfuThUpg3RtwJhvPuVhvD0S6jRnrH
2dHEdMR8kzO5HbulgSM3cE3Ye0tHZFf59eKeK2SFG70GBkpuw0Da0xV+u6Qn
/gfP9uNEPZv099+Q9AgoAUHmqgZKjncjgm1W8rXE4vzsxdnz+Ozs82fB3/a+
0V6/+2oediSzdLbRx5bSgMUjqNVxHYfku/T8zdvj2g3maxSs/QwLAE6k6oDc
6/vJwCu5/DmW059IjZIlYjFwFHhjWoBuTcvn2+8qAbRW6LmvFI9T0JlkuXab
v7EWD/aJjzwlvFwqSMuwc7PXdcXPPuxH7OPFrukliWtcoTHj+qYaNAAy1IwY
GhWdoP0fu06UAECsbT4pAShUgFR6wBGhWdgvHYGxSmrz7tsEULn1mJRBZNUZ
B1tl2ICkgIgXOSO8R1RsgcpRnXrkiD4XC4A8oMLXE481vHFd4Ms+vaASOOVv
IBZq1eciOqVHKy4pV/srCMUO+pMUs1yq93k64QUX+fsKffCgb9o1QxumoBUD
o+iS7gnRTTmyxgRfVAn5uK/1+MO+TBalhMg5BFTixgLXRVIAKqQLSsek7kxo
KhIVjQJv8VDwhiIkqYQnS2jc0DZfufOnaiLAlIXwShQ/ja7pngg2rzwwDtev
GeJQZgG8/QOmYLIkQ0ZBjR/SET2pT7oHUglpMt5zNDB8TWoNZUxpNlNZsxNq
Mz76hJ+fBM/7bWhhZbMNYJ/krFGE58OjowO1ZF3NMdNQe96FKU8Vf5dMKNeY
mwbyPHTTsEsfKqVIK6SpS8Zfy5s97n3KTWVrMZ+R9gmV1M+glqQWU6aofq8p
NBJ8pMKgtGWlyv1sOCio9WWFbXeoVYybmKouhW0crSc9H4dG3/pAOKH4jsTc
XNDQGpFYYf5TJaWZyeS/dQZ/0SYjZ7PnIsDVPN16dmwV+VVLQJ0/W7N2fc9k
+lDqJRtGZDlPFjgLLFayp1vagtPRX2JRoWMqKoRfvsJ4eg069woOYYTgwn73
2WtmH1Ql0sRJmU2DqrSWKRfJZm/tHVfyxu44avrwKosGPbMo1d61y0LfDMmp
igEYfVZDwgnVOmIUcm11BZdkBRr3i79JlrjGLSV+MjtFMWVsrlnlVU+7sEsF
t5391G2zs6/oqW78nuryGhUxlJ6A3BKwrOVNk82ChuIKm1p8Qkf4qn7ssmm+
99/Sjr3+cNTWjp3zSABxshkeBReniHVh7jT6u9yetd5sHd9u2ImCalGmq53F
shUX9KEadbYxlqei+7W5pPYWUjcs4Z5VYndmcZEpM7pKXuZ3mLONxdE44I8L
1bReABvDUIwkTwXj4iJXjUuQZ5LHfkMejb9Uf3kofkdWk7RNcL1iHzYk302i
aBb55cW0uNgxl+j2qtfTncGVekOQ7XIqATMIL7hmayyRTrUIgfmlqxlaYdpM
HurlCemIV5NMY0WlJlllq0ruqE5mam1tvH1xDhR7dPzCA9IMwLCFClnYhJPp
VxE5VaR6ThO1vEJkat31EUi3K+WgXQinrURp3oT9pS+Ab6DciilwpZAQtph4
5zkucu4ARbkF1j8jBNRmv5daSGQqblymxSTZYAsQgA9ceFch32X41JpeS6dW
fh3FkEUy4Sa+/wH3iQ3PJKLP0F5B2ueISnPTS1SBFXgra4tShlSaonBtQTj9
OUhsttAg9lGTFHHLVF2VYX8Sz0OblQ3XLPPTduesqTlnyaY34zQ29VsGUx2L
s43LnFCQQNB6kwO5yJ8HOoRWBifBjkrEM97abQhjtbG8fmiKxpfs6AypLXT8
5pCc04KBqc0yV22NvnY19IrEsu4sW2HDnlrF+bDbTOTN5Pk6wi5/as3x2hEk
q20kYtvuGVpSiYK0oS+kDJluSfUg0rV51FYaqccB8fcFV1NU1k3rKvwV3BM4
n1JNFvTMiFvbj6CPbAQ9LqUtvQnZm1eVgJLrFtm4SFhkhDFt7QbrOTCsSd7b
cestdyY4JlEWSZD0GBM8VNbIVT5r/S7KWqrGUewnfVR55LpXSDlfrxcCC8+a
+OrnD2npR8zZpEeBRW9WNsDSxlWWIxtm4wdfiiYeUUsk/wTQoMMatU7qZcVQ
1aTUVhOiqkmRX5eVbQtoitRQSgSVRhpvUz/7pmmhcGWdXPyD7E4oHsW+8H4i
n4sFJaTEwMEVGEg5SJwzgAqtcBmqsJOsCK3I1wAeN4uEUjW4ZnJOGpVdzS70
84KOONU1vyFQoUgbU0MJLncvsRLY8Y6yYGVYZc+tXSe054Q2FBatd7rhxuep
H4bRVkkEIy2cN+Y8m2K63YWFaiiM03omqSs9yI2erZI8kAYOWk6cnuPeT8zN
rl5dkj6B/wJzXPEkpeawUXRC2LkvkpRoDMHT7GhtF/qlZqL9yC7U6fGZa+jh
FyoxnEFyznk2jr+UUnfx8AD9PDaYasUq4Iqjh9CAuErhwmScTmhNioLOU0DJ
FSwPoMy1G7gMruI1qzKvLvcILl23aG3KKpQFGxehRvAhpprIoi+LlRaYxR62
YO3W2ke7MXLy4XL1RJvwt+IubZy9oxYp61KjPqy+YuV3abdDB31ZLetD3ZMR
DIUdZ1OQ/KlWbpyxGVNUT/J4q52AbiCQqFkaeSSFU//gxoidtbIZ/NowraYi
oXYRobuCgL4jId2WZo4XpN5baavA+t1cLhwDogsulAd8qTvPN1wsbppgAgzF
gIIgNy/J6Xnh9ug3ECRxlgSGl0kxJWectU+dk+MauMTLy3OKYEZvJQi4cJNJ
bsfnGGgSzEnGjaBXeRBtCEqOFDZ36bf4yjvsJlRuUHzhmAoFf78pCkhBQ+TW
4kT0DQXUa5uSFUEzky5dmmGNfjMMfqeH1klWqJrvy2hJYzhuzxdUzJM8NhFe
RSbyMoqLlJbKuSRw2AAc0jjVzI2BvnwCkUfPw8pm2FfAX5iribjY2hRrWF8n
aknZEx+HxCYSRF6QKq5NL49Vr2yYVYCKUIUdQPIgi8/ltdvmUbVocrHZ14om
UqkAL/lPMhidsu37ExYSoSY+TNZXLYsDNVfsPYlYFhxZYChvRcbbqtoTJk2e
8w2kayaCEV9BT8MQ8BO/TJuaSlssaWS+FE3aprC8b6rTI/POprfv0lXFtqn2
jx3mD9Nq/iDDKunEYcTuuZ5A1gQE8lt4sBTpQ+5borHpE1f0C0d/s6mwhsjY
9skcUbcGtraqfs7VdyWYWXQEa0SlarCkrIkWAnIGkwULwzWCrFgJmj+nyiVU
rZ15cxTdk2kp1H1TJdYMDUf4EV1tQGYjjqD5mC2pzZkZLjk6FAfEgDVgmQUW
MhJCSV2psWkx1iuB2xB5t+GLlWBMsxJMtLMSTKPSG1eH18ovUuoFvRNSbA7T
QGyll6ZMKGiMZSq3hgwUJOrT3WP+eXxxxswV5WjN0XWdGwjEtuNmyfv3qYEr
vuIVDSXD+I6TsVVU7hJu0wCkBBgaEhxscbASYkjZNdKZ2FVUpUYSghA2Bscc
o+01mWxtgKC4hVyQTpdUiD6n5/cYpvVaZ4PoxFVXDEsX0qWgMnt8DaVhsq2S
9stmOtM47Pv4/HY1mRf5ihpfUCNC3blYsF9fXfT8Tj5c2Cf5cg3I6J4akBGT
gpq9KIj85t6ZvNVynXjFnNm7o1y+HiAVbIISSmyrbgrJSSWLPwpXi1jkTS+1
Pnzu74r/KQPVOCOx0ShEKH+rpSYmKyEOlBGHT1JcoTN+1udFaoTFxfMVCwhL
wlddtRjW63jDvmuk1PVCuogo+KyUgIhaV1qregBqua19oD1gmBnXCq5jJXgs
fgTIRA5GLjmp9kg6qWWtUCVZRxZY96vRHYdQPJKMkzQoCY/V1nbjtTMdcHlY
Lg1LtR1doQmDbaHEbYYKmC1gxehCegzGSDQLXdq8+IpC/rmTWSENKgEYcFzM
6aWasRgMvrZzDBlWI68dDTBA6kjjXULvRRQ0/d4y+U10ZLhpDNuuQFrJKceg
1qyITFcPWDafNB3C2uftVMKabP9OPswVlXXm6qac90/izLGvX6F1qUtlZKQb
MFO5mhqlkiO+7aeprPlMuy7FsueViKA4QhuWQR6iIATya6ir52iEKZWae8Ul
eEvsA+OuX1g6znXt0vSOrlgGRF4O/SpG3WuYT+WaUtBxuvYSPZIFRVzxxAS0
hVgjoo9nVECLdKscVMgUm9B4bdD08QX2s8XlSxbbFt8AcUzlD4l5lXrIrgpG
9+LsrOeQ4DxbwZ36lyuAXiXx0vvs8042L0+xf82fQQvlK14NIrkl2t0xaGlO
rEotYtO2ftGN/pO9oD8ksX2s/pasZhs0cfhIhj0JgsYwVsTttl4cfJlatjPZ
xhqVEQqGK5ZpOcKXM4QWtjQQRUNSkCBnz3GLGw1sJQ4YyWFjAzm4uW1zEybb
eAtqwISY3A4bcRZItiMi3DFVxlQniyqhVg/3Y9R9TT2h12LRbOB77p6cVBF5
hVzFESdpc4S7xPBryGpC5uvlYBe2aPQHEGa6RKRBVmTVpY2LqK75m14bcQdP
L3FAevS92Cz0/rpuknyBu2EhLHF7y4UVzOxFDZOF9nJYbJ2cLEoLq/LOUsug
i9QXhtU+KMlT4YTd71YpUx5RSDi9kAU60tNAaY84kFrH05X6VEiToKl+qFro
LSyOpSZqk+TdKGkBUVt9q1vzT6Aa7NDhfBFdcBQerNo81TSoiOiZHPxeA5HS
3qesK+NCGiUQxOkTVOJ5wB0tW7gUJugk5gp710o7y0RDDjKXK+ayRQrvIdWR
XUQSkVfqhBupp9dNUHb07W3NaYiLA25Bq8B+ZtgEUArx82IuN+PK/zKs1RJF
b226sRZlKfExrMASRW/WgkxtX55irxmS+QLY4ANPxln11MsnTqhbt62ET44g
V9VO6i1GJqy42JdqPvSGDcQFwDXa3QgiUrxus+NN0Ovmsj2uDBeNlA+XsyNU
zQapaVKnnjCqmojFRE9FtmiOzjC72KgvrNbIeWQCrImiY3eIYnTlYBF0G1tU
wfeaDzpfmos+IVEZcPuuKW5KFONGVHhpTAMg05YTfgJF2NbM46u4lPNkBlOw
jt8te7JpY15g33fLUvxvznGWKgeyc4PPEKbikbpnIpYaOLVkibKXBAly2Ddc
BWlnebMpiOvW1nQyLzDSEnDxtUYq9w26Lv6njVweYG2mMyUEG3RE0JugQ755
jTeEXXsEYGJ88gCv75h40I6pQOEEIUA4BnEwevLs9OoF0RC/0RW1rApICXa8
ou9in3Z8/o0UJuhqpTTm5RalMzxx6rMFugZ5ocjN08XV9WRd2NLXtu3tRK1U
iJ9UStPoEAS3jwpa4pcwK8CHg29rpRx4V40r0QexxO//xQVjka6wgbcOORZc
fhfISaBYtuJWnKQUvU/HUtSWp/8Shf6Vn2M46i/PnSyInzGqnFhUgc/e2saw
v0a/juI4HtHf3o8j+AKo+hQetrHErmsjfIrIBv/Usr1xPBu9DF+zCrRHccHE
Te59EagsfCNF47l1jCcZ3/uqKiL4FIlGJOi/lE/0vfbO3jyC6i7w4BsWqb55
CET4X11TXWmWGy68IQH/SvHcVCtFPtRw7h1YSAHcF40+j/KuxlRQFzx+6LmG
5/3ADM2i1H+zDTKok3FsONcDhTPmCYgusCWm1+n0zx1yMHT4YoVN24xt2tb6
/JW6jWGhk3mGTmzU3Bt+YvwWAEkVkp1/OfpWB7MV+tCQZH2q1CGBIbxZU52+
jHuNsdiJGaXolVSHLVC7OxDpOxjplYkFmbjkv4uKTEVlsipwq2jQKyhr8BjM
sEiDROwO+WIxstCNB+QGngViMUtFLUy30qdrZVcfY5ebuGahsJFyEoNSY+ZR
kN7zBhmRORjsC1k6/ThheqJ41iHtltC0/RTJ4/7k0XcPAcJ+l8SdI9vzQnc2
4yoFodjJuscYYN9z5avwK++yKH6LDu6p3xonv+LSi0Ry1Tpn0w9IQIkwJH0m
NwtLo4yMninGkGCaFDpx5sniBik7fLUcdDDwAc+OfBJixio3aLXPJuR1Q9Uv
XVJ0TcLD2rq+JAwsthGWuwIy2KVcVl67WNlsMeEEvdGgQmJRX9kJPdjDwGDb
Ri5w/xtvO74dgRySVk7rR5zeUVAk1Spv1hIh3coLtXbxiKScagQTQZx664gX
1K4rGqNNdo6Q6d4kqxjG6Rn2foG6OCOeRF9kq56L8EW3cOQcqtSL7vj7gY3M
8nMhNPoZKyaBblpp5TLkkJ49RlNnOSJoj5tqIYdqdur2qj87XJIU++qO5EWs
vSVxpSAv5jNcy0geV8WR8MezLSDO9DstFx2D56dwuH3EbfqE1MxBh50yXoog
3Zyy/d7x/Wo+7ZPBHJcTe0mHMbt/QAxCC1tCQRYhIqkoL3VWtIo1po8upIgQ
37urj6uYb3YHBKLru4VeQiBHm+WG2zmxDyCJnYaFMdUYHa8Dl8aWoWBUF+Mk
eypotZ5KJz6AMi2l8U4QwEPCPawzZtxkoHN6h/Whu8XW0c2It54d3XRr+bKO
WrZRUgdoxhy4SA7rKZl6CajOjjm/K7sGTiUOqnATSpRMKINFPEaUCXSH7og0
WSrHK7lDpwbtlS7kzW7IOmwiLgzv1sTldwHXx5wqzptD5wrbo0ccLd1+JBR3
Z4+EMmrw0K0hqYGB6l32S33LGp9iPYBwFoD/XSJJ9TzyZsWMYmrNLX5G0FlV
J2ASXzWDdaBpE4gVRvQ0HcFYDAspDhbPCjVX0satWCfVN0T1tamsUZcv1q47
hcWwOZmDbK6gb0r8tx++5bU2Q6O/THI9qT52ehTs4i8ucuXOijDIUikj9cho
UoDEpoCSzbLYIgbb++qufp2J6N3vdqSsJyNAVnpkjYJouFPj30MeCZAqzI/A
pVjCUUOOkMdoZ2AazEbqQ5hq1JcMG2bF7JsyF5ygeHHQ6VHWRqSdPXihkumE
TWw5y9HbtThjvO1GUmmcusNivFatWBh3eCchFQS/TlXNhcJFje7qu2VONCSj
1hFjtCGIHTgUufYmeazpkHaNTymLZZlhE6lGdCIBnvlhGM7KFUGdpUSCPbyC
gldilum+AYheUZ8AEJ96O/iK/wzs783F6eur01en56dXb39UMVwW6VctFNuP
ipdW2uaYGr+ixTQdbzgVnTIL8hVaahna5LJjpy1Ct0SajRYjdIVV2C7mLtmW
IyeeNxrHRmIlBjyKCa3uyyd4ageKODoz5qyiyqaRo8nRRmGU8rz27Qmd1VGB
EYBPaU/tVut6jSBfUos8v0oIkvA8yIKOjJDjWRZbZyOaRpJwBcS6IramRUg0
q5eCsZp1GG1FdNvOR83k+F79jNNW+sLfRO2HzvQgNLwzWBoF+gZM2NDNYCl3
DQQ0VbMCnvisOcVCIq4K7XnId+IZxgSwbIA7868I59/sELWe5dXcAWTsRqnj
uquKqtvhwqNRWHg0FGhVaSIerKp9pTQLe7ojTye9cJVj+rd6Uxp1QfXY5Kit
oyy6p0Bpiw/Yq0EATNPbrgQ0U2VS41cm5f27Si3sHIhcLVITkMxGqVnJvb48
Obu6Mt3LDQVbndCctnZmnzkdsfXJti+8b1NWO+gYEm4ecJd1oZxkVRX733oq
bBKFejSplhztoquonJ2b+xfzuglWXu0XpiT+4lVCAkBe8j1AEyfXAKGNRZQe
tK5K/yLqZlL1DtPlD2+hZChxB+Rui2VPtWoqSkJO4YSldHtV/Kpg9grSwfEC
WlaMVTVYq7Y1wSiB0wt94Jb1HoA8OE60afEgekF8mApw9jnNzNkvliDfYTkv
LgnkqmyQXMyiFiU+cWlL2+cLwx2EnZua+jXespIGIic2KaC/+RlPTLPyDBUI
IX60uLc/NbdgY7OGJp+0g46jpNowY8AmZ03V8fubi9eV5BuOUphmcPkwasJJ
jtyvrIsxHAiCkFNZxdsgUajyGCtBBMjr1H4aglevONnznHC84UTUkTkGu0Ye
LkkpBz+kyBp1CK+7NVtvL6IqPSTB0ayuZqrWQMR+mXOcsg1uUc2YIWv246HI
MIDFpmy6pcch3j88kRxFutEn2BCepKwdnGH38165C7XcjlHRk+r8NhBEtYO+
urDFKdfTq+/GaVazzW/EvgHDEd7OidJTCWbftNAbqOmK0GZD3T2u9lC6SdhP
6vesY67TlzhBW++ZCFOtso/YYNjjHZaR/l6iPnbaiilKB7A2fK/98WOOzOEs
XVwfqbXhhBhJgDdEalafcAA87FN4XHvTIy/eq89pclw0mSKx+mZnU6QB1a7G
G+3VVLg/b5XykDQDlWpiY2aqXiVMvuhSjDQd73JJjkWYx+vWF4Rru8DvMPUU
ZCgsOr2jHVOjc3e/GWnGEKi1eISVHGnz7nsKirOo4Ro/cvpPbrIqDO95q3uU
2IjWY4+DyuMguYwA4lSdueIyhED6n6rUxbLmeCtCNxoLnouUw6fj1cEeIXgo
tH636COF6cxYunVgYIgEYOLQjYLt6MnmcM1gQS5RXSrtTdqCiQmgOO7L7bjI
piPzMq+seEWMUCW2PhoupyzU3NJ3VurEUAZNL0JYCwpQ7FUtFGUHuBn/2uPO
pX7tjpD/yNSD/glKAfKNvhDd78L5bZy/kZ6vXafwlEu8yWSGkL6tNjyB0rfI
6h9QtBFS3RhU1kXGQd26bsrCosrya3KXsxkBTx3dxfUNH8XD/SUKaNSKQQAe
+li8xrJzLsTlwqIyogl4/ck8jLPA+/gepYTggdUjQtqPqR6NlpD2L7kfmEHc
SKBmUm+TqKMu9iGVMFNSNFi6lYCJIHUaCCmnVodhovWWtlT+BvTQ1Qw1mqyc
5BvEw7Y+sqhu+8sdp1RHOHWlg23sPDp9XOo3JkhRDDrJJz6cBuygtOq1q2QI
d3K9RrPETh3BK+8kUvxymaCpq6RyDVahCsrv+bUhibbcwiuYG1a0VRS3UjyG
z3NLCUpGoXK1ODPpWE8BseZZesvBUXZ4TRaLvCi9GvFYpglXNral5Fuqx/+q
AOKwgbeu7iD6tOEOn+gG6YHIRQzwXzAAVrc9GJqTF2/RiV+Z4RBDAPxa507U
9gukqh2ib6y0orVXexjBEFBgn7+heuUzAOY3YSFEX8sIilnjik/fmfPnb2GO
ryq32tXyrD0GScNc4cUIHp/FXJEeq5SqA17jzezkx2cYIoFlGAdmeEDQ+lIt
1rAS66+N2o8hv6qXgGyd+BCG4QrmrtKqnXZr57i3TOs9RVpxyvPsxdlzgByC
2jNIK8CIWqOn9DYr2f7FBatxzzVQ18oiN4sX65g4LdbK9KDbVhTTUHCDnaiJ
RGWjnKaPUn74hne5bRXoe2gON9w5lX4SO+VgecAMVbgxV3d5zKkJtpptu1Qs
ZR2lWF8pUoKxHUrYwcuBE6tp6VmXtIrjiHMAqS81R5RxychfShTFgT9Ry96R
6ZBkQLIxtZoeNfr30VfYPRf9ojh4nMQgjcYH+weP4v2DTvSZihvSdBfaXyqc
CmVxeLtcowF4tLcnloABUMM9GnKPonPs9nhOFN3vf0skkLzgF1DIH5nh48cH
+48Oh0f79CGK+/bDx/IhCv8w9NHRfvrkcH8/Tg++G8eHw+lhnDwePooPDx89
Ojo6hG/2hzz0He9/PJwcTB+mh/HNUfIofvzku/14PJmm8c3+8ODh4dEj/KQj
04peAW/dpCBoXmNSFSz6GrfKz6C+gRU5efGakYFbnicxnMpodTj+2+zH+fnN
+/fJq/ifs48/FH97kby5vvpYFieHZ+X+D8Pyxfj53clsxiPaPA5vkFcnyX5y
8Mv1x/z6aLn/7snLq2fPXj97ffLq788+zB7Hs/jHdZp9/9fl0aNDe5ZaCjTw
SlJvdZH/MRSm7+OnZy9H3GQznoZtYHE7LHkFI3w7atQO+T6sYLPtHlOCNpx4
1IYTj74VJw5+B5ywpVK5pmmAEF+Hlz/rYV2RaRZbnyFVrBXtHwwG8T5V7m9i
Ya1+vjx6YLq1xXF3Cp+kHYxaO8OQxKTNNI6lHctOxR8XHJNlb1cLGdc25s6v
ixolrnavNpFZTWsNJbQbDIbDI7EcBv1UbB+R+7ERFgZrGgiOCUKiABZr+4d2
pGx9DyOZsRD9byRWyXB8MHkIqIDHiX/tu7/kT0isGC1vjuLk0fhxDFg4jAEv
b2IPL4dNxNzV4OH/dpJFh3wQtrZB8eK/cdDhgX3VGaPCExcbrKDWcswH+y3H
/GT/W4/54Hc45npvjpAAfRWu/RyA/iFI2e5aBl2AfgPoG3D8KuiT3tUG9za6
/+TRt8L94e8A92a/k2+G/EEN8of13ki/Ad4e5L4AaaKye0Jl4+WsiA8PWkD+
cNgC8u+G3wryw98B5O3NY74Z7A87P+8kWG+3wx9v3uTvD/6+Pjk6/+eTlx++
/9frjw+nr767fZYclu9+OX2c/Ue1f3fxvyYhwToy3dYWVJZ7futx7j6eL5zr
l2Sno5YDPRp+84Ee/Q4HWuvx880neSgniX6rkfnEboGg2AwMFHG72d33BnXJ
vX8msdaWiYcdegfrwH/eKZt5hf69jnEoPY3IsiN9pbDy5gQTKGsGuX7dOaLP
kakNTfz6gxuB8J8F8h1dt+5p/WPzoV08cybhx0c2YE8LxVpX3m2WRPeWm8US
161S6lf2l3Ky6heaTMmDX9NpSh792nZT8vjunlM/iy7F/cLE1Vtvt5WVHKKK
ma5psVWnke+H4fJW2vWLZGxM8Pm6y0POPXYt49jcaUktcV4nii90r4psBVMS
9Nm2KviCbkzpA6JtztgtE5qXIhlAcW/GFZY9reLhyHU8sOliPNZf82ynB9Hp
BmSax8hujips6XUgt4BqQ3GdyVrHg3bdibsHUYMdwgK/IfVPiBJBi+o6jpoA
E6MuV0XRP10+Hc/y3MOPFxncAECCbWPCvdqEDfQNmuv0PG6D36KZZv11Zppx
svpQkxOs2a6dpwRvfImjHLQpPU9CpedmmAKWT4iaH36NiMBXAhTx8ePJkxhu
wEEMd2I/9u7EwT1SGUIs4CfMHPxlHNwnlNeefbhLlIiQT3g8wqvjLR7nO9cK
OOgNQ45+rx0TIZPGXFqkCQtLhb1jdjekemCOJx9W+R0eGbtKd3pX2NBLIY4f
SlcolC4jrmZW5Ju1JmtkhZeOlSyoszBeOBsub0Ops5XaBbgHS7OTb2SzNvKb
ZkKajZReTd2XF0UOz0rOhZcsZr6QLNbIg440DzorJYEs+v8BQhYEOgP8AAA=
-->
</rfc>
Reference in New Issue View Git Blame Copy Permalink