c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ed8a3f17c2cf1a4b68e8ee373cc524437ec5cecf
ietf-wimse-ect/draft-nennemann-wimse-execution-context-00.xml
Christian Nennemann ed8a3f17c2 Reduce scope and tighten framing for submission readiness 
- Remove Operational Modes section (point-to-point, deferred,
  full ledger) to reduce surface area for a -00 submission
- Trim Ledger Interface to essential properties only, remove
  ledger entry JSON example
- Condense regulatory motivation in Introduction to 2 sentences
  with forward reference to compliance mapping table
- Reframe "cryptographic proof" to "signed, structured records"
  in abstract and introduction to accurately reflect self-assertion
- Make WPT co-presence RECOMMENDED rather than assumed, hedging
  against s2s-protocol evolution; ECT is independently verifiable
  via WIT public key
- Fix broken reference: draft-oauth-transaction-tokens-for-agents
  (not an ietf- WG draft)
- Add jti to all JSON examples (required claim was missing from 9
  of 10 examples)
- Clean up dangling cross-references to removed sections

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

3295 lines
141 KiB
XML
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.5) -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc ipr="trust200902" docName="draft-nennemann-wimse-execution-context-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
<front>
<title abbrev="WIMSE Execution Context">Execution Context Tokens for Distributed Agentic Workflows</title>
<author fullname="Christian Nennemann">
<organization>Independent Researcher</organization>
<address>
<email>ietf@nennemann.de</email>
</address>
</author>
<date year="2026" month="February" day="24"/>
<area>Security</area>
<workgroup>WIMSE</workgroup>
<keyword>execution context</keyword> <keyword>workload identity</keyword> <keyword>agentic workflows</keyword> <keyword>audit trail</keyword> <keyword>compliance</keyword> <keyword>regulated systems</keyword>
<abstract>
<?line 85?>
<t>This document defines Execution Context Tokens (ECTs), an extension
to the Workload Identity in Multi System Environments (WIMSE)
architecture for distributed agentic workflows in regulated
environments. ECTs provide signed, structured records of task
execution order, policy evaluation outcomes, and compliance state
across
agent-to-agent communication. By extending WIMSE Workload Identity
Tokens with execution context claims in JSON Web Token (JWT)
format, this specification enables regulated systems to maintain
structured audit trails that support compliance verification.
ECTs use a directed acyclic graph (DAG) structure to represent task
dependencies, record policy evaluation outcomes at each decision
point, and integrate with WIMSE Workload Identity Tokens (WIT)
using the same signing model and cryptographic primitives. A new
HTTP header field,
Execution-Context, is defined for transporting ECTs alongside
existing WIMSE headers. ECTs are a technical building block that
supports, but does not by itself constitute, compliance with
regulatory frameworks.</t>
</abstract>
</front>
<middle>
<?line 107?>
<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, what policy was applied, or whether compliance
requirements were evaluated at each decision point.</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, in what order, and what policy was evaluated.</t>
<t>As identified in <xref target="I-D.ni-wimse-ai-agent-identity"/>, call context
in agentic workflows needs to be visible and preserved. ECTs
provide a mechanism to address this requirement with cryptographic
assurances.</t>
</section>
<section anchor="problem-statement"><name>Problem Statement</name>
<t>Three core gaps exist in current approaches to regulated agentic
systems:</t>
<t><list style="numbers" type="1">
<t>WIMSE authenticates agents but does not record what they
actually did. A WIT proves "Agent A is authorized" but not
"Agent A executed Task X, under Policy Y, producing Output Z."</t>
<t>No standard mechanism exists to record policy evaluation
outcomes at each decision point in a multi-agent workflow.</t>
<t>No mechanism exists to cryptographically link compensation and
rollback decisions to original actions.</t>
</list></t>
<t>Existing observability tools such as distributed tracing
<xref target="OPENTELEMETRY"/> provide visibility for debugging and monitoring
but do not provide cryptographic assurances. Tracing data is not
cryptographically signed, not tamper-evident, and not designed for
regulatory audit scenarios.</t>
</section>
<section anchor="scope-and-applicability"><name>Scope and Applicability</name>
<t>This document defines:</t>
<t><list style="symbols">
<t>The Execution Context Token (ECT) format (<xref target="ect-format"/>)</t>
<t>DAG structure for task dependency ordering (<xref target="dag-validation"/>)</t>
<t>Policy checkpoint recording (<xref target="policy-claims"/>)</t>
<t>Integration with the WIMSE identity framework
(<xref target="wimse-integration"/>)</t>
<t>An HTTP header for ECT transport (<xref target="http-header"/>)</t>
<t>Audit ledger interface requirements (<xref target="ledger-interface"/>)</t>
</list></t>
<t>The following are out of scope and are handled by WIMSE:</t>
<t><list style="symbols">
<t>Workload authentication and identity provisioning</t>
<t>Key distribution and management</t>
<t>Trust domain establishment and management</t>
<t>Credential lifecycle management</t>
</list></t>
</section>
<section anchor="relationship-to-regulatory-compliance"><name>Relationship to Regulatory Compliance</name>
<t>ECTs are a technical mechanism that can support compliance programs
by providing structured, cryptographically signed execution
records. ECTs do not by themselves constitute compliance with any
regulatory framework referenced in this document.</t>
<t>Compliance with each referenced regulation requires organizational
controls, policies, procedures, validation, and governance measures
beyond the scope of this specification. The regulatory references
in this document are intended to motivate the design requirements,
not to claim that implementing ECTs satisfies these regulations.</t>
<t>ECTs provide evidence of claimed execution ordering and policy
evaluation. They do not independently verify that the claimed
execution actually occurred as described, that the policy
evaluation was correct, or that the agent faithfully performed the
stated action. The trustworthiness of ECT claims depends on the
trustworthiness of the signing agent and the integrity of the
broader deployment environment.</t>
</section>
</section>
<section anchor="conventions-and-definitions"><name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
<?line -18?>
<t>The following terms are used in this document:</t>
<dl>
<dt>Agent:</dt>
<dd>
<t>An autonomous workload, as defined by WIMSE
<xref target="I-D.ietf-wimse-arch"/>, that executes tasks within a workflow.</t>
</dd>
<dt>Task:</dt>
<dd>
<t>A discrete unit of agent work that consumes inputs and produces
outputs.</t>
</dd>
<dt>Directed Acyclic Graph (DAG):</dt>
<dd>
<t>A graph structure representing task dependency ordering where
edges are directed and no cycles exist.</t>
</dd>
<dt>Execution Context Token (ECT):</dt>
<dd>
<t>A JSON Web Token <xref target="RFC7519"/> defined by this specification that
records task execution details and policy evaluation outcomes.</t>
</dd>
<dt>Audit Ledger:</dt>
<dd>
<t>An append-only, immutable log of all ECTs within a workflow or
set of workflows, used for regulatory audit and compliance
verification.</t>
</dd>
<dt>Policy Checkpoint:</dt>
<dd>
<t>A point in a workflow where a policy evaluation outcome is
recorded within an ECT.</t>
</dd>
<dt>Workload Identity Token (WIT):</dt>
<dd>
<t>A WIMSE credential proving a workload's identity within a trust
domain.</t>
</dd>
<dt>Workload Proof Token (WPT):</dt>
<dd>
<t>A WIMSE proof-of-possession token used for request-level
authentication.</t>
</dd>
<dt>Trust Domain:</dt>
<dd>
<t>A WIMSE concept representing an organizational boundary with a
shared identity issuer, corresponding to a SPIFFE <xref target="SPIFFE"/>
trust domain.</t>
</dd>
<dt>Witness:</dt>
<dd>
<t>A third-party entity that observes and attests to the execution
of a task, providing additional accountability.</t>
</dd>
</dl>
</section>
<section anchor="wimse-integration"><name>WIMSE Architecture Integration</name>
<section anchor="wimse-foundation"><name>WIMSE Foundation</name>
<t>The WIMSE architecture <xref target="I-D.ietf-wimse-arch"/> defines:</t>
<t><list style="symbols">
<t>Workload Identity Tokens (WIT) that prove a workload's identity
within a trust domain ("I am Agent X in trust domain Y")</t>
<t>Workload Proof Tokens (WPT) that prove possession of the private
key associated with a WIT ("I control the key for Agent X")</t>
<t>Multi-hop authentication via the service-to-service protocol
<xref target="I-D.ietf-wimse-s2s-protocol"/></t>
</list></t>
<t>The following execution accountability needs are complementary to
the WIMSE scope and are not addressed by workload identity alone:</t>
<t><list style="symbols">
<t>Recording what agents actually do with their authenticated
identity</t>
<t>Recording policy evaluation outcomes at each hop</t>
<t>Maintaining structured execution records</t>
<t>Linking compensation or rollback actions to original tasks</t>
</list></t>
</section>
<section anchor="extension-model"><name>Extension Model</name>
<t>ECTs extend WIMSE by adding an execution accountability layer
between the identity layer and the application layer:</t>
<figure title="WIMSE Extension Architecture Layers" anchor="fig-layers"><artwork type="ascii-art"><![CDATA[
+--------------------------------------------------+
| WIMSE Layer (Identity) |
| WIT: "I am Agent X (spiffe://td/agent/x)" |
| WPT: "I prove I control the key for Agent X" |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| ECT Layer (Execution Accountability) [This Spec]|
| ECT: "Task executed, dependencies met, |
| policy evaluated, outcome recorded" |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| Ledger Layer (Immutable Record) |
| "All ECTs appended to audit ledger" |
+--------------------------------------------------+
]]></artwork></figure>
<t>This extension reuses the WIMSE signing model, extends JWT claims
using standard JWT extensibility <xref target="RFC7519"/>, and maintains WIMSE
concepts including trust domains and workload identifiers.</t>
</section>
<section anchor="integration-points"><name>Integration Points</name>
<t>An ECT integrates with the WIMSE identity framework through the
following mechanisms:</t>
<t><list style="symbols">
<t>The ECT JOSE header "kid" parameter <bcp14>MUST</bcp14> reference the public
key identifier from the agent's WIT.</t>
<t>The ECT "iss" claim <bcp14>MUST</bcp14> use the WIMSE workload identifier
format (a SPIFFE ID <xref target="SPIFFE"/>).</t>
<t>The ECT <bcp14>MUST</bcp14> be signed with the same private key 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, what policy was
evaluated, and what precedent tasks exist.</t>
<t>Ledger: Appends the verified ECT to the audit ledger.</t>
</list></t>
</section>
</section>
<section anchor="ect-format"><name>Execution Context Token Format</name>
<t>An Execution Context Token is a JSON Web Token (JWT) <xref target="RFC7519"/>
signed as a JSON Web Signature (JWS) <xref target="RFC7515"/> using the Compact
Serialization. JWS JSON Serialization <bcp14>MUST NOT</bcp14> be used for ECTs.</t>
<section anchor="jose-header"><name>JOSE Header</name>
<t>The ECT JOSE header <bcp14>MUST</bcp14> contain the following parameters:</t>
<figure title="ECT JOSE Header Example" anchor="fig-header"><sourcecode type="json"><![CDATA[
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
"kid": "agent-a-key-id-123"
}
]]></sourcecode></figure>
<dl>
<dt>alg:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. The digital signature algorithm used to sign the ECT.
<bcp14>MUST</bcp14> match the algorithm in the corresponding WIT.
Implementations <bcp14>MUST</bcp14> support ES256 <xref target="RFC7518"/>. The "alg"
value <bcp14>MUST NOT</bcp14> be "none". Symmetric algorithms (e.g., HS256,
HS384, HS512) <bcp14>MUST NOT</bcp14> be used, as ECTs require asymmetric
signatures for non-repudiation.</t>
</dd>
<dt>typ:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. <bcp14>MUST</bcp14> be set to "wimse-exec+jwt" to distinguish ECTs
from other JWT types, consistent with the WIMSE convention for
type parameter values.</t>
</dd>
<dt>kid:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. The key identifier referencing the public key from
the agent's WIT <xref target="RFC7517"/>. Used by verifiers to look up the
correct public key for signature verification.</t>
</dd>
</dl>
</section>
<section anchor="jwt-claims"><name>JWT Claims</name>
<t>The ECT payload contains both WIMSE-compatible standard JWT claims
and execution context claims defined by this specification.</t>
<section anchor="standard-jwt-claims"><name>Standard JWT Claims</name>
<t>The following standard JWT claims <xref target="RFC7519"/> <bcp14>MUST</bcp14> be present in
every ECT:</t>
<dl>
<dt>iss:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. StringOrURI. The issuer of the ECT, which <bcp14>MUST</bcp14> be
the workload's SPIFFE ID in the format
<spanx style="verb">spiffe://&lt;trust-domain&gt;/&lt;path&gt;</spanx>. This <bcp14>MUST</bcp14> match the "sub"
claim of the agent's WIT.</t>
</dd>
<dt>sub:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. StringOrURI. The subject of the ECT. When present,
<bcp14>MUST</bcp14> equal the "iss" claim. This claim is included for
compatibility with JWT libraries and frameworks that expect a
"sub" claim to be present.</t>
</dd>
<dt>aud:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. StringOrURI or array of StringOrURI. The intended
recipient(s) of the ECT. Because ECTs serve as both inter-agent
messages and audit records, the "aud" claim <bcp14>SHOULD</bcp14> contain the
identifiers of all entities that will verify the ECT. In
practice this means:
</t>
<t><list style="symbols">
<t><strong>Point-to-point delivery</strong>: when an ECT is sent from one
agent to a single next agent, "aud" contains that agent's
workload identity. The receiving agent verifies the ECT and
forwards it to the ledger on behalf of the issuer.</t>
<t><strong>Direct-to-ledger submission</strong>: when an ECT is submitted
directly to the audit ledger (e.g., after a join or at
workflow completion), "aud" contains the ledger's identity.</t>
<t><strong>Multi-audience</strong>: when an ECT must be verified by both the
next agent and the ledger independently, "aud" <bcp14>MUST</bcp14> be an
array containing both identifiers (e.g.,
["spiffe://example.com/agent/next",
"spiffe://example.com/system/ledger"]). Each verifier checks
that its own identity appears in the array.</t>
</list></t>
<t>In multi-parent (join) scenarios where a task depends on ECTs
from multiple parent agents, the joining agent creates a new ECT
with the parent task IDs in "par". The "aud" of this new ECT
is set according to the rules above based on where the ECT will
be delivered — it is independent of the "aud" values in the
parent ECTs.</t>
</dd>
<dt>iat:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. NumericDate. The time at which the ECT was issued.
The ECT records a completed action, so the "iat" value reflects
when the record was created, not when task execution began.</t>
</dd>
<dt>exp:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. NumericDate. The expiration time of the ECT.
Implementations <bcp14>SHOULD</bcp14> set this to 5 to 15 minutes after "iat"
to limit the replay window while allowing for reasonable clock
skew and processing time.</t>
</dd>
</dl>
<t>The standard JWT "nbf" (Not Before) claim is not used in ECTs
because ECTs record completed actions and are valid immediately
upon issuance.</t>
<dl>
<dt>jti:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. String. A globally unique identifier for both the
ECT and the task it records, in UUID format <xref target="RFC9562"/>. Since
each ECT represents exactly one task, "jti" serves as both the
token identifier (for replay detection) and the task identifier
(for DAG parent references in "par"). Receivers <bcp14>MUST</bcp14> reject
ECTs whose "jti" has already been seen within the expiration
window. When "wid" is present, uniqueness is scoped to the
workflow; when "wid" is absent, uniqueness <bcp14>MUST</bcp14> be enforced
globally across the ECT store.</t>
</dd>
</dl>
</section>
<section anchor="exec-claims"><name>Execution Context</name>
<t>The following claims are defined by this specification:</t>
<dl>
<dt>wid:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A workflow identifier that groups related
ECTs into a single workflow. When present, <bcp14>MUST</bcp14> be a UUID
<xref target="RFC9562"/>.</t>
</dd>
<dt>exec_act:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. String. The action or task type identifier describing
what the agent performed (e.g., "process_payment",
"validate_safety", "calculate_dosage"). Note: this claim is
intentionally named "exec_act" rather than "act" to avoid
collision with the "act" (Actor) claim registered by
<xref target="RFC8693"/>.</t>
</dd>
<dt>par:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. Array of strings. Parent task identifiers
representing DAG dependencies. Each element <bcp14>MUST</bcp14> be the "jti"
value of a previously verified ECT. An empty array indicates
a root task with no dependencies. A workflow <bcp14>MAY</bcp14> contain
multiple root tasks.</t>
</dd>
</dl>
</section>
<section anchor="policy-claims"><name>Policy Evaluation</name>
<t>The following claims record policy evaluation outcomes:</t>
<dl>
<dt>pol:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The identifier of the policy rule that was
evaluated for this task (e.g.,
"clinical_data_access_policy_v1"). <bcp14>MUST</bcp14> be present when
"pol_decision" is present.</t>
</dd>
<dt>pol_decision:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The result of the policy evaluation. When
present, <bcp14>MUST</bcp14> be one of the values registered in the ECT Policy
Decision Values registry (<xref target="pol-decision-registry"/>). <bcp14>MUST</bcp14> be
present when "pol" is present. Initial values are:
</t>
<t><list style="symbols">
<t>"approved": The policy evaluation succeeded and the task
was authorized to proceed.</t>
<t>"rejected": The policy evaluation failed. A "rejected" ECT
<bcp14>MUST</bcp14> still be recorded for accountability. An ECT with
"pol_decision" of "rejected" <bcp14>MAY</bcp14> appear as a parent in the
"par" array of a subsequent ECT, but only for compensation,
rollback, or remediation tasks. Agents <bcp14>MUST NOT</bcp14> proceed
with normal workflow execution based on a parent ECT whose
"pol_decision" is "rejected".</t>
<t>"pending_human_review": The policy evaluation requires human
judgment before proceeding. Agents <bcp14>MUST NOT</bcp14> proceed with
dependent tasks until a subsequent ECT from a human reviewer
records an "approved" decision referencing this task as a
parent.</t>
</list></t>
<t>When "pol" and "pol_decision" are absent, the ECT records task
execution without a policy checkpoint. Regulated deployments
<bcp14>SHOULD</bcp14> include policy claims on all ECTs to maintain complete
audit trails.</t>
</dd>
<dt>pol_enforcer:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. StringOrURI. The identity of the entity (system or
person) that evaluated the policy decision. When present,
<bcp14>SHOULD</bcp14> use SPIFFE ID format.</t>
</dd>
<dt>pol_timestamp:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. NumericDate. The time at which the policy decision
was made. When present, <bcp14>MUST</bcp14> be equal to or earlier than the
"iat" claim.</t>
</dd>
</dl>
<t>This specification intentionally defines only the recording of
policy evaluation outcomes. The mechanisms by which policies are
defined, distributed to agents, and evaluated are out of scope.
The "pol" claim is an opaque identifier referencing an external
policy; the semantics and enforcement of that policy are
determined by the deployment environment. Implementations may
use any policy engine or framework (e.g., OPA/Rego, Cedar, XACML,
or custom solutions) provided that the evaluation outcome is
faithfully recorded in the ECT claims defined above.</t>
</section>
<section anchor="data-integrity-claims"><name>Data Integrity</name>
<t>The following claims provide integrity verification for task
inputs and outputs without revealing the data itself:</t>
<dl>
<dt>inp_hash:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A cryptographic hash of the input data,
formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The
hash algorithm identifier <bcp14>MUST</bcp14> be a lowercase value from the
IANA Named Information Hash Algorithm Registry (e.g., "sha-256",
"sha-384", "sha-512"). Implementations <bcp14>MUST</bcp14> support "sha-256"
and <bcp14>SHOULD</bcp14> use "sha-256" unless a stronger algorithm is
required. Implementations <bcp14>MUST NOT</bcp14> accept hash algorithms
weaker than SHA-256 (e.g., MD5, SHA-1). The hash <bcp14>MUST</bcp14> be
computed over the raw octets of the input data.</t>
</dd>
<dt>out_hash:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A cryptographic hash of the output data,
using the same format and algorithm requirements as "inp_hash".</t>
</dd>
<dt>inp_classification:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The data sensitivity classification of the
input (e.g., "public", "confidential", "restricted").</t>
</dd>
</dl>
</section>
<section anchor="operational-claims"><name>Task Metadata</name>
<t>The following claims provide additional context about task
execution:</t>
<dl>
<dt>exec_time_ms:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Integer. The execution duration of the task in
milliseconds. <bcp14>MUST</bcp14> be a non-negative integer.</t>
</dd>
<dt>regulated_domain:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The regulatory domain applicable to this
task. Values <bcp14>MUST</bcp14> be registered in the ECT Regulated Domain
Values registry (<xref target="regulated-domain-registry"/>).</t>
</dd>
<dt>model_version:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The version identifier of the AI or ML model
used to perform the task, if applicable.</t>
</dd>
<dt>witnessed_by:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Array of StringOrURI. Identifiers of third-party
entities that the issuing agent claims observed or attested to
the execution of this task. When present, each element <bcp14>SHOULD</bcp14>
use SPIFFE ID format. Note that this claim is self-asserted by
the ECT issuer; witnesses listed here do not co-sign this ECT.
For stronger assurance, witnesses <bcp14>SHOULD</bcp14> submit independent
signed ECTs to the ledger attesting to their observation (see
<xref target="witness-attestation-model"/>). In regulated environments,
implementations <bcp14>SHOULD</bcp14> use witness attestation for critical
decision points to mitigate the risk of single-agent false
claims. See also <xref target="self-assertion-limitation"/> for the security
implications of self-asserted witness claims.</t>
</dd>
</dl>
</section>
<section anchor="compensation-claims"><name>Compensation and Rollback</name>
<dl>
<dt>compensation_required:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Boolean. Indicates whether this task is a
compensation or rollback action for a previous task.</t>
</dd>
<dt>compensation_reason:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A human-readable reason for the compensation
action. <bcp14>MUST</bcp14> be present if "compensation_required" is true.
Values <bcp14>SHOULD</bcp14> use structured identifiers (e.g.,
"policy_violation_in_parent_trade") rather than free-form text
to minimize the risk of embedding sensitive information. See
<xref target="data-minimization"/> for privacy guidance.
If "compensation_reason" is present, "compensation_required"
<bcp14>MUST</bcp14> be true.</t>
</dd>
</dl>
<t>Note: compensation ECTs reference historical parent tasks via the
"par" claim. The referenced parent ECTs may have passed their own
"exp" time; ECT expiration applies to the verification window of
the ECT itself, not to its validity as a parent reference in the
ledger.</t>
</section>
<section anchor="extension-claims"><name>Extensions</name>
<dl>
<dt>ext:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Object. An extension object for domain-specific
claims not defined by this specification. Implementations
that do not understand extension claims <bcp14>MUST</bcp14> ignore them.</t>
</dd>
</dl>
<t>To avoid key collisions between different domains, extension
key names <bcp14>MUST</bcp14> use reverse domain notation (e.g.,
"com.example.custom_field"). Implementations <bcp14>MUST NOT</bcp14> use
unqualified key names within the "ext" object. To prevent
abuse and excessive token size, the serialized JSON
representation of the "ext" object <bcp14>SHOULD NOT</bcp14> exceed 4096
bytes, and the JSON nesting depth within the "ext" object
<bcp14>SHOULD NOT</bcp14> exceed 5 levels. Implementations <bcp14>SHOULD</bcp14> reject
ECTs whose "ext" claim exceeds these limits.</t>
</section>
</section>
<section anchor="complete-ect-example"><name>Complete ECT Example</name>
<t>The following is a complete ECT payload example:</t>
<figure title="Complete ECT Payload Example" anchor="fig-full-ect"><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://example.com/agent/clinical",
"sub": "spiffe://example.com/agent/clinical",
"aud": "spiffe://example.com/agent/safety",
"iat": 1772064150,
"exp": 1772064750,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"exec_act": "recommend_treatment",
"par": [],
"pol": "clinical_reasoning_policy_v2",
"pol_decision": "approved",
"pol_enforcer": "spiffe://example.com/policy/clinical-engine",
"pol_timestamp": 1772064145,
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"inp_classification": "confidential",
"exec_time_ms": 245,
"regulated_domain": "medtech",
"model_version": "clinical-reasoning-v4.2",
"witnessed_by": [
"spiffe://example.com/audit/observer-1"
]
}
]]></sourcecode></figure>
</section>
</section>
<section anchor="http-header"><name>HTTP Header Transport</name>
<section anchor="execution-context-header-field"><name>Execution-Context Header Field</name>
<t>This specification defines the Execution-Context HTTP header field
<xref target="RFC9110"/> for transporting ECTs between agents.</t>
<t>The header field value is the ECT in JWS Compact Serialization
format <xref target="RFC7515"/>. The value consists of three Base64url-encoded
parts separated by period (".") characters.</t>
<t>An agent sending a request to another agent includes the
Execution-Context header alongside the WIMSE Workload-Identity
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 audit ledger, which
serves as the authoritative store of previously verified ECTs.</t>
</section>
<section anchor="validation-rules"><name>Validation Rules</name>
<t>When receiving and verifying an ECT, implementations <bcp14>MUST</bcp14> perform
the following DAG validation steps:</t>
<t><list style="numbers" type="1">
<t>Task ID Uniqueness: The "jti" claim <bcp14>MUST</bcp14> be unique within the
applicable scope (the workflow identified by "wid", or the
entire ECT store if "wid" is absent). If an ECT with the same
"jti" already exists, the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Parent Existence: Every task identifier listed in the "par"
array <bcp14>MUST</bcp14> correspond to a task that is available in the ECT
store (either previously recorded in the ledger or received
inline as a verified parent ECT). If any parent task is not
found, the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Temporal Ordering: The "iat" value of every parent task <bcp14>MUST
NOT</bcp14> be greater than the "iat" value of the current task plus a
configurable clock skew tolerance (<bcp14>RECOMMENDED</bcp14>: 30 seconds).
That is, for each parent: <spanx style="verb">parent.iat &lt; child.iat +
clock_skew_tolerance</spanx>. The tolerance accounts for clock skew
between agents; it does not guarantee strict causal ordering
from timestamps alone. Causal ordering is primarily enforced
by the DAG structure (parent existence in the ECT store), not by
timestamps. If any parent task violates this constraint, the
ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Acyclicity: Following the chain of parent references <bcp14>MUST NOT</bcp14>
lead back to the current ECT's "jti". If a cycle is detected,
the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Parent Policy Decision: If any parent ECT contains a
"pol_decision" of "rejected" or "pending_human_review", the
current ECT's "exec_act" <bcp14>MUST</bcp14> indicate a compensation,
rollback, remediation, or human review action.
Implementations <bcp14>MUST NOT</bcp14> accept an ECT representing normal
workflow continuation when a parent's "pol_decision" is not
"approved", unless the current ECT has "compensation_required"
set to true. This rule only applies when the parent ECT
contains policy claims.</t>
<t>Trust Domain Consistency: Parent tasks <bcp14>SHOULD</bcp14> belong to the
same trust domain or to a trust domain with which a federation
relationship has been established.</t>
</list></t>
</section>
<section anchor="dag-validation-algorithm"><name>DAG Validation Algorithm</name>
<t>The following pseudocode describes the DAG validation procedure:</t>
<figure title="DAG Validation Pseudocode" anchor="fig-dag-validation"><sourcecode type="pseudocode"><![CDATA[
function validate_dag(ect, ledger, clock_skew_tolerance):
// Step 1: Uniqueness check
if ledger.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 = ledger.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, ledger, 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, ledger,
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 = ledger.get(parent_id)
if parent is not null:
result = has_cycle(target_jti, parent.par, ledger,
visited, max_depth)
if result is error or result is true:
return result
return false
]]></sourcecode></figure>
<t>The cycle detection traverses the ancestor graph rooted at the
current task's parents. The complexity is O(V) where V is the
number of ancestor nodes reachable from the current task's parent
references. For typical workflows with shallow DAGs, this is
efficient. To prevent denial-of-service via extremely deep or
wide DAGs, implementations <bcp14>SHOULD</bcp14> enforce a maximum ancestor
traversal limit (<bcp14>RECOMMENDED</bcp14>: 10000 nodes). If the limit is
reached before cycle detection completes, the ECT <bcp14>SHOULD</bcp14> be
rejected. Implementations <bcp14>SHOULD</bcp14> cache cycle detection results
for previously verified tasks to avoid redundant traversals.</t>
</section>
</section>
<section anchor="verification"><name>Signature and Token Verification</name>
<section anchor="verification-procedure"><name>Verification Procedure</name>
<t>When an agent receives an ECT, it <bcp14>MUST</bcp14> perform the following
verification steps in order:</t>
<t><list style="numbers" type="1">
<t>Parse the JWS Compact Serialization to extract the JOSE header,
payload, and signature components per <xref target="RFC7515"/>.</t>
<t>Verify that the "typ" header parameter is "wimse-exec+jwt".</t>
<t>Verify that the "alg" header parameter is not "none" and is
not a symmetric algorithm.</t>
<t>Verify the "kid" header parameter references a known, valid
public key from a WIT within the trust domain.</t>
<t>Retrieve the public key identified by "kid" and verify the JWS
signature per <xref target="RFC7515"/> Section 5.2.</t>
<t>Verify that the signing key identified by "kid" has not been
revoked within the trust domain. Implementations <bcp14>MUST</bcp14> check
the key's revocation status using the trust domain's key
lifecycle mechanism (e.g., certificate revocation list, OCSP,
or SPIFFE trust bundle updates).</t>
<t>Verify the "alg" header parameter matches the algorithm in the
corresponding WIT.</t>
<t>Verify the "iss" claim matches the "sub" claim of the WIT
associated with the "kid" public key.</t>
<t>Verify the "aud" claim contains the verifier's own workload
identity. When "aud" is an array, it is sufficient that the
verifier's identity appears as one element; the presence of
other audience values does not cause verification failure.
When the verifier is the audit ledger, the ledger's own
identity <bcp14>MUST</bcp14> appear in "aud".</t>
<t>Verify the "exp" claim indicates the ECT has not expired.</t>
<t>Verify the "iat" claim is not unreasonably far in the past
(implementation-specific threshold, <bcp14>RECOMMENDED</bcp14> maximum of
15 minutes) and is not unreasonably far in the future
(<bcp14>RECOMMENDED</bcp14>: no more than 30 seconds ahead of the
verifier's current time, to account for clock skew).</t>
<t>Verify all required claims ("jti", "exec_act", "par") are
present and well-formed.</t>
<t>If "pol" or "pol_decision" is present, verify that both are
present and that "pol_decision" is one of "approved",
"rejected", or "pending_human_review".</t>
<t>Perform DAG validation per <xref target="dag-validation"/>.</t>
<t>If all checks pass, the ECT <bcp14>MUST</bcp14> be appended to the audit
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
ledger, to prevent information disclosure.</t>
<t>When ECT verification fails during HTTP request processing, the
receiving agent <bcp14>SHOULD</bcp14> respond with HTTP 403 (Forbidden) if the
WIT 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, ledger):
// Parse JWS
(header, payload, signature) = parse_jws(ect_jws)
// Verify header
if header.typ != "wimse-exec+jwt":
return reject("Invalid typ parameter")
if header.alg == "none" or is_symmetric(header.alg):
return reject("Prohibited algorithm")
// Look up public key
public_key = trust_domain_keys.get(header.kid)
if public_key is null:
return reject("Unknown key identifier")
// Verify signature
if not verify_jws_signature(header, payload,
signature, public_key):
return reject("Invalid signature")
// Verify key not revoked
if is_key_revoked(header.kid, trust_domain_keys):
return reject("Signing key has been revoked")
// Verify algorithm alignment
wit = get_wit_for_key(header.kid)
if header.alg != wit.alg:
return reject("Algorithm mismatch with WIT")
// Verify issuer matches WIT subject
if payload.iss != wit.sub:
return reject("Issuer does not match WIT subject")
// Verify audience
if verifier_id not in payload.aud:
return reject("ECT not intended for this recipient")
// Verify not expired
if payload.exp < current_time():
return reject("ECT has expired")
// Verify iat freshness (not too old, not in the future)
if payload.iat < current_time() - max_age_threshold:
return reject("ECT issued too long ago")
if payload.iat > current_time() + clock_skew_tolerance:
return reject("ECT issued in the future")
// Verify required claims
for claim in ["jti", "exec_act", "par"]:
if claim not in payload:
return reject("Missing required claim: " + claim)
// Validate policy claims (optional, but must be paired)
if "pol" in payload or "pol_decision" in payload:
if "pol" not in payload or "pol_decision" not in payload:
return reject("pol and pol_decision must both be present")
if payload.pol_decision not in
["approved", "rejected", "pending_human_review"]:
return reject("Invalid pol_decision value")
// Validate DAG (against ledger or inline parent ECTs)
result = validate_dag(payload, ledger,
clock_skew_tolerance)
if result is error:
return reject("DAG validation failed")
// All checks passed; append to ledger
ledger.append(payload)
return accept
]]></sourcecode></figure>
</section>
</section>
<section anchor="ledger-interface"><name>Audit Ledger Interface</name>
<t>ECTs are designed to be recorded in an immutable audit ledger for
compliance verification and post-hoc analysis. This specification
defines required properties for the ledger but does not mandate
a specific storage technology. Implementations <bcp14>MAY</bcp14> use
append-only logs, databases with cryptographic commitment schemes,
distributed ledgers, or any storage mechanism that provides the
required properties.</t>
<t>An audit ledger implementation <bcp14>MUST</bcp14> provide:</t>
<t><list style="numbers" type="1">
<t>Append-only semantics: Once an ECT is recorded, it <bcp14>MUST NOT</bcp14> be
modified or deleted.</t>
<t>Ordering: The ledger <bcp14>MUST</bcp14> maintain a total ordering of ECT
entries via a monotonically increasing sequence number.</t>
<t>Lookup by 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
pol: spec_review_policy_v2 pol_decision: approved
Agent B (Code Generator):
jti: task-002 par: [task-001]
exec_act: implement_module
pol: coding_standards_v3 pol_decision: approved
Agent C (Test Agent):
jti: task-003 par: [task-002]
exec_act: execute_test_suite
pol: test_coverage_policy_v1 pol_decision: approved
Agent D (Build Agent):
jti: task-004 par: [task-003]
exec_act: build_release_artifact
pol: build_validation_v2 pol_decision: approved
Human Release Manager:
jti: task-005 par: [task-004]
exec_act: approve_release
pol: release_approval_policy pol_decision: approved
pol_enforcer: spiffe://meddev.example/human/release-mgr-42
witnessed_by: [spiffe://meddev.example/audit/qa-observer-1]
]]></artwork></figure>
<t>ECTs record that requirements were reviewed before implementation
began, that tests were executed against the implemented code, that
the build artifact was validated, and that a human release manager
explicitly approved the release. The DAG structure ensures no
phase was skipped or reordered.</t>
<section anchor="fda-audit-with-dag-reconstruction"><name>FDA Audit with DAG Reconstruction</name>
<t>During a regulatory audit, an FDA reviewer requests evidence of
the development process for a specific software release. The
auditing authority retrieves all ECTs sharing the same workflow
identifier ("wid") from the audit ledger and reconstructs the
complete DAG:</t>
<figure title="Reconstructed DAG for FDA Audit" anchor="fig-fda-audit"><artwork><![CDATA[
task-001 (review_requirements_spec)
|
v
task-002 (implement_module)
|
v
task-003 (execute_test_suite)
|
v
task-004 (build_release_artifact)
|
v
task-005 (approve_release) [human, witnessed]
]]></artwork></figure>
<t>The reconstructed DAG provides cryptographic evidence that:</t>
<t><list style="symbols">
<t>Each phase was executed by an identified and authenticated agent.</t>
<t>Policy checkpoints were evaluated at every phase transition.</t>
<t>The execution sequence was maintained (no step was bypassed).</t>
<t>A human-in-the-loop approved the final release, with independent
witness attestation.</t>
<t>Timestamps and execution durations are recorded for each step.</t>
</list></t>
<t>This can contribute to compliance with:</t>
<t><list style="symbols">
<t><xref target="FDA-21CFR11"/> Section 11.10(e): Computer-generated audit trails
that record the date, time, and identity of the operator.</t>
<t><xref target="EU-MDR"/> Annex II: Technical documentation traceability for the
software development lifecycle.</t>
<t><xref target="EU-AI-ACT"/> Article 12: Automatic logging capabilities for
high-risk AI systems involved in the development process.</t>
<t><xref target="EU-AI-ACT"/> Article 14: ECTs can record evidence that human
oversight events occurred during the release process.</t>
</list></t>
</section>
</section>
<section anchor="financial-trading-workflow"><name>Financial Trading Workflow</name>
<t>In a financial trading workflow, agents perform risk assessment,
compliance verification, and trade execution. The DAG structure
records that compliance checks were evaluated before trade
execution.</t>
<figure title="Financial Trading Workflow" anchor="fig-finance"><artwork><![CDATA[
Agent A (Risk Assessment):
jti: task-001 par: []
exec_act: calculate_risk_exposure
pol: risk_limits_policy_v2 pol_decision: approved
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
pol: compliance_check_v1 pol_decision: approved
Agent C (Execution):
jti: task-003 par: [task-002]
exec_act: execute_trade
pol: execution_policy_v3 pol_decision: approved
]]></artwork></figure>
<t>This can contribute to compliance with:</t>
<t><list style="symbols">
<t><xref target="MIFID-II"/>: ECTs provide cryptographic records of the execution
sequence that can support transaction audit requirements.</t>
<t><xref target="DORA"/> Article 12: ECTs contribute to ICT activity logging.</t>
<t><xref target="EU-AI-ACT"/> Article 12: Logging of decisions made by AI-driven
systems.</t>
</list></t>
</section>
<section anchor="compensation-and-rollback"><name>Compensation and Rollback</name>
<t>When a compliance violation is discovered after execution, ECTs
provide a mechanism to record authorized compensation actions with
a cryptographic link to the original task:</t>
<figure title="Compensation ECT Example" anchor="fig-compensation"><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://bank.example/agent/operations",
"sub": "spiffe://bank.example/agent/operations",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772150550,
"exp": 1772151150,
"jti": "550e8400-e29b-41d4-a716-446655440099",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"exec_act": "initiate_trade_rollback",
"par": ["550e8400-e29b-41d4-a716-446655440003"],
"pol": "compensation_policy_v1",
"pol_decision": "approved",
"pol_enforcer": "spiffe://bank.example/human/compliance-officer",
"compensation_required": true,
"compensation_reason": "policy_violation_in_parent_trade"
}
]]></sourcecode></figure>
<t>The "par" claim links the compensation action to the original
trade, creating an auditable chain from execution through
violation discovery to remediation.</t>
</section>
<section anchor="autonomous-logistics-coordination"><name>Autonomous Logistics Coordination</name>
<t>In a logistics workflow, multiple compliance checks complete
before shipment commitment. The DAG structure records that all
required checks were completed:</t>
<figure title="Logistics Workflow with Parallel Tasks" anchor="fig-logistics"><artwork><![CDATA[
Agent A (Route Planning):
jti: task-001 par: []
exec_act: plan_route
pol: route_policy_v1 pol_decision: approved
Agent B (Customs):
jti: task-002 par: [task-001]
exec_act: validate_customs
pol: customs_policy_v2 pol_decision: approved
Agent C (Safety):
jti: task-003 par: [task-001]
exec_act: verify_cargo_safety
pol: safety_policy_v1 pol_decision: approved
Agent D (Payment):
jti: task-004 par: [task-002, task-003]
exec_act: authorize_payment
pol: payment_policy_v3 pol_decision: approved
System (Commitment):
jti: task-005 par: [task-004]
exec_act: commit_shipment
pol: commitment_policy_v1 pol_decision: approved
]]></artwork></figure>
<t>Note that tasks 002 and 003 both depend only on task-001 and can
execute in parallel. Task 004 depends on both, demonstrating the
DAG's ability to represent parallel execution with a join point.</t>
</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>This section addresses security considerations following the
guidance in <xref target="RFC3552"/>.</t>
<section anchor="threat-model"><name>Threat Model</name>
<t>The following threat actors are considered:</t>
<t><list style="symbols">
<t>Malicious agent (insider threat): An agent within the trust
domain that intentionally creates false ECT claims.</t>
<t>Compromised agent (external attacker): An agent whose private
key has been obtained by an external attacker.</t>
<t>Ledger tamperer: An entity attempting to modify or delete ledger
entries after they have been recorded.</t>
<t>Time manipulator: An entity attempting to manipulate timestamps
to alter perceived execution ordering.</t>
</list></t>
</section>
<section anchor="self-assertion-limitation"><name>Self-Assertion Limitation</name>
<t>ECTs are self-asserted by the executing agent. The agent claims
what it did, and this claim is signed with its private key. A
compromised or malicious agent could create ECTs with false claims
(e.g., setting "pol_decision" to "approved" without actually
evaluating the policy).</t>
<t>ECTs do not independently verify that:</t>
<t><list style="symbols">
<t>The claimed execution actually occurred as described</t>
<t>The policy evaluation was correctly performed</t>
<t>The input/output hashes correspond to the actual data processed</t>
<t>The agent faithfully performed the stated action</t>
</list></t>
<t>The trustworthiness of ECT claims depends on the trustworthiness
of the signing agent. To mitigate single-agent false claims,
regulated environments <bcp14>SHOULD</bcp14> use the "witnessed_by" mechanism
to include independent third-party observers at critical decision
points. However, the "witnessed_by" claim is self-asserted by
the ECT issuer: the listed witnesses do not co-sign the ECT and
there is no cryptographic evidence within a single ECT that the
witnesses actually observed the task. An issuing agent could
list witnesses that did not participate.</t>
<section anchor="witness-attestation-model"><name>Witness Attestation Model</name>
<t>To address the self-assertion limitation of the "witnessed_by"
claim, witnesses <bcp14>SHOULD</bcp14> submit their own independent signed ECTs
to the audit ledger attesting to the observed task. A witness
attestation ECT:</t>
<t><list style="symbols">
<t><bcp14>MUST</bcp14> set "iss" to the witness's own workload identity.</t>
<t><bcp14>MUST</bcp14> set "exec_act" to "witness_attestation" (or a domain-
specific equivalent).</t>
<t><bcp14>MUST</bcp14> include the observed task's "jti" in the "par" array,
linking the attestation to the original task.</t>
<t><bcp14>MUST</bcp14> set "pol_decision" to "approved" to indicate the witness
confirms the observation.</t>
</list></t>
<t>When a task's "witnessed_by" claim lists one or more witnesses,
auditors <bcp14>SHOULD</bcp14> verify that corresponding witness attestation
ECTs exist in the ledger for each listed witness. A mismatch
between the "witnessed_by" list and the set of independent witness
ECTs in the ledger <bcp14>SHOULD</bcp14> be flagged during audit review.</t>
<t>This model converts witness attestation from a self-asserted claim
to a cryptographically verifiable property of the ledger: the
witness independently signs their own ECT using their own key,
and the ledger records both the original task ECT and the witness
attestation ECTs.</t>
</section>
</section>
<section anchor="organizational-prerequisites"><name>Organizational Prerequisites</name>
<t>ECTs operate within a broader trust framework. The guarantees
provided by ECTs are only meaningful when the following
organizational controls are in place:</t>
<t><list style="symbols">
<t>Key management governance: Controls over who provisions agent
keys and how keys are protected.</t>
<t>Ledger integrity governance: The ledger is maintained by an
entity independent of the workflow agents.</t>
<t>Policy lifecycle management: Policy identifiers in ECTs map to
actual, validated policy rules.</t>
<t>Agent deployment governance: Agents are deployed and maintained
in a manner that preserves their integrity.</t>
</list></t>
</section>
<section anchor="signature-verification"><name>Signature Verification</name>
<t>ECTs <bcp14>MUST</bcp14> be signed with the agent's private key using JWS
<xref target="RFC7515"/>. The signature algorithm <bcp14>MUST</bcp14> match the algorithm
specified in the agent's WIT. Receivers <bcp14>MUST</bcp14> verify the ECT
signature against the WIT public key before processing any
claims. Receivers <bcp14>MUST</bcp14> verify that the signing key has not been
revoked within the trust domain (see step 6 in
<xref target="verification"/>).</t>
<t>If signature verification fails or if the signing key has been
revoked, the ECT <bcp14>MUST</bcp14> be rejected entirely and the failure <bcp14>MUST</bcp14>
be logged.</t>
<t>Implementations <bcp14>MUST</bcp14> use established JWS libraries and <bcp14>MUST NOT</bcp14>
implement custom signature verification.</t>
</section>
<section anchor="replay-attack-prevention"><name>Replay Attack Prevention</name>
<t>ECTs include short expiration times (<bcp14>RECOMMENDED</bcp14>: 5-15 minutes) to
limit the window for replay attacks. The "aud" claim restricts
replay to unintended recipients: an ECT intended for Agent B
will be rejected by Agent C. The "iat" claim enables receivers to
reject ECTs that are too old, even if not yet expired.</t>
<t>The DAG structure provides additional replay protection: an ECT
referencing parent tasks that already have a recorded child task
with the same action can be flagged as a potential replay.</t>
<t>Implementations <bcp14>MUST</bcp14> maintain a cache of recently-seen "jti"
values to detect replayed ECTs within the expiration window.
An ECT with a duplicate "jti" value <bcp14>MUST</bcp14> be rejected.</t>
</section>
<section anchor="man-in-the-middle-protection"><name>Man-in-the-Middle Protection</name>
<t>ECTs do not replace transport-layer security. ECTs <bcp14>MUST</bcp14> be
transmitted over TLS or mTLS connections. When used with the WIMSE
service-to-service protocol <xref target="I-D.ietf-wimse-s2s-protocol"/>,
transport security is already established. HTTP Message Signatures
<xref target="RFC9421"/> provide an alternative channel binding mechanism.</t>
<t>The defense-in-depth model provides:</t>
<t><list style="symbols">
<t>TLS/mTLS (transport layer): Prevents network-level tampering.</t>
<t>WIT/WPT (WIMSE identity layer): Proves agent identity and
request authorization.</t>
<t>ECT (execution accountability layer): Records what the agent did
and under what policy.</t>
</list></t>
</section>
<section anchor="key-compromise"><name>Key Compromise</name>
<t>If an agent's private key is compromised, an attacker can forge
ECTs that appear to originate from that agent. To mitigate this
risk:</t>
<t><list style="symbols">
<t>Implementations <bcp14>SHOULD</bcp14> use short-lived keys and rotate them
frequently (hours to days, not months).</t>
<t>Private keys <bcp14>SHOULD</bcp14> be stored in Hardware Security Modules (HSMs)
or equivalent secure key storage.</t>
<t>Trust domains <bcp14>MUST</bcp14> support rapid key revocation.</t>
<t>Upon suspected compromise, the trust domain <bcp14>MUST</bcp14> revoke the
compromised key and issue a new WIT with a fresh key pair.</t>
</list></t>
<t>ECTs signed with a compromised key that were recorded in the
ledger before revocation remain valid historical records but <bcp14>SHOULD</bcp14>
be flagged in the ledger as "signed with subsequently revoked key"
for audit purposes.</t>
</section>
<section anchor="collusion-and-false-claims"><name>Collusion and False Claims</name>
<t>A single malicious agent cannot forge parent task references
because DAG validation requires parent tasks to exist in the
ledger. However, multiple colluding agents could potentially
create a false execution history if they control the ledger.</t>
<t>Mitigations include:</t>
<t><list style="symbols">
<t>Independent ledger maintenance: The ledger <bcp14>SHOULD</bcp14> be maintained
by an entity independent of the workflow agents.</t>
<t>Witness attestation: Using the "witnessed_by" claim to include
independent third-party observers.</t>
<t>Cross-verification: Multiple independent ledger replicas can be
compared for consistency.</t>
<t>Out-of-band audit: External auditors periodically verify ledger
contents against expected workflow patterns.</t>
</list></t>
</section>
<section anchor="denial-of-service"><name>Denial of Service</name>
<t>ECT signature verification is computationally inexpensive
(approximately 1ms per ECT on modern hardware for ES256). DAG
validation complexity is O(V) where V is the number of ancestor
nodes reachable from the parent references; for typical shallow
DAGs this is efficient.</t>
<t>Implementations <bcp14>SHOULD</bcp14> apply rate limiting at the API layer to
prevent excessive ECT submissions. DAG validation <bcp14>SHOULD</bcp14> be
performed after signature verification to avoid wasting resources
on unsigned or incorrectly signed tokens.</t>
</section>
<section anchor="timestamp-accuracy"><name>Timestamp Accuracy</name>
<t>ECTs rely on timestamps ("iat", "exp") for temporal ordering.
Clock skew between agents can lead to incorrect ordering
judgments. Implementations <bcp14>SHOULD</bcp14> use synchronized time sources
(e.g., NTP) and <bcp14>SHOULD</bcp14> allow a configurable clock skew tolerance
(<bcp14>RECOMMENDED</bcp14>: 30 seconds).</t>
<t>Cross-organizational deployments where agents span multiple trust
domains with independent time sources <bcp14>MAY</bcp14> require a higher clock
skew tolerance. Deployments using trust domain federation <bcp14>SHOULD</bcp14>
document their configured clock skew tolerance value and <bcp14>SHOULD</bcp14>
ensure all participating trust domains agree on a common tolerance.</t>
<t>The temporal ordering check in DAG validation incorporates the
clock skew tolerance to account for minor clock differences
between agents.</t>
</section>
<section anchor="ect-size-constraints"><name>ECT Size Constraints</name>
<t>ECTs with many parent tasks or large extension objects can
increase HTTP header size. Implementations <bcp14>SHOULD</bcp14> limit the "par"
array to a maximum of 256 entries. Workflows requiring more
parent references <bcp14>SHOULD</bcp14> introduce intermediate aggregation
tasks. The "ext" object <bcp14>SHOULD NOT</bcp14> exceed 4096 bytes when
serialized as JSON and <bcp14>SHOULD NOT</bcp14> exceed a nesting depth of
5 levels (see also <xref target="extension-claims"/>).</t>
</section>
</section>
<section anchor="privacy-considerations"><name>Privacy Considerations</name>
<section anchor="data-exposure-in-ects"><name>Data Exposure in ECTs</name>
<t>ECTs necessarily reveal:</t>
<t><list style="symbols">
<t>Agent identities ("iss", "aud") for accountability purposes</t>
<t>Action descriptions ("exec_act") for audit trail completeness</t>
<t>Policy evaluation outcomes ("pol", "pol_decision") for
compliance verification</t>
<t>Timestamps ("iat", "exp") for temporal ordering</t>
</list></t>
<t>ECTs are designed to NOT reveal:</t>
<t><list style="symbols">
<t>Actual input or output data values (replaced with cryptographic
hashes via "inp_hash" and "out_hash")</t>
<t>Internal computation details or intermediate steps</t>
<t>Proprietary algorithms or intellectual property</t>
<t>Personally identifiable information (PII)</t>
</list></t>
</section>
<section anchor="data-minimization"><name>Data Minimization</name>
<t>Implementations <bcp14>SHOULD</bcp14> minimize the information included in ECTs.
The "exec_act" claim <bcp14>SHOULD</bcp14> use structured identifiers (e.g.,
"process_payment") rather than natural language descriptions.
The "pol" claim <bcp14>SHOULD</bcp14> reference policy identifiers rather than
embedding policy content.</t>
<t>The "compensation_reason" claim (<xref target="compensation-claims"/>)
deserves particular attention: because it is human-readable and
may describe the circumstances of a failure or policy violation,
it risks exposing sensitive operational details. Implementations
<bcp14>SHOULD</bcp14> use short, structured reason codes (e.g.,
"policy_violation_in_parent_trade") rather than free-form
natural language explanations. Implementers <bcp14>SHOULD</bcp14> review
"compensation_reason" values for potential information leakage
before deploying to production.</t>
</section>
<section anchor="storage-and-access-control"><name>Storage and Access Control</name>
<t>ECTs stored in audit ledgers <bcp14>SHOULD</bcp14> be access-controlled so that
only authorized auditors and regulators can read them.
Implementations <bcp14>SHOULD</bcp14> consider encryption at rest for ledger
storage containing sensitive regulatory data.</t>
<t>Full input and output data (corresponding to the hashes in ECTs)
<bcp14>SHOULD</bcp14> be stored separately from the ledger with additional access
controls, since auditors may need to verify hash correctness but
general access to the data values is not needed.</t>
</section>
<section anchor="regulatory-access"><name>Regulatory Access</name>
<t>ECTs are designed for interpretation by qualified human auditors
and regulators. ECTs provide structural records of execution
ordering and policy evaluation; they are not intended for public
disclosure.</t>
</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<section anchor="media-type-registration"><name>Media Type Registration</name>
<t>This document requests registration of the following media type
in the "Media Types" registry maintained by IANA:</t>
<dl>
<dt>Type name:</dt>
<dd>
<t>application</t>
</dd>
<dt>Subtype name:</dt>
<dd>
<t>wimse-exec+jwt</t>
</dd>
<dt>Required parameters:</dt>
<dd>
<t>none</t>
</dd>
<dt>Optional parameters:</dt>
<dd>
<t>none</t>
</dd>
<dt>Encoding considerations:</dt>
<dd>
<t>8bit; an ECT is a JWT that is a JWS using the Compact
Serialization, which is a sequence of Base64url-encoded values
separated by period characters.</t>
</dd>
<dt>Security considerations:</dt>
<dd>
<t>See the Security Considerations section of this document.</t>
</dd>
<dt>Interoperability considerations:</dt>
<dd>
<t>none</t>
</dd>
<dt>Published specification:</dt>
<dd>
<t>This document</t>
</dd>
<dt>Applications that use this media type:</dt>
<dd>
<t>Applications that implement regulated agentic workflows requiring
execution context tracing and audit trails.</t>
</dd>
<dt>Additional information:</dt>
<dd>
<t>Magic number(s): none
File extension(s): none
Macintosh file type code(s): none</t>
</dd>
<dt>Person and email address to contact for further information:</dt>
<dd>
<t>Christian Nennemann, ietf@nennemann.de</t>
</dd>
<dt>Intended usage:</dt>
<dd>
<t>COMMON</t>
</dd>
<dt>Restrictions on usage:</dt>
<dd>
<t>none</t>
</dd>
<dt>Author:</dt>
<dd>
<t>Christian Nennemann</t>
</dd>
<dt>Change controller:</dt>
<dd>
<t>IETF</t>
</dd>
</dl>
</section>
<section anchor="header-registration"><name>HTTP Header Field Registration</name>
<t>This document requests registration of the following header field
in the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
maintained by IANA:</t>
<dl>
<dt>Field name:</dt>
<dd>
<t>Execution-Context</t>
</dd>
<dt>Status:</dt>
<dd>
<t>permanent</t>
</dd>
<dt>Specification document:</dt>
<dd>
<t>This document, <xref target="http-header"/></t>
</dd>
</dl>
</section>
<section anchor="claims-registration"><name>JWT Claims Registration</name>
<t>This document requests registration of the following claims in
the "JSON Web Token Claims" registry maintained by IANA:</t>
<texttable title="JWT Claims Registrations" anchor="_table-claims">
<ttcol align='center'>Claim Name</ttcol>
<ttcol align='left'>Claim Description</ttcol>
<ttcol align='center'>Change Controller</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>wid</c>
<c>Workflow Identifier</c>
<c>IETF</c>
<c><xref target="exec-claims"/></c>
<c>exec_act</c>
<c>Action/Task Type</c>
<c>IETF</c>
<c><xref target="exec-claims"/></c>
<c>par</c>
<c>Parent Task Identifiers</c>
<c>IETF</c>
<c><xref target="exec-claims"/></c>
<c>pol</c>
<c>Policy Rule Identifier</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_decision</c>
<c>Policy Decision Result</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_enforcer</c>
<c>Policy Enforcer Identity</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_timestamp</c>
<c>Policy Decision Timestamp</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>inp_hash</c>
<c>Input Data Hash</c>
<c>IETF</c>
<c><xref target="data-integrity-claims"/></c>
<c>out_hash</c>
<c>Output Data Hash</c>
<c>IETF</c>
<c><xref target="data-integrity-claims"/></c>
<c>inp_classification</c>
<c>Input Data Classification</c>
<c>IETF</c>
<c><xref target="data-integrity-claims"/></c>
<c>exec_time_ms</c>
<c>Execution Time (ms)</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>witnessed_by</c>
<c>Witness Identities</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>regulated_domain</c>
<c>Regulatory Domain</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>model_version</c>
<c>AI/ML Model Version</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>compensation_required</c>
<c>Compensation Flag</c>
<c>IETF</c>
<c><xref target="compensation-claims"/></c>
<c>compensation_reason</c>
<c>Compensation Reason</c>
<c>IETF</c>
<c><xref target="compensation-claims"/></c>
<c>ext</c>
<c>Extension Object</c>
<c>IETF</c>
<c><xref target="extension-claims"/></c>
</texttable>
</section>
<section anchor="pol-decision-registry"><name>ECT Policy Decision Values Registry</name>
<t>This document establishes the "ECT Policy Decision Values"
registry under the "JSON Web Token (JWT)" group. Registration
policy is Specification Required per <xref target="RFC8126"/>.</t>
<t>The initial contents of the registry are:</t>
<texttable title="ECT Policy Decision Values" anchor="_table-pol-decision">
<ttcol align='center'>Value</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='center'>Change Controller</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>approved</c>
<c>Policy evaluation succeeded</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>rejected</c>
<c>Policy evaluation failed</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pending_human_review</c>
<c>Awaiting human judgment</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
</texttable>
</section>
<section anchor="regulated-domain-registry"><name>ECT Regulated Domain Values Registry</name>
<t>This document establishes the "ECT Regulated Domain Values"
registry under the "JSON Web Token (JWT)" group. Registration
policy is Specification Required per <xref target="RFC8126"/>.</t>
<t>The initial contents of the registry are:</t>
<texttable title="ECT Regulated Domain Values" anchor="_table-regulated-domain">
<ttcol align='center'>Value</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='center'>Change Controller</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>medtech</c>
<c>Medical technology and devices</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>finance</c>
<c>Financial services and trading</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
<c>military</c>
<c>Military and defense</c>
<c>IETF</c>
<c><xref target="operational-claims"/></c>
</texttable>
</section>
</section>
</middle>
<back>
<references title='References' anchor="sec-combined-references">
<references title='Normative References' anchor="sec-normative-references">
<reference anchor="RFC7515">
<front>
<title>JSON Web Signature (JWS)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
<date month="May" year="2015"/>
<abstract>
<t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7515"/>
<seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>
<reference anchor="RFC7517">
<front>
<title>JSON Web Key (JWK)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<date month="May" year="2015"/>
<abstract>
<t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7517"/>
<seriesInfo name="DOI" value="10.17487/RFC7517"/>
</reference>
<reference anchor="RFC7519">
<front>
<title>JSON Web Token (JWT)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
<date month="May" year="2015"/>
<abstract>
<t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7519"/>
<seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>
<reference anchor="RFC7518">
<front>
<title>JSON Web Algorithms (JWA)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<date month="May" year="2015"/>
<abstract>
<t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7518"/>
<seriesInfo name="DOI" value="10.17487/RFC7518"/>
</reference>
<reference anchor="RFC9562">
<front>
<title>Universally Unique IDentifiers (UUIDs)</title>
<author fullname="K. Davis" initials="K." surname="Davis"/>
<author fullname="B. Peabody" initials="B." surname="Peabody"/>
<author fullname="P. Leach" initials="P." surname="Leach"/>
<date month="May" year="2024"/>
<abstract>
<t>This specification defines UUIDs (Universally Unique IDentifiers) --
also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform
Resource Name namespace for UUIDs. A UUID is 128 bits long and is
intended to guarantee uniqueness across space and time. UUIDs were
originally used in the Apollo Network Computing System (NCS), later
in the Open Software Foundation's (OSF's) Distributed Computing
Environment (DCE), and then in Microsoft Windows platforms.</t>
<t>This specification is derived from the OSF DCE specification with the
kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have
been incorporated into this document. This document obsoletes RFC
4122.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9562"/>
<seriesInfo name="DOI" value="10.17487/RFC9562"/>
</reference>
<reference anchor="RFC9110">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="I-D.ietf-wimse-arch">
<front>
<title>Workload Identity in a Multi System Environment (WIMSE) Architecture</title>
<author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
<organization>CyberArk</organization>
</author>
<author fullname="Yaroslav Rosomakho" initials="Y." surname="Rosomakho">
<organization>Zscaler</organization>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>University of Applied Sciences Bonn-Rhein-Sieg</organization>
</author>
<date day="30" month="September" year="2025"/>
<abstract>
<t> The increasing prevalence of cloud computing and micro service
architectures has led to the rise of complex software functions being
built and deployed as workloads, where a workload is defined as a
running instance of software executing for a specific purpose. This
document discusses an architecture for designing and standardizing
protocols and payloads for conveying workload identity and security
context information.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-wimse-arch-06"/>
</reference>
<reference anchor="I-D.ietf-wimse-s2s-protocol">
<front>
<title>WIMSE Workload-to-Workload Authentication</title>
<author fullname="Brian Campbell" initials="B." surname="Campbell">
<organization>Ping Identity</organization>
</author>
<author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
<organization>CyberArk</organization>
</author>
<author fullname="Arndt Schwenkschuster" initials="A." surname="Schwenkschuster">
<organization>SPIRL</organization>
</author>
<author fullname="Yaron Sheffer" initials="Y." surname="Sheffer">
<organization>Intuit</organization>
</author>
<date day="16" month="October" year="2025"/>
<abstract>
<t> The WIMSE architecture defines authentication and authorization for
software workloads in a variety of runtime environments, from the
most basic ones up to complex multi-service, multi-cloud, multi-
tenant deployments. This document defines the simplest, atomic unit
of this architecture: the protocol between two workloads that need to
verify each other&#x27;s identity in order to communicate securely. The
scope of this protocol is a single HTTP request-and-response pair.
To address the needs of different setups, we propose two protocols,
one at the application level and one that makes use of trusted TLS
transport. These two protocols are compatible, in the sense that a
single call chain can have some calls use one protocol and some use
the other. Workload A can call Workload B with mutual TLS
authentication, while the next call from Workload B to Workload C
would be authenticated at the application level.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-wimse-s2s-protocol-07"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
</references>
<references title='Informative References' anchor="sec-informative-references">
<reference anchor="RFC3552">
<front>
<title>Guidelines for Writing RFC Text on Security Considerations</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="B. Korver" initials="B." surname="Korver"/>
<date month="July" year="2003"/>
<abstract>
<t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="72"/>
<seriesInfo name="RFC" value="3552"/>
<seriesInfo name="DOI" value="10.17487/RFC3552"/>
</reference>
<reference anchor="RFC8693">
<front>
<title>OAuth 2.0 Token Exchange</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="A. Nadalin" initials="A." surname="Nadalin"/>
<author fullname="B. Campbell" initials="B." role="editor" surname="Campbell"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="C. Mortimore" initials="C." surname="Mortimore"/>
<date month="January" year="2020"/>
<abstract>
<t>This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8693"/>
<seriesInfo name="DOI" value="10.17487/RFC8693"/>
</reference>
<reference anchor="RFC9421">
<front>
<title>HTTP Message Signatures</title>
<author fullname="A. Backman" initials="A." role="editor" surname="Backman"/>
<author fullname="J. Richer" initials="J." role="editor" surname="Richer"/>
<author fullname="M. Sporny" initials="M." surname="Sporny"/>
<date month="February" year="2024"/>
<abstract>
<t>This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9421"/>
<seriesInfo name="DOI" value="10.17487/RFC9421"/>
</reference>
<reference anchor="I-D.ni-wimse-ai-agent-identity">
<front>
<title>WIMSE Applicability for AI Agents</title>
<author fullname="Ni Yuan" initials="N." surname="Yuan">
<organization>Huawei</organization>
</author>
<author fullname="Peter Chunchi Liu" initials="P. C." surname="Liu">
<organization>Huawei</organization>
</author>
<date day="20" month="October" year="2025"/>
<abstract>
<t> This document discusses WIMSE applicability to Agentic AI, so as to
establish independent identities and credential management mechanisms
for AI agents.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ni-wimse-ai-agent-identity-01"/>
</reference>
<reference anchor="SPIFFE" target="https://spiffe.io/docs/latest/spiffe-about/overview/">
<front>
<title>Secure Production Identity Framework for Everyone (SPIFFE)</title>
<author >
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="EU-AI-ACT" target="https://eur-lex.europa.eu/eli/reg/2024/1689">
<front>
<title>Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2024" month="June" day="13"/>
</front>
</reference>
<reference anchor="FDA-21CFR11" target="https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11">
<front>
<title>Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures</title>
<author >
<organization>U.S. Food and Drug Administration</organization>
</author>
<date />
</front>
</reference>
<reference anchor="MIFID-II" target="https://eur-lex.europa.eu/eli/dir/2014/65">
<front>
<title>Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2014" month="May" day="15"/>
</front>
</reference>
<reference anchor="DORA" target="https://eur-lex.europa.eu/eli/reg/2022/2554">
<front>
<title>Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2022" month="December" day="14"/>
</front>
</reference>
<reference anchor="EU-MDR" target="https://eur-lex.europa.eu/eli/reg/2017/745">
<front>
<title>Regulation (EU) 2017/745 on medical devices (MDR)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2017" month="April" day="05"/>
</front>
</reference>
<reference anchor="OPENTELEMETRY" target="https://opentelemetry.io/docs/specs/otel/">
<front>
<title>OpenTelemetry Specification</title>
<author >
<organization>Cloud Native Computing Foundation</organization>
</author>
<date />
</front>
</reference>
<reference anchor="I-D.ietf-scitt-architecture">
<front>
<title>An Architecture for Trustworthy and Transparent Digital Supply Chains</title>
<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
<organization>Fraunhofer SIT</organization>
</author>
<author fullname="Antoine Delignat-Lavaud" initials="A." surname="Delignat-Lavaud">
<organization>Microsoft Research</organization>
</author>
<author fullname="Cedric Fournet" initials="C." surname="Fournet">
<organization>Microsoft Research</organization>
</author>
<author fullname="Yogesh Deshpande" initials="Y." surname="Deshpande">
<organization>ARM</organization>
</author>
<author fullname="Steve Lasker" initials="S." surname="Lasker">
</author>
<date day="10" month="October" year="2025"/>
<abstract>
<t> Traceability in supply chains is a growing security concern. While
verifiable data structures have addressed specific issues, such as
equivocation over digital certificates, they lack a universal
architecture for all supply chains. This document defines such an
architecture for single-issuer signed statement transparency. It
ensures extensibility, interoperability between different
transparency services, and compliance with various auditing
procedures and regulatory requirements.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-scitt-architecture-22"/>
</reference>
<reference anchor="I-D.ietf-oauth-transaction-tokens">
<front>
<title>Transaction Tokens</title>
<author fullname="Atul Tulshibagwale" initials="A." surname="Tulshibagwale">
<organization>SGNL</organization>
</author>
<author fullname="George Fletcher" initials="G." surname="Fletcher">
<organization>Practical Identity LLC</organization>
</author>
<author fullname="Pieter Kasselman" initials="P." surname="Kasselman">
<organization>Defakto Security</organization>
</author>
<date day="24" month="January" year="2026"/>
<abstract>
<t> Transaction Tokens (Txn-Tokens) are designed to maintain and
propagate user identity and authorization context across workloads
within a trusted domain during the processing of external requests,
such as API calls. They ensure that this context is preserved
throughout the call chain, even when new transactions are initiated
internally, thereby enhancing security and consistency in complex,
multi-service architectures.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-oauth-transaction-tokens-07"/>
</reference>
<reference anchor="I-D.oauth-transaction-tokens-for-agents">
<front>
<title>Transaction Tokens For Agents</title>
<author fullname="Ashay Raut" initials="A." surname="Raut">
<organization>Amazon</organization>
</author>
<date day="10" month="February" year="2026"/>
<abstract>
<t> This document specifies an extension to the OAuth Transaction Tokens
framework (https://drafts.oauth.net/oauth-transaction-tokens/draft-
ietf-oauth-transaction-tokens.html) to support agent context
propagation within Transaction Tokens for agent-based workloads. The
extension defines two new context fields: &#x27;actor&#x27; and &#x27;principal&#x27;.
The &#x27;actor&#x27; field identifies the agent performing the action, while
the &#x27;principal&#x27; field identifies the human or system entity that
initiated the agent&#x27;s action. For autonomous agents operating
independently, the &#x27;principal&#x27; field MAY be omitted. These
additional context fields enable services within the call graph to
make more granular access control decisions, thereby enhancing
security.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-oauth-transaction-tokens-for-agents-04"/>
</reference>
</references>
</references>
<?line 1628?>
<section numbered="false" anchor="related-work"><name>Related Work</name>
<section numbered="false" anchor="wimse-workload-identity"><name>WIMSE Workload Identity</name>
<t>The WIMSE architecture <xref target="I-D.ietf-wimse-arch"/> and service-to-
service protocol <xref target="I-D.ietf-wimse-s2s-protocol"/> provide the
identity foundation upon which ECTs are built. WIT/WPT answer
"who is this agent?" and "does it control the claimed key?" while
ECTs record "what did this agent do?" and "what policy was
evaluated?" Together they form an identity-plus-accountability
framework for regulated agentic systems.</t>
</section>
<section numbered="false" anchor="oauth-20-token-exchange-and-the-act-claim"><name>OAuth 2.0 Token Exchange and the "act" Claim</name>
<t><xref target="RFC8693"/> defines the OAuth 2.0 Token Exchange protocol and
registers the "act" (Actor) claim in the JWT Claims registry.
The "act" claim creates nested JSON objects representing a
delegation chain: "who is acting on behalf of whom." While
the nesting superficially resembles a chain, it is strictly
linear (each "act" object contains at most one nested "act"),
represents authorization delegation rather than task execution,
and carries no task identifiers, policy decisions, or
input/output integrity data. The "act" chain cannot represent
branching (fan-out) or convergence (fan-in) and therefore
cannot form a DAG.</t>
<t>ECTs intentionally use the distinct claim name "exec_act" for the
action/task type to avoid collision with the "act" claim. The
two concepts are orthogonal: "act" records "who authorized whom,"
ECTs record "what was done, in what order, with what policy
outcomes."</t>
</section>
<section numbered="false" anchor="transaction-tokens"><name>Transaction Tokens</name>
<t>OAuth Transaction Tokens <xref target="I-D.ietf-oauth-transaction-tokens"/>
propagate authorization context across workload call chains.
The Txn-Token "req_wl" claim accumulates a comma-separated list
of workloads that requested replacement tokens, which is the
closest existing mechanism to call-chain recording.</t>
<t>However, "req_wl" cannot form a DAG because:</t>
<t><list style="symbols">
<t>It is linear: a comma-separated string with no branching or
merging representation. When a workload fans out to multiple
downstream services, each receives the same "req_wl" value and
the branching is invisible.</t>
<t>It is incomplete: only workloads that request a replacement
token from the Transaction Token Service appear in "req_wl";
workloads that forward the token unchanged are not recorded.</t>
<t>It carries no task-level granularity, no parent references,
no policy evaluation outcomes, and no execution content.</t>
</list></t>
<t>Extensions for agentic use cases
(<xref target="I-D.oauth-transaction-tokens-for-agents"/>) add agent
identity and constraints ("agentic_ctx") but no execution
ordering or DAG structure.</t>
<t>ECTs and Transaction Tokens are complementary: a Txn-Token
propagates authorization context ("this request is authorized
for scope X on behalf of user Y"), while an ECT records
execution accountability ("task T was performed, depending on
tasks P1 and P2, with policy Z evaluated and approved"). An
agent request could carry both a Txn-Token for authorization
and an ECT for execution recording. The WPT "tth" claim
defined in <xref target="I-D.ietf-wimse-s2s-protocol"/> can hash-bind a
WPT to a co-present Txn-Token; a similar binding mechanism
for ECTs is a potential future extension.</t>
</section>
<section numbered="false" anchor="distributed-tracing-opentelemetry"><name>Distributed Tracing (OpenTelemetry)</name>
<t>OpenTelemetry <xref target="OPENTELEMETRY"/> and similar distributed tracing
systems provide observability for debugging and monitoring. ECTs
differ in several important ways: ECTs are cryptographically
signed per-task with the agent's private key; ECTs are
tamper-evident through JWS signatures; ECTs enforce DAG validation
rules; and ECTs are designed for regulatory audit rather than
operational monitoring. OpenTelemetry data is typically controlled
by the platform operator and can be modified or deleted without
detection. ECTs and distributed traces are complementary: traces
provide observability while ECTs provide signed execution records.
ECTs may reference OpenTelemetry trace identifiers in the "ext"
claim for correlation.</t>
</section>
<section numbered="false" anchor="blockchain-and-distributed-ledgers"><name>Blockchain and Distributed Ledgers</name>
<t>Both ECTs and blockchain systems provide immutable records. This
specification intentionally defines only the ECT token format and
is agnostic to the storage mechanism. ECTs can be stored in
append-only logs, databases with cryptographic commitments,
blockchain networks, or any storage providing the required
properties defined in <xref target="ledger-interface"/>.</t>
</section>
<section numbered="false" anchor="scitt-supply-chain-integrity-transparency-and-trust"><name>SCITT (Supply Chain Integrity, Transparency, and Trust)</name>
<t>The SCITT architecture <xref target="I-D.ietf-scitt-architecture"/> defines a
framework for creating transparent and auditable supply chain
records through Transparency Services, Signed Statements, and
Receipts. ECTs and SCITT are naturally complementary: the ECT
"wid" (Workflow Identifier) claim can serve as a correlation
identifier referenced in SCITT Signed Statements, linking a
complete ECT audit trail to a supply chain transparency record.
For example, in a regulated manufacturing workflow, each agent
step produces an ECT (recording what was done, by whom, under
what policy), while the overall workflow identified by "wid" is
registered as a SCITT Signed Statement on a Transparency Service.
This enables auditors to verify both the individual execution
steps (via ECT DAG validation) and the end-to-end supply chain
integrity (via SCITT Receipts) using the "wid" as the shared
correlation point. The "ext" claim in ECTs (<xref target="exec-claims"/>)
can carry SCITT-specific metadata such as Transparency Service
identifiers or Receipt references for tighter integration.</t>
</section>
<section numbered="false" anchor="w3c-verifiable-credentials"><name>W3C Verifiable Credentials</name>
<t>W3C Verifiable Credentials represent claims about subjects (e.g.,
identity, qualifications). ECTs represent execution records of
actions (what happened, in what order, under what policy). While
both use JWT/JWS as a serialization format, their semantics and
use cases are distinct.</t>
</section>
</section>
<section numbered="false" anchor="implementation-guidance"><name>Implementation Guidance</name>
<section numbered="false" anchor="minimal-implementation"><name>Minimal Implementation</name>
<t>A minimal conforming implementation needs to:</t>
<t><list style="numbers" type="1">
<t>Create JWTs with all required claims ("iss", "aud", "iat",
"exp", "jti", "exec_act", "par") and policy claims ("pol",
"pol_decision") when policy evaluation was performed.</t>
<t>Sign ECTs with the agent's private key using an algorithm
matching the WIT (ES256 recommended).</t>
<t>Verify ECT signatures against WIT public keys.</t>
<t>Perform DAG validation (parent existence, temporal ordering,
cycle detection).</t>
<t>Append verified ECTs to the audit ledger.</t>
</list></t>
</section>
<section numbered="false" anchor="storage-recommendations"><name>Storage Recommendations</name>
<t><list style="symbols">
<t>Append-only log: Simplest approach; immutability by design.</t>
<t>Database with hash chains: Periodic cryptographic commitments
over batches of entries.</t>
<t>Distributed ledger: Maximum immutability guarantees for
cross-organizational audit.</t>
<t>Hybrid: Hot storage in a database, cold archive in immutable
storage.</t>
</list></t>
</section>
<section numbered="false" anchor="performance-considerations"><name>Performance Considerations</name>
<t><list style="symbols">
<t>ES256 signature verification: approximately 1ms per ECT on
modern hardware.</t>
<t>DAG validation: O(V) where V is the number of reachable ancestor
nodes (typically small for shallow workflows).</t>
<t>JSON serialization: sub-millisecond per ECT.</t>
<t>Total per-request overhead: approximately 5-10ms, acceptable
for regulated workflows where correctness is prioritized over
latency.</t>
</list></t>
</section>
<section numbered="false" anchor="interoperability"><name>Interoperability</name>
<t>Implementations are expected to use established JWT/JWS libraries
(JOSE) for token creation and verification. Custom cryptographic
implementations are strongly discouraged. Implementations are
expected to be tested against multiple JWT libraries to ensure
interoperability.</t>
</section>
</section>
<section numbered="false" anchor="regulatory-compliance-mapping"><name>Regulatory Compliance Mapping</name>
<t>The following table summarizes how ECTs can contribute to
compliance with various regulatory frameworks. ECTs are a
technical building block; achieving compliance requires
additional organizational measures beyond this specification.</t>
<texttable title="Regulatory Compliance Mapping" anchor="_table-regulatory">
<ttcol align='left'>Regulation</ttcol>
<ttcol align='left'>Requirement</ttcol>
<ttcol align='left'>ECT Contribution</ttcol>
<c>FDA 21 CFR Part 11</c>
<c>Audit trails recording date, time, operator, actions (11.10(e))</c>
<c>Cryptographic signatures and append-only ledger contribute to audit trail requirements</c>
<c>EU MDR</c>
<c>Technical documentation traceability (Annex II)</c>
<c>ECTs provide signed records of AI-assisted decision sequences</c>
<c>EU AI Act Art. 12</c>
<c>Automatic logging capabilities for high-risk AI</c>
<c>ECTs contribute cryptographic activity logging</c>
<c>EU AI Act Art. 14</c>
<c>Human oversight capability</c>
<c>ECTs can record evidence that human oversight events occurred</c>
<c>MiFID II</c>
<c>Transaction records for supervisory authorities</c>
<c>ECTs provide cryptographic execution sequence records</c>
<c>DORA Art. 12</c>
<c>ICT activity logging policies</c>
<c>ECT ledger contributes to ICT activity audit trail</c>
</texttable>
</section>
<section numbered="false" anchor="examples"><name>Examples</name>
<section numbered="false" anchor="example-1-simple-two-agent-workflow"><name>Example 1: Simple Two-Agent Workflow</name>
<t>Agent A executes a data retrieval task and sends the ECT to
Agent B:</t>
<t>ECT JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
"kid": "agent-a-key-2026-02"
}
]]></sourcecode></figure>
<t>ECT Payload:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://example.com/agent/data-retrieval",
"sub": "spiffe://example.com/agent/data-retrieval",
"aud": "spiffe://example.com/agent/validator",
"iat": 1772064150,
"exp": 1772064750,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"exec_act": "fetch_patient_data",
"par": [],
"pol": "clinical_data_access_policy_v1",
"pol_decision": "approved",
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"exec_time_ms": 142,
"regulated_domain": "medtech"
}
]]></sourcecode></figure>
<t>Agent B receives the ECT, verifies it, executes a validation
task, and creates its own ECT:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://example.com/agent/validator",
"sub": "spiffe://example.com/agent/validator",
"aud": "spiffe://example.com/system/ledger",
"iat": 1772064160,
"exp": 1772064760,
"jti": "550e8400-e29b-41d4-a716-446655440002",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"exec_act": "validate_safety",
"par": ["550e8400-e29b-41d4-a716-446655440001"],
"pol": "safety_validation_policy_v2",
"pol_decision": "approved",
"exec_time_ms": 89,
"regulated_domain": "medtech"
}
]]></sourcecode></figure>
<t>The resulting DAG:</t>
<figure><artwork><![CDATA[
task-...-0001 (fetch_patient_data)
|
v
task-...-0002 (validate_safety)
]]></artwork></figure>
</section>
<section numbered="false" anchor="example-2-medical-device-sdlc-with-release-approval"><name>Example 2: Medical Device SDLC with Release Approval</name>
<t>A multi-step medical device software lifecycle workflow with
autonomous agents and human release approval:</t>
<t>Task 1 (Spec Review Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/spec-reviewer",
"sub": "spiffe://meddev.example/agent/spec-reviewer",
"aud": "spiffe://meddev.example/agent/code-gen",
"iat": 1772064150,
"exp": 1772064750,
"jti": "a1b2c3d4-0001-0000-0000-000000000001",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "review_requirements_spec",
"par": [],
"pol": "spec_review_policy_v2",
"pol_decision": "approved",
"regulated_domain": "medtech",
"model_version": "spec-review-v3.1",
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
}
]]></sourcecode></figure>
<t>Task 2 (Code Generation Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/code-gen",
"sub": "spiffe://meddev.example/agent/code-gen",
"aud": "spiffe://meddev.example/agent/test-runner",
"iat": 1772064200,
"exp": 1772064800,
"jti": "a1b2c3d4-0001-0000-0000-000000000002",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "implement_module",
"par": ["a1b2c3d4-0001-0000-0000-000000000001"],
"pol": "coding_standards_v3",
"pol_decision": "approved",
"regulated_domain": "medtech",
"model_version": "codegen-v2.4"
}
]]></sourcecode></figure>
<t>Task 3 (Autonomous Test Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/test-runner",
"sub": "spiffe://meddev.example/agent/test-runner",
"aud": "spiffe://meddev.example/agent/build",
"iat": 1772064260,
"exp": 1772064860,
"jti": "a1b2c3d4-0001-0000-0000-000000000003",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "execute_test_suite",
"par": ["a1b2c3d4-0001-0000-0000-000000000002"],
"pol": "test_coverage_policy_v1",
"pol_decision": "approved",
"regulated_domain": "medtech",
"exec_time_ms": 4523
}
]]></sourcecode></figure>
<t>Task 4 (Build Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/build",
"sub": "spiffe://meddev.example/agent/build",
"aud": "spiffe://meddev.example/human/release-mgr-42",
"iat": 1772064310,
"exp": 1772064910,
"jti": "a1b2c3d4-0001-0000-0000-000000000004",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "build_release_artifact",
"par": ["a1b2c3d4-0001-0000-0000-000000000003"],
"pol": "build_validation_v2",
"pol_decision": "approved",
"regulated_domain": "medtech",
"out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
}
]]></sourcecode></figure>
<t>Task 5 (Human Release Manager Approval):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/human/release-mgr-42",
"sub": "spiffe://meddev.example/human/release-mgr-42",
"aud": "spiffe://meddev.example/system/ledger",
"iat": 1772064510,
"exp": 1772065110,
"jti": "a1b2c3d4-0001-0000-0000-000000000005",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "approve_release",
"par": ["a1b2c3d4-0001-0000-0000-000000000004"],
"pol": "release_approval_policy",
"pol_decision": "approved",
"pol_enforcer": "spiffe://meddev.example/human/release-mgr-42",
"witnessed_by": [
"spiffe://meddev.example/audit/qa-observer-1"
],
"regulated_domain": "medtech"
}
]]></sourcecode></figure>
<t>The resulting DAG records the complete SDLC: spec review preceded
implementation, implementation preceded testing, testing preceded
build, and a human release manager approved the final release
with independent witness attestation.</t>
<figure><artwork><![CDATA[
task-...-0001 (review_requirements_spec)
|
v
task-...-0002 (implement_module)
|
v
task-...-0003 (execute_test_suite)
|
v
task-...-0004 (build_release_artifact)
|
v
task-...-0005 (approve_release) [human, witnessed]
]]></artwork></figure>
<t>An FDA auditor reconstructs this DAG by querying the audit ledger
for all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
verifying each signature. The DAG provides cryptographic evidence
that the SDLC followed the prescribed process with human oversight
at the release gate.</t>
</section>
<section numbered="false" anchor="example-3-parallel-execution-with-join"><name>Example 3: Parallel Execution with Join</name>
<t>A workflow where two tasks execute in parallel and a third task
depends on both:</t>
<figure><artwork><![CDATA[
task-...-0001 (assess_risk)
| \
v v
task-...-0002 task-...-0003
(check (verify
compliance) liquidity)
| /
v v
task-...-0004 (execute_trade)
]]></artwork></figure>
<t>Task 004 ECT payload:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://bank.example/agent/execution",
"sub": "spiffe://bank.example/agent/execution",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772064250,
"exp": 1772064850,
"jti": "f1e2d3c4-0004-0000-0000-000000000004",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"exec_act": "execute_trade",
"par": [
"f1e2d3c4-0002-0000-0000-000000000002",
"f1e2d3c4-0003-0000-0000-000000000003"
],
"pol": "trade_execution_policy_v3",
"pol_decision": "approved",
"regulated_domain": "finance"
}
]]></sourcecode></figure>
<t>The "par" array with two entries records that both compliance
checking and liquidity verification were completed before trade
execution.</t>
</section>
</section>
<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>
<t>The author thanks the WIMSE working group for their foundational
work on workload identity in multi-system environments. The
concepts of Workload Identity Tokens and Workload Proof Tokens
provide the identity foundation upon which execution context
tracing is built.</t>
</section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+W963LbZpYo+h9PgaF/hOwhKFEX26E7PVuW5FgZy1ZLctyZ
TEoDkhCFmATYACiZ7XjqPMR5gP0s+1HOk5x1/S4AKMnp7KpdtVPdiUgC32V9
61v3SxRFQZVW82QUdo4/JZNVleZZeJhnVfKpCi/zj0lWhtd5ER6lZVWk41WV
TMODWZJV6ST8kBcfr+f5XdkJ4vG4SG5hkA8npxfHYWOoTjCJq2SWF+tRWFbT
YJpPsngBs06L+LqKsiTLkkWcZdFduiiTKNH3owm/H21vB+VqvEjLEr6t1kt4
9eT48lWQrRbjpBgFUxh+FMAKdoO4SGJYyQUMUaTVuhPcwTpnRb5a6vo6wcdk
Dd9OR0EYRqGZLZTZ6Ft8a57H0zCd4narNX0by97vdO/87WqaVmFVxOmcPk/y
xXKextkkoY9FMlvNYwRduS6rZFEGQbyqbvKC5of/h+H1aj5niBzeFABreDl8
q1ChJ/JiFmfpP2JcKGw+mybLJMOlhedJmcTF5CYp6EF4JZ2PwjSprv+HAexg
mgRBlhcLeP82wXnPXx0+2x/u2z+f2T+/tX8+lz+/3X+6o38Oh9v450l0NMBZ
5NBwCS1flztltCzyKp/k81EQpNl1bRW7+/s68vOn3+7qJHs7Qx0tS3WKNKID
iPRM8ImLs5NXr45HtHfFZTr8JDwr8ulqQkd7Im+ErwoAMx4f4fXxbVKs8ywJ
uzxMr8PjxMUsqUbhTVUty9HWVrlMr6+TQZpvAeaWW3iYZSXfRvE4X1VbOYx0
myZ3WzQA4WN4Hc9LRIHj99HBSXRweOmv8pzxApfXPX7fC3e2d/a2hk+ffxvm
12F1k4THqyJfJoAKZ3EB+LTA046zqf58mK+ySToP5/E6zWbhNL/Lwpu4WORZ
WgKyFat5UoYweFxU6XU6SeN5mAKCz+cpAHECez6wP5y4PxxMqg2ASFZFNE8+
DRJcWQz/2Urm6RYg+JZZvLN//C7afhoNd+lLi/T4T4QoPdq4R91cHRTvM4AX
DPHq6CDaGR6+Oh8Ofahe4n/DnWEfhpgm+P6rZJoUsEcL77KP01UhvBsez5NJ
VQDMJvDABKhC+cL97iKdZXEF2FS2Q+Tu7m6QTK6LwSy/3QKsK2ADW7QWWN7W
5CZeVkkRnWwB+dIPB1tLmDwaDltQZQOU3g8uBuGrPJ8SbI6K1Sw8mC7SDMky
7QgePz15dXIUnZz44DhKC9gLXDc4jeHe1tP9reP3X4lfgEKLuPiYVCXgT3id
ZkDZGJlg9hW+VYbd0xRmD09OvgpxpmmxJcvy0GYIaLMfDff/eLQ5end+8OAt
3Nna2d/fw31P01lawVZhEIYz/A2okM5TuihIQnAaC5MSgA1fdnGe33OHeGr/
Du1EQ/jf3h8PDKBLp0fnD4Fj+Gzr2d4+YUEyTSewyWlym04SPPSj89+xSR7Q
P/Bn0Tae+R+/x3dnx28vj98cnx5fnv/kb/UdcNDLZJ4skqpYhxfLZILUkPbe
vikYGckkv2C4QQkvlls5/NBG+zds53Cer6bhW2KEsIfFEiQQoOGvYDdTvdCG
k5aTtKqIwaYV4BcQI4/R5jhDBIQgK2PidlFFkps+tOn3CNCXGSo8GkQRCDJj
pCeTKggub9ISOMqErjccOGA4HPhGGbF7fHhZ9vpwIiBOVfAN7qDK6Ug+qCRl
eDBQkdPVvErDC5KHwuPsNgVqK5SEZLRe4G6XLtrUkUEbchiOaeSsIHEGHACe
w+JCEEJuQW4ISyDoybQfIu2iwYFTMt0nHIrLj4GVCOHrpOiHy3yeTtZhchvP
V3w3gOWDlJeUfUJCK/DBsLCCIJ4UeVkGLK1UOUMZH1usMkExWNfLNUNrikfP
onMDWIFA+C6tbpqiajiZxyAa4e5/uHj3NvyQjPlIwu4PHy57AQtbfTgHOM7S
xfAwyeIxCggN6TSEcwMZMqvg/4EDJUfKhWdu4iosV8tlXlTu9kEKMlMMAgL8
qkzCGE4P+RAOM1lPAJrhrIiXN0AoD77v2bPAuYtkCSQW4UWHoYLuJEVo81Hd
cyAhrCuJJzeAs5OU0HCZw174nFD8gXmrhMG5AeQGqT+cAAhXJZ4OInIJVIfQ
B79YgHAx58Mv1ssqp+3AtpZFukjxViPiHYRZche8vrw8C2+SGFAJOEUyn/YD
c5EiuUj9EO8bXbMpsxW8rghdnIzgGM/zbFYCCgN+oopgcIaHNogOChDAG27O
TUbUerxK54Rh43k++UgnF8jJAUDhPsE9B7hleRWO4W5WZTK/RvyCKSq4bH33
eBFsgWAMaHPhtUrT5YApyCKdTuegazxBidKI3/D5SXiaA1iYtgF5+d10wUwZ
fv7cooJ8+aI3HVA7H6/KyqhypHUR3WCUqW5AK5zdPIAAdMb6SAAqBVAJ8/vZ
ZQ/ATruhoyhRCZgkeOXlz1CVn6CxXFc1gmUrkb3J78ySy9BZMxw8InYOXxQh
U5gQDngegmAJslhoMVWXG5kdwSYC8y1tImI64SAnnuHr/C65RZLX0H8J/xKL
K/F0Cte0tDQJiN4E2FcVj0E8qtYAl3/P8jtc0t1NHoIAhcQICQBoJKyUmbH4
Vgd3SFTuYmQ8GeAdfZSbjt/GS0BDJN1wPe5uEgKDo2oXyd9XQGQYW+4SuAVC
HnDOGlEIiSjAfs8N9XN5BmDipEhihOd8DS8t5/kaTyLP8kW+Kpn9MBEMJjks
HeQ/ICpyJq6qjvePeHqREkUg/F6CgmIvkcXoMvz//p//F+eer+jCfv5sNMcv
X/rw0VF6+AuV+eFTgHj6+TMKnoBMOJAAxOF0fSbiSPhdpoc7WxDjVPhEi/gj
rgDHtEynWyYJTEHvR3YDMB1SrBjeBp4xB1gu4Kjg9d5gkyDhygmhygl0gzy2
TwAWREtKemoWL8NxUt0lgLstOOqut4mQMoVzpfQsXzCLtIsS8DBOwvOABinA
D0gUfSOCAc5XR1ODdbD7g1LWBnQf2Y/QrM0WDTxWvtNii4J3msJOliRT4tNj
4LhwYHieuBRinMUtTM28IFChJwbZHagE6IsLfE3vLu3ZuTfMFj2GFsRluSrw
giF5ADIOxAOmW4QXKOjgS3jGBSAGwIuOB6EI/Al3K/ow3twih/uXlMzg9c7J
zgKRPEAKHd57Sj63ElnAnBBL24A5AD86LuLAQMOJI8BLHTJdwndpKVJ5+o9k
2qFRYUB63zzDaASLvAQpJPxbP4RbDATnjA/6pz4OCuwNb8m7VQXye/gfg04Q
7MCkb3MUA/HSTx24E1QEAO1CDBv6NgkyTLMQrHCaSEZEqlS0gOPZ5cnb5vQO
lQA0T7OPRD8B45khIpPAJRT5fD6OQVbQqWkEgNYsRYLG1BvR4VgFkXyMeCcX
DR7OQUQsV7B4JOaO3I7aBTwPvNDTyyzTZnTmYUjoT8ar2UxJEZq2gOLgCIwJ
hAf6qi+IOXgLHJrnRd0sxtPH025CRFUDHLSKATBFlNzSzeSbjt+DXEFP4epc
SYil43ICYnWR5nJXLiagMtKrB8i7JgKgDVQRlTCSJTaoWaRl9UKW6cPu589A
JSP+9OVLD94FWdoRpUmKRNw1EvSayRYCAt6exrMIUC9lfZNHEOyGmzr5yOjG
uCqvMMZGrHTwGyciUuNqiXpYUm6osmFwgF0wCpO+1L7IIx14wgibZw8vrSCM
r6ImHvED8hKBHXjODF7BIYvreJKEniwA7/EDkXkAXyYh9BpQnYUUFJvh7iE/
LM2x4ZdwlabI1EA4pn3RMRmZsSZTkpah+ybExPuDCBuF/05MRC6DPryIM7jG
REfh8AuUV6c5ql9hUiKjTcsbY+vwnj0Efo7zwIWcp9cJalWJ+wTi33ki9s6b
dIlX+Nzi66EVnIJWtcFhGEhgJ8CyW/Q92CIc4qIMxrJdQhVX4th0zRw+LbxW
FRi51jAigBZQZY602yokdX0EQLNu1UkAC65BDITniPVW7p2D+3lYG4aIrfNK
YS1hgk510S5AJg3EshQLAWmoAAV4Gw3G/dBeLyYgM/QSZDTlAsRLfCgYJ+sc
fiIFk/COLFl1dV20DGebZqVlUN8cnSXiOtz6KanzrHolNAtTMO+K9AMieTmb
E/jAU4AO/WoUUOQSJQgyJIiViQMg4gWukYXJ5oQ2Q2O6522pEMksRFMCywV5
q2tFg9S6ugB3yL6w5hXiZmRwx2RjBIB8QuLHlHhQUk7g2iE+mlcbE5P0BpiI
hgpSMsyjzGivY0AT9NStHW0Gfg7I5jMVvignVeFVBiyEg8lQ1AJAIDUTew1v
ibwzOEDLw4QPYmvg6WPBEiacSF/4sWAMshVSTNZTCAEcZQY5EfKRWzxKZOXk
QUCOk9JnpoMfAeB3pA90Tt9fXHb6/N/w7Tv6+/z4r+9Pzo+P8O+L1wdv3pg/
Anni4vW792+O7F/2zcN3p6fHb4/4Zfg29L4KOqcHP3X4enTenV2evHt78KbT
uK+E0izwEhEHSZdAXgbmaPGdl4dn/+t/DvdAzP6X81eHO8PhtyBa8Ifnw2d7
8AEUR7mMeQYHyR9JegQhNYkLkq9Q/o6XaPlHAx9g/g351uC+ATT/9DNC5pdR
+OfxZDnc+4t8gRv2vlSYeV8SzJrfNF5mILZ81TKNgab3fQ3S/noPfvI+K9yd
L//8byAfJmE0fP5vfwnqvBIOYMEcY1W2EFfgkCRFj4IRcnVHcVaNrc+Xks1d
ylhBOthg0pFbKyJ5SWINm0RJGnYkYBTWaVrktBNEEpDbU+LqVloWjgbIv0JB
O81Aei9FgUKZPkG3fk5CPVK2IzVdHojp8ntruuS52JZpRS9jwiRgbZLB7hCh
YCaUTRia1khK0mZITF30KRK375ELeSU1K/Dnz+LRN/alKfPVhjmYVO3QWAVo
0ZaosmZfOgS7zfaKCi/JY29I3NLjX+LWI7xuoD8vFiu2P8zzGZ0K3DViHY3T
BEDBgsqEDs/ovn1GOZQOG9K3b4qHl31rdCDS7aGRbhlmjl5l5qazgS82bha0
CAMuWI+uPsPNwFQbbIpsUuRpWUieWDGOmCeSe3NNvimtMGngQ8wC5mYx0Z3L
MU6ybdKdaElGP/jfMkdjilhe8FEHoH9fgdQZzZPbBCNZfNkWbxfJp0c0sbeJ
HOC9rHy8j7MNlrC1iG14ujcxcmizyRSUNrSrEBcGqZ9dI2ixkDgPwGj+48sX
eL1y5GUERFoh++SVAbSKaYSedjg+Hp2uPauqCeNyXGEkR6kmKCuShoSbdA36
jmAbT6epbKZmXEIuy8A4cC1Yrnr0+UlT8yExnd9zfH/BZbs9bJPF21UgH7Bm
EwzIHtKOZ7BzH9NUHel2TsJ4wdFf4d+I5rs//9TpuZM37eTuzA4KiqizLEhA
hdlREgHdPZ+kJFQxqpAVB1cgEje9g08i2sqSaAFkX41u8mVdMbtNY5ap7rHQ
t/Af30Zf54Ou1OligxjokKQTPSI5GhG/ygOrH/tqpmNTZyK9wQJPh3xutHKy
fol1zNq+cqOLp4VnSUMDjzlqd5xHeNQAqghhcQ36ep4DCrWcRuGbNCMrsmdk
Qjqj9iWxJHnWJeLtdC2OjTH2FJ1tomKwx1RACGDCK8nUZuNpzON1UgRqNSYZ
WkFKPxnROmYrDY1BvwCw//u//xvwcZKmcNmq4F+jr/7nX4Pf1Kb5hmbr6s3s
hRv/+Q1fwtcuR6F/8bocdjba2qqmW3TwW596HfedM36Hr9r9VwZf+l1b2rjs
DT/c/m7IodYkcLPyz4F3wL3wZzKoYQjHLwIFeA2DwawYg7qf60sGDRy0PB/c
/I9/FcjhJDxf2X1H3/o/HHYshxm0M7IXX/sm+gkYOgcqlLHsxkaE2DG1dbyX
ftfy4F4Fn0fhk+t0FtFdKzkw5zsTRKy332OotJey80VsqK7DZqU+IiGvrqe+
L3SjDH/4oFq4uPaNqR5/kfGEcDjic18scEz8StFYRPApHaedyxVZyKgR8uuU
Xa1PnnjSwRlKoSUICY54EJFoWsJmD0iwtAEM5cPGVuPfRhuB5VnGrufYm2Hk
H96ZSIKw8zEFFAfRCUYCVS8k9dbYm5hfr8ZwSYRd233B7PnCmky+QTihOGzn
6YCI1xE7E42L4SF2Gy2wgknU5G2kwJMjRxDseRPQoGON87FgougNETNqQobI
PPeu29hi5jNgVdXNIux6IIPvHZD1aBkwLix7IgObF63OnNQEXZ70A3Br8pIT
kV7EH9lhSsZxEdHpPmYSCTAjBwWeciOsRJeXYqRAUaAT0oSR1BAnkCCABsuj
ec9lXjpfdZHBIvjPlxhq1gg6GCF1+DNKbpblHPwF4w7ry+QnEcyFL9igGj/9
i0crHBeAoRi0xNe81YsKJAsYAEkEQ7JVKhWhFD2Bt6DaEllcArI9IAH2VdYS
awzfexAoqsACltH5ki4/qoPMxFxl1DoxmSUFbAhkB67YTWPk5C84qhGvftlm
Ck1x4YEKt+TrpJuJGD5gcRVAmqS31o7YlTPryQhkAWGrhHHAXkq4DUtBvVH4
oz4qx9iimSIC4jl6ShmJI97W+2F6LfsErF1K1sIDYB+wYxXh0PUd9bA2CdsW
jBHcJG99zTXP+RGWrVvvPcJoqiFn1uCC/lSxZaAHj/gHwlkAN2UHFeuOLnsk
bXCTteYVE7PPTxz3HRP4DS8gjraG97n8KRB6F3sPm+h1fOHCvrAPSqMNF0JP
CEZ9XsC24rno67B1eIWH8n4I1dqJVNbYDlBcYKZGZFEu4+cnv+ZwmOKxY3ys
cxsaDoXUWGii5VWGngpV+rUE5fgzHCORW0xautjZf9rp4zfVeonf2Ayif/31
ruKfkJ3BTxxpEUdwNaJ0Gg13djvBF5+28IqEqpiFymaOP8WoyyFhgenRyqAm
XrH5a7R4aaBeI/qAKuR7kTs9wKh93H0bl9jMIMLwxOiUrD/RIOqdI5iYk34O
l4dXRzBDoxjgf+IdYicDvbIDj12sFxjbjN5zXQdo78lgNuiHr3FYBOfri93n
e/h5f7jTayADWXZJdtTwo7jUUdHgY9IpCGtg4qhIlnB11MQEx1iDrGHoCbG9
+gnjd1MOQ1il5Q3HvYTMqJhBolyHOWNln2y+8KwJdbGCx8R4SMizH9IbjgxE
UEMMB2RqOfqaGKTCkt4wS5RpYTi8L2uY83pG5/VebABCaApSked5/jFcLYXQ
iqPKGxoganGvZvzEmwmAOGQHFFzMu0od+fZeLuM1MUq5jmU4zjVONkItHgZD
RumJzCJM+6Fitfjke23PtLgnyLjtoLzMur2lZV7PxK2oogHEaRZgNOOatMEg
SNk26BzdRYWW+HfF+/MTOUi2QJp0gsNL5CIp3E4ZW47OsZxZkdTQL6Tp8OB/
GVX9z8QUI2aKf9n6MwDy5i//RVOmZZ0GdMrVGC8qC8myEl8uhSdwJ+q3ad0J
PPMrIojdCnJjlIiU+yr5gYsas33Akc51cbyKVFUciXwJQ0UH1pToNuGpzNNx
QcGOxF2d0Ebx4CxxSWj6pV2qwzl3Tm2A6ZH1O+ZsDy1IIMvG5P9sOUDxe7N1
Pl2mMGS37PlgeJlMYlQ82K+N9mAkW4Ts5F7k0CqU35OyjGdqLSYWL/atPgMM
vtNdiEjosDJjbOM7LO4OEpvYjY7xril8ZdzausATNEEvMRcjJY0rRXtFjDkd
8P2f4H9/In0RzZjsvgAdN0VU/9OfRuTUFFcEHhxdBaaHGYtoIgmSXZ2CXJMw
w9sqqoRsSmlAZUyM37AI1TRNmvAEX9Q0AqYKsRphhjh0F6PQllYqQEkQDxCP
cXITz6/1xPhGDszG2R2HO5c3bGZw2+bxx4qVPPiHPWzzdZvUppwuvkaCH4e/
5iQXh3Fld03OIbbpIunqtQBLd+KIyHbxbJ/GWVHMr693gZLz2JEvgV4SUqps
7RyTMVqa4CdHOdBlKUGMMzl3ujeyWMoJIJR3cJRhwE//588dQ8ESFn4GsHex
OuJSOvJk+3Mc1rklJqP//AVj5Y/RkqxsjQPNBKk46gRUK/S1W5s3eeVLpa20
AQLnSSZRkMCjSa3B4+rZCDzjwnP8rxRw4QoICw3HlkFYueOrjeNZVMZ4cApE
xZQOHMM1GsjbNNPJES22A991jOSFZ6FxPfZ9upsVWasLdXThcJy5G4/RfjuO
URTA4BTajl4kpBowwjjRiw8PUfB4VVMU9RbxGliKCQ11koWL8A5CWI3svl0t
4KgmR7B1jWtJFwl6BJgpmuUA9aR7OkXxVKUJdSbHemNMkEw/LHNhOHEly0Kh
CfNu8XDoUlQ3iYnxxcgcOgEJz+QHfCf1OJnFKEwAk3lwG/BMKoY32pHDHVrk
a6HsJIHiEcI57eO/hvvhIs0oJIGJBm0HRQSQ1jAPSPawBDUajiybkmc5xWht
FWnY7xqDYkMmiAnm6KCc/BGwRCISJugqQ+yAhYpO7wlCnWx83Qm7bwEsLxMY
L+lZpo2wUnsTIf7Y5XwC3frplMYpRQFs6LRPUEJP5utgBaoIHTW62GE1v1Zp
K6um2OvZPB+TQ2qVpX9fJZ6hEPbtkDZhDgQvOlaX0cLa378H+UrMgCTxYUEC
EpUvUvb1k4uKsU4ECdTjYyL2mLjCrtwOrLcTqge4dJfAznBniV0+Gzq8aYIG
aKT4tWW6Zkp6AYNw5VrZED1DEZAEnhOXRGIrhlUU0wIJfry7AYVZlnmDyvwc
sGMKbABdVyVlPRhzi4PFRI0Qv1TGAzUJ7ntaWlMLnwHFlyHhQefjVChOYJnb
C75a5vV43HhbmUqCtRwmxFnNQUsKjNKFssopZurJkzZ7yOcneHl9LcQK+yLf
U1zMfeoDiER3rJM1xGFCQsO2naMlXkNFQfASzMUITAcAwpQjFpnQoprobDkr
oSa5ji1WBhSPeAXIt+lu4FYlC0rDtEnhdNYogW0YOxyaJAfhRjb+UGSWjtCJ
K9DgkHCx4UPiT5OrMr5OqjUG4E3i+YSyL66mOUq2hJFAOpIRg1YpB7InlKQ5
2gFOFsuTTMOObqwTAuLdMCgBXegbBNxtnk5JO5jPOWvBMEl+pnuACfJKoYpk
hup4QWerQMQyIAREuDA1+B2o3F8SIDFk+MzhvY4gQ+K/E42C19J1/6kokjCh
N+dJK8XbZywlZIqFkW7TfFUau2uipt2DLEwWS5RUaG1wCTllBeNnwiLPZWkE
hiyvr8FBz9ODn1QyQ8XDJIrpEKXcI4liOrae+s9P/MD8DTfpwdxZuElLrNLS
fpMubzz01MANHg1FFtFnyM5qU++4RkIqIWVGvOxM5ikFml9hTgZgFGMvjXZ1
OyS0rKvzSJnwVXjqSlNTXBo3oPWbn+7bCLwAAK5twotB/sCTNS488hJ5TaQp
B4lTY9uTY8KSE5q/86P7eLGWhIrI5NzpD+jRCh17g7t92ry3Z5SEU4ofk+XE
WB6A9Y0OJV7dJmj+vGzbJybpTJJkKiGHytZE34ndNCm83URkKLGNh2fWdc/w
15QPSHhuHxbpN5Q9lhVqwGPrXedswnrunnhAKQOZdQ4fDeBMnCnwMklAL1nE
hSM7bgrmx9aSEKOqWKKbiwViTo2mIGFcjxvDIkqPhrFQrDhG0osVU25ryL6I
0ppIBXwCXSYIINHMLQ1whFmV+2NHSGfpoHX7gBF2++aAllxc4OpmtYizK6Rh
yd3GwzJZDvQ0z/Lrajoj+jgmyVK3ILy1fX/OGVk1hB0rcKLpvAFq1sVinjfk
VYpfyOoQmYPNNifON7QqlcEj59cZdgSPD/b6ULC5Dz9KfxFZp6rpL3Il7OHg
BjFXyMSH2oQpku80v9FG5CNNrLkM9VUmznlmQ2GdAgxGNqdwTFuAQUidiGDF
g8ZAo08L6ZJPXVbROdQWhIoSBVy21BkC7hBIBVeLIVE2h6qFNYiywC5rRfWl
xLS62mIfo2PW5g+YOC3iabJRMBOjJkaWgW5QzFOVVZgAsOLJlk6JJfEDon3p
RxOXiR5YxZRyH6+De0KieUc26IIi+2hfmjKEqBeIhNv3syVzY5Ag67pNZ6/l
qg2I4TNuG9UP42+XcU3tcu+LJGEXmMnEO3ghIZJwDat0wmqgoNjC2BKsS5UX
jskAVjpPNqWhNLXqRQzqJBYHydaGGmUzzDrICyeMRSTcd2cHW3Cz8n54mIDq
2w//dnB4+qYfIG1egZ6xCMt8Ttez7Gke0tSm8LRHcDspPYb7ODy85r0gi4xI
YUeYSXpiUnE+P0ExJjK5OQ+IYponZXN5vOgATd0MnNQEyUcwtAfIZALivTiY
OLGVandQlb3lFSiPN5uVIj9XFp815lacksbrm8gbTrUJO/hcZFyDI+RRT/dW
xTwCjMoBdhE+0HGEvPImjnb2n46yvfFfZz/dnF5/+BC/if4++/Rj8ddX8bv/
vLr8VBaHeyfl9o/D8tX46O5wNutISQ14n9bluEQtHlv1CwCbFBNYiYjrGoGE
ZpyDtwfhW9JbTrTuIED3NY56YEY9N/KYqFKy6I7Zwe7zvY58vz/cofXd64E1
IyDRhqNzaKP5CVjhHJXpGFWZPEMLrrNRVl+IHU83zYYcF8XmZVWDExnQkvij
EryL1wc4pe7v9Gi/T98NtXYJvW7lzQmVo0Lp4zbh+mZFfBfmIFlUZRNL4D4A
Ov5udGO0NvhWq7YjFh8yRxnoeMm9iJaK7ij34N9wycrSsQ9sVgPo2pQYSVKl
t3gN/Vc1wy6U/Rplm3yupE7n2XUqCRz4GbgQerpRCOsJpaAY1NOkimmyz0+c
WnKPpBJO1oH6VanoZK1a1UjMDsg+rxZlbd9Eq5LC2D9Nas+qcPcqijSpoCnq
8EAWM8rNtVcOvfZZMuPiZamMGwSmrsPV1GSIbNa/TO6OJBBI7DUaQckoRXcA
FwNviOakK2hXuKzYxQkqQdimcZlFijPW07qCgIJFr9A49wDmyCMtGvEBeShP
33DgKeG0aE9stDFQpkgou+0B2rEogQUgOF7XJj9o93ie+O5FJ+kFBVbP0ai+
NMenIaInZ8RM2deFCTG0XvF0O2m711bEbohdiWtMYYLHW2+Kg2xv0kW5LmZk
XxFcwKSo1CJkw9/QC/giVBCV4TylhZJbRHKFJ3kk8TVpqbb8VxgUYUisFoXo
OwOpdZ88ha7vROJV2NRT1vyUDCnrtUkLrYJhauWQQUvmifh5DuslzGA1/8Sp
W+fVIEJqmLb7IRCqMmzoDMt6KtBINKsEYa1wCKsV8ONME8GLFG46ipBk6ow0
yZnrFjJuINYn6K0oc9iKczy4C/JwSAEHUwqzlLrLsnohpISc/unqBmQippWH
tXIk4bmminx+4mrglnC6314py6zdnZd5Pk/ijKAt1jlTQMoqjSkrjQ8kq7Bx
wtgD+TI0loH+nM3ckPTcCO36UokJHzcQdIcKQptV3ghuuUb207J7MgZUxSoZ
WBLoYI6TtNPq+O2oES7NObv/Ks2uWI++AuVzmnR6nu33ukiSiAkbF88mPMsA
Of7h41myGCecrKMcF7mHkcsY1+jOkCwtY7gIRuHboCbMVumU/U9wpE0wIDh9
38cGQAUWqgyvgC3hHg6Ip0yj3wFfsAQNlshw3L6lJpgFbFayITSJW1PC8bei
+gOSEGbDxZTyJTTkLgs6yadlh7TgF0T7HGcl10AztMjTGsTBCPqoIZqkEEhB
m5yc6+QSIMe6YxazuxMDmQ1jdfOwSvLYyAd7BTGA28f1dxR5JMZxk6GRczwS
lfVh3qsat6E3EhJ9X7BYQxoOJHRAeACVaSL/qDO1jE6HDRQ9Z086af7is6AA
OuO1KE2NsSnGNRCQJKWj71Q4xXfQL1LaVAZUy4oyUakGViT8gK8XIuLAxEiQ
3npFNSE3axUo58PIwSpDiwa7HuzEjjewgwEZAmVEvZyoFPKxeMx6NoKEvMm3
ibg7S7ikfSHcHOMLo2PMb2C8J5506M4R2ooENC68ubf97dNgvK60MCq+QhHE
mfBK4K3VzaZFB80B90NKRi5bgCMPi/vUdZ7SkCxU8DBasYQ4loQpH4phjS6K
hPbW5fDUjV3wAiTlCOthyRg+N9oQDcNRM+r2EO1yNf6q5zGI4/7n1dOnJq5R
OHz2bGf76d5wf5u+RNpivnwmX6LDC8bd399Onu9tb0fJzrfjaG843YviZ8On
0d7e06f7+3vwy/YQhsY37iSmens8nOxMd6Nk73o/evrs+bdRPJ5Mo+R6e7iz
u7eP33RkXnEcjlBLwlK4IGQBQ0niyjoskXaOwp9/4TnQnjVyPEVM2dGerSxq
p6Mcy5pyR46h2PyqhtKN0OMRDbgjtkTZAYz10oHo3j6v0+ifowctHq0GD5pE
lWh3kDeH8Xa88+vVp/xqf7H9/vnry5cv3758e/jmby8/zp5Fs+inZZJ+/8Ni
/+menHhD+yUAekqqOQzRE+GJHdwJ+XN8DQ5fXiRTLArF73nqkXs2kTmb6HZv
sGOQxOozeK7B5lgxMm5viSpSREPkzb/UwvPRUBch4ZEAfe8Kn8nNdKL0n4Ru
YtClKST2+YlbR0xyjeuZU/LWKyTOrQZiNQkTs22+Xi/6G3CAwHC4rdJyo8Kv
8hw2+kqojzuGmLhSG2CBhZ8/XGgGh5+oEbjxMpz0ocorDSPB8KI4YgnHl3WD
HrrgK9TLMBCedTJUY9N8GnY7AxAEJzcxBqlyRuOB5qyVUtM63pivpl4Q2snm
vLV6TpVbr9nkmUnmGtPi4Pvjy3ArXqZCCSNyzdBxbA0Hw+B1XlajUH6jpQwc
NAxaktiS9Q834+8n6WAwwODrwaC5XO8h1DvhoUbOmkzj5axpWh05A/E8GetM
7lo9PpFFTcroJh+BsQe5MSsC835g3t4IX8aqOeExukypvBKHebNKH2Da4JrP
UrHgQcSzfh9JwCsk4kmj2TD7+qG1YdxXFbDEBth0m065toGESptwr6XYKE3d
NTReff7sSsaE96AnoKNBYEReRypp4+emITaa1TrhWcZpVhj4apg9F6jRqJCg
HgsqEVHo3JOBp6pSmDg1VfvI0ScDyjheyrpNVVRlsRZx/U0Z+K5VykTD2Jcf
TSk68lV4pR+JAr6TBjZSZoEUuji8r/aRhKTSSZAl0o13g121qUdhXT1CsqoK
qZarJalrU9lAiWJBfbJRUK4fUFV7Agfyk7ww9VYznsUDtfW7o6zKiBWQLqEa
IkrQIFgAyopHRipLG2eRuMWtyUgjdRDmFsSkjNoK2DNUJKpGALqkmgQ2PJGf
oBCMis2tFFFH+NEekSTSrXPc5xhNLFfRQRezY3EFUshD3eBEN0AWTlqllY1r
GyyrZKkFfC8Z97EHh8QMcsgBRzU6ud/jRCNDazmkjjGYq6R0q5ukJZKPGBLJ
olKwj1+Xi2oiEMlW4kc09pQkmKgS43VgKYXWqtGXXEfXRgZYSzRHXEh+qsSi
UVlcvAcjbjBVD05T06WqQHglAhueLwmRmvfHtJ1DBClE3qUD1v5NA/Buu0lK
nNZBkbp3U5MtCkOU6P00o6pvZBswWGWNFj1LR10yJwV1Oa8D9O974YQ5tZfJ
AgSfeB6+k4sr+OEEg+P9Jti5E0lSfagJhzMKCbd+/foIdNmlBjUNsJyvNDSE
hOLZqrBh1xx0XeXzhEzEYdcpnzcKd7dD8YX0BjTAJR9Gn2gxEUFe6ij8L4k6
gcWEfwYRKZ1P6W8u/UFzXeFcV2au/9LIBzO5xD9xmqRdHo3gy4kvMFba5JPP
VsCjgY+SnS+dYOHWVYkdjATSfErkI1WNhltLYCTFof8sm9DSRVyk87Ub7huq
r9+vONyVs0oU/133DKFmry+lXWkQu4J2vGILZCJ1ypmGx6kWO8ARNuDYHpqe
mGGRCPfKVi5EjMB2CQ6LddiWGlxo8Dlc/ZBMv2JtU1SCWb8pmULIwrlSH/fw
qGgVHCN2zz3Yt/RCIjo1UHBUgwVFImh+ESPvvbFvgDDtgV8WbrWd2KBeI29N
qKFBS9ibjXpzQt6I+rrhW2q2plcecl8LEfbidTkyLqjlXeFvWqyVRUuGEW6i
EQ9nSrpbc4B63WunSZH2m23EoeYek5FYpBaKeKVwILXJmqQVe25KafjsvIgv
QIGnVJncltTDwHhOT54A0p654pMYu8YJKkQ2aj9kN7lXiQ35YF6v3kYMjuOO
4vCaGuKJfyHkAPhUqkQjJCjXwJSfJmx90pAiTQBF3Wi2LJPVNEf10ZTdLQ2x
cCQGI7BLxRH7XnC9ytjZYgLYQWLtUllelZTaqGgPy5BsbYUXIIuEw5Ejf3CA
HvqkrrVEg54KDjuAqwz6DvwBQkJvJFABmgZgKIq86FItAJBofHmg0wucCXfM
kVn6RzZQZXYOCSZnBrtUUuLJODeFu9ugxfA7Xeosqbrm6R4zakO9ENFX87n2
F/OX7QbHI+El9jwKO+G/hpsGJE71l+9oRcS0WkH9uOm8uDu5bz7QdkfhIZFO
k2ATdlkYK2I0M1F180Va4SKxljqKTd/hdez2KESGori/Q6y9IhLsn+YS48QU
Y+R1Cd5t/LOIP11RuwDgU1dmTgCLTIJFR3CXLDPpV0gR2vDlMC0wzaLwC7+K
+ZtTw9g0jYEiQWBep3jsEsR1cwXs1rgd3RXtzpxeaTbYti/dM+2OJifshl3J
LwN0AHR7eODmkbb9nMaf0sUKNEKBUP183N20oLdd7sjHNvz9u+9Cu7UaYiF8
m2+kma5fHxfWwM/q3uLptH5vvvpqARb716uBcc1j8fBuA7ptOB15+vFo58CK
f7a4xK581w7l6/1qiaoR9jNDhzsSmDSp3VA5eyHrBiW4CjLmq3DHJWRRrvT9
jZoENCqW9fBPXPg1fNf9UU0KP4qJU/o7U3i+zpLl1NoLBW62hGjFsdapHJvE
gGNBqvWSnLe2mw7Rm/KGUjKRSZXSLy8tg+Qa++Ny+Kr1pwEosjSeYzFdrSGK
5o3kU4UiEUULA2nLC8xLS2TEDaEcIlRjS5faDQvqN8xXR4bb8A8DQ7QyUuvo
SVg4wcfaJ+onqBYQR6U1EkZghNSNPrcJDt4YlPGvDNhT37ROsCSjSWLw+BQL
3maVpSVkvHCKFiH75HpHP7qO7s9PPOseGzzcB85UtKgXUxNlt7QGj8qzcYSe
jSPw3Otk4aiXygKOJ/XrNltDYceIGrFYn5zaR32hSWupiQ7btfVb8IxALUMd
EG2crhWfrQ0/1nohUAkktezayjWYGVKrmSNqeGMAKmLXNgCSQa4SxB1OOGWf
StaGZbNokKhgZvxESgo2hnZUrzj8mOV3mTTNYMD4VXOkDLDjPK7Vf96n5AtY
SnLrVin0i/OwyYiWY21geoIsUpsjqMEdzpUxfX+wI+J7HYRaJnDTlChekwac
JCp83wKCTzfuaoP2pPIsq5gw2zclDWVwFTbgdgR0x4RHP0q3LKdzjGn3IkGu
k4S7g6Me6IyMpqt++O7w4oyRF+66BPjxFOMVdssJV0sU29FUEjyrYUI7klH5
G+UotSJYokU1KyU+rw3t1JZ0x3NLzYhVCN5ni1ut0rTFVa+O3rf1PdiqL17l
Dy1s8Q1XsTCdJ4mn21opnIpEg3CiBhn++lK9oVwp1zF4xWKNHbxRHiMuKTFR
AjBfiEfEFBPko2L3m9Qe0XRBYzniugB+HkKczldFwlr8B1VvTfWOVA3Urgnb
WhcZCN7eGXltpw2CAcB3uD3w4EsBUBIWakL2lFPpHaKwKNJOh0P/dZvbY2og
ZKbIAhATnpxV9ZKNBF2fQZvQJPKMljf5HOizw4ANuxbY2koQPaGQ9057vSJ/
B03ssfUMm/Vw58PMMTmGMV4YG47uIYMRfNIFxvLkajusmQ7xLg53DKDYISVu
DomP6pJNq+8YhPpStoByfYgmS/Qh1U5M5vOIfRo4NrAUDMajLCSyQW1I0+17
XXyoAkPb6PRrcxDJv/VjPNxc1P5mAxiuEhjTmTD7ukGCqH29LRq+s08741ar
WLCGQvaaVm63WrK5GGJKlHg6sew1BAt2Rm42nGs0VSBX0jwwz2czTZmle7hc
Fcu85AR3Uhy0hJUbXcXJQyYI1iB73XlpOjnaoMA+JwKzIOyEb1LDlXleEr1g
satR9ZQ9riCYIQn36tnaMieuD9aGqptgL3aJEK2mAfa2d8MuyPXjdAo0poea
E76PgkIq0Y6UyGvjyGHR9DXLWzLIMOi+z2yys45jSv82S+rxZiRVidcF5HOc
T9f1RM84hC1giqNockLRsIst53IFNpeLTXTmPNrxhETzS9f7y53Ga5m4YucU
EJvqLmynrJ9NcC1ppQ1Z2prlNpvp6D5fAaai/eXqV2zTogQK9OoNOjAJDBJp
dAV81pgy1I7HwjWLZV2RmK20bI6lB+r4Eh/FiXUBamUSasdvs+mD/x6AtBz+
y3cN2dizfvD163ZOGGVQebQyCxtu7IAgtqAtQ+RkPOjyygjHXftQr3UK0Flu
0jEZuIz8Y2xlb6T0oxVKAhWPEXIAgAYwybQhk35k2wZaNuw7nuGwtpj3GQnj
tbKWnRpQzQnw2MjwBBPgAK7Mr42ju8ckEnoCeN9ZbzvU9GDMK/U1UqQsNYsl
OZtXCgcD31/Jdw6U+k04ts974cj5xmQu49WXYMVZWOqMsjsCyv+HY0PLEfx1
BWQUZ2semINbgKzw6IBqz7YsyWY0LkCMp2qS0uX+sr4iKXKpMjISS6kWKVjC
BzWA53RWqjjZdgA8lJEieWJnxAY0RP4UM6SlEtLtz0xORSBbZkTKxY9Kg0NT
YcTUe6zP6UiL/gbhS/TQsgBFAZHd9vNWuVNGaQA0xgqLICeSs6HL8fZ5SFKj
bMuKfb0akNlL7K0hjNgePUuujPy5cV1ceI0mJO9QPMs7LXP8pT7HfZb9zdN4
W6nDoSZQiilYBfnw503y5S/GLMzP+qhQswnrok5TrovmT8reDfrTLE68SLWS
C918yVmVXOpDiy8uYxxMACjlVsxS2gTb2jrNW/4mWt581C7hFW27Zl6VtaLk
bBOCOo75mk/de4UnU9L7s+sUdWXndsH5lw2LU/LrzUSKZacBfJS2uxr6ZONP
JOTEyYzxPDueB9Dw/gdt663uwVZ/Tiu+1zQDFrrMlg58RSCZvhDRn+r+0dIC
I/PzL7r0njXPs/Pbs8974p5ThXyDQMYxzm7LPcry5RbIn580mh47nX5NG2su
veuGB4Hiabv0efVRsfCv03zXWy2jaFlFN/kEPsTzdZmWJsLPDZwONHDaCbLD
nGjKVNW4RpnR6/e+wJqHVRLEVj5GQzkQSW5bnIMutG4zmB38RAk0TiNCVJtA
3MQ8MyxiULY0vkf76yKl3ISwhNMGNaofuNU5eIklqZsUWSprqTVONjGNrNY0
tixx014fa28DYqDmYcTsfOBsxZTrGIXv2Oesio6eqjVzc9wUYfwin7JtktyS
VP5R7Mp+UJasSWpUS1WaGPCmciOFuL0tDZxgcHLCEZ8xtmzPqzyTGE5QidAg
wjmA6JuH9bKPR7stgKALcu6YSnaDCtpcgxZZMK4ZvE9o8pVoEWm0q6tAyyuF
8hFVEsP0SWvZDW8u0eFMCr49Vra65p4RI8vNhJTSR+Igt5BXy6JTWJfqH1AU
Ukmp4knxEePCi4QNps1VjBMDejYmY+kW6ZjYKPUa2KhWrs9EEbDY1tTLxsRc
txUV80Ei8h4UrUO6CZ+fwF2JsKBGqU2WSjF723AONznslgr/h/QGPLLgMC0K
4rnJ72p9oetd4pDgtOc/s4oL11bi5t2xWS+XE5mUL6RvqyzS1FwK7/LVfBoY
PdyWUajlH/olJeoduYP2jtyaLFqvPGja4SrYuLTUGFmpVsQLOPlXa5udZM4O
+mRocpCWKbYhHUSxA6w6qY4ht4rmF1bhT5MpeTmPEnJPXhy9OaTECcSLIDjJ
CKH5kSk/UubX1R2zhttkni+J8Fn/QBeH6PWDgxPTbbDEWCWNb7eZCjeECOSw
ccEaKFMItS9VAVQH67awJBLPbeksr417GdjmWp8/vzo6iHaGh6/Oh0PHITMc
Dobb3YRtr58/H7+PTo/O4XdZQOCWzjJtik08oIaDuztXCwoelgGNVtL1QYck
HLm4tp7pYh862AqXMSN9AgMbCFGi7e0hkgCM9Ql//iXgqmJUKVQi565coF0h
ygXUkm5E6CcCmU2AI2nHq3oYqmQnXZjDl2H3EKOxvkcrFAK3saQduyRdpL80
w5GugG2s5okuCaQQlBW1HHF5dbsrAtj9SzoMu5do9qNPjeXsNpaz4y9HOvpd
YemDq3KVVmZB9M0EC9eg7mTKST64oKOw+3KVzqcbVrTXWNGuv6IxvnwlGH0V
o+ssJm2aVsW/WoFSz23zql5TLOW53JBTuDvUUNlf1X5jVXv+qmQ8XZcuxyxT
Lp7AafNy+AdTbC40GXxwEeAOaAbVFukMWzJ8tJgV0d4OmzpsWZPw501vcwrg
3+PIZgH+4onHkooYldP5RMXj+whdRyVeyRlxUzuEQXAyB91UEyzhi18BlRWX
DuTcLZje0q6SXjaHeRW1Ubhz/BplThAOhIoZVL9OdZtp3zo8bBVEPvoFHz0W
NadoZo43pWMR6y49JwZhPx47yUrqtJPlAVFlmrT8mC6XLPYVCclvEuD5JATa
KtoESSw42LlNnUFYBEdsu4/DevNt3AINoOUb1e4MahayfvFD4pI3kNnQleuV
4nrbYzLO2T2cE7NW4S8pbflEbCrtVZFSgShwi3tTPkjPaVjoSuB4HE7WEAvv
hk8AYCTZ0JD07ibijQofdva8DQyt7dapaeOZXZAWGySu8dRe2G0nO40n90Hx
9klBL/yZ8MzWwZn6d+16GkfCNfmiOZiAJZYAN/DMDMporFjReMwoQL56ZbAC
0Z5aUVI9Zouo5oKxvOtEU3Avlso2NWaRZABjnNXrcepttbUTK00soZkoCzdl
gS6qlcYyKgoXmzQCeBfEfXLG4PfjNdsAevi+1nYB2RKWF81zbETtXtdr6nEs
h9Dne+ZXHGop7EMrc7I1vE5LWr9LpUSnhi4lpeBCtcLlJM7c5FGQJB11HtdC
5/CQkDWiOKcVtsmZsUiRTL3ipEGopFbILhVaQ2JIHmryj9fqkXJRtLwY0PxG
fjvIsuRTeHICqhlq+Cx0ifgWayziJNFGz9cmB+x+adbMcnASHRxe4kRwdVDM
He6MAJ+rHH2aE3KuUj22eMlTiIkCJrhJZzcR6VIgEXMVVfIs5vNbayRtoXT3
TL03Yvo1iVU98i+JqcubUwL+7IYwGVE8n5Bpd6quVYcx2HlRLXgF6JdNsFj0
ZRFzII2vFFybByp5QImn6XypoXK0+ZgaueMG+5tMQ8LcsHKQRds2fhWYeru4
WWc0sbXVLrJwaxrYFsGry+LndERmlY+Xxm2hfNzoFfBf8m0bGQq/5HoirjD+
CElct/X1Urg41yxkrBiu31wRrFjifVgGN7nX/4QITuCXdZhTMCDZvWcdHrsh
vDPJ8Zvx1HR+fiwtOz15dXIUnZx8+SLXS20RPjtS3NP6yLoTpCXKBhgv48zY
oIh5iFddm4NZ/s9X/ejd+UGNwPAt99Z+gv1PJlKEUsjO/VTqjdAmWLDClisi
I7+EN6ZFeksxhkKcbNWb1gJrJlffvcVaAYwS29KS9Cqk9dTrxoCoz51lWkxl
mnxdTN1C8l51Le04QzXDa2nfWJjAJN/ByzNinoiPD9XdGcfZR6tXUGEcU3az
bC+984hX6tV3vFf8Zle1+jvD/e39Rv2d4f5w+LX1d76VajpSfme6i3V34qfR
+NnkefTt9nAnmibX25GpvQPfNMvvpNQwQC/vlWb0eSV4HlMLaLfzi9bH4TIz
Tv6c7eTwz1To8SDM2qXFzyhHE7ACuz17b0SpEm0PUJG40SOq3dWK0HjY6xSi
cevFuUVoLv2iB4TTtuJD7R7UkT2gJfS595Uk6hOh4axlSmQlDcbKg2JdC+zl
1Zu75utokjaZIqC0k+ULrGUIJAUbqU5KIBNU3JwVYJYM5uZHKxEYo1+TWZty
FsKmMbmQ5CDrVmnVWT0ZAFQ66zJxpQDTsWpUZ/c5EtSzeZxheMbjuf1yjs5O
fNkwePzgWZAeaWqjom7l7+Du6unksnClYe78sWbye5i5X1CNm0dw9g1SRlzM
cmkcZCyQ9KkBlAdNa2fclOgRZrWdfthuYDP8Qzsc6Zrkoy9xbF7TBTc8QDlM
0LCxqgfNaozCV4rSjhQmQz7G8OjSFHu3hKDYm6hyD6uKZ3EBdyKZU4mNEsmL
U0qX0msQ0ZCv40FTgADrlpypLL1J6CLgQyDLiOScSJYeja4lPPCAnMaJOFy/
5uFBbQsu8DdYVoN1MKIxGserI9Z6Z2hzTe6YQTk/UjaWU6A1PbmsOaDi6bTg
8kFaZpaLWJnnnTRkXJnWCcXNUR7H7v7+jrpILm+QqIanVKW5lsNc8W/xhErI
xEVi5iGSE4WnMVrjkGhy5GU35Z/lTdCRTTGsemYHoIskZXM5D6/PhLaZpNw9
pwcByoLIZYDWp6UaPNBKxP0b0FoAHBy9Dc7EVA2RaqYSWfNi1fKx702sD4QT
SkyB+DELGlrzDipMa9byx+RLXltPsg2CUK8oi4wAg7XjIFVjhdo30NiZLtms
eM9k+lDiFJAIyCUbz3EWWKzUWWpWCOKjv8BKxAdayDh8YwoZh5+fbC5y7IRP
1AtVuzqDxixrlzen1HZwxz1OgSUbm69X/5pjMtgqVJV6dpSEEoYHpGErBmBk
dw0JJ+juFBSSboI4EuOSrECye8qkopXWIpKwv7rtsmPa3ABrRuwMtImGdjUn
Kocua5pMCrB6jWhdLzldHMr7xKV4x6MzWEtGXBp381Rea3ZZobag3Ad9vrYF
luR5qtm/JQ0G0OeelLWyOmT3pam5E4CWJ9MRtCS2aRJiaziRcbmKbVg1kxC6
4SAg4ZVHK55EI5hGIoaYVs2HA9E9NYfMYJFTt7tZq1vG7gftbnS38jPlxng1
GZ2oBqwPLI5yN6bAqSivheKRIlam0LhtysP2Vljw6/wOTaz9tgk313q3EfoY
UTqSfNbSqRWelM1C77avdEWpw5R4s8nULKQ4dqvAmRQrO4nFRq2MT6fFZe8P
snoVfQoywJU66+SKxBLUitCDi7rEDkfsafkgRt4Dp3o7MSIgQJsLxnO1YuaB
jCkerQotrTLlej3gBwT8zaXvK61A7WGAUwI/aOuaXS+E70BNIKYTBm6xehiP
OSkF9SSVZO/JGPJGLY/OaajtvmjL1yD9klevnMk6YZf8SxL2gUYR9TShdgEE
BeVAM6jeg8ZmtOqPV7lLkvcw4g9UO6WN7lbbLBj+Du6jwnQxpSCPA5pASlgV
i9JZqCp2YszRRbfdwTnX/uR2S5R0ZvCiH5jyeYIhbrCTn4nZ4q9gduDmDjkR
hOyV8C82IYlGrQda3qqFetAt08LSUijRxVWFjXRydae2oVTX85hypsRYroY7
9N+po4TuG8IX9s09l5rNFjgj2SdjBNmAyu80CxiyUZw0dwn/M+4PXuPIpUM1
Poq3sHRuKJIuk94r34GYACfnt4VXfVobHftY6PVd3nBLxXL4rpgBo/iHdK4J
z0AgxLuDFSxKEQDYXuaQ2XGRU5ovpwabiB6RjEypMmM7nErgHwtZpLIskhiZ
IbBfW1/JJujn/qLIpprP+XXUL+YxBrTDVft3EDzZlU5GiBnaQ8jiPKJuxPQS
tTsCoZktxGxQJRLPsjM73m5AFeMP3A2xknpeRlq2Lb3cSZyYvrRsBPMF4eZw
vrAWzud4OZ3sbbO1kf5Yi0iTlgNLbuzCHK5vIxDcPq40BevuTi83dzfS+JH9
a/iEOGXtvjDUmoLM4izTfsukFFJlS0ZZAykRyk2anRvuLKil6Y6uhFyphPaN
JynLtcC0sWblY5vLZ7NyJLS1kl6D5odAmIT15+lsmH3e6OPtVBLAUFhnJidA
BBNjnKoEbldNTmaIs3Vgeq9smqGl2IBXWOCBogLUnIY92E/bquX2OFH1vrxH
ity/bl2Fu4J7EloTqtGJ4SxCftzM1sBktuJS2gogoDzrlCij8hvzdFzErG7C
mKaWnwm3MI0CWzfGWHjO/d4PSA1GKnfL2nmgPIVFg/KGYpBtYw5SRWvJ3PuR
mxYOF4/LszCtpV4dTod5Vry1NI5bYUB7imFVF3oU+MsqM+lPJuupHJnYbzc1
SiyTwFe0za6cAPqJ2Fiokzp581RIlyJ9FQVh/VILmbshkYEWHbCa6ISg0jzA
deLm5zfNvLbSrw3Kld0JUWVrGe0ncLtWelWFxUrMRdnIsBDbEAgqvMmVib36
rmprR0+eIw5wQ5ScrDFmNZvQz4mE52I4+TWBCnl1VKL0wk3EJYC3yqVOjgyr
NaCdC+rgEiPHIHBaHqPwuuJ2SokbG9xWWRLDf20Mymk6xYIcZwaqvrZO65kk
thp9hMsrjIFtEIYuAQ7oOcBi0x/w8s0FCZD4X+C/GU9SapULCpk14KcK7oEU
TYqq3NRPwkPPJznoP59PoqNBmlTXESfmljtlpL9++dIPzEKtDRBraGhhPqdq
YcjJ3aec/275Syml+Pd2MLrFuC0zNh9lHNKOanEGMuA4ZTHXKMqCzlNAyQyW
B1Dmom4sMipes63jzcUWwaVrF03Q7Y2UsgDRTtAE8DGiPidiaxPnLzCLrQ9n
l2GXC9+bmBk7Rk6Bb1xQ35QEyaZBaBLr1W5uAokQo7qu5cXts22GPhex8U55
DU8ypco8SF2pzQ7/zKIDIx7KWdZOKfUOWrl0yj4iMWdR+KDaHulmAumaJYFD
arhoCDX0JQm2MrW/8NcWWwn1EMQ4DTqMDaWsqCPWDeE9mQyNoFdg5x5uE4Rp
jAXXVAd+1b3JV1xXfBpjzjqlJoEMeVOSBnlm9+iU7eTytyRIvI6LKYUmGZv3
KUUBAvd4fXFK2W+oJRm9lPGcgSY5RmQwdRh6rf8o6BzS0MgW7sFX3i+p4zuK
NZX44Rn8/aaIILXvkYtLSJVrfMSxucxJuaKOkMmdqc2EUUSYskoPYTKl2gdd
2S1uDEfH6BdX9+pOqKzk1CIqEloqpyA6fbmMzrMyrQgdOu+rhVj41V2YLZ8/
X5viTLC+TtBSYkNCKiSRhiDyimxyh2xsDQ7U0tQw1QJ1oXqcgORe1Q1bEQvW
zCV5asmIpk27zwnztmIdrjHOcdbOJZ1CIrrYbmxY3xwkULYhx2JitOSCobwW
2W+tGpcDUQDKKd9AumYiMPEVdJQbAT/x0aSpJLUlPgXhQ6lPbbrSh6buPgrf
m8JYraYRawslPeYBayj5ZjAJxsvfHIWnCvC0uW9ku/BgKUKIXK+4EJltYgsB
4+jvVhUWGxxz4Cug4IiasrHDRi013JfFtTWsrR+G+oSQzibKCIgbTAUMyJYI
oSITrD6iEofUcJRZNF3iTTqBEPNVFRtPFpzYJwxvAKoacPTxpxSULJT4hwvO
XMIBMZkZOGeBhU6FLiIAji929p9iYUNA/sBB/gdLRobNkpHBxpKRjQLgLziE
VEpESk1IdHBKDXJMGjYlIZuioWAtFoReh2QKIYmfrhqz0YOzE+axKE5rFR3b
lI1AjMbYshQhqnb5bZVGp50E+dY2nIwpt3gXs5EWKAfwL6Qv8OsqE9pHidjW
lWKSgz8mihAmADk8QB9NPFmb5ArxLNsI5S5pEn0OduoxTOtVkAfBoS2671e0
p0tB1df5IvKybP3kX1fTmeYI3sfW19nkpsgzCjrD1YW6c3GCvb0867kNurkC
aPxwa4DgntYAAZOCmmXKy0okhJWtlsvYafPDDmJl6vXocG8TlNYsvACzRtIZ
VnKi1Qb+ahGLnOnFaugye1sQXPmlBlmLqUYhQibOllYJrItYUAacekI5Gdb7
UZ8XqRG2ncol7nBB+KqrFodaHW84DgjZXL3FCiIKPiu14oLWldbKo4F2boqk
aatH5r21VlzYIwyrpGJT00PTiUAtn3RSi1r/AjKSzLE6cKMJJqF4INnQidcs
DAsyb8Zra0HgriHcMYQMzrYiXYjd3sXzjnqYqXTL6ELqTI7tdhr9D0zlqorS
Ubm7d8ERY4iycFzM2KXPjdgNHm4KGVJTSDLhBk6nSWCA1B7SuYTOi3GtbWR+
HWg/SDZhSV/iRk9SsmA9YVF80owpQfaG7t5jielW+6gcZkYNf7jpBVfmIunl
wFWz0MjUJY9Vn201TOVq2pQKivi2m0K95DPtWs9Vz6ngRkkUJsSNTPLG5Os4
v/NVBc/QOjAAs1/zIvUkUWFDVL6fUvIYgr2heoQtJ8dQYnc6+d4R/8X9Tu51
MYZ0xeYwbam6EITqqcfyAbazImGI7ZHYI2lSJCBH8kArizFPuqhLxXtJO8tB
CYWHCqcuk3l8Pk94+eqfwTdAwlORRkzq0nnHlr7rnp2c9CxenTqdi6nbVr2b
8UbJweub7M6gXdkUVQeBXDz1fLLg+ug2zx0xOWs0Xa2nM0kSWHk6zmYrNJ64
eCtzU40bb1rbRnjZ9EE4wwe2E7RW5GHxVGh+ez9nnqr7+XNbI/AvvWCq3gVm
OFR9H0XajKVx1aa4xmqtBTfaTLAfs4accHwu1vBfYG4zkkYUKI2NGitc88pN
mG0/QC9iimSfckX8PtcmlJxkgUpKB9Y7GddtEn33FKVN+ISEWXOMv7NXd9A4
YUwwjTni11taUjitdqlBXPvxyOWm4t/GiOqiMAh0H2GiwLZMA5FEwgZs9QPx
BUktFbz1B9QRQd10aksw5hQ3FsE1uMT0WiQKKvwOghNn43LTFpuPYDQozvqU
vFbNw4rJO7EYbLqyGhgIDJcoGRkCKjLaEzBEBdPqMFIu2McOJ5kWiQXA4NVq
rkQUV+VS0a7vf5fgAqGaQh56QcPypN0b52ur/4gyyhYZa4hn0AXqTcVSi1RY
RuGENyVLmPyLosklTVhQJ3V7vKoCzg7U8XSlLivQDgvUOkIdMAYWB9ILo8l3
rpW+gwollH+8Dm1/bM6h1gUH/sGqSVstv3rHHMuR210wMJKnlOHy+fALNoTg
8hpV6djTF3iVUZ+EJwdvD9pkEkxlj8PL9TJBIKQcY8uBZamtWmHzqgvnITWA
2BBW4nyoyiaBRqvYCcqOvr2uOaNxccDIaRXYYRw7u0s3Pl7MxWpcuT/65TOD
4NyUONI6mSU+hkUxg+CdVFxr/fE443IStZhefOD5OK1eOJWN4vCHDxK6JZ8u
nGLnUoYfZAmvEL+0V+Q3TFIXAK7R9lbQk3K/mp1vvZ63F+2ByLjoi4T5yIbY
ZhPVrOVl9ITRsIC4TTxDJMnm6Ayzs5U6QL3iNPiAhzVBcGAPUSzqHBKI4QgG
VfC95oPWgWpjDEkxSidOGw2jXEis/EoMNtKgFkCmd8jNFcbyV5byOPwCl3Ia
z2AKtuh0y55sOgxfpXNHp3J/OcVZqhyI0TU+Q5iKR2qfCVig4yzqBUraJqIu
Z+o8YcJ9vSqIcdbWdHhTYGg+4OLbJMuw9hYgFvqr/kemnwdYK/dECcEKvU/0
5rvT03dv8YawP5cAjEYYfYDXd0CcacNUQXAIfFz4CPE1evLk+PIV0RC34TW1
rvZICXa+pt8il3Z8+Z0UxuturTTm9RoFZzxx6rcNAiG5Hsm318XV9WRdb9ET
K4tbd4JWKsRPKqVpdAqG20d9DvBHmBXgQ5h+4bfpll01rkQfNEe3Dzj3EUG6
wtb7OuRY0vxDICfhwGlGQa8dUoE/JGPpdcLTP0Shf+PnGI764ciK6fgdo8qh
QRX47tzI6L8Fv42iKBrRv50/R/ADUPUpPGyST05s4YzfCNngP7W6UzieyZGB
n1nh3aJEEuIm974IVBZ+kf5h3D/W0R3ufxUw6zfVj7HZ7YbVMuduvGvrVv5W
b8QIwKJSkY8YRLMX7SDH+o12En/MMMaG2rKYS+e3ewdSpRmfIwmSlNLX8o2+
SVqpCcHyR1A9Gx58x5LnVw+Bi4AvytLeRG85h43fHjMq4RcC6WqBWGEoAqeP
dBdlzx3JUbr8YVyfD6K5uIhOrG3nMaMYZijloul2GeH1SL97eCAKHbiiog4E
ioOTrdM3Eg/+o/n24XFaU2CRDriJpq/m8cwdrVWbbhuOtM/aYOf67SOGQ57w
G/mt2BL6ju2F3t2u2/HgRcyRo3RX+VJT5DYQakqKE2Nt/Qb9yEqHMh2g6XB9
Ir3/StnXDapug0qkn8zmwTuBodocIdFG4Luw9l4nnBX5aslF76ywr5YT0C89
NmbFair59y/nrw6fD3eeUjIbJ7ukpHEbR58wHbOcmBpt/sbrBHD/YazC1Lf5
rcVISf0MUbl7iGiZqLS2Ubj+7oMEtKVyMd6mu5hdcKwUqvPo/tEs1rko4tbk
3XD+FvvOjawspKCJfoaCRJKZ8HUouGGG/wtxUCrDwQtaD85WBCZJXyo1PoqM
ai2S35xyORKnVppaNohQj6LtqL+htRmWpn/ygih+7BFjWFSso4uLjptwATAJ
gBRyiQ+0rvBDKNnByKxaJdPvOhToIdjL4WYfNOlGBZj25y81rA9Od3KTYpAh
WkgbcXz4K+yHetzZ+L/gawMAjdUGPXwm5o362jKSrpbU4gQVfWM3wjJpGB2m
AXWgmNwlRdDBYP9UXPuk0P6bOBqo5nRaeeEtmrX4MVnDYzDDPPGqC3buNOfL
jgcXWId0QuXQFx+YQkbwANzJWSJW2oTKWC1syTOQgbBtfeT7lgKTTSFBxHXF
3Cv78g6VynBnsC23//jThC+bBl93yIlA/LT9mClk8vnTb3fhCLSAN764cWRz
oGhbZwpAUcRmsu4BZlf3bHcA/Mnh6ko1xN3geDk0STrjtjZE2dSv6jURjwPM
R55J6AhWyxiFeugYBIzlczD85iaeXyOxgp8Wgw5GruLhUjSJOCDLFcZbpBMK
j0LjbrKg8OiYhzWt20ixn68DrGkPKk2Xkp147eIftZ3cMWywrCgDS3ZCD/Yw
lVM2Ufrxm6GzHdesT5Fjth5PwLn9BYXCZ3mjQnFf8dAUDsIi5oGXL2vTWMgi
rVHpdAhUdkQi2MxSgzE62G8QWN3rOItgnF7IoUwg2c6IhtMPadZTtCvIFRDY
YDjMqDo6+H5gou3d3HhNYcUi7Gk2qbRXBCrAjidMi8BxlPcWbZ7sQCYUBgPg
mGnbnn8WvaTWZHVH5iCs0S/pSAWcxAzXMpLH1VpMKOU4FBCN+p0W4oD5ylM4
7z6iO31DtuW+tmc3FCJQ5+6gw8E3TqEpumdl+y3l29h82qWqOa40ckpXRRzm
8+ULpmEtY4qd9dFOjXhS69mkY064JRqiM9/Sy09ZxHSgA/rH1Z3xEALxWi2I
QpUS6xFH1raKaX2Y/awDi93Rdq4SjzFHpNBqHWOuxHqUSSmt1714bTLrwToj
Rls+D64EYEIj7WLrmKhuQ45fpDvOV3vUsg28/ZwReYPXzl4IcsQv4BZwAJat
nU6F8CRX00AVLkmJKjgVO5DIICoacYdhJ0m8MNJIn5MpTVdbk+FgNmQCcwLu
FGrXxI3Q4BqMuR4ibw6DaDjuYMT5d+1HQmkW5kio+AIeunEsNTBQowjd3o+y
xhdY9NKfBeB/F0vlSB55lTFbmRpHi1s84qSqkzsJp5/BOtARDHQMA7WbAX+Y
tovfb4yu4DINWN/fN2mTmd4os1LAVlivKYcfdPnebbpy6IrlXH70YKMhWhIO
3WD+cGLDjcJuRya5mlSfOj0KcXYXZ51VsB4v5UZpKvVUbhKI2FRVIhdnsUYE
N9fZUoY6R1LS0O1ICybGj7R0CCKFTlMp/fBvPsMFSBXhT8DyWJ5SD48Q1mBj
mgLMRnZFoqgmErIvBRaYr3OIUnjGpW7OdoTKylH/h1sSFn0Smm/doxz/QPtF
83aksgbg2FoaVjqkjiN3HKAQ/5WtUMZzresBUh9mqCiMdqrqRsiktEaZcr2a
++Vg9E6jjS7CDBWQdHAoTjzOIy2/Y9b4gmoegC4CV6+R0ULHw/zWT4HiHk/W
0SKRwU4PlEvx6nTfAdwvqfssSGy9DczJfQb29+7s+O3l8Zvj0+PL859UNZBF
uo1WxHUUaJVV1QAk492p/TpNxiuuikjZqHmG7l+GNsV3cYQfQrdEwo8OJwxy
qrAJ+V28LkdWZWikbwfiegZsiwj57stBfWEGCjijJ+IaFBi6x80P0GNpQnZL
eV67wfuRjQEl5b6gPbW7wuvFuL1gGzf0xAOJfx7klkduysHP87V1MU0DqXAD
FL8i3qjlerWKFAXqNxvKmAaXpkm8+t5JBa6dcdJKhfiXoP3QmWr43nwGS6PT
yCCQFOi1E6fkg4CmarbykABHTsuV8PyiSOZO1uhLDCBlAQN35l4RTgvfIK+9
RFpiADK2o9Rx3XZk0u1wa6XAc/vWBGbV04iRayJupTRrEVNsSUC6apZjuTEN
0Wi0MtJjk6M20Te/v6cScF5nu5IE12ymxPu3NY3ZABU4HaM8ktloeSW1vi4O
Ty4vw+7FiiLzD2lO0wSoz/yQZIPJui8cclVWG+gYEm4ecJPFo5ykVRW5vzpa
c1xT3U1tx8qsorJucjrzktdNsHKqJDMlcRevYhYA8oLvAXpIuRwtbSyglPJl
VboXUTeTaNwfXX7/FkpWOxUeDbstjkFV5Kk+LgbicUKtc1Xc8vvmCtLB8QJa
VqwVVWJbfJ8qVjhxssTzXAA5cMSCBgStQfCK+DBV5exzaQJrMlmAkIh187ke
iC1vScI1C2SULM9RamQE5DRKw87Dmno3XrMSyAbYwNHsjKhDtTiICc1tDo5T
5B4bVxGwMYlRzCeapdwOL46jb0OHAVuTNafbBHLZ+C1THgSFA7hxGARrhUqK
ng27GJKL+/bZk9HmQ6QEVR5huUEPY60tgYbg1Ssi9pzAHd5wLIrMDaZDBQ4C
Sb1AN+jcGI8Imbs1/3AvoCrRJLbRrLbjE1D8mFheucJDLlvhFri8ABBI1uxG
zJO1AWuxm9IfDlv4sHsoxSzoGh/Cfli02sAONj/v1FQUN1g8RhVRmqyagFBV
HPoaDCeBPD2973acZi+u/DrQcsxdQtkbIu/UQM63VzSyf3sDtZoRJq2ob/Pl
Fko5MYdbOYFYwn36klxiGtgRgbK9xEjMEVsPB875ffG+l+qOG+3YFIcNiOy/
1/74Acdes/cC10c6sj8hhinipZEmfIecJAn7FF6HV7nWAdVPEuhziQXpWI+x
9v1wU0vUnhtuaAajSH9+vRbtT9Vx2kvkGQVpQP39kG445QHvL6NCafFaEIX6
BmKhFL2wmPPbpVw9QqLFgkKeegPq5Sc9Yb20QZuA6FdCAfEMG/OdSW+BWmpP
V7giWXfw3vWb6QkMFS6HY8RNWMm+aZeozYZFim6pZeYHH5/rjiRGsxVvIq8X
I4hAI4Av9aurWKcEHvJCxTcWWsdrkd7RdHEk4hKfhdMZcITAoITOzTKU9III
x9LIGcNWJe0Hh240q8SIOk4S8hZkCzFpzkhbChsBCsd9vR4X6XQUvs4rI6cR
R1XRr48W1ilLR7f0mxFfMaRSc9gR1nLg5G+rhcRuADdjW3u2o5TX3ZBoGoT1
VFOCkodqowdySm0SqckuRQMSheRbzalcICkgqwenkNowSaoRQB4LjySOkJJH
oPvOU04l1HVTqj/12lxS2B7bI/DUMWytvuH9aLi9QEmPessKwH3/kA3Y5E26
QdspUQC87GTHxlmwrF0sich4YPXI1PZjqsfKx2RGkIxjLF/TqN7DvMJU8Am6
P7y7OJZMJNJYWEyWwE2vbg9QYq7r42cSpS1rgAuRZzNUjbAm+grxcNqSbId6
u7tcTAhhQ7RSL5OxiQ4rW3cIs/Ap85FkHhdOA/a+Gj3d9gGBO7lcon1jo7Lh
1CUWdWCxiNGyVlI5MqOZeS0l3HYsRFtu4RUsQFC09Vg06gAmbQaVabZDDaZw
ZlLWXgBi3aTJLQdpm+G1IkHg5BDUiMciibkXmWmu2dJP08RPcTzAue2lgYFD
cIcPdYP0QGBDAfhfMAD2o9oZhoevzjGYsAqHQ4wAcbs/Wpnd7UmkBo2+aUjR
1XZHGFJ26FFgl5ux6dAyAM6o8Jt7uOqK134OV3z8Pjw9Ooc5HtXhqKsdkXoM
kobdw8lgODiJuEcn1jrUMBWNezeTH5xgqCa2FhmEwx2C1kPtj/zmR781+pn4
/Kre1qR14j0Yhnse2uZGZtq1mePezkj39EXCKU/TVydHADkEtWP/VoARtUYv
721asiGNW8xxNOA9nWNa+oXpmDgt9n9xoNvW6IXFNjNRE4nKRosYF6VaQkRw
A6Zv2z00hzuIS7eKDSz3iXkgHKpwE17e5REnxJoGUu1itTRmkCrzpUgJoenZ
zM5pjgrJpqVjptKWCiOuPIH8QCLb691fQEDFTh4kGXAzEGDF+I2fm8I/feTO
KSTxRnEEsme0s73zNNre0U4fNN0Z92t/qNGMmBQGQA2laQyFr5rttfeaedxb
9XYzzbdEbskb/Wa2n+4NG/1m4MtnX9tvZnvo9ZsZDyc72HMmoqYz2F8mGk+m
SXS9bTvONPvNXCcgnl5hAQDMS8Steq1m/CYy85SIID12xZljX9dMxuQMI+xu
4giQYpTtjf86++nm9PrDh/hN9PfZpx+Lv76K311dfiqLw72TcvvHYflqfHR3
OJvxICbT2BnkzWG8He/8evUpv9pfbL9//vry5cu3L98evvnby4+zZ9Es+mmZ
pN//sNh/uufAQKKV8Qz2dujretwwziEBbAYFtZ2I59oFvOyrEoPhSX33Wjn+
ArxSbMbUSBksJi9VY78eo2tY9jAy1164D4/v7ZqEWPy0DYuffi0W7/wBWGz6
s3AXlK/uljT0uyVJLxWnKbBp8PIYLK/h1vNvH41al2RIx8QGZD21XqaDwSDa
poamzUtbaysqj+6E3RpkejyPwzd2Rq0NyUks1R7HB9KMeKN5BhcckR12U+dy
Ww/3zu2aEsS2xZH2Ls+mtT672gsZcx+RIw29Nt6mLfT9d6fe0JhuA0q5kXbF
bb9Cj32vfpNa38N0N2zM+Tt5Qjwc70x2AX8RDfBf2/Zf8o/PE/guXe9H8dPx
swhbjkVwma4j5zINm7dpU7/czZyhtf35Y67KfZeCHvDyL3QqAX10uzsY/h/E
WMwtRiTd8Tu7owz6TyCqjziPwlH/lUehJyrSUbHCstAtGLqz3YKhz7e/FkN3
/gAMrXdp9gn+o65JrT0eZSdgPYlpDNrB1e3u/x7sxUMBUEe3O4MavuyC/mhp
4SVakv4JfGmc5KNQpvHWo7CG7BBt+NImHzx/+rX4svsH4EuzY/dXY8yOjzE0
ErXuAyB8nRD8INbU5Ie9/Z1dD1X2wu5L6lj/TyCIc2iPQg3n+QeQgltBCu+O
FrMi2ttpwY7dYQt2fDv8WuzY+wOwo71T+1djSK3lJo/qyJB/EEds41Ln6+FP
1+/yDzt/Wx7un/79+euP3//j7afd6Ztvb1/Ge+X7X4+fpf9ebd+d/cfEpzr7
YZdNOyrqnVK3gsKIfF+LXZtP/wE02/ziA/j2kJqy34Jo+8OvRrT9PwDR5KQV
1b4aw/Z8DDMYK2clZOif6ur66FPxarPC+tnxuZGIoE1s6+9xpJVZo2EH3vjl
92tGTjdS23OUdJcRGa+lIhJ2tphgkmPN59CvO5D1uVA6JvX1DzsC3WhW3uOa
irKQa2MSLqmoQMql8+mRoFExsqVzzaBV3dskj29U+uriUfuDu1pr3OWL7Y8C
x2knku2PA1WpoXov/JkAZhtcTX8Ra0pGjgGJe6FTzTgwWpK/KNIfCwglxdp0
cHIcw1z8eT533OZYIeFxV5TCGjjOBsemqCLjQnCa4JqeCO3dywLT94OUZ3YK
CRZgTAf3ytNeIuJP9u3igQygGDXTjmRGU98d2R6jNruexvohTzfGTlh9m3yK
mDvD0dct3UUFt6mUMndnqPUYbbdHYI+lsrxCrwMhROj885+IHe4XDXQNPaQM
ulxEVP/p8uk4LrMefj1P4TIAEqwbE27VJmxgskF6LMLWc5gh/or25eXj7Mst
XcmNv+HRfcxrb/z+NuYocLeZEJ77JoTrYQL3YkJcZu8xItXva2Puwdjjc8wn
3GXs3Kcn1p7d3SR6GWai8jm1TzfQtS2If68MJpnHHkNyesxJvM5dbtqqet2y
KfLKonBAOK7B8AaX/fLQfjdtrbFPG7PZF+S7Pph8zPI7xAsOPdnorWbHGcWe
S6NzTg9GGoGroZRzzdJLCyd3N54HFBWbt3T8QwoiJkDu4Ow2uZSUPZOul183
s5dNoks2tT+eFTk8Kxl1TmZx+EBmcaO+VaD1rdJSso2D/x9r56QxXSkBAA==
-->
</rfc>
Reference in New Issue View Git Blame Copy Permalink