c/ietf-wimse-ect
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a6d2a955ee49a89482a57fd3cb04fc1e528374d1
ietf-wimse-ect/draft-nennemann-wimse-execution-context-00.xml
Christian Nennemann a6d2a955ee Fix extension key prefix: io.wimse -> org.ietf.wimse 
Use correct IETF reverse domain notation for spec-defined
extension keys within the ext object.

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

3192 lines
138 KiB
XML
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.5) -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc ipr="trust200902" docName="draft-nennemann-wimse-execution-context-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
<front>
<title abbrev="WIMSE Execution Context">Execution Context Tokens for Distributed Agentic Workflows</title>
<author fullname="Christian Nennemann">
<organization>Independent Researcher</organization>
<address>
<email>ietf@nennemann.de</email>
</address>
</author>
<date year="2026" month="February" day="24"/>
<area>Security</area>
<workgroup>WIMSE</workgroup>
<keyword>execution context</keyword> <keyword>workload identity</keyword> <keyword>agentic workflows</keyword> <keyword>audit trail</keyword> <keyword>compliance</keyword> <keyword>regulated systems</keyword>
<abstract>
<?line 85?>
<t>This document defines Execution Context Tokens (ECTs), an extension
to the Workload Identity in Multi System Environments (WIMSE)
architecture for distributed agentic workflows in regulated
environments. ECTs provide signed, structured records of task
execution order, policy evaluation outcomes, and compliance state
across
agent-to-agent communication. By extending WIMSE Workload Identity
Tokens with execution context claims in JSON Web Token (JWT)
format, this specification enables regulated systems to maintain
structured audit trails that support compliance verification.
ECTs use a directed acyclic graph (DAG) structure to represent task
dependencies, record policy evaluation outcomes at each decision
point, and integrate with WIMSE Workload Identity Tokens (WIT)
using the same signing model and cryptographic primitives. A new
HTTP header field,
Execution-Context, is defined for transporting ECTs alongside
existing WIMSE headers. ECTs are a technical building block that
supports, but does not by itself constitute, compliance with
regulatory frameworks.</t>
</abstract>
</front>
<middle>
<?line 107?>
<section anchor="introduction"><name>Introduction</name>
<section anchor="motivation"><name>Motivation</name>
<t>The Workload Identity in Multi System Environments (WIMSE)
framework <xref target="I-D.ietf-wimse-arch"/> provides robust workload
authentication through Workload Identity Tokens (WIT) and Workload
Proof Tokens (WPT). The WIMSE service-to-service protocol
<xref target="I-D.ietf-wimse-s2s-protocol"/> defines how workloads authenticate
each other across call chains using the Workload-Identity and
Workload-Proof-Token HTTP headers.</t>
<t>However, workload identity alone does not address execution
accountability. Knowing who performed an action does not record
what was done, what policy was applied, or whether compliance
requirements were evaluated at each decision point.</t>
<t>Regulated environments increasingly deploy autonomous agents that
coordinate across organizational boundaries. Multiple regulatory
frameworks — including <xref target="EU-AI-ACT"/>, <xref target="FDA-21CFR11"/>, <xref target="MIFID-II"/>,
and <xref target="DORA"/> — require structured, auditable records of automated
decision-making and execution (see <xref target="_table-regulatory"/> for a
detailed mapping).</t>
<t>This document defines an extension to the WIMSE architecture that
addresses the gap between workload identity and execution
accountability. WIMSE authenticates agents; this extension records
what they did, in what order, and what policy was evaluated.</t>
<t>As identified in <xref target="I-D.ni-wimse-ai-agent-identity"/>, call context
in agentic workflows needs to be visible and preserved. ECTs
provide a mechanism to address this requirement with cryptographic
assurances.</t>
</section>
<section anchor="problem-statement"><name>Problem Statement</name>
<t>Three core gaps exist in current approaches to regulated agentic
systems:</t>
<t><list style="numbers" type="1">
<t>WIMSE authenticates agents but does not record what they
actually did. A WIT proves "Agent A is authorized" but not
"Agent A executed Task X, under Policy Y, producing Output Z."</t>
<t>No standard mechanism exists to record policy evaluation
outcomes at each decision point in a multi-agent workflow.</t>
<t>No mechanism exists to cryptographically link compensation and
rollback decisions to original actions.</t>
</list></t>
<t>Existing observability tools such as distributed tracing
<xref target="OPENTELEMETRY"/> provide visibility for debugging and monitoring
but do not provide cryptographic assurances. Tracing data is not
cryptographically signed, not tamper-evident, and not designed for
regulatory audit scenarios.</t>
</section>
<section anchor="scope-and-applicability"><name>Scope and Applicability</name>
<t>This document defines:</t>
<t><list style="symbols">
<t>The Execution Context Token (ECT) format (<xref target="ect-format"/>)</t>
<t>DAG structure for task dependency ordering (<xref target="dag-validation"/>)</t>
<t>Policy checkpoint recording (<xref target="policy-claims"/>)</t>
<t>Integration with the WIMSE identity framework
(<xref target="wimse-integration"/>)</t>
<t>An HTTP header for ECT transport (<xref target="http-header"/>)</t>
<t>Audit ledger interface requirements (<xref target="ledger-interface"/>)</t>
</list></t>
<t>The following are out of scope and are handled by WIMSE:</t>
<t><list style="symbols">
<t>Workload authentication and identity provisioning</t>
<t>Key distribution and management</t>
<t>Trust domain establishment and management</t>
<t>Credential lifecycle management</t>
</list></t>
</section>
<section anchor="relationship-to-regulatory-compliance"><name>Relationship to Regulatory Compliance</name>
<t>ECTs are a technical mechanism that can support compliance programs
by providing structured, cryptographically signed execution
records. ECTs do not by themselves constitute compliance with any
regulatory framework referenced in this document.</t>
<t>Compliance with each referenced regulation requires organizational
controls, policies, procedures, validation, and governance measures
beyond the scope of this specification. The regulatory references
in this document are intended to motivate the design requirements,
not to claim that implementing ECTs satisfies these regulations.</t>
<t>ECTs provide evidence of claimed execution ordering and policy
evaluation. They do not independently verify that the claimed
execution actually occurred as described, that the policy
evaluation was correct, or that the agent faithfully performed the
stated action. The trustworthiness of ECT claims depends on the
trustworthiness of the signing agent and the integrity of the
broader deployment environment.</t>
</section>
</section>
<section anchor="conventions-and-definitions"><name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
<?line -18?>
<t>The following terms are used in this document:</t>
<dl>
<dt>Agent:</dt>
<dd>
<t>An autonomous workload, as defined by WIMSE
<xref target="I-D.ietf-wimse-arch"/>, that executes tasks within a workflow.</t>
</dd>
<dt>Task:</dt>
<dd>
<t>A discrete unit of agent work that consumes inputs and produces
outputs.</t>
</dd>
<dt>Directed Acyclic Graph (DAG):</dt>
<dd>
<t>A graph structure representing task dependency ordering where
edges are directed and no cycles exist.</t>
</dd>
<dt>Execution Context Token (ECT):</dt>
<dd>
<t>A JSON Web Token <xref target="RFC7519"/> defined by this specification that
records task execution details and policy evaluation outcomes.</t>
</dd>
<dt>Audit Ledger:</dt>
<dd>
<t>An append-only, immutable log of all ECTs within a workflow or
set of workflows, used for regulatory audit and compliance
verification.</t>
</dd>
<dt>Policy Checkpoint:</dt>
<dd>
<t>A point in a workflow where a policy evaluation outcome is
recorded within an ECT.</t>
</dd>
<dt>Workload Identity Token (WIT):</dt>
<dd>
<t>A WIMSE credential proving a workload's identity within a trust
domain.</t>
</dd>
<dt>Workload Proof Token (WPT):</dt>
<dd>
<t>A WIMSE proof-of-possession token used for request-level
authentication.</t>
</dd>
<dt>Trust Domain:</dt>
<dd>
<t>A WIMSE concept representing an organizational boundary with a
shared identity issuer, corresponding to a SPIFFE <xref target="SPIFFE"/>
trust domain.</t>
</dd>
<dt>Witness:</dt>
<dd>
<t>A third-party entity that observes and attests to the execution
of a task, providing additional accountability.</t>
</dd>
</dl>
</section>
<section anchor="wimse-integration"><name>WIMSE Architecture Integration</name>
<section anchor="wimse-foundation"><name>WIMSE Foundation</name>
<t>The WIMSE architecture <xref target="I-D.ietf-wimse-arch"/> defines:</t>
<t><list style="symbols">
<t>Workload Identity Tokens (WIT) that prove a workload's identity
within a trust domain ("I am Agent X in trust domain Y")</t>
<t>Workload Proof Tokens (WPT) that prove possession of the private
key associated with a WIT ("I control the key for Agent X")</t>
<t>Multi-hop authentication via the service-to-service protocol
<xref target="I-D.ietf-wimse-s2s-protocol"/></t>
</list></t>
<t>The following execution accountability needs are complementary to
the WIMSE scope and are not addressed by workload identity alone:</t>
<t><list style="symbols">
<t>Recording what agents actually do with their authenticated
identity</t>
<t>Recording policy evaluation outcomes at each hop</t>
<t>Maintaining structured execution records</t>
<t>Linking compensation or rollback actions to original tasks</t>
</list></t>
</section>
<section anchor="extension-model"><name>Extension Model</name>
<t>ECTs extend WIMSE by adding an execution accountability layer
between the identity layer and the application layer:</t>
<figure title="WIMSE Extension Architecture Layers" anchor="fig-layers"><artwork type="ascii-art"><![CDATA[
+--------------------------------------------------+
| WIMSE Layer (Identity) |
| WIT: "I am Agent X (spiffe://td/agent/x)" |
| WPT: "I prove I control the key for Agent X" |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| ECT Layer (Execution Accountability) [This Spec]|
| ECT: "Task executed, dependencies met, |
| policy evaluated, outcome recorded" |
+--------------------------------------------------+
|
v
+--------------------------------------------------+
| Ledger Layer (Immutable Record) |
| "All ECTs appended to audit ledger" |
+--------------------------------------------------+
]]></artwork></figure>
<t>This extension reuses the WIMSE signing model, extends JWT claims
using standard JWT extensibility <xref target="RFC7519"/>, and maintains WIMSE
concepts including trust domains and workload identifiers.</t>
</section>
<section anchor="integration-points"><name>Integration Points</name>
<t>An ECT integrates with the WIMSE identity framework through the
following mechanisms:</t>
<t><list style="symbols">
<t>The ECT JOSE header "kid" parameter <bcp14>MUST</bcp14> reference the public
key identifier from the agent's WIT.</t>
<t>The ECT "iss" claim <bcp14>MUST</bcp14> use the WIMSE workload identifier
format (a SPIFFE ID <xref target="SPIFFE"/>).</t>
<t>The ECT <bcp14>MUST</bcp14> be signed with the same private key associated
with the agent's WIT.</t>
<t>The ECT signing algorithm (JOSE header "alg" parameter) <bcp14>MUST</bcp14>
match the algorithm used in the corresponding WIT.</t>
</list></t>
<t>When an agent makes an HTTP request to another agent, the
Execution-Context header is carried alongside WIMSE identity
headers:</t>
<figure title="HTTP Header Stacking" anchor="fig-http-headers"><artwork type="ascii-art"><![CDATA[
HTTP Request from Agent A to Agent B:
Workload-Identity: <WIT for Agent A>
Execution-Context: <ECT recording what A did>
]]></artwork></figure>
<t>When a Workload Proof Token (WPT) is available per
<xref target="I-D.ietf-wimse-s2s-protocol"/>, agents <bcp14>SHOULD</bcp14> include it
alongside the WIT and ECT. ECT verification does not depend
on the presence of a WPT; the ECT is independently verifiable
via the WIT public key.</t>
<t>The receiving agent (Agent B) verifies in order:</t>
<t><list style="numbers" type="1">
<t>WIT (WIMSE layer): Verifies Agent A's identity within the
trust domain. WPT verification, if present, per
<xref target="I-D.ietf-wimse-s2s-protocol"/>.</t>
<t>ECT (this extension): Records what Agent A did, what policy was
evaluated, and what precedent tasks exist.</t>
<t>Ledger: Appends the verified ECT to the audit ledger.</t>
</list></t>
</section>
</section>
<section anchor="ect-format"><name>Execution Context Token Format</name>
<t>An Execution Context Token is a JSON Web Token (JWT) <xref target="RFC7519"/>
signed as a JSON Web Signature (JWS) <xref target="RFC7515"/> using the Compact
Serialization. JWS JSON Serialization <bcp14>MUST NOT</bcp14> be used for ECTs.</t>
<section anchor="jose-header"><name>JOSE Header</name>
<t>The ECT JOSE header <bcp14>MUST</bcp14> contain the following parameters:</t>
<figure title="ECT JOSE Header Example" anchor="fig-header"><sourcecode type="json"><![CDATA[
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
"kid": "agent-a-key-id-123"
}
]]></sourcecode></figure>
<dl>
<dt>alg:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. The digital signature algorithm used to sign the ECT.
<bcp14>MUST</bcp14> match the algorithm in the corresponding WIT.
Implementations <bcp14>MUST</bcp14> support ES256 <xref target="RFC7518"/>. The "alg"
value <bcp14>MUST NOT</bcp14> be "none". Symmetric algorithms (e.g., HS256,
HS384, HS512) <bcp14>MUST NOT</bcp14> be used, as ECTs require asymmetric
signatures for non-repudiation.</t>
</dd>
<dt>typ:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. <bcp14>MUST</bcp14> be set to "wimse-exec+jwt" to distinguish ECTs
from other JWT types, consistent with the WIMSE convention for
type parameter values.</t>
</dd>
<dt>kid:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. The key identifier referencing the public key from
the agent's WIT <xref target="RFC7517"/>. Used by verifiers to look up the
correct public key for signature verification.</t>
</dd>
</dl>
</section>
<section anchor="jwt-claims"><name>JWT Claims</name>
<t>The ECT payload contains both WIMSE-compatible standard JWT claims
and execution context claims defined by this specification.</t>
<section anchor="standard-jwt-claims"><name>Standard JWT Claims</name>
<t>The following standard JWT claims <xref target="RFC7519"/> <bcp14>MUST</bcp14> be present in
every ECT:</t>
<dl>
<dt>iss:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. StringOrURI. The issuer of the ECT, which <bcp14>MUST</bcp14> be
the workload's SPIFFE ID in the format
<spanx style="verb">spiffe://&lt;trust-domain&gt;/&lt;path&gt;</spanx>. This <bcp14>MUST</bcp14> match the "sub"
claim of the agent's WIT.</t>
</dd>
<dt>sub:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. StringOrURI. The subject of the ECT. When present,
<bcp14>MUST</bcp14> equal the "iss" claim. This claim is included for
compatibility with JWT libraries and frameworks that expect a
"sub" claim to be present.</t>
</dd>
<dt>aud:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. StringOrURI or array of StringOrURI. The intended
recipient(s) of the ECT. Because ECTs serve as both inter-agent
messages and audit records, the "aud" claim <bcp14>SHOULD</bcp14> contain the
identifiers of all entities that will verify the ECT. In
practice this means:
</t>
<t><list style="symbols">
<t><strong>Point-to-point delivery</strong>: when an ECT is sent from one
agent to a single next agent, "aud" contains that agent's
workload identity. The receiving agent verifies the ECT and
forwards it to the ledger on behalf of the issuer.</t>
<t><strong>Direct-to-ledger submission</strong>: when an ECT is submitted
directly to the audit ledger (e.g., after a join or at
workflow completion), "aud" contains the ledger's identity.</t>
<t><strong>Multi-audience</strong>: when an ECT must be verified by both the
next agent and the ledger independently, "aud" <bcp14>MUST</bcp14> be an
array containing both identifiers (e.g.,
["spiffe://example.com/agent/next",
"spiffe://example.com/system/ledger"]). Each verifier checks
that its own identity appears in the array.</t>
</list></t>
<t>In multi-parent (join) scenarios where a task depends on ECTs
from multiple parent agents, the joining agent creates a new ECT
with the parent task IDs in "par". The "aud" of this new ECT
is set according to the rules above based on where the ECT will
be delivered — it is independent of the "aud" values in the
parent ECTs.</t>
</dd>
<dt>iat:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. NumericDate. The time at which the ECT was issued.
The ECT records a completed action, so the "iat" value reflects
when the record was created, not when task execution began.</t>
</dd>
<dt>exp:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. NumericDate. The expiration time of the ECT.
Implementations <bcp14>SHOULD</bcp14> set this to 5 to 15 minutes after "iat"
to limit the replay window while allowing for reasonable clock
skew and processing time.</t>
</dd>
</dl>
<t>The standard JWT "nbf" (Not Before) claim is not used in ECTs
because ECTs record completed actions and are valid immediately
upon issuance.</t>
<dl>
<dt>jti:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. String. A globally unique identifier for both the
ECT and the task it records, in UUID format <xref target="RFC9562"/>. Since
each ECT represents exactly one task, "jti" serves as both the
token identifier (for replay detection) and the task identifier
(for DAG parent references in "par"). Receivers <bcp14>MUST</bcp14> reject
ECTs whose "jti" has already been seen within the expiration
window. When "wid" is present, uniqueness is scoped to the
workflow; when "wid" is absent, uniqueness <bcp14>MUST</bcp14> be enforced
globally across the ECT store.</t>
</dd>
</dl>
</section>
<section anchor="exec-claims"><name>Execution Context</name>
<t>The following claims are defined by this specification:</t>
<dl>
<dt>wid:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A workflow identifier that groups related
ECTs into a single workflow. When present, <bcp14>MUST</bcp14> be a UUID
<xref target="RFC9562"/>.</t>
</dd>
<dt>exec_act:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. String. The action or task type identifier describing
what the agent performed (e.g., "process_payment",
"validate_safety", "calculate_dosage"). Note: this claim is
intentionally named "exec_act" rather than "act" to avoid
collision with the "act" (Actor) claim registered by
<xref target="RFC8693"/>.</t>
</dd>
<dt>par:</dt>
<dd>
<t><bcp14>REQUIRED</bcp14>. Array of strings. Parent task identifiers
representing DAG dependencies. Each element <bcp14>MUST</bcp14> be the "jti"
value of a previously verified ECT. An empty array indicates
a root task with no dependencies. A workflow <bcp14>MAY</bcp14> contain
multiple root tasks.</t>
</dd>
</dl>
</section>
<section anchor="policy-claims"><name>Policy Evaluation</name>
<t>The following claims record policy evaluation outcomes:</t>
<dl>
<dt>pol:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The identifier of the policy rule that was
evaluated for this task (e.g.,
"clinical_data_access_policy_v1"). <bcp14>MUST</bcp14> be present when
"pol_decision" is present.</t>
</dd>
<dt>pol_decision:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. The result of the policy evaluation. When
present, <bcp14>MUST</bcp14> be one of the values registered in the ECT Policy
Decision Values registry (<xref target="pol-decision-registry"/>). <bcp14>MUST</bcp14> be
present when "pol" is present. Initial values are:
</t>
<t><list style="symbols">
<t>"approved": The policy evaluation succeeded and the task
was authorized to proceed.</t>
<t>"rejected": The policy evaluation failed. A "rejected" ECT
<bcp14>MUST</bcp14> still be recorded for accountability. An ECT with
"pol_decision" of "rejected" <bcp14>MAY</bcp14> appear as a parent in the
"par" array of a subsequent ECT, but only for compensation,
rollback, or remediation tasks. Agents <bcp14>MUST NOT</bcp14> proceed
with normal workflow execution based on a parent ECT whose
"pol_decision" is "rejected".</t>
<t>"pending_human_review": The policy evaluation requires human
judgment before proceeding. Agents <bcp14>MUST NOT</bcp14> proceed with
dependent tasks until a subsequent ECT from a human reviewer
records an "approved" decision referencing this task as a
parent.</t>
</list></t>
<t>When "pol" and "pol_decision" are absent, the ECT records task
execution without a policy checkpoint. Regulated deployments
<bcp14>SHOULD</bcp14> include policy claims on all ECTs to maintain complete
audit trails.</t>
</dd>
<dt>pol_enforcer:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. StringOrURI. The identity of the entity (system or
person) that evaluated the policy decision. When present,
<bcp14>SHOULD</bcp14> use SPIFFE ID format.</t>
</dd>
</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>
<dl>
<dt>compensation_required:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Boolean. Indicates whether this task is a
compensation or rollback action for a previous task.</t>
</dd>
<dt>compensation_reason:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. String. A human-readable reason for the compensation
action. <bcp14>MUST</bcp14> be present if "compensation_required" is true.
Values <bcp14>SHOULD</bcp14> use structured identifiers (e.g.,
"policy_violation_in_parent_trade") rather than free-form text
to minimize the risk of embedding sensitive information. See
<xref target="data-minimization"/> for privacy guidance.
If "compensation_reason" is present, "compensation_required"
<bcp14>MUST</bcp14> be true.</t>
</dd>
</dl>
<t>Note: compensation ECTs reference historical parent tasks via the
"par" claim. The referenced parent ECTs may have passed their own
"exp" time; ECT expiration applies to the verification window of
the ECT itself, not to its validity as a parent reference in the
ledger.</t>
</section>
<section anchor="extension-claims"><name>Extensions</name>
<dl>
<dt>ext:</dt>
<dd>
<t><bcp14>OPTIONAL</bcp14>. Object. An extension object for domain-specific
claims not defined by this specification. Implementations
that do not understand extension claims <bcp14>MUST</bcp14> ignore them.</t>
</dd>
</dl>
<t>To avoid key collisions between different domains, extension
key names <bcp14>MUST</bcp14> use reverse domain notation (e.g.,
"com.example.custom_field"). Implementations <bcp14>MUST NOT</bcp14> use
unqualified key names within the "ext" object. To prevent
abuse and excessive token size, the serialized JSON
representation of the "ext" object <bcp14>SHOULD NOT</bcp14> exceed 4096
bytes, and the JSON nesting depth within the "ext" object
<bcp14>SHOULD NOT</bcp14> exceed 5 levels. Implementations <bcp14>SHOULD</bcp14> reject
ECTs whose "ext" claim exceeds these limits.</t>
<t>The following extension keys are <bcp14>RECOMMENDED</bcp14> for common use
cases. These are not registered claims; they are carried
within the "ext" object:</t>
<t><list style="symbols">
<t>"org.ietf.wimse.exec_time_ms": Integer. Execution duration in
milliseconds.</t>
<t>"org.ietf.wimse.regulated_domain": String. Regulatory domain
(e.g., "medtech", "finance", "military").</t>
<t>"org.ietf.wimse.model_version": String. AI/ML model version.</t>
<t>"org.ietf.wimse.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>"org.ietf.wimse.inp_classification": String. Data sensitivity
classification (e.g., "public", "confidential", "restricted").</t>
<t>"org.ietf.wimse.pol_timestamp": NumericDate. Time at which the
policy decision was made, if distinct from "iat".</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",
"sub": "spiffe://example.com/agent/clinical",
"aud": "spiffe://example.com/agent/safety",
"iat": 1772064150,
"exp": 1772064750,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
"exec_act": "recommend_treatment",
"par": [],
"pol": "clinical_reasoning_policy_v2",
"pol_decision": "approved",
"pol_enforcer": "spiffe://example.com/policy/clinical-engine",
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
"ext": {
"org.ietf.wimse.pol_timestamp": 1772064145,
"org.ietf.wimse.exec_time_ms": 245,
"org.ietf.wimse.regulated_domain": "medtech",
"org.ietf.wimse.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 audit ledger, which
serves as the authoritative store of previously verified ECTs.</t>
</section>
<section anchor="validation-rules"><name>Validation Rules</name>
<t>When receiving and verifying an ECT, implementations <bcp14>MUST</bcp14> perform
the following DAG validation steps:</t>
<t><list style="numbers" type="1">
<t>Task ID Uniqueness: The "jti" claim <bcp14>MUST</bcp14> be unique within the
applicable scope (the workflow identified by "wid", or the
entire ECT store if "wid" is absent). If an ECT with the same
"jti" already exists, the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Parent Existence: Every task identifier listed in the "par"
array <bcp14>MUST</bcp14> correspond to a task that is available in the ECT
store (either previously recorded in the ledger or received
inline as a verified parent ECT). If any parent task is not
found, the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Temporal Ordering: The "iat" value of every parent task <bcp14>MUST
NOT</bcp14> be greater than the "iat" value of the current task plus a
configurable clock skew tolerance (<bcp14>RECOMMENDED</bcp14>: 30 seconds).
That is, for each parent: <spanx style="verb">parent.iat &lt; child.iat +
clock_skew_tolerance</spanx>. The tolerance accounts for clock skew
between agents; it does not guarantee strict causal ordering
from timestamps alone. Causal ordering is primarily enforced
by the DAG structure (parent existence in the ECT store), not by
timestamps. If any parent task violates this constraint, the
ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Acyclicity: Following the chain of parent references <bcp14>MUST NOT</bcp14>
lead back to the current ECT's "jti". If a cycle is detected,
the ECT <bcp14>MUST</bcp14> be rejected.</t>
<t>Parent Policy Decision: If any parent ECT contains a
"pol_decision" of "rejected" or "pending_human_review", the
current ECT's "exec_act" <bcp14>MUST</bcp14> indicate a compensation,
rollback, remediation, or human review action.
Implementations <bcp14>MUST NOT</bcp14> accept an ECT representing normal
workflow continuation when a parent's "pol_decision" is not
"approved", unless the current ECT has "compensation_required"
set to true. This rule only applies when the parent ECT
contains policy claims.</t>
<t>Trust Domain Consistency: Parent tasks <bcp14>SHOULD</bcp14> belong to the
same trust domain or to a trust domain with which a federation
relationship has been established.</t>
</list></t>
</section>
<section anchor="dag-validation-algorithm"><name>DAG Validation Algorithm</name>
<t>The following pseudocode describes the DAG validation procedure:</t>
<figure title="DAG Validation Pseudocode" anchor="fig-dag-validation"><sourcecode type="pseudocode"><![CDATA[
function validate_dag(ect, ledger, clock_skew_tolerance):
// Step 1: Uniqueness check
if ledger.contains(ect.jti, ect.wid):
return error("ECT ID already exists")
// Step 2: Parent existence and temporal ordering
for parent_id in ect.par:
parent = ledger.get(parent_id)
if parent is null:
return error("Parent task not found: " + parent_id)
if parent.iat >= ect.iat + clock_skew_tolerance:
return error("Parent task not earlier than current")
// Step 3: Cycle detection (with traversal limit)
visited = set()
result = has_cycle(ect.jti, ect.par, ledger, visited,
max_ancestor_limit)
if result is error or result is true:
return error("Circular dependency or depth limit exceeded")
return success
function has_cycle(target_jti, parent_ids, ledger,
visited, max_depth):
if visited.size() >= max_depth:
return error("Maximum ancestor traversal limit exceeded")
for parent_id in parent_ids:
if parent_id == target_jti:
return true
if parent_id in visited:
continue
visited.add(parent_id)
parent = ledger.get(parent_id)
if parent is not null:
result = has_cycle(target_jti, parent.par, ledger,
visited, max_depth)
if result is error or result is true:
return result
return false
]]></sourcecode></figure>
<t>The cycle detection traverses the ancestor graph rooted at the
current task's parents. The complexity is O(V) where V is the
number of ancestor nodes reachable from the current task's parent
references. For typical workflows with shallow DAGs, this is
efficient. To prevent denial-of-service via extremely deep or
wide DAGs, implementations <bcp14>SHOULD</bcp14> enforce a maximum ancestor
traversal limit (<bcp14>RECOMMENDED</bcp14>: 10000 nodes). If the limit is
reached before cycle detection completes, the ECT <bcp14>SHOULD</bcp14> be
rejected. Implementations <bcp14>SHOULD</bcp14> cache cycle detection results
for previously verified tasks to avoid redundant traversals.</t>
</section>
</section>
<section anchor="verification"><name>Signature and Token Verification</name>
<section anchor="verification-procedure"><name>Verification Procedure</name>
<t>When an agent receives an ECT, it <bcp14>MUST</bcp14> perform the following
verification steps in order:</t>
<t><list style="numbers" type="1">
<t>Parse the JWS Compact Serialization to extract the JOSE header,
payload, and signature components per <xref target="RFC7515"/>.</t>
<t>Verify that the "typ" header parameter is "wimse-exec+jwt".</t>
<t>Verify that the "alg" header parameter is not "none" and is
not a symmetric algorithm.</t>
<t>Verify the "kid" header parameter references a known, valid
public key from a WIT within the trust domain.</t>
<t>Retrieve the public key identified by "kid" and verify the JWS
signature per <xref target="RFC7515"/> Section 5.2.</t>
<t>Verify that the signing key identified by "kid" has not been
revoked within the trust domain. Implementations <bcp14>MUST</bcp14> check
the key's revocation status using the trust domain's key
lifecycle mechanism (e.g., certificate revocation list, OCSP,
or SPIFFE trust bundle updates).</t>
<t>Verify the "alg" header parameter matches the algorithm in the
corresponding WIT.</t>
<t>Verify the "iss" claim matches the "sub" claim of the WIT
associated with the "kid" public key.</t>
<t>Verify the "aud" claim contains the verifier's own workload
identity. When "aud" is an array, it is sufficient that the
verifier's identity appears as one element; the presence of
other audience values does not cause verification failure.
When the verifier is the audit ledger, the ledger's own
identity <bcp14>MUST</bcp14> appear in "aud".</t>
<t>Verify the "exp" claim indicates the ECT has not expired.</t>
<t>Verify the "iat" claim is not unreasonably far in the past
(implementation-specific threshold, <bcp14>RECOMMENDED</bcp14> maximum of
15 minutes) and is not unreasonably far in the future
(<bcp14>RECOMMENDED</bcp14>: no more than 30 seconds ahead of the
verifier's current time, to account for clock skew).</t>
<t>Verify all required claims ("jti", "exec_act", "par") are
present and well-formed.</t>
<t>If "pol" or "pol_decision" is present, verify that both are
present and that "pol_decision" is one of "approved",
"rejected", or "pending_human_review".</t>
<t>Perform DAG validation per <xref target="dag-validation"/>.</t>
<t>If all checks pass, the ECT <bcp14>MUST</bcp14> be appended to the audit
ledger.</t>
</list></t>
<t>If any verification step fails, the ECT <bcp14>MUST</bcp14> be rejected and the
failure <bcp14>MUST</bcp14> be logged for audit purposes. Error messages
<bcp14>SHOULD NOT</bcp14> reveal whether specific parent task IDs exist in the
ledger, to prevent information disclosure.</t>
<t>When ECT verification fails during HTTP request processing, the
receiving agent <bcp14>SHOULD</bcp14> respond with HTTP 403 (Forbidden) if the
WIT is valid but the ECT is invalid, and HTTP 401
(Unauthorized) if the ECT signature verification fails. The
response body <bcp14>SHOULD</bcp14> include a generic error indicator without
revealing which specific verification step failed. The receiving
agent <bcp14>MUST NOT</bcp14> process the requested action when ECT verification
fails.</t>
</section>
<section anchor="verification-pseudocode"><name>Verification Pseudocode</name>
<figure title="ECT Verification Pseudocode" anchor="fig-verification"><sourcecode type="pseudocode"><![CDATA[
function verify_ect(ect_jws, verifier_id,
trust_domain_keys, ledger):
// Parse JWS
(header, payload, signature) = parse_jws(ect_jws)
// Verify header
if header.typ != "wimse-exec+jwt":
return reject("Invalid typ parameter")
if header.alg == "none" or is_symmetric(header.alg):
return reject("Prohibited algorithm")
// Look up public key
public_key = trust_domain_keys.get(header.kid)
if public_key is null:
return reject("Unknown key identifier")
// Verify signature
if not verify_jws_signature(header, payload,
signature, public_key):
return reject("Invalid signature")
// Verify key not revoked
if is_key_revoked(header.kid, trust_domain_keys):
return reject("Signing key has been revoked")
// Verify algorithm alignment
wit = get_wit_for_key(header.kid)
if header.alg != wit.alg:
return reject("Algorithm mismatch with WIT")
// Verify issuer matches WIT subject
if payload.iss != wit.sub:
return reject("Issuer does not match WIT subject")
// Verify audience
if verifier_id not in payload.aud:
return reject("ECT not intended for this recipient")
// Verify not expired
if payload.exp < current_time():
return reject("ECT has expired")
// Verify iat freshness (not too old, not in the future)
if payload.iat < current_time() - max_age_threshold:
return reject("ECT issued too long ago")
if payload.iat > current_time() + clock_skew_tolerance:
return reject("ECT issued in the future")
// Verify required claims
for claim in ["jti", "exec_act", "par"]:
if claim not in payload:
return reject("Missing required claim: " + claim)
// Validate policy claims (optional, but must be paired)
if "pol" in payload or "pol_decision" in payload:
if "pol" not in payload or "pol_decision" not in payload:
return reject("pol and pol_decision must both be present")
if payload.pol_decision not in
["approved", "rejected", "pending_human_review"]:
return reject("Invalid pol_decision value")
// Validate DAG (against ledger or inline parent ECTs)
result = validate_dag(payload, ledger,
clock_skew_tolerance)
if result is error:
return reject("DAG validation failed")
// All checks passed; append to ledger
ledger.append(payload)
return accept
]]></sourcecode></figure>
</section>
</section>
<section anchor="ledger-interface"><name>Audit Ledger Interface</name>
<t>ECTs are designed to be recorded in an immutable audit ledger for
compliance verification and post-hoc analysis. This specification
defines required properties for the ledger but does not mandate
a specific storage technology. Implementations <bcp14>MAY</bcp14> use
append-only logs, databases with cryptographic commitment schemes,
distributed ledgers, or any storage mechanism that provides the
required properties.</t>
<t>An audit ledger implementation <bcp14>MUST</bcp14> provide:</t>
<t><list style="numbers" type="1">
<t>Append-only semantics: Once an ECT is recorded, it <bcp14>MUST NOT</bcp14> be
modified or deleted.</t>
<t>Ordering: The ledger <bcp14>MUST</bcp14> maintain a total ordering of ECT
entries via a monotonically increasing sequence number.</t>
<t>Lookup by ECT ID: The ledger <bcp14>MUST</bcp14> support efficient retrieval
of ECT entries by "jti" value.</t>
<t>Integrity verification: The ledger <bcp14>SHOULD</bcp14> provide a mechanism
to verify that no entries have been tampered with (e.g.,
hash chains or Merkle trees).</t>
</list></t>
<t>The ledger <bcp14>SHOULD</bcp14> be maintained by an entity independent of the
workflow agents to reduce the risk of collusion.</t>
</section>
<section anchor="use-cases"><name>Use Cases</name>
<t>This section describes representative use cases demonstrating how
ECTs provide execution records in regulated environments. These
examples demonstrate ECT mechanics; production deployments would
include additional domain-specific requirements beyond the scope
of this specification.</t>
<t>Note: task identifiers in this section are abbreviated for
readability. In production, all "jti" values are required to be
UUIDs per <xref target="exec-claims"/>.</t>
<section anchor="medical-device-sdlc-workflow"><name>Medical Device SDLC Workflow</name>
<t>In a medical device software development lifecycle (SDLC),
AI agents assist across multiple phases from requirements
analysis through release approval. Regulatory frameworks
including <xref target="FDA-21CFR11"/> Section 11.10(e) and <xref target="EU-MDR"/> require
audit trails documenting the complete development process for
software used in medical devices.</t>
<figure title="Medical Device SDLC Workflow" anchor="fig-medtech-sdlc"><artwork><![CDATA[
Agent A (Spec Reviewer):
jti: task-001 par: []
exec_act: review_requirements_spec
pol: spec_review_policy_v2 pol_decision: approved
Agent B (Code Generator):
jti: task-002 par: [task-001]
exec_act: implement_module
pol: coding_standards_v3 pol_decision: approved
Agent C (Test Agent):
jti: task-003 par: [task-002]
exec_act: execute_test_suite
pol: test_coverage_policy_v1 pol_decision: approved
Agent D (Build Agent):
jti: task-004 par: [task-003]
exec_act: build_release_artifact
pol: build_validation_v2 pol_decision: approved
Human Release Manager:
jti: task-005 par: [task-004]
exec_act: approve_release
pol: release_approval_policy pol_decision: approved
pol_enforcer: spiffe://meddev.example/human/release-mgr-42
ext: {org.ietf.wimse.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",
"sub": "spiffe://bank.example/agent/operations",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772150550,
"exp": 1772151150,
"jti": "550e8400-e29b-41d4-a716-446655440099",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"exec_act": "initiate_trade_rollback",
"par": ["550e8400-e29b-41d4-a716-446655440003"],
"pol": "compensation_policy_v1",
"pol_decision": "approved",
"pol_enforcer": "spiffe://bank.example/human/compliance-officer",
"compensation_required": true,
"compensation_reason": "policy_violation_in_parent_trade"
}
]]></sourcecode></figure>
<t>The "par" claim links the compensation action to the original
trade, creating an auditable chain from execution through
violation discovery to remediation.</t>
</section>
<section anchor="autonomous-logistics-coordination"><name>Autonomous Logistics Coordination</name>
<t>In a logistics workflow, multiple compliance checks complete
before shipment commitment. The DAG structure records that all
required checks were completed:</t>
<figure title="Logistics Workflow with Parallel Tasks" anchor="fig-logistics"><artwork><![CDATA[
Agent A (Route Planning):
jti: task-001 par: []
exec_act: plan_route
pol: route_policy_v1 pol_decision: approved
Agent B (Customs):
jti: task-002 par: [task-001]
exec_act: validate_customs
pol: customs_policy_v2 pol_decision: approved
Agent C (Safety):
jti: task-003 par: [task-001]
exec_act: verify_cargo_safety
pol: safety_policy_v1 pol_decision: approved
Agent D (Payment):
jti: task-004 par: [task-002, task-003]
exec_act: authorize_payment
pol: payment_policy_v3 pol_decision: approved
System (Commitment):
jti: task-005 par: [task-004]
exec_act: commit_shipment
pol: commitment_policy_v1 pol_decision: approved
]]></artwork></figure>
<t>Note that tasks 002 and 003 both depend only on task-001 and can
execute in parallel. Task 004 depends on both, demonstrating the
DAG's ability to represent parallel execution with a join point.</t>
</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>This section addresses security considerations following the
guidance in <xref target="RFC3552"/>.</t>
<section anchor="threat-model"><name>Threat Model</name>
<t>The following threat actors are considered:</t>
<t><list style="symbols">
<t>Malicious agent (insider threat): An agent within the trust
domain that intentionally creates false ECT claims.</t>
<t>Compromised agent (external attacker): An agent whose private
key has been obtained by an external attacker.</t>
<t>Ledger tamperer: An entity attempting to modify or delete ledger
entries after they have been recorded.</t>
<t>Time manipulator: An entity attempting to manipulate timestamps
to alter perceived execution ordering.</t>
</list></t>
</section>
<section anchor="self-assertion-limitation"><name>Self-Assertion Limitation</name>
<t>ECTs are self-asserted by the executing agent. The agent claims
what it did, and this claim is signed with its private key. A
compromised or malicious agent could create ECTs with false claims
(e.g., setting "pol_decision" to "approved" without actually
evaluating the policy).</t>
<t>ECTs do not independently verify that:</t>
<t><list style="symbols">
<t>The claimed execution actually occurred as described</t>
<t>The policy evaluation was correctly performed</t>
<t>The input/output hashes correspond to the actual data processed</t>
<t>The agent faithfully performed the stated action</t>
</list></t>
<t>The trustworthiness of ECT claims depends on the trustworthiness
of the signing agent. To mitigate single-agent false claims,
regulated environments <bcp14>SHOULD</bcp14> use the "org.ietf.wimse.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>
<section anchor="witness-attestation-model"><name>Witness Attestation Model</name>
<t>To address the self-assertion limitation of the
"org.ietf.wimse.witnessed_by" extension, witnesses <bcp14>SHOULD</bcp14> submit their
own independent signed ECTs to the audit ledger attesting to the
observed task. A witness attestation ECT:</t>
<t><list style="symbols">
<t><bcp14>MUST</bcp14> set "iss" to the witness's own workload identity.</t>
<t><bcp14>MUST</bcp14> set "exec_act" to "witness_attestation" (or a domain-
specific equivalent).</t>
<t><bcp14>MUST</bcp14> include the observed task's "jti" in the "par" array,
linking the attestation to the original task.</t>
<t><bcp14>MUST</bcp14> set "pol_decision" to "approved" to indicate the witness
confirms the observation.</t>
</list></t>
<t>When a task's "org.ietf.wimse.witnessed_by" extension lists one or more
witnesses, auditors <bcp14>SHOULD</bcp14> verify that corresponding witness
attestation ECTs exist in the ledger for each listed witness. A
mismatch between the extension value and the set of independent
witness ECTs in the ledger <bcp14>SHOULD</bcp14> be flagged during audit review.</t>
<t>This model converts witness attestation from a self-asserted claim
to a cryptographically verifiable property of the ledger: the
witness independently signs their own ECT using their own key,
and the ledger records both the original task ECT and the witness
attestation ECTs.</t>
</section>
</section>
<section anchor="organizational-prerequisites"><name>Organizational Prerequisites</name>
<t>ECTs operate within a broader trust framework. The guarantees
provided by ECTs are only meaningful when the following
organizational controls are in place:</t>
<t><list style="symbols">
<t>Key management governance: Controls over who provisions agent
keys and how keys are protected.</t>
<t>Ledger integrity governance: The ledger is maintained by an
entity independent of the workflow agents.</t>
<t>Policy lifecycle management: Policy identifiers in ECTs map to
actual, validated policy rules.</t>
<t>Agent deployment governance: Agents are deployed and maintained
in a manner that preserves their integrity.</t>
</list></t>
</section>
<section anchor="signature-verification"><name>Signature Verification</name>
<t>ECTs <bcp14>MUST</bcp14> be signed with the agent's private key using JWS
<xref target="RFC7515"/>. The signature algorithm <bcp14>MUST</bcp14> match the algorithm
specified in the agent's WIT. Receivers <bcp14>MUST</bcp14> verify the ECT
signature against the WIT public key before processing any
claims. Receivers <bcp14>MUST</bcp14> verify that the signing key has not been
revoked within the trust domain (see step 6 in
<xref target="verification"/>).</t>
<t>If signature verification fails or if the signing key has been
revoked, the ECT <bcp14>MUST</bcp14> be rejected entirely and the failure <bcp14>MUST</bcp14>
be logged.</t>
<t>Implementations <bcp14>MUST</bcp14> use established JWS libraries and <bcp14>MUST NOT</bcp14>
implement custom signature verification.</t>
</section>
<section anchor="replay-attack-prevention"><name>Replay Attack Prevention</name>
<t>ECTs include short expiration times (<bcp14>RECOMMENDED</bcp14>: 5-15 minutes) to
limit the window for replay attacks. The "aud" claim restricts
replay to unintended recipients: an ECT intended for Agent B
will be rejected by Agent C. The "iat" claim enables receivers to
reject ECTs that are too old, even if not yet expired.</t>
<t>The DAG structure provides additional replay protection: an ECT
referencing parent tasks that already have a recorded child task
with the same action can be flagged as a potential replay.</t>
<t>Implementations <bcp14>MUST</bcp14> maintain a cache of recently-seen "jti"
values to detect replayed ECTs within the expiration window.
An ECT with a duplicate "jti" value <bcp14>MUST</bcp14> be rejected.</t>
</section>
<section anchor="man-in-the-middle-protection"><name>Man-in-the-Middle Protection</name>
<t>ECTs do not replace transport-layer security. ECTs <bcp14>MUST</bcp14> be
transmitted over TLS or mTLS connections. When used with the WIMSE
service-to-service protocol <xref target="I-D.ietf-wimse-s2s-protocol"/>,
transport security is already established. HTTP Message Signatures
<xref target="RFC9421"/> provide an alternative channel binding mechanism.</t>
<t>The defense-in-depth model provides:</t>
<t><list style="symbols">
<t>TLS/mTLS (transport layer): Prevents network-level tampering.</t>
<t>WIT/WPT (WIMSE identity layer): Proves agent identity and
request authorization.</t>
<t>ECT (execution accountability layer): Records what the agent did
and under what policy.</t>
</list></t>
</section>
<section anchor="key-compromise"><name>Key Compromise</name>
<t>If an agent's private key is compromised, an attacker can forge
ECTs that appear to originate from that agent. To mitigate this
risk:</t>
<t><list style="symbols">
<t>Implementations <bcp14>SHOULD</bcp14> use short-lived keys and rotate them
frequently (hours to days, not months).</t>
<t>Private keys <bcp14>SHOULD</bcp14> be stored in Hardware Security Modules (HSMs)
or equivalent secure key storage.</t>
<t>Trust domains <bcp14>MUST</bcp14> support rapid key revocation.</t>
<t>Upon suspected compromise, the trust domain <bcp14>MUST</bcp14> revoke the
compromised key and issue a new WIT with a fresh key pair.</t>
</list></t>
<t>ECTs signed with a compromised key that were recorded in the
ledger before revocation remain valid historical records but <bcp14>SHOULD</bcp14>
be flagged in the ledger as "signed with subsequently revoked key"
for audit purposes.</t>
</section>
<section anchor="collusion-and-false-claims"><name>Collusion and False Claims</name>
<t>A single malicious agent cannot forge parent task references
because DAG validation requires parent tasks to exist in the
ledger. However, multiple colluding agents could potentially
create a false execution history if they control the ledger.</t>
<t>Mitigations include:</t>
<t><list style="symbols">
<t>Independent ledger maintenance: The ledger <bcp14>SHOULD</bcp14> be maintained
by an entity independent of the workflow agents.</t>
<t>Witness attestation: Using the "org.ietf.wimse.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" claim (<xref target="compensation-claims"/>)
deserves particular attention: because it is human-readable and
may describe the circumstances of a failure or policy violation,
it risks exposing sensitive operational details. Implementations
<bcp14>SHOULD</bcp14> use short, structured reason codes (e.g.,
"policy_violation_in_parent_trade") rather than free-form
natural language explanations. Implementers <bcp14>SHOULD</bcp14> review
"compensation_reason" values for potential information leakage
before deploying to production.</t>
</section>
<section anchor="storage-and-access-control"><name>Storage and Access Control</name>
<t>ECTs stored in audit ledgers <bcp14>SHOULD</bcp14> be access-controlled so that
only authorized auditors and regulators can read them.
Implementations <bcp14>SHOULD</bcp14> consider encryption at rest for ledger
storage containing sensitive regulatory data.</t>
<t>Full input and output data (corresponding to the hashes in ECTs)
<bcp14>SHOULD</bcp14> be stored separately from the ledger with additional access
controls, since auditors may need to verify hash correctness but
general access to the data values is not needed.</t>
</section>
<section anchor="regulatory-access"><name>Regulatory Access</name>
<t>ECTs are designed for interpretation by qualified human auditors
and regulators. ECTs provide structural records of execution
ordering and policy evaluation; they are not intended for public
disclosure.</t>
</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<section anchor="media-type-registration"><name>Media Type Registration</name>
<t>This document requests registration of the following media type
in the "Media Types" registry maintained by IANA:</t>
<dl>
<dt>Type name:</dt>
<dd>
<t>application</t>
</dd>
<dt>Subtype name:</dt>
<dd>
<t>wimse-exec+jwt</t>
</dd>
<dt>Required parameters:</dt>
<dd>
<t>none</t>
</dd>
<dt>Optional parameters:</dt>
<dd>
<t>none</t>
</dd>
<dt>Encoding considerations:</dt>
<dd>
<t>8bit; an ECT is a JWT that is a JWS using the Compact
Serialization, which is a sequence of Base64url-encoded values
separated by period characters.</t>
</dd>
<dt>Security considerations:</dt>
<dd>
<t>See the Security Considerations section of this document.</t>
</dd>
<dt>Interoperability considerations:</dt>
<dd>
<t>none</t>
</dd>
<dt>Published specification:</dt>
<dd>
<t>This document</t>
</dd>
<dt>Applications that use this media type:</dt>
<dd>
<t>Applications that implement regulated agentic workflows requiring
execution context tracing and audit trails.</t>
</dd>
<dt>Additional information:</dt>
<dd>
<t>Magic number(s): none
File extension(s): none
Macintosh file type code(s): none</t>
</dd>
<dt>Person and email address to contact for further information:</dt>
<dd>
<t>Christian Nennemann, ietf@nennemann.de</t>
</dd>
<dt>Intended usage:</dt>
<dd>
<t>COMMON</t>
</dd>
<dt>Restrictions on usage:</dt>
<dd>
<t>none</t>
</dd>
<dt>Author:</dt>
<dd>
<t>Christian Nennemann</t>
</dd>
<dt>Change controller:</dt>
<dd>
<t>IETF</t>
</dd>
</dl>
</section>
<section anchor="header-registration"><name>HTTP Header Field Registration</name>
<t>This document requests registration of the following header field
in the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
maintained by IANA:</t>
<dl>
<dt>Field name:</dt>
<dd>
<t>Execution-Context</t>
</dd>
<dt>Status:</dt>
<dd>
<t>permanent</t>
</dd>
<dt>Specification document:</dt>
<dd>
<t>This document, <xref target="http-header"/></t>
</dd>
</dl>
</section>
<section anchor="claims-registration"><name>JWT Claims Registration</name>
<t>This document requests registration of the following claims in
the "JSON Web Token Claims" registry maintained by IANA:</t>
<texttable title="JWT Claims Registrations" anchor="_table-claims">
<ttcol align='center'>Claim Name</ttcol>
<ttcol align='left'>Claim Description</ttcol>
<ttcol align='center'>Change Controller</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>wid</c>
<c>Workflow Identifier</c>
<c>IETF</c>
<c><xref target="exec-claims"/></c>
<c>exec_act</c>
<c>Action/Task Type</c>
<c>IETF</c>
<c><xref target="exec-claims"/></c>
<c>par</c>
<c>Parent Task Identifiers</c>
<c>IETF</c>
<c><xref target="exec-claims"/></c>
<c>pol</c>
<c>Policy Rule Identifier</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_decision</c>
<c>Policy Decision Result</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pol_enforcer</c>
<c>Policy Enforcer Identity</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>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>compensation_required</c>
<c>Compensation Flag</c>
<c>IETF</c>
<c><xref target="compensation-claims"/></c>
<c>compensation_reason</c>
<c>Compensation Reason</c>
<c>IETF</c>
<c><xref target="compensation-claims"/></c>
<c>ext</c>
<c>Extension Object</c>
<c>IETF</c>
<c><xref target="extension-claims"/></c>
</texttable>
</section>
<section anchor="pol-decision-registry"><name>ECT Policy Decision Values Registry</name>
<t>This document establishes the "ECT Policy Decision Values"
registry under the "JSON Web Token (JWT)" group. Registration
policy is Specification Required per <xref target="RFC8126"/>.</t>
<t>The initial contents of the registry are:</t>
<texttable title="ECT Policy Decision Values" anchor="_table-pol-decision">
<ttcol align='center'>Value</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='center'>Change Controller</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>approved</c>
<c>Policy evaluation succeeded</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>rejected</c>
<c>Policy evaluation failed</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
<c>pending_human_review</c>
<c>Awaiting human judgment</c>
<c>IETF</c>
<c><xref target="policy-claims"/></c>
</texttable>
</section>
</section>
</middle>
<back>
<references title='References' anchor="sec-combined-references">
<references title='Normative References' anchor="sec-normative-references">
<reference anchor="RFC7515">
<front>
<title>JSON Web Signature (JWS)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
<date month="May" year="2015"/>
<abstract>
<t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7515"/>
<seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>
<reference anchor="RFC7517">
<front>
<title>JSON Web Key (JWK)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<date month="May" year="2015"/>
<abstract>
<t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7517"/>
<seriesInfo name="DOI" value="10.17487/RFC7517"/>
</reference>
<reference anchor="RFC7519">
<front>
<title>JSON Web Token (JWT)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
<date month="May" year="2015"/>
<abstract>
<t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7519"/>
<seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>
<reference anchor="RFC7518">
<front>
<title>JSON Web Algorithms (JWA)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<date month="May" year="2015"/>
<abstract>
<t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7518"/>
<seriesInfo name="DOI" value="10.17487/RFC7518"/>
</reference>
<reference anchor="RFC9562">
<front>
<title>Universally Unique IDentifiers (UUIDs)</title>
<author fullname="K. Davis" initials="K." surname="Davis"/>
<author fullname="B. Peabody" initials="B." surname="Peabody"/>
<author fullname="P. Leach" initials="P." surname="Leach"/>
<date month="May" year="2024"/>
<abstract>
<t>This specification defines UUIDs (Universally Unique IDentifiers) --
also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform
Resource Name namespace for UUIDs. A UUID is 128 bits long and is
intended to guarantee uniqueness across space and time. UUIDs were
originally used in the Apollo Network Computing System (NCS), later
in the Open Software Foundation's (OSF's) Distributed Computing
Environment (DCE), and then in Microsoft Windows platforms.</t>
<t>This specification is derived from the OSF DCE specification with the
kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have
been incorporated into this document. This document obsoletes RFC
4122.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9562"/>
<seriesInfo name="DOI" value="10.17487/RFC9562"/>
</reference>
<reference anchor="RFC9110">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="I-D.ietf-wimse-arch">
<front>
<title>Workload Identity in a Multi System Environment (WIMSE) Architecture</title>
<author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
<organization>CyberArk</organization>
</author>
<author fullname="Yaroslav Rosomakho" initials="Y." surname="Rosomakho">
<organization>Zscaler</organization>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>University of Applied Sciences Bonn-Rhein-Sieg</organization>
</author>
<date day="30" month="September" year="2025"/>
<abstract>
<t> The increasing prevalence of cloud computing and micro service
architectures has led to the rise of complex software functions being
built and deployed as workloads, where a workload is defined as a
running instance of software executing for a specific purpose. This
document discusses an architecture for designing and standardizing
protocols and payloads for conveying workload identity and security
context information.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-wimse-arch-06"/>
</reference>
<reference anchor="I-D.ietf-wimse-s2s-protocol">
<front>
<title>WIMSE Workload-to-Workload Authentication</title>
<author fullname="Brian Campbell" initials="B." surname="Campbell">
<organization>Ping Identity</organization>
</author>
<author fullname="Joseph A. Salowey" initials="J. A." surname="Salowey">
<organization>CyberArk</organization>
</author>
<author fullname="Arndt Schwenkschuster" initials="A." surname="Schwenkschuster">
<organization>SPIRL</organization>
</author>
<author fullname="Yaron Sheffer" initials="Y." surname="Sheffer">
<organization>Intuit</organization>
</author>
<date day="16" month="October" year="2025"/>
<abstract>
<t> The WIMSE architecture defines authentication and authorization for
software workloads in a variety of runtime environments, from the
most basic ones up to complex multi-service, multi-cloud, multi-
tenant deployments. This document defines the simplest, atomic unit
of this architecture: the protocol between two workloads that need to
verify each other&#x27;s identity in order to communicate securely. The
scope of this protocol is a single HTTP request-and-response pair.
To address the needs of different setups, we propose two protocols,
one at the application level and one that makes use of trusted TLS
transport. These two protocols are compatible, in the sense that a
single call chain can have some calls use one protocol and some use
the other. Workload A can call Workload B with mutual TLS
authentication, while the next call from Workload B to Workload C
would be authenticated at the application level.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-wimse-s2s-protocol-07"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
</references>
<references title='Informative References' anchor="sec-informative-references">
<reference anchor="RFC3552">
<front>
<title>Guidelines for Writing RFC Text on Security Considerations</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="B. Korver" initials="B." surname="Korver"/>
<date month="July" year="2003"/>
<abstract>
<t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="72"/>
<seriesInfo name="RFC" value="3552"/>
<seriesInfo name="DOI" value="10.17487/RFC3552"/>
</reference>
<reference anchor="RFC8693">
<front>
<title>OAuth 2.0 Token Exchange</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="A. Nadalin" initials="A." surname="Nadalin"/>
<author fullname="B. Campbell" initials="B." role="editor" surname="Campbell"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="C. Mortimore" initials="C." surname="Mortimore"/>
<date month="January" year="2020"/>
<abstract>
<t>This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8693"/>
<seriesInfo name="DOI" value="10.17487/RFC8693"/>
</reference>
<reference anchor="RFC9421">
<front>
<title>HTTP Message Signatures</title>
<author fullname="A. Backman" initials="A." role="editor" surname="Backman"/>
<author fullname="J. Richer" initials="J." role="editor" surname="Richer"/>
<author fullname="M. Sporny" initials="M." surname="Sporny"/>
<date month="February" year="2024"/>
<abstract>
<t>This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9421"/>
<seriesInfo name="DOI" value="10.17487/RFC9421"/>
</reference>
<reference anchor="I-D.ni-wimse-ai-agent-identity">
<front>
<title>WIMSE Applicability for AI Agents</title>
<author fullname="Ni Yuan" initials="N." surname="Yuan">
<organization>Huawei</organization>
</author>
<author fullname="Peter Chunchi Liu" initials="P. C." surname="Liu">
<organization>Huawei</organization>
</author>
<date day="20" month="October" year="2025"/>
<abstract>
<t> This document discusses WIMSE applicability to Agentic AI, so as to
establish independent identities and credential management mechanisms
for AI agents.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ni-wimse-ai-agent-identity-01"/>
</reference>
<reference anchor="SPIFFE" target="https://spiffe.io/docs/latest/spiffe-about/overview/">
<front>
<title>Secure Production Identity Framework for Everyone (SPIFFE)</title>
<author >
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="EU-AI-ACT" target="https://eur-lex.europa.eu/eli/reg/2024/1689">
<front>
<title>Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2024" month="June" day="13"/>
</front>
</reference>
<reference anchor="FDA-21CFR11" target="https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11">
<front>
<title>Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures</title>
<author >
<organization>U.S. Food and Drug Administration</organization>
</author>
<date />
</front>
</reference>
<reference anchor="MIFID-II" target="https://eur-lex.europa.eu/eli/dir/2014/65">
<front>
<title>Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2014" month="May" day="15"/>
</front>
</reference>
<reference anchor="DORA" target="https://eur-lex.europa.eu/eli/reg/2022/2554">
<front>
<title>Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2022" month="December" day="14"/>
</front>
</reference>
<reference anchor="EU-MDR" target="https://eur-lex.europa.eu/eli/reg/2017/745">
<front>
<title>Regulation (EU) 2017/745 on medical devices (MDR)</title>
<author >
<organization>European Parliament and Council of the European Union</organization>
</author>
<date year="2017" month="April" day="05"/>
</front>
</reference>
<reference anchor="OPENTELEMETRY" target="https://opentelemetry.io/docs/specs/otel/">
<front>
<title>OpenTelemetry Specification</title>
<author >
<organization>Cloud Native Computing Foundation</organization>
</author>
<date />
</front>
</reference>
<reference anchor="I-D.ietf-scitt-architecture">
<front>
<title>An Architecture for Trustworthy and Transparent Digital Supply Chains</title>
<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
<organization>Fraunhofer SIT</organization>
</author>
<author fullname="Antoine Delignat-Lavaud" initials="A." surname="Delignat-Lavaud">
<organization>Microsoft Research</organization>
</author>
<author fullname="Cedric Fournet" initials="C." surname="Fournet">
<organization>Microsoft Research</organization>
</author>
<author fullname="Yogesh Deshpande" initials="Y." surname="Deshpande">
<organization>ARM</organization>
</author>
<author fullname="Steve Lasker" initials="S." surname="Lasker">
</author>
<date day="10" month="October" year="2025"/>
<abstract>
<t> Traceability in supply chains is a growing security concern. While
verifiable data structures have addressed specific issues, such as
equivocation over digital certificates, they lack a universal
architecture for all supply chains. This document defines such an
architecture for single-issuer signed statement transparency. It
ensures extensibility, interoperability between different
transparency services, and compliance with various auditing
procedures and regulatory requirements.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-scitt-architecture-22"/>
</reference>
<reference anchor="I-D.ietf-oauth-transaction-tokens">
<front>
<title>Transaction Tokens</title>
<author fullname="Atul Tulshibagwale" initials="A." surname="Tulshibagwale">
<organization>SGNL</organization>
</author>
<author fullname="George Fletcher" initials="G." surname="Fletcher">
<organization>Practical Identity LLC</organization>
</author>
<author fullname="Pieter Kasselman" initials="P." surname="Kasselman">
<organization>Defakto Security</organization>
</author>
<date day="24" month="January" year="2026"/>
<abstract>
<t> Transaction Tokens (Txn-Tokens) are designed to maintain and
propagate user identity and authorization context across workloads
within a trusted domain during the processing of external requests,
such as API calls. They ensure that this context is preserved
throughout the call chain, even when new transactions are initiated
internally, thereby enhancing security and consistency in complex,
multi-service architectures.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-oauth-transaction-tokens-07"/>
</reference>
<reference anchor="I-D.oauth-transaction-tokens-for-agents">
<front>
<title>Transaction Tokens For Agents</title>
<author fullname="Ashay Raut" initials="A." surname="Raut">
<organization>Amazon</organization>
</author>
<date day="10" month="February" year="2026"/>
<abstract>
<t> This document specifies an extension to the OAuth Transaction Tokens
framework (https://drafts.oauth.net/oauth-transaction-tokens/draft-
ietf-oauth-transaction-tokens.html) to support agent context
propagation within Transaction Tokens for agent-based workloads. The
extension defines two new context fields: &#x27;actor&#x27; and &#x27;principal&#x27;.
The &#x27;actor&#x27; field identifies the agent performing the action, while
the &#x27;principal&#x27; field identifies the human or system entity that
initiated the agent&#x27;s action. For autonomous agents operating
independently, the &#x27;principal&#x27; field MAY be omitted. These
additional context fields enable services within the call graph to
make more granular access control decisions, thereby enhancing
security.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-oauth-transaction-tokens-for-agents-04"/>
</reference>
</references>
</references>
<?line 1583?>
<section numbered="false" anchor="related-work"><name>Related Work</name>
<section numbered="false" anchor="wimse-workload-identity"><name>WIMSE Workload Identity</name>
<t>The WIMSE architecture <xref target="I-D.ietf-wimse-arch"/> and service-to-
service protocol <xref target="I-D.ietf-wimse-s2s-protocol"/> provide the
identity foundation upon which ECTs are built. WIT/WPT answer
"who is this agent?" and "does it control the claimed key?" while
ECTs record "what did this agent do?" and "what policy was
evaluated?" Together they form an identity-plus-accountability
framework for regulated agentic systems.</t>
</section>
<section numbered="false" anchor="oauth-20-token-exchange-and-the-act-claim"><name>OAuth 2.0 Token Exchange and the "act" Claim</name>
<t><xref target="RFC8693"/> defines the OAuth 2.0 Token Exchange protocol and
registers the "act" (Actor) claim in the JWT Claims registry.
The "act" claim creates nested JSON objects representing a
delegation chain: "who is acting on behalf of whom." While
the nesting superficially resembles a chain, it is strictly
linear (each "act" object contains at most one nested "act"),
represents authorization delegation rather than task execution,
and carries no task identifiers, policy decisions, or
input/output integrity data. The "act" chain cannot represent
branching (fan-out) or convergence (fan-in) and therefore
cannot form a DAG.</t>
<t>ECTs intentionally use the distinct claim name "exec_act" for the
action/task type to avoid collision with the "act" claim. The
two concepts are orthogonal: "act" records "who authorized whom,"
ECTs record "what was done, in what order, with what policy
outcomes."</t>
</section>
<section numbered="false" anchor="transaction-tokens"><name>Transaction Tokens</name>
<t>OAuth Transaction Tokens <xref target="I-D.ietf-oauth-transaction-tokens"/>
propagate authorization context across workload call chains.
The Txn-Token "req_wl" claim accumulates a comma-separated list
of workloads that requested replacement tokens, which is the
closest existing mechanism to call-chain recording.</t>
<t>However, "req_wl" cannot form a DAG because:</t>
<t><list style="symbols">
<t>It is linear: a comma-separated string with no branching or
merging representation. When a workload fans out to multiple
downstream services, each receives the same "req_wl" value and
the branching is invisible.</t>
<t>It is incomplete: only workloads that request a replacement
token from the Transaction Token Service appear in "req_wl";
workloads that forward the token unchanged are not recorded.</t>
<t>It carries no task-level granularity, no parent references,
no policy evaluation outcomes, and no execution content.</t>
</list></t>
<t>Extensions for agentic use cases
(<xref target="I-D.oauth-transaction-tokens-for-agents"/>) add agent
identity and constraints ("agentic_ctx") but no execution
ordering or DAG structure.</t>
<t>ECTs and Transaction Tokens are complementary: a Txn-Token
propagates authorization context ("this request is authorized
for scope X on behalf of user Y"), while an ECT records
execution accountability ("task T was performed, depending on
tasks P1 and P2, with policy Z evaluated and approved"). An
agent request could carry both a Txn-Token for authorization
and an ECT for execution recording. The WPT "tth" claim
defined in <xref target="I-D.ietf-wimse-s2s-protocol"/> can hash-bind a
WPT to a co-present Txn-Token; a similar binding mechanism
for ECTs is a potential future extension.</t>
</section>
<section numbered="false" anchor="distributed-tracing-opentelemetry"><name>Distributed Tracing (OpenTelemetry)</name>
<t>OpenTelemetry <xref target="OPENTELEMETRY"/> and similar distributed tracing
systems provide observability for debugging and monitoring. ECTs
differ in several important ways: ECTs are cryptographically
signed per-task with the agent's private key; ECTs are
tamper-evident through JWS signatures; ECTs enforce DAG validation
rules; and ECTs are designed for regulatory audit rather than
operational monitoring. OpenTelemetry data is typically controlled
by the platform operator and can be modified or deleted without
detection. ECTs and distributed traces are complementary: traces
provide observability while ECTs provide signed execution records.
ECTs may reference OpenTelemetry trace identifiers in the "ext"
claim for correlation.</t>
</section>
<section numbered="false" anchor="blockchain-and-distributed-ledgers"><name>Blockchain and Distributed Ledgers</name>
<t>Both ECTs and blockchain systems provide immutable records. This
specification intentionally defines only the ECT token format and
is agnostic to the storage mechanism. ECTs can be stored in
append-only logs, databases with cryptographic commitments,
blockchain networks, or any storage providing the required
properties defined in <xref target="ledger-interface"/>.</t>
</section>
<section numbered="false" anchor="scitt-supply-chain-integrity-transparency-and-trust"><name>SCITT (Supply Chain Integrity, Transparency, and Trust)</name>
<t>The SCITT architecture <xref target="I-D.ietf-scitt-architecture"/> defines a
framework for creating transparent and auditable supply chain
records through Transparency Services, Signed Statements, and
Receipts. ECTs and SCITT are naturally complementary: the ECT
"wid" (Workflow Identifier) claim can serve as a correlation
identifier referenced in SCITT Signed Statements, linking a
complete ECT audit trail to a supply chain transparency record.
For example, in a regulated manufacturing workflow, each agent
step produces an ECT (recording what was done, by whom, under
what policy), while the overall workflow identified by "wid" is
registered as a SCITT Signed Statement on a Transparency Service.
This enables auditors to verify both the individual execution
steps (via ECT DAG validation) and the end-to-end supply chain
integrity (via SCITT Receipts) using the "wid" as the shared
correlation point. The "ext" claim in ECTs (<xref target="exec-claims"/>)
can carry SCITT-specific metadata such as Transparency Service
identifiers or Receipt references for tighter integration.</t>
</section>
<section numbered="false" anchor="w3c-verifiable-credentials"><name>W3C Verifiable Credentials</name>
<t>W3C Verifiable Credentials represent claims about subjects (e.g.,
identity, qualifications). ECTs represent execution records of
actions (what happened, in what order, under what policy). While
both use JWT/JWS as a serialization format, their semantics and
use cases are distinct.</t>
</section>
</section>
<section numbered="false" anchor="implementation-guidance"><name>Implementation Guidance</name>
<section numbered="false" anchor="minimal-implementation"><name>Minimal Implementation</name>
<t>A minimal conforming implementation needs to:</t>
<t><list style="numbers" type="1">
<t>Create JWTs with all required claims ("iss", "aud", "iat",
"exp", "jti", "exec_act", "par") and policy claims ("pol",
"pol_decision") when policy evaluation was performed.</t>
<t>Sign ECTs with the agent's private key using an algorithm
matching the WIT (ES256 recommended).</t>
<t>Verify ECT signatures against WIT public keys.</t>
<t>Perform DAG validation (parent existence, temporal ordering,
cycle detection).</t>
<t>Append verified ECTs to the audit ledger.</t>
</list></t>
</section>
<section numbered="false" anchor="storage-recommendations"><name>Storage Recommendations</name>
<t><list style="symbols">
<t>Append-only log: Simplest approach; immutability by design.</t>
<t>Database with hash chains: Periodic cryptographic commitments
over batches of entries.</t>
<t>Distributed ledger: Maximum immutability guarantees for
cross-organizational audit.</t>
<t>Hybrid: Hot storage in a database, cold archive in immutable
storage.</t>
</list></t>
</section>
<section numbered="false" anchor="performance-considerations"><name>Performance Considerations</name>
<t><list style="symbols">
<t>ES256 signature verification: approximately 1ms per ECT on
modern hardware.</t>
<t>DAG validation: O(V) where V is the number of reachable ancestor
nodes (typically small for shallow workflows).</t>
<t>JSON serialization: sub-millisecond per ECT.</t>
<t>Total per-request overhead: approximately 5-10ms, acceptable
for regulated workflows where correctness is prioritized over
latency.</t>
</list></t>
</section>
<section numbered="false" anchor="interoperability"><name>Interoperability</name>
<t>Implementations are expected to use established JWT/JWS libraries
(JOSE) for token creation and verification. Custom cryptographic
implementations are strongly discouraged. Implementations are
expected to be tested against multiple JWT libraries to ensure
interoperability.</t>
</section>
</section>
<section numbered="false" anchor="regulatory-compliance-mapping"><name>Regulatory Compliance Mapping</name>
<t>The following table summarizes how ECTs can contribute to
compliance with various regulatory frameworks. ECTs are a
technical building block; achieving compliance requires
additional organizational measures beyond this specification.</t>
<texttable title="Regulatory Compliance Mapping" anchor="_table-regulatory">
<ttcol align='left'>Regulation</ttcol>
<ttcol align='left'>Requirement</ttcol>
<ttcol align='left'>ECT Contribution</ttcol>
<c>FDA 21 CFR Part 11</c>
<c>Audit trails recording date, time, operator, actions (11.10(e))</c>
<c>Cryptographic signatures and append-only ledger contribute to audit trail requirements</c>
<c>EU MDR</c>
<c>Technical documentation traceability (Annex II)</c>
<c>ECTs provide signed records of AI-assisted decision sequences</c>
<c>EU AI Act Art. 12</c>
<c>Automatic logging capabilities for high-risk AI</c>
<c>ECTs contribute cryptographic activity logging</c>
<c>EU AI Act Art. 14</c>
<c>Human oversight capability</c>
<c>ECTs can record evidence that human oversight events occurred</c>
<c>MiFID II</c>
<c>Transaction records for supervisory authorities</c>
<c>ECTs provide cryptographic execution sequence records</c>
<c>DORA Art. 12</c>
<c>ICT activity logging policies</c>
<c>ECT ledger contributes to ICT activity audit trail</c>
</texttable>
</section>
<section numbered="false" anchor="examples"><name>Examples</name>
<section numbered="false" anchor="example-1-simple-two-agent-workflow"><name>Example 1: Simple Two-Agent Workflow</name>
<t>Agent A executes a data retrieval task and sends the ECT to
Agent B:</t>
<t>ECT JOSE Header:</t>
<figure><sourcecode type="json"><![CDATA[
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
"kid": "agent-a-key-2026-02"
}
]]></sourcecode></figure>
<t>ECT Payload:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://example.com/agent/data-retrieval",
"sub": "spiffe://example.com/agent/data-retrieval",
"aud": "spiffe://example.com/agent/validator",
"iat": 1772064150,
"exp": 1772064750,
"jti": "550e8400-e29b-41d4-a716-446655440001",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"exec_act": "fetch_patient_data",
"par": [],
"pol": "clinical_data_access_policy_v1",
"pol_decision": "approved",
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
}
]]></sourcecode></figure>
<t>Agent B receives the ECT, verifies it, executes a validation
task, and creates its own ECT:</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://example.com/agent/validator",
"sub": "spiffe://example.com/agent/validator",
"aud": "spiffe://example.com/system/ledger",
"iat": 1772064160,
"exp": 1772064760,
"jti": "550e8400-e29b-41d4-a716-446655440002",
"wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
"exec_act": "validate_safety",
"par": ["550e8400-e29b-41d4-a716-446655440001"],
"pol": "safety_validation_policy_v2",
"pol_decision": "approved"
}
]]></sourcecode></figure>
<t>The resulting DAG:</t>
<figure><artwork><![CDATA[
task-...-0001 (fetch_patient_data)
|
v
task-...-0002 (validate_safety)
]]></artwork></figure>
</section>
<section numbered="false" anchor="example-2-medical-device-sdlc-with-release-approval"><name>Example 2: Medical Device SDLC with Release Approval</name>
<t>A multi-step medical device software lifecycle workflow with
autonomous agents and human release approval:</t>
<t>Task 1 (Spec Review Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/spec-reviewer",
"sub": "spiffe://meddev.example/agent/spec-reviewer",
"aud": "spiffe://meddev.example/agent/code-gen",
"iat": 1772064150,
"exp": 1772064750,
"jti": "a1b2c3d4-0001-0000-0000-000000000001",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "review_requirements_spec",
"par": [],
"pol": "spec_review_policy_v2",
"pol_decision": "approved",
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
}
]]></sourcecode></figure>
<t>Task 2 (Code Generation Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/code-gen",
"sub": "spiffe://meddev.example/agent/code-gen",
"aud": "spiffe://meddev.example/agent/test-runner",
"iat": 1772064200,
"exp": 1772064800,
"jti": "a1b2c3d4-0001-0000-0000-000000000002",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "implement_module",
"par": ["a1b2c3d4-0001-0000-0000-000000000001"],
"pol": "coding_standards_v3",
"pol_decision": "approved"
}
]]></sourcecode></figure>
<t>Task 3 (Autonomous Test Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/test-runner",
"sub": "spiffe://meddev.example/agent/test-runner",
"aud": "spiffe://meddev.example/agent/build",
"iat": 1772064260,
"exp": 1772064860,
"jti": "a1b2c3d4-0001-0000-0000-000000000003",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "execute_test_suite",
"par": ["a1b2c3d4-0001-0000-0000-000000000002"],
"pol": "test_coverage_policy_v1",
"pol_decision": "approved"
}
]]></sourcecode></figure>
<t>Task 4 (Build Agent):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/agent/build",
"sub": "spiffe://meddev.example/agent/build",
"aud": "spiffe://meddev.example/human/release-mgr-42",
"iat": 1772064310,
"exp": 1772064910,
"jti": "a1b2c3d4-0001-0000-0000-000000000004",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "build_release_artifact",
"par": ["a1b2c3d4-0001-0000-0000-000000000003"],
"pol": "build_validation_v2",
"pol_decision": "approved",
"out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc"
}
]]></sourcecode></figure>
<t>Task 5 (Human Release Manager Approval):</t>
<figure><sourcecode type="json"><![CDATA[
{
"iss": "spiffe://meddev.example/human/release-mgr-42",
"sub": "spiffe://meddev.example/human/release-mgr-42",
"aud": "spiffe://meddev.example/system/ledger",
"iat": 1772064510,
"exp": 1772065110,
"jti": "a1b2c3d4-0001-0000-0000-000000000005",
"wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
"exec_act": "approve_release",
"par": ["a1b2c3d4-0001-0000-0000-000000000004"],
"pol": "release_approval_policy",
"pol_decision": "approved",
"pol_enforcer": "spiffe://meddev.example/human/release-mgr-42",
"ext": {
"org.ietf.wimse.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 "org.ietf.wimse.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",
"sub": "spiffe://bank.example/agent/execution",
"aud": "spiffe://bank.example/system/ledger",
"iat": 1772064250,
"exp": 1772064850,
"jti": "f1e2d3c4-0004-0000-0000-000000000004",
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
"exec_act": "execute_trade",
"par": [
"f1e2d3c4-0002-0000-0000-000000000002",
"f1e2d3c4-0003-0000-0000-000000000003"
],
"pol": "trade_execution_policy_v3",
"pol_decision": "approved"
}
]]></sourcecode></figure>
<t>The "par" array with two entries records that both compliance
checking and liquidity verification were completed before trade
execution.</t>
</section>
</section>
<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>
<t>The author thanks the WIMSE working group for their foundational
work on workload identity in multi-system environments. The
concepts of Workload Identity Tokens and Workload Proof Tokens
provide the identity foundation upon which execution context
tracing is built.</t>
</section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA9W923bbVpYo+o6vQNMPIasJSpQl22GqqrcsybHSlq2S5LjS
lQw1SEIkYhJgAaBktuMe5yPOB+xv2Z9yvuTM67oAoCSn83BORlUiksC6zDXX
vF+iKAqqtFoko7Bz8imZrKs0z8KjPKuST1V4lX9MsjK8yYvwOC2rIh2vq2Qa
Hs6SrEon4Ye8+HizyO/KThCPx0VyC4N8OD27PAkbQ3WCSVwls7zYjMKymgbT
fJLFS5h1WsQ3VZQlWZYs4yyL7tJlmUSJvh9N+P1odzco1+NlWpbwbbVZwaun
J1evgmy9HCfFKJjC8KMAVvA0iIskhpVcwhBFWm06wR2sc1bk65WurxN8TDbw
7XQUhGEUmtlCmY2+xbcWeTwN0ylut9rQt7Hs/U73zt+up2kVVkWcLujzJF+u
FmmcTRL6WCSz9SJG0JWbskqWZRDE62qeFzQ//D8Mb9aLBUPkaF4ArOHl8K1C
hZ7Ii1mcpf8V40Jh89k0WSUZLi28SMokLibzpKAH4ZV0MQrTpLr5Xwawg2kS
BFleLOH92wTnvXh19PxgeGD/fG7//Nb++UL+/Pbg2Z7+ORzu4p+n0fEAZ5FD
wyW0fF3uldGqyKt8ki9GQZBmN7VVPD040JFfPPv2qU6yvzfU0bJUp0gjOoBI
zwSfuDw/ffXqZER7V1ymw0/C8yKfrid0tKfyRviqADDj8RFen9wmxSbPkrDL
w/Q6PE5czJJqFM6ralWOdnbKVXpzkwzSfAcwt9zBwywr+TaKx/m62slhpNs0
uduhAQgfw5t4USIKnLyPDk+jw6Mrf5UXjBe4vO7J+164t7u3vzN89uLbML8J
q3kSnqyLfJUAKpzHBeDTEk87zqb681G+zibpIlzEmzSbhdP8LgvncbHMs7QE
ZCvWi6QMYfC4qNKbdJLGizAFBF8sUgDiBPZ8aH84dX84nFRbAJGsi2iRfBok
uLIY/rOTLNIdQPAds3hn//hdtPssGj6lLy3S4z8RovRo6x51c3VQvM8AXjDE
q+PDaG949OpiOPSheoX/DfeGfRhimuD7r5JpUsAeLbzLPk5XhfBueLJIJlUB
MJvAAxOgCuV37neX6SyLK8Cmsh0id3d3g2RyUwxm+e0OYF0BG9ihtcDydibz
eFUlRXS6A+RLPxzurGDyaDhsQZUtUHo/uByEr/J8SrA5Ltaz8HC6TDMky7Qj
ePzs9NXpcXR66oPjOC1gL3Dd4DSG+zvPDnZO3n8lfgEKLePiY1KVgD/hTZoB
ZWNkgtnX+FYZds9SmD08Pf0qxJmmxY4sy0ObIaDNQTQ8+OPR5vjdxeGDt3Bv
Z+/gYB/3PU1naQVbhUEYzvA3oEK6SOmiIAnBaSxMSgA2fNnFeX7PHeKp/Tu0
Fw3hf/t/PDCALp0dXzwEjuHznef7B4QFyTSdwCanyW06SfDQjy9+xyZ5QP/A
n0e7eOZ//B7fnZ+8vTp5c3J2cnXxk7/Vd8BBr5JFskyqYhNerpIJUkPae/um
YGQkk/yC4QYlvFju5PBDG+3fsp2jRb6ehm+JEcIeliuQQICGv4LdTPVCG05a
TtKqIgabVoBfQIw8RpvjDBEQgqyMidtFFUlu+tC23yNAX2ao8GgQRSDIjJGe
TKoguJqnJXCUCV1vOHDAcDjwrTJi9+Toquz14URAnKrgG9xBldORfFBJyvBg
oCJn60WVhpckD4Un2W0K1FYoCclovcDdLl20qSODNuQwHNPIWUHiDDgAPIfF
hSCE3ILcEJZA0JNpP0TaRYMDp2S6TzgUlx8DKxHC10nRD1f5Ip1swuQ2Xqz5
bgDLBykvKfuEhFbgg2FhBUE8KfKyDFhaqXKGMj62XGeCYrCulxuG1hSPnkXn
BrACgfBdWs2bomo4WcQgGuHuf7h89zb8kIz5SMLuDx+uegELW304BzjO0sXw
MMniMQoIDek0hHMDGTKr4P+BAyVHyoVn5nEVluvVKi8qd/sgBZkpBgEBfl0m
YQynh3wIh5lsJgDNcFbEqzkQysPve/YscO4iWQGJRXjRYaigO0kR2nxU9xxI
COtK4skccHaSEhquctgLnxOKPzBvlTA4t4DcIPWHUwDhusTTQUQugeoQ+uAX
SxAuFnz4xWZV5bQd2NaqSJcp3mpEvMMwS+6C11dX5+E8iQGVgFMki2k/MBcp
kovUD/G+0TWbMlvB64rQxckIjvEiz2YloDDgJ6oIBmd4aIPooAABvOHmzDOi
1uN1uiAMGy/yyUc6uUBODgAK9wnuOcAty6twDHezKpPFDeIXTFHBZeu7x4tg
CwRjQJsLb1SaLgdMQZbpdLoAXeMJSpRG/IbPT8KzHMDCtA3Iy++mC2bK8PPn
FhXkyxe96YDa+XhdVkaVI62L6AajTDUHrXA2fwAB6Iz1kQBUCqAS5vfzqx6A
nXZDR1GiEjBJ8MrLn6EqP0Fjua5qBMtWIjvP78ySy9BZMxw8InYOXxQhU5gQ
DngRgmAJslhoMVWXG5kdwSYC8y1tImI64SAnnuHr/C65RZLX0H8J/xKLK/F0
Cte0tDQJiN4E2FcVj0E8qjYAl3/P8jtc0t08D0GAQmKEBAA0ElbKzFh8q4M7
JCp3MTKeDPCOPspNx2/jFaAhkm64HnfzhMDgqNpF8s81EBnGlrsEboGQB5yz
RhRCIgqw3wtD/VyeAZg4KZIY4bnYwEurRb7Bk8izfJmvS2Y/TASDSQ5LB/kP
iIqciauq4/0jnl6kRBEIv1egoNhLZDG6DP+f/+v/xrkXa7qwnz8bzfHLlz58
dJQe/kJlfvgUIJ5+/oyCJyATDiQAcThdn4k4En6X6eHOlsQ4FT7RMv6IK8Ax
LdPplkkCU9D7kd0ATIcUK4a3gWcsAJZLOCp4vTfYJki4ckKocgLdII/tE4AF
0ZKSnprFq3CcVHcJ4G4LjrrrbSKkTOFcKT3L75hF2kUJeBgn4XlAgxTgBySK
vhHBAOero6nBOtj9YSlrA7qP7Edo1naLBh4r32mxRcE7TWEnS5Ip8ekxcFw4
MDxPXAoxzuIWpmZeEKjQE4PsDlQC9MUlvqZ3l/bs3Btmix5DC+KyXBd4wZA8
ABkH4gHTLcNLFHTwJTzjAhAD4EXHg1AE/oS7FX0Yb26Rw/1LSmbweudkZ4FI
HiCFDu89JZ9biSxgToilbcAcgB8dF3FgoOHEEeClDpku4bu0FKk8/a9k2qFR
YUB63zzDaASLvAIpJPx7P4RbDATnnA/6pz4OCuwNb8m7dQXye/gfg04Q7MGk
b3MUA/HSTx24E1QEAO1CDBv6tgkyTLMQrHCaSEZEqlS0gON5ypO3zekdKgFo
kWYfiX4CxjNDRCaBSyjyxWIcg6ygU9MIAK1ZigSNqTeiw4kKIvkY8U4uGjyc
g4hYrmHxSMwduR21C3geeKGnl1mmzejMw5DQn4zXs5mSIjRtAcXBERgTCA/0
VV8Qc/AWODTPi7pZjKePp92EiKoGOGgVA2CKKLmlm8k3Hb8HuYKewtW5khBL
x+UExOoizeWuXE5AZaRXD5F3TQRAW6giKmEkS2xRs0jL6oUs04fdz5+BSkb8
6cuXHrwLsrQjSpMUibhrJOgNky0EBLw9jWcRoF7K+iaPINgNN3XykdGNcVVe
YYyNWOngN05FpMbVEvWwpNxQZcPgALtgFCZ9qX2RRzr0hBE2zx5dWUEYX0VN
POIH5CUCO/CcGbyCQxY38SQJPVkA3uMHIvMAvkxC6A2gOgspKDbD3UN+WJpj
wy/hKk2RqYFwTPuiYzIyY02mJC1D902IifcHETYK/52YiFwGfXgZZ3CNiY7C
4Rcor05zVL/CpERGm5ZzY+vwnj0Cfo7zwIVcpDcJalWJ+wTi30Ui9s55usIr
fGHx9cgKTkGr2uAwDCSwE2DZLfoebBEOcVkGY9kuoYorcWy7Zg6fFl6rCoxc
axgRQAuoskDabRWSuj4CoNm06iSABTcgBsJzxHor987B/TyqDUPE1nmlsJYw
Qae6aBcgkwZiWYqFgDRUgAK8jQbjfmivFxOQGXoJMppyCeIlPhSMk00OP5GC
SXhHlqy6ui5ahrNNs9IyqG+OzhJxHW79lNR5Vr0SmoUpmHdF+gGRvJzNCXzg
KUCHfjUKKHKJEgQZEsTKxAEQ8QLXyMJkc0KboTHd87ZUiGQWoimB5YK81Y2i
QWpdXYA7ZF/Y8ApxMzK4Y7IxAkA+IfFjSjwoKSdw7RAfzauNiUl6A0xEQwUp
GeZRZrQ3MaAJeuo2jjYDPwdk85kKX5STqvAqAxbCwWQoagEgkJqJvYa3RN4Z
HKDlYcIHsTXw9LFgCRNOpC/8WDAG2QopJusphACOMoOcCPnILR4lsnLyICDH
Sekz08GPAPA70gc6Z+8vrzp9/m/49h39fXHyt/enFyfH+Pfl68M3b8wfgTxx
+frd+zfH9i/75tG7s7OTt8f8Mnwbel8FnbPDnzp8PTrvzq9O3709fNNp3FdC
aRZ4iYiDpEsgLwNztPjOy6Pz//O/h/sgZv/LxaujveHwWxAt+MOL4fN9+ACK
o1zGPIOD5I8kPYKQmsQFyVcof8crtPyjgQ8wf06+NbhvAM0//QMh88so/PN4
shru/1W+wA17XyrMvC8JZs1vGi8zEFu+apnGQNP7vgZpf72HP3mfFe7Ol3/+
N5APkzAavvi3vwZ1XgkHsGSOsS5biCtwSJKiR8EIubqjOKvG1udLyeYuZawg
HWwx6citFZG8JLGGTaIkDTsSMArrNC1y2gkiCcjtKXF1Ky0LRwPkX6OgnWYg
vZeiQKFMn6BbPyehHinbsZouD8V0+b01XfJcbMu0opcxYRKwtslgd4hQMBPK
JgxNayQlaTMkpi76FInb98iFvJKaFfjzZ/HoG/vSlPlqwxxMqnZorAK0aEtU
WbMvHYLdZntFhZfksTckbunxr3DrEV430J+XyzXbHxb5jE4F7hqxjsZpAqBg
QWVCh2d03z6jHEqHDenbN8XDy741OhDp9shItwwzR68yc9PZwBdbNwtahAEX
rEdXn+FmYKotNkU2KfK0LCRPrBhHzBPJvbkm35RWmDTwIWYBc7OY6M7lGCfZ
NulOtCKjH/xvlaMxRSwv+KgD0H+uQeqMFsltgpEsvmyLt4vk02Oa2NtEDvBe
VT7ex9kWS9hGxDY83XmMHNpsMgWlDe0qxIVB6mfXCFosJM4DMJr/+PIFXq8c
eRkBkVbIPnllAK1iGqGnHY6PR6drz6pqwrgcVxjJUaoJyoqkIeEmXYO+I9jG
02kqm6kZl5DLMjAOXQuWqx59ftLUfEhM5/cc319w1W4P22bxdhXIB6zZBAOy
h7TjGezcxzRVR7qd0zBecvRX+Hei+e7PP3V67uRNO7k7s4OCIuqsChJQYXaU
REB3zycpCVWMKmTFwRWIxE3v4JOItrIkWgDZV6N5vqorZrdpzDLVPRb6Fv7j
2+jrfNCVOl1sEAMdknSiRyRHI+JXeWD1Y1/NdGzqTKS3WODpkC+MVk7WL7GO
WdtXbnTxtPAsaWjgMUftjvMIjxpAFSEsrkFfz3NAoZbTKHyTZmRF9oxMSGfU
viSWJM+6RLydrsWJMcaeobNNVAz2mAoIAUx4JZnabD2NRbxJikCtxiRDK0jp
JyNax2yloTHoFwD2f//3fwM+TtIULlsV/Gv01f/8a/Cb2jTf0GxdvZm9cOs/
v+FL+NrVKPQvXpfDzkY7O9V0hw5+51Ov475zzu/wVbv/yuBLv2tLW5e95Yfb
3w051JoEblb+OfQOuBf+gwxqGMLxi0ABXsNgMCvGoO7n+pJBAwctzwc3/+Nf
BXI4Cc9Xdt/Rt/4/DjuWwwzaGdmLr30T/QQMnUMVylh2YyNC7JjaOt5Lv2t5
cK+Cz6PwyU06i+iulRyY8xcTRKy332OotJey80VsqK7DZq0+IiGvrqe+L3Sj
DH/4oFq4uPaNqR5/kfGEcDjic18scEz8StFYRPApHaedyxVZyKgR8puUXa1P
nnjSwTlKoSUICY54EJFoWsJmD0mwtAEM5cPGVuPfRhuB5VnGrufYm2HkH96Z
SIKw8zEFFAfRCUYCVS8k9dbYm5hfr8dwSYRd233B7PnSmky+QTihOGzn6YCI
1xE7E42L4SF2Gy2wgknU5G2kwNNjRxDseRPQoGON87FgougNETNqQobIPPeu
29hiFjNgVdV8GXY9kMH3Dsh6tAwYF5Y9kYHNi1ZnTmqCLk/6Abg1ecmJSC/j
j+wwJeO4iOh0HzOJBJiRgwJPuRFWostLMVKgKNAJacJIaogTSBBAg+XRvBcy
L52vushgEfznSww1awQdjJA6/BklN8tyDv+KcYf1ZfKTCObCF2xQjZ/+1aMV
jgvAUAxa4mve6mUFkgUMgCSCIdkqlYpQip7AW1BtiSyuANkekAD7KmuJNYbv
PQgUVWABy+h8RZcf1UFmYq4yap2YzJICNgSyA1fspjFy8u84qhGvftlmCk1x
4YEKt+TrpJuJGD5gcRVAmqS31o7YlTPryQhkAWGrhHHAXkm4DUtBvVH4oz4q
x9iimSIC4jl6ShmJI97W+2F6I/sErF1J1sIDYB+wYxXh0PUd9bA2CdsWjBHc
JG99zTXP+RGWrVvvPcJoqiFn1uCC/lSxZaAHj/gHwlkAN2UHFeuOLnskbXCb
teYVE7PPTxz3HRP4LS8gjraG97n8KRB6F3sPm+h1fOHSvnAASqMNF0JPCEZ9
XsK24oXo67B1eIWH8n4I1dqJVNbYDlBcYKZGZFEu4+cnv+ZwmOKxY3yscxsa
DoXUWGii5VWGngpV+rUE5fgzHCORW0xautw7eNbp4zfVZoXf2Ayif/31ruKf
kJ3BTxxpEUdwNaJ0Gg33nnaCLz5t4RUJVTELlc2cfIpRl0PCAtOjlUFNvGLz
12jx0kC9RvQBVcj3Ind6gFH7uPs2LrGdQYThqdEpWX+iQdQ7RzAxJ/0CLg+v
jmCGRjHA/8Q7xE4GemUHHrvcLDG2Gb3nug7Q3pPBbNAPX+OwCM7Xl09f7OPn
g+Fer4EMZNkl2VHDj+JSR0WDj0mnIKyBiaMiWcHVURMTHGMNsoahJ8T26ieM
3005DGGdlnOOewmZUTGDRLkOc8bKPtl84VkT6mIFj4nxkJBnP6Q3HBmIoIYY
DsjUcvQ1MUiFJb1hlijTwnB4X9Yw5/Wczuu92ACE0BSkIi/y/GO4XgmhFUeV
NzRA1OJezfiJNxMAccQOKLiYd5U68u29XMUbYpRyHctwnGucbIRaPAyGjNIT
mUWY9kPFavHJ99qeaXFPkHHbQXmZdXtLy7yeiVtRRQOI0yzAaMYNaYNBkLJt
0Dm6ywot8e+K9xencpBsgTTpBEdXyEVSuJ0ythydYzmzIqmhX0jT4cH/NKr6
n4kpRswU/7rzZwDk/K//SVOmZZ0GdMr1GC8qC8myEl8uhSdwJ+q3ad0JPPMr
IojdCnJjlIiU+yr5gYsas33Akc51cbyKVFUciXwJQ0UH1pToNuGpLNJxQcGO
xF2d0Ebx4KxwSWj6pV2qwzl3Tm2A6ZH1O+ZsDy1IIMvG5P9sOUDxe7N1Pl2l
MGS37PlgeJlMYlQ82K+N9mAkW4Ts5F7k0CqU35OyjGdqLSYWL/atPgMMvtNd
iEjosDJjbOM7LO4OEpvYjY7xril8ZdzausBTNEGvMBcjJY0rRXtFjDkd8P2f
4H9/In0RzZjsvgAdN0VU/9OfRuTUFFcEHhxdBaaHGYtoIgmSXZ2CXJMww9sq
qoRsSmlAZUyM37AI1TRNmvAEX9Q0AqYKsRphhjh0F6PQllYqQEkQDxCPcTKP
Fzd6YnwjB2bj7I7DncsbNjO4bfP4Y8VKHvzDHrbFpk1qU04X3yDBj8Nfc5KL
w7iyuybnENt0kXT1WoClO3FEZLt4tk/jrCjm19e7RMl57MiXQC8JKVW2do7J
GC1N8JOjHOiylCDGmZw73RtZLOUEEMo7OMow4Kd//kfHULCEhZ8B7F2sjriU
jjzZ/hyHde6IyejnXzBW/gQtycrWONBMkIqjTkC1Ql+7tXmTV75U2kobIHCe
ZhIFCTya1Bo8rp6NwDMuPMf/SgEXroCw1HBsGYSVO77aOJ5FZYwHp0BUTOnA
MVyjgbxNM50e02I78F3HSF54FhrXY9+nu1mRtbpQRxcOx5m78Rjtt+MYRQEM
TqHt6EVCqgEjjBO9+PAQBY9XNUVRbxGvgaWY0FAnWbgI7yCE1cju2/USjmpy
DFvXuJZ0maBHgJmiWQ5QT7qnUxRPVZpQZ3KsN8YEyfTDMheGE1eyLBSaMO8W
D4cuRTVPTIwvRubQCUh4Jj/gO6nHySxGYQKYzIPbgGdSMbzRjhzu0CJfC2Un
CRSPEM7pAP81PAiXaUYhCUw0aDsoIoC0hnlAsocVqNFwZNmUPMspRmurSMN+
1xgUGzJBTDBHB+Xkj4AlEpEwQVcZYgcsVHR6TxDqZOObTth9C2B5mcB4Sc8y
bYSV2psI8ccu5xPo1k+nNE4pCmBDp32CEnqy2ARrUEXoqNHFDqv5tUpbWTXF
Xs8W+ZgcUuss/ec68QyFsG+HtAlzIHjRsbqMFtb+/j3IV2IGJIkPCxKQqHyZ
sq+fXFSMdSJIoB4fE7HHxBV25XZgvZ1QPcCluwR2hjtL7PLZ0OFNEzRAI8Wv
LdM1U9ILGIQr18qG6BmKgCTwgrgkElsxrKKYFkjw490cFGZZ5hyV+QVgxxTY
ALquSsp6MOYWB4uJGiF+qYwHahLc97S0phY+A4ovQ8KDzsepUJzAMrfv+GqZ
1+Nx421lKgnWcpgQZzUHLSkwShfKKqeYqSdP2uwhn5/g5fW1ECvsi3xPcTH3
qQ8gEt2xTtYQhwkJDdt2jpZ4DRUFwUuwECMwHQAIU45YZEKLaqKz5ayEmuQ6
tlgZUDziNSDftruBW5UsKA3TJoXTWaMEtmHscGiSHIQb2fhDkVk6QieuQYND
wsWGD4k/Ta7L+CapNhiAN4kXE8q+uJ7mKNkSRgLpSEYMWqUcyJ5QkuZoBzhZ
LE8yDTu6sU4IiDdnUAK60DcIuNs8nZJ2sFhw1oJhkvxM9xAT5JVCFckM1fGC
zlaBiGVACIhwYWrwO1S5vyRAYsjwucN7HUGGxH8nGgWvpev+U1EkYUJvzpNW
irfPWErIFAsj3ab5ujR210RNu4dZmCxXKKnQ2uAScsoKxs+ERZ7L0ggMWV5f
g4OeZ4c/qWSGiodJFNMhSrlHEsV0Yj31n5/4gflbbtKDubNwk1ZYpaX9Jl3N
PfTUwA0eDUUW0WfIzmpT77hGQiohZUa87EwWKQWaX2NOBmAUYy+Ndn07JLSs
q/NImfBVeOpaU1NcGjeg9Zuf7tsIvAAArm3Ci0H+wJM1LjzyEnlNpCkHiVNj
25NjwpITmr/zo/t4sZGEisjk3OkP6NEKHXuDu33avLdnlIRTih+T5cRYHoD1
jQ4lXt0maP68atsnJulMkmQqIYfK1kTfid00KbzdRGQosY2HZ9Z1z/A3lA9I
eG4fFuk3lD2WFWrAY+td52zCeu6eeEApA5l1Dh8N4EycKfAySUAvWcSFIztu
CubH1pIQo6pYopuLBWJOjaYgYVyPG8MiSo+GsVCsOEbSixVTbmvIvojSmkgF
fAJdJggg0SwsDXCEWZX7Y0dIZ+mgdfuAEXb75oBWXFzger5extk10rDkbuth
mSwHeppn+XU9nRF9HJNkqVsQ3tq+P+eMrBrCjhU40XTRADXrYjHPG/IqxS9k
dYjMwWabE+cbWpXK4JHz6ww7gscHe30o2NyHH6W/iKxT1fQXuRL2cHCDmCtk
4kNtwhTJd5rfaCPykSbWXIb6KhPnPLOhsE4BBiObUzimLcAgpE5EsOJBY6DR
p4V0yacuq+gcagtCRYkCLlvqDAF3CKSCq8WQKJtD1cIaRFlg1yxgP+DYly40
MZjum1X8KLfwJrgn5Ji3Z4MaKHKOdFNNycGjDUSC7PvZiLlR+Ml6bdPFa7lg
A2KojDtGtcL41lVcU2tcfJQk5wIzhXgH30kIIqB5lU5YzZIjXBpd3boseeEY
bG+l32RbmkdTa13GoK5h8Y1sY257NsOo/rxwwkREgnx3frgDmJv3w6MEVMt+
+PfDo7M3/QBp3xrk+CWo7AtC/7KneT5TmyLTHiHtpMwY6u7wyJp3gCweIuUc
Y6bmqUl1+fwExYTI5L48IOpoHpLNlfG875oaGTih/xLvb+42kKEExGdx4HDi
KNXGoCp2q2tQzubblQ4/FxWfNeZMnJLG65vIFk5lCTv4XGRcbyPkAc/218Ui
AozKAXYRPtBxhKhyHkd7B89G2f74b7Of5mc3Hz7Eb6J/zj79WPztVfzu5+ur
T2VxtH9a7v44LF+Nj++OZrOOlKyA92ldjsvR4rFVbwCwSTGBlYg4rBE+aCY5
fHsYviW94FTr+gF0X+Ooh2bUCyPviKoii+6YHTx9sd+R7w+Ge7S+ez2cZgQk
inB0Du0xPwGrWaCyGqOqkGdoIXU2yuoBsbvpttmQo6FYuqpqcCIDVRJ/VOXn
8vUhTqn7Ozs+6NN3Q60NQq9beW5C5Z6Qu98mXD+siO/CHDh3VTaxBO4DoOPv
RjdGa4NvtWo2YlEhc4+Bjpc8i2ip6N6Ru3lUSxoPLzSg9/MTV06yl9T99loB
X9vOyzxfJHFGAq3oUKbMh2XtKbP2B0KKWYQ0Whu9OmgsA61u22FK0kiE1hep
l4GPm5Jv7lBBaHP/Gi5IEEtbd08iW1WsEzQ4imrgILITWt1qnu+oqpTmnIN5
nWbXLO1cg4gwBcXe09BviiShaJNQSpyikAEa2BJke8bBFKALSJMsxwmHVJcY
YUMFylJ7uxFGSUKqOlFkGUPyuAk8FGQHzGa2TqdsJYQjbYIBwelbqLYAKrBQ
ZXgFbK/wcEDsmRqjCPiChQIwkdkxzpeaBhCw8G8dnYmb+etYxZGJwn3CnIWY
AvMrCqnP77Kgk3xadcgo+x0xM8ekzJVqTFqJx3vEDAxSjYnsIrYiZQdycoGQ
4YbcH47yYncnaowNNnKj5Uuyq8kHewUxzM7H9XfkHxYThomjzdlrTMUXyF0d
qdymLmkNXLvPpd+gqYE4eCSrl4ppkBXbmVpGp8NOZ1nO/o4lyo9iWaIwB2Nb
Kk0lmCl6nwhIEnjbd+rQ4TtovSptwCky96JMNHkFViQlD/l6ISIOjCeLpJ9r
qty1nTcht4CRg3WGznQ2ENmJHZttB91mAmVEvZyoFHqb4zFLawgSsvnfJmKU
LuGS9jV9hSKxYHSMzAqMjUso4U1jjtDmjdK48Ob+7rfPgvGm0vJ1+ArFeYEE
TsYyEDFBOd2y6KA54EFIKWNlC3DkYTFyuyZuGpKlaR5G88rJc1IOmsk2iicA
V7YLO/mtqqQvc0poC1BiEe0AgSoJNo6phpGNJPINZ+pwgGywZdsULd3JixlF
KQ4oCmmAKuHP10gDfr5elp0RS6xwJ50g13C6LlTlQcNeitgLwnA2hT02hzTV
cX6+ZuyEUQ1Xcgo48I/odRCxCsQwrN6AkhTXI03wzyXaT+JiA5jbMhnFxv98
jZcBtWBnpsPTnbM3UuVOfm4b4I5T7nC14w28f9gemHHqGWbZE+pn55l4COvy
N6oxZ+xN1U+DvNyzWZMfdXETIYUuAHLfETLY+NhQVol8mhL+JBBVF08J3uvF
VIIFPPephFWyh7S5fxCNfr6GdcJtNbVDHSiSFqN8lLPr/Iet/Z7CuMhCn2c3
qeSE4me43xg8h3ad1jMEQYBRsMSaNTB7zdtZd9gGYV2dJ0vfEmQGis3lYLqJ
hIyQR5PDx47EFEFMS4Ih65c0db29XkiZkNN6ICcGHI22xA9wnIEaikVfWI+/
6nl0e9//vPpGaDWw2VE4fP58b/fZ/vBgl75EPm++fC5foosAxj042E1e7O/u
Rsnet+Nofzjdj+Lnw2fR/v6zZwcH+/DL7hCGxjfuJAp1dzyc7E2fRsn+zUH0
7PmLb6N4PJlGyc3ucO/p/gF+05F5xdUyQiRA2gY4CcJdElfWxYNyzCj8xy88
B1ooRo5tnaUstACquLjXUenRGr9GjmnN/Kqmpa3Q4xENuCO2LchmjcowelBJ
bdVRaRmq97iDvDmKd+O9X68/5dcHy933L15fvXz59uXbozd/f/lx9jyaRT+t
kvT7H5YHz/ZlKUjDR+Fnsge23B3v6ujJ7x/0W5+nI8EXmNrvbXvOEHFLwy19
bn2DKK1DiM0ZRuYMo9v9wR5Kw19qYctoYImQ1UvgsndRz+X+OdHLT0I3YeLK
FFj6/MStryQ5mPWMEnnrFYpDrYY9NeWReNt8vV4MNWDH6XC4K+pDs/KpSnls
rBPBwB1DTBOpdTxjQdwPlxrZ7gewB24cAQfDiw7Aw0iQsOjiWNruZd0Qg67J
CrkOBghXLAWvYI58GnY7A1C9JvMYg/c40+tQc3lKqfUbb83jUetweX8+Tz3X
xK1ja/JvJKOHKW7w/clVuBOvUqF3EZms6Th2hoNh8Dovq1Eov9FSBs5lD1qS
e5LND/Px95N0MBhgUOpg0Fyu9xC6S+GhRi6PTOPl8mi6ETlJ8DwZ60xOTz1u
i5U7ynQl266JP3Z9+QLzfmDe3gpfxqoF4TG6kqjsDIe/9inSJEBpccNnqVjw
IOJZe7gkJhUSCaJRPpiV+tDaMB6mClhHAmy6Taec8y0hpCYMZiW2JVOPCsXP
z59dXZTwHjRzNBALjMgbQ6U+/JwdxEazWidsxTgTCgNfDT/mwh3qLQ/qMXIS
KYJODxl4qkq8id9RQws5QGRAGcdL5bUpXGqeqUWiflMGvsuJMnQwJuBHU6KL
bMxeSTyigO+ksYekn5MJJQ7vqwkjoXp0EmRlduOAYFdtBomwbpBAsqomIC3j
SbLVtnJq4t1HC06j0FY/oGrfBA50IuWFqUOZ8SweqK0/ErVDRqyAhHO1yaDO
CuIDoKxY0qXirjHyi7vQyNGBRjAgzC2IyfxjKwPPUHWvGoG5EoIf2LAtfoJc
0xXX0KdII8KP9kgNSU5yjvsCoyzlKjroYnYsLhxyBadtKr8sPKg8Cbi2QdA2
V1rY9IpxH3sTSCwVu2I52svJiR0nGjFXy62TAgWUg0HVI7qajOBHOBFDIolT
Cpnx63JRTWQWWSf9SK+ekgTjbTfWYpZbaK0alcb1Ra3HVFevnmjJ25MYHSoX
ivdgxI136kE7QHDLynqI6EoENmxZEsU0H4ppO4dOUeiwSwesk4kG4N12k5Q4
rYMida+UBqEXhijR+2lG1bDIGmewypoJe5aOumROCo1yvPs6m94LJ8w1vEqW
IPjEi/CdXFzBDydIFu83wc6dSJKNQ03EmlGorFh+62G2YiPS2rw0wGqxVpc5
qZ+zdWHDUTkYtcoXCdVTDbuO2WUUPt0NxZrRG9AAV3wYfaLFRAR5qaPwP8Ub
D4sJ/wwiUrqY0t9cEoHmusa5rs1c/6lRx2ZyiQvh9DG7PBrBlxO/wxhSk2c7
WwOPBj5KlnXQpkMMg8XOLgJpPiXybak+wCX3UYc+8p9lo3W6jIt0sXHDIEP1
0fqVWLtyVoniv+sDJdTs9aXkJQ1iV9COV2zzT6R+M9PwONUkcBxhC47to2GH
GRaJcK9sRTfECCwj77BYh22piZMGX8DVD8nZIvZtRSWY9ZuSKYQsnCuYcW+D
ilbB2s899+DA0guJdNMAqlENFuRB1rwLRt57Y4IAYdoDYizcajuxwY5G3ppQ
ofeWcCAbDeSEAhH1dcNa1FFErzzkdhQi7MUxcsRQUMtHwd+0iCWLlgwj3EQj
TsiUurZKv3pLa6dJEcjbvTKh5mSSW0akFooEpDAO9YKYYH57bkpp+Oy8SBhA
gWdUsdmWGsOAYU7bnADSnrvik5iXxwkqRDaaOWT3plehCvlgXq9qRQyOTWNx
eEONwsSjF3JgcCrVcxESFINtyvIStj5pSJHG8V03ja3KZD3NUX005UhLQywc
icEI7FKJwb4X3Kwzdm+awF6QWLtUrlQlpTYq2sPyDDs74SXIIuFw5MgfHLiE
sb43mrqup4LDDuAqg74Df4CQ0BsJVICmARiKIi+6lCMNEo0vD3R6gTPhnjky
S//I66DMziHB5D5kJ2ZKPBnnpjBgG8wV/kWXOkuqrnm6x4zaUC9E9PVioX2X
/GW7QcNIeIk9j8JO+K/htgGJU/31L7QiYlqtoH7cdAn2sFL+LPfNB9rTUXhE
pNMkHoRdFsaKGI1EVPV5mVa4SKwxjWLTX/A6dnsU2kDRrX9BrL0mEuyf5grj
exRj5HUJamz8s4w/XVMZdeBT12ZOAItMgsUYcJcsM+lXSBHa8OUoLTD8vPAL
YorDiVNm2BmE1u4gMK9TnGoJ4rq5AnZr3KbrmnZnTq80G2zbl+6ZdkeTE3bD
ruSXAbrcuj08cPNI237O4k/pcg0aoUCofj7ublrQ2y535GMb/v6Xv4R2azXE
Qvg230gzXb8+LqyBn9W9xdNp/d589dUCLPavVwPjmsfi4d0WdNtyOvL049HO
gRX/bHGJW7O5dihf71dLVI2wnxs63JGws0nthsrZC1k3KMHVYTGOnzvRIIty
pe9v1CSg0Yysh3/igpjhu+6PalL4UUyc0veWwpZ1liynlkcocLMlRCsxtU7l
2CRg0leIuJsVhUvYLiNEb8o5paohkyr76m4LkhvsG8phh9aDDaDI0niBRUa1
tiKaN5JPFYpEFOUJpC0vMF8nkRHrmrUwdBGqsdVF7YYF9RvmqyPDXfiHgSFa
Gal19CQsnOBj7RP1E1QLiKPSGgkjMELqVi/3BAdvDMr4VwYcG9O0TrAko8kz
8PgUC4FmlaUlZLxwirkg++Q6MD+6oSWfn3jWPTZ4uA+cq2hRLzIlym5pDR6V
Z+MIPRtH4AW0kIWjXkIIOJ7U9dpuDYUdI2rEYn1yasL0hSZtpFY0bNfWtcAz
ArUMdUC0cbpWfLY2/FirEU+lYdSyayt6YMR8rZaIqOGNAai4V9sASAa5egp3
fuBUZirlGZbNYiqigpnxEym11hjaUb3i8GOW32XSTIAB41cTkfKoTtxCrS7u
AUUOwFKSW7d6m1+0hE1GtBxrA9MTZJHaHEEN7nCujOkHgz0R3+sg1PJp26ZE
8Zo04CRR4fsWEHy6dVdbtCeVZ1nFhNm+KWkog6uwAbdTmjsmPPpRugg5HTVM
Gwzx1E8S7pqMeqAzMpqu+uG7o8tzRl646xIHz1OM19hFJFyvUGxHU0nwvIYJ
7UhGZUGUo9SKA4kW1awg96I2tFNzzx3PLcEhViF4ny1utQq8Fle9+mLf1vdg
q2F4FRE04f8bzu43HfmIp9saEpyiQYNwgD0Z/vqS1V6ulesYvGKxxg7eKBsQ
l5SwJVl+34lHxBRZ46Ni95vUZNA0KmM54nxpP348ThfrImEt/oOqt6aqQaoG
ateEba2LDARv74y8tgMBwQDgO9wdePClkEPJQDBBssqp9A5RICJpp8Oh/zpZ
Af3c8MwknwMx4clZVS/ZSND1GbQJBiTPaDnPF0Cf3TAsZdcCW5sh3xMKee+0
N2vyd9DEHlvPsIkJd4TLHJNjGOOF0UYYNWQwgk+6xOi5XG2HNdMh3sXhngEU
O6TEzSERSF2yafUdg1Bf0rkpR4NossT7Uk25ZLGI2KeBYwNLwfBXyh4hG9SW
9MW+192EMtPbRqdfm4NIXqIfyeHm6PW3G8BwlcCYzoXZ1w0SRO3r7aLwnQPa
GbegxEIeFCTbtHK7VWTNxRBTokSwimWvIViwM3K74VzjFwO5kuaBRT6baSoh
3cPVuljlHBN4QoqDlvZx4xk56cOEnRtkrzsvTYc7G4bb5wRJFoSdgGlqRLHI
S6IXLHY1qkGyxxUEMyThXp1PW/7B9cHasiQmvJJdIkSraYD93adhF+T6cToF
GtNDzQnfR0EhlfhiSnA0ARMowtHXLG/JIMOg+z6zSaA6jimJ2iw1xpuRFBNe
F5DPcT7d1BPg4hC2gJFqoskJRcPunpyDE9gcHDbRmfNoxxMSza9c7y93YK5l
KIqdU0Bsql6wnbJ+NsGNpNs1ZGlrlttupqP7fA2YivaX61+xfYUSKNCrt+jA
JDBI4NA1xrqqzqx2PBauWSzrisRspWVzLD1Qx1f4KE6sC1Ark1A7fptNH/z3
AKTl8F/+0pCNPesHX79u55RRBpVHK7Ow4cYOCGIL2jJETsaDLq+NcNy1D/Va
pwCdZZ6OycBl5B9jK3sjJfGsUBKoeIyQAwA0gEmmDZn0I9s20LJh3/EMh7XF
vM9IGK+V++vUgGpOgMdGhieYAAdwbX5tHN09JpHQE8D7znrboaYHY16pr5Fi
0ykimuRsXikcDHx/Ld85UOo34dg+76Uj5xuTuYxXX4IVZ2GpM8piDCgvGo4N
LUfw1zWQUZyteWAObgGywqMDqsnZsiSbibYEMZ6q7En376v6iiTuWGVkJJZS
RU+whA9qAM/prFSJr+0AeCgjRfLEzogNaIj8KWZISyWkC5qZnIrjtcyIlIsf
lcZvpvKCqYNXn9ORFv0NwpfooWUBigIeu+3nrXKnjNIAaIxhxCAnkrOhyxku
eUhSo2zLin29GpDZS+ytIYzYHj1Lro38uXVdXJCKJiTvUDzLOy1z/LU+x32W
/e3TeFupw6EmUIopWAX58B/b5MtfjFmYn/VRoWYT1kWdpVwvyp+UvRv0p1mc
eJFqqejdfMV52VwCQYvSrWIcTAAoZSjMUtoE29o6zVv+JlrefNQu4RVtR2Ve
lbWi5GxT8DqO+ZpP3XuFJ1PS+w/XKerKzu2C8y9bFqfk15uJFMtOA/gobXc1
9MnGn0jIiZOL5nl2PA+g4f0P2tZb3YOt/pxWfK9pBix0mS0d+ooAJmKw6E/1
0GhpgZH5+Rddes+a59n57dnnPXHPqc68RSDjGGe3FRnl5XBr2M9PGs1gnQ6o
pr0vlyR1w4NA8bTdy7y6kVgQ1WlK6q2WUbSsonk+gQ/xYlOmpYnwcwOnAw2c
doLs8hVam6RYshOf5PXBXmItuCoJYisfo6EciCS3c81BF9q0GcwOf6JUKadB
G6pNIG5iZicmn5ctDcEpySqlDISwhNMGNaofuFUVeIklqZsUWSprqTWUNTGN
rNY0tixx015/X28DYqDmYcTsfOhsxZRZGIXv2Oesio6eqjVzc9wUYfwyn7Jt
ktySVBZP7Mp+UJasSWr3SrWOGPCmciOFuO0nDZxgcHLCEZ8xtrLOqzyTGE5Q
idAgwlm36JuH9bKPR6vQg6ALcu6YShmDCtpcgybHG9cM3ic0+Uq0iDQg1VWg
5ZVC+YgqiWH6tLVcgjeX6HAtjeXZ6pp7RowsNxNSEi2Jg9xaWy2LTsFRylun
KCTstBueJcVHjAsvEjaYNlcxTgzo2ZiMJTekk1yjBGZgo1q5bg1FwGK7Ry//
GbNL15zuBkTkPShaR3QTPj+BuxJRWqE2nynF7G3DOdx0zFsqiB7SG/DIksO0
KIhnnt/V+uXWu2chwTFJJG6dD5PTGEjcvDs26+VyIpPyO+lnKYs0tWjCO8x2
C4webpva1TJ+/VIA9U7FQXunYk3PrldkM21CFWxccmeMrFQrhQWcbq81n04z
Zwd9MjQ5SMsU25AOotgBVuNTx5BbXfALq/BnyZS8nMcJuScvj98cUeIE4kUQ
nGaE0PzIlB8p85vqjlnDbbLIV0T4rH+gi0P0+sHhqenCVmKsksa320yFOSEC
OWxcsAbKFELt11MA1cF6GyyJxAs/79OW1A5s06HPn18dH0Z7w6NXF8Oh45AZ
DgfD3W7CttfPn0/eR2fHF/C7LCBwSwqZ9q0mHlDDwd2dqwUFD8uARiuM+qBD
Eo5cXFtydLE/F2yFyzuRPoGBDYQo0e7uEEkAxvqE//gl4GpLVEFRIueuXaBd
I8oFlMg4IvQTgcymuZG041WDC1Wyk+604cuwe4TRWN+jFQqB21jSnl2SLtJf
muFI18A21otElwRSCMqKWqa1vL59KgLY/Us6CrtXaPajT43lPG0sZ89fjnQ6
u8Yc1+tynVZmQfTNBAuOoO5kyuw9uKDjsPtynS6mW1a031jRU39FY3z5WjD6
OkbXWUzaNK2Kf7UCpZ7b9lW9pljKC7khZ9Tuvqiv6qCxqn1/VTKerkuXY5Yp
F0/gtH05/IMpwhWaPEm4CHAHNINqh3SGHRk+Ws6KaH+PFgRr+bwto/p6vIEN
DAaDX75gkrfJfl8mVYwCWs8TkSW7MCqni4mKyPcRu45KvZI34qZ3CJPghA66
rSZgwhfBAiq5rD3VqZMqvaUd97yMDvMqaqT5NOHXKHuC8CBU7KB0ZNVvpn3r
9LAV4vj4l3z8WPCZIpo55pSORiy89JwYhf2YbAAmdSHJ8oAoM01afkxXKxb9
ioRkOAnyfBICfRWNgqQWHOzCps8gLIJjtt/HYb0xMW6BBtDSdmp7BlUL2b/4
Iqv5VlIburK9Ul1ve0zKOcOH82I2KgAmpS0thw13vQpAKhQFbuFjygnpOc3c
XCkcj8PJHGIB3vAKAIwkHBqy3t1GwFHpw66Ht4Ght906RW088xTvQp3MNZ7a
D7vtpKfx5AEo3z456IX/IDyzBQKmv/j5ttM4Es7JF83BBMAexA08M4MyGi9W
NB4zSpCvYhmsQLSnwhNUq9YiqrlgLPM6ERXcp6KyDV9ZLMHCAef1WoV6W23d
u0qTS2gmysRNKyn9gDuwcqpRU7h2gBHCuyDyk0MGvx9v2A5AdQu0ohLIl7C8
aJFjk173ut5Q/1c5hD7fM0eMZ9swGRKdKg60Midjw+tCo5U3VFJ06otSYgou
VKsTTuLMTSAFadJR6XEtdA4PCVojinVaYwuRGYsVydQr3BiESmqF7FJtOSSG
5KUmH3mtViNqxEhNBjS/keEOsyz5FJ6egnqGWj4LXiLCxRqPOEm0Ce6NyQO7
X6I1sxyeRodHVzgRXB0UdYd7I8DnKke/5oQcrFRxL17xFGKmgAnm6WwekT4F
UjFXmCTvYr64tYbSFkp3z9T7I6Zfk1hVJP+SmJqlOaXQz+aEyYji+YTMu1N1
rzqMwc6LqsErKpqChXSvipiDaXzF4MY8UMkDSjxNV0ANl6PNx9TkGjfY32Ye
EuaG9bos2rbxq8DUIsXNOqOJva12kYVb08CBHbgmj1/QEZlVPl4it0XEcaPX
wH/Jv23kKPySq/i4AvkjpHHd1tdL4uJgs5Cxorh+c02wYqn3YTnc5F//D8Rw
Ar+sw5yCAcnTe9bhsRuu5qPMZjuemq64j6VlZ6evTo+j09MvX+R6qT3CZ0eK
e1o7VneCtETZAONlnBk7FDEP8axr4yTL//mqH7+7OKwRGL7l3tpPsTfEhAvo
KNm5n0q9EdoEC1bYcoEb5JfwxrRIbynOUIiTrW/TWtbQ5Ou7t1jr7lFyW1qS
boW0nvqAGBD1uetGi7lME7CLqVtk26tpp904qJ5yLfUbixOYBDyvefpDFXbG
cfbRaCZcAoc5DM7VXmTnEa/U6+x4r/iNgGqVdoYHuweNSjvDg+HwayvtfCt1
c6TQzvQpVtiJn0Xj55MX0be7w71omtzsRqbKDnzTLLSTUjF1vbzXmtXnFdt5
TNWfp51ftJQOVXNxc+hslfv/SS0eD8KsYVr8jHI0Ayuw2zP4RpQu0fYAlWYc
PaLGZK0QjYe9TjEat0qjW4jmyi98QDhtqz7U7kEd2QNaQp/7AkmyPhEazlym
ZFbSYKw8KBa2wF5evbkbvo4mcZMpAko7Wb7ECqJAUrAu1qQEMkGFqVkBZslg
YX60EoEx/DWZtSlpIWwaEwxJDrKulVad1ZMBQKWzbhNXCjDdfEZ1dp8jQT1f
xBmGaDye268W6PDElw2Dxw+eFemR5jYqpVj+Du6u3k4uxlga5s4fa2a/h5n7
JdW5eQRn3yJlxMUsl6YqxgpJnxpAedC8ds4NWx5hWtvrh+1GNsM/tPuLrkk+
+hLH9jVdcjF4lMMEDRuretC0xih8rSjtSGEy5GOMjy5NsXdLCIq9iSr3sKp4
HhdwJ5IFldkokbygH0JsU5Rig4iGfB0PmoIEWLfkbGXp20AXAR8CWUYk50Qy
9Wh0LeOBB+Q0lcPh+jUvD2pbcIG/wdIarIMRjdFYXh2x1ldAGw9yNwHK+4Gf
yZ5DadCaolzWnFDxdFpIMUN9fuI976Qi48q0Oi9ujnI5nh4c7Kmb5GqORDU8
w6Jk9Tzmin+LJ1RGhipnyjxEcqLwLEZrHBJNaTie8s/yJujIpiBWPbsD0EUS
s7mkh9cjQFvwUf6eUz8eZUHkMkDr01INHmwxxdr7aC0ADk5tzO3EVIOUKhUT
WfPi1fKx71GsD4QTSlyB+DILGlpzDypMba6koR/5kzfWm2wDIdQzyiJjNU82
jpNUjRVq30BjZ7pis+I9k+lDiVNEIiC3bLzAWWCxUmupWSWIj/4SK2keUiVN
/PENqnGaXuZU2cRcgIX5zQ2h8EpxakEMmU3jlrUDFrdW5JioO+7/yJ3b2ebr
tp+VuAy2ClWlnh0looThIWnYigEY3V1DwgkV+GQUkk5rOBLjkqxAMnzKpKKV
1qKSsPe07UBiWoAAa0bsDLQBgnZ8JiqHbmuaTMoee006XU85XRzK/cSleMej
M1hLRlwal/NUXmt2yKCWidwjerGxRZbkeaovvyPF4dHvnpS10jpk96WpufmB
lijTERisToMHW8eJjMtVbEOrmYTQDQcBCa88WvEkIsE0gTDEtGo+HIjuqXlk
BouwinmVzvBUuYRZpAuzB9sP2l3pbr11yo+5xxXTCbz6w2FXygVTtg6WmOxR
7W5xqbtmS7fUrZSyRbqJLUXTStylEiHGVlnY1uv8Dg2x/YDugKlu2Hq1TAxi
MZJcVwxqD2xxW8G9SR65zec1c6JIOCnHVy8DY10TEh27FeJMWp+dxNwDt1qv
1uo95JaRTjdVuo24UmcIcgdNJeAV4QUXeIVFbNkD80GMv4fW+MsMCgiTDBI5
huGIKmp+4drhzBsZgzwaFloapmEi92KBrULtlg/W/qBcPrjCEvEBdbFtLyTc
2nyYl267wDqAFCC2mb+ls3kkMUBJJcl+MoO8UUu7c/oSuy/aajdI6uTVa2ey
TtglV5REiaD9RJ1SqIgAmqLIaAbVy0BKm7sZLRLkFfqSXD8MEAQtUMmou9U2
Y4e/g/sINt1Oqd/jgCaQilfFsnQWqjqg2H100Y/DDMJrScgqKG3NXsa+LcAn
SOOGS/m5nLrC2nH72UdODCL7NKSGmrxMrNHEvWuBLObIulwmL1oIXsosuhRM
8U76Y7rT2kCsm0VMGVdiZleTH3r+1MXC1cQB3LBn7rTTQGfJZ/YJHVHxgIr3
NMsfOmW+JXjQOE54jSMO/pLJfA6Ml7LkC0s3BImbSQ6W74Da94Nas23VxLV9
rI+UXjfbbafI0ta7YgYiGyfEw9vnIEriVcL6F6WIDmxpcwjxuMgpSZgTi008
kMhUptCZsTpOJWyQxTNSdrCXPOwSGLetzmTT+3N/UWSNzRf8OmomixjD4eHm
/TswQnbCk/lihpYUslWPqMcrvURNbkDcZtsym2KJCbDUzS67OShxpqo/PFhJ
NTAjZ9tGTu4kTkRgWjZCAVnEbg8GDGvBgI5/1Mn9Nlsb6Y+1eDZpEbIC6hKE
wgP7NnbB7Y5JU7DW73Twcncj7fTYM4dPiDvX7gsDtSlELc4y7WJL6iTVxWSU
NZAScd4k6bnB0oJamizpytaVynbfeDK2XAtMOmvWTbaZgDanRwJjK+kSbn4I
hGdYT6DOhrnrje7ITh0CDKR1ZnJCSzCtxqlp4PYq5FSIONsEoixun6GlVIFX
luCBkgRht6TqgskqfNZWa7fHaa73ZU1S3P9N6yrcFdyTDptQhU8MhBHy4+bF
BiYvFpfSVj4BJWGnwBkV71ik4yJmRRXGNJUATaCGaQ/XujHGwgvuon1ICjRS
uVvW6wUPVVIo5xTB7PdmL2up4AeRm1QOF892WpfeOk7fblbZtbCOW59A2ypg
TRh6FPjLOjPJUyZnqhyZyHE3sUpsmsBXtHmpnAB6mNjMqJM6WfdUhpfihBUF
Yf1SSZklQzLtoutW06QQVJpFuEnc7P6mgdjWCbYhvbI7IapsZ6P9BG6vQq8m
sdiXuaQbmSRiGzxBZTu5rrFXHVat9OgDdMQBbmCUkx3HrGYb+jlx9FxKJ78h
UCGvjqj5ObdmlvDfKpcqOzKsitetHdK1P3rgNJJFWXZNFXWrxI0sbqtLicHD
NnrlLJ1iOY9zA1Vfz6f1TBJbyz7C5RXGNDeQZuPaFI6eAyw2XeGu3lyS8Ij/
Bf6b8SSl1siggFsDfqr/HkjJpajKTfUlPPR8koOG9Pk0OibRNeK03nKvjPTX
L1/6gVmotR6mtvm8W/Mw5NTwM86et/yllEL++3sYF2McnhkbnjIOiEffZwYy
4DhlEdd4QwWdp4CSGSwPoMwl4VhkVLxmK8mbyx2CS9cumqDbGyllAaKdoPHg
Y0R9icRKJ25jYBY7H86vwi6XzTfRNnaMnELmuBy/KSiSTYPQpOWrxd2EICFG
dV2bjdu92Ax9IWJjrZv7lOr6IHWltlj8M4sOjHgoZ1kLp1RLaOXSKXuXxBBG
gYdqtaSbCaRrlgQOqeGSI3CTRIKtTOUw/LXFyoIWiQAjPOgwthTCog52c8J7
MjYaQa/ATlvc1guTIAuuyA78qjvP11yVfBpjxjslNoEMOS9JoTy3e3SKfnLx
XBIkXsfFlIKajLX8jOIHgXu8vjyj3DnUkIyaynjOQJMMJTK1Ogy91nUSdA5p
QGbL/uAr71fURxvFmko8+Az+flNEkMr5yMUlGMs1W+LYXCSlRIUMkPjOVHbC
+CNMeKWHMBVTLYuu7BY3huOW7F5pdq9qhcpKTiWjIqGlcgKj00fP6DxrLTsR
OHTeVwuxbKy7MFt8f7ExpZ1gfZ2gpUCHBGNIGg5B5BVZ847YTBscqi2qYeQF
6kLVPAHJvZodtp4WrJkL+tRSGU3za58T5m2lPhwDnevmXUgyhsSCsY3LsL4F
SKBsfY7FOGnJBUN5I7LfRjUuB6IAlDO+gXTNRGDiK+goNwJ+4qNJU0lqS5sK
wocSp9p0pQ9N3X0UvjdltR5pKRHHi5pQt1hQw1YLKnl9MMUm8nPVzvRA0iZc
kC3Dg6UIKXL94kJkuoktM4yjv1tXWMpwzCG1gKIjarLIriC14nDXF9cWsbEe
HupCQjqdKCsgjjCVMCBdIQSLTLD+mAooUv80ZuF0ybfpDELs11VsfGRwop8w
cAKobsBxzZ9SUMJQIxguOS8KB8Q0AuCsBZZRFbqJADi53Dt4hmUT4XIEzuV4
sCBl2CxIGWwtSNkoL8792rQApVScRNepVDjHlGRTcLIpOgpWY7npTUimEtII
6Coymz08P2UejOK21uixTRYJxGi7LUsRsmrEwdaAdJpVkNduy8mYYo53Mdt0
gbIAf0P6g/0JM6GNlOZtnTQm9fhjoghhQpvDQ/T+xJONSdsQn7WNfe6SptHn
MKoew7ReY3kQHNmS/n69fLoUVNudryEvy1Zn/nU9nWkG4n1sf5NN5kWeUTgb
ri7UnYt77e3Vec9t28z1ReOHGw8E9zQeCJgU1CxXXs4jIaxstVzFThMhdj0r
06/HnXuboKRp4RWYj5LO5okUEwv81SIWOdOLVdEVBmy5ceWnGr4tphyFCJlA
WxoxWMOtvM9JLZTtYf0n9XmRGmFTq1wiGpeEr7pqcdXV8YYjjJBS1xu4IKLg
s1KJLmhdaa34GmjvpgSbtm5l3lxr9IUdyLAGKzYpPjJ9DtQySie1rHVHICPK
AmsPN5raEooHkmudeK3IsNzzdry2FgbuScL9SMggbevdhdgDXHz6qKeZOrqM
LqTuoC+g2V3B1MWqKNmV29YXHIuGKAvHxYxfuuiIXeHhJq8hNXklE2/gdI4F
BkjtXp1L6LwY19rA5jeB9ndlExcILzll19Z6DJOF6wmL6pNmtAqyN3Qkn0i0
uNpP5TAzaifELTW47hdJN4euGoZGqC45uPpsy2EqV9O2VJDEt90E7RWfadc6
unpOfThKzzDBc2SyNyZhx62eryt4htaBoZ39mtOpJykQW+L9/WSVxxDsLbUp
bLE6hhI76rlrPBbFtl3fNVe6KzaJaUtNhyDUGAAsTmCbNxKG2DaMPZI2RQJy
JA+0whjzpYu6VBqYtLcclNQE+9BaQ7B5fLFIePnqv8E3QMJTkUZM7tLXxxbW
656fnvYsXp05ncipl1e9O/lWycHrg+7OoD3fFFUHgVw8dZSyVe/Rbds7YpLW
OL1aj3aSJLCudZzN1mhccfFW5qYKOt60ti34qumjcIYPbGd3rffD4qnQ/Pb+
7DxV9/Nn91d744Opeh+Y4VBtfxRpM5bGVdviCq6cAMY5/gviXAH2V9dgFo78
xQ4BS8ycRtKIAqWxYWP9bF65CeDtB+hlTJHsUxaK37feBKmTLFBJYcJ6Z/K6
zaLvniLDgRJWnWN8KC7aP1dQ3BOqBxo0ThhTV2OOJfaWlhRO62xqP9d+PHK5
qbS4MbK6KAwC3UeYKLAN2UAkkSgDW1tBfEVSqQVv/SH1W1A3ntoajLnFDV1w
DTIxvRaJAgu/g+DEgR3cEsZmOhgNivNJJWNWM7xi8l4sB9uurIYcAsMlSkaG
goqM+gQMUcG09owUI/axw0nTRWIBMHi1XigRxVW5VLTr++YlFkGoppCHXtCw
TGlvyMXG6j+ijLLFxhrqGXSBeluxkCOVrVE44U3JEib/omhywRQW1EkdH6+r
gPMOdTxdqcsKtH8DNaZQB42BxaF02mjynRul76BCCeUfb0Lb756zs3XBgX+w
avJWy7DeMcey5PYuDIzkKUW+fD7s9G1v1LxjT2Dg1V19Ep4evj1sk0kwST4O
rzarBIGQcvQuh6yltiaGzdgunIfUQGKDY4nzoSqbBBrcYicoO/r2puasxsUB
I6dVZPEyGQUj7fXHi7lcjyv3R784ZxBcmAJKWoWzxMew5GYQvJN6bq0/nmRc
rKIWLYwPvBin1XdO3aQ4/OGDBH/Jp0unlLoU+QdZwivzL80b+Q2TLgaAazTV
FfSkrLJmX12vo+5le4gzLvoyYT6yJWraxEtr8Ro9YTQsIG4TzxBJsjk6w+x8
rQ5Sr/QNPuBhTRAc2kMUizsHG2K4gkEVfK/5oHWw2uhFUozSidOkwygXEoW/
FoONtL8FkOkdcrOQsbiWpTwOv8ClnMUzmIItOt2yJ5sOw1fpwtGp3F/OcJYq
B2J0g88QpuKR2mcCFug4P3uJkraJycuZOk+YcN+sC2KctTUdzQsM+gdcfJtk
GVb2AsRCA+P/yvTzACvxniohWKN3it58d3b27i3eEPb3EoDRCKMP8PoOiTNt
mSoIjoCPCx8hvkZPnp5cvSIa4rbTpsbYHinBvtr0W+TSji+/k8J4vbOVxrze
oOCMJ07dvEEgJNck+f66uLqerOstemplcZtO0EqF+EmlNI0+xHD7qIsC/giz
AnwI0y/9JuCyq8aV6IPm6HYZ5y4lSFfYul+HHEuafwjkJNA4zajSRodU4A/J
WDqp8PQPUejf+DmGo344tmI6fseocmRQBb67MDL6b8FvoyiKRvRv588R/ABU
fQoPm7SWU1uS4zdCNvhPraoVjmeyb+BnVnh3KEWFuMm9LwKVhV+kOxl3p3V0
h/tfBcz6TfVjbKW7ZbXMuRvv2qqYv9XbPAKwqBDlIwbRvEg7yIl+o33KHxpG
dV18jgQ/0iVfyzf6JimTJrLKH0HVY3jwHQuMXz1Ea34mopKbBflqEc/cAVsV
srbhSIGpDXah3z5iOCQrv5Hrg41p79jk5KFH3RQEL2ICF+Viypeav7XlrlPG
ltj76hjxI8utSreALMBRRopCShw2DcJg4xak4cn2wTuBufjshG+jEV1Ye68T
zop8veKqbFZeVOUbVBSPElrJjGrS/cvFq6MXw71nlGnFmRgpKW3GVyR0yywn
pk6Qv/E6Adx/GLUxxVd+a7FzUcM91A8eukAm8KltFC4Q++BVbimti7TsLmYv
DusV6n+4fzSLdS6KuEVjt5w/IA8AJuR8f1SIWOJCYgyDsjSUTP/SId+t4CpH
kHzQsHqlOe3PX2mkDpzoZJ5i3BAaNRqhOfgrbIWaXtmQnuBrY3qMooVGeRPG
Qo0u+WzWK+p5gLK5UfWwZhIGfGiMDMgSd6BGdzB+NxVvHMmg/ya2QSpCm1ae
x1pTmD4mG3gMZlgkXqmxDsW3YKKHHQ/urA7pRL+g+ywwVU3gAbiHs0QMKwnV
tFna+kdAVbGPdeSbgwMTIC1xgXVZ2qsB8Q7lwHBvsCs3/uTThC+YxlN2yO5H
9Kv9mCkK6sWzb5/CEWhFX3xx68jmQNEcxreeAgPNZN1DTLXs2XLh+JNDRZVS
iIXQMUxqxmTGfS6ImqkrxOsqHAeYnDgTby+mzo9CPXSM68NaGugxn8eLGyRQ
8NNy0MFgNDxccgCLz6Bco4s0nVDEA9pjkiVFPMY8rOnlRLL4YhNgkWuQQrqU
u8BrF5eGbe2MkUBlRQkVshN6sId5XbKJ0g/JCp3tuJY4CgaxxTkCTvQtKLo1
yxslS/uKh6aKCFY1DrzkORuZTkYkDTSlQ6AaBBKUYpYajNEnNkdgdW/iLIJx
eiFHH9wmxYzoNv2QZj2bpIXWu8DGt2CSxPHh9wMTQOsmymo+G1ZlTrNJpcXj
UWZ1jNdaEYoDN3do86S6Ge81xrQwkbRNwCx6SeG56o40OCzaLRkGoMHlM1zL
SB5XAw+hlGMDRDTqd1qIAyYvTuG8+4ju9A2Zg/rar9lQiED9MYMO+8udqjN0
z8r2W8q3sfm0S1VzXGnk1LGJ2DMPOgt6KmIKh/PRTvVuKf5qEq4m3CMJ0Zlv
6dWnLGI60AF57/rOGPWBeK2Xa27vzu7ZOLLmEEzuwVRIHVhMBbaVjTh52IlM
q3XsL+KeLZNSejF7IZikicM6I0ZbPg9OCzbRTnaxdUxUSz+HJNEd56s9atkG
3n5OcJrjtbMXgnxnS7gFHDNhiylTVSzJxjJQhUtSovhNmc/izKcM8jv0FCfx
UhkoAIHoi2lzaYKWzYaMLz3g1oF2TdwZCa7BmIuj8ebQ782uwhGn1LQfCUVO
myOhTGw8dGMLbmCgBv64zeBkjd8FYX0WgP9dLGXkeOR1xmxlamyjbib5aVUn
dxIhO4N1oO8G6BjGXjZjdDAxD7/f6hDlnG0s+O1bociyZpQHqWYprNfUxw66
fO+2XTn0nnBiLzqd0HYkOURufG44sRECYbcjk1xPqk+dHkUtuouz9mVYjxdF
rzSVmqw2CURsSqyQV6LYIIKb62wpQ50jKWnodqQnC+NHWjoEkaIhqbZ2+Hef
4QKkivAnYHksT6lRVghrsDXyGGYjUwBRVBO81Jdsa+brHFUQnnPdi/M9obJy
1P/h1odEM6JmVPYosTfQBrK8HUmzBxzbSAc7h9Sxs90BCvFf2QolMNbKoCP1
YYaKwminquZCJqVXwpSLV9wvB6NDCfXzCIPOQdLBoTiXMI+0FodZ43eU6LxM
0Y3ZCFKn42F+62c1cNMXaxuVYD6nKcKVGGK77wDuV9SOEiS23hbm5D4D+3t3
fvL26uTNydnJ1cVPqhrIIt3OC2LtDbTkomoAktPqFIKcJuM1l0ijBLM8Q48N
Q5tCMjgoB6FbIuFHGzHGJVTYlfgu3pQjqzI0MjID8RYBtkWEfPellX1nBgo4
SD/ixHOMtuFq6OhkMFF2pTyv7aH9YKSA8uy+oz21e6/qlXk9/7jrLfZA4p8H
edKQm3K84mJjrcLTQHLygeJXxBu1dqeWlKHY22aHCdPxznSNVncZvlc/46SV
CvEvQfuhM9XwHXAMlkbrgUEgWY0bJ7TABwFN1aztLzFJnGknEbVFkSycRLCX
GPPFAgbuzL0inOm5RV57ibTEAGRsR6njum3RotvhXiuB56mpCcyqpxEj19y6
SmnWMiZ3cEC6apZj7SH1qjZ6m+ixyVEbh/nvb7ICnNfZruS1NLur8P5tgVM2
OgVOCxmPZDZ64Ejhn8uj06ursHu5pmDaI5rTdAXpMz8k2WCy6QuHXJfVFjqG
hJsH3GbxKCdpVUXur47WHNdUd1PorTKrqKxni8685HUTrJySqUxJ3MWrmAWA
vOR7gE4Nrk1JGwsoS3RVle5F1M0kGqpDl9+/hZKoSlUIw26LLV8VeSqWibEz
nCPnXBW3Fre5gnRwvICWFWvNhNhW4qYkdCe0jXieCyAHjpijTNAaBK+ID1OJ
vj5nG1uTyRKERCyizSn+ttYdCdcskFH+KweWmHbyGHsm7DysqXfjDSuBbHQN
HM3OiDqUXk9MaGHD5ms9xAnYmJck5hNNPGyHF4e+tqHDgA3ImqZpYi9syIXJ
+EfhAG4cxq1ZoZIC3sIuRtHhvn32ZLT5EClBlUdYe8zDWGtLoCF49YqIPcfX
zhuORZGZYwZD4CCQFA9z40SN8YiQuVtz6fQCKhlLYhvNalvAaLsBtAjPcco2
uAUuLwAEkjW7Qa5kbcDCzCab32ELH54eSX46XeMj2A+LVlvYwfbnnQJr4naI
x6giStdFE8OlikNf41fE997T+27HaTbnyW8Crc3aJZSdE3mnjlK+vaKR0Ncb
qNWMMGlNjVyvdlDKiTlCwomdEO7Tl3hw09GKCJRtLkRijth6ONbFb5T1vZR6
22rHptBJQGT/vfbHDzlckj0WuD7Skf0JMbIIL4105TrivCfYp/C69h7bTlxv
n7OmpYU1hsf2w3t6cNsIITMYBefy67UAXSp40V4vyyhIA2r4hXTDqRV2f2UE
ynTVGgfUSAxrH+iFxTS+LqXXEBItlxSl0BtQcy9pEull+ticIb+4AYhn2Klr
S6vurnBFsu7gves3I4oZKlzhwoibsJID0z9Nu49ur1bkxwte6I4krKoVbyKv
ORuIQCOALzWwqlinBB7ynYpvLLSONyK9o+niWMQlPgunVdgIgUE5WNtlKCkM
H46lsytGmkmkPg7d6F6HQTAc1+8tyNZW0TDvtqwTAhSO+3ozLtLpKHydV0ZO
I46qol8fLaxTlo5u6TcjvmIUlKalIqzlwCmivBbFtgXcjG3tCUpSa3NLblgQ
1rPDCEoeqo0eSAOzeV8mIQwNSBRFazWncomkgKwenPVlI5so7Zc8Fh5JHCEl
j0D3XaSc/aPrpuxdar63okgbtkfgqWOkSX3DB9Fwd4mSHjWbFID7/iEbY8Wb
dOMsU6IAeNnJjo2zYOGqWHIH8cDqwWTtx1QPb43JjCBJgliRolGQg3mFKcoR
dH94d3kiyQOksbCYLLFWXikOoMRcqsMP/k9b1gAXIs9mqBphgeQ14uG0JT8G
9XZ3uRjDLT3VhXqZJCt0WNlSIphYS8lKJPO4cBqw99Xo6bYpANzJ1QrtG1uV
DadIqagDy2WMlrWSKgwZzcyrL+/2ZiDacguvYE5x0dZ0zagDmGcVVKbzBnWb
wZlJWfsOEGueJrccV2mG1yTjwAn7rRGPZRJzYyLTba+lwd5vCiCOAbiwhfUx
UAPu8JFukB4IrPuf/wUDYHOavWF49OoC43+qcDhEj7vbDs7K7G6DEjVo9E11
+q72PulhOIJHgV1uxqZDywA4CNqv9O+qK14vKlzxyfvw7PgC5nhUu5Outkfp
MUgadg8n6PjwNOKmfVi+TMMCNFTVTH54itFV2GdgEA73CFoP9ULxO6H81mhu
4POreo+D1on3YRhugmY7nZhpN2aOe9uk3NMkBac8S1+dHgPkENSO/VsBRtQa
vby3acmGNO43hXuugbrW1ajZPEjHxGmxGYQD3bauDyy2mYmaSFQ2+kW4KOVG
hziX2zRxuofmcEthKV2/heU+MQ+EQxVuwqu7POIcNtNNpl2slirtUnK6FCkh
NE1c2TnNUSHZtHTMVFpffcTJ4sgPJBi13goCBFQs60+SAXcGAFaM3/jh5PzT
R26jQBJvFEcge0Z7u3vPot09LftP051rl+77u06ISWEA1FA6SFBAnNlee+OJ
x71V7z3RfEvklrzRfGL32f6w0XwCvnz+tc0ndode84nxcLKHDSgi6kCBzSai
8WSaRDe7tv1Es/nETQLi6TXm7GIqEW7V6zvhd5RYpEQE6bFrTvb4us4SJs0P
YTePI0CKUbY//tvsp/nZzYcP8Zvon7NPPxZ/exW/u776VBZH+6fl7o/D8tX4
+O5oNuNBTHKgM8ibo3g33vv1+lN+fbDcff/i9dXLl29fvj168/eXH2fPo1n0
0ypJv/9hefBs36CS9gjwXLSAX31VRjDMqO9eD8fuj1eDzZEa8YIVoqWg49dj
Zg1bHkbK2gv34eO9rVAQG5+1YeOzr8XGvT8AG03TBW5t8NUtUIZ+CxRpkOB0
+zRdGx7AVsWRK7JsY3Aw8oJap8HBYBDtUrvB5i2qNf2TR/fCbm2L3FLTJeR7
o9aWwSQnahfSQ2kXutVegguOyDC6rbewrTl55/Y0CGLbgES7C2fTWhdM7VaK
+UPIIoZeo13TuPX+S1BrWMpojWJnpD0r2+/CY9+rX4nW9zBlBNvm/U4iHQ/H
e5OngIiIBvivXfsv+ccn0nwpbg6i+Nn4eYQNgSK4FTeRcyuGzWuxrZvldlLd
2qD4/3cUmpBrz++ZjMLc/wDB/AN/FG75rzwKrVAjjYo1lkxtway93RbMerH7
tZi19wdgVr33qU9xH4XetaZTjS7Uj6W0eNZPQYmy9MfrS/07zrpxCo867sZb
jzpxUsbbzrqNub549rVn/fQPOOtmD9uvPu09/7S3tPj+mhPfr3f7/h3n7MD+
USfsPP/A2bZ10W455KfDlkP+dvi1h7z/Bxxyewvirz7oWi+5lq7pj2EmbXzg
YjP86eZd/mHv76ujg7N/vnj98fv/evvp6fTNt7cv4/3y/a8nz9N/r3bvzv9j
4mPKQdhtbcVuhKGvRZ7th/sAFm1/8QF0ekgSP2jBo4PhV+PRwR+AR7UG1V+N
QPs+Am3pc/8/6kb46FNBb/Qo/MyuufvKBMLeAu5Xtp2CoHFn559xpFUBo2GH
3sGeZF+2qg1OIz3bLo8E+xGZWqXkBpZWn2AKVM1C3q+7O/W5UDp49PUPOwLd
WVZRt3Sxv6cXtik7Y5MjUsllODDxvNrgwPjrb9M4+IpajNRIqVWfemT7dqtV
PdDDXR58TCN3efSx3dzl8e0t3X8RY0NG9m8J76h3s09LDmjH0hZJsTGtSBz/
J5ctXSwc7zDm7j7uepP3nsNJcGzuRK6Wcqfx4wPN4QNTsZ5UUvZ9CPpg6AL3
h9Iq+OI29c2/gQygqDjTbjtG/306sn31TCY4j/VDnm4NEbBaLLnOMEWEg4xb
OurJpaAin1xXvNZXr13L5+7a1ICasCB0/vkZUcL9ooGjoYeJQZfL2+k/XT4d
xzPUw68XKdwAQIJNY8Kd2oQN9PVaQvccRoq/ohl19TgzaksnXmNWf3Tv3tob
v791L4rUbYr5C18xvxkmcC8mxKH2HyNt/b7WvR6MPR7JzMZdxt59Wlzt2afb
pDJ41JfAqWVwS6Pvr7BvOb2QJOrkLjedAr0GsBQ/5PQ7JxTWkG6Dqn5dUr9B
7PY28U/Cw8nHLL/DY+cAiq0+V3b/UAS19O7lJFckAbgaSpbWXLO0cDJQ40VA
sZ15S2cqJBBiN+OmpG7fNkk8M0ln+U0zB9eka2RT++N5kcOzkhfm5MeGD+TH
NgqrBFpYJS0lZzb4fwHhWBSqTCEBAA==
-->
</rfc>
Reference in New Issue View Git Blame Copy Permalink