c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
bf0f94ab3044dc492774179bbc320edfac8a9497
ietf-wimse-ect/draft-nennemann-wimse-execution-context-00.xml
Christian Nennemann bf0f94ab30 Simplify spec: remove sub, move compensation and policy to ext 
- Remove sub claim (always equals iss, added no information)
- Move compensation_required and compensation_reason to ext keys
- Move pol, pol_decision, pol_enforcer to ext keys
- IANA JWT Claims table reduced from 11 to 6 registered claims
- Trim witness attestation section to concise guidance
- Fix remaining ledger-mandatory language in verification
  step 15 and minimal implementation guidance

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

3165 lines
136 KiB
XML
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.5) -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc ipr="trust200902" docName="draft-nennemann-wimse-execution-context-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
<front>
<title abbrev="WIMSE Execution Context">Execution Context Tokens for Distributed Agentic Workflows</title>
<author fullname="Christian Nennemann">
<organization>Independent Researcher</organization>
<address>
<email>ietf@nennemann.de</email>
</address>
</author>
<date year="2026" month="February" day="25"/>
<area>Security</area>
<workgroup>WIMSE</workgroup>
<keyword>execution context</keyword> <keyword>workload identity</keyword> <keyword>agentic workflows</keyword> <keyword>audit trail</keyword> <keyword>compliance</keyword> <keyword>regulated systems</keyword>
<abstract>
<?line 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 via extension keys (<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
+--------------------------------------------------+
| Optional: Audit Ledger (Immutable Record) |
| "ECTs MAY be appended to an audit ledger" |
+--------------------------------------------------+
]]></artwork></figure>
<t>This extension reuses the WIMSE signing model, extends JWT claims
using standard JWT extensibility <xref target="RFC7519"/>, and maintains WIMSE
concepts including trust domains and workload identifiers.</t>
</section>
<section anchor="integration-points"><name>Integration Points</name>
<t>An ECT integrates with the WIMSE identity framework through the
following mechanisms:</t>
<t><list style="symbols">
<t>The ECT JOSE header "kid" parameter <bcp14>MUST</bcp14> reference the public
key identifier from the agent's WIT.</t>
<t>In WIMSE deployments, the ECT "iss" claim <bcp14>SHOULD</bcp14> use the WIMSE
workload identifier format (a SPIFFE ID <xref target="SPIFFE"/>).</t>
<t>The ECT <bcp14>MUST</bcp14> be signed with the same private key associated
with the agent's WIT.</t>
<t>The ECT signing algorithm (JOSE header "alg" parameter) <bcp14>MUST</bcp14>
match the algorithm used in the corresponding WIT.</t>
</list></t>
<t>When an agent makes an HTTP request to another agent, the
Execution-Context header is carried alongside WIMSE identity
headers:</t>
<figure title="HTTP Header Stacking" anchor="fig-http-headers"><artwork type="ascii-art"><![CDATA[
HTTP Request from Agent A to Agent B:
Workload-Identity: <WIT for Agent A>
Execution-Context: <ECT recording what A did>
]]></artwork></figure>
<t>When a Workload Proof Token (WPT) is available per
<xref target="I-D.ietf-wimse-s2s-protocol"/>, agents <bcp14>SHOULD</bcp14> include it
alongside the WIT and ECT. ECT verification does not depend
on the presence of a WPT; the ECT is independently verifiable
via the WIT public key.</t>
<t>The receiving agent (Agent B) verifies in order:</t>
<t><list style="numbers" type="1">
<t>WIT (WIMSE layer): Verifies Agent A's identity within the
trust domain. WPT verification, if present, per
<xref target="I-D.ietf-wimse-s2s-protocol"/>.</t>
<t>ECT (this extension): Records what Agent A did, what policy was
evaluated, and what precedent tasks exist.</t>
<t>Ledger (if deployed): Appends the verified ECT to the audit
ledger.</t>
</list></t>
</section>
</section>
<section anchor="ect-format"><name>Execution Context Token Format</name>
<t>An Execution Context Token is a JSON Web Token (JWT) <xref target="RFC7519"/>
signed as a JSON Web Signature (JWS) <xref target="RFC7515"/> using the Compact
Serialization. JWS JSON Serialization <bcp14>MUST NOT</bcp14> be used for ECTs.</t>
<section anchor="jose-header"><name>JOSE Header</name>
<t>The ECT JOSE header <bcp14>MUST</bcp14> contain the following parameters:</t>
<figure title="ECT JOSE Header Example" anchor="fig-header"><sourcecode type="json"><![CDATA[
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
"kid": "agent-a-key-id-123"
}
]]></sourcecode></figure>
<dl>
<dt>alg:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. The digital signature algorithm used to sign the ECT.
<bcp14>MUST</bcp14> match the algorithm in the corresponding WIT.
Implementations <bcp14>MUST</bcp14> support ES256 <xref target="RFC7518"/>. The "alg"
value <bcp14>MUST NOT</bcp14> be "none". Symmetric algorithms (e.g., HS256,
HS384, HS512) <bcp14>MUST NOT</bcp14> be used, as ECTs require asymmetric
signatures for non-repudiation.</t>
</dd>
<dt>typ:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. <bcp14>MUST</bcp14> be set to "wimse-exec+jwt" to distinguish ECTs
from other JWT types, consistent with the WIMSE convention for
type parameter values.</t>
</dd>
<dt>kid:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. The key identifier referencing the public key from
the agent's WIT <xref target="RFC7517"/>. Used by verifiers to look up the
correct public key for signature verification.</t>
</dd>
</dl>
</section>
<section anchor="jwt-claims"><name>JWT Claims</name>
<t>The ECT payload contains both WIMSE-compatible standard JWT claims
and execution context claims defined by this specification.</t>
<section anchor="standard-jwt-claims"><name>Standard JWT Claims</name>
<t>The following standard JWT claims <xref target="RFC7519"/> <bcp14>MUST</bcp14> be present in
every ECT:</t>
<dl>
<dt>iss:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. StringOrURI. A URI identifying the issuer of the
ECT. In WIMSE deployments, this <bcp14>SHOULD</bcp14> be the workload's
SPIFFE ID in the format <spanx style="verb">spiffe://&lt;trust-domain&gt;/&lt;path&gt;</spanx>,
matching the "sub" claim of the agent's WIT. Non-WIMSE
deployments <bcp14>MAY</bcp14> use other URI schemes (e.g., HTTPS URLs or
URN:UUID identifiers).</t>
</dd>
<dt>aud:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. StringOrURI or array of StringOrURI. The intended
recipient(s) of the ECT. Because ECTs serve as both inter-agent
messages and audit records, the "aud" claim <bcp14>SHOULD</bcp14> contain the
identifiers of all entities that will verify the ECT. In
practice this means:
</t>
<t><list style="symbols">
<t><strong>Point-to-point delivery</strong>: when an ECT is sent from one
agent to a single next agent, "aud" contains that agent's
workload identity. The receiving agent verifies the ECT and
forwards it to the ledger on behalf of the issuer.</t>
<t><strong>Direct-to-ledger submission</strong>: when an ECT is submitted
directly to the audit ledger (e.g., after a join or at
workflow completion), "aud" contains the ledger's identity.</t>
<t><strong>Multi-audience</strong>: when an ECT must be verified by both the
next agent and the ledger independently, "aud" <bcp14>MUST</bcp14> be an
array containing both identifiers (e.g.,
["spiffe://example.com/agent/next",
"spiffe://example.com/system/ledger"]). Each verifier checks
that its own identity appears in the array.</t>
</list></t>
<t>In multi-parent (join) scenarios where a task depends on ECTs
from multiple parent agents, the joining agent creates a new ECT
with the parent task IDs in "par". The "aud" of this new ECT
is set according to the rules above based on where the ECT will
be delivered — it is independent of the "aud" values in the
parent ECTs.</t>
</dd>
<dt>iat:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. NumericDate. The time at which the ECT was issued.
The ECT records a completed action, so the "iat" value reflects
when the record was created, not when task execution began.</t>
</dd>
<dt>exp:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. NumericDate. The expiration time of the ECT.
Implementations <bcp14>SHOULD</bcp14> set this to 5 to 15 minutes after "iat"
to limit the replay window while allowing for reasonable clock
skew and processing time.</t>
</dd>
</dl>
<t>The standard JWT "nbf" (Not Before) claim is not used in ECTs
because ECTs record completed actions and are valid immediately
upon issuance.</t>
<dl>
<dt>jti:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. String. A globally unique identifier for both the
ECT and the task it records, in UUID format <xref target="RFC9562"/>. Since
each ECT represents exactly one task, "jti" serves as both the
token identifier (for replay detection) and the task identifier
(for DAG parent references in "par"). Receivers <bcp14>MUST</bcp14> reject
ECTs whose "jti" has already been seen within the expiration
window. When "wid" is present, uniqueness is scoped to the
workflow; when "wid" is absent, uniqueness <bcp14>MUST</bcp14> be enforced
globally across the ECT store.</t>
</dd>
</dl>
</section>
<section anchor="exec-claims"><name>Execution Context</name>
<t>The following claims are defined by this specification:</t>
<dl>
<dt>wid:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A workflow identifier that groups related
ECTs into a single workflow. When present, <bcp14>MUST</bcp14> be a UUID
<xref target="RFC9562"/>.</t>
</dd>
<dt>exec_act:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. String. The action or task type identifier describing
what the agent performed (e.g., "process_payment",
"validate_safety", "calculate_dosage"). Note: this claim is
intentionally named "exec_act" rather than "act" to avoid
collision with the "act" (Actor) claim registered by
<xref target="RFC8693"/>.</t>
</dd>
<dt>par:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. Array of strings. Parent task identifiers
representing DAG dependencies. Each element <bcp14>MUST</bcp14> be the "jti"
value of a previously verified ECT. An empty array indicates
a root task with no dependencies. A workflow <bcp14>MAY</bcp14> contain
multiple root tasks.</t>
</dd>
</dl>
</section>
<section anchor="policy-claims"><name>Policy Evaluation Extension Keys</name>
<t>Policy evaluation outcomes are recorded as extension keys within
the "ext" object (<xref target="extension-claims"/>). This keeps the core
registered claims focused on DAG structure and execution context,
while allowing deployments to add policy recording as needed.</t>
<t>The following extension keys are defined for policy evaluation:</t>
<dl>
<dt>"pol":</dt>
<dd>
<t>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>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 from "ext", the ECT
records task execution without a policy checkpoint. Regulated
deployments <bcp14>SHOULD</bcp14> include policy keys on all ECTs to maintain
complete audit trails.</t>
</dd>
<dt>"pol_enforcer":</dt>
<dd>
<t>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>
</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" key 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 "ext" keys 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>
</dl>
</section>
<section anchor="compensation-claims"><name>Compensation and Rollback</name>
<t>Compensation and rollback actions are recorded using the "par"
claim to reference the original task and the "exec_act" claim to
describe the remediation action. The referenced parent ECTs may
have passed their own "exp" time; ECT expiration applies to the
verification window of the ECT itself, not to its validity as a
parent reference in the ECT store.</t>
</section>
<section anchor="extension-claims"><name>Extensions</name>
<dl>
<dt>ext:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Object. An extension object for domain-specific
claims not defined by this specification. Implementations
that do not understand extension claims <bcp14>MUST</bcp14> ignore them.</t>
</dd>
</dl>
<t>To avoid key collisions between different domains, extension
key names <bcp14>SHOULD</bcp14> use reverse domain notation (e.g.,
"com.example.custom_field") to avoid collisions between
independently developed extensions. To prevent abuse and
excessive token size, the serialized JSON representation of
the "ext" object <bcp14>SHOULD NOT</bcp14> exceed 4096 bytes, and the JSON
nesting depth within the "ext" object <bcp14>SHOULD NOT</bcp14> exceed 5
levels. Implementations <bcp14>SHOULD</bcp14> reject ECTs whose "ext" claim
exceeds these limits.</t>
<t>The following extension keys are defined by this specification
for common use cases. Because these keys are documented here,
they use short names without reverse domain prefixes.</t>
<t>Policy evaluation keys (see <xref target="policy-claims"/> for full
definitions and decision value semantics):</t>
<t><list style="symbols">
<t>"pol": String. Policy rule identifier.</t>
<t>"pol_decision": String. Policy evaluation outcome
("approved", "rejected", or "pending_human_review").</t>
<t>"pol_enforcer": StringOrURI. Identity of the policy
evaluator.</t>
<t>"pol_timestamp": NumericDate. Time at which the policy
decision was made, if distinct from "iat".</t>
</list></t>
<t>Operational metadata keys:</t>
<t><list style="symbols">
<t>"exec_time_ms": Integer. Execution duration in milliseconds.</t>
<t>"regulated_domain": String. Regulatory domain (e.g.,
"medtech", "finance", "military").</t>
<t>"model_version": String. AI/ML model version.</t>
<t>"witnessed_by": Array of StringOrURI. Identifiers of
third-party entities that the issuer claims observed the
task. Note: this is self-asserted; for verifiable witness
attestation, witnesses should submit independent signed ECTs.</t>
<t>"inp_classification": String. Data sensitivity classification
(e.g., "public", "confidential", "restricted").</t>
<t>"compensation_required": Boolean. Indicates whether this task
is a compensation or rollback action.</t>
<t>"compensation_reason": String. Structured reason code for the
compensation action (e.g., "policy_violation_in_parent_trade").
<bcp14>SHOULD</bcp14> use structured identifiers rather than free-form text
to minimize information leakage (see <xref target="data-minimization"/>).</t>
</list></t>
</section>
</section>
<section anchor="complete-ect-example"><name>Complete ECT Example</name>
<t>The following is a complete ECT payload example:</t>
<figure title="Complete ECT Payload Example" anchor="fig-full-ect"><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://example.com/agent/clinical",
"aud": "spiffe://example.com/agent/safety",
"iat": 1772064150,
"exp": 1772064750,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"exec_act": "recommend_treatment",
"par": [],
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"ext": {
"pol": "clinical_reasoning_policy_v2",
"pol_decision": "approved",
"pol_enforcer": "spiffe://example.com/policy/clinical-engine",
"pol_timestamp": 1772064145,
"exec_time_ms": 245,
"regulated_domain": "medtech",
"model_version": "clinical-reasoning-v4.2"
}
}
]]></sourcecode></figure>
</section>
</section>
<section anchor="http-header"><name>HTTP Header Transport</name>
<section anchor="execution-context-header-field"><name>Execution-Context Header Field</name>
<t>This specification defines the Execution-Context HTTP header field
<xref target="RFC9110"/> for transporting ECTs between agents.</t>
<t>The header field value is the ECT in JWS Compact Serialization
format <xref target="RFC7515"/>. The value consists of three Base64url-encoded
parts separated by period (".") characters.</t>
<t>An agent sending a request to another agent includes the
Execution-Context header alongside the WIMSE Workload-Identity
header:</t>
<figure title="HTTP Request with ECT Header" anchor="fig-http-example"><artwork><![CDATA[
GET /api/safety-check HTTP/1.1
Host: safety-agent.example.com
Workload-Identity: eyJhbGci...WIT...
Execution-Context: eyJhbGci...ECT...
]]></artwork></figure>
<t>When multiple parent tasks contribute context to a single request,
multiple Execution-Context header field lines <bcp14>MAY</bcp14> be included, each
carrying a separate ECT in JWS Compact Serialization format.</t>
<t>When a receiver processes multiple Execution-Context headers, it
<bcp14>MUST</bcp14> individually verify each ECT per the procedure in
<xref target="verification"/>. If any single ECT fails verification, the
receiver <bcp14>MUST</bcp14> reject the entire request. The set of verified
parent task IDs across all received ECTs represents the complete
set of parent dependencies available for the receiving agent's
subsequent ECT.</t>
</section>
</section>
<section anchor="dag-validation"><name>DAG Validation</name>
<section anchor="overview"><name>Overview</name>
<t>ECTs form a Directed Acyclic Graph (DAG) where each task
references its parent tasks via the "par" claim. This structure
provides a cryptographically signed record of execution ordering,
enabling auditors to reconstruct the complete workflow and verify
that required predecessor tasks were recorded before dependent
tasks.</t>
<t>DAG validation is performed against the ECT store — either an
audit ledger or the set of parent ECTs received inline.</t>
</section>
<section anchor="validation-rules"><name>Validation Rules</name>
<t>When receiving and verifying an ECT, implementations <bcp14>MUST</bcp14> perform
the following DAG validation steps:</t>
<t><list style="numbers" type="1">
<t>Task ID Uniqueness: The "jti" claim <bcp14>MUST</bcp14> be unique within the
applicable scope (the workflow identified by "wid", or the
entire ECT store if "wid" is absent). If an ECT with the same
"jti" already exists, the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Parent Existence: Every task identifier listed in the "par"
array <bcp14>MUST</bcp14> correspond to a task that is available in the ECT
store (either previously recorded in the ledger or received
inline as a verified parent ECT). If any parent task is not
found, the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Temporal Ordering: The "iat" value of every parent task <bcp14>MUST
NOT</bcp14> be greater than the "iat" value of the current task plus a
configurable clock skew tolerance (<bcp14>RECOMMENDED</bcp14>: 30 seconds).
That is, for each parent: <spanx style="verb">parent.iat &lt; child.iat +
clock_skew_tolerance</spanx>. The tolerance accounts for clock skew
between agents; it does not guarantee strict causal ordering
from timestamps alone. Causal ordering is primarily enforced
by the DAG structure (parent existence in the ECT store), not by
timestamps. If any parent task violates this constraint, the
ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Acyclicity: Following the chain of parent references <bcp14>MUST NOT</bcp14>
lead back to the current ECT's "jti". If a cycle is detected,
the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Parent Policy Decision: If any parent ECT's "ext" object
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". This rule only applies
when the parent ECT's "ext" contains policy keys.</t>
<t>Trust Domain Consistency: Parent tasks <bcp14>SHOULD</bcp14> belong to the
same trust domain or to a trust domain with which a federation
relationship has been established.</t>
</list></t>
</section>
<section anchor="dag-validation-algorithm"><name>DAG Validation Algorithm</name>
<t>The following pseudocode describes the DAG validation procedure:</t>
<figure title="DAG Validation Pseudocode" anchor="fig-dag-validation"><sourcecode type="pseudocode"><![CDATA[
function validate_dag(ect, ect_store, clock_skew_tolerance):
// Step 1: Uniqueness check
if ect_store.contains(ect.jti, ect.wid):
return error("ECT ID already exists")
// Step 2: Parent existence and temporal ordering
for parent_id in ect.par:
parent = ect_store.get(parent_id)
if parent is null:
return error("Parent task not found: " + parent_id)
if parent.iat >= ect.iat + clock_skew_tolerance:
return error("Parent task not earlier than current")
// Step 3: Cycle detection (with traversal limit)
visited = set()
result = has_cycle(ect.jti, ect.par, ect_store, visited,
max_ancestor_limit)
if result is error or result is true:
return error("Circular dependency or depth limit exceeded")
return success
function has_cycle(target_jti, parent_ids, ect_store,
visited, max_depth):
if visited.size() >= max_depth:
return error("Maximum ancestor traversal limit exceeded")
for parent_id in parent_ids:
if parent_id == target_jti:
return true
if parent_id in visited:
continue
visited.add(parent_id)
parent = ect_store.get(parent_id)
if parent is not null:
result = has_cycle(target_jti, parent.par, ect_store,
visited, max_depth)
if result is error or result is true:
return result
return false
]]></sourcecode></figure>
<t>The cycle detection traverses the ancestor graph rooted at the
current task's parents. The complexity is O(V) where V is the
number of ancestor nodes reachable from the current task's parent
references. For typical workflows with shallow DAGs, this is
efficient. To prevent denial-of-service via extremely deep or
wide DAGs, implementations <bcp14>SHOULD</bcp14> enforce a maximum ancestor
traversal limit (<bcp14>RECOMMENDED</bcp14>: 10000 nodes). If the limit is
reached before cycle detection completes, the ECT <bcp14>SHOULD</bcp14> be
rejected. Implementations <bcp14>SHOULD</bcp14> cache cycle detection results
for previously verified tasks to avoid redundant traversals.</t>
</section>
</section>
<section anchor="verification"><name>Signature and Token Verification</name>
<section anchor="verification-procedure"><name>Verification Procedure</name>
<t>When an agent receives an ECT, it <bcp14>MUST</bcp14> perform the following
verification steps in order:</t>
<t><list style="numbers" type="1">
<t>Parse the JWS Compact Serialization to extract the JOSE header,
payload, and signature components per <xref target="RFC7515"/>.</t>
<t>Verify that the "typ" header parameter is "wimse-exec+jwt".</t>
<t>Verify that the "alg" header parameter is not "none" and is
not a symmetric algorithm.</t>
<t>Verify the "kid" header parameter references a known, valid
public key from a WIT within the trust domain.</t>
<t>Retrieve the public key identified by "kid" and verify the JWS
signature per <xref target="RFC7515"/> Section 5.2.</t>
<t>Verify that the signing key identified by "kid" has not been
revoked within the trust domain. Implementations <bcp14>MUST</bcp14> check
the key's revocation status using the trust domain's key
lifecycle mechanism (e.g., certificate revocation list, OCSP,
or SPIFFE trust bundle updates).</t>
<t>Verify the "alg" header parameter matches the algorithm in the
corresponding WIT.</t>
<t>Verify the "iss" claim matches the "sub" claim of the WIT
associated with the "kid" public key.</t>
<t>Verify the "aud" claim contains the verifier's own workload
identity. When "aud" is an array, it is sufficient that the
verifier's identity appears as one element; the presence of
other audience values does not cause verification failure.
When the verifier is the audit ledger, the ledger's own
identity <bcp14>MUST</bcp14> appear in "aud".</t>
<t>Verify the "exp" claim indicates the ECT has not expired.</t>
<t>Verify the "iat" claim is not unreasonably far in the past
(implementation-specific threshold, <bcp14>RECOMMENDED</bcp14> maximum of
15 minutes) and is not unreasonably far in the future
(<bcp14>RECOMMENDED</bcp14>: no more than 30 seconds ahead of the
verifier's current time, to account for clock skew).</t>
<t>Verify all required claims ("jti", "exec_act", "par") are
present and well-formed.</t>
<t>If "ext" is present and contains "pol" or "pol_decision",
verify that both are present and that "pol_decision" is one
of "approved", "rejected", or "pending_human_review".</t>
<t>Perform DAG validation per <xref target="dag-validation"/>.</t>
<t>If all checks pass and an audit ledger is deployed, the ECT
<bcp14>SHOULD</bcp14> be appended to the ledger.</t>
</list></t>
<t>If any verification step fails, the ECT <bcp14>MUST</bcp14> be rejected and the
failure <bcp14>MUST</bcp14> be logged for audit purposes. Error messages
<bcp14>SHOULD NOT</bcp14> reveal whether specific parent task IDs exist in the
ECT store, to prevent information disclosure.</t>
<t>When ECT verification fails during HTTP request processing, the
receiving agent <bcp14>SHOULD</bcp14> respond with HTTP 403 (Forbidden) if the
WIT is valid but the ECT is invalid, and HTTP 401
(Unauthorized) if the ECT signature verification fails. The
response body <bcp14>SHOULD</bcp14> include a generic error indicator without
revealing which specific verification step failed. The receiving
agent <bcp14>MUST NOT</bcp14> process the requested action when ECT verification
fails.</t>
</section>
<section anchor="verification-pseudocode"><name>Verification Pseudocode</name>
<figure title="ECT Verification Pseudocode" anchor="fig-verification"><sourcecode type="pseudocode"><![CDATA[
function verify_ect(ect_jws, verifier_id,
trust_domain_keys, ect_store):
// Parse JWS
(header, payload, signature) = parse_jws(ect_jws)
// Verify header
if header.typ != "wimse-exec+jwt":
return reject("Invalid typ parameter")
if header.alg == "none" or is_symmetric(header.alg):
return reject("Prohibited algorithm")
// Look up public key
public_key = trust_domain_keys.get(header.kid)
if public_key is null:
return reject("Unknown key identifier")
// Verify signature
if not verify_jws_signature(header, payload,
signature, public_key):
return reject("Invalid signature")
// Verify key not revoked
if is_key_revoked(header.kid, trust_domain_keys):
return reject("Signing key has been revoked")
// Verify algorithm alignment
wit = get_wit_for_key(header.kid)
if header.alg != wit.alg:
return reject("Algorithm mismatch with WIT")
// Verify issuer matches WIT subject
if payload.iss != wit.sub:
return reject("Issuer does not match WIT subject")
// Verify audience
if verifier_id not in payload.aud:
return reject("ECT not intended for this recipient")
// Verify not expired
if payload.exp < current_time():
return reject("ECT has expired")
// Verify iat freshness (not too old, not in the future)
if payload.iat < current_time() - max_age_threshold:
return reject("ECT issued too long ago")
if payload.iat > current_time() + clock_skew_tolerance:
return reject("ECT issued in the future")
// Verify required claims
for claim in ["jti", "exec_act", "par"]:
if claim not in payload:
return reject("Missing required claim: " + claim)
// Validate policy extension keys (optional, but must be paired)
ext = payload.ext or {}
if "pol" in ext or "pol_decision" in ext:
if "pol" not in ext or "pol_decision" not in ext:
return reject("pol and pol_decision must both be present")
if ext.pol_decision not in
["approved", "rejected", "pending_human_review"]:
return reject("Invalid pol_decision value")
// Validate DAG (against ECT store or inline parent ECTs)
result = validate_dag(payload, ect_store,
clock_skew_tolerance)
if result is error:
return reject("DAG validation failed")
// All checks passed; record if store is available
if ect_store is not null:
ect_store.append(payload)
return accept
]]></sourcecode></figure>
</section>
</section>
<section anchor="ledger-interface"><name>Audit Ledger Interface</name>
<t>ECTs <bcp14>MAY</bcp14> be recorded in an immutable audit ledger for compliance
verification and post-hoc analysis. A ledger is <bcp14>RECOMMENDED</bcp14> for
regulated environments but is not required for point-to-point
operation. This specification does not mandate a specific storage
technology. Implementations <bcp14>MAY</bcp14> use append-only logs, databases
with cryptographic commitment schemes, distributed ledgers, or
any storage mechanism that provides the required properties.</t>
<t>When an audit ledger is deployed, the implementation <bcp14>MUST</bcp14> provide:</t>
<t><list style="numbers" type="1">
<t>Append-only semantics: Once an ECT is recorded, it <bcp14>MUST NOT</bcp14> be
modified or deleted.</t>
<t>Ordering: The ledger <bcp14>MUST</bcp14> maintain a total ordering of ECT
entries via a monotonically increasing sequence number.</t>
<t>Lookup by ECT ID: The ledger <bcp14>MUST</bcp14> support efficient retrieval
of ECT entries by "jti" value.</t>
<t>Integrity verification: The ledger <bcp14>SHOULD</bcp14> provide a mechanism
to verify that no entries have been tampered with (e.g.,
hash chains or Merkle trees).</t>
</list></t>
<t>The ledger <bcp14>SHOULD</bcp14> be maintained by an entity independent of the
workflow agents to reduce the risk of collusion.</t>
</section>
<section anchor="use-cases"><name>Use Cases</name>
<t>This section describes representative use cases demonstrating how
ECTs provide execution records in regulated environments. These
examples demonstrate ECT mechanics; production deployments would
include additional domain-specific requirements beyond the scope
of this specification.</t>
<t>Note: task identifiers in this section are abbreviated for
readability. In production, all "jti" values are required to be
UUIDs per <xref target="exec-claims"/>.</t>
<section anchor="medical-device-sdlc-workflow"><name>Medical Device SDLC Workflow</name>
<t>In a medical device software development lifecycle (SDLC),
AI agents assist across multiple phases from requirements
analysis through release approval. Regulatory frameworks
including <xref target="FDA-21CFR11"/> Section 11.10(e) and <xref target="EU-MDR"/> require
audit trails documenting the complete development process for
software used in medical devices.</t>
<figure title="Medical Device SDLC Workflow" anchor="fig-medtech-sdlc"><artwork><![CDATA[
Agent A (Spec Reviewer):
jti: task-001 par: []
exec_act: review_requirements_spec
ext.pol: spec_review_policy_v2
ext.pol_decision: approved
Agent B (Code Generator):
jti: task-002 par: [task-001]
exec_act: implement_module
ext.pol: coding_standards_v3
ext.pol_decision: approved
Agent C (Test Agent):
jti: task-003 par: [task-002]
exec_act: execute_test_suite
ext.pol: test_coverage_policy_v1
ext.pol_decision: approved
Agent D (Build Agent):
jti: task-004 par: [task-003]
exec_act: build_release_artifact
ext.pol: build_validation_v2
ext.pol_decision: approved
Human Release Manager:
jti: task-005 par: [task-004]
exec_act: approve_release
ext.pol: release_approval_policy
ext.pol_decision: approved
ext.pol_enforcer: spiffe://meddev.example/human/release-mgr-42
ext.witnessed_by: [...]
]]></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
ext.pol: risk_limits_policy_v2
ext.pol_decision: approved
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
ext.pol: compliance_check_v1
ext.pol_decision: approved
Agent C (Execution):
jti: task-003 par: [task-002]
exec_act: execute_trade
ext.pol: execution_policy_v3
ext.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",
"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"],
"ext": {
"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
ext.pol: route_policy_v1
ext.pol_decision: approved
Agent B (Customs):
jti: task-002 par: [task-001]
exec_act: validate_customs
ext.pol: customs_policy_v2
ext.pol_decision: approved
Agent C (Safety):
jti: task-003 par: [task-001]
exec_act: verify_cargo_safety
ext.pol: safety_policy_v1
ext.pol_decision: approved
Agent D (Payment):
jti: task-004 par: [task-002, task-003]
exec_act: authorize_payment
ext.pol: payment_policy_v3
ext.pol_decision: approved
System (Commitment):
jti: task-005 par: [task-004]
exec_act: commit_shipment
ext.pol: commitment_policy_v1
ext.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" in "ext" 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"
extension key (carried in "ext") to include independent
third-party observers at critical decision points. However,
this value is self-asserted by the ECT issuer: the listed
witnesses do not co-sign the ECT and there is no cryptographic
evidence within a single ECT that the witnesses actually
observed the task. An issuing agent could list witnesses that
did not participate.</t>
<t>To strengthen witness attestation beyond self-assertion, witnesses
<bcp14>SHOULD</bcp14> submit their own independent signed ECTs referencing the
observed task's "jti" in the "par" array. Auditors can then
cross-check the "witnessed_by" extension against independent
witness ECTs in the ECT store.</t>
</section>
<section anchor="organizational-prerequisites"><name>Organizational Prerequisites</name>
<t>ECTs operate within a broader trust framework. The guarantees
provided by ECTs are only meaningful when the following
organizational controls are in place:</t>
<t><list style="symbols">
<t>Key management governance: Controls over who provisions agent
keys and how keys are protected.</t>
<t>Ledger integrity governance: The ledger is maintained by an
entity independent of the workflow agents.</t>
<t>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" extension
key in "ext" to include independent third-party observers.</t>
<t>Cross-verification: Multiple independent ledger replicas can be
compared for consistency.</t>
<t>Out-of-band audit: External auditors periodically verify ledger
contents against expected workflow patterns.</t>
</list></t>
</section>
<section anchor="denial-of-service"><name>Denial of Service</name>
<t>ECT signature verification is computationally inexpensive
(approximately 1ms per ECT on modern hardware for ES256). DAG
validation complexity is O(V) where V is the number of ancestor
nodes reachable from the parent references; for typical shallow
DAGs this is efficient.</t>
<t>Implementations <bcp14>SHOULD</bcp14> apply rate limiting at the API layer to
prevent excessive ECT submissions. DAG validation <bcp14>SHOULD</bcp14> be
performed after signature verification to avoid wasting resources
on unsigned or incorrectly signed tokens.</t>
</section>
<section anchor="timestamp-accuracy"><name>Timestamp Accuracy</name>
<t>ECTs rely on timestamps ("iat", "exp") for temporal ordering.
Clock skew between agents can lead to incorrect ordering
judgments. Implementations <bcp14>SHOULD</bcp14> use synchronized time sources
(e.g., NTP) and <bcp14>SHOULD</bcp14> allow a configurable clock skew tolerance
(<bcp14>RECOMMENDED</bcp14>: 30 seconds).</t>
<t>Cross-organizational deployments where agents span multiple trust
domains with independent time sources <bcp14>MAY</bcp14> require a higher clock
skew tolerance. Deployments using trust domain federation <bcp14>SHOULD</bcp14>
document their configured clock skew tolerance value and <bcp14>SHOULD</bcp14>
ensure all participating trust domains agree on a common tolerance.</t>
<t>The temporal ordering check in DAG validation incorporates the
clock skew tolerance to account for minor clock differences
between agents.</t>
</section>
<section anchor="ect-size-constraints"><name>ECT Size Constraints</name>
<t>ECTs with many parent tasks or large extension objects can
increase HTTP header size. Implementations <bcp14>SHOULD</bcp14> limit the "par"
array to a maximum of 256 entries. Workflows requiring more
parent references <bcp14>SHOULD</bcp14> introduce intermediate aggregation
tasks. The "ext" object <bcp14>SHOULD NOT</bcp14> exceed 4096 bytes when
serialized as JSON and <bcp14>SHOULD NOT</bcp14> exceed a nesting depth of
5 levels (see also <xref target="extension-claims"/>).</t>
</section>
</section>
<section anchor="privacy-considerations"><name>Privacy Considerations</name>
<section anchor="data-exposure-in-ects"><name>Data Exposure in ECTs</name>
<t>ECTs necessarily reveal:</t>
<t><list style="symbols">
<t>Agent identities ("iss", "aud") for accountability purposes</t>
<t>Action descriptions ("exec_act") for audit trail completeness</t>
<t>Policy evaluation outcomes (via "ext" keys "pol",
"pol_decision") when present, 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" extension key <bcp14>SHOULD</bcp14> reference policy identifiers
rather than embedding policy content.</t>
<t>The "compensation_reason" extension key in "ext"
(<xref target="compensation-claims"/>) deserves particular attention: because
it is human-readable, it risks exposing sensitive operational
details. See <xref target="extension-claims"/> for guidance on using
structured identifiers.</t>
</section>
<section anchor="storage-and-access-control"><name>Storage and Access Control</name>
<t>ECTs stored in audit ledgers <bcp14>SHOULD</bcp14> be access-controlled so that
only authorized auditors and regulators can read them.
Implementations <bcp14>SHOULD</bcp14> consider encryption at rest for ledger
storage containing sensitive regulatory data.</t>
<t>Full input and output data (corresponding to the hashes in ECTs)
<bcp14>SHOULD</bcp14> be stored separately from the ledger with additional access
controls, since auditors may need to verify hash correctness but
general access to the data values is not needed.</t>
</section>
<section anchor="regulatory-access"><name>Regulatory Access</name>
<t>ECTs are designed for interpretation by qualified human auditors
and regulators. ECTs provide structural records of execution
ordering 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>inp_hash</c>
<c>Input Data Hash</c>
<c>IETF</c>
<c><xref target="data-integrity-claims"/></c>
<c>out_hash</c>
<c>Output Data Hash</c>
<c>IETF</c>
<c><xref target="data-integrity-claims"/></c>
<c>ext</c>
<c>Extension Object</c>
<c>IETF</c>
<c><xref target="extension-claims"/></c>
</texttable>
<t>Note: Policy evaluation keys ("pol", "pol_decision",
"pol_enforcer") are carried within the "ext" object as
spec-defined extension keys (<xref target="policy-claims"/>) and do not
require separate JWT Claims registration.</t>
</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>
</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 1575?>
<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 extension keys
("ext.pol", "ext.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>If an audit ledger is deployed, append verified ECTs to it.</t>
</list></t>
</section>
<section numbered="false" anchor="storage-recommendations"><name>Storage Recommendations</name>
<t><list style="symbols">
<t>Append-only log: Simplest approach; immutability by design.</t>
<t>Database with hash chains: Periodic cryptographic commitments
over batches of entries.</t>
<t>Distributed ledger: Maximum immutability guarantees for
cross-organizational audit.</t>
<t>Hybrid: Hot storage in a database, cold archive in immutable
storage.</t>
</list></t>
</section>
<section numbered="false" anchor="performance-considerations"><name>Performance Considerations</name>
<t><list style="symbols">
<t>ES256 signature verification: approximately 1ms per ECT on
modern hardware.</t>
<t>DAG validation: O(V) where V is the number of reachable ancestor
nodes (typically small for shallow workflows).</t>
<t>JSON serialization: sub-millisecond per ECT.</t>
<t>Total per-request overhead: approximately 5-10ms, acceptable
for regulated workflows where correctness is prioritized over
latency.</t>
</list></t>
</section>
<section numbered="false" anchor="interoperability"><name>Interoperability</name>
<t>Implementations are expected to use established JWT/JWS libraries
(JOSE) for token creation and verification. Custom cryptographic
implementations are strongly discouraged. Implementations are
expected to be tested against multiple JWT libraries to ensure
interoperability.</t>
</section>
</section>
<section numbered="false" anchor="regulatory-compliance-mapping"><name>Regulatory Compliance Mapping</name>
<t>The following table summarizes how ECTs can contribute to
compliance with various regulatory frameworks. ECTs are a
technical building block; achieving compliance requires
additional organizational measures beyond this specification.</t>
<texttable title="Regulatory Compliance Mapping" anchor="_table-regulatory">
<ttcol align='left'>Regulation</ttcol>
<ttcol align='left'>Requirement</ttcol>
<ttcol align='left'>ECT Contribution</ttcol>
<c>FDA 21 CFR Part 11</c>
<c>Audit trails recording date, time, operator, actions (11.10(e))</c>
<c>Cryptographic signatures and append-only ledger contribute to audit trail requirements</c>
<c>EU MDR</c>
<c>Technical documentation traceability (Annex II)</c>
<c>ECTs provide signed records of AI-assisted decision sequences</c>
<c>EU AI Act Art. 12</c>
<c>Automatic logging capabilities for high-risk AI</c>
<c>ECTs contribute cryptographic activity logging</c>
<c>EU AI Act Art. 14</c>
<c>Human oversight capability</c>
<c>ECTs can record evidence that human oversight events occurred</c>
<c>MiFID II</c>
<c>Transaction records for supervisory authorities</c>
<c>ECTs provide cryptographic execution sequence records</c>
<c>DORA Art. 12</c>
<c>ICT activity logging policies</c>
<c>ECT ledger contributes to ICT activity audit trail</c>
</texttable>
</section>
<section numbered="false" anchor="examples"><name>Examples</name>
<section numbered="false" anchor="example-1-simple-two-agent-workflow"><name>Example 1: Simple Two-Agent Workflow</name>
<t>Agent A executes a data retrieval task and sends the ECT to
Agent B:</t>
<t>ECT JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
"kid": "agent-a-key-2026-02"
}
]]></sourcecode></figure>
<t>ECT Payload:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://example.com/agent/data-retrieval",
"aud": "spiffe://example.com/agent/validator",
"iat": 1772064150,
"exp": 1772064750,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"exec_act": "fetch_patient_data",
"par": [],
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"ext": {
"pol": "clinical_data_access_policy_v1",
"pol_decision": "approved"
}
}
]]></sourcecode></figure>
<t>Agent B receives the ECT, verifies it, executes a validation
task, and creates its own ECT:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://example.com/agent/validator",
"aud": "spiffe://example.com/system/ledger",
"iat": 1772064160,
"exp": 1772064760,
"jti": "550e8400-e29b-41d4-a716-446655440002",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"exec_act": "validate_safety",
"par": ["550e8400-e29b-41d4-a716-446655440001"],
"ext": {
"pol": "safety_validation_policy_v2",
"pol_decision": "approved"
}
}
]]></sourcecode></figure>
<t>The resulting DAG:</t>
<figure><artwork><![CDATA[
task-...-0001 (fetch_patient_data)
|
v
task-...-0002 (validate_safety)
]]></artwork></figure>
</section>
<section numbered="false" anchor="example-2-medical-device-sdlc-with-release-approval"><name>Example 2: Medical Device SDLC with Release Approval</name>
<t>A multi-step medical device software lifecycle workflow with
autonomous agents and human release approval:</t>
<t>Task 1 (Spec Review Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/spec-reviewer",
"aud": "spiffe://meddev.example/agent/code-gen",
"iat": 1772064150,
"exp": 1772064750,
"jti": "a1b2c3d4-0001-0000-0000-000000000001",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "review_requirements_spec",
"par": [],
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"ext": {
"pol": "spec_review_policy_v2",
"pol_decision": "approved"
}
}
]]></sourcecode></figure>
<t>Task 2 (Code Generation Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/code-gen",
"aud": "spiffe://meddev.example/agent/test-runner",
"iat": 1772064200,
"exp": 1772064800,
"jti": "a1b2c3d4-0001-0000-0000-000000000002",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "implement_module",
"par": ["a1b2c3d4-0001-0000-0000-000000000001"],
"ext": {
"pol": "coding_standards_v3",
"pol_decision": "approved"
}
}
]]></sourcecode></figure>
<t>Task 3 (Autonomous Test Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/test-runner",
"aud": "spiffe://meddev.example/agent/build",
"iat": 1772064260,
"exp": 1772064860,
"jti": "a1b2c3d4-0001-0000-0000-000000000003",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "execute_test_suite",
"par": ["a1b2c3d4-0001-0000-0000-000000000002"],
"ext": {
"pol": "test_coverage_policy_v1",
"pol_decision": "approved"
}
}
]]></sourcecode></figure>
<t>Task 4 (Build Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/build",
"aud": "spiffe://meddev.example/human/release-mgr-42",
"iat": 1772064310,
"exp": 1772064910,
"jti": "a1b2c3d4-0001-0000-0000-000000000004",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "build_release_artifact",
"par": ["a1b2c3d4-0001-0000-0000-000000000003"],
"out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc",
"ext": {
"pol": "build_validation_v2",
"pol_decision": "approved"
}
}
]]></sourcecode></figure>
<t>Task 5 (Human Release Manager Approval):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/human/release-mgr-42",
"aud": "spiffe://meddev.example/system/ledger",
"iat": 1772064510,
"exp": 1772065110,
"jti": "a1b2c3d4-0001-0000-0000-000000000005",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "approve_release",
"par": ["a1b2c3d4-0001-0000-0000-000000000004"],
"ext": {
"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"
]
}
}
]]></sourcecode></figure>
<t>The resulting DAG records the complete SDLC: spec review preceded
implementation, implementation preceded testing, testing preceded
build, and a human release manager approved the final release.
The "ext" object in task 5 carries witness metadata via
the "witnessed_by" extension key.</t>
<figure><artwork><![CDATA[
task-...-0001 (review_requirements_spec)
|
v
task-...-0002 (implement_module)
|
v
task-...-0003 (execute_test_suite)
|
v
task-...-0004 (build_release_artifact)
|
v
task-...-0005 (approve_release) [human]
]]></artwork></figure>
<t>An FDA auditor reconstructs this DAG by querying the audit ledger
for all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
verifying each signature. The DAG provides cryptographic evidence
that the SDLC followed the prescribed process with human oversight
at the release gate.</t>
</section>
<section numbered="false" anchor="example-3-parallel-execution-with-join"><name>Example 3: Parallel Execution with Join</name>
<t>A workflow where two tasks execute in parallel and a third task
depends on both:</t>
<figure><artwork><![CDATA[
task-...-0001 (assess_risk)
| \
v v
task-...-0002 task-...-0003
(check (verify
compliance) liquidity)
| /
v v
task-...-0004 (execute_trade)
]]></artwork></figure>
<t>Task 004 ECT payload:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://bank.example/agent/execution",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772064250,
"exp": 1772064850,
"jti": "f1e2d3c4-0004-0000-0000-000000000004",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"exec_act": "execute_trade",
"par": [
"f1e2d3c4-0002-0000-0000-000000000002",
"f1e2d3c4-0003-0000-0000-000000000003"
],
"ext": {
"pol": "trade_execution_policy_v3",
"pol_decision": "approved"
}
}
]]></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:
H4sIAAAAAAAAA9W923bbVpYo+o6vQNMPIasJSZQl26Er1VuW5Fgpy1ZJclzp
SoYaJEESMQmwAFAyW3GP8xHnA/a37E85X3LmdV0AULZTeTgnoyqxQWBd5ppr
3i9RFAVVWi2SYdg5/ZiM11WaZ+FxnlXJxyq8zj8kWRlO8yI8ScuqSEfrKpmE
R7Mkq9Jx+D4vPkwX+V3ZCeLRqEhuYZD3Z+dXp2FjqE4wjqtklhebYVhWk2CS
j7N4CbNOinhaRVmSZckyzrLoLl2WSZTo99GYv4/29oJyPVqmZQlPq80KPj07
vX4ZZOvlKCmGwQSGHwawgsdBXCQxrOQKhijSatMJ7mCdsyJfr3R9neBDsoGn
k2EQhlFoZgtlNnqKXy3yeBKmE9xutaGnsez9TvfOT9eTtAqrIk4X9Pdxvlwt
0jgbJ/TXIpmtFzGCrtyUVbIsgyBeV/O8oPnh/2E4XS8WDJHjeQGwho/DNwoV
eiMvZnGW/neMC4XNZ5NklWS4tPAyKZO4GM+Tgl6ET9LFMEyTavq/DGB3JkkQ
ZHmxhO9vE5z38uXx08PBof3jU/vHb+0fn8kfvz18sq9/HAz28I9n0ckOziKH
hktoeVzul9GqyKt8nC+GQZBm09oqHh8e6sjPnnz7WCc52B/oaFmqU6QRHUCk
Z4JvXF2cvXx5OqS9Ky7T4SfhRZFP1mM62jP5InxZAJjx+AivT2+TYpNnSdjl
YXodHicuZkk1DOdVtSqHu7vlKp1Ok5003wXMLXfxMMtKnkbxKF9XuzmMdJsm
d7s0AOFjOI0XJaLA6bvo6Cw6Or72V3nJeIHL656+64X7e/sHu4Mnz74N82lY
zZPwdF3kqwRQ4SIuAJ+WeNpxNtGfj/N1Nk4X4SLepNksnOR3WTiPi2WepSUg
W7FeJGUIg8dFlU7TcRovwhQQfLFIAYhj2POR/eHM/eFoXG0BRLIuokXycSfB
lcXwn91kke4Cgu+axTv7x2fR3pNo8JgeWqTHfyJE6eHWPerm6qB4lwG8YIiX
J0fR/uD45eVg4EP1Gv8b7g/6MMQkwe9fJpOkgD1aeJd9nK4K4dvwdJGMqwJg
NoYXxkAVyufus6t0lsUVYFPZDpG7u7udZDwtdmb57S5gXQEb2KW1wPJ2x/N4
VSVFdLYL5Ev/crS7gsmjwaAFVbZA6d3O1U74Ms8nBJuTYj0LjybLNEOyTDuC
18/PXp6dRGdnPjhO0gL2AtcNTmNwsPvkcPf03VfiF6DQMi4+JFUJ+BNO0wwo
GyMTzL7Gr8qwe57C7OHZ2VchziQtdmVZHtoMAG0Oo8HhH482J28vjz57C/d3
9w8PD3Dfk3SWVrBVGIThDH8GVEgXKV0UJCE4jYVJCcCGh12c5/fcIZ7av0P7
0QD+d/DHAwPo0vnJ5efAMXi6+/TgkLAgmaRj2OQkuU3HCR76yeXv2CQP6B/4
02gPz/yP3+Pbi9M316evT89Pry9/8rf6FjjodbJIlklVbMKrVTJGakh7b98U
jIxkkj8w3KCED8vdHH5oo/1btnO8yNeT8A0xQtjDcgUSCNDwl7CbiV5ow0nL
cVpVxGDTCvALiJHHaHOcIQJCkJUxcbuoIslNX9r2ewToywwVXg2iCASZEdKT
cRUE1/O0BI4ypusNBw4YDge+VUbsnh5fl70+nAiIUxU8wR1UOR3Je5WkDA8G
KnK+XlRpeEXyUHia3aZAbYWSkIzWC9zt0kWbODJoQw7DMY2cFSTOgDuA57C4
EISQW5AbwhIIejLph0i7aHDglEz3CYfi8kNgJUJ4nBT9cJUv0vEmTG7jxZrv
BrB8kPKSsk9IaAU+GBZWEMTjIi/LgKWVKmco42vLdSYoBut6sWFoTfDoWXRu
ACsQCN+l1bwpqobjRQyiEe7+h6u3b8L3yYiPJOz+8P66F7Cw1YdzgOMsXQwP
kyweoYDQkE5DODeQIbMK/h84UHKkXHhnHldhuV6t8qJytw9SkJliJyDAr8sk
jOH0kA/hMOPNGKAZzop4NQdCefR9z54Fzl0kKyCxCC86DBV0xylCm4/qgQMJ
YV1JPJ4Dzo5TQsNVDnvhc0LxB+atEgbnFpAbpH5/BiBcl3g6iMglUB1CH3yw
BOFiwYdfbFZVTtuBba2KdJnirUbEOwqz5C54dX19Ec6TGFAJOEWymPQDc5Ei
uUj9EO8bXbMJsxW8rghdnIzgGC/ybFYCCgN+oopgcIaHNogOChDAG27OPCNq
PVqnC8Kw0SIff6CTC+TkAKBwn+CeA9yyvApHcDerMllMEb9gigouW989XgRb
IBgD2lw4VWm63GEKskwnkwXoGo9QojTiN/z9UXieA1iYtgF5+d10wUwZ3t+3
qCCfPulNB9TOR+uyMqocaV1ENxhlqjlohbP5ZxCAzlhfCUClACphfr+47gHY
aTd0FCUqAeMEr7z8MVTlJ2gs11WNYNlKZOf5nVlyGTprhoNHxM7hQREyhQnh
gBchCJYgi4UWU3W5kdkRbCIwT2kTEdMJBznxDF/ld8ktkryG/kv4l1hciScT
uKalpUlA9MbAvqp4BOJRtQG4/DXL73BJd/M8BAEKiRESANBIWCkzY/GtDu6Q
qNzFyHgywDv6q9x0fBqvAA2RdMP1uJsnBAZH1S6Sf66ByDC23CVwC4Q84Jw1
ohASUYD9Xhrq5/IMwMRxkcQIz8UGPlot8g2eRJ7ly3xdMvthIhiMc1g6yH9A
VORMXFUd7x/x9CIlikD4vQIFxV4ii9Fl+P/8X/83zr1Y04W9vzea46dPffir
o/TwA5X54W8B4un9PQqegEw4kADE4XR9JuJI+F2mhztbEuNU+ETL+AOuAMe0
TKdbJglMQd9HdgMwHVKsGL4GnrEAWC7hqODz3s42QcKVE0KVE+gGeWyfACyI
lpT01ixehaOkuksAd1tw1F1vEyFlCudK6Vk+ZxZpFyXgYZyE9wENUoAfkCh6
IoIBzldHU4N1sPujUtYGdB/Zj9Cs7RYNPFa+02KLgm+awk6WJBPi0yPguHBg
eJ64FGKcxS1MzbwgUKEnBtkdqAToi0v8TO8u7dm5N8wWPYYWxGW5LvCCIXkA
Mg7EA6Zbhlco6OBHeMYFIAbAi44HoQj8CXcr+jDe3CKH+5eUzOD1zsnOApE8
QAodPHhKPrcSWcCcEEvbgDkAPzou4sBAw4kjwEcdMl3Cs7QUqTz972TSoVFh
QPrevMNoBIu8Bikk/Hs/hFsMBOeCD/qnPg4K7A1vydt1BfJ7+J87nSDYh0nf
5CgG4qWfOHAnqAgA2oUYNvRtE2SYZiFY4TSRjIhUqWgBx/OYJ2+b0ztUAtAi
zT4Q/QSMZ4aITAKXUOSLxSgGWUGnphEAWrMUCRpTb0SHUxVE8hHinVw0eDkH
EbFcw+KRmDtyO2oX8D7wQk8vs0yb0ZmHIaE/Ga1nMyVFaNoCioMjMCYQHuin
viDm4C1waJ4XdbMYTx9PuwkRVQ1w0CoGwBRRcks3k286Pge5gt7C1bmSEEvH
5RjE6iLN5a5cjUFlpE+PkHeNBUBbqCIqYSRLbFGzSMvqhSzTh937e6CSEf/t
06cefAuytCNKkxSJuGsk6A2TLQQEfD2JZxGgXsr6Jo8g2A03dfyB0Y1xFT+5
TWOHPn5INiWOwkgcsR7Cg5yJlI2vEUGx1N0QasPzAOFgFKaGqf2QRzry5BO2
2B5fW9kYP0XlPOIX5CM6CWBDM/gEhyym8TgJPfEAvuMXIvMCfkxy6RSwn+UW
lKThOiKLLM1J4kO4XRPkcyAv077o5IwYWRMzSfHQfROuIgARh6Pwr8RX5H7o
y8s4g5tNpBXwoUARdpKjRhYmJfLetJwb84f37jGweJwH7uginSaoaCXuG4iS
l4mYQOfpCm/1pUXhYytLBa2ahMNDkOaOgYu3qICwRTjEZRmMZLuEPa4Qsu3m
Oaxb2K/qNHLTYUQALaDKAsm51VHqKgqAZtOqpgAWTEEyhPeIG1fuNYQre1wb
huiv80lhjWOCTnVpL0C+DfSzFKMBKa0ABfgabcj90N44pikzdBxkNOUSJE58
KRglmxx+Ip2T8I6MW3UNXhQPZ5tmpWVQ3xydJeI6EIIJafisjSU0CxM174r0
A6KCOVsY+MBTgA79anRSZBwlyDYkm5WJAyBiD67dhSnpmDZDY7rnbQkTiTFE
UwLLGHmrG0WD1Hq/AHfI5LDhFeJmZHDHimNkgnxMEsmE2FJSjuHaIT6aTxsT
k0AHmIi2C9I7zKvMe6cxoAk67zaOggM/B2QGmgirlJOq8CoDFsLBZCh9ASCQ
mokJh7dEDhscoOVlwgcxP/D0sWAJE06kL/xaMAJxCykmqy6EAI5+g8wJWcst
HiVyd3IqIBNK6e9MB4HCo2wBS+qcv7u67vT5v+Gbt/Tny9O/vTu7PD3BP1+9
Onr92vwhkDeuXr199/rE/sl+efz2/Pz0zQl/DE9D71HQOT/6qcPXo/P24vrs
7Zuj153GfSWUZhmYiDgIvwTyMjBHi9+8OL74P/97cACS979dvjzeHwy+BWmD
//Js8PQA/gK6pFzGPIOD5L+SQAlyaxIXJHKhSB6v0BmANj/A/Dm52+C+ATT/
9A+EzC/D8M+j8Wpw8Bd5gBv2HirMvIcEs+aTxscMxJZHLdMYaHrPa5D213v0
k/d3hbvz8M//ASJjEkaDZ//xl6DOK+EAlswx1mULcQUOSYL1MBgiV3d0aVXi
+nwp2QKmjBWkgy1WHrm1IqWXJOmwlZQEZEcoRvmdpkVOO0YkAVE+Ja5uBWjh
aID8a5S90wwE+lJ0KhTzE/T05yTnI2U7UWvmkVgzv7fWTJ6LzZtWGjNWTQLW
NrHsDhEKZkLZhKFp7aYkgIbE1EXFIgn8AVGRV1IzDN/fi5PfmJwmzFcbFmLS
vkNjKKBFW6LKyn7pEOw2cyzqwCSPvSZxS49/hVuP8LqBSr1crtkkschndCpw
14h1NE4TAAULKhM6PKMO9xnlUDpsCOS+dR4+9g3UgQi8x0bgZZg5qpaZm84G
HmzdLCgWBlywHl19hpuBqbaYGdnKyNOykDy2YhwxTyT35pp8U1ph0sCHmAXM
zWKiO5djr2RzpTvRiuyA8L9VjvYVMcbgqw5A/7kGqTNaJLcJBrf4si3eLpJP
T2hibxM5wHtV+XgfZ1uMYxsR2/B05zFyaLPJFPQ4NLUQFwapn70laMSQ0A/A
aP7Dp0/weeXIywiItEL2ySsDaBWTCJ3vcHw8Ol171l4TxuW4wuCOUq1SViQN
CTfpGvQdwTaeTFLZTM3ehFyWgXHkGrVc9ej+UVPzITGdv3PcgcF1u4lsmxHc
1Sk/Y+AmGJCJpB3PYOc+pqk60u2chfGSA8LCvxPNd3/+qdNzJ2+azt2ZHRQU
UWdVkIAKs6MkAup8Pk5JqGJUIcMOrkAkbvoG30S0lSXRAsjkGs3zVV0xQ4WW
ZKoHjPYt/Mc329f5oCt1utggNjsk6USPSI5GxK/ywOrHvprpmNmZSG8xytMh
XxpFnQxiYjCz5rDc6OJp4RnX0OZjjtod5wucbABVhLB4C309zwGFGlOj8HWa
kWHZszshnVGTkxiXPIMT8Xa6FqfG/nCO/jdRMdiJKiAEMOGVZGqz9TQW8SYp
AjUkkwytIKWfjGgds+GGxqBfANj/8z//A/g4TlO4bFXw79FX//PvwW9q5nxN
s3X1ZvbCrf/8hh/hZ9fD0L94XY5EG+7uVpNdOvjdj72O+80Ff8NX7eErgx/9
ri1tXfaWH25/N+RQaxK4WfnnyDvgXvgPsrFhVMcvAgX4DOPDrBiDup/rXgYN
HLQ8H9z8j38VyAclPF/ZfUe/+v847N6umFkNQ1cuAwQ0UhgTgJ5ZAoGhQxcN
lARUt1h8YzsCevMcg1vnX4EC3Kvgfhg+mqaziO5aybE635m4Yr39HkMlVCg7
n8Ss6vpw1uo2EvLqOu/7QjfK8If3qoWLt99Y7/EXGU8IhyM+98UCx8SvFI1F
BJ/S8eO5XJGFjBohn6bsfX30yJMOLlAKLUFIcMSDiETTEjZ7RIKljWkoP29s
NS5vtBFYnmXseo4JGkb+4a0JLgg7H1JAcRCdYCRQ9UJSb429ifn1egSXRNi1
3RfMni+tyeQbhBOKw2gnloVaK0XZ5ygumL0Dgl9HrE+i52IkidkeSiVNKBrr
uJEOz04cAbG3426QNjHSkCALPgr0EPGjJnyILNS6Hx3W2GgWM2Bh1XwZdj1Q
wnMHlD1aBowLyx7LwOZDq0snNQGYJ30PXJyuIBHvZfyBfatkNBfRnS+pBA3M
yJeBp9+IQNHlpRhUUBTorzQRJzWECiReoMEKad5LmZfOXb1psAj+4wuMSmvE
JwyRavwZJTrLio7+giGK9WXymwjmwhd4UL2f/MWjIY5rwFASWuIr3upVBRIH
DICkgyHZKq2KsIpOw1tQeYlIrkB6+Ixk2FcZTLCX6QEIGlVgAcvofE1EAdVE
Zm6ukmr9ncyqAjYQsq9X7Kkxcvjn5uqkZZuJNMWFByr0kluUbixi+A6LsQDS
JL219sWunFlPRiDLCFsrjK/2WiJzWDrqDcMf9VU5xhaNFREQz9FT1khM8bbe
D9Op7BOwdiUJDp8B+w77YBEOXd+nD2uTCG/BGMFNcuzXvPicSmHZvXX0I4wm
Gp1mDTHoelVeCqtmkpZMYM6jFRt2EeoCxgm7sVjDJPZJ8zELJb1xm13nJZO3
+0eO749ZwZYPEGtbYwNdThYIBYy9l03oO35wZT84BPXSxhqhzwRDRq9ga/FC
NHsABnzCQ3k/hGoXRbprrAwoXDD7I0Ip1/P+0a85HK/49hhD63yJhkNxNhYq
abmaobBCp34tQY2+B0ATAcaMp6v9wyedPj6pNit8YtOP/v3Xu4p/QsYHP3GY
RhzBZYnSSTTYf9wJPvnUhlckdMYsVDZz+jFGrQ9JDUyP9gg1Bot3QEPNSwP1
GhsAdCEvjdzyHQz5x9238Y3tLCMMz4z2yZoWDaJ+PIKJOelncJ14dQQzNJ/B
jUi8Q+xkoIF24LWrzRIDo9H1rusAPT/Zme30w1c4LILz1dXjZwf498PBfq+B
DGQDJklTY5fiUkdF05DJxSCsgYmjIlnB9VFjFBxjDbKGxSfECOsnjM8mHMOw
Tss5B82EzLqYZaIEiAlnZZ+sw/CuiZOxktbY+FIoLCCkLxxpiaCGGA7I1HL0
NYFJxSq9YZZM08JweF/6MOf1lM7rnVgLhNgUpEwv8vxDuF4J6RWXljc0QNTi
Xs1MijcTAHHMriq4mHeVuvztvVzFG2Kdch3LcJRrkG2E+j4MhqzTE65F7Pbj
zGrBzQ9aqWlxj5CV20F5mXXLTMu8njFcUUWjj9MswFDIDemNQZCyFdE5uqsK
bfZvi3eXZxRpBP/VY9zo2bH1Ut1yofD4bZJvaoSFEYsG1hpnMt1QoDW0jpjB
fxn1/8/EUCNmqH/Z/TOAfP6X/+qrcKmL6pTrkYrWYmxzZVmMIcoiFbKdJZL+
h0I4Xw3cbzmeJ2gQ0nsO0tUV/PC6ZFP9u8s3w3fvcMVWz0EZHHjedmCiPQgk
0Ji8mT6Qr+fWi8229nSVwsjdsmcyQAjCL5JxjCtlLzVad5G0EEKSs5BjpxAw
SVnGM7X9kiYr1ipWRTrwrKaGOOzGmM74nonzgoQddopjQGsKj4yTOjEoAN+u
MNkiJf0pRetDjEkb8PxP8L8/kfaHRkl2RoDGmiI6/ulPQ3JRimMBGTyhK9Os
jAUrkd/ISk5RrEmY4Y0SBUA2pfe0MgbDb1jwaRoaTbCBLyAasVBFTw0hQ9y8
i1HUSisVdCQkBy74KJnHi6meGN+RHbNxdq7hzuULm/rbtnn8sWLVDP5hf9li
40lXOrVgaTxFohyHv+YkzYZxZXdNrh620CJ56bUAS3fiCLZ28WxtxllROK+v
d4ny7siRA4GmEVKqROwckzFBmlAmR6TXZSnRijM5d7o3slgK+ieUd3CUYcBv
//yPjqEdCQsoO7B3sSHiUjryZvt7HLe5K6afn3/BYPhTtAsr6+FIMkEqjiEB
MoKec2vBJh97qTSNNkDgBCLJYY7AR0kZwePq2RA745BzvKkUPuEy8aXGW8sg
rJLx1cbxLCpjwDdFmmLOBo7hqvryNc10dkKL7cCzjpGO8Cw0Ssd+T3ezIttz
oW4rHI5Tc+MRWmNHMbJrDDWh7ehFQqoBI4wSvfjwEkWHVzX1Tm8Rr4EljdBQ
J1m4CNggKNXI7pv1Eo5qfAJb1yiVdJmgff9unopYScsB6kn3dIIipHJ8dQ3H
emNMyEs/LHmrHZhTloWCDSbW4uHQpajmiQnixTgbOgGJv+QXfJfzKJnFyPCT
j3Uxr7kNeCcVMxrtyOEOLTKwUHaSEvEI4ZwO8V+Dw3CZZhRgwESDtoMSGEhU
mOgje1iB8gtHlk3IT5xiOLaKHexFjUH5IMPBGJNwUJb9AFgi8QVjdHwhdsBC
RRP3hJVONpp2wu4bAMuLBMZLesKQOJLVWIkI8Ucu5xPo1k+nNC4mCkdDF3yC
UnSy2ARrUBfoqNFhDqv5tUpbWTWJPLNFPiL30jpL/7lOaoY4l7QJcyB40bG6
jBbWTlKCCDQklWHFARJnr1L23JPDibFORDTUvmMi9piZwo7ZDqy3E6o/t3SX
wK5tZ4ldPhs6vEmC5mSk+LVlmtcxUpVqYRx9r9fKBtwZioAk8JK4JBJbMZP+
CkMHEsp4NwelVpY5R4V7AdgxATaAjqiS0hqMkcTBYqJGiF9oJ8G7AaoM3Pe0
tAYSPgOKFkPCg67EiVCcwDK353y1zOfxqPG1MpUEizWMibOag5YcF6ULZZVT
BNSjR202i/tHeHl9TcEK5CKDU5TLQyI+iER3rDdpUJKPhIZtO0dLvIaqfuAl
WIjplg4AhClHLDKBQgJWA03DWQk1yRFssTKg6MIbQL5tdwO3KmlOGodNSqGz
RglTw0jg0GQxCDey0YQis3SETtyAloWEi40TEk2a3JTxNKk2GE43jhdjSq+4
meQo2RJGAulIhgxapRzInlCSZncQnCzWH5mEHd1YJwTEmzMoAV3oCQLuNk8n
pEEuFpyWYJgkv9M9wgx4pVBFMkOVuaCzVSBinQ8CIlyYGvyOVO4vCZAYAHzh
8F5HkCHx34ktwWvpOvNUFEmY0JvzpJXi7TPWDDKgwki3ab4ujbU0UYPsURYm
yxVKKrQ2uISck4LRMGGR57I0AkOW19fgoCdqTyKZoeJhMsF0iFLukcQknVq/
u3V8/RXD7u8f+VH3Joyp1VVfWCclEsRaCD8TGwpB6KC8F+YjpFaUXqBv2uh+
QmxAog9JsirVxISpd+aU5VJP8/Fa5Bo/K6FV0+8HNabpKp2cr6S2WWv1jzkP
ivKs6jEY3hZdAoMEvBHXAASmAw87iIveBXYuqwalyCpAgBPtzs34CkIpCZFK
uJxe3vEipRD6G0xAgdvFN5nGurkd0BUVL5BjgGA6DW/daB6OS+93eNH2t8bq
4T3AsdrKvaBqj+IF1lqG7FQ+E4HSOeHUmCAVU0801ToMf3RfLzaSIRKZvEL9
gXGpZnJRuZAOw90qKgMpBcTJcmIsgcAqV4eSy24TtNJet+0TE5HGhCgeZxeV
L3ZTwRDXiM4SUvHwzL0fGH5KOY901e3LogCEsseyQiPAyLmJlDFZz08Uly5l
WbPa5Z8+nIkzBdITiVAmw70IJY5/hUUSa0yJUVsu0T/HOgGnf1PUM67HDcoR
vU/jcij4HVMDxNgqBCtkJ0ppLbkCPoEu00QQ6haWDDryvKo+saOnsIDUun3A
CLt9c0ArLqBwM18v4+wGyXhyt/WwTNoGvc2z/LqezIhFjEi41i2IeNG+P+eM
rCbGHiE40XTRADWrozHPG/IqxaFl1ajMwWab9+fbg5W04JHz5ww7gsd7e30o
et6HH+XzjKy1iAi+8bhvD/XFvWIelIl9tflhJO1q2Q3fWFhze8qnRJHzzAb5
utUmQqOpeNUmlNSJPFo4pM4zDKpJQUiX/K3LVgpEYJCqQA/rBWKLsPnhDoFU
cDUEQhuE4NliWWfRTGc/gtoXsDT5me6b1X0pf3IaPBBDzduzURoUCkjqueYY
4dEGwuP6fsZlbmwexHptSnwtuW2HmCjjDjkkCB/zVVzT61xslDTuAhOfeP3P
JaISkLxKx6xnyrEtjbHCelp52Zg7YMX/ZFvWSlNtX8agr2J5kWxj7no2wySF
vHCiXoQLv7042gVkzfvhcQK6dT/8+9Hx+et+gJRvDYrMMizzBWF82dO0pYnN
+GkP+HYygAxtFw7J8hQhvIofZPIRMe8Ec1HPTObO/SOUDSKTyvMZrUnTqmzq
jxc0oMmfgZPJIOkL5joDEUpAfxCnAKfGUvUPqtO3ugHtdL5d6/KzbfFdY8/F
KWm8PgtES4ypJuGzg+9Fxj84RA7w5GBdLCLAqBxgF+ELHWuk7JTzONo/fDLM
DkZ/m/00P5++fx+/jv45+/hj8beX8dufb64/lsXxwVm59+OgfDk6uTuezTpS
lAO+p3U5flGLx1a/A8AmxRhWIvqABiyhnejozVH4hhSjM61cCNB9haMemVEv
jbQj4p4sumN28PjZQUeeHw72aX0PumHNCKhkwNE5AVDmJ2A0C9TWY5Su8wxN
xM5GWT8iZjfZNhvyM5RFV1UNTmShS+IPqv1dvTrCKXV/5yeHfXo20Oon9LlA
VKg4UR9MbmRSF9+FOfDtqmxiCdwHQMffjW6M1gbfavV6xKRE9i4DHS8XGNFS
0b0jd/O4lhYfXmp88v0jV0qyl7TxRSOi2VPE7CpJRAskyzKvxdR5IdBGfHV0
dP3O5LwJY7GCmpeC6OSyOpZhoqPzGKPwYwo1ryhIHM30MNWqQ4bJ5yTFOGZV
LseiiRKBR37EFGqNrkJZJLc+JzcAGS/IBYCiTN2k5uoZvpVJlLuSzEs1FRUN
M1UNi96SRiuavFENRc+lIgPkL42UdyMCM5HlqKuHvM+Nm6WyhaSqUtEIMuY6
U8vodF/SWZaz2X+JMoQYWIgDGxNLaSqeTNAJQ3CSaNK+U28Nv0EjTumSCyTy
RZloTgasSYr7MYXtADbvGJcOccEbqlHV6RlrT8tCAj++bILZQWRuNKshqSUn
swr5XUbMpzEtl8zdt4nYY0tQvPqah0GBQjAMBQ4Z844w3WnTSmETIEMcF748
2Pv2CZxVpaXZ8BMcLQDJqxLTAigljo31MwMeBpT7VLYQUXmZVRLPuktD0jEH
PIwmSJPToPwai0Ur3gWiri1zytUKkXuVjtubJ7NjSRYmDIdOpj4CckMflnNk
N4w1rlzgoAwcwjT9SOErTTMTl4HgukC1UhB0tVAyYsE0tY4Ho9kwvzXSYo/C
j9kUY2n/hWNysfx7R9782TGANL5pimxoxLc6Vt/RJ0nDVWXyZ9Ymf1Z1smen
s0pITQU5q6kfkkxuwghzZ81IUEssMQKj1HxXDfebGceADY0Wy3iSUHwkhy+N
VaVD/xSc1FunYOkyqWKS7vCwGMTIQHgVP98sy86Q5VCAqhNxG07Whaox4TJF
EgDcK5uUtA1TxAcOgPDEBb9TVEJTxYxAB5wJK0og7LlsaoJ/XKIJJC42AmkK
0P/5BvGwdrJHZ7vnr6X6nvxMX9xxoh+uZ7SBD47aA0jOvGgNIta1nEATt+GE
7wjBljzBifqTgCf7tnXy9y6mEXLRAmDznO6Ajb4NZZUo1VGaoYS56uIprXy9
mEhQg+fmlRBN9uRGJLL8fAMLA1pqqpY6cCLtokSiUqW3iJX+q3gP1LFAMWDk
OsizaSqpp3w3UI+k28HH4oo+eDdYvIRpX+T5IomJHap53JRoMyYLdojHn8v9
ap0J/afu9q7c6p34Y4jqgxbkFRHUymNjh+fRFYQbBeiV5guZIYX/swQC16KA
u4U7Dl1G6iS2ueEUrpNkWiQJBeWGUkYebRtA+ZbA08LU0R8AVh9AK1fCSYqf
vKjVbzjo7ljNISgFSQhpnXekrv/dC8QTvl4Pf8XEiuGWiA6O/FBzNSswGFjw
8PvqfaLRgQANw8HTp/t7Tw4Gh3v0EKVI8/CpPEQnDIx7eLiXPDvY24uS/W9H
0cFgchDFTwdPooODJ08ODw/gl70BDI1f3Eks7t5oMN6fPI6Sg+lh9OTps2+j
eDSeRMl0b7D/+OAQn3RkXhGUh4jNyDDhNsEBJ3FlnWgogA/Df/zCcxhVYPhZ
5bNV96QhVZ9xB3l9HO/F+7/efMxvDpd77569un7x4s2LN8ev//7iw+xpNIt+
WiXp9z8sD58cyHZRihiG94GaQnE040lgtEfDp/oR9iVYp+YWcGyKzu8OG2s/
WR7VoELEhhV3CJeJ6XkfHMoLBHl8g/nLvvnBMA7LNyxP4FeIujvE32w6MpuO
bg929lE7/lSLwkaBI0JxTOKwvRt0IRfDCcZ+FLoZIdemstT9I7ewlCSf1lNm
5KuXKDC3GgDV5EeKTPPzemHYgH3Mg8GeiE/NKrCqCbBRTwRJdwwRqlLro8fi
wO+vNFDfj8cP3JALju0XVZGHkZhn0dqxzN+LuskGNbcKGR/GO1cssYL0keYT
ELV2QI8Yz2OMc+QUtyNNViql7nG8NVFJTcflwwlL9WQat6avSTCSlCUmhcH3
p9fhbrxKhXBFZM+m49gd7AyCV3lZDUP5jZay49yMoCV7Kdn8MB99P053dnYw
gnZnp7lc7yX0LMNLjWQlmcZLVtJ8KnKm4Hky1pmkpXqIG3shKMWXbMAmnNoN
exCY9wPz9Vb4MlYtCI8lAVQOZtKnoJwA88U2fJaKBZ9FPGs3l8yrQoJmNCAK
03E/tzYMHaoC1qMBm27TCSe7S7StiRhaiRXKFOLC4O77e9dkQXh/NiVTssCI
vDZU48RPSkJsNKt1InyM06Ew8JW7JBVLNLAgqIcTSlAN+kRk4InGb5lQJ3a2
MzELZEAZx8thtjlq2p2gFrT7TRn4rilKOEIv/Y+mNhlZo73ygEQB30qTE8m7
J1EnDh8qhiNRjXQSJAO6IVOwKw9nNTeNvZYkdGvAgZG+tKQpCT3b6shJ2BtA
qFlhrB9Q5XMCB/qY8sLU5Mx4Fg/U1m+JmisjVkD6gYq/qCADtwWUFZu7VB82
tj5xKxpRPtBgD4S5BTE5vG2V5BmadyrfBEYRoEnKJDILvNhmOWwfMzQIkFEq
zfAWs2TpnPUlRqPKPXRwxWxXPD3kL07b7Miy6qDy5NLa7soqWWmF12tGfGzS
IDFn7K/lqDi2aap9XiILa5mDUpaB8kmoZka3mictkWDEjUhulPJt/LncUgtY
UKRrEXE9pQfGJW+Myiyl0Fo1eo8LrdrsZV29mhckK1FimahuKl6CIXcgqgc3
AbUtK8eRRCZiG94tSW+a28WEnUPMKMTaJQLWikoD8G67gkNO0FPdeWWxStGH
vmcU4ngDEydlka1niahL46TiKucFrLPJg3DCTMrrZAlST7wI38qtFfxwgonx
chPs3IkkiCbUpLIZhRSLelYPRxY7jRYppgFWi7X61Ukbnq0LG7bLQbsVqLpU
WDbsOsXUhuHjvVAMJKQ6IuGiw+gTISYKyEsdhv8lLntYTPhnkI/SxYT+zIUg
aK4bnOvGzPVfGp1tJpfgEU6Fs8ujEXwh8TnG2pos4tkaGDQwUdJoQbkP0WKI
LW4E0nxK5AJT+Z57D6B16th/l2N00mVcpIuNGy4aqivXD/7qylkliv8NI3+v
L4U+aRC7gna8YgU+kULWTMDjVFPccYQtOHaAliTmViS/vbR17BAjsJ6+Q0Ud
nqV+s4DzdUGXIMuFxPUrKsGs35RMIWThXLeNmzxUtArWdR64B4eWXtTirIY1
WMh0jh1bEZhTVuKH44jyQnS6tkCaftvGrP/JXDgNi6zZd/pOBJHjlSJibENw
eC7rqvqct5KJsnzqxIDWQ40QAmmmpTxZzmSYSaJTM8AIsc8qzCp+kPGZ4jbE
60VfmySGlnMwwHfiXuBQn1AxalsyDUOlOal0DGh44UpDJhMQ9Rsbxx2yX9Or
tIWcLa9X5yKWxWbkOJxSDzSx/IUcEp1KFWCMQqfoc1NemPDvUUMoNB7vuglq
VSbrSU4WOPVDlub6OzKAkb+lcoT9LpiuMzbSmZBmEEC7VHYV/nVDxKHfShp7
WFFidze8AgEjHAwdoYLjlNDsOLWD7OjJ4OA7cEVpgh1g/r2hwAZoFQCjKPKi
S3ncIKn4fL7TC5w5983BWbpGridlYg5ppfhTevkmJV6Lc1MYtI3kCr9zVjtL
qq75oMdXzRAmxNf1YqG9pfyVu3HTiNXEeYdhJ/z3cNuAxIT+QtMzP2oF+JdN
l2CfLmW9Qj98uD0ehsdEFU3uRdhlOauI0fhDZayXaYWLxKLZKBF9hwJut0fB
DRTd+h2i7w1RV/9AVxjh46COjCBxjY1/lvHHG6oWD2/fmGkBMjIPFpLAjbJE
pI/gwiVtWHOcFhiEX/hFPsX3yIlD7BdE03oQmM8pVLUEYdxcB7s77kZ2Qxs0
B1i6e2zbmm6bNkjzE5rDxuSXHXTAdnt47OaVti2dxx/T5Rr0PQFS/ZTcDbXg
uV3x0Mc5/P2770K7uxp6IYibX6SZrl9fF1rP7+re4smkfnt+zx0DdPbvWQP1
modTR8AteLfljOTtL8c/B2L8s0UqbkXn2pp83V6tTTVqf2GIc0eC0Ma12yoY
ILTeIAaXvsW0Bu68g3zLFbK/UbVfIxtZ1/7I1T7Dt90f1Wzwo5gxpc8vhTDr
LFlOLZ5QrmZrh5aZap3KsTvApC8RfTcrKmpvu6oQ7SnnlISAnEtT8tMySKbY
J5WDEJ2oBrjYabzACqpaOFKaJKCoQ3ERQOZAvLpD6ySPWFeghcuL7IytPWr3
LKjfM1/rGOzBPwwMUb5Ie6M3YeEEH2uDqJ+gWjkczdWIHYGRRbdGPoxx8Mag
jH8lxSi0pdWweGOiSwqQCLJJnFWWolAmjFN/Brkpl6750Y0yun/kWfDYruG+
cKHyRr1Slui0pbVrVJ4pI/RMGX5sExky6nWQgPtJcbLtFk/YMaJGLBYmp4xN
XyjTRgphw3ZtKQ48I9C+UNVDO6ZrqWejwo+1AvhUzUatt7YICUbP18qfiLbd
GIAqlLUNQNIxFXzhthYsB1Od0rBs1n8RTcuMn0gducbQjoYVhx+y/C6TTgkM
GL8AitR+dUJ4akV/DykEAZaS3Lql6fw6K2wZouVYU5eeIMvZ5ghqcIdzZUw/
3NkXmb4OQq0Bt21KlLlJ0cVgKqbdt4Dgk6272qIUqYTLmiTM9k1JQxlchQ24
neHcMb/BPC5WtJ12IabHh3jLxwl3iUbdzhkZLVT98O3x1QUjL9x1iYnnKUZr
bJESrlcoy1PNj6c1TGhHMipUohylVs9ItNpmGbxntaGd0oHueC11T+B7NqzV
ygtbXPWKpH1b34MtDuIViND6B99wsQPTgZB4ui2pwekaNAiH25N9ry9J/uVa
uY7BKxZu7OCNKgpxSclbkvT4XLweplIcHxXbj6VEhaZUGQMRR5D50eRxulhj
BCZ+/l61XlPkQXyNrjm67xgRGQje3hl5bXsFggHAd7C348GXok8lY9UEliin
0jtEMamksg4G/udk7PNT5TOTiw/EhCdnDb5ko0nXZ9AmKJS8n+U8XwB9dhiw
YdcCW1swoCcU8sFpp2vyadDEHlvPsEMLd8DLHMtiGOOFseWEPGQwgk+6xIjK
XE2ENQsh3sXBvgEUO53ElSGBTl0yXfUdQ09fstspY4NosiQpUmG8ZLGI2G+B
YwNLATGEzSA2iU9K8csl4TwTirhzLTB9uychppS/HxeJNwz90rTdaPUbNG99
PsbPt3PhwoFXXQj/rxsuiAHUO2bhN4e0We7CiaVOKISaw839yrhs++OqgG7O
VeiUfHIL69r7A9OIva8hh7B/crs5XUNgA7nB5oVFPptpFiItcrUuVjkHkZ6S
nqGFkQInJJYzRkxkl7kbdX+maQBIjnu17fY5vZJFZzccCvtyLPKSKAwLao0i
mOyHBVEOib5X3tTWz3A9s7auiwnSZV8JUXca4GDvcdgFTWCUToAq9VDXwu9R
tEglOJ3SI00YBQp99JglNBlkEHTfZTaFVMcxlWCb9dR4M5KiwusCgjvKJ5t6
zlwcwhYwOFR0P6GB2P+UY3UDm8PDlj5zJO2oQsL8tesT5h7VtfxGKfAgIDZl
Q9jgWT+bYCo5eg3p21r3tlv76KrfALKi9ebmV+zmoSQNlPEtWjOJGBI/dIOW
VUfRVnMgS+Qsy3VFzLYitjmZHqjxK3wV59Y1qJlKSCR/zVYT/vMOiNjhv33X
EKg9wwlfwm7njLEGNU4r6LDZxw4Isg6aQUS4xrMub4xE3bUv9VqnAEVnno7I
QmaEJmNsey2l/6wkE6hMjcADADTgSSYRmfQD20TQImK/8SyPtcW8y0iCr5U1
7NSAak6Ax0YuKcgAB3Bjfm0c3QN2lNCT2vvOetuhpgdjPqmvkTIqqNMoCee8
UjgYeH4jzxwo9ZtwbJ/3ylEOjPFdxqsvwcrAsNQZJUIGlFgNx4YWJ/jTDVBS
nK15YA5uAbLCqztUe7RlSTaZbQmyP1UUlRbp1/UVSUy0CtZIL0GuFq8T2c3o
oHbgPZ0Vfm8/AB7KiJ48sTNiAxoitIoF0xIK6QtnJqcCgy0zIvHiV6UVnqnX
YGoJ1ud0REx/g/AQvbcsdVGsY7f9vFVYlVEaAI0xeB+ES/JZdDlDKg9J1JRt
WVmxVwMye5C9NYQRW7NnyY0RWreui4t60YTkZ4pneadljr/U53jINbB9Gm8r
dTjUpFCxIqv0H/5jm1D6i7Eo87s+KtTMybqo85RrbvmTsnuE/mgWJ/4ok2Bc
a4GaS0MFrqWgBf5WMQ6KgMRote8cnMHe0eH9JwaxVLqgvLSmNCw/mO3x27K9
9i/sj1v2Da9ryy7zmawaJW1bjKNjDOEw2I73Ok+ihPgf22TtdkH7ly0LU2Ls
zUS6aadxFCiddzVCygbxkIRE8SlO+JPnK/Kci0YY+BIjfavnsdVD1HoHavoE
y2JmY0e++oCJIxLClk41QMkJ6ql5NJsuCuvaYI1Ct9qzTgH2pHteAU9kdMpY
bxHqOHra6yJyZrrt3j9q9NeVoEEJIXXjjUBTsk3gPJ1Jq5JI+zZvhYzFZRXN
8zH8JV5sypQrLlmFy9XUnYbNmKhoCwtwW/FUm4oLPeBKQW4J1iDXpCoTlegH
e1s2lk04FMKI43gaQJADaqabg/a1abPoSXldpz0eKmog3WKGCObKl0GzQzvl
AaaUz6DleP0SEAyOEpXfgMJbeS31dr4msFJFfwluxF1jVpTbbuJBvda3oIhd
nQcXa/mRs0GT/TcM37LnXLUtRRFrneeoLkLxZT5hkyq5Vam4oZjD/ZAxWaRU
Suc6IxgpkVduHBO3YuW7g3HTCQejxthxPK/yTMJLQS9DOw5Vk6b4WVgvu6a0
AwCI2iBpj6hoNKjCzTVohr/xKOGFREt1vFDbBeVZyyrQYEyBhkQJxZ5+1lrz
wZtLFEmtEhHbw2Zjce4ZWbLcTEhp4CSQcgd0NYg6ZWMp+Z5ipLDKc3ieFB8w
ZL1I2M7bXMUoMaBnGzjWDZHufo1CpoENuOXSOxSciy04GTHT8gO1EM4XizVn
/wEVege35hjvBxAeuEER5cNqQ6BSrPU2NMXNLL5NbAYtvLLkIDIKJ5rnd7Ue
xvWOZki92mkK69llEkhIvzs2GwfkRMblc+kxKou0FXTuMBcwMMYA22iwlrDu
1zOod48O2rtHB4EkLtbq6pnWrQo2rho0QvZNu2Q6Gk9s2aqzzNlBn4xhDtJq
5QMhKNSxN8CaiurPcmtEfmI7wnkyIefsSUJe1auT18eU04F4EQRnGSE0vzLh
V8p8Wt1x3jTlohM5tG6NLg7R6wdHZ6YzXolxVxp6b5Mo5oQI5GdywRoohwm1
h1IBVCdmag3oES/8vFdTfaYMbCOo+/uXJ0fR/uD45eVg4PiRBoOdwV43YZPx
/f3pu+j85BJ+lwUEbjEkk8xtohU1Ut3duZpx8LAMaLROrA86JOwoBmg7lC72
TIOtcIUq0mgwKoMQJdrbGyAJwIil8B+/kHgrdTAliO/GBdoNohzLwChBDgkF
RRC0aWv2BSP4DUOVKaVvcPgi7B5jfNn3aBBDEDcWtm8Xpkv1F2j40g0wjzWJ
UWZhINCgpKpld8ub28dftKzjsHuNVkj6W2NJjxtL2veXJH3objAX+KZcp5W3
KHo6xhoqqMuZcoFftLCTsPtinS4mW1Z20FjZY39lI/z4RnD8JkYfYEwavlkd
v2GF2s+f5CuqfXYp9+YcbhS1BPZXdthY2YG/MhlP1+YuySxXruSNzcHfviz7
o+ZEIp5KRiRcFbglmv61S5rMrkwTLWdFdKCbNgnoN6MNrH1nZ+cXT7qWHMeo
nCzGKl0/ROY6KjCLJuDmnAh74CwTuqcmwsMXvgIqma0d7qmvLX2l/Q+9NBPz
KWrD+SThzyirg846VCygAgSqSk361iVjy9vxES/5iLFgN0Vac/wsgV2kTHpP
bNJ+rDgo2dTpJcsDosk0afkhXa1Y6CsSkt4kVPVRCJRVlBGSV3CwS5vTg7AI
Tth9EIf1NtG4BRpA6/Kp6RtreyJvZOdpNd9KZD1ZX+mttz0m4px2RM6CaqOi
X1LacnjY/tgrYKTiUOAWrqZclZ7TWs8VyKn6kN06R1AZLgGAkSxIQ9C720g3
6ovYg/I2MDS2W6eijXceg6zYIGuNtw7CbjuJabx5CKq+f+V74T8Iz2zhhIl/
16aTOBKeyRfNwQTAHsQNPDODMhrgVjReM0qRr3IZrEC0p5IaVGvYIqq5YCzt
OiEg3Geksu13WSDBqgcX9eqKeltt0b5Kk15oJkoPTrVoAu7ASqhGQeFqIUb8
7oKwT/4gfD7asL2Byjsc8e0FlT2C5UWLHFsmu9d1SqWo5BD6fM8cAZ7t0mTE
dKpb0MqcTBKv/q+WGKlVxzIJM7hQLa04jjM3qxXkSGsZoLXQOXxOxBpScNYa
W8DMWJRIJl6xySBUUitkl0rjITEktzo59WuVXtguwPVdHOntKMuSj+HZGShm
qPWzyCXCW6wBlONEWxLb2hUPy7JmlqOz6Oj4GieCq4NC7mAfu7pWObpVx+Ti
pYKB8YqnSLlvFkwwT2fziDQpkIe5PCY5N/PFrTXStlC6B6Y+GDL9GseqHPmX
xGR75JTXP5sTJiOK52MyLU/Uu+swBjsvKgUvqVwMVgG+LmKO/vFVgql5oZIX
lHiaXowa30ebj6nlOG6wHzi45Gf7EnPDiiAWbdv4VWBqp+JmndHErle7yMKt
aeDADlyTxC/piMwqv1wWt0XgcaM3wH/Jve7JSvgDl6P6PaK47u/rxXDx8jlm
PU8O16c3BLgvFXePnVbQ/4IYTsfhLMecjAHRZ9QCjwtxeSPlQdvR17Qu/lIS
d3728uwkOjv79ElunRoofC6lKKn1cHUzSGKUOzC6xpkxTBFPEX+/9sOyYgFT
gJO3l0c1usOX31v7Gbb8GEv5IaFGDxOv10Ky8qkpdsWVrpCNwheTIr2leEmh
WbZITmuxRlNbwL3cWvOH7JZpSeoVsgBq72JA1OdmKi32M00WLyZu4fCWckMc
UB7U0tSxkILJF/TKO36uTM8ozj4YRYTr7hiDdNleqcf7xG/WVKvVMzjcO2zU
6hkcDgZfW6vnW6m8I6V6Jo+xRk/8JBo9HT+Lvt0b7EeTZLoXmTo98KRZqoeq
xcV6IW80hdAr1/MldYMed36RsVsK6Tgn5pTi/1dL6HggZ3XRYl+Uo9VXoB/W
1uCU08K0jvZXpA5WRxes2HyTZlK/SspXBc3SOB6OOuVxzDOnyJRKxE4pBsJc
W4eiXlyrhtIBLaPPTZ2kggCRE06npgxbUl+sMCiGtcBeUb2fG750Jn2U7z2K
Olm+zNclEg4sgzcugRhQSW3WflksWJgfrThg7H1NTm2KbAiPxhxJEoKsn6VV
YfUEANDnAutadkQA04ppWOf1OZLNi0WcYWzIl7P61QJ9q/ixx93xwVeajJCv
UwXQ8ncwdXWscg3R0uPp/OgrpQzg6FdUgecL2PkWCSMuZrl0xvGMkPTk6+1p
F9x55wtsafv9sN2qZjiGtvFx1yWPvlTUCK64rj0KY4KXjaV91pjGOH2jOF4T
xWTYLwWVS2zspRNKY6+oij2sQF7EBVyWZEFFQUqkO+iXEIsVZQoh+iFbx5On
IAXWODkfW1pR0A2hCGNQMkSck7RDGl2LjuBpOa0Ccbh+zeuDOhjc7G+wEAhr
ZkR8NP5YR6z1R9B2ktwVgdKX4Gey8lCKt6ZflzWnVDyZFFL6Ud8fe+87ada4
stka7plUTqCUlMeHh/vqNrmeI7UNz7F+Wj1Hu+Lf4jFVvImLxMxDtCgKz2O0
0SE1lebvKf8sX2Inc02fqiepAFpI0jkXIPHaHmhjRUpDJB7Dvh4UBZH9ABNI
SzWDoO2IGwqgDQF4PrWUtxNTed0ViIEx0Tsvgi4f+R7G+kA4oQQqiG+zoKE1
haLChO1K2jSSf3ljvctiXAusg5glxmpOS1CnqZow1OqBJtB0xcbGBybTlxKn
5EVAbtp4gbPAYqWGT7OgER/9FdYdPaK6o/jja1TsNEvOqUmKKQ0L85uamBEb
vMKlWr5DZtNgau1rxg0zOUrrjrt6Aq82lmCny5hWZGJbUVXq2VE+TRgekd6t
GIBR5zUkHFM5VEYhqbCMIzEuyQokUalMKlppM4aKUxGw/bftrqIB1HAfuGaY
1grWpttE8tCfTbNKOW+/7LXjQqcbRLmsuCbvnMwMxtARl8YXPZHPmt0/qCMm
t+lebGxhKHmfqufvSul7dMgnZa0iEJmFaWpu7aBl1XQEhq/TvsLWniLbcxXb
wG+mJXTVQYTCu49GPglVMF26DVWtmi8HooNqXpxBJ6yQWqUzPF4uuxbpwuwJ
97fF7TjlWSnfx/XBdAIvUi/sYpW6lM1bhBBU4Fyd664Z0y0JLCV/kWJii9i0
EsepxKexlRb28Sq/Q8MsVtbm5AEuwdh6qUw8ZDGUZF2MsQ9sEWBBtnEeIbjM
N5LLoQFfvl4ZGGubEOfYLWNn8hLtJIqWgVvVWGsaH3ELUKc7Lt1DXKkzBLmH
JhJ8i/CCq7vCMtZUyB4YapLN0NDdZhbWMAWfNjmlkDXvREohV6YlwZaiyKHf
Jilx9sWJ4ByS4JbUkmbDITsBkC2OuUxUFlBUgNSFbKKWEwSqDjQXgXS70m7S
poOYNgbh22IGNP+/tUT3BfAi1BawDkApJIeVe+c8R0VOyZKcYGkCDIQom7pO
xmoxkTgkpu8kLWGLcYAPXHhbvMamOef+osiaky/4cxRtFjFG+AL9+CvcJ/bt
kWI0Qx2NbF1Dav1JH1HrD+DXbJtiU442XefC9HD6c5ACTZV6eLGS4keGUdv2
Nu4kTohRWjZii5hHt0cXhbXoIsft4uTAmq0N9cdagIx0zVhh541QrlLfukTd
NoE0BesQTl8jdzfSYowN/hxIR8Cx+8KAT4p5AeVQm5uSPEpdbvlqGEiJPGBS
j9zwTY3BlCwwlzlXyhO+8Zi05A5jHk2zRqzNb7JpChJpV0n1evNDIP5R62DQ
2TCHt9E018nHxsg8ZybHY42ZAk5ut9u/jaO742wTiLS5fYaWlG0vPfszqdlc
xZtcak/a6or2OH/voVwwilyetq7CXcEDeX4JFTRE/7qEfrkJf4FJ+MOltKWR
Iwd1qj9REYNFOipilnRhTFP4zPh/TdOs1o0xFl5yc+UjksCRyt2yYiB4qNyX
u1DUWnaXtZTYw8hNroWLZxtwS7sZp50zy/xaYMTN09ai9lgbg14FKWCdmXwQ
kwZSDk0oqpsrIqaS4M40dJQTQAs1Gy50Uif7mEqOJqYUJ5UcDdy+IWw0Qo+Q
Zn4gqDQxapO4Wc5N05OtiWpjBGV3QlRZUeeyaS6j9OqviuWKK12RThNbnyxV
KeQarl4xTLX/IesEeEwXMWWWckfKnBRBs5pt6OcE5nJJkXxKoEIpO6Ke2Nyx
V+IJq1yqjciwKgG0Ns7WttmB01wT5pmsqYBolbihim1l+DAa0TrFz9MJljW4
MFD19QNazzixdbsjXF5hdPsd6UGtrbLoPcBi0yvr+vUVqUH4X+C/GU9Saq0A
iuAz4Kda14GUnsEwda1Cg4eej/NFeH9/Fp3spEk1jThTsdwvI/3106d+YBZq
zQ+p7UnuFoQLOeH1nNOCLX8ppWj5wT66243DJGPNNeMIW/SdZAlcmJTLNhhv
iqDzBFAyg+UBlLlGFjf4ULxm7er11S7BpWsXTdDtDZWyYEdgVDo+RNSzR9R8
cTsBs9h9f3EddrlEuHHi2zFyisTh0uOmsEI2CUKTbKz2OxPZgBjVdXU9t6Or
GfpSTMO1Jt8Tqm+C1JXaRPHPLDow4qGcZU0kkgbeyqVTtluLJk3xTGr2oJsJ
pGuWBA6p4dILcJPEYF+ZCkr4a4t2hopNgE5jOowtBYFMS6FoQdYKI+gV2HeK
21xhXlfB1aeBX3VBC+cKzJMY83gpfwJkyHlJMSkXdo9ORUSWpEmQeBUXE4qV
MOa2cwpLAu7x6uqcsn8wmARka7jhpDLgeww0SYQgW43D0Gu9+EC/koZctvwJ
fvJuRb2FUaypxAPI4O83RQSpEo5cXGI8XLsHjs3FIkApBNqUJXemwg2GNWAO
H72EWWVqkXBlt7gxHPem9spQSzq+yM0iKzkVXYqElspZWHDYABxSdtWvgUky
fAKBQ+f9csHYS89dmC00vtiYEjewvk7QUnlAnLkS108QeUlWgGO28wRHqtI2
rERAXajCISC5V4zA1hWCNXNhk1omlmkI7HPC3K9hIIUYrJ7vOpAWEt0tISas
KhvWBxq2mK9iMWpYcsFQ3ojst1GNy6/9cM43kK6ZCEx8BR3lRsBPfDRpKklt
eRhB+LlMjDZd6X1Tkx+G72wzwy1qsphqXVtci+UlbLW8kJ2Y1HE/2+VcTyBt
AgL5MLxYilQi9y3WvK6xLbqKo79dV1jDbcSheYCTQ+oyyMZjNQ1wSwtJBBLd
wdiEqcUCKXGinYD8wWTBwHCFICsyQfMTqhxH/amYZwfBAwUjhLqvq9hY1eEI
P6IPFshswPGRH1PQulAFGCw5swIHxOROYKUFFpIUQokAOL3aP3yC9eLgNgTO
bfhsJb6wWYkv2FqJr1E+mfthaeU9KbWHzhap4IwplKbSXlNWFDTGErybkGwj
pALQ3WO+enRxxkwX5WstNWI7DhKI0Z5UaovCGjWwxe+cSvxk599yMqaK3V3M
7QWBlABDQ4KDrfkyIYaUmWqtufKUGiAKQpgQyfAIzcTxeGPCv8XLZWMou6Ra
9DlUo8cwrdea3QmObclyvx44XQqqXc3XkJdlq9RqP/QHWh4Sn99k43mRZxT/
gqsLdedikH9zfdFzu9dyYcX484XVgwcKqwdMCmqmKi9rihBWtlquYqdDCjur
lMvX41e9TVAypjAHjGtPZ/NEqigF/moRi5zppdaay/1t8WVloBoGKrYbhQil
obcUmmflxIIy4OB4ihq3dtf6vEiNsGNPLiFQS8JXXbXY9Ot4w8EKSKnr3SkQ
UfBdKcEVtK60VnUK1HVTe0p7lzIzrnUxwvZKWHwSO6Udmzruagqlk1rWqr+T
1WSBdVcbXV0JxQPJ1ky8PktY7XY7XluTAvdc4H4LVFvbFvoKsRWyeAFRMTMF
RBldSL/JsVNJo3q8Ke9TUbocd+8uOKwFURaOizm9tAgRQ8KXdjwlm27gtFEF
BkidVJ1L6HyIgqbbEzWfBochNztlmxZIKznl59Wa7HJ3OpbNx03/tvY2P5Wo
UzWYymFm1CuFWwZw+SISZ45cvQutTl2KgOuz8YapXE29UskRv3ZTPFd8pl0b
U9ZzKl1RmLeJwyHnVLS9YSgMg5nATi93CiDjSDTX0dhji7qECfRrqet+xSQv
Iv5LqLnjp4UtKvdwanIxCNndx521sVSw7YytqZhdsVCIfO67kEL1JNKOTSM8
Qh/b0q5HsqeIR45YgjYZY8x08ZoKppIul4PKmmCbT6fVuL6+WCS8fMk43+AX
IP6pvCMGeGlqYouHdS/OznoW6c6dNorUxajeWnGrWGE6NVIulDODdrtSPN4J
5Fb6Tbg/3ytSey6LgVpjgODQ3S6SJGZgtd84m63R1OIitcxNhUB8/6apc6b9
s1cNz0XgTpOAHDchvUVeFBlWGENr4GFtShXng+79fVtX9E89XDs7KZhNUU10
FIQzluFFKQu44CWnn3Bu8SKhtH80OFDhnFyy7rmhqeZcEPcPBPGwLSj102wS
LLpVJnSGmibjrWo/J3GgSJUERP4jqsquvi1VwI0Nws2+cq0UMX0WiVYHv4Nw
wU5TbiVhw4eNlsG5W5KdptkUMZn0lzvbMFcDeYAp0YUm7bkiSzdtXNQUrfsg
RRh9eDopcXhnAAYv1wulJbgql5h0/SKsEm0gxENuSS9omGu0OdxiY3UEUdjY
jGGt1wy6QF2QWLCNikMonJbAlrOEqaAoY1yWgIVZ0lFH6yrgHB8dT1fqUkQt
nkK169VrYWBxJPX4m+R3qmQOKL66tDfhP4GCsZOLMyF1wYF/sGoHVnOpIqJj
bnGblwVGOpPSPT6ves7WA1xeo7YVu8cCr8Tio/Ds6M1RG9/GhNQ4vN6sEgRC
yjFxHP+R2sxzmx1ZOC+p1cCGnBEDQHUPLri43e0EZUe/3tQ8uLg44Ge0CuxM
PgyG2u+LF3O1HlXuj34RviC4NMVLtNpeia9haT3sjC0o1vbjacaJ4LUYPHzh
2SitnjvVSeLwh/cSWCF/u3LqLEsF8CD0a4D3pUwjfWFyMABwja6agp6UqtFs
rOm11LxqDxzERSM9xOVsiUU0UYhaIkJPGJVvxG2isiJtNUdnmF2s1WvoFZjA
FzysCYIje4hihubIHfThG1TB75ovWq+jDQUi5SEdOxX8jQAuMa5rMWpI/0sA
md4hN+MPu5JayuNwflzKeTyDKdjq0S17sukwfJkuHL3D/eUcZ6lyIEZTfIcw
FY/UvhOwXMO5kEuURiUKlDN+4CqMmXBP1wUx7NqajucFhtICLr5Jsgzr5wBi
oZPnf2X69x0sunmmhGCNLhv6ErTqt2/whrATlABM7FBe4PUdEWfaMhWo4CA/
CB8hvkZvnp1evyQa4vbTpc64HinBxrr0W+TSjk+/k8J4zXOVxrzaoPyIJ07t
fEEeIn8dOcS6uLqerOsNui9lcZtO0EqF+E2lNI1GpHD7qMQ6/gizAnwI069q
haF4V40r0QdhxW0zzC0MkK6wybsOORZn/hDISdRemlFWe4fUxPfJSNos8PSf
o9C/8XsMR/3LiZVW8RmjyrFBFXh2aUTU34LfhlEUDenfzh+H8ANQ9Qm8bILF
z2z6+2+EbPCfWu0YHM/EtsPPrBTuUuA3cZMHPwQqC79IGyPuUOnI7g9+qqoS
vkUCE6kir+SJfke6iAnT8UdQ7QpefMuC1lcPgQj/GxmuWUJ/ywYDb+ENufg3
CtinpBx5qPH6W7DQROgPW3RmrojICnKjsrefM9XjEHSJyXQ89561Iy4pbCji
PtqTRvHF+3sWhhyNA4kqe+M1Acc2JXb25N4Oa3+qNdrDioMoIyqNgCsI80W6
Kb2Im8YltI5z6TywffBOYC4Ze4Hb7mMXVt7rhLMiX6+4zpCVzVTPA3XAozpW
CqIqS/92+fL42WD/CeUKcAhxSqEZxnchNMIsJ6Y+bb/xOgGB/rCbbYoK/NaC
Q9QCC2VxF3Nrp0z4biJv2kbhAoufG6KtQCXSjbuYvQosw6s9/OHR7D1yUcSt
o7jl/AF5ADAhJ6yi8sHSDRI+GJQlj2TyXYechx1mEX6X89B0OW99/1pDReBE
x/MUA1fQKteIDcFfYSvUfcbGlARfG1RilBo0Eps4Cuo+x2ezXlEp8ZSbc7Na
hbVAMOJAgzSAb9+BytrBANJUvEMk7/2HmKOo2GJaeS5Tjb0H2gCvwQyLxCuh
06EACwxYtuPBndUhnfALdOcEJlsfXoB7OEvEeJJspPN1ZsJEIuwbG/nmycBE
6EpgWl1u9ZKY36LMFe7v7MmNP/045gumAX0dMjUR9Wo/ZgrDefbk28dwBEwv
mfZsHdkcKMa48K2nyDQzWfcIk4V6tgQv/tSkoRsxSjm2MM35ybh8PFEzNc17
HTvjANNrZuJ9xKzQYaiHjoFlmAyOHtx5vJgigYKfljsdjIbCwyWHpNiwyzW6
7NIxudzR9pEsKeQu5mFNUxWSexebAOvEAsfvUp0RXrswHds3FUNRyoo6qshO
6MUeJiSYxuxeTFDobMe1tlE0gs0uDzhVraDwyixvFOHrKx6aNHiq3ullfdjQ
aDLYaKQjHQKl10pUhFlqMEIfzRyB1Z3GWQTj9EL2ht8mxYzoNv2QZj2bbIBh
IoENsKCG70ff75gITjfVSxMxsPpomo0rLciM8qFjL9VKJxw5uMudq1E+M95U
DKpgImm78Vj0koJK1R1pS1jHVkLcQVvKZ7iWobyuxhRCKcfehmjU77QQB8y6
mcB59xHd6QmZXvraTdVQiED9Azsd9t86ZRPonpXtt5RvY/Ntl6rmuNLIKcQQ
sacY9AM0jscUj+Wjneq4Us5QGw5hIZCF1OrkW3r9MYuYDnRAPLq5W+iVBeK1
Xq65nTK7C+PImh4w8wNzeHRgUctthwjxK7BTk1br2DrEXVgmpfRI9WIASeuF
dUaMtnwenNhmwm3sYuuYqDZkjomhO85Xe9iyDbz9WBYGDxOunb0QVBZnCbeA
ffi2PChVe5EyEgaqcElKFNkpd0+cy5QDeYeeyyReKgPFxhRIX0y/ORM1azZk
fLsB9/Cya+KGI3ANRlz0hzeHflh2XQ05p6P9SCh01xwJ5RLioRu7awMDNRDF
7coka3yOlZ38WQD+d7GUR+KR1xmzlYmxQ7q5kGdVndxJiOYM1oFeAaBjGPzX
jBlBTxs+3+qg46xDLGHrW3zIimXUIanSJqzXVHxF1wXeu21XDtsacUYaKxcT
Yd+BGyDqdB5H9UcmuRlXH0HNwbA5d3HWlgvr8cK4laZSt8MmgYhN9QDyABQb
RHBznS1lqHMkJQ3djvQ5YPxIS4cgUjgeVYsN/+4zXIBUEf4ELI/lKTWACmEN
toa+wmykdhNFNcE0fUkTZL7OXu7wgjO3L/aFyspR/6db9wxNdpq72aMEtUA7
OfJ2JFEUcGwjPaMcUsfOXwcogTRowq1QsbFaYV+kPsxQURjtVNVcyGSgmiil
Xz8sB6PzBnX6CKOeQdLBoSiUYJxHmk1u1vicEvaWKTrIGlHSdDzMb/2wem6k
YNViCS5zin9fi9Gz+xbgfk194UBi621hTu47sL+3F6dvrk9fn56fXl/+pKqB
LNKtMC6W1UBLiakGwDF8boGzSTJac40fynDKM/SOMLQpRICDRBC6JRJ+tMei
K7zC9qB38aYcWpXB811TnKV4ZgDbIkK+h/KanpuBAo4SjziBstIyJGTQN1Ff
pbyvfVr94JiAEr2e057aPUX1ipOucBg4vkwfJP55kNcKuSnHzy021gI7CSS3
FCh+RbxRa9JpUQQK/mzWTDd50KZ9q7qmyI5SO+OklQrxL0H7oTPV8J1dDJZG
Me2dQNLqNo4X2wcBTdWsVi1WI071ksiLQnvc8514gTFILGDgztwrwqmGW+S1
F0hLDEBGdpQ6rtsOBrodbhIQ+E0CfIFZ9TRi5JrcVSnNWsbkeg1IV81yrJ6h
HsxGDX89Njlq45wOHmgm0BID4lT9AM7rbFcSK0gPCd0uArx/W7iPjU6B7RsQ
eiSz0RZCSldcHZ9dX4fdqzUFdx7TnKbOfZ/5IckG401fOOS6rLbQMSTcPOA2
i0c5Tqsqcn91tOa4prqbGkaVWUVlvUh05iWvm2DllAJkSuIuXsUsAOQV3wN0
IHBxNdpYQGmKq6p0L6JuJtHoELr8/i2UTEmqvBV2W+zmqshTtTeMyuAkLeeq
uDVmzRWkg+MFtKwYi0KxIm8qzFKuuhNqRTzPBZADR0ySJWjtBC+JD1P1qT6n
u1qTyRKERCwOyxUibRknEq5ZIKMETC5Db/o6Y7iTsPOwpt6NNqwEstE1cDQ7
I+ogRKn49sJ2Ca838yVgU59tNp9o5ls7vDgUsw0ddtiArHmCJs7BhjeQUMOh
SZMUbhyGSlmhkptSU6ga7ttnT0abD5ESVHmE1XM8jLW2BBqCV6+I2HP82rzh
WBSZOUbUBw4CSfkbN27RGI8Imbs190kvoJqHJLbRrLapAVD8mFheucZDLlvh
Fri8ABBI1uwGXZK1AQuOmnRyhy28f3wsCdJ0jY9hPyxabWEH2993SgSJIyUe
oYooncxM9JcqDn2NFRE/d0/vux2n2W4inwZaXLBLKDsn8k49Unx7RSOjrLej
VjPCpDU1R7zeRSkn5mgEt1c5c5++xCebHi1EoGy7DBJzxNbDcSV+65fvJeJq
qx2bovUAkf3v2l8/4gg99ljg+khH9ifEKB68NNJn5pgTb2Cfwuvam906caZ9
TtuV4nsYkdkPH2iG60TjeJ4p+hzjT6lWFn/sl80y8aJthV/oc6M07VBbG6Ql
TgWch9P1Kf1SE++pXQ4m5OslxtyyLqWAEGItlxQl0Ntxm8F72Sg2r8XPuAeR
DfvRbGma2xVOSRYfvIv9ZmArA5rLLhgRFFaCLdwl23FrryGWbLQLoEjemNJQ
+RF8l7pHCXRqxa7Ia0oEgtIQIE6NWyrWPIHTPFchj0Xb0UZkfDRwnIhQxafj
tMgZIngoc2i7pCVlkcOR9FTE2C+JL8ehG72cMCyFo9G9BdkSIFLnedyWK0EA
xXFfbUZFOhmGr/LKSHPEd1VA7KMddsIy1C39ZoRcjEvS7EmEtaAAhVfW4sq2
gJvxrz2tRmrKbcloCsJ6ThNByUO+4WeSl2y2kkljQjMTJjJ1rX5VLpFgkG2E
c5VsrBFlp5JfwyOcQ6T3EWjIi5RzVnTdlGRKTadWFPvCVgs8dYz9qG/4MBrs
LVEepC5tAnDfi2SjnniTbuQjdd1O8fqTtRtnge/xu0xTi+vhXe3HVA84jcnY
IKltWDihUTeCOYqpHRF0f3h7dSpR7aTXsDAt0U9exQig11xRwo9KT1vWABci
z2aoQGGF0DXi4aQlqwO1e3e5o4SaYCS274VJDUK3lq14gfmflGJDkpELpx32
0Rpt3lbChju5WqEVZKtK4hTjE6VhuYzR/lZSIRyjv3lllN3K5ERbbuETTH0t
2poNGaUBs4O42xzl2lGvBZyZVLrngFjzNLnlSEczvObCBk4gbo14LJOY23KY
LlMtjaV+UwBxpMClrR+NASpwh491g/RCYIME+F8wALZm2B+Exy8vMSKnCgcD
9Mu7bZCsZO+W51ezR98UYe5q5f8eBi14FNjlb2xgtAyA+Y1f0NpVarxOLLji
03fh+cklzPFFxf672hygxyBpWEecMOCjs4ibVWGNfA0e0OBRM/nRGcY7YTnt
nXCwT9D6XCcAvw/Ab40a3j6/qpfybp34AIbhNj+2zr+ZdmPmeLBJwAMtAnDK
8/Tl2QlADkHtWMkVYESt0Rd8m5ZsbuNuK7jnGqhrPT2arTN0TJwWa5470G0r
bs7CnJmoiURloyy6i1JuDIlzuU0LkwdoDvfilNrNW1juI/NCOFDhJry+yyPO
vDK9FNqFbylTLKVVS5ESQtO8kF3YHDuSTUrHmKXVhYec4oz8QMJD6xXPQWTF
2tYkGXCGFbBifFLrsk4/feAC4yQDR3EE0mi0v7f/JNrb70jda5ruQrsAP1xc
XQwPO0ANpbY6hdqZ7bXXV29+JRJI3iiwvvfkYNAosA4Pn35tgfW9gVdgfTQY
72OR9YiqrGNB9Wg0niTRdM+WWG8WWJ8mIGjeYM4oLPoGt+rVVueq6SYBDLc8
jyM4lWF2MPrb7Kf5+fT9+/h19M/Zxx+Lv72M395cfyyL44Ozcu/HQflydHJ3
PJvxiCZtzBnk9XG8F+//evMxvzlc7r179ur6xYs3L94cv/77iw+zp9Es+mmV
pN//sDx8ctDZXr99kRKVpdXfcH7HV9Rxd+qjm/LXnpcWkKevugVGGvVd3HdM
/4j3bJHUoBcsc4qFCmGEr0e7GgI9hHEPFvRHfHvShm9Pvhbf9v8AfDPlwbn2
9lcX8h88UMhfynk7jehMofGvwoJrMl9jK2ck5bU2WTs7O9Ee9cpqXp1axyp5
dT/s1nbd43kcOrw/bO10SWKetsk7kl52W40iuOCIrJ/bWmLayoZ3buntILYF
9LUpZjaptXDTVnqYkIMUfuD1hzTdBR9G81oXPcZ0CuzVhmvt2N76HeZSYO+m
30lh48Fof/wYcAyPE/+1Z/8l//gUlvF9ehjFT0ZPI+xYEQHCTyMH4QdNjN/W
Uu3/d3S2tWXn110sxJt9v38niln/Au74OPBFaIOKX1SssYBmC+bs77VgzrO9
r8Wc/T8Ac+oN9nxi+UXo+1DXk0af068/y8egvljS4fU//R1n2TiYLzpOUmjb
DrKN6T178rUH+fgPOMhmF8SvPsr9B45yS3fYrz/Og3qr2N9xiM5xfOb42lqo
tpzj40HLOX47+NpzPPgDzrG9T+VXn6U2I2qj1JebwU/Tt/n7/b+vjg/P//ns
1Yfv//vNx8eT19/evogPyne/nj5N/1rt3V3853g7pW5pyPv1yHAYdlvb9Bo5
5GvxY/t5fwZRPifeHrZgyOHgqzHk8A/AkFp/0q9GjYMHrvmWnsb/cqOqLz2m
sFbUDbZET8MHSAIaNXb/GUdawy0adOibXx6Ut50OSk5Xc5SIuXG4dOfFEitj
TBCqWYb7dWegvkc2X/Q16R/sCHRlWHvb0rv4gQ6opg6ITR1IJdL/0ES7ai14
482+TePgwYry2BmjVfP4wi69Vv/4TKteefFL+vXKq1/atFde39659xdRvLnr
skQ71JsWpyXHd2NVhaTYqPfSdQhyGUntncwx+unkC68xObM5ugLH5oazahJ2
Wnx9pgdwYCqIk/LGRn7BF/Tkc58P0yya/YO+nTOQART3ZtxEwdEUHw9toyST
hMxj/ZCnWz3mVt8jHxFmTHDMbUuLJLkFVIOR6zzXGiW168PcRJX6jBIWhM4/
PyNKuA8aOBp6mBh0ufqY/tPl03FcID18vEjhBgASbBoT7tYmbKCv1+mz5/A9
/BXthasvsxe2NGM09uN/tRcjSrFtiuwzX5GdDhLA8jHxlYMvkX5+Xy9GD2Ie
Z2Pm4C5j/yGtqPbu421SErz6gNBLDSFb2rJ+tanH6QAiERV3uent5PXyo3gZ
p10t4aiGMBtc9OtC+r3+trf7fRQejT9k+R1iAocCbPUesiODIoalDSMndeId
x9VQcrDmVqWFk3EZLwKKZcR1aQqLyV9IMzUhcTs5t8GOJFqZJKt82sw5NekJ
2cT+eFHk8K7kQTn5oOFn8kEbRTsCLdqRlpIjGvy/4hN/sbUcAQA=
-->
</rfc>
Reference in New Issue View Git Blame Copy Permalink