c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a0a3369113875e69e126971974978188bd1c2ce9
ietf-wimse-ect/draft-nennemann-wimse-execution-context-00.xml
Christian Nennemann a0a3369113 Simplify spec: remove sub, move compensation to ext, add RFC 8126 
Restore from pre-linter base (898b0f8) and re-apply targeted
changes to avoid unintended structural rewrites:

- Remove sub claim (always equals iss, adds no information)
- Move compensation_required and compensation_reason to ext keys
- Trim witness attestation section to concise guidance
- Fix ledger-mandatory language in verification step 15 and
  minimal implementation step 5
- Add RFC 8126 to normative references

Policy evaluation claims (pol, pol_decision, pol_enforcer) remain
as registered JWT claims in this spec.

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

3122 lines
134 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 86?>
<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 108?>
<section anchor="introduction"><name>Introduction</name>
<section anchor="motivation"><name>Motivation</name>
<t>The Workload Identity in Multi System Environments (WIMSE)
framework <xref target="I-D.ietf-wimse-arch"/> provides robust workload
authentication through Workload Identity Tokens (WIT) and Workload
Proof Tokens (WPT). The WIMSE service-to-service protocol
<xref target="I-D.ietf-wimse-s2s-protocol"/> defines how workloads authenticate
each other across call chains using the Workload-Identity and
Workload-Proof-Token HTTP headers.</t>
<t>However, workload identity alone does not address execution
accountability. Knowing who performed an action does not record
what was done, what policy was applied, or whether compliance
requirements were evaluated at each decision point.</t>
<t>Regulated environments increasingly deploy autonomous agents that
coordinate across organizational boundaries. Multiple regulatory
frameworks — including <xref target="EU-AI-ACT"/>, <xref target="FDA-21CFR11"/>, <xref target="MIFID-II"/>,
and <xref target="DORA"/> — require structured, auditable records of automated
decision-making and execution (see <xref target="_table-regulatory"/> for a
detailed mapping).</t>
<t>This document defines an extension to the WIMSE architecture that
addresses the gap between workload identity and execution
accountability. WIMSE authenticates agents; this extension records
what they did, in what order, and what policy was evaluated.</t>
<t>As identified in <xref target="I-D.ni-wimse-ai-agent-identity"/>, call context
in agentic workflows needs to be visible and preserved. ECTs
provide a mechanism to address this requirement with cryptographic
assurances.</t>
</section>
<section anchor="problem-statement"><name>Problem Statement</name>
<t>Three core gaps exist in current approaches to regulated agentic
systems:</t>
<t><list style="numbers" type="1">
<t>WIMSE authenticates agents but does not record what they
actually did. A WIT proves "Agent A is authorized" but not
"Agent A executed Task X, under Policy Y, producing Output Z."</t>
<t>No standard mechanism exists to record policy evaluation
outcomes at each decision point in a multi-agent workflow.</t>
<t>No mechanism exists to cryptographically link compensation and
rollback decisions to original actions.</t>
</list></t>
<t>Existing observability tools such as distributed tracing
<xref target="OPENTELEMETRY"/> provide visibility for debugging and monitoring
but do not provide cryptographic assurances. Tracing data is not
cryptographically signed, not tamper-evident, and not designed for
regulatory audit scenarios.</t>
</section>
<section anchor="scope-and-applicability"><name>Scope and Applicability</name>
<t>This document defines:</t>
<t><list style="symbols">
<t>The Execution Context Token (ECT) format (<xref target="ect-format"/>)</t>
<t>DAG structure for task dependency ordering (<xref target="dag-validation"/>)</t>
<t>Policy checkpoint recording (<xref target="policy-claims"/>)</t>
<t>Integration with the WIMSE identity framework
(<xref target="wimse-integration"/>)</t>
<t>An HTTP header for ECT transport (<xref target="http-header"/>)</t>
<t>Audit ledger interface requirements (<xref target="ledger-interface"/>)</t>
</list></t>
<t>The following are out of scope and are handled by WIMSE:</t>
<t><list style="symbols">
<t>Workload authentication and identity provisioning</t>
<t>Key distribution and management</t>
<t>Trust domain establishment and management</t>
<t>Credential lifecycle management</t>
</list></t>
</section>
<section anchor="relationship-to-regulatory-compliance"><name>Relationship to Regulatory Compliance</name>
<t>ECTs are a technical mechanism that can support compliance programs
by providing structured, cryptographically signed execution
records. ECTs do not by themselves constitute compliance with any
regulatory framework referenced in this document.</t>
<t>Compliance with each referenced regulation requires organizational
controls, policies, procedures, validation, and governance measures
beyond the scope of this specification. The regulatory references
in this document are intended to motivate the design requirements,
not to claim that implementing ECTs satisfies these regulations.</t>
<t>ECTs provide evidence of claimed execution ordering and policy
evaluation. They do not independently verify that the claimed
execution actually occurred as described, that the policy
evaluation was correct, or that the agent faithfully performed the
stated action. The trustworthiness of ECT claims depends on the
trustworthiness of the signing agent and the integrity of the
broader deployment environment.</t>
</section>
</section>
<section anchor="conventions-and-definitions"><name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
<?line -18?>
<t>The following terms are used in this document:</t>
<dl>
<dt>Agent:</dt>
<dd>
<t>An autonomous workload, as defined by WIMSE
<xref target="I-D.ietf-wimse-arch"/>, that executes tasks within a workflow.</t>
</dd>
<dt>Task:</dt>
<dd>
<t>A discrete unit of agent work that consumes inputs and produces
outputs.</t>
</dd>
<dt>Directed Acyclic Graph (DAG):</dt>
<dd>
<t>A graph structure representing task dependency ordering where
edges are directed and no cycles exist.</t>
</dd>
<dt>Execution Context Token (ECT):</dt>
<dd>
<t>A JSON Web Token <xref target="RFC7519"/> defined by this specification that
records task execution details and policy evaluation outcomes.</t>
</dd>
<dt>Audit Ledger:</dt>
<dd>
<t>An append-only, immutable log of all ECTs within a workflow or
set of workflows, used for regulatory audit and compliance
verification.</t>
</dd>
<dt>Policy Checkpoint:</dt>
<dd>
<t>A point in a workflow where a policy evaluation outcome is
recorded within an ECT.</t>
</dd>
<dt>Workload Identity Token (WIT):</dt>
<dd>
<t>A WIMSE credential proving a workload's identity within a trust
domain.</t>
</dd>
<dt>Workload Proof Token (WPT):</dt>
<dd>
<t>A WIMSE proof-of-possession token used for request-level
authentication.</t>
</dd>
<dt>Trust Domain:</dt>
<dd>
<t>A WIMSE concept representing an organizational boundary with a
shared identity issuer, corresponding to a SPIFFE <xref target="SPIFFE"/>
trust domain.</t>
</dd>
<dt>Witness:</dt>
<dd>
<t>A third-party entity that observes and attests to the execution
of a task, providing additional accountability.</t>
</dd>
</dl>
</section>
<section anchor="wimse-integration"><name>WIMSE Architecture Integration</name>
<section anchor="wimse-foundation"><name>WIMSE Foundation</name>
<t>The WIMSE architecture <xref target="I-D.ietf-wimse-arch"/> defines:</t>
<t><list style="symbols">
<t>Workload Identity Tokens (WIT) that prove a workload's identity
within a trust domain ("I am Agent X in trust domain Y")</t>
<t>Workload Proof Tokens (WPT) that prove possession of the private
key associated with a WIT ("I control the key for Agent X")</t>
<t>Multi-hop authentication via the service-to-service protocol
<xref target="I-D.ietf-wimse-s2s-protocol"/></t>
</list></t>
<t>The following execution accountability needs are complementary to
the WIMSE scope and are not addressed by workload identity alone:</t>
<t><list style="symbols">
<t>Recording what agents actually do with their authenticated
identity</t>
<t>Recording policy evaluation outcomes at each hop</t>
<t>Maintaining structured execution records</t>
<t>Linking compensation or rollback actions to original tasks</t>
</list></t>
</section>
<section anchor="extension-model"><name>Extension Model</name>
<t>ECTs extend WIMSE by adding an execution accountability layer
between the identity layer and the application layer:</t>
<figure title="WIMSE Extension Architecture Layers" anchor="fig-layers"><artwork type="ascii-art"><![CDATA[
+--------------------------------------------------+
| WIMSE Layer (Identity) |
| WIT: "I am Agent X (spiffe://td/agent/x)" |
| WPT: "I prove I control the key for Agent X" |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| ECT Layer (Execution Accountability) [This Spec]|
| ECT: "Task executed, dependencies met, |
| policy evaluated, outcome recorded" |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| 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</name>
<t>The following claims record policy evaluation outcomes:</t>
<dl>
<dt>pol:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The identifier of the policy rule that was
evaluated for this task (e.g.,
"clinical_data_access_policy_v1"). <bcp14>MUST</bcp14> be present when
"pol_decision" is present.</t>
</dd>
<dt>pol_decision:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The result of the policy evaluation. When
present, <bcp14>MUST</bcp14> be one of the values registered in the ECT Policy
Decision Values registry (<xref target="pol-decision-registry"/>). <bcp14>MUST</bcp14> be
present when "pol" is present. Initial values are:
</t>
<t><list style="symbols">
<t>"approved": The policy evaluation succeeded and the task
was authorized to proceed.</t>
<t>"rejected": The policy evaluation failed. A "rejected" ECT
<bcp14>MUST</bcp14> still be recorded for accountability. An ECT with
"pol_decision" of "rejected" <bcp14>MAY</bcp14> appear as a parent in the
"par" array of a subsequent ECT, but only for compensation,
rollback, or remediation tasks. Agents <bcp14>MUST NOT</bcp14> proceed
with normal workflow execution based on a parent ECT whose
"pol_decision" is "rejected".</t>
<t>"pending_human_review": The policy evaluation requires human
judgment before proceeding. Agents <bcp14>MUST NOT</bcp14> proceed with
dependent tasks until a subsequent ECT from a human reviewer
records an "approved" decision referencing this task as a
parent.</t>
</list></t>
<t>When "pol" and "pol_decision" are absent, the ECT records task
execution without a policy checkpoint. Regulated deployments
<bcp14>SHOULD</bcp14> include policy claims on all ECTs to maintain complete
audit trails.</t>
</dd>
<dt>pol_enforcer:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. StringOrURI. The identity of the entity (system or
person) that evaluated the policy decision. When present,
<bcp14>SHOULD</bcp14> use SPIFFE ID format.</t>
</dd>
</dl>
<t>This specification intentionally defines only the recording of
policy evaluation outcomes. The mechanisms by which policies are
defined, distributed to agents, and evaluated are out of scope.
The "pol" claim is an opaque identifier referencing an external
policy; the semantics and enforcement of that policy are
determined by the deployment environment. Implementations may
use any policy engine or framework (e.g., OPA/Rego, Cedar, XACML,
or custom solutions) provided that the evaluation outcome is
faithfully recorded in the ECT claims defined above.</t>
</section>
<section anchor="data-integrity-claims"><name>Data Integrity</name>
<t>The following claims provide integrity verification for task
inputs and outputs without revealing the data itself:</t>
<dl>
<dt>inp_hash:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A cryptographic hash of the input data,
formatted as "hash-algorithm:base64url-encoded-hash" (e.g.,
"sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The
hash algorithm identifier <bcp14>MUST</bcp14> be a lowercase value from the
IANA Named Information Hash Algorithm Registry (e.g., "sha-256",
"sha-384", "sha-512"). Implementations <bcp14>MUST</bcp14> support "sha-256"
and <bcp14>SHOULD</bcp14> use "sha-256" unless a stronger algorithm is
required. Implementations <bcp14>MUST NOT</bcp14> accept hash algorithms
weaker than SHA-256 (e.g., MD5, SHA-1). The hash <bcp14>MUST</bcp14> be
computed over the raw octets of the input data.</t>
</dd>
<dt>out_hash:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A cryptographic hash of the output data,
using the same format and algorithm requirements as "inp_hash".</t>
</dd>
</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><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>"pol_timestamp": NumericDate. Time at which the policy
decision was made, if distinct from "iat".</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": [],
"pol": "clinical_reasoning_policy_v2",
"pol_decision": "approved",
"pol_enforcer": "spiffe://example.com/policy/clinical-engine",
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"ext": {
"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 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
contains policy claims.</t>
<t>Trust Domain Consistency: Parent tasks <bcp14>SHOULD</bcp14> belong to the
same trust domain or to a trust domain with which a federation
relationship has been established.</t>
</list></t>
</section>
<section anchor="dag-validation-algorithm"><name>DAG Validation Algorithm</name>
<t>The following pseudocode describes the DAG validation procedure:</t>
<figure title="DAG Validation Pseudocode" anchor="fig-dag-validation"><sourcecode type="pseudocode"><![CDATA[
function validate_dag(ect, 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 "pol" or "pol_decision" is present, verify that both are
present and that "pol_decision" is one of "approved",
"rejected", or "pending_human_review".</t>
<t>Perform DAG validation per <xref target="dag-validation"/>.</t>
<t>If all checks pass 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 claims (optional, but must be paired)
if "pol" in payload or "pol_decision" in payload:
if "pol" not in payload or "pol_decision" not in payload:
return reject("pol and pol_decision must both be present")
if payload.pol_decision not in
["approved", "rejected", "pending_human_review"]:
return reject("Invalid pol_decision value")
// Validate DAG (against 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
pol: spec_review_policy_v2 pol_decision: approved
Agent B (Code Generator):
jti: task-002 par: [task-001]
exec_act: implement_module
pol: coding_standards_v3 pol_decision: approved
Agent C (Test Agent):
jti: task-003 par: [task-002]
exec_act: execute_test_suite
pol: test_coverage_policy_v1 pol_decision: approved
Agent D (Build Agent):
jti: task-004 par: [task-003]
exec_act: build_release_artifact
pol: build_validation_v2 pol_decision: approved
Human Release Manager:
jti: task-005 par: [task-004]
exec_act: approve_release
pol: release_approval_policy pol_decision: approved
pol_enforcer: spiffe://meddev.example/human/release-mgr-42
ext: {witnessed_by: [...]} (extension metadata)
]]></artwork></figure>
<t>ECTs record that requirements were reviewed before implementation
began, that tests were executed against the implemented code, that
the build artifact was validated, and that a human release manager
explicitly approved the release. The DAG structure ensures no
phase was skipped or reordered.</t>
<section anchor="fda-audit-with-dag-reconstruction"><name>FDA Audit with DAG Reconstruction</name>
<t>During a regulatory audit, an FDA reviewer requests evidence of
the development process for a specific software release. The
auditing authority retrieves all ECTs sharing the same workflow
identifier ("wid") from the audit ledger and reconstructs the
complete DAG:</t>
<figure title="Reconstructed DAG for FDA Audit" anchor="fig-fda-audit"><artwork><![CDATA[
task-001 (review_requirements_spec)
|
v
task-002 (implement_module)
|
v
task-003 (execute_test_suite)
|
v
task-004 (build_release_artifact)
|
v
task-005 (approve_release) [human, witnessed]
]]></artwork></figure>
<t>The reconstructed DAG provides cryptographic evidence that:</t>
<t><list style="symbols">
<t>Each phase was executed by an identified and authenticated agent.</t>
<t>Policy checkpoints were evaluated at every phase transition.</t>
<t>The execution sequence was maintained (no step was bypassed).</t>
<t>A human-in-the-loop approved the final release, with independent
witness attestation.</t>
<t>Timestamps and execution durations are recorded for each step.</t>
</list></t>
<t>This can contribute to compliance with:</t>
<t><list style="symbols">
<t><xref target="FDA-21CFR11"/> Section 11.10(e): Computer-generated audit trails
that record the date, time, and identity of the operator.</t>
<t><xref target="EU-MDR"/> Annex II: Technical documentation traceability for the
software development lifecycle.</t>
<t><xref target="EU-AI-ACT"/> Article 12: Automatic logging capabilities for
high-risk AI systems involved in the development process.</t>
<t><xref target="EU-AI-ACT"/> Article 14: ECTs can record evidence that human
oversight events occurred during the release process.</t>
</list></t>
</section>
</section>
<section anchor="financial-trading-workflow"><name>Financial Trading Workflow</name>
<t>In a financial trading workflow, agents perform risk assessment,
compliance verification, and trade execution. The DAG structure
records that compliance checks were evaluated before trade
execution.</t>
<figure title="Financial Trading Workflow" anchor="fig-finance"><artwork><![CDATA[
Agent A (Risk Assessment):
jti: task-001 par: []
exec_act: calculate_risk_exposure
pol: risk_limits_policy_v2 pol_decision: approved
Agent B (Compliance):
jti: task-002 par: [task-001]
exec_act: verify_compliance
pol: compliance_check_v1 pol_decision: approved
Agent C (Execution):
jti: task-003 par: [task-002]
exec_act: execute_trade
pol: execution_policy_v3 pol_decision: approved
]]></artwork></figure>
<t>This can contribute to compliance with:</t>
<t><list style="symbols">
<t><xref target="MIFID-II"/>: ECTs provide cryptographic records of the execution
sequence that can support transaction audit requirements.</t>
<t><xref target="DORA"/> Article 12: ECTs contribute to ICT activity logging.</t>
<t><xref target="EU-AI-ACT"/> Article 12: Logging of decisions made by AI-driven
systems.</t>
</list></t>
</section>
<section anchor="compensation-and-rollback"><name>Compensation and Rollback</name>
<t>When a compliance violation is discovered after execution, ECTs
provide a mechanism to record authorized compensation actions with
a cryptographic link to the original task:</t>
<figure title="Compensation ECT Example" anchor="fig-compensation"><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://bank.example/agent/operations",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772150550,
"exp": 1772151150,
"jti": "550e8400-e29b-41d4-a716-446655440099",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"exec_act": "initiate_trade_rollback",
"par": ["550e8400-e29b-41d4-a716-446655440003"],
"pol": "compensation_policy_v1",
"pol_decision": "approved",
"pol_enforcer": "spiffe://bank.example/human/compliance-officer",
"ext": {
"compensation_required": true,
"compensation_reason": "policy_violation_in_parent_trade"
}
}
]]></sourcecode></figure>
<t>The "par" claim links the compensation action to the original
trade, creating an auditable chain from execution through
violation discovery to remediation.</t>
</section>
<section anchor="autonomous-logistics-coordination"><name>Autonomous Logistics Coordination</name>
<t>In a logistics workflow, multiple compliance checks complete
before shipment commitment. The DAG structure records that all
required checks were completed:</t>
<figure title="Logistics Workflow with Parallel Tasks" anchor="fig-logistics"><artwork><![CDATA[
Agent A (Route Planning):
jti: task-001 par: []
exec_act: plan_route
pol: route_policy_v1 pol_decision: approved
Agent B (Customs):
jti: task-002 par: [task-001]
exec_act: validate_customs
pol: customs_policy_v2 pol_decision: approved
Agent C (Safety):
jti: task-003 par: [task-001]
exec_act: verify_cargo_safety
pol: safety_policy_v1 pol_decision: approved
Agent D (Payment):
jti: task-004 par: [task-002, task-003]
exec_act: authorize_payment
pol: payment_policy_v3 pol_decision: approved
System (Commitment):
jti: task-005 par: [task-004]
exec_act: commit_shipment
pol: commitment_policy_v1 pol_decision: approved
]]></artwork></figure>
<t>Note that tasks 002 and 003 both depend only on task-001 and can
execute in parallel. Task 004 depends on both, demonstrating the
DAG's ability to represent parallel execution with a join point.</t>
</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>This section addresses security considerations following the
guidance in <xref target="RFC3552"/>.</t>
<section anchor="threat-model"><name>Threat Model</name>
<t>The following threat actors are considered:</t>
<t><list style="symbols">
<t>Malicious agent (insider threat): An agent within the trust
domain that intentionally creates false ECT claims.</t>
<t>Compromised agent (external attacker): An agent whose private
key has been obtained by an external attacker.</t>
<t>Ledger tamperer: An entity attempting to modify or delete ledger
entries after they have been recorded.</t>
<t>Time manipulator: An entity attempting to manipulate timestamps
to alter perceived execution ordering.</t>
</list></t>
</section>
<section anchor="self-assertion-limitation"><name>Self-Assertion Limitation</name>
<t>ECTs are self-asserted by the executing agent. The agent claims
what it did, and this claim is signed with its private key. A
compromised or malicious agent could create ECTs with false claims
(e.g., setting "pol_decision" to "approved" without actually
evaluating the policy).</t>
<t>ECTs do not independently verify that:</t>
<t><list style="symbols">
<t>The claimed execution actually occurred as described</t>
<t>The policy evaluation was correctly performed</t>
<t>The input/output hashes correspond to the actual data processed</t>
<t>The agent faithfully performed the stated action</t>
</list></t>
<t>The trustworthiness of ECT claims depends on the trustworthiness
of the signing agent. To mitigate single-agent false claims,
regulated environments <bcp14>SHOULD</bcp14> use the "witnessed_by"
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 ("pol", "pol_decision") for
compliance verification</t>
<t>Timestamps ("iat", "exp") for temporal ordering</t>
</list></t>
<t>ECTs are designed to NOT reveal:</t>
<t><list style="symbols">
<t>Actual input or output data values (replaced with cryptographic
hashes via "inp_hash" and "out_hash")</t>
<t>Internal computation details or intermediate steps</t>
<t>Proprietary algorithms or intellectual property</t>
<t>Personally identifiable information (PII)</t>
</list></t>
</section>
<section anchor="data-minimization"><name>Data Minimization</name>
<t>Implementations <bcp14>SHOULD</bcp14> minimize the information included in ECTs.
The "exec_act" claim <bcp14>SHOULD</bcp14> use structured identifiers (e.g.,
"process_payment") rather than natural language descriptions.
The "pol" claim <bcp14>SHOULD</bcp14> reference policy identifiers rather than
embedding policy content.</t>
<t>The "compensation_reason" 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>pol</c>
<c>Policy Rule Identifier</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_decision</c>
<c>Policy Decision Result</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_enforcer</c>
<c>Policy Enforcer Identity</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>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>
</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="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>
<reference anchor="RFC9562">
<front>
<title>Universally Unique IDentifiers (UUIDs)</title>
<author fullname="K. Davis" initials="K." surname="Davis"/>
<author fullname="B. Peabody" initials="B." surname="Peabody"/>
<author fullname="P. Leach" initials="P." surname="Leach"/>
<date month="May" year="2024"/>
<abstract>
<t>This specification defines UUIDs (Universally Unique IDentifiers) --
also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform
Resource Name namespace for UUIDs. A UUID is 128 bits long and is
intended to guarantee uniqueness across space and time. UUIDs were
originally used in the Apollo Network Computing System (NCS), later
in the Open Software Foundation's (OSF's) Distributed Computing
Environment (DCE), and then in Microsoft Windows platforms.</t>
<t>This specification is derived from the OSF DCE specification with the
kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have
been incorporated into this document. This document obsoletes RFC
4122.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9562"/>
<seriesInfo name="DOI" value="10.17487/RFC9562"/>
</reference>
<reference anchor="RFC9110">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="I-D.ietf-wimse-arch">
<front>
<title>Workload Identity in a Multi System Environment (WIMSE) Architecture</title>
<author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
<organization>CyberArk</organization>
</author>
<author fullname="Yaroslav Rosomakho" initials="Y." surname="Rosomakho">
<organization>Zscaler</organization>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>University of Applied Sciences Bonn-Rhein-Sieg</organization>
</author>
<date day="30" month="September" year="2025"/>
<abstract>
<t> The increasing prevalence of cloud computing and micro service
architectures has led to the rise of complex software functions being
built and deployed as workloads, where a workload is defined as a
running instance of software executing for a specific purpose. This
document discusses an architecture for designing and standardizing
protocols and payloads for conveying workload identity and security
context information.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-wimse-arch-06"/>
</reference>
<reference anchor="I-D.ietf-wimse-s2s-protocol">
<front>
<title>WIMSE Workload-to-Workload Authentication</title>
<author fullname="Brian Campbell" initials="B." surname="Campbell">
<organization>Ping Identity</organization>
</author>
<author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
<organization>CyberArk</organization>
</author>
<author fullname="Arndt Schwenkschuster" initials="A." surname="Schwenkschuster">
<organization>SPIRL</organization>
</author>
<author fullname="Yaron Sheffer" initials="Y." surname="Sheffer">
<organization>Intuit</organization>
</author>
<date day="16" month="October" year="2025"/>
<abstract>
<t> The WIMSE architecture defines authentication and authorization for
software workloads in a variety of runtime environments, from the
most basic ones up to complex multi-service, multi-cloud, multi-
tenant deployments. This document defines the simplest, atomic unit
of this architecture: the protocol between two workloads that need to
verify each other&#x27;s identity in order to communicate securely. The
scope of this protocol is a single HTTP request-and-response pair.
To address the needs of different setups, we propose two protocols,
one at the application level and one that makes use of trusted TLS
transport. These two protocols are compatible, in the sense that a
single call chain can have some calls use one protocol and some use
the other. Workload A can call Workload B with mutual TLS
authentication, while the next call from Workload B to Workload C
would be authenticated at the application level.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-wimse-s2s-protocol-07"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references>
<references title='Informative References' anchor="sec-informative-references">
<reference anchor="RFC3552">
<front>
<title>Guidelines for Writing RFC Text on Security Considerations</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="B. Korver" initials="B." surname="Korver"/>
<date month="July" year="2003"/>
<abstract>
<t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="72"/>
<seriesInfo name="RFC" value="3552"/>
<seriesInfo name="DOI" value="10.17487/RFC3552"/>
</reference>
<reference anchor="RFC8693">
<front>
<title>OAuth 2.0 Token Exchange</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="A. Nadalin" initials="A." surname="Nadalin"/>
<author fullname="B. Campbell" initials="B." role="editor" surname="Campbell"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="C. Mortimore" initials="C." surname="Mortimore"/>
<date month="January" year="2020"/>
<abstract>
<t>This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8693"/>
<seriesInfo name="DOI" value="10.17487/RFC8693"/>
</reference>
<reference anchor="RFC9421">
<front>
<title>HTTP Message Signatures</title>
<author fullname="A. Backman" initials="A." role="editor" surname="Backman"/>
<author fullname="J. Richer" initials="J." role="editor" surname="Richer"/>
<author fullname="M. Sporny" initials="M." surname="Sporny"/>
<date month="February" year="2024"/>
<abstract>
<t>This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9421"/>
<seriesInfo name="DOI" value="10.17487/RFC9421"/>
</reference>
<reference anchor="I-D.ni-wimse-ai-agent-identity">
<front>
<title>WIMSE Applicability for AI Agents</title>
<author fullname="Ni Yuan" initials="N." surname="Yuan">
<organization>Huawei</organization>
</author>
<author fullname="Peter Chunchi Liu" initials="P. C." surname="Liu">
<organization>Huawei</organization>
</author>
<date day="20" month="October" year="2025"/>
<abstract>
<t> This document discusses WIMSE applicability to Agentic AI, so as to
establish independent identities and credential management mechanisms
for AI agents.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ni-wimse-ai-agent-identity-01"/>
</reference>
<reference anchor="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 1546?>
<section numbered="false" anchor="related-work"><name>Related Work</name>
<section numbered="false" anchor="wimse-workload-identity"><name>WIMSE Workload Identity</name>
<t>The WIMSE architecture <xref target="I-D.ietf-wimse-arch"/> and service-to-
service protocol <xref target="I-D.ietf-wimse-s2s-protocol"/> provide the
identity foundation upon which ECTs are built. WIT/WPT answer
"who is this agent?" and "does it control the claimed key?" while
ECTs record "what did this agent do?" and "what policy was
evaluated?" Together they form an identity-plus-accountability
framework for regulated agentic systems.</t>
</section>
<section numbered="false" anchor="oauth-20-token-exchange-and-the-act-claim"><name>OAuth 2.0 Token Exchange and the "act" Claim</name>
<t><xref target="RFC8693"/> defines the OAuth 2.0 Token Exchange protocol and
registers the "act" (Actor) claim in the JWT Claims registry.
The "act" claim creates nested JSON objects representing a
delegation chain: "who is acting on behalf of whom." While
the nesting superficially resembles a chain, it is strictly
linear (each "act" object contains at most one nested "act"),
represents authorization delegation rather than task execution,
and carries no task identifiers, policy decisions, or
input/output integrity data. The "act" chain cannot represent
branching (fan-out) or convergence (fan-in) and therefore
cannot form a DAG.</t>
<t>ECTs intentionally use the distinct claim name "exec_act" for the
action/task type to avoid collision with the "act" claim. The
two concepts are orthogonal: "act" records "who authorized whom,"
ECTs record "what was done, in what order, with what policy
outcomes."</t>
</section>
<section numbered="false" anchor="transaction-tokens"><name>Transaction Tokens</name>
<t>OAuth Transaction Tokens <xref target="I-D.ietf-oauth-transaction-tokens"/>
propagate authorization context across workload call chains.
The Txn-Token "req_wl" claim accumulates a comma-separated list
of workloads that requested replacement tokens, which is the
closest existing mechanism to call-chain recording.</t>
<t>However, "req_wl" cannot form a DAG because:</t>
<t><list style="symbols">
<t>It is linear: a comma-separated string with no branching or
merging representation. When a workload fans out to multiple
downstream services, each receives the same "req_wl" value and
the branching is invisible.</t>
<t>It is incomplete: only workloads that request a replacement
token from the Transaction Token Service appear in "req_wl";
workloads that forward the token unchanged are not recorded.</t>
<t>It carries no task-level granularity, no parent references,
no policy evaluation outcomes, and no execution content.</t>
</list></t>
<t>Extensions for agentic use cases
(<xref target="I-D.oauth-transaction-tokens-for-agents"/>) add agent
identity and constraints ("agentic_ctx") but no execution
ordering or DAG structure.</t>
<t>ECTs and Transaction Tokens are complementary: a Txn-Token
propagates authorization context ("this request is authorized
for scope X on behalf of user Y"), while an ECT records
execution accountability ("task T was performed, depending on
tasks P1 and P2, with policy Z evaluated and approved"). An
agent request could carry both a Txn-Token for authorization
and an ECT for execution recording. The WPT "tth" claim
defined in <xref target="I-D.ietf-wimse-s2s-protocol"/> can hash-bind a
WPT to a co-present Txn-Token; a similar binding mechanism
for ECTs is a potential future extension.</t>
</section>
<section numbered="false" anchor="distributed-tracing-opentelemetry"><name>Distributed Tracing (OpenTelemetry)</name>
<t>OpenTelemetry <xref target="OPENTELEMETRY"/> and similar distributed tracing
systems provide observability for debugging and monitoring. ECTs
differ in several important ways: ECTs are cryptographically
signed per-task with the agent's private key; ECTs are
tamper-evident through JWS signatures; ECTs enforce DAG validation
rules; and ECTs are designed for regulatory audit rather than
operational monitoring. OpenTelemetry data is typically controlled
by the platform operator and can be modified or deleted without
detection. ECTs and distributed traces are complementary: traces
provide observability while ECTs provide signed execution records.
ECTs may reference OpenTelemetry trace identifiers in the "ext"
claim for correlation.</t>
</section>
<section numbered="false" anchor="blockchain-and-distributed-ledgers"><name>Blockchain and Distributed Ledgers</name>
<t>Both ECTs and blockchain systems provide immutable records. This
specification intentionally defines only the ECT token format and
is agnostic to the storage mechanism. ECTs can be stored in
append-only logs, databases with cryptographic commitments,
blockchain networks, or any storage providing the required
properties defined in <xref target="ledger-interface"/>.</t>
</section>
<section numbered="false" anchor="scitt-supply-chain-integrity-transparency-and-trust"><name>SCITT (Supply Chain Integrity, Transparency, and Trust)</name>
<t>The SCITT architecture <xref target="I-D.ietf-scitt-architecture"/> defines a
framework for creating transparent and auditable supply chain
records through Transparency Services, Signed Statements, and
Receipts. ECTs and SCITT are naturally complementary: the ECT
"wid" (Workflow Identifier) claim can serve as a correlation
identifier referenced in SCITT Signed Statements, linking a
complete ECT audit trail to a supply chain transparency record.
For example, in a regulated manufacturing workflow, each agent
step produces an ECT (recording what was done, by whom, under
what policy), while the overall workflow identified by "wid" is
registered as a SCITT Signed Statement on a Transparency Service.
This enables auditors to verify both the individual execution
steps (via ECT DAG validation) and the end-to-end supply chain
integrity (via SCITT Receipts) using the "wid" as the shared
correlation point. The "ext" claim in ECTs (<xref target="exec-claims"/>)
can carry SCITT-specific metadata such as Transparency Service
identifiers or Receipt references for tighter integration.</t>
</section>
<section numbered="false" anchor="w3c-verifiable-credentials"><name>W3C Verifiable Credentials</name>
<t>W3C Verifiable Credentials represent claims about subjects (e.g.,
identity, qualifications). ECTs represent execution records of
actions (what happened, in what order, under what policy). While
both use JWT/JWS as a serialization format, their semantics and
use cases are distinct.</t>
</section>
</section>
<section numbered="false" anchor="implementation-guidance"><name>Implementation Guidance</name>
<section numbered="false" anchor="minimal-implementation"><name>Minimal Implementation</name>
<t>A minimal conforming implementation needs to:</t>
<t><list style="numbers" type="1">
<t>Create JWTs with all required claims ("iss", "aud", "iat",
"exp", "jti", "exec_act", "par") and policy claims ("pol",
"pol_decision") when policy evaluation was performed.</t>
<t>Sign ECTs with the agent's private key using an algorithm
matching the WIT (ES256 recommended).</t>
<t>Verify ECT signatures against WIT public keys.</t>
<t>Perform DAG validation (parent existence, temporal ordering,
cycle detection).</t>
<t>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": [],
"pol": "clinical_data_access_policy_v1",
"pol_decision": "approved",
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
}
]]></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"],
"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": [],
"pol": "spec_review_policy_v2",
"pol_decision": "approved",
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
}
]]></sourcecode></figure>
<t>Task 2 (Code Generation Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/code-gen",
"aud": "spiffe://meddev.example/agent/test-runner",
"iat": 1772064200,
"exp": 1772064800,
"jti": "a1b2c3d4-0001-0000-0000-000000000002",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "implement_module",
"par": ["a1b2c3d4-0001-0000-0000-000000000001"],
"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"],
"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"],
"pol": "build_validation_v2",
"pol_decision": "approved",
"out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
}
]]></sourcecode></figure>
<t>Task 5 (Human Release Manager Approval):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/human/release-mgr-42",
"aud": "spiffe://meddev.example/system/ledger",
"iat": 1772064510,
"exp": 1772065110,
"jti": "a1b2c3d4-0001-0000-0000-000000000005",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "approve_release",
"par": ["a1b2c3d4-0001-0000-0000-000000000004"],
"pol": "release_approval_policy",
"pol_decision": "approved",
"pol_enforcer": "spiffe://meddev.example/human/release-mgr-42",
"ext": {
"witnessed_by": [
"spiffe://meddev.example/audit/qa-observer-1"
]
}
}
]]></sourcecode></figure>
<t>The resulting DAG records the complete SDLC: spec review preceded
implementation, implementation preceded testing, testing preceded
build, and a human release manager approved the final release.
The "ext" object in task 5 carries witness metadata via
the "witnessed_by" extension key.</t>
<figure><artwork><![CDATA[
task-...-0001 (review_requirements_spec)
|
v
task-...-0002 (implement_module)
|
v
task-...-0003 (execute_test_suite)
|
v
task-...-0004 (build_release_artifact)
|
v
task-...-0005 (approve_release) [human]
]]></artwork></figure>
<t>An FDA auditor reconstructs this DAG by querying the audit ledger
for all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
verifying each signature. The DAG provides cryptographic evidence
that the SDLC followed the prescribed process with human oversight
at the release gate.</t>
</section>
<section numbered="false" anchor="example-3-parallel-execution-with-join"><name>Example 3: Parallel Execution with Join</name>
<t>A workflow where two tasks execute in parallel and a third task
depends on both:</t>
<figure><artwork><![CDATA[
task-...-0001 (assess_risk)
| \
v v
task-...-0002 task-...-0003
(check (verify
compliance) liquidity)
| /
v v
task-...-0004 (execute_trade)
]]></artwork></figure>
<t>Task 004 ECT payload:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://bank.example/agent/execution",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772064250,
"exp": 1772064850,
"jti": "f1e2d3c4-0004-0000-0000-000000000004",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"exec_act": "execute_trade",
"par": [
"f1e2d3c4-0002-0000-0000-000000000002",
"f1e2d3c4-0003-0000-0000-000000000003"
],
"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:
H4sIAAAAAAAAA9W963bbVpYw+B9PgY/+EbKaoERZsh2mqvqTZTlW2rJVkhxX
upKlBkmQREwCLACUzHbcax5iHmCeZR5lnmT29VwAULJT+THjldgSCZzLPvvs
+yWKoqBKq2UyCjunH5PJpkrzLDzJsyr5WIXX+YckK8NZXoQv0rIq0vGmSqbh
8TzJqnQSvs+LD7Nlfld2gng8LpJbGOT92fnVadgYqhNM4iqZ58V2FJbVNJjm
kyxewazTIp5VUZZkWbKKsyy6S1dlEiX6fjTh96P9/aDcjFdpWcKn1XYNr56d
Xr8Mss1qnBSjYArDjwJYweMgLpIYVnIFQxRpte0Ed7DOeZFv1rq+TvAh2cKn
01EQhlFoZgtlNvoU31rm8TRMp7jdakufxrL3O907f7qZplVYFXG6pN8n+Wq9
TONsktCvRTLfLGMEXbktq2RVBkG8qRZ5QfPD/2E42yyXDJGTRQGwhpfDNwoV
eiIv5nGW/neMC4XNZ9NknWS4tPAyKZO4mCySgh6EV9LlKEyTava/DWAH0yQI
srxYwfu3Cc57+fLk6dHwyP741P74rf3xmfz4bHjwRH789ujJgf44HO7jj2fR
iwFOKOeHq2n5uDwoo3WRV/kkX46CIM1mtQU9PjrSkZ89+faxTnJ4MNTRslSn
SCM6i0iPB5+4ujh7+fJ0RGBQtCY8SMKLIp9uJnTKZ/JG+LIAiONJEoqf3ibF
Ns+SsMvD9Do8TlzMk2oULqpqXY729sp1OpslgzTfAyQu9/Bcy0o+jeJxvqn2
chjpNk3u9mgAQs1wFi9LxIbTd9HxWXR8cu2v8pJRBJfXPX3XCw/2Dw73hk+e
fRvms7BaJOHppsjXCWDFRVwAaq3w4ONsql+f5Jtski7DZbxNs3k4ze+ycBEX
qzxLS8C7YrNMyhAGj4sqnaWTNF6GKeD6cpkCECew52P7xZn7xfGk2gGIZFNE
y+TjIMGVxfDPXrJM9wDX98zinf3jZ9H+k2j4mD60+I9/IsTu0c496ubqoHiX
AbxgiJcvjqOD4cnLy+HQh+o1/hseDPswxDTB918m06SAPVp4l32crgrh3fB0
mUyqAmA2gQcmQCDK79zPrtJ5FleATWU7RO7u7gbJZFYM5vntHmBdARvYo7XA
8vYmi3hdJUV0tgeUTH853lvD5NFw2IIqO6D0bnA1CF/m+ZRg86LYzMPj6SrN
kELTjuDx87OXZy+iszMfHC/SAvYC1w1OY3i49+Ro7/TdV+IXoNAqLj4kVQn4
E87SDIgcIxPMvsG3yrB7nsLs4dnZVyHONC32ZFke2gwBbY6i4dEfjzYv3l4e
P3gLD/YOjo4Ocd/TdJ5WsFUYhOEMPwMqpMuULgqSEJzGwqQEYMOHXZzn99wh
ntq/QwfREP47/OOBAXTp/MXlQ+AYPt17enhEWJBM0wlscprcppMED/3F5e/Y
JA/oH/jTaB/P/I/f49uL0zfXp69Pz0+vL3/yt/oWmOl1skxWSVVsw6t1MkFq
SHtv3xSMjGSSXzDcoIQXy70cvmij/Tu2c7LMN9PwDTFC2MNqDcII0PCXsJup
XmjDSctJWlXEYNMK8AuIkcdoc5whAkKQlTFxu6giIU4f2vV9BOjLDBUeDaII
ZJox0pNJFQTXi7QEjjKh6w0HDhgOB75TXOyenlyXvT6cCEhWFXyCO6hyOpL3
KlQZHgxU5HyzrNLwikSj8DS7TYHaCiUhca0XuNulizZ1xNGGSIZjGpErSJwB
B4DnsLgQhJBbkBvCEgh6Mu2HSLtocOCUTPcJh+LyQ2CFQ/g4KfrhOl+mk22Y
3MbLDd8NYPkg8CVln5DQyn4wLKwgiCdFXpYBSytVzlDGx1abTFAM1vV8y9Ca
4tGzFN0AViAQvkurRVNqDSfLGEQj3P0PV2/fhO+TMR9J2P3h/XUvYGGrD+cA
x1m6GB4mWTxGAaEhqIZwbiBOZhX8HzhQcgReeGYRV2G5Wa/zonK3D1KQmWIQ
EOA3ZRLGcHrIh3CYyXYC0AznRbxeAKE8/r5nzwLnLpI1kFiEFx2GyryTFKHN
R3XPgYSwriSeLABnJymh4TqHvfA5ofgD81YJg3MHyA1Svz8DEG5KPB1E5BKo
DqEPfrAC4WLJh19s11VO24FtrYt0leKtRsQ7DrPkLnh1fX0RLpIYUAk4RbKc
9gNzkSK5SP0Q7xtdsymzFbyuCF2cjOAYL/NsXgIKA36itmBwhoc2iA66EMAb
bs4iI2o93qRLwrDxMp98oJML5OQAoHCf4J4D3LK8CsdwN6syWc4Qv2CKCi5b
3z1eBFsgGAOKXThTabocMAVZpdPpEtSORyhRGvEbfn8UnucAFqZtQF5+N10w
U4afPrWoIJ8/600H1M7Hm7IyWh0pYEQ3GGWqBSiI88UDCEBnrI8EoFIAlTDf
X1z3AOy0GzqKEpWASYJXXn4MVfkJGst1VSNYthLZRX5nllyGzprh4BGxc/ig
CJnChHDAyxAES5DFQouputzI7Ag2EZhPaRMR0wkHOfEMX+V3yS2SvIYqTPiX
WFyJp1O4pqWlSUD0JsC+qngM4lG1Bbj8R5bf4ZLuFnkIAhQSIyQAoJGwUmbG
4lsd3CFRuYuR8WSAd/Sr3HT8NF4DGiLphutxt0gIDI7WXST/3ACRYWy5S+AW
CHnAOWtEISSiAPu9NNTP5RmAiZMiiRGeyy28tF7mWzyJPMtX+aZk9sNEMJjk
sHSQ/4CoyJm4WjveP+LpRUoUgfB7DQqKvUQWo8vw//k//k+ce7mhC/vpk9Ec
P3/uw6+O0sMfqMwPvwWIp58+oeAJyIQDCUAcTtdnIo6E32V6uLMVMU6FT7SK
P+AKcEzLdLplksAU9H5kNwDTIcWK4W3gGUuA5QqOCl7vDXYJEq6cEKqcQDfI
Y/sEYEG0pKSn5vE6HCfVXQK424Kj7nqbCClTOFdKz/I7ZpF2UQIexkl4HtAg
BfgBiaJPRDDA+epoarAOdn9cytqA7iP7EZq126KBx8p3WsxS8E5T2MmSZEp8
egwcFw4MzxOXQoyzuIWpmRcEKvTEILsDlQB9cYWv6d2lPTv3htmix9CCuCw3
BV4wJA9AxoF4wHSr8AoFHXwJz7gAxAB40fEgFIE/4W5FH8abW+Rw/5KSGbze
OdlZIJIHSKHDe0/J51YiC5gTYmkbMAfgR8dFHBhoOHEEeKlDVkz4LC1FKk//
O5l2aFQYkN43zzAawSKvQQoJ/94P4RYDwbngg/6pj4MCe8Nb8nZTgfwe/ueg
EwQHMOmbHMVAvPRTB+4EFQFAuxDDNr9dggzTLAQrnCaSEZEqFS3geB7z5G1z
eodKAFqm2Qein4DxzBCRSeASiny5HMcgK+jUNAJAa54iQWPqjehwqoJIPka8
k4sGD+cgIpYbWDwSc0duR+0Cngde6OlllmkzOvMwJPQn4818rqQITVtAcXAE
xgTCA33VF8QcvAUOzfOibhbj6eNpNyGiqgEOWsUAmCJKbulm8k3Hz0GuoKdw
da4kxNJxOQGxukhzuStXE1AZ6dVj5F0TAdAOqohKGMkSO9Qs0rJ6Icv0YffT
J6CSEf/2+XMP3gVZ2hGlSYpE3DUS9JbJFgIC3p7G8whQL2V9k0cQ7IabOvnA
6Ma4Kq8wxkasdPAbZyJS42qJelhSbqiyYXCAXTAKk77UvsgjHXvCCJtnT66t
IIyvoiYe8QPyEoEdeM4cXsEhi1k8SUJPFoD3+IHIPIAvkxA6A1RnIQXFZrh7
yA9Lc2z4IVylKTI1EI5pX3RMRmasyZSkZei+CTHx/iDCRuF/EBORy6APr+IM
rjHRUTj8AuXVaY7qV5iUyGjTcmFsHd6zJ8DPcR64kMt0lqBWlbhPIP5dJmLv
XKRrvMKXFl9PrOAUtKoNDsNAAjsBlt2i78EW4RBXZTCW7RKquBLHrmvm8Gnh
tarAyLWGEQG0gCpLpN1WIanrIwCabatOAlgwAzEQniPWW7l3Du7nSW0YIrbO
K4W1hAk61UW7AJk0EMtSLASkoQIU4G00GPdDe72YgMzRS5DRlCsQL/GhYJxs
c/iKFEzCO7Jk1dV10TKcbZqVlkF9c3SWiOtw66ekzrPqldAsTMG8K9IPiOTl
bE7gA08BOvStUUCRS5QgyJAgViYOgIgXuEYWJpsT2gyN6Z63pUIksxBNCSwX
5K1uFQ1S6/UC3CH7wpZXiJuRwR2TjREA8gmJH1PiQUk5gWuH+GhebUxM0htg
IhoqSMkwjzKjncWAJui02zraDHwdkM1nKnxRTqrCqwxYCAeToagFgEBqJvYa
3hJ5Z3CAlocJH8TWwNPHgiVMOJG+8GPBGGQrpJispxACOMoMciLkI7d4lMjK
yYOAHCel35kOfgCA35E+0Dl/d3Xd6fO/4Zu39PPl6d/enV2evsCfr14dv35t
fgjkiatXb9+9fmF/sm+evD0/P33zgl+GT0Pvo6BzfvxTh69H5+3F9dnbN8ev
O437SijNAi8RcZB0CeRlYI4W33l+cvF//1/DQxCz/9fly5OD4fBbEC34l2fD
p4fwCyiOchnzDA6SfyXpEYTUJC5IvkL5O16j5R8NfID5C/KtwX0DaP7pHwiZ
X0bhn8eT9fDwr/IBbtj7UGHmfUgwa37SeJmB2PJRyzQGmt7nNUj76z3+yftd
4e58+Od/B/kwCaPhs3//a1DnlXAAK+YYm7KFuAKHJCl6FIyQqzuKs2psfb6U
bO5SxgrSwQ6TjtxaEclLEmvYJErSsCMBo7BO0yKnnSCSgNyeEle30rJwNED+
DQraaQbSeykKFMr0CXr4cxLqkbK9UNPlsZguv7emS56LbZlW9DImTALWLhns
DhEKZkLZhKFpjaQkbYbE1EWfInH7HrmQV1KzAn/6JM59Y1+aMl9tmINJ1Q6N
VYAWbYkqa/alQ7DbbK+o8JI89prELT3+NW49wusG+vNqtWH7wzKf06nAXSPW
0ThNABQsqEzo8Izu22eUQ+mwIX37pnh42bdGByLdnhjplmHm6FVmbjob+GDn
ZkGLMOCC9ejqM9wMTLXDpsgmRZ6WheSJFeOIeSK5N9fkm9IKkwY+xCxgbhYT
3bkc4yTbJt2J1mT0g//WORpTxPKCjzoA/ecGpM5omdwmGNTiy7Z4u0g+fUET
e5vIAd7rysf7ONthCduK2Ianu4iRQ5tNpqC0oV2FuDBI/ewaQYuFxHkARvMP
nz/D65UjLyMg0grZJ68MoFVMI/S0w/Hx6HTtWVVNGJfjCiM5SjVBWZE0JNyk
a9B3BNt4Ok1lMzXjEnJZBsaxa8Fy1aNPj5qaD4np/J7j+wuu2+1huyzergL5
gDWbYED2kHY8g537mKbqSLdzFsYrDgQL/0403/36p07PnbxpJ3dndlBQRJ11
QQIqzI6SCOju+SQloYpRhaw4uAKRuOkdfBLRVpZECyD7arTI13XF7DaNWaa6
x0Lfwn98G32dD7pSp4sNYqBDkk70iORoRPwqD6x+7KuZjk2difQOCzwd8qXR
ysn6JdYxa/vKjS6eFp4lDQ085qjdcb7AowZQRQiLa9DX8xxQqOU0Cl+nGVmR
PSMT0hm1L4klybMuEW+na3FqjLHn6GwTFYM9pgJCABNeSaY2O09jGW+TIlCr
McnQClL6yojWMVtpaAz6BoD9P//zP4CPkzSFy1YF/xZ99Z9/C35Tm+Zrmq2r
N7MX7vzzG76Er12PQv/idTnsbLS3V0336OD3PvY67jsX/A5ftfuvDL70u7a0
c9k7vrj93ZBDrUngZuWfY++Ae+E/yKCGIRy/CBTgNQwGs2IM6n6uLxk0cNDy
fHDzH/8qkMNJeL6y+46+9f9x2L1dM7Maha5cBghopDAmAD2zBAJDhy4aKAmo
brH4xnYEdN05BrfOvwIFuFfBp1H4aJbOI7prJQfm/MXEE+vt9xgqoULZ+Sw2
VNdhs1EfkZBX11PfF7pRhj+8Vy1cXPvGVI/fyHhCOBzxuS8WOCZ+pWgsIviU
jtPO5YosZNQI+SxlV+ujR550cIFSaAlCgiMeRCSalrDZYxIsbQBD+bCx1fi3
0UZgeZax6zn2Zhj5h7cmkiDsfEgBxUF0gpFA1QtJvTX2JubXmzFcEmHXdl8w
e76yJpNvEE4oDqOdWBZqrRRln0O2YPYOCH4dsT6JnothI2Z7KJU0oWhM4UY6
PHvhCIi9gbtB2sRY438s+CiqQ8SPmvAhslDrfnRYY6NZzoGFVYtV2PVACZ87
oOzRMmBcWPZEBjYvWl06qQnAPOl74OJ0BYl4r+IP7Eglo7mI7nxJJUJgTo4L
PP1GuIkuL8UIgqJA56QJL6khVCDBAQ1WSPNeyrx07uo6g0Xwj88xBK0RjDBC
qvFnlOgsKzr+K8Yj1pfJTyKYC1/gQfV++lePhjiuAUNJaImveKtXFUgcMACS
DoZkq7Qqwip6CG9B5SUiuQbp4QHJsK8ymGAv0wMQNKrAApbR+ZqIAqqJzNxc
JdU6N5lVBWwgZMeu2FNj5PDfmauTlm0m0hQXHqjQSz5QurGI4QMWYwGkSXpr
7YtdObOejECWEbZWGMfstYThsHTUG4U/6qNyjC0aKyIgnqOnrJGY4m29H6Yz
2Sdg7VoSGx4A+4AdrgiHru/Ah7VJOLdgjOAmefFrLntOobDs3nr1EUZTDUWz
hhj0syovhVUzSUumMOfxmg27CHUB45TdWKxhEvuk+ZiFkt64y67zksnbp0eO
o49ZwY4XEGtbAwFdThYIBYy9h02cO75wZV84AvXSBhahzwTjQ69ga/FSNHsA
BrzCQ3lfhGoXRbprrAwoXDD7I0Ip1/PTo19zOF7x7TGG1vkSDYfibCxU0nI1
Q2GFTv1aghr9CQBNBBgzna4Ojp50+vhJtV3jJzbt6N9+vav4K2R88BXHZMQR
XJYonUbDg8ed4LNPbXhFQmfMQmUzpx9j1PqQ1MD0aI9QY7B4BzSuvDRQr7EB
QBfy0sgtH2B8P+6+jW/sZhlheGa0T9a0aBD14xFMzEk/g+vEqyOYofkMbkTi
HWInAw20A49dbVcYBY1+dl0H6PnJYD7oh69wWATnq6vHzw7x96PhQa+BDGQD
JklTA5XiUkdF05BJvCCsgYmjIlnD9VFjFBxjDbKGxSfECOsnjJ9NOWBhk5YL
jpAJmXUxy0QJEBPNyj5Zh+FZExRjJa2J8aVQDEBIbzjSEkENMRyQqeXoawKT
ilV6wyyZpoXh8L70Yc7rKZ3XO7EWCLEpSJle5vmHcLMW0isuLW9ogKjFvZqZ
FG8mAOKEXVVwMe8qdfnbe7mOt8Q65TqW4TjXiNoI9X0YDFmnJ1yL2O0HldUi
me+1UtPiHiErt4PyMuuWmZZ5PWO4ooqGGqdZgHGPW9IbgyBlK6JzdFcV2uzf
Fu8uzyisCP7VY9zq2bH1Ut1yofD4XZJvaoSFMYsG1hpn0tpQoDW0jpjBfxn1
/8/EUCNmqH/d+zOAfPHX/+qrcKmL6pSbsYrWYmxzZVkMGMoiFbKdJZL+h0I4
Xw3cbzlZJGgQ0nsO0tUVfPG6ZFP9u8s3o3fvcMVWz0EZHHjebmCiPQgk0Ji8
mT6QrxfWi8229nSdwsjdsmfSPQjCz5NJjCtlLzVad5G0EEKSs5ADpRAwSVnG
c7X9kiYr1ipWRTrwWU0NcdiNMZ3xPRPnBQk77BTH6NUUPjJO6sSgALy7xsyK
lPSnFK0PMWZowOd/gv/+RNofGiXZGQEaa4ro+Kc/jchFKY4FZPCErkyzMhas
RH4jKzmFrCZhhjdKFADZlN7TyhgMv2HBp2loNMEGvoBoxEIVPTVeDHHzLkZR
K61U0JGQHLjg42QRL2d6YnxHBmbj7FzDncsbNuW3bfP4ZcWqGfxhf9ly60lX
OrVgaTxDohyHv+YkzYZxZXdNrh620CJ56bUAS3fiCLZ28WxtxllROK+vd4Xy
7tiRA4GmEVKqROwckzFBmlAmR6TXZSnRijM5d7o3sliK8CeUd3CUYcBP//yP
jqEdCQsoA9i72BBxKR15sv05DtLcE9PPz79g5Psp2oWV9XDYmCAVx5AAGUHP
ubVgk4+9VJpGGyBwApHkmEbgo6SM4HH1bDydccg53lQKn3CZ+EqDq2UQVsn4
auN4FpUxupvCSjFBA8dwVX15m2Y6e0GL7cBnHSMd4VlolI59n+5mRbbnQt1W
OBzn4cZjtMaOY2TXGGpC29GLhFQDRhgnevHhIQoFr2rqnd4iXgNLGqGhTrJw
EbBBUKqR3TebFRzV5AVsXaNU0lWC9v27RSpiJS0HqCfd0ymKkMrx1TUc640x
IS/9sOStdmBOWRYKNphFi4dDl6JaJCZiF+Ns6AQk2JIf8F3O42QeI8NPPtbF
vOY24JlUzGi0I4c7tMjAQtlJSsQjhHM6wr+GR+EqzSjAgIkGbQclMJCoMKtH
9rAG5ReOLJuSnzjF2GsVO9iLGoPyQYaDCWbcoCz7AbBE4gsm6PhC7ICFiibu
CSudbDzrhN03AJbnCYyX9IQhcdiqsRIR4o9dzifQrZ9OaVxMFI6GLvgEpehk
uQ02oC7QUaPDHFbza5W2smoSeebLfEzupU2W/nOT1AxxLmkT5kDwomN1GS2s
naQEEWhIKsPyAiTOXqXsuSeHE2OdiGiofcdE7DENhR2zHVhvJ1R/bukugV3b
zhK7fDZ0eNMEzclI8WvLNI9jpCrVwDj+Xq+VDbgzFAFJ4CVxSSS2Yib9FYYO
JJTxbgFKrSxzgQr3ErBjCmwAHVEl5TAYI4mDxUSNEL/QToJ3A1QZuO9paQ0k
fAYULYaEB12JU6E4gWVu3/HVMq/H48bbylQSrMwwIc5qDloSWpQulFVOEVCP
HrXZLD49wsvrawpWIBcZnKJc7hPxQSS6Y71Jg5J8JDRs2zla4jVU7QMvwVJM
t3QAIEw5YpEJFBKwGmgazkqoSY5gi5UBRRfeAPLtuhu4Vclp0qBrUgqdNUqY
GkYChyZlQbiRjSYUmaUjdOIGtCwkXGyckGjS5KaMZ0m1xXC6SbycUC7FzTRH
yZYwEkhHMmLQKuVA9oSSNLuD4GSx7sg07OjGOiEg3oJBCehCnyDgbvN0Shrk
csk5CIZJ8jPdY0x3VwpVJHNUmQs6WwUiFvUgIMKFqcHvWOX+kgCJAcAXDu91
BBkS/53YEryWrjNPRZGECb05T1op3j5jzSADKox0m+ab0lhLEzXIHmdhslqj
pEJrg0vICSgYDRMWeS5LIzBkeX0NDnqi9iSSGSoeJu1LhyjlHklM0qn1u396
5IfZ77hJD2bCwk1aY82V9pt0vfDQU8MweDQUWUSfIeuoTaTjigepBIgZ8bIz
WaYUNn6DGRaAUYy9NNrN7ZDQsq5yI2XCV+GpG000cWncgNZvvrpvI/ACALi2
CS+i+D1P1rjwyEvkNZGmHCROjf1NjgkLSGg2zo/u48VW0iMik0GnX6Afymze
LkEIM7zi7Rkl4ZSiwWQ5MSb7s77RoTSq2wRNlNdt+8SUm0mSTCWAUNma6Dux
m/SEt5uIDKWp8fDMuu4ZfkbZfYTn9mGRfkPZY1mhBjy2vnLODaxn4ok/k/KJ
Wefw0QDOxJkCL5OE55LVWjiy41xgfmwtCTGqiiU6p1gg5kRnCvnF9bgRKaL0
aFAKRX5jXLxYGuW2huxBKK0ZU8An0GWCABLN0tIAR5hVuT92hHSWDlq3Dxhh
t28OaM2lAm4Wm1Wc3SANS+52HpbJWaCneZZfN9M50ccxSZa6BeGt7ftzzsiq
IewOgRNNlw1Qsy4W87whr1K8OVaHyBxsthluvjFUqQweOb/OsCN4vLfXh0LH
ffhRMovIOlVNf5ErYQ8HN4iZPyba06Y/kXyn2YqOcQwNdL6jT19l4pxnNrDV
KadgZHMKrrTlFITUiQhWtJI6zyqm+rSQLvmtyyo6W+NAqChRwOXIaUPAHQKp
4KpLQ3ZzqFpYQyQL7JrT64cP+9KFpvnSfbOKH2UKzoJ7Aoh5ezZEgeLgSDfV
BBs82kAkyL6fW5gbhZ8szDb5u5bZNSCGyrhjVCuMVl3HNbXGxUdJWS4w74d3
8J0EFAKaV+mE1Sw5wpXR1a2jkReOofNW+k12JW00tdZVDOoaltLItua2Z3OM
0c8LJ+hDJMi3F8d7gLl5PzxJQLXsh38/Pjl/3Q+Q9m1Ajl+Byr4k9C97mrUz
tQkv7fHOTgKMoe4Oj6xZ8MniIVLOC8y7PDOJK58eoZgQmUyWB0QdzSqymS+e
z1wTHQMnkF+i983dBjKUgPgsNnFOA6VKF1STbn0Dytlit9LhZ5bis8aciVPS
eHht+IZwYkrYweci4x4bIQ94crgplhFgVA6wi/CBjiNElYs4Ojh6MsoOx3+b
/7Q4n71/H7+O/jn/+GPxt5fx259vrj+WxcnhWbn/47B8OX5xdzKfd6QABbxP
63LcghaPrXoDgE2KCaxExGGN10EzyfGb4/AN6QVnWqUPoPsKRz02o14aeUdU
FVl0x+zg8bPDjnx+NDyg9d3rhTQjIFGEo3Noj/kKWM0SldUYVYU8Qwups1FW
D4jdTXfNhhwNxdJ1VYMTGaiS+IMqP1evjnFK3d/5i6M+fTbUSh/0upXnJlS8
Cbn7bcLVwIr4LsyBc1dlE0vgPgA6/m50Y7Q2+FarTSMWFTL3GOh4qbCIloru
HbmbJ7UU8PBSw3M/PXLlJHtJG280AnrjwhEA7SpJSAskyTCvhZR5EcBGgHVU
VH3PpHwJa7GimpeB56RyOoZRoqOLGIPQY4q0rihGGq3UMNW6Q3a574ieOVZF
Lj2ieQKBR37EEmhtjkJZJI88Jys46e5kAUdhpm5Rcqmob2SRaJaSrCvyiz0I
DJHysejtGIVGUWRNbGROn3JCPbkLI+XeiMBMZDno6D7na+NmBWLml0xNKpBA
tkxnahmd7ks6z3K2eq9QihD7AjmkjYWhNNU9puiDIDhJMGXfqS2G76ANo3TJ
BRL5okw0JQHWJIXsmMJ2AJsHxqNBXPCG6jF1esbY0bKQwA+vmmJyDFnbzGpI
bsnJqkBuhzHzacxKJWvvbSLmyBJUr76mIVCcDAxDcTPGuiFMdxYI8gPey+nZ
/L8Qx4U3D/e/fQJnVWkZMnwFRwtA9iIzCawb1BLHxPjAgEcBpf6ULURUHmal
xDNu0pB0zAEPo/nBZDMvB82kCcUNOMQvsAgGorCtckpVCpF7lY7XlyezY0kS
IgyHPpY+AnJLL5YLZDeMNa5c4KAMHMIs/SiZNER6fr5BgvDzzarsjFiCSYqB
E6oYTjeFisDhKkXkAbqXTWHfEepwojz8fMMzwCCG0DvZ+JpjY0QBoGmYio+M
lItLJvjjCtXnuNgCU8XRKbL55xvcAWo9ztDHZ3vnr6VGmXxNb9xxhhSuZ7yF
F47bPe9nnpubrnktmco4vJ24B9V9OMFqqoZ4oOa+UZIcZctZhPS3ANh8R4TJ
hi2GskqUByg/S+IDdfGUj7tZTsUb7PnHJLaNXWARMbufb2BhcAtNbUcHTiSX
loiOVXqL5Nl/FL0AapGl4BmyuebZLJWcPfwd7i2GLKGmzscC0jljTYlFRGC6
msOq4XNbq3HJKMJorFnF04SCIjlmaSJef3JK0Twuc/75RgUgmO95ni+TmAi2
2i9NwSyjVrPHMn4oOad1JnRwuWC8cmsp4pchCrhaHlWEJCsxTByqTOCC3QMa
p/lSZkjhf+aRAMgC4ICQ9bRSJ/PI9Xe7VuxZkSQUNRlKfW9UxNMMiNJ/I8O1
Ei7A6gNojlreilQTeVDLk3BU1Ilo78SnJcavTt1S10HqRUoJ56nHJ2Lk+2iH
y51d82pbZREbPb/3P6/uARodkGUUDp8+Pdh/cjg82qcPUc4xHz6VD9FKDuMe
He0nzw7396Pk4NtxdDicHkbx0+GT6PDwyZOjo0P4Zn8IQ+MbdxIsuT8eTg6m
j6PkcHYUPXn67NsoHk+mUTLbHx48PjzCTzoyr4hyI7w1SNLh1sIBJ3FlvRwo
Io7Cf/zCc6CSPnLMy4xeaART4/KBvObaf0aOdcl8q9aVndDjEQ24I1avZbNG
ah49qKe1qmm0DBX93UFen8T78cGvNx/zm6PV/rtnr66fP3/z/M3J678//zB/
Gs2jn9ZJ+v0Pq6Mnh7IUZLij8FNg7IYurdGjPjxiuyYDHZ9gFnZgvjC8ybIm
y3b4EWIgDn8x5xCZc4huDwcHqLp9rkXIop0gQllBYmS9y3Mhd8IJlH0UutH6
16bqz6dHbtEfSQyspzPIWy9Rmmu1T6lFiqTs5uv1Cp0B+/+Gw30pbtcsx6li
KtucRMpxxxANO7X+U6zS+v5Kg6j9WOnAdYdz3LXoMTyMxKOKSon11p7X7Qmo
VlTIWzEWtWJxag1z5NOw2xmAkDtZxBiDxulHx5pIUkoB2nhnEokaOcv7k0nq
iQ5ucVWT/CHpJEwFg+9Pr8O9eJ0KzYrI8krHsTccDINXeVmNQvmOljJwLmzQ
klmSbH9YjL+fpIPBAKMbB4Pmcr2H0OsHDzUSSWQaL5FEc13I1o/nyVhnEkrq
4UdsJKf0SzJRmlBX1yUtMO8H5u2d8GWsWhIeS3KeHMy0TwETAebybPksFQse
RDxr1pWsmEICGjRYBVMlH1obhnVUASt5gE236ZQTkSUS0kRzrMVEYookYeDt
p0+uPk14fzYjO6fAiJwKVH/CTxhBbDSrdaIvjE28MPCVuyTVJNTpG9RDvSTg
AW33MvBUY2tMGEq1SKwdXwaUcbz8Ups/pGXiawGV35SB7zmhZBB0bf9o6kaR
qdSr00YU8K10m5CcaJJy4vC+QiUScUYnQeKfG84Cu/JwVvOG2KlGcj0BEMmq
Cl5aW5LknV01vsRJDRBqVn/qB1SCmsCBvpC8MMURM57FA7V1q6Gqy4gVkAqi
ki9qbyACAMqKQVjKwBpDlHi9jLYQqCMeYW5BTP5YW652jraHyrfPUHRekjKJ
zAIv7lQO28cMDdBilEozvMUsVDpnfYmRgnIPHVwx2xU3BLkz0zYjp6w6qDyR
tLa7skrWWmrzmhEfq+VLPBC7EzliiQ1uajyWqK9aVpekzFOsP9Uz6Gooux+l
Q9yIREYprcWvyy21gAV9pxat1FN6YDzGxuLJUgqtVSOruOKl9frp6tWbKhlj
EmdCBSzxEoy4FUw98ASobVlZLwfbL23orSQkad4NE3YO/6HwV5cIWBMfDcC7
7QoOOQEpdc+KxSpFH3qfUYjd4SaGxSJbzxJRl8ZJ6UuO2d5k03vhhFlu18kK
pJ54Gb6VWyv44QR64uUm2LkTSZprqAk/cwr3FM2sHioqplOtFksDrJcbdfuS
wj3fFDakkgMqK9ByqcJn2HUKXY3Cx/uh2GBIa0TCRYfRJ0JMFJCXOgr/SzzK
sJjwzyAfpcsp/cxJ+jTXDc51Y+b6L42cNZNLbAOnKdnl0Qi+kPgdxkGaDM/5
Bhg0MFFSZtMJlljclNhrRCDNp0T+GZXvuQg8GhFO/Gc5hCRdxUW63LqhfKH6
Gf3aoF05q0Txv2GB7vWlCCMNYlfQjlesuydSUZgJeJxq+jGOsAPHDtFYxdyK
5LeXtsYYYgQWNneoqMOz1KkTcC4l6BJktJCYa0UlmPWbkimELJxranG1/YpW
wbrOPffgyNILidbSIKBRDRbkBdXcgdgqaLviWgBh2oM6LNxqO7HeECNsTaj0
eEtIi41ocXwkRH3d0Axj58FXHnKdCRH2YvE46iWo5VTgd1pWkeVKhhFuohHr
YoovG61dxQ2KRKMwAnXBmGByC3OlEgx3LxIDju8J1f+1haswYJVT+yaAcBeu
3GPysVCTsdG0IbvXvHpHyMPyeo0kYk5s14vDGbWdEjNiyIGpqdRixVhgigE2
RV4J0x41xD/jeK3bmdZlspnmZGZTd1hpLrrD7Y2kLfn79r1gtsnYEmcCS0HU
7FLxS/jrhshAv5UI9jCvf28vvAJRIhyOHPGBY2fQtjizgwz0bHDwAVxGmmAA
bL43EtgAVQJgFEVedCmbFmQSn6N3eoEz54E5OEvByAOi7MohokiWGVduUuKq
ODcFo9qQovAvzmrnSdU1L/SY2xoShNi6WS61nY+/cjd6Fakn8dhR2An/Ldw1
ILGbv9L0zHlaAf5l0yXYGkmZrBAOH26PR+EJ0T8TAR92WaIqYjTzUDHhVVrh
IrF0Mco+f0FRttsjHzuFWf4F0feG6Kh/oGsMNHFQR0aQALvGn1X88YYKdMPT
N2ZagIzMg+n8uFGWffQjuHBJG9acpAWGQhd+qUVxgXH6Brun0E4fBOZ1ipks
Qew218HujhtA3dAGzQGW7h7btqbbpg3S/ITmsDH5ZoB+wG4Pj9080ral8/hj
utqAZidAqp+Su6EWPLcrHvk4h9//5S+h3V0NvRDEzTfSTNevjwuV52d1b/F0
Wr89v+eOATr796yBes3DqSPgDrzbcUby9JfjnwMx/toiFXf/cq1KvhavdqUa
tb8wxLkjsVCT2m0VDBBabxCDC5BicDk3O0G+5YrT36iCryF2rFV/5JqL4dvu
j2og+FEMltJllWJpdZYsp646KEGzXUOL/bRO5VgYYNKXiL7bNZUWt40siPaU
C8qfQs6lidFpGSQzbE3JsXCOcx0udhovsY6llu9DY0XysUIZh9zzQObyApNI
EhmxrioLlxcpGbsp1O5ZUL9nvn4x3Ic/DAxRs0hPoydh4QQfa22on6DaMxwd
1YgdgZE6dzrgJzh4Y1DGv5Jc5W3JDSzemCCHAiSCbBpnlaUolI/gVAFBbsoF
RH50g10+PfJsdWzBcB+4UHmjXq9ItNfSWjAqz2gRekYLP8SGTBb1ajTA/aRE
1G7bJuwYUSMWW5JTTKQvlGkr5Yhhu7YgAp4R6Fmo1KHF0rXJs/ngx1oZcqop
onZaWwoCw7hrRShEr24MQHWi2gZASshlN7i5AOfXUrXIsGxW4RCdyoyfSDWv
xtCOLhWHH7L8LpN69QwYvwyFVOB0IklqpVePKJ4BlpLcugXC/GoXbAOi5Vij
lp4gy9nmCGpwh3NlTD8aHIhMXwehVuLaNSXK3KTSJolK5LeA4NOdu9qhDqmE
yzojzPZNSUMZXIUNuM243DHh0Q/SqMZp2mA6LYhLfJJwY15U7JyR0RbVD9+e
XF0w8sJdl+BsnmK8wUYV4WaNsjxVXnhaw4R2JKNyEcpRalVlRLVqFiN7Vhva
KeDmjtdSfQLeZxNarcirxVWvVNW39T3YEg1emr5moX/DKeem6RvxdFvYgPMG
aBCO+iZLXl9SrcuNch2DVyzc2MEbuexxSVlEknr2nfg3TL0uPiq2FEuhAM3t
MaYgDmTyg5rjdLnBQEB8/b3qvCbVXryKruG575gLGQje3hl5bZF7ggHAd7g/
8OBLQZASFm+iR5RT6R2i0EhSWYdD/3Uy6/kJy5nJiAZiwpOz/l6y1t/1GbSJ
TSQ/Z7nIl0CfHQZs2LXA1qZt94RC3jvtbEPeC5rYY+sZ9sngpmOZY0MMY7ww
tqiLhwxG8ElXGNiXqzGwZgvEuzg8MIBi95I4LSRqqktGqr5j4elLjjElDhBN
lswxKk+WLJcReyhwbGApIIZwSgMZlXbk1PW9BhqULt02On3bHESS5fzYCjdx
rL/booWrBMZ0Icy+bqUgal/vSITvHNHOuMshVpegsF0OcfaLkbJJjwuxGdGK
1mer7Li1TO1lgWnEjNcQOtjtuNtKrmGXgVxX88Ayn881940Wud4U65wDF09J
qdBaNIEThslZCiZWy1yEupvSNFgjf7yabPuc1MdyshvghK0QlnlJ5ISlskbd
QXavgtyGFN6rKGlLFrgOV1tKwwSGsguESDkNcLj/OOyC2D9Op0CCeqhY4fso
R6QSEE1JeSY6AiU8+pjFMRlkGHTfZTZxUccxxTebJax4M5IWwesC6jrOp9t6
0lYcwhYwNE8UPSF42F+S40MDmzfCZj1zJO2oQpL7tevq5R7Ataw6yakXEJtK
DWzbrJ9NMJMUsYaobU15u017dN1vAFnRVHPzKzZQUPoFmvcOFZnkCQkLusHI
WkerVtsfi98suHVFprbytDmZHujsa3wU59Y1qE1K6CG/zSYS/nkA8nT4v/7S
kJ49Kwlfwm7njLEG1Usr1bCNxw4Igg3aPESSxrMub4z43LUP9VqnAK1mkY7J
HGYkJGNZey3V1qzYEqgAjcADADTgSfYPmfQDG0DQ/GHf8cyMtcW8y0hcr1WS
69SAak6Ax0aWKMgAB3Bjvm0c3T1Gk9AT0fvOetuhpgdjXqmvkaL4qZMjSeK8
UjgY+PxGPnOg1G/CsX3eK0cTMJZ2Ga++BCvwwlLnlHwXUDovHBual+CnG6Ck
OFvzwBzcAmSFRwdU7rFlSTaBagWCPhVxlBbU1/UVSTS1StFIL0GIlqoiZCSj
gxrAczorfN9+ADyUkTN5YmfEBjREQhVzpSUU0orLTE413VpmROLFj0r3MVMw
wJRvq8/pyJP+BuFDdMqyiEUhjN3281bJVEZpADTG0GmQJMlB0eWsnDwkuVK2
ZQXDXg3I7Bj21hBGbLqeJzdGQt25Lq6jRBOSUyme552WOf5an+M+P8Duabyt
1OFQEznFZKyifviPXRLoL8Z8zM/6qFCzHeuizlMuc+RPyr4Q+tEsTpxPtQzq
bi616zlzX2uprWMcTAAo1RPMUtpE39o6zVv+Jlre/KJdwivaE8m8KmtF2dpW
u+g4Nm4+de8VnkxJ7z8cCduTrttF6192LE7JrzcTqZ6dBvBRHu9qqJONxiGZ
iAJNnDgmzxXk+Q4N+/8SG3yrY7HVAdSK9TUNgqUvs7FjX2HAJBOJRUtnGmnk
ROfUHJZND4T1XLAOoVvtWZs/u8g9o78nJDq1gneIcRwG7bVqODMtTT89ajQx
leg/iQV1A4dAN7KdtjwtSatfSI8sb4WMyWUVLfIJ/BIvt2XKZW2siuUq4k4L
3HoDdbyzqbZpFgpAxmmvzmWQr8VFbsIL/ahty7iyKYc5GAEcTwNIcEAdS3PQ
t7ZtBjupYer0IEPVDORZzPLAjOwyaPa8pmyzlHIStOapX2qAwVGiuhtQnCqv
pd4z1URIqrAvUYq4a8ygcmv636vJ+gYSMZvz4GIMP3Y2aCoSjMK37BhX/UpR
xBrfOTyLUHyVT9liSl5TqiAn1m4/9ksWKeWopbBFDByucgOSuN8l3x0MgE44
qjTGHs55lWcSJwqaGJppqGQvBcLCetnzpGXWQbgG2XpMlXlB+W2uQfPIjcMI
LyQaoiUoRTpv6irQHkwRg0QJxVx+1lpZwJtLVMeWjupsC84900qWmwkp2ZhE
UO4prfZOpzYnpXhTsBOW0g3Pk+IDxp4XCZtxm6sYJwb0bOLG6hTSQq1RLTKw
kbNc4oWibLHPISNmWn6gPq35crnhTEGgQu/g1pzg/QDCAzcooqxL7bpSijHe
Rp64+au3ic3ThEdWHA1GsUKL/K7WKLbeNgqpVztNYc26TAKJzXfHZnOAnMik
/E4aOcoibU3jO8wbDIz6b7u51dKi/az5eoveoL1FbxBIkmOteJnpj6lg4+o0
Y2TfWlQLvYZTWx7pLHN20Cfzl4O0ml8vBIXaogZYuE7dVW4hvs9sOThPpuR7
fZGQ0/TqxesTSs5AvAiCM2oqL49M+ZEyn1V3nJ1LGc9EDq3XootD9PrB8Zlp
P1ZiWJXG0NtsiAUhArmRXLAGymFCbVRTANWJmVoDesRLP0fW1DgpA9tt59On
ly+Oo4PhycvL4dBxEw2Hg+F+N2GL8KdPp++i8xeX8L0sIHCr75iUYRN2qCHn
7s7VcIOHZUCjxTh90CFhRzFAe050sTEVbIUrIZEOg0EXhCjR/v4QSQAGJIX/
+CXgwkRUbFAC9G5coN0gygXUo2pE6CdCoE2HI9nKK5wWqjQpbVnD52H3BAPH
vkfjFwK3saQDuyRdpL80w5FugG1sSICiJYEYg/KpVjQtb24fi7h3/5JOwu41
Whvpt8ZyHjeWc+AvR1p83WC28E25SSuzIPpkgrU5UF8zFekeXNCLsPt8ky6n
O1Z02FjRY39FY3z5RjD6JkaHXkwaPK2Kv7Xiq57b7lW9opDNS7kh59Tnvaiv
6qixqkN/VTKerkuXY5YpF0/gtHs5/IWpVxWafEq4CHAHNEtrj/SUPRk+Ws2L
6PCAFgRr+WSS0W/GW1jxYDD45TMmXJv6AKukilFO63lCteQoRuV0OVGh+j7q
1lE5WRQAN2dEuAJnidD1NHEbvswVUDli7R5OPUPpLe0t56WJmFdR7c2nCb9G
WRl08KGiA+V5qwY17Vvfi62exue94vPGYsgUKc3xsHQWIlzSc2J89mO9AZjU
RSPLAyLFNGn5IV2vWdYrEhLaJAD1UQgEVXQQElNwsEubk4OwCF6wnyAO6y14
cQs0gJZ9Uxt36baEJ0jsoK2eiK9k1tse025OGyKvQLVViS8pbdk1bC3rVcdR
KShwiwJTrknPaVvmyuFU2sZuneOiDHMAwEgWo6Hj3V0UG9VE7O93GxgC262T
0MYzj/Eu1Ola46nDsNtOaxpPHoGG79//XvgPwjNbW2H6i5/EO40jYZV80RxM
AOxB3MAzMyijYWtF4zGjC/malsEKRHuqukF1XC2imgvGQq4T2ME9HCrb2pTl
ECxYcFGv46e31daEqzRphWai9N5U6x3gDqxgavQSLspgpO4uyPjk+MHPx1s2
M1AFiGO+vaCpR7C8aJljO1r3us6ozpEcQp/vmSO3swGarJVOAQxamZMJ4nVR
0SoktdJLJuEFF6qV+yZx5malgvhoDQK0FjqHhySrEYVcbbC9xpzliGTqFTUM
QiW1Qnap7hoSQ3KWk6u+VseQzQF5MaD5jdB2nGXJx/DsDPQxVPZZ0hKZLdaw
yEmi7V5t2Yn7RVgzy/FZdHxyjRPB1UHZdniAHTOrHP2nE/LlUjW6eM1TpNyT
CCZYpPNFRAoUiMFcfZG8mPny1lpjWyjdPVMfjph+TWLVifxLYup55pSXP18Q
JiOK5xOyIU/VjeswBjsv6gIvqaIMFpm9LmKO6fE1gZl5oJIHlHiaPncatUeb
j6mdM26wHzi45GfrEnPDYh4Wbdv4VWDqdOJmndHEnFe7yMKtaeDADlwTwC/p
iMwqv1wEtwW2caM3wH/Jj24EJ/yQ6xy5EvgXiN+6ra8XvcWL5zW6F9lbP7kh
WLGY+7DgbZK6/wW5m8Av6zCnYEDy+J51eOyGSx0ps9mNp6b/65fSsvOzl2cv
orOzz5/leqkBwmdHintaV9XpB2/YAONlnBnDEzEP8eBrUyHL//mqv3h7eVwj
MHzLvbWfYd+EiZQiErJzP5V6LbQpn5niQVw5CPklvDEt0lsKdxTiZAvZtJb8
M0UA3FusdXnILpmWpEwhraceGQZEfe5I0WIf06zuYuoWoG4pCcTx4EEtnxwr
HpjEPq9I4EOldMZx9sGoIlwbxxicy/ZqOt4rfsebWj2d4dH+UaOezvBoOPza
ejrfSnUcKaczfYx1dOIn0fjp5Fn07f7wIJoms/3I1NKBT5rldFKqGq438UZT
/7ySOl9S2+dx5xctmEP1XpxDcsq5/ysVdzwIs35okS3K0YirwPYK3XhLcYpd
YT5Gv/URqVLV0XUrHt+kmVSXkuJSQbN6jYedTgUb85lTAkqFXqdaAuGsLRVR
L31VQ+aAltHnnjiS5E+EhDOeKQmWNBQr74nJLLCXU2/mlq+bSfjkG4/STJav
8k2JJAMLik1KIANUlJkVXOb8S/Ol5fjGktdkxqYOhrBhTG4kOcd6UFp1Uo/H
g8oWWDexw+VNJ5tRnZ3nSDAvlnGGcR5fzs3XS/Sa4suGgeMvnlnoC+1nVD6y
/B3cW/2lXICyNMybf63Z8R5m3ldUHOcLOPcOKSIu5rk0FDFmRfqtAZQH7WUX
3KzkC2xlB/2w3Wpm+IN2PtE1ya++RLF7TVdcCB3lLEHDxqoetJUxCt8oSjtS
lgz5JdZEr8u9uVtCUOxNVLmGVcGLuIA7kSypPAf1ukfHgtieKJMHEQ35Nh40
RRqw7siZ0tKzgC4CPgSyikjGiaQF0uha/gMPyGmohsP1a24b1KbgAn+DJTlY
xyIaoyHDOmKtpr423eNK+pReBF+TvYZSsDU9uqx5leLptJA6j/r8xHveSYPG
lc03cKOkhgGljDw+OjpQv8f1AolqeI6VzOo51BV/F0+o9kxcJGYeIjlReB6j
tQ2JprTITvlreRP7PWt6Uz2JBNBFksK5FIhXH1/bz1GaoFM7HWU95DJA69NS
DRpsEcW682gNAKZOjbftxFSFVRrYw6xe0Fs+9l2E9YFwQok0EOdkQUNrikOF
CdWVNLMjB/HWuofFTBZYDy+LhNWClqBeTzVGqP0CjZnpms2G90ymDyVO8YmA
/KzxEmeBxUo1nWZpIT76KywyekxFRvHL16imaRabU4AUUw6W5js1FiM2eFVK
tZCGzKbxz9r9idsKcmDVHfc+5F7jbNN1ejFpbSS2+lSlnh3lu4ThMWnQigEY
KF5DwgnVPmUUkkK8OBLjkqxAEonKpKKV1kKbsDey7b5h2l8Aa0bsDLT4v3Yk
JiqHfmiaTIo9t/Sc31ojHqWY4lK849EZrKUiLo0PeSqvNbtDULtA7mG83NrK
TPI81Vbfk8Lo6EhPylpJHrLr0tRc+F/rmukIDFanuYEt/kTG4yq2IdpMQuiG
g4CEVx6tdBJiYBogGGJaNR8ORLfUdDWDRVidtErneKpc9yzShdmD7e+Kt3FK
o1Iajutb6QReyeWwi2XiUrZPkYxN5a/VKe7aId2yv1LWFwkl9s9MK3F4SlwZ
m1lhH6/yO7SsYt1lDvPnGoitd8lELhYjyaHFaPjAFvoVZJvkkdsNXbMuNFDL
1xcDYy4Tmhy7deRMuqCdxCC+W7lY6xYfc39Ep3UoXT9cqTME+XemEiaL8IIb
u8Zyv1TmHPhoks3RUt1m19XwAp8kOeWONUNEyh1XpmD9jsLHYa2nuLMvzs/m
UAK3ppV0Yg3Zio/ccMJ1mrKAvPlSmLGJWk41b/WAuQik25VefDZxwxS5D98W
cyD1nK8LCHUBLAh1AUzPL4XksNLunOe4yCmHkfMeTWCA0GJTWMlYI6YSP8Rk
nYQk7L8M8IELbyvK2Ozj3F8UWWnyJb+OEs0yxlhcoB//AfeJnXOk9sxRAyMb
1oj6ItJL1BgC2DTbnNhEox2puWw5nP4ChD9TwxwerKT6kOHPtvmJO4kTGpSW
jZggZs3tUUFhLSrI8Zs4qalmayP9shbYIj0V1tiXIZSr1Lc+TbejHE3B2oLT
9cbdjbSgYos9B8ARcOy+MFCTYlVA9dPOjySGUgtQvhoGUiIGmCQhN+xSYycl
X8vlyZXyhG883iwpvZjx0izSajORbEKBRMhVUuXbfBGIg9N6CPyG7LWOon43
8cCZyXE5Y0y/k3Lt9vfiOOw42wYiZO6eoSWT2suafiBjmitok0/sSVthzx5n
2t2XtUURx7PWVbgruCcjL6GKguggl5AtNzUvMKl5uJS27G7koE5RJqotsEzH
RcwCLoxpKo8ZB65pqdS6McbCS+48e0yCN1K5W9YHBA+V+3KPglo/47KWqXoU
uTmvcPFsd2JpRuL0umVRX+t+uOnTWrgeS1bQoyAFbDKTuWESNsqRCSF1szrE
FhLcmYZ/cgJoeWbzhE7qJAVTzc/E1MKkmp+B21WCTULo0tEcDQSVpjBtEzf5
uGlYskVJbWyf7E6IKuvntJ/AZZReAVSxS3EBKlJlYutUpTKBXETVq0ap1j1k
nQCP2TKmHFDuWJiT/mdWswv9nIBarvSRzwhUKGVH1DCY25lKHGCVSxEQGVYl
gNauwtpTOHCaL8I80w1V8KwSN8SwrQ4eRhFar/Z5OsVqAxcGqr5+QOuZJLZw
doTLK4xKP5AGvdpIiZ4DLDadlK5fX5H2g/8C/814klJT+CnyzoCfik0HUhEG
w8u1OAweej7Jl+GnT2fRi0GaVLOIcwrLgzLSbz9/7gdmodbqkNqGzW6dtpBT
U885gdfyl1Kqhh8eoL/cOEIyVlgzjoxFn0iWwIVJuZqC8ZIIOk8BJTNYHkCZ
S1dxEw/Fa9auXl/tEVy6dtEE3d5IKQs2pkel40NEHV1Euxd3EjCLvfcX12GX
a3QbL7wdI6dQGq79beodZNMgNGnBaqkzoQmIUV1X13M7fpqhL8XwW+uAPKWy
I0hdqYkQf82iAyMeylnWMiIJ261cOmWrtCjQFJCk1g66mUC65kngkBquiAA3
SczxlSlshN+2aGeo2ATo+aXD2FGnxzSciZZkpDCCXoFdibgJEmZgFVz+GfhV
F7RwLoE8jTHjlvIeQIZclBRUcmH36BQqZEmaBIlXcTGlYAdjZTunuCLgHq+u
zilrB6NBQLaGG04qAz7HQJMEBjLROAy91qkN9Ctp12SrkuAr79bUexbFmko8
ewz+flNEkDLdyMUlSMM1d+DYXMMBlEKgTVlyZwrPYFwCZtvRQ5gHphYJV3aL
G8NxG2OvDrQkzovcLLKSU2ilSGipnD0Fhw3AIWVXvRaY3MInEDh03q/Xi53W
3IXZSt/Lrak8A+vrBC01AsRJK/H4BJGXZAU4YfNOcKwqbcM4BNSFCg8Ckntl
A2y5H1gz1xupZVCZhrE+J8z9agNSMsHq+a57aClR2RIjwqqyYX2gYYvVKhaj
hiUXDOWtyH5b1bj8Kg3nfAPpmonAxFfQUW4E/MRHk6aS1JY/EYQPZVC06Urv
m5r8KHxnW93tUJPFQqumlx2Wl7DV8kLmYVLH/SyVcz2BtAkI5MPwYClSidy3
WPOxJrYWKo7+dlNhabUxx9YBTo6oBx3bjNU0wD0lJIFHdAdjCqYeB6TEiXYC
8geTBQPDNYKsyATNX1BBN+pBxTw7CO4p7SDUfVPFxpgOR/gRPaxAZgMOcPyY
gtaFKsBwxRkROCDGEwMrLbC+oxBKBMDp1cHREyzjBrchcG7DgwXywmaBvGBn
gbxG/WLueaUF8aQCHvpYpIQypj6aAnhNWVHQGGvibkOyjZAKQHeP+erxxRkz
XZSvtSiI7UdHIEZ7UqkN7GrUwNakc0rhk3l/x8mY4nJ3MTefA1ICDA0JDjZu
y4QYUkaptebKp9QeTxDCxDiGx2gmjidbE78tzi0bBNkl1aLPIRg9hmm9BOwg
OLE1w/2C3HQpqHg0X0Neli0eq/2y72mIR3x+m00WRZ5xY3V0cejOxQ7/5vqi
5/Y25XqH8cOVzYN7KpsHTApqpiov24kQVrZarmOnRQn7qJTL1wNQvU1QEqUw
BwxMT+eLRIobBf5qEYuc6aUEmsv9bU1kZaAaxym2G4UIJYy3VHpn5cSCMuDo
dgr7tnbX+rxIjbBlTi6hTSvCV1212PTreMOhCEip6+0hEFHwWamMFbSutFYM
CtR1UxJKO1syM661EcL+RlgTEruUnZhC6moKpZNa1cqvk9VkieVQGz0/CcUD
ybJMvEZHWIR2N15bkwI3PeCGB1Ty2tbfCrFRrjj/UDEzdT0ZXUi/ybFVSKN8
uynEU1GaG/d2LjhoBVEWjos5vfToEEPCl/bDJJtu4DTZBAZIfTadS+i8iIKm
2zEznwVHIbfCZJsWSCs55dXVWrByZziWzSdNt7Z2vj6VsFE1mMphZtSshGv2
c6EhEmeOXb0LrU5dimzrs/GGqVxNvVLJEd92UzPXfKZdGyvWc2pSUZy2ibIh
55SxAbd0Zw+p3kGnX3Mn9iQWekfgrx+1/iUE2/HAwi6UQTgFshhK7NHj1spY
pNe2RtYsya4YIUQE971EoToLMS3ZtncjDLGN2nokXooE5EgeaHYx9koXdalU
KalrOWilCXbrdHpN6+PLZcLLl2TwLb4BEp6KNGJjl8YhtpJX9+LsrGfx6tzp
UqhN1b3OhTslB9MIkfKVnBm0o5Si6iCQi+d3YX64FaM23RUbtAb0wKG7TRpJ
ksA6u3E236A1xcVbmZvqdXjT2sbJ66ZTwhk+SEBEm5JKotVFWDwVmt8aMeg3
qDWSetD99KmtHfbnHq6Z/Q/MgagKOcq4GYvnom8FXGKSU0M43XeZUCY+2hKo
ek0uifDcj1TzIYixB4Jw2G2T2lQ2aRHdJhMMQ91y8Ta1n4/4RqRwASL9MdVB
V7eV6tbGvOBmRrkGiJhei0Rhg+9BbmB/KLdtsBG/RoHgvCrJHNNMh5is9avB
LozV0BzgN3SRSTGuyIhNGxcNREsxSG1QH55Oupo0Y3+5WSoNwVW5RKTrlz2V
QAIhGnI7ekHDEqON15ZbK/6LLsYWCmuYZtAF6l3EqmlUr0HhtAKOmyVM/UTP
4koBLKeS+jneVAHn3+h4ulKXEmo9E6oWrw4JA4tjqYDfJLszJW+gQai3ehv+
EygX+684S1EXHPgHqyZetYQqIjqWFLcxWGAEL6mo47Oh79gwgMtrFJhiz1fg
1Tl8FJ4dvzluY8mYLBqH19t1gkBIOcqNQztSmwxuMxcL5yE1CNggMiL8qMnB
BRePup2g7Ojb25pzFhcHfIxWgS2psY+79NLixVxtxpX7pV8JLwguTT0RLXlX
4mNY3y4I3krxpNYvTzPO0q5F1eEDz8Zp9Z1TMCQOf3gvMRPy25VT2Vhqbgeh
X3W7L7US6Q2TNgGAa3SsFPSk7Ipm00qvXeVVeyggLhrpIS5nR3ShiSvUqg16
wqhXI24TlRVBqjk6w+xiow5Br+YDPuBhTRAc20MUCzMH5aB73qAKvtd80DoU
bZQP6QXpxKmZb2RriVbdiL1CeksCyPQOudl42PHTUh6H4+NSzuM5TMEGjW7Z
k02H4ct06agU7jfnOEuVAzGa4TOEqXik9pmA5RnOU1yhoClxnZykA1dhwoR7
timIYdfWdLIoMDgWcPFNkmVY0gYQC/03/zvT3wdY+fJMCcEGvTH0JijMb9/g
DWH/JgGY2KE8wOs7Js60YyrQrkF+ED5CfI2ePDu9fkk0xO1VS11nPVKCTWvp
u8ilHZ9/J4XxGtMqjXm1RbkRT5xa5YI8RK448nV1cXU9Wdcb9EzK4radoJUK
8ZNKaRpNPuH2UVFz/BJmBfgQpl/VajXxrhpXog/CitvCl5sGIF1ha3YdcizO
/CGQk4C8NKOM8w5pgO+TsTQ24OkfotC/8XMMR/3lhZVS8TNGlRODKvDZpRFR
fwt+G0VRNKK/nR9H8AVQ9Sk8bMK/z2xq+m+EbPBPrZwLjmei1OFr1vf2KJSb
uMm9LwKVhW+kcRB3f3RE5/tfBcz6TdVDbFW5Y7XMuRvv2hJ0v9XbqAGwqN7b
FwyiKUV2kFP9RJsAPzSMqnr4HAl+pEq9kk/0TdKlTCSRP4Jqh/DgWxYYv3oI
vLi/kW2dNY23bNPwDqAh3/9GqQSUFSQfaibBjttEuQNiUKrD/EeWDJUywMUD
YEV6SHr9to2rZz3hUuF/9+CdwFwtduu23cIurL3XCedFvllzwR8rkal2B0qA
R2us7KNdIp4ND55QyD+HBKcUamF8EUIYzGpiaof2Gy8ToP2HXWeT5f9bix2F
Ok2hAP4QhppImrZRuNDhg3elpVAkEou7mL0ELLirffv+0SzSuRji1jPccfyA
OwCYkBNLUeNgkQapHQzK4kYy/UuHnIGCqn7bcHOp25+/1tAPONHJIsVAFLSy
NWI98FvYCjV5sTEiwdcGiRhNBo2+Ji6Cmrzx2WzWVMQ75W7XrEthcQ6MINCg
C2DWd6CndjAgNBVvDwl5/y62Jyp6mFaeC1Rj6T8kW3gMZlgmXk2bDgVMYACy
HQ+urA7phFOgeyYw6fPwAFzDeSIWk2QrraQzE/YRYSPWyDc3BibiVgLN6sKq
l2z8FgWt8GCwLxf+9OOEL5gG6HXIrkTkq/2Y+YY/+fYxHME0mVEDdHxx58jm
QDFmhW89RZqZybrHmPPTs8Vv8SuHiCqlEAuUY/jS1J2MC7cTMVNTu9cWMw4w
S2Yu3kTM4RyFeugYKIZJ2+iRXcTLGRIo+Go16GB0Ex4uORjFJl1u0AWXTsiF
jgaPZEUhdDEPa3qXkLC73AZYrxXYfJcKf/DaxWRue5NiaElZUUcH2Qk92MME
A9Pp3IvxCZ3tuBY8ii6wWeABZ5wVFC6Z5Y1ieH3FQ5OuTlU0vSwOG+pMVhqN
XKRDoGRYiXIwSw3G6HNZILC6sziLYJxeyN7t26SYE92mL9KsZ5MHMOwjsAET
1EH9+PuBich0M7Y0sQKrgKbZpNJSyCgUOsZRLT3CkYB73AoahTLjHcUgCSaS
tumNRS+pcFTdkYqE9WQlZB1UpHyOaxnJ42pBIZRyjGyIRv1OC3HALJopnHcf
0Z0+IXtLX5uWGgoRqL1/0GF/rFPegO5Z2X5L+TY2n3apao4rjZyCCRF7fkEp
QEt4TPFVPtqpYitlBbWvD1bmWErNTL6l1x+ziOlAB9SDmztjNAbitVltuD8x
u//iyNobMJMDc3J04DI0BcL4YogTgZ2UtFrHwCHuvzIppRWpF9NHqi6sM2K0
5fPg/DQTPmMXW8dENRxzjAvdcb7ao5Zt4O3HOi14mHDt7IUg38wKbgH75G2Z
Tiq/IuUeDFThkpQo31IKnjiLKZXxDj2RSbxSBootIZC+mLZuJgrWbMj4agNu
lWXXxK0+4BqMuQoPbw79quyKGnGORvuRUCiuORJKCcRDN8bWBgZqYInb/EjW
+F0Q1mcB+N/FUq+IR95kzFamxvjopjSeVXVyJyGXc1gHugKAjmEwXzMGBKsW
4Oc7HW6cPIilZH0zD5mujO4gZdOE9ZrKq+ivwHu368ph9yDOMCMfRjwV9h24
AZ9OK2/03ckkN5PqY6dHYXDu4qwBF9bjhWUrTaWmgk0CEZtcfzL7F1tEcHOd
LWWocyQlDd2OdBhg/EhLhyBSeB1VbQ3/7jNcgFQR/gQsj+Up29uaCGuwM5QV
ZiNdmyiqCY7pS9of83X2WocXnIB9cSBUVo76P91CZGin01zMHiWcBdowkbcj
+Z6AY1vp2OSQOnbmOkAJpDUSboWqf9UK7CL1YYaKwminqhZCJgOWrKacRX2/
HIweG1SAI4xiBkkHh6LQgEkeaVK4WeN3lIC3StEr1oh6puNhfuuHyXMLA2t8
lGAxpwj3tVg6u28B7tfUfg0ktt4O5uQ+A/t7e3H65vr09en56fXlT6oayCLd
St9iTg20tpdqAByT51YcmybjDdfioYylPEOXCEObXP4c9IHQLZHwoxEW/d4V
duG8i7flyKoMnqOa4ibFHQPYFhHy3Zen9J0ZKOCo74gTIistGkJWfBPFVcrz
2g7VD3YJKHHrO9pTu3uoXgLS8786DkwfJP55kKsKuSnHwy231uw6DSRXFCh+
RbxRi8RpbQMK5mzWLjctnEyXVPVH4Xv1M05aqRB/E7QfOlMN38PFYGkUtR4E
kia3dVzXPghoqmbVaIl54dQtidgstJU834nnGFPEAgbuzL0inDq4Q157jrTE
AGRsR6njuu0koNvhYv2BX6zfF5hVTyNGrslaldKsVUz+1oB01SzHIhjqtmzU
0tdjk6M2HungnqL+LQEfTuEO4LzOdiVRgvSQ0K3mz/u3lfTY5hTY+v2hRzIb
7RmkAsXVydn1ddi92lCw5gnNaerN95kfkmww2faFQ27KagcdQ8LNA+6yeJST
tKoi91tHa45rqrupOFSZVVTWdURnXvK6CVZObT6mJO7iVcwCQF7xPUCvARdB
o40FlHa4rkr3IupmEg0Focvv30LJfKQKWWG3xViuijxVZcNQDE66cq6KW/TV
XEE6OF5Ay4qxhBMr8qbkK+WeO6FTxPNcADlwxKRXgtYgeEl8mGpF9Tl91ZpM
ViAkYrVWLtloiy6RcM0CGSVUcjl40z4ZY5uEnYc19W68ZSWQba6Bo9kZUQch
SiWxl7YZd71nLgGb2lmz+UQz2drhxaGVbegwYPux5v2Z4AYb00BCDcchTVO4
cRgXZYVK7v3cxSgt3LfPnow2HyIlqPIIi+B4GGttCTQEr14Rsec4s3nDsSgy
C4yQDxwEkio2bhyiMR4RMndrPpNeQLUJSWyjWW1zAa1rjRbhBU7ZBrfA5QWA
QLJmN4iSrA1YAdSkhzts4f3jE0l4pmt8Avth0WoHO9j9vFPpR7wO8RhVROkh
ZkK9VHHoa4CIOLd7et/tOM22D/ks0CKAXULZBZF36lXi2ysaGWK9gVrNCJM2
1Jbweg+lnJhDENyW4Mx9+hJvbHqlEIGybStIzBFbDweT+C1Yvpcwq512bArN
A0T232t//JjD8dhjgesjHdmfEEN38NJIv5cTTqSBfQqva+8p68SN9jkNV0rl
YfhlP7yn56wNwTGDUfAnv14LAKUKCu2FW4yCNKBWMkg3nKI196faU+qkJs1T
ixpMptcLi3lhXUrfICRarSgMoDdw+6t7mSQ2J8XPlgfxDHvA7GhN2xWuSNYd
vHf9ZsQqQ4VLJhhxE1aCXdElU3Fnfx+WYrTXnkjZmI5Q+SF6l7pHiWRqxaTI
awQEQtEIIE7NUirWMoGrfKcCHYux463I82jMeCECFJ+O05ZmhOChrJ/dUpXU
JA7H0rkQg7skNhyHbvRPwrgTjiT3FmTLd2hgcVueAwEUx321HRfpdBS+yisj
uRGPVWGwjzbXKctLt/SdEWgx8EgzHxHWggIUP1kLHNsBbsa/9pQYKQO3Ixsp
COv5SAQlD/lGDyQe2Uwjk4KEJiVMQupaXapcIXEgOwjnGdlgIsosJR+GRyRH
SNsj0IaXKeeb6LopQZQaPa0puIUtFHjqGNxR3/BRNNxfoexHndEE4L7HyIY1
8Sbd0EZqW53i9SfLNs4C7+N7maYF1+O32o+pHlEak2FB0tKw6EGj5gNzD1P3
Iej+8PbqVMLVSYdhwVnCm7xqD0CbuRqEH26etqwBLkSezVFZwtqdG8TDaUtG
Bmry7nLHCXWgSGzTCZPWgy4sW60CczcpPYakIBdOA/bHGs3d1qOGO7leo8Vj
p/rh1M8TBWG1itHWVlIRG6OreaWN3bLgRFtu4RVMWy3aGvwYBQEze7jDG+XJ
UaMDnJnUt+8AsRZpcsuhjGZ4zWMNnEjbGvFYJTH3xDCdnVqaOf2mAOKogEtb
0xkjN+AOn+gG6YHABgTwXzAA9kU4GIYnLy8x5KYKh0P0wbuth6wU79bGVxNH
3xRG7mrZ/R4GKHgU2OVvbEy0DID5jV9k2lVgvDYouOLTd+H5i0uY44sq7Xe1
Mn+PQdKwhDhxvsdnETeIwgL1Giig0aFm8uMzDGjCEteDcHhA0HqoDL9fhP+3
Rl1tn1/Vy2u3TnwIw3DDHVtk30y7NXPcW6H/nvr8OOV5+vLsBUAOQe1YxBVg
RK3R73ublmxa41YnuOcaqGsNNZp9K3RMnBbrkDvQbSs4zoKcmaiJRGWjVLmL
Um68iHO5Tf+Qe2gO97+Uqso7WO4j80A4VOEmvL7LI86aMo0M2gVtKSAs1VBL
kRJC0zCQ3dUcJ5JNS8dwpaV/R5yejPxA4j/rVchBZMWq0yQZcB1rYMX4Sa2X
OX31gYt+kwwcxRFIo9HB/sGTaP+gIxWpaboL7UJ7f8FzMTIMgBpKvXOKQTPb
a6953nxLJJC8UfR8/8nhsFH0HD58+rVFz/eHXtHz8XBygIXPI6p8jkXOo/Fk
mkSzfVv2vFn0fJaAoHmD+Z6w6Bvcqlfv3K9kvkyJnNFjN5wp8XUVzU2KGMJu
EUdwvKPscPy3+U+L89n79/Hr6J/zjz8Wf3sZv725/lgWJ4dn5f6Pw/Ll+MXd
yXzOg5jEMmeQ1yfxfnzw683H/OZotf/u2avr58/fPH9z8vrvzz/Mn0bz6Kd1
kn7/w+royaFBCi1E7blfAVP6qkhgCFHfRXTHpo9IzqZGjWbBMqRYURBG+Hoc
q2HLfeh1b0V9RK4nbcj15GuR6+APQC5TqJvLYX91Jf2hX0lfimo7Ld9Mpe8H
kE+P/JqM0Bgoi0S61n1qMBhE+9SCqnkpao2g5NGDsFvbIrdZcynswai1byQJ
cNqK7lh6xu00beCCI7Jh7mowaesN3rl1sIPYFq3XFpPZtNYZTVvWYS4N0u6h
123RdO+7H6drXesYrVEejLSPWTtqt76HaRDYEul30s54OD6YPAaEwuPEv/bt
X/LHp52M3LOjKH4yfhphf4gIsHsWOdg9bKL3rk5luyloa7fJ/98RTkKSA78B
JkpL/wKi+Af+RTiC+ltUbLCGZQuaHOy3oMmz/a9Fk4M/AE3qTep8MvhFuFpr
KNLoD/ql5A8P7jGoHJYoeB1Df8fBNU7hi86OlNC2U2vjXc+efO2pPf4DTq3Z
NvCrz+3AP7cdbVS/5uwO6x1Vf8eJObB/4KzaOo+2HNrjYcuhfTv82kM7/AMO
rb2L41cfXK2DT0un2S+h2W3k9nI7/Gn2Nn9/8Pf1ydH5P5+9+vD9f7/5+Hj6
+tvb5/Fh+e7X06fpf1T7dxf/OfFP/ijstravNbLD1yLD7sN9ACsekj+PWtDh
aPjV6HD0B6BDrVXnV+PBoY8HO1r8/kutnL74VLxGTl5hNNhMwK1cdt98NC7s
/TOOtA5aNOzQO9iu5fNO6djpMeR09Eb5lRtnS4tarB49waScmoW2X3fA6XNk
e0Wfj/5gR6C7xorVjga+97QBNYU2bLh+KtH1RybCVOupGw/ybRoH91Zlx6YS
rXrCF7aqtdrCA/1q5cEvaVorj35p51p5fHf72l9EJ+bWwxJhUO/cm5YcU43l
C5Jiq15E1zHHpRi1gTDHxafTL7zA5EDmiAYcm7uuqmnWaYL1QCPcwFThJlWL
je2CL+g9514ZpmMy++l8e2MgAyjuzbkRgaPXPR7ZHkMm25fH+iFPd3qprXZG
vhrMUuA415buQnILqI4h10qu9Rhq1165kyg12yQsCJ0/PyNKuB80cDT0MDHo
cgUv/dPl03FcET38eJnCDQAk2DYm3KtN2EBfr/1lz+F4+C3a7dZfZrdraVRo
7Lj/ap9ClEzb1M5nvto5GyaA5RPiKIdfIuT8vj6FHsQ8nsbMwV3GwX1qTe3Z
x7uEIXjUF2SpP2JLi9KvsMI4LTMkjOEuNz2QvNZ2FJDidGolhNQYYYN4fiFF
v/Xd7ga3j8LjyYcsv8NjZ//7Tpcdew8oJFe6EnLWJF5oXA0l32ryUlo4KY3x
MqBgQVyX5oiYBIE0U+sOt1tzO9JIJpPJYspnzaROE/+fTe2XF0UOz0qikZNw
GT6QcNkohRFoKYy0lCTM4P8FIlPfHfsYAQA=
-->
</rfc>
Reference in New Issue View Git Blame Copy Permalink