Christian Nennemann
898b0f8747
Move 6 metadata claims (pol_timestamp, inp_classification, exec_time_ms, regulated_domain, model_version, witnessed_by) from registered JWT claims to recommended ext extension keys. Use short key names for spec-defined extensions. Make audit ledger explicitly optional: rename pseudocode parameter from ledger to ect_store, mark architecture diagram ledger layer as optional, add conditional append logic, and soften Audit Ledger Interface language. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
3198 lines
138 KiB
XML
3198 lines
138 KiB
XML
<?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 " ">
|
||
<!ENTITY zwsp "​">
|
||
<!ENTITY nbhy "‑">
|
||
<!ENTITY wj "⁠">
|
||
|
||
]>
|
||
|
||
|
||
<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
|
||
+--------------------------------------------------+
|
||
| Optional: Audit Ledger (Immutable Record) |
|
||
| "ECTs MAY be appended to an audit ledger" |
|
||
+--------------------------------------------------+
|
||
]]></artwork></figure>
|
||
|
||
<t>This extension reuses the WIMSE signing model, extends JWT claims
|
||
using standard JWT extensibility <xref target="RFC7519"/>, and maintains WIMSE
|
||
concepts including trust domains and workload identifiers.</t>
|
||
|
||
</section>
|
||
<section anchor="integration-points"><name>Integration Points</name>
|
||
|
||
<t>An ECT integrates with the WIMSE identity framework through the
|
||
following mechanisms:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>The ECT JOSE header "kid" parameter <bcp14>MUST</bcp14> reference the public
|
||
key identifier from the agent's WIT.</t>
|
||
<t>In WIMSE deployments, the ECT "iss" claim <bcp14>SHOULD</bcp14> use the WIMSE
|
||
workload identifier format (a SPIFFE ID <xref target="SPIFFE"/>).</t>
|
||
<t>The ECT <bcp14>MUST</bcp14> be signed with the same private key associated
|
||
with the agent's WIT.</t>
|
||
<t>The ECT signing algorithm (JOSE header "alg" parameter) <bcp14>MUST</bcp14>
|
||
match the algorithm used in the corresponding WIT.</t>
|
||
</list></t>
|
||
|
||
<t>When an agent makes an HTTP request to another agent, the
|
||
Execution-Context header is carried alongside WIMSE identity
|
||
headers:</t>
|
||
|
||
<figure title="HTTP Header Stacking" anchor="fig-http-headers"><artwork type="ascii-art"><![CDATA[
|
||
HTTP Request from Agent A to Agent B:
|
||
Workload-Identity: <WIT for Agent A>
|
||
Execution-Context: <ECT recording what A did>
|
||
]]></artwork></figure>
|
||
|
||
<t>When a Workload Proof Token (WPT) is available per
|
||
<xref target="I-D.ietf-wimse-s2s-protocol"/>, agents <bcp14>SHOULD</bcp14> include it
|
||
alongside the WIT and ECT. ECT verification does not depend
|
||
on the presence of a WPT; the ECT is independently verifiable
|
||
via the WIT public key.</t>
|
||
|
||
<t>The receiving agent (Agent B) verifies in order:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>WIT (WIMSE layer): Verifies Agent A's identity within the
|
||
trust domain. WPT verification, if present, per
|
||
<xref target="I-D.ietf-wimse-s2s-protocol"/>.</t>
|
||
<t>ECT (this extension): Records what Agent A did, what policy was
|
||
evaluated, and what precedent tasks exist.</t>
|
||
<t>Ledger (if deployed): Appends the verified ECT to the audit
|
||
ledger.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="ect-format"><name>Execution Context Token Format</name>
|
||
|
||
<t>An Execution Context Token is a JSON Web Token (JWT) <xref target="RFC7519"/>
|
||
signed as a JSON Web Signature (JWS) <xref target="RFC7515"/> using the Compact
|
||
Serialization. JWS JSON Serialization <bcp14>MUST NOT</bcp14> be used for ECTs.</t>
|
||
|
||
<section anchor="jose-header"><name>JOSE Header</name>
|
||
|
||
<t>The ECT JOSE header <bcp14>MUST</bcp14> contain the following parameters:</t>
|
||
|
||
<figure title="ECT JOSE Header Example" anchor="fig-header"><sourcecode type="json"><![CDATA[
|
||
{
|
||
"alg": "ES256",
|
||
"typ": "wimse-exec+jwt",
|
||
"kid": "agent-a-key-id-123"
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
<dl>
|
||
<dt>alg:</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14>. The digital signature algorithm used to sign the ECT.
|
||
<bcp14>MUST</bcp14> match the algorithm in the corresponding WIT.
|
||
Implementations <bcp14>MUST</bcp14> support ES256 <xref target="RFC7518"/>. The "alg"
|
||
value <bcp14>MUST NOT</bcp14> be "none". Symmetric algorithms (e.g., HS256,
|
||
HS384, HS512) <bcp14>MUST NOT</bcp14> be used, as ECTs require asymmetric
|
||
signatures for non-repudiation.</t>
|
||
</dd>
|
||
<dt>typ:</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14>. <bcp14>MUST</bcp14> be set to "wimse-exec+jwt" to distinguish ECTs
|
||
from other JWT types, consistent with the WIMSE convention for
|
||
type parameter values.</t>
|
||
</dd>
|
||
<dt>kid:</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14>. The key identifier referencing the public key from
|
||
the agent's WIT <xref target="RFC7517"/>. Used by verifiers to look up the
|
||
correct public key for signature verification.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="jwt-claims"><name>JWT Claims</name>
|
||
|
||
<t>The ECT payload contains both WIMSE-compatible standard JWT claims
|
||
and execution context claims defined by this specification.</t>
|
||
|
||
<section anchor="standard-jwt-claims"><name>Standard JWT Claims</name>
|
||
|
||
<t>The following standard JWT claims <xref target="RFC7519"/> <bcp14>MUST</bcp14> be present in
|
||
every ECT:</t>
|
||
|
||
<dl>
|
||
<dt>iss:</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14>. StringOrURI. A URI identifying the issuer of the
|
||
ECT. In WIMSE deployments, this <bcp14>SHOULD</bcp14> be the workload's
|
||
SPIFFE ID in the format <spanx style="verb">spiffe://<trust-domain>/<path></spanx>,
|
||
matching the "sub" claim of the agent's WIT. Non-WIMSE
|
||
deployments <bcp14>MAY</bcp14> use other URI schemes (e.g., HTTPS URLs or
|
||
URN:UUID identifiers).</t>
|
||
</dd>
|
||
<dt>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>SHOULD</bcp14> use reverse domain notation (e.g.,
|
||
"com.example.custom_field") to avoid collisions between
|
||
independently developed extensions. To prevent abuse and
|
||
excessive token size, the serialized JSON representation of
|
||
the "ext" object <bcp14>SHOULD NOT</bcp14> exceed 4096 bytes, and the JSON
|
||
nesting depth within the "ext" object <bcp14>SHOULD NOT</bcp14> exceed 5
|
||
levels. Implementations <bcp14>SHOULD</bcp14> reject ECTs whose "ext" claim
|
||
exceeds these limits.</t>
|
||
|
||
<t>The following extension keys are defined by this specification
|
||
for common use cases. Because these keys are documented here,
|
||
they use short names without reverse domain prefixes:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>"exec_time_ms": Integer. Execution duration in milliseconds.</t>
|
||
<t>"regulated_domain": String. Regulatory domain (e.g.,
|
||
"medtech", "finance", "military").</t>
|
||
<t>"model_version": String. AI/ML model version.</t>
|
||
<t>"witnessed_by": Array of StringOrURI. Identifiers of
|
||
third-party entities that the issuer claims observed the
|
||
task. Note: this is self-asserted; for verifiable witness
|
||
attestation, witnesses should submit independent signed ECTs.</t>
|
||
<t>"inp_classification": String. Data sensitivity classification
|
||
(e.g., "public", "confidential", "restricted").</t>
|
||
<t>"pol_timestamp": NumericDate. Time at which the policy
|
||
decision was made, if distinct from "iat".</t>
|
||
</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": {
|
||
"pol_timestamp": 1772064145,
|
||
"exec_time_ms": 245,
|
||
"regulated_domain": "medtech",
|
||
"model_version": "clinical-reasoning-v4.2"
|
||
}
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="http-header"><name>HTTP Header Transport</name>
|
||
|
||
<section anchor="execution-context-header-field"><name>Execution-Context Header Field</name>
|
||
|
||
<t>This specification defines the Execution-Context HTTP header field
|
||
<xref target="RFC9110"/> for transporting ECTs between agents.</t>
|
||
|
||
<t>The header field value is the ECT in JWS Compact Serialization
|
||
format <xref target="RFC7515"/>. The value consists of three Base64url-encoded
|
||
parts separated by period (".") characters.</t>
|
||
|
||
<t>An agent sending a request to another agent includes the
|
||
Execution-Context header alongside the WIMSE Workload-Identity
|
||
header:</t>
|
||
|
||
<figure title="HTTP Request with ECT Header" anchor="fig-http-example"><artwork><![CDATA[
|
||
GET /api/safety-check HTTP/1.1
|
||
Host: safety-agent.example.com
|
||
Workload-Identity: eyJhbGci...WIT...
|
||
Execution-Context: eyJhbGci...ECT...
|
||
]]></artwork></figure>
|
||
|
||
<t>When multiple parent tasks contribute context to a single request,
|
||
multiple Execution-Context header field lines <bcp14>MAY</bcp14> be included, each
|
||
carrying a separate ECT in JWS Compact Serialization format.</t>
|
||
|
||
<t>When a receiver processes multiple Execution-Context headers, it
|
||
<bcp14>MUST</bcp14> individually verify each ECT per the procedure in
|
||
<xref target="verification"/>. If any single ECT fails verification, the
|
||
receiver <bcp14>MUST</bcp14> reject the entire request. The set of verified
|
||
parent task IDs across all received ECTs represents the complete
|
||
set of parent dependencies available for the receiving agent's
|
||
subsequent ECT.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="dag-validation"><name>DAG Validation</name>
|
||
|
||
<section anchor="overview"><name>Overview</name>
|
||
|
||
<t>ECTs form a Directed Acyclic Graph (DAG) where each task
|
||
references its parent tasks via the "par" claim. This structure
|
||
provides a cryptographically signed record of execution ordering,
|
||
enabling auditors to reconstruct the complete workflow and verify
|
||
that required predecessor tasks were recorded before dependent
|
||
tasks.</t>
|
||
|
||
<t>DAG validation is performed against the ECT store — either an
|
||
audit ledger or the set of parent ECTs received inline.</t>
|
||
|
||
</section>
|
||
<section anchor="validation-rules"><name>Validation Rules</name>
|
||
|
||
<t>When receiving and verifying an ECT, implementations <bcp14>MUST</bcp14> perform
|
||
the following DAG validation steps:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>Task ID Uniqueness: The "jti" claim <bcp14>MUST</bcp14> be unique within the
|
||
applicable scope (the workflow identified by "wid", or the
|
||
entire ECT store if "wid" is absent). If an ECT with the same
|
||
"jti" already exists, the ECT <bcp14>MUST</bcp14> be rejected.</t>
|
||
<t>Parent Existence: Every task identifier listed in the "par"
|
||
array <bcp14>MUST</bcp14> correspond to a task that is available in the ECT
|
||
store (either previously recorded in the ledger or received
|
||
inline as a verified parent ECT). If any parent task is not
|
||
found, the ECT <bcp14>MUST</bcp14> be rejected.</t>
|
||
<t>Temporal Ordering: The "iat" value of every parent task <bcp14>MUST
|
||
NOT</bcp14> be greater than the "iat" value of the current task plus a
|
||
configurable clock skew tolerance (<bcp14>RECOMMENDED</bcp14>: 30 seconds).
|
||
That is, for each parent: <spanx style="verb">parent.iat < 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, ect_store, clock_skew_tolerance):
|
||
// Step 1: Uniqueness check
|
||
if ect_store.contains(ect.jti, ect.wid):
|
||
return error("ECT ID already exists")
|
||
|
||
// Step 2: Parent existence and temporal ordering
|
||
for parent_id in ect.par:
|
||
parent = ect_store.get(parent_id)
|
||
if parent is null:
|
||
return error("Parent task not found: " + parent_id)
|
||
if parent.iat >= ect.iat + clock_skew_tolerance:
|
||
return error("Parent task not earlier than current")
|
||
|
||
// Step 3: Cycle detection (with traversal limit)
|
||
visited = set()
|
||
result = has_cycle(ect.jti, ect.par, ect_store, visited,
|
||
max_ancestor_limit)
|
||
if result is error or result is true:
|
||
return error("Circular dependency or depth limit exceeded")
|
||
|
||
return success
|
||
|
||
function has_cycle(target_jti, parent_ids, ect_store,
|
||
visited, max_depth):
|
||
if visited.size() >= max_depth:
|
||
return error("Maximum ancestor traversal limit exceeded")
|
||
for parent_id in parent_ids:
|
||
if parent_id == target_jti:
|
||
return true
|
||
if parent_id in visited:
|
||
continue
|
||
visited.add(parent_id)
|
||
parent = ect_store.get(parent_id)
|
||
if parent is not null:
|
||
result = has_cycle(target_jti, parent.par, ect_store,
|
||
visited, max_depth)
|
||
if result is error or result is true:
|
||
return result
|
||
return false
|
||
]]></sourcecode></figure>
|
||
|
||
<t>The cycle detection traverses the ancestor graph rooted at the
|
||
current task's parents. The complexity is O(V) where V is the
|
||
number of ancestor nodes reachable from the current task's parent
|
||
references. For typical workflows with shallow DAGs, this is
|
||
efficient. To prevent denial-of-service via extremely deep or
|
||
wide DAGs, implementations <bcp14>SHOULD</bcp14> enforce a maximum ancestor
|
||
traversal limit (<bcp14>RECOMMENDED</bcp14>: 10000 nodes). If the limit is
|
||
reached before cycle detection completes, the ECT <bcp14>SHOULD</bcp14> be
|
||
rejected. Implementations <bcp14>SHOULD</bcp14> cache cycle detection results
|
||
for previously verified tasks to avoid redundant traversals.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="verification"><name>Signature and Token Verification</name>
|
||
|
||
<section anchor="verification-procedure"><name>Verification Procedure</name>
|
||
|
||
<t>When an agent receives an ECT, it <bcp14>MUST</bcp14> perform the following
|
||
verification steps in order:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>Parse the JWS Compact Serialization to extract the JOSE header,
|
||
payload, and signature components per <xref target="RFC7515"/>.</t>
|
||
<t>Verify that the "typ" header parameter is "wimse-exec+jwt".</t>
|
||
<t>Verify that the "alg" header parameter is not "none" and is
|
||
not a symmetric algorithm.</t>
|
||
<t>Verify the "kid" header parameter references a known, valid
|
||
public key from a WIT within the trust domain.</t>
|
||
<t>Retrieve the public key identified by "kid" and verify the JWS
|
||
signature per <xref target="RFC7515"/> Section 5.2.</t>
|
||
<t>Verify that the signing key identified by "kid" has not been
|
||
revoked within the trust domain. Implementations <bcp14>MUST</bcp14> check
|
||
the key's revocation status using the trust domain's key
|
||
lifecycle mechanism (e.g., certificate revocation list, OCSP,
|
||
or SPIFFE trust bundle updates).</t>
|
||
<t>Verify the "alg" header parameter matches the algorithm in the
|
||
corresponding WIT.</t>
|
||
<t>Verify the "iss" claim matches the "sub" claim of the WIT
|
||
associated with the "kid" public key.</t>
|
||
<t>Verify the "aud" claim contains the verifier's own workload
|
||
identity. When "aud" is an array, it is sufficient that the
|
||
verifier's identity appears as one element; the presence of
|
||
other audience values does not cause verification failure.
|
||
When the verifier is the audit ledger, the ledger's own
|
||
identity <bcp14>MUST</bcp14> appear in "aud".</t>
|
||
<t>Verify the "exp" claim indicates the ECT has not expired.</t>
|
||
<t>Verify the "iat" claim is not unreasonably far in the past
|
||
(implementation-specific threshold, <bcp14>RECOMMENDED</bcp14> maximum of
|
||
15 minutes) and is not unreasonably far in the future
|
||
(<bcp14>RECOMMENDED</bcp14>: no more than 30 seconds ahead of the
|
||
verifier's current time, to account for clock skew).</t>
|
||
<t>Verify all required claims ("jti", "exec_act", "par") are
|
||
present and well-formed.</t>
|
||
<t>If "pol" or "pol_decision" is present, verify that both are
|
||
present and that "pol_decision" is one of "approved",
|
||
"rejected", or "pending_human_review".</t>
|
||
<t>Perform DAG validation per <xref target="dag-validation"/>.</t>
|
||
<t>If all checks pass, 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, ect_store):
|
||
// Parse JWS
|
||
(header, payload, signature) = parse_jws(ect_jws)
|
||
|
||
// Verify header
|
||
if header.typ != "wimse-exec+jwt":
|
||
return reject("Invalid typ parameter")
|
||
|
||
if header.alg == "none" or is_symmetric(header.alg):
|
||
return reject("Prohibited algorithm")
|
||
|
||
// Look up public key
|
||
public_key = trust_domain_keys.get(header.kid)
|
||
if public_key is null:
|
||
return reject("Unknown key identifier")
|
||
|
||
// Verify signature
|
||
if not verify_jws_signature(header, payload,
|
||
signature, public_key):
|
||
return reject("Invalid signature")
|
||
|
||
// Verify key not revoked
|
||
if is_key_revoked(header.kid, trust_domain_keys):
|
||
return reject("Signing key has been revoked")
|
||
|
||
// Verify algorithm alignment
|
||
wit = get_wit_for_key(header.kid)
|
||
if header.alg != wit.alg:
|
||
return reject("Algorithm mismatch with WIT")
|
||
|
||
// Verify issuer matches WIT subject
|
||
if payload.iss != wit.sub:
|
||
return reject("Issuer does not match WIT subject")
|
||
|
||
// Verify audience
|
||
if verifier_id not in payload.aud:
|
||
return reject("ECT not intended for this recipient")
|
||
|
||
// Verify not expired
|
||
if payload.exp < current_time():
|
||
return reject("ECT has expired")
|
||
|
||
// Verify iat freshness (not too old, not in the future)
|
||
if payload.iat < current_time() - max_age_threshold:
|
||
return reject("ECT issued too long ago")
|
||
if payload.iat > current_time() + clock_skew_tolerance:
|
||
return reject("ECT issued in the future")
|
||
|
||
// Verify required claims
|
||
for claim in ["jti", "exec_act", "par"]:
|
||
if claim not in payload:
|
||
return reject("Missing required claim: " + claim)
|
||
|
||
// Validate policy claims (optional, but must be paired)
|
||
if "pol" in payload or "pol_decision" in payload:
|
||
if "pol" not in payload or "pol_decision" not in payload:
|
||
return reject("pol and pol_decision must both be present")
|
||
if payload.pol_decision not in
|
||
["approved", "rejected", "pending_human_review"]:
|
||
return reject("Invalid pol_decision value")
|
||
|
||
// Validate DAG (against ECT store or inline parent ECTs)
|
||
result = validate_dag(payload, ect_store,
|
||
clock_skew_tolerance)
|
||
if result is error:
|
||
return reject("DAG validation failed")
|
||
|
||
// All checks passed; record if store is available
|
||
if ect_store is not null:
|
||
ect_store.append(payload)
|
||
return accept
|
||
]]></sourcecode></figure>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="ledger-interface"><name>Audit Ledger Interface</name>
|
||
|
||
<t>ECTs <bcp14>MAY</bcp14> be recorded in an immutable audit ledger for compliance
|
||
verification and post-hoc analysis. A ledger is <bcp14>RECOMMENDED</bcp14> for
|
||
regulated environments but is not required for point-to-point
|
||
operation. This specification does not mandate a specific storage
|
||
technology. Implementations <bcp14>MAY</bcp14> use append-only logs, databases
|
||
with cryptographic commitment schemes, distributed ledgers, or
|
||
any storage mechanism that provides the required properties.</t>
|
||
|
||
<t>When an audit ledger is deployed, the implementation <bcp14>MUST</bcp14> provide:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>Append-only semantics: Once an ECT is recorded, it <bcp14>MUST NOT</bcp14> be
|
||
modified or deleted.</t>
|
||
<t>Ordering: The ledger <bcp14>MUST</bcp14> maintain a total ordering of ECT
|
||
entries via a monotonically increasing sequence number.</t>
|
||
<t>Lookup by ECT ID: The ledger <bcp14>MUST</bcp14> support efficient retrieval
|
||
of ECT entries by "jti" value.</t>
|
||
<t>Integrity verification: The ledger <bcp14>SHOULD</bcp14> provide a mechanism
|
||
to verify that no entries have been tampered with (e.g.,
|
||
hash chains or Merkle trees).</t>
|
||
</list></t>
|
||
|
||
<t>The ledger <bcp14>SHOULD</bcp14> be maintained by an entity independent of the
|
||
workflow agents to reduce the risk of collusion.</t>
|
||
|
||
</section>
|
||
<section anchor="use-cases"><name>Use Cases</name>
|
||
|
||
<t>This section describes representative use cases demonstrating how
|
||
ECTs provide execution records in regulated environments. These
|
||
examples demonstrate ECT mechanics; production deployments would
|
||
include additional domain-specific requirements beyond the scope
|
||
of this specification.</t>
|
||
|
||
<t>Note: task identifiers in this section are abbreviated for
|
||
readability. In production, all "jti" values are required to be
|
||
UUIDs per <xref target="exec-claims"/>.</t>
|
||
|
||
<section anchor="medical-device-sdlc-workflow"><name>Medical Device SDLC Workflow</name>
|
||
|
||
<t>In a medical device software development lifecycle (SDLC),
|
||
AI agents assist across multiple phases from requirements
|
||
analysis through release approval. Regulatory frameworks
|
||
including <xref target="FDA-21CFR11"/> Section 11.10(e) and <xref target="EU-MDR"/> require
|
||
audit trails documenting the complete development process for
|
||
software used in medical devices.</t>
|
||
|
||
<figure title="Medical Device SDLC Workflow" anchor="fig-medtech-sdlc"><artwork><![CDATA[
|
||
Agent A (Spec Reviewer):
|
||
jti: task-001 par: []
|
||
exec_act: review_requirements_spec
|
||
pol: spec_review_policy_v2 pol_decision: approved
|
||
|
||
Agent B (Code Generator):
|
||
jti: task-002 par: [task-001]
|
||
exec_act: implement_module
|
||
pol: coding_standards_v3 pol_decision: approved
|
||
|
||
Agent C (Test Agent):
|
||
jti: task-003 par: [task-002]
|
||
exec_act: execute_test_suite
|
||
pol: test_coverage_policy_v1 pol_decision: approved
|
||
|
||
Agent D (Build Agent):
|
||
jti: task-004 par: [task-003]
|
||
exec_act: build_release_artifact
|
||
pol: build_validation_v2 pol_decision: approved
|
||
|
||
Human Release Manager:
|
||
jti: task-005 par: [task-004]
|
||
exec_act: approve_release
|
||
pol: release_approval_policy pol_decision: approved
|
||
pol_enforcer: spiffe://meddev.example/human/release-mgr-42
|
||
ext: {witnessed_by: [...]} (extension metadata)
|
||
]]></artwork></figure>
|
||
|
||
<t>ECTs record that requirements were reviewed before implementation
|
||
began, that tests were executed against the implemented code, that
|
||
the build artifact was validated, and that a human release manager
|
||
explicitly approved the release. The DAG structure ensures no
|
||
phase was skipped or reordered.</t>
|
||
|
||
<section anchor="fda-audit-with-dag-reconstruction"><name>FDA Audit with DAG Reconstruction</name>
|
||
|
||
<t>During a regulatory audit, an FDA reviewer requests evidence of
|
||
the development process for a specific software release. The
|
||
auditing authority retrieves all ECTs sharing the same workflow
|
||
identifier ("wid") from the audit ledger and reconstructs the
|
||
complete DAG:</t>
|
||
|
||
<figure title="Reconstructed DAG for FDA Audit" anchor="fig-fda-audit"><artwork><![CDATA[
|
||
task-001 (review_requirements_spec)
|
||
|
|
||
v
|
||
task-002 (implement_module)
|
||
|
|
||
v
|
||
task-003 (execute_test_suite)
|
||
|
|
||
v
|
||
task-004 (build_release_artifact)
|
||
|
|
||
v
|
||
task-005 (approve_release) [human, witnessed]
|
||
]]></artwork></figure>
|
||
|
||
<t>The reconstructed DAG provides cryptographic evidence that:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Each phase was executed by an identified and authenticated agent.</t>
|
||
<t>Policy checkpoints were evaluated at every phase transition.</t>
|
||
<t>The execution sequence was maintained (no step was bypassed).</t>
|
||
<t>A human-in-the-loop approved the final release, with independent
|
||
witness attestation.</t>
|
||
<t>Timestamps and execution durations are recorded for each step.</t>
|
||
</list></t>
|
||
|
||
<t>This can contribute to compliance with:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t><xref target="FDA-21CFR11"/> Section 11.10(e): Computer-generated audit trails
|
||
that record the date, time, and identity of the operator.</t>
|
||
<t><xref target="EU-MDR"/> Annex II: Technical documentation traceability for the
|
||
software development lifecycle.</t>
|
||
<t><xref target="EU-AI-ACT"/> Article 12: Automatic logging capabilities for
|
||
high-risk AI systems involved in the development process.</t>
|
||
<t><xref target="EU-AI-ACT"/> Article 14: ECTs can record evidence that human
|
||
oversight events occurred during the release process.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="financial-trading-workflow"><name>Financial Trading Workflow</name>
|
||
|
||
<t>In a financial trading workflow, agents perform risk assessment,
|
||
compliance verification, and trade execution. The DAG structure
|
||
records that compliance checks were evaluated before trade
|
||
execution.</t>
|
||
|
||
<figure title="Financial Trading Workflow" anchor="fig-finance"><artwork><![CDATA[
|
||
Agent A (Risk Assessment):
|
||
jti: task-001 par: []
|
||
exec_act: calculate_risk_exposure
|
||
pol: risk_limits_policy_v2 pol_decision: approved
|
||
|
||
Agent B (Compliance):
|
||
jti: task-002 par: [task-001]
|
||
exec_act: verify_compliance
|
||
pol: compliance_check_v1 pol_decision: approved
|
||
|
||
Agent C (Execution):
|
||
jti: task-003 par: [task-002]
|
||
exec_act: execute_trade
|
||
pol: execution_policy_v3 pol_decision: approved
|
||
]]></artwork></figure>
|
||
|
||
<t>This can contribute to compliance with:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t><xref target="MIFID-II"/>: ECTs provide cryptographic records of the execution
|
||
sequence that can support transaction audit requirements.</t>
|
||
<t><xref target="DORA"/> Article 12: ECTs contribute to ICT activity logging.</t>
|
||
<t><xref target="EU-AI-ACT"/> Article 12: Logging of decisions made by AI-driven
|
||
systems.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="compensation-and-rollback"><name>Compensation and Rollback</name>
|
||
|
||
<t>When a compliance violation is discovered after execution, ECTs
|
||
provide a mechanism to record authorized compensation actions with
|
||
a cryptographic link to the original task:</t>
|
||
|
||
<figure title="Compensation ECT Example" anchor="fig-compensation"><sourcecode type="json"><![CDATA[
|
||
{
|
||
"iss": "spiffe://bank.example/agent/operations",
|
||
"sub": "spiffe://bank.example/agent/operations",
|
||
"aud": "spiffe://bank.example/system/ledger",
|
||
"iat": 1772150550,
|
||
"exp": 1772151150,
|
||
"jti": "550e8400-e29b-41d4-a716-446655440099",
|
||
"wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
|
||
"exec_act": "initiate_trade_rollback",
|
||
"par": ["550e8400-e29b-41d4-a716-446655440003"],
|
||
"pol": "compensation_policy_v1",
|
||
"pol_decision": "approved",
|
||
"pol_enforcer": "spiffe://bank.example/human/compliance-officer",
|
||
"compensation_required": true,
|
||
"compensation_reason": "policy_violation_in_parent_trade"
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
<t>The "par" claim links the compensation action to the original
|
||
trade, creating an auditable chain from execution through
|
||
violation discovery to remediation.</t>
|
||
|
||
</section>
|
||
<section anchor="autonomous-logistics-coordination"><name>Autonomous Logistics Coordination</name>
|
||
|
||
<t>In a logistics workflow, multiple compliance checks complete
|
||
before shipment commitment. The DAG structure records that all
|
||
required checks were completed:</t>
|
||
|
||
<figure title="Logistics Workflow with Parallel Tasks" anchor="fig-logistics"><artwork><![CDATA[
|
||
Agent A (Route Planning):
|
||
jti: task-001 par: []
|
||
exec_act: plan_route
|
||
pol: route_policy_v1 pol_decision: approved
|
||
|
||
Agent B (Customs):
|
||
jti: task-002 par: [task-001]
|
||
exec_act: validate_customs
|
||
pol: customs_policy_v2 pol_decision: approved
|
||
|
||
Agent C (Safety):
|
||
jti: task-003 par: [task-001]
|
||
exec_act: verify_cargo_safety
|
||
pol: safety_policy_v1 pol_decision: approved
|
||
|
||
Agent D (Payment):
|
||
jti: task-004 par: [task-002, task-003]
|
||
exec_act: authorize_payment
|
||
pol: payment_policy_v3 pol_decision: approved
|
||
|
||
System (Commitment):
|
||
jti: task-005 par: [task-004]
|
||
exec_act: commit_shipment
|
||
pol: commitment_policy_v1 pol_decision: approved
|
||
]]></artwork></figure>
|
||
|
||
<t>Note that tasks 002 and 003 both depend only on task-001 and can
|
||
execute in parallel. Task 004 depends on both, demonstrating the
|
||
DAG's ability to represent parallel execution with a join point.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="security-considerations"><name>Security Considerations</name>
|
||
|
||
<t>This section addresses security considerations following the
|
||
guidance in <xref target="RFC3552"/>.</t>
|
||
|
||
<section anchor="threat-model"><name>Threat Model</name>
|
||
|
||
<t>The following threat actors are considered:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Malicious agent (insider threat): An agent within the trust
|
||
domain that intentionally creates false ECT claims.</t>
|
||
<t>Compromised agent (external attacker): An agent whose private
|
||
key has been obtained by an external attacker.</t>
|
||
<t>Ledger tamperer: An entity attempting to modify or delete ledger
|
||
entries after they have been recorded.</t>
|
||
<t>Time manipulator: An entity attempting to manipulate timestamps
|
||
to alter perceived execution ordering.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="self-assertion-limitation"><name>Self-Assertion Limitation</name>
|
||
|
||
<t>ECTs are self-asserted by the executing agent. The agent claims
|
||
what it did, and this claim is signed with its private key. A
|
||
compromised or malicious agent could create ECTs with false claims
|
||
(e.g., setting "pol_decision" to "approved" without actually
|
||
evaluating the policy).</t>
|
||
|
||
<t>ECTs do not independently verify that:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>The claimed execution actually occurred as described</t>
|
||
<t>The policy evaluation was correctly performed</t>
|
||
<t>The input/output hashes correspond to the actual data processed</t>
|
||
<t>The agent faithfully performed the stated action</t>
|
||
</list></t>
|
||
|
||
<t>The trustworthiness of ECT claims depends on the trustworthiness
|
||
of the signing agent. To mitigate single-agent false claims,
|
||
regulated environments <bcp14>SHOULD</bcp14> use the "witnessed_by"
|
||
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
|
||
"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 "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 "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'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: 'actor' and 'principal'.
|
||
The 'actor' field identifies the agent performing the action, while
|
||
the 'principal' field identifies the human or system entity that
|
||
initiated the agent's action. For autonomous agents operating
|
||
independently, the 'principal' 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 1586?>
|
||
|
||
<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": {
|
||
"witnessed_by": [
|
||
"spiffe://meddev.example/audit/qa-observer-1"
|
||
]
|
||
}
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
<t>The resulting DAG records the complete SDLC: spec review preceded
|
||
implementation, implementation preceded testing, testing preceded
|
||
build, and a human release manager approved the final release.
|
||
The "ext" object in task 5 carries witness metadata via
|
||
the "witnessed_by" extension key.</t>
|
||
|
||
<figure><artwork><![CDATA[
|
||
task-...-0001 (review_requirements_spec)
|
||
|
|
||
v
|
||
task-...-0002 (implement_module)
|
||
|
|
||
v
|
||
task-...-0003 (execute_test_suite)
|
||
|
|
||
v
|
||
task-...-0004 (build_release_artifact)
|
||
|
|
||
v
|
||
task-...-0005 (approve_release) [human]
|
||
]]></artwork></figure>
|
||
|
||
<t>An FDA auditor reconstructs this DAG by querying the audit ledger
|
||
for all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and
|
||
verifying each signature. The DAG provides cryptographic evidence
|
||
that the SDLC followed the prescribed process with human oversight
|
||
at the release gate.</t>
|
||
|
||
</section>
|
||
<section numbered="false" anchor="example-3-parallel-execution-with-join"><name>Example 3: Parallel Execution with Join</name>
|
||
|
||
<t>A workflow where two tasks execute in parallel and a third task
|
||
depends on both:</t>
|
||
|
||
<figure><artwork><![CDATA[
|
||
task-...-0001 (assess_risk)
|
||
| \
|
||
v v
|
||
task-...-0002 task-...-0003
|
||
(check (verify
|
||
compliance) liquidity)
|
||
| /
|
||
v v
|
||
task-...-0004 (execute_trade)
|
||
]]></artwork></figure>
|
||
|
||
<t>Task 004 ECT payload:</t>
|
||
|
||
<figure><sourcecode type="json"><![CDATA[
|
||
{
|
||
"iss": "spiffe://bank.example/agent/execution",
|
||
"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:
|
||
H4sIAAAAAAAAA9W923rbVpYgfI+nQNMXIasJSpQl22GqqkeW5Fhpy1ZJclzp
|
||
qnxqkIRIxCTAAkDJbMf9/Q/xP8A8yzzKPMms4z4AoCSncjHjL7ElEtiHtdde
|
||
50MURUGVVotkFHZOPiWTdZXmWXiUZ1XyqQqv8o9JVoY3eREep2VVpON1lUzD
|
||
w1mSVekk/JAXH28W+V3ZCeLxuEhuYZAPp2eXJ2FjqE4wiatklhebUVhW02Ca
|
||
T7J4CbNOi/imirIky5JlnGXRXboskyjR96MJvx/t7gblerxMyxI+rTYrePX0
|
||
5OpVkK2X46QYBVMYfhTACp4GcZHEsJJLGKJIq00nuIN1zop8vdL1dYKPyQY+
|
||
nY6CMIxCM1sos9Gn+NYij6dhOsXtVhv6NJa93+ne+dP1NK3CqojTBf0+yZer
|
||
RRpnk4R+LZLZehEj6MpNWSXLMgjidTXPC5of/g/Dm/ViwRA5mhcAa3g5fKtQ
|
||
oSfyYhZn6X/FuFDYfDZNVkmGSwsvkjKJi8k8KehBeCVdjMI0qW7+hwHsYJoE
|
||
QZYXS3j/NsF5L14dPT8YHtgfn9sfv7U/vpAfvz14tqc/Doe7+ONpdDzAWeTQ
|
||
cAktH5d7ZbQq8iqf5ItREKTZTW0VTw8OdOQXz759qpPs7w11tCzVKdKIDiDS
|
||
M8EnLs9PX706GdHeFZfp8JPwvMin6wkd7am8Eb4qAMx4fITXJ7dJscmzJOzy
|
||
ML0OjxMXs6QahfOqWpWjnZ1yld7cJIM03wHMLXfwMMtKPo3icb6udnIY6TZN
|
||
7nZoAMLH8CZelIgCJ++jw9Po8OjKX+UF4wUur3vyvhfu7e7t7wyfvfg2zG/C
|
||
ap6EJ+siXyWACudxAfi0xNOOs6l+fZSvs0m6CBfxJs1m4TS/y8J5XCzzLC0B
|
||
2Yr1IilDGDwuqvQmnaTxIkwBwReLFIA4gT0f2i9O3S8OJ9UWQCTrIloknwYJ
|
||
riyGf3aSRboDCL5jFu/sHz+Ldp9Fw6f0oUV6/BMhSo+27lE3VwfF+wzgBUO8
|
||
Oj6M9oZHry6GQx+qV/hvuDfswxDTBN9/lUyTAvZo4V32cboqhHfDk0UyqQqA
|
||
2QQemABVKL9zP7tMZ1lcATaV7RC5u7sbJJObYjDLb3cA6wrYwA6tBZa3M5nH
|
||
qyopotMdIF/6y+HOCiaPhsMWVNkCpfeDy0H4Ks+nBJvjYj0LD6fLNEOyTDuC
|
||
x89OX50eR6enPjiO0wL2AtcNTmO4v/PsYOfk/VfiF6DQMi4+JlUJ+BPepBlQ
|
||
NkYmmH2Nb5Vh9yyF2cPT069CnGla7MiyPLQZAtocRMOD3x9tjt9dHD54C/d2
|
||
9g4O9nHf03SWVrBVGIThDD8DKqSLlC4KkhCcxsKkBGDDh12c57fcIZ7av0N7
|
||
0RD+2//9gQF06ez44iFwDJ/vPN8/ICxIpukENjlNbtNJgod+fPEbNskD+gf+
|
||
PNrFM//99/ju/OTt1cmbk7OTq4uf/K2+Aw56lSySZVIVm/BylUyQGtLe2zcF
|
||
IyOZ5BcMNyjhxXInhy/aaP+W7Rwt8vU0fEuMEPawXIEEAjT8FexmqhfacNJy
|
||
klYVMdi0AvwCYuQx2hxniIAQZGVM3C6qSHLTh7Z9HwH6MkOFR4MoAkFmjPRk
|
||
UgXB1TwtgaNM6HrDgQOGw4FvlRG7J0dXZa8PJwLiVAWf4A6qnI7kg0pShgcD
|
||
FTlbL6o0vCR5KDzJblOgtkJJSEbrBe526aJNHRm0IYfhmEbOChJnwAHgOSwu
|
||
BCHkFuSGsASCnkz7IdIuGhw4JdN9wqG4/BhYiRA+Top+uMoX6WQTJrfxYs13
|
||
A1g+SHlJ2ScktAIfDAsrCOJJkZdlwNJKlTOU8bHlOhMUg3W93DC0pnj0LDo3
|
||
gBUIhO/Sat4UVcPJIgbRCHf/w+W7t+GHZMxHEnZ/+HDVC1jY6sM5wHGWLoaH
|
||
SRaPUUBoSKchnBvIkFkF/wcOlBwpF56Zx1VYrlervKjc7YMUZKYYBAT4dZmE
|
||
MZwe8iEcZrKZADTDWRGv5kAoD7/v2bPAuYtkBSQW4UWHoYLuJEVo81HdcyAh
|
||
rCuJJ3PA2UlKaLjKYS98Tij+wLxVwuDcAnKD1B9OAYTrEk8HEbkEqkPogx8s
|
||
QbhY8OEXm1WV03ZgW6siXaZ4qxHxDsMsuQteX12dh/MkBlQCTpEspv3AXKRI
|
||
LlI/xPtG12zKbAWvK0IXJyM4xos8m5WAwoCfqCIYnOGhDaKDAgTwhpszz4ha
|
||
j9fpgjBsvMgnH+nkAjk5ACjcJ7jnALcsr8Ix3M2qTBY3iF8wRQWXre8eL4It
|
||
EIwBbS68UWm6HDAFWabT6QJ0jScoURrxG35/Ep7lABambUBefjNdMFOGnz+3
|
||
qCBfvuhNB9TOx+uyMqocaV1ENxhlqjlohbP5AwhAZ6yPBKBSAJUw359f9QDs
|
||
tBs6ihKVgEmCV15+DFX5CRrLdVUjWLYS2Xl+Z5Zchs6a4eARsXP4oAiZwoRw
|
||
wIsQBEuQxUKLqbrcyOwINhGYT2kTEdMJBznxDF/nd8ktkryG/kv4l1hciadT
|
||
uKalpUlA9CbAvqp4DOJRtQG4/HuW3+GS7uZ5CAIUEiMkAKCRsFJmxuJbHdwh
|
||
UbmLkfFkgHf0q9x0/DReARoi6YbrcTdPCAyOql0k/1gDkWFsuUvgFgh5wDlr
|
||
RCEkogD7vTDUz+UZgImTIokRnosNvLRa5Bs8iTzLl/m6ZPbDRDCY5LB0kP+A
|
||
qMiZuKo63j/i6UVKFIHwewUKir1EFqPL8H//f/8/zr1Y04X9/Nlojl++9OFX
|
||
R+nhD1Tmh98CxNPPn1HwBGTCgQQgDqfrMxFHwu8yPdzZkhinwidaxh9xBTim
|
||
ZTrdMklgCno/shuA6ZBixfA28IwFwHIJRwWv9wbbBAlXTghVTqAb5LF9ArAg
|
||
WlLSU7N4FY6T6i4B3G3BUXe9TYSUKZwrpWf5HbNIuygBD+MkPA9okAL8gETR
|
||
JyIY4Hx1NDVYB7s/LGVtQPeR/QjN2m7RwGPlOy22KHinKexkSTIlPj0GjgsH
|
||
hueJSyHGWdzC1MwLAhV6YpDdgUqAvrjE1/Tu0p6de8Ns0WNoQVyW6wIvGJIH
|
||
IONAPGC6ZXiJgg6+hGdcAGIAvOh4EIrAn3C3og/jzS1yuH9JyQxe75zsLBDJ
|
||
A6TQ4b2n5HMrkQXMCbG0DZgD8KPjIg4MNJw4ArzUIdMlfJaWIpWn/5VMOzQq
|
||
DEjvm2cYjWCRVyCFhH/th3CLgeCc80H/1MdBgb3hLXm3rkB+D/9j0AmCPZj0
|
||
bY5iIF76qQN3gooAoF2IYUPfNkGGaRaCFU4TyYhIlYoWcDxPefK2Ob1DJQAt
|
||
0uwj0U/AeGaIyCRwCUW+WIxjkBV0ahoBoDVLkaAx9UZ0OFFBJB8j3slFg4dz
|
||
EBHLNSweibkjt6N2Ac8DL/T0Msu0GZ15GBL6k/F6NlNShKYtoDg4AmMC4YG+
|
||
6gtiDt4Ch+Z5UTeL8fTxtJsQUdUAB61iAEwRJbd0M/mm4+cgV9BTuDpXEmLp
|
||
uJyAWF2kudyVywmojPTqIfKuiQBoC1VEJYxkiS1qFmlZvZBl+rD7+TNQyYh/
|
||
+/KlB++CLO2I0iRFIu4aCXrDZAsBAW9P41kEqJeyvskjCHbDTZ18ZHRjXJVX
|
||
GGMjVjr4jVMRqXG1RD0sKTdU2TA4wC4YhUlfal/kkQ49YYTNs0dXVhDGV1ET
|
||
j/gBeYnADjxnBq/gkMVNPElCTxaA9/iByDyAL5MQegOozkIKis1w95AflubY
|
||
8EO4SlNkaiAc077omIzMWJMpScvQfRNi4v1BhI3CfycmIpdBH17GGVxjoqNw
|
||
+AXKq9Mc1a8wKZHRpuXc2Dq8Z4+An+M8cCEX6U2CWlXiPoH4d5GIvXOervAK
|
||
X1h8PbKCU9CqNjgMAwnsBFh2i74HW4RDXJbBWLZLqOJKHNuumcOnhdeqAiPX
|
||
GkYE0AKqLJB2W4Wkro8AaDatOglgwQ2IgfAcsd7KvXNwP49qwxCxdV4prCVM
|
||
0Kku2gXIpIFYlmIhIA0VoABvo8G4H9rrxQRkhl6CjKZcgniJDwXjZJPDV6Rg
|
||
Et6RJauurouW4WzTrLQM6pujs0Rch1s/JXWeVa+EZmEK5l2RfkAkL2dzAh94
|
||
CtChb40CilyiBEGGBLEycQBEvMA1sjDZnNBmaEz3vC0VIpmFaEpguSBvdaNo
|
||
kFpXF+AO2Rc2vELcjAzumGyMAJBPSPyYEg9KyglcO8RH82pjYpLeABPRUEFK
|
||
hnmUGe1NDGiCnrqNo83A1wHZfKbCF+WkKrzKgIVwMBmKWgAIpGZir+EtkXcG
|
||
B2h5mPBBbA08fSxYwoQT6Qs/FoxBtkKKyXoKIYCjzCAnQj5yi0eJrJw8CMhx
|
||
Uvqd6eBHAPgd6QOds/eXV50+/xu+fUc/X5z85f3pxckx/nz5+vDNG/NDIE9c
|
||
vn73/s2x/cm+efTu7Ozk7TG/DJ+G3kdB5+zwpw5fj86786vTd28P33Qa95VQ
|
||
mgVeIuIg6RLIy8AcLb7z8uj8f/3P4T6I2f9y8epobzj8FkQL/uXF8Pk+/AKK
|
||
o1zGPIOD5F9JegQhNYkLkq9Q/o5XaPlHAx9g/px8a3DfAJp/+BtC5udR+Mfx
|
||
ZDXc/7N8gBv2PlSYeR8SzJqfNF5mILZ81DKNgab3eQ3S/noPf/J+V7g7H/7x
|
||
30A+TMJo+OLf/hzUeSUcwJI5xrpsIa7AIUmKHgUj5OqO4qwaW58vJZu7lLGC
|
||
dLDFpCO3VkTyksQaNomSNOxIwCis07TIaSeIJCC3p8TVrbQsHA2Qf42CdpqB
|
||
9F6KAoUyfYJu/ZyEeqRsx2q6PBTT5ffWdMlzsS3Til7GhEnA2iaD3SFCwUwo
|
||
mzA0rZGUpM2QmLroUyRu3yMX8kpqVuDPn8Wjb+xLU+arDXMwqdqhsQrQoi1R
|
||
Zc2+dAh2m+0VFV6Sx96QuKXHv8KtR3jdQH9eLtdsf1jkMzoVuGvEOhqnCYCC
|
||
BZUJHZ7RffuMcigdNqRv3xQPL/vW6ECk2yMj3TLMHL3KzE1nAx9s3SxoEQZc
|
||
sB5dfYabgam22BTZpMjTspA8sWIcMU8k9+aafFNaYdLAh5gFzM1iojuXY5xk
|
||
26Q70YqMfvDfKkdjilhe8FEHoP9Yg9QZLZLbBCNZfNkWbxfJp8c0sbeJHOC9
|
||
qny8j7MtlrCNiG14uvMYObTZZApKG9pViAuD1M+uEbRYSJwHYDT/8OULvF45
|
||
8jICIq2QffLKAFrFNEJPOxwfj07XnlXVhHE5rjCSo1QTlBVJQ8JNugZ9R7CN
|
||
p9NUNlMzLiGXZWAcuhYsVz36/KSp+ZCYzu85vr/gqt0ets3i7SqQD1izCQZk
|
||
D2nHM9i5j2mqjnQ7p2G85Oiv8K9E892vf+r03MmbdnJ3ZgcFRdRZFSSgwuwo
|
||
iYDunk9SEqoYVciKgysQiZvewScRbWVJtACyr0bzfFVXzG7TmGWqeyz0LfzH
|
||
t9HX+aArdbrYIAY6JOlEj0iORsSv8sDqx76a6djUmUhvscDTIV8YrZysX2Id
|
||
s7av3OjiaeFZ0tDAY47aHecRHjWAKkJYXIO+nueAQi2nUfgmzciK7BmZkM6o
|
||
fUksSZ51iXg7XYsTY4w9Q2ebqBjsMRUQApjwSjK12Xoai3iTFIFajUmGVpDS
|
||
V0a0jtlKQ2PQNwDs//7v/wZ8nKQpXLYq+Nfoq//8a/Cr2jTf0GxdvZm9cOuf
|
||
X/ElfO1qFPoXr8thZ6OdnWq6Qwe/86nXcd8553f4qt1/ZfCl37Slrcve8sXt
|
||
b4Ycak0CNyv/HHoH3Av/RgY1DOH4WaAAr2EwmBVjUPdzfcmggYOW54Ob//hX
|
||
gRxOwvOV3Xf0rf/LYfduxcxqFLpyGSCgkcKYAPTMEggMHbpooCSgusXiG9sR
|
||
0HXnGNw6/wwU4F4Fn0fhk5t0FtFdKzkw508miFhvv8dQCRXKzhexoboOm7X6
|
||
iIS8up76vtCNMvzhg2rh4to3pnr8RsYTwuGIz32xwDHxK0VjEcGndJx2Lldk
|
||
IaNGyG9SdrU+eeJJB+cohZYgJDjiQUSiaQmbPSTB0gYwlA8bW41/G20ElmcZ
|
||
u55jb4aRf3hnIgnCzscUUBxEJxgJVL2Q1Ftjb2J+vR7DJRF2bfcFs+dLazL5
|
||
BuGE4jDaiWWh1kpR9jlkC2bvgODXEeuT6LkYNmK2h1JJE4rGFG6kw9NjR0Ds
|
||
DdwN0ibGGv9jwUdRHSJ+1IQPkYVa96PDGhvNYgYsrJovw64HSvjcAWWPlgHj
|
||
wrInMrB50erSSU0A5kk/ABenK0jEexl/ZEcqGc1FdOdLKhECM3Jc4Ok3wk10
|
||
eSlGEBQFOidNeEkNoQIJDmiwQpr3Qualc1fXGSyCf3yJIWiNYIQRUo0/okRn
|
||
WdHhnzEesb5MfhLBXPgCD6r30z97NMRxDRhKQkt8zVu9rEDigAGQdDAkW6VV
|
||
EVbRQ3gLKi8RyRVIDw9Ihn2VwQR7mR6AoFEFFrCMzldEFFBNZObmKqnWucms
|
||
KmADITt2xZ4aI4f/zlydtGwzkaa48ECFXvKB0o1FDB+wGAsgTdJba1/sypn1
|
||
ZASyjLC1wjhmryQMh6Wj3ij8UR+VY2zRWBEB8Rw9ZY3EFG/r/TC9kX0C1q4k
|
||
m+EBsA/Y4Ypw6PoOfFibhHMLxghukhe/5rLnvAnL7q1XH2E01VA0a4hBP6vy
|
||
Ulg1k7RkCnMertiwi1AXME7ZjcUaJrFPmo9ZKOmN2+w6r5i8fX7iOPqYFWx5
|
||
AbG2NRDQ5WSBUMDYe9jEueMLl/aFA1AvbWAR+kwwPvQSthYvRLMHYMArPJT3
|
||
Rah2UaS7xsqAwgWzPyKUcj0/P/klh+MV3x5jaJ0v0XAozsZCJS1XMxRW6NQv
|
||
JajRnwHQRIAxvely7+BZp4+fVJsVfmJzjf71l7uKv0LGB19xTEYcwWWJ0mk0
|
||
3HvaCb741IZXJHTGLFQ2c/IpRq0PSQ1Mj/YINQaLd0DjyksD9RobAHQhL43c
|
||
8gHG9+Pu2/jGdpYRhqdG+2RNiwZRPx7BxJz0C7hOvDqCGZrP4EYk3iF2MtBA
|
||
O/DY5WaJUdDoZ9d1gJ6fDGaDfvgah0Vwvr58+mIffz8Y7vUayEA2YJI0NVAp
|
||
LnVUNA2ZxAvCGpg4KpIVXB81RsEx1iBrWHxCjLB+wvjZlAMW1mk55wiZkFkX
|
||
s0yUADG7rOyTdRieNUExVtKaGF8KxQCE9IYjLRHUEMMBmVqOviYwqVilN8yS
|
||
aVoYDu9LH+a8ntN5vRdrgRCbgpTpRZ5/DNcrIb3i0vKGBoha3KuZSfFmAiCO
|
||
2FUFF/OuUpe/vZereEOsU65jGY5zjaiNUN+HwZB1esK1iN1+UFktkvleKzUt
|
||
7gmycjsoL7NumWmZ1zOGK6poqHGaBRj3uCG9MQhStiI6R3dZoc3+XfH+4pTC
|
||
iuBfPcaNnh1bL9UtFwqP3yb5pkZYGLNoYK1xJq0NBVpD64gZ/KdR//9IDDVi
|
||
hvrnnT8CyOd//s++Cpe6qE65HqtoLcY2V5bFgKEsUiHbWSLpfyiE89XA/ZaT
|
||
eYIGIb3nIF1dwhdvSjbVv794O3r/Hlds9RyUwWEBCEx1MjWAiScHz/yCOKpp
|
||
HAQ5EtNUJFAKCLQiZmOGozTQKCjM0jZT1cckTCcMFSNZraMLjYixSMcFRWYS
|
||
y3fiMMXdtMIloZ3aBSJ7IWVZA8zlrF9zZ3to7gIBOyZnbXPb6qRnV0K6SmHI
|
||
btnzwfAymcR4EOyER+M1Uk66b+QL5TgwPPekLOOZmrZJURdjHGtaHfispmU5
|
||
3NRYBpmMiG+GZDn2+WNwbgofGR98YjAc3l1h4khK6mGKxpUYE1Dg8z/Af38g
|
||
5RZtruxrAYU8xdv2hz+MyAMrfhM8OLqNTJIzlhtFPCUnAEXkJmGGBEP0G9mU
|
||
kqHK2EO/YbmuaUc1sRS+/GukXpWsNRwOceguRkkyrVSOk4gjoF/jZB4vbvTE
|
||
mAQMzMbZd4g7lzdsGnPb5vHLijVP+MPuwMXGEx51armE8Q3ynDj8JSdhPYwr
|
||
u2vyZLEBGqlnrwVYuhNHbreLZ2M6zoq6R329SxTnx46YCySbkFIFfueYjIXV
|
||
RGo5GosuS2lynMm5072RxVICA6G8g6MMA37673/rGNKYsPw1gL2LiRSX0pEn
|
||
25/jGNQdsWz9/WcM7D9Bs7dyVo6KE6TiEBmgkhgYYA30FEJQKsmmDRA4gQdw
|
||
yCaICaRr4XH1bLig8Tc6zmKKDnFllKXGjssgrHHy1cbxLCpj8DpFzWL+CY7h
|
||
WjLkbZrp9JgW24HPOkb4w7PQICT7Pt3NikzrhXrlcDhOM47HaGwexyiNYCQN
|
||
bUcvElINGGGc6MWHhyjSvappr3qLeA0sSIWGOsnCRX8AObBGdt+ul3BUk2PY
|
||
ugbhpMsE3Rd381SkZloOUE+6p1OUkFWgUc93rDfGRPT0wzIXhhNXsiyU2zBJ
|
||
GA+HLkU1T0xAMoYR0QlILCk/4HvUx8ksRnkGmMyD24BnUrES0o4c7tAi4gtl
|
||
JyEYjxDO6QD/Gh6EyzSj+AkmGrQdFDBBYMSkJdnDCnR7OLJsSm7wFEPLVapi
|
||
J3EMuhXZRSaYUISi+kfAEgmfmKBfD7EDFiqGBk8W62Tjm07YfQtgeZnAeEnP
|
||
Mm2ElRrBCPHHLucT6NZPpzQeNIq2wwiDBJWEZLEJ1qAN0VFjPACs5pcqbWXV
|
||
JNHNFvmYvGfrLP3HOqnZGV3SJsyB4EXH6jJaWDsJQSKvkdCJ1RNIWr9MOTCB
|
||
/GmMdSJIoHEhJmKPWTbsd+7AejuhuqtLdwnsuXeW2OWzocObJmgtR4pfW6Z5
|
||
HANxqa7H4fd6rWw8oaEISAIviEsisRUrMIppgURq3s1BZ5dlztGesADsmAIb
|
||
QD9bSSkaxgbkYDFRI8QvlfFAU4P7npbW/sNnQMFwSHjQUzoVihNY5vYdXy3z
|
||
ejxuvK1MJcHCExPirOagJV9H6UJZ5RTg9eRJm0nm8xO8vL4iZPUNUTEoiOc+
|
||
DQZEojtWCxviMCGhYdvO0RKvoQomeAkWYpmmAwBhyhGLTBxUTXS2nJVQk/zc
|
||
FisDCp68BuTbdjdwq5KypTHlpPM6a5QoPAx0Dk1GhnAjGywpMktH6MQ1KJFI
|
||
uNj2IsGyyXUZ3yTVBqMFJ/FiQqki19McJVvCSCAdyYhBq5QD2RNK0uztgpPF
|
||
WirTsKMb64SAeHMGJaALfYKAu83TKWkHiwWnWBgmyc90DzGbXylUkczQIlDQ
|
||
2SoQsWYJAREuTA1+hyr3lwRIjG8+d3ivI8iQ+O+EzuC1dH2VKookTOjNedJK
|
||
8fYZYw3Zh2Gk2zRfl8YYnKi9+TALk+UKJRVaG1xCzq/BYJ+wyHNZGoEhy+tr
|
||
cNATlUORzFDxMFltOkQp90hCrk5sWMHnJ34WwZab9GCiL9ykFZaUab9JV3MP
|
||
PTXKhEdDkUX0GTL+2jxBLuiQSvybES87k0VKUfHXmEACGMXYS6Nd3w4JLesW
|
||
BaRM+Co8da15NC6NG9D6zVf3bQReAADXNuEFTH/gyRoXHnmJvCbSlIPEqTEv
|
||
yjHBCMeabPSj+3ixkeyPyCQI6hfoZjObt0sQwgyveHtGSTilYDdZToy1DFjf
|
||
6FCW2G2CFtirtn1iRtEkSaYSH6lsTfSd2M3pwttNRIay8Hh4Zl33DH9DyYuE
|
||
5/ZhkX5D2WNZoQY8tqEAnPpYTzQUdy2lS7PO4aMBnIkzBV4miT4mo7xwZMd3
|
||
wvzYWhJiVBVL9L2xQMx53BTRjOtxA25E6dGYGwpsx7B/MaTKbQ3ZQVJaK62A
|
||
T6DLBAEkmoWlAY4wq3J/7AjpLB20bh8wwm7fHNCKKyFcz9fLOLtGGpbcbT0s
|
||
k5JBT/Msv6ynM6KPY5IsdQvCW9v355yRVUPY2wMnmi4aoGZdLOZ5Q16lOKus
|
||
DpE52GwT+Hxbr1IZPHJ+nWFH8Phgrw9Fxvvwo1wdkXWqmv4iV8IeDm4QE5tM
|
||
MKvN7iL5TpMxHdsf2h99P6a+ysQ5z2zcrlMtwsjmFDtqq0UIqRMRrHjQGGj0
|
||
aSFd8luXVXQ2NoJQUaKAy5Y6Q8AdAqngajEkOiEG1s7KArumLPvR0b50oVnM
|
||
dN+s4keJkDfBPfHRvD0bgUFhfqSbav4QHm0gEmTfT53MjcJPBnSb215LXBsQ
|
||
Q2XcMaoVBuOu4ppa4+KjZGQXmNbEO/hO4iUBzat0wmqWHOHS6OrWj8oLx8wA
|
||
K/0m23JSmlrrMgZ1DSuFZBtz27MZpiDkhRPTIhLku/PDHcDcvB8eJaBa9sO/
|
||
Hh6dvekHSPvWIMcvQWVfEPqXPU1Kmtp8nvZwbie/x1B3h0fWHBRk8RAp5xjT
|
||
Sk9NXs7nJygmRCZR5wFRR5OmbGKPFxKgeZyBk6cgyQnmbgMZSkB8FpM/Z7lS
|
||
IQ8qube6BuVsvl3p8BNn8VljzsQpaTy8NnxDOO8m7OBzkfH+jZAHPNtfF4sI
|
||
MCoH2EX4QMcRosp5HO0dPBtl++O/zH6an918+BC/if4x+/Rj8ZdX8bu/X199
|
||
Kouj/dNy98dh+Wp8fHc0m3Wkvga8T+tyvJ4Wj616A4BNigmsRMRhDUdCM8nh
|
||
28PwLekFp1qEEKD7Gkc9NKNeGHlHVBVZdMfs4OmL/Y58fjDco/Xd62Q1IyBR
|
||
hKNzaI/5CljNApXVGFWFPEMLqbNRVg+I3U23zYYcDcXSVVWDExmokvijKj+X
|
||
rw9xSt3f2fFBnz4baiETet3KcxOqTYXc/TbhYmdFfBfmwLmrsoklcB8AHX8z
|
||
ujFaG3yrld4RiwqZewx0vExfREtF947czaNahnt4odHHn5+4cpK9pO6n1wr4
|
||
2nZe5vkiiTMSaEWHMjVJLGtPmbU/EP/MIqTR2ujVQWMZaHXbDlOSRiK0vkhx
|
||
D3zc1KdzhwpCm6jY8IKCWNq6exLZqmKdoMFRVAMHkZ048FbzfEdVpTTnhNHr
|
||
NLtmaecaRIQpKPaehn5TJAkFvIRSjxWFDNDAliDbMw6mAF1AmmQ5Tjj+u8Sw
|
||
H6qmltrbjTBKElLViSLLGJJ0TuChyD9gNrN1OmUrIRxpEwwITt9CtQVQgYUq
|
||
wytge4WHA2LP1IBKwBesaoBZ145xvtSchYCFf+voTNw0ZccqjkwU7hMmWMSU
|
||
RVBR/H9+lwWd5NOqQ0bZ74iZOSZlLqtjcmA83iNmYJBqTLgZsRWpkZCTC4QM
|
||
N+T+cJQXuztRY2y8kxvaX5JdTX6xVxBj/3xcf0f+YTFhmKDfnL3GVCmC/OCR
|
||
ym147Zi9cjTdfVEFDZoaiINHUpCp8gdZsZ2pZXQ67HSW5ezvWKL8KJYlirQw
|
||
tqXSlK2ZoveJgCRRwn2naB6+g9Yr734hey/KRHNtYE1SoZEvGKLiwPiySP65
|
||
pkJjcK3UzNWykMCPG5xi1hfZWc1qSGLNiTKRw2nMEhqmW5Od/zYRQ3QJF7Ov
|
||
+TUUAAbDUECYsWsJ9WNM6qA7Tk/PJraGOC68ub/77TM4q0rr6+ErOFoAUjcZ
|
||
yGDdoJA6xuUHBjwIKKetbGGf8jCro55Zm4akYw54GE18J29JOWhmAyluwCE+
|
||
whYciKq+zCkHL0S5pXT8/TyZHUuya2E49K71EZAbJr9zFDQYa1yJ0EEZOISb
|
||
9JOkiJFd9O/XSA3+fr0sOyOWXeF2OjG44XRdqPIDxBeRB4TibAr7jlB7F7Xx
|
||
79c8Awxi2JFTZkKTxwwnAPkLa0ygCMVVUxP8cYmGk7jYgDiFo1PI/t+vcQeo
|
||
7zpDH57unL2R4nvyNb1xx6l/uJ7xBl44bI+5OPUCHOia17IETaiDE9CjWi9n
|
||
Dk7VBYNs2jNHk4t0cRMh8S0ANt8RYbLxuKGsElkwJR5K4KsunhLN14upxAF4
|
||
nlEJ2mTnZ0Rizt+vYWFwC03RUgdOpJEoT0Ta7D+K/h+1xVNUGFnb8+wmlWRU
|
||
/B3uLcbioY2GjwW4OGNNidVxYLqaq7LhbV2pWdGYQNBMtwSGT9G+HIw3kXgP
|
||
ckdy+NmR2BGI40gwZf22pa6r1gtJE0pYDwTFaKHRFuc/BwmolVeE/fX4q55H
|
||
n/X9z6tjg1YDmx2Fw+fP93af7Q8PdulDZNLmw+fyIdr3YdyDg93kxf7ubpTs
|
||
fTuO9ofT/Sh+PnwW7e8/e3ZwsA/f7A5haHzjTqJYd8fDyd70aZTs3xxEz56/
|
||
+DaKx5NplNzsDvee7h/gJx2ZV/wkIzx1JEmAdSCZJXFl/TMohIzCv/3Mc6B5
|
||
YeQYxllEQvOdynp7HRX9rOVq5NjFzLdqF9oKPR7RgDtiw4Bs1sj7owc1zFYF
|
||
k5ahSos7yJujeDfe++X6U359sNx9/+L11cuXb1++PXrz15cfZ8+jWfTTKkm/
|
||
/2F58GxfloIMYxR+DozF070retT7B2yRZaDjE0yC98wXhrZa0mrJJj9CBNCh
|
||
j+YcInMO0e3+YA/F0S+10GW0cETI6yR42bts53KHnAjmJ6GbRnFlyjF9fuJW
|
||
Y5KMzXqeibz1CqWRVsua2tJIvmy+Xi+dGrDncjjcFfm9WSdVxSy2lgmXdscQ
|
||
20BqPb9YPvfDpUa3+0HsgevI54B4EcJ5GAkUFmUYC+G9rFtC0DdYIW/AIOGK
|
||
xYEVzJFPw25nAELaZB5j9BznhR1qhk8plYHjrdk9ap4t78/yqWeguFVvTVaO
|
||
5Pkw1Qy+P7kKd+JVKjQrIpsxHcfOcDAMXudlNQrlO1rKwLmwQUvKT7L5YT7+
|
||
fpIOBgMMOx0Mmsv1HkJ/JTzUyPCRabwMH01CIi8Fnidjncn0qQdOsXZFebFk
|
||
XDUxyK4zXWDeD8zbW+HLWLUgPJasSY0/7VOoR4BJVhs+S8WCBxHPGqQlXamQ
|
||
UAwNs8Ec1ofWhgEpVcBKCmDTbTrlDHGJ4TRxKCsx7pjqVRgR/fmzqwwS3oNq
|
||
jBZagRG5Q6gwiJ/Jg9hoVuvEjRhrfmHgq/G/XOZD3dVBPUhNQjXQ6yADT1WL
|
||
NgE0aukgD4QMKON4ib82sUvtI7VQ0G/KwPf5UJYOOuV/NAW9yMjrFdAjCvhO
|
||
2oBIsjrZMOLwvgoyEitHJ0FmXjcQB3bVZhEI6xYBJKtqg9GinyQfbSu+Ju51
|
||
NKE0ynL1A6oNTuBAL05emKqVGc/igdo6BFFVY8QKSIRWowhqHyACAMqKKVvq
|
||
8xoru/jrjLQbaAgBwtyCmOwvto7wDHXnyg/fobjCJGUSmQVexKwcto8ZGlrG
|
||
KJVmeItZCHXO+gJjHOUeOrhitisOFHLEpm3mWVl1UHkibG13ZZWstAbqFSM+
|
||
tjGQSCZ2hHKsFbt11M4k8Wq1dDupZUBJGFRooqs5Bn58EXEjEhml5hm/LrfU
|
||
AhZtg36cVU/pgfF1G1stSym0Vo0J41Kk1l+pq1c/sKTySYQMVRbFSzDiHj31
|
||
kBmgtmVl/TN0HwIbNCyZYpoQxYSdA5cocNclAtbFQwPwbruCQ04oTd0nZLFK
|
||
0YfeZxRiW5iJvrHI1rNE1KVxUpOUo83X2fReOGH64VWyBKknXoTv5NYKfjgh
|
||
qni5CXbuRJJ/HGom1owCVcXuWg9yFbO8lvGlAVaLtTqsSWGcrQsbDMqhoFW+
|
||
SKj0ath1KpCNwqe7odgQegMa4IoPo0+EmCggL3UU/qf4wmEx4R9BPkoXU/qZ
|
||
qyfQXNc417WZ6z815tdMLlEZnD9ml0cj+ELidxjBaVJvZ2tg0MBEya4N+m+I
|
||
5hhsAiOQ5lMiz5LK91ydH5XgI/9ZNhmny7hIFxs3CDFUD6lftLUrZ5Uo/rse
|
||
SELNXl+qY9IgdgXteMUW90RKPTMBj1PNC8cRtuDYPhpbmFuR/PbKFn9DjMCK
|
||
8w4VdXiWuqMCTnIFXYJcHWJdVlSCWb8pmULIwrnYGbdBqGgVrOvccw8OLL2Q
|
||
ODMNXxrVYEH+W816iK2Cti0iBxCmPRzFwq22ExtqaIStCdWEbwnGsbE4TiAO
|
||
UV83qETdNPTKQ04/IcJeFCHH6wS1bBD8TutdslzJMMJNNKJ0TFVsq7Wrr7J2
|
||
mhT/u90nEmpSJjlFRGShODwKolAfhAmlt+emlIbPzotDARR4RsWdbVUyDNfl
|
||
vM0JIO25KzuZZDvUhmwsccjORa+YFfLBvF4Aixgc27bi8IZ6iokpLeSw3FQK
|
||
7SIkKALaVPAlbH3SECGN27lu21qVyXqao+5oKpeWhlg4EoOR1qU4g30vuFln
|
||
7Fw0YbUgrnapsin8dU2kpN9KSHtYtGFnJ7wEcSQcjhwRhCOHMNj2xg4y0LPB
|
||
wQdwoWmCAYgKvZHABigbAKMo8qJLqdIg1/hSQacXOHPumYOzVJC8AMryHEJM
|
||
Ljx2JKbEmXFuCsW1AVXhn5zVzpKqa17oMcc2ZAwxfr1YaK8mf+Vu7C5SYOLT
|
||
o7AT/mu4bUBiWX+m6Zl7tQL8cdMl2PdKGbVcPB9uT0fhEdFQE/8fdlkqK2I0
|
||
FVGl6GVa4SKxLjXKT3/Ce9ntUYQBBZn+CdH3mmixf6ArDLNxUEdGkPDCxp9l
|
||
/Omaqq/D09dmWoCMzIO1GnCjLD/pR0gd2rDmKC0wELzw62iKG4iTV9hFg7bq
|
||
IDCvU8RoCaK7uQ52d9zd65o2aA6wdPfYtjXdNm2Q5ic0h43JNwP0hXV7eOzm
|
||
kbYtncWf0uUatEMBUv2U3A214Lld8cjHOfz+T38K7e5q6IUgbr6RZrp+fVw4
|
||
BT+re4un0/rt+S13DNDZv2cN1GseTh0Bt+DdljOSpx+Pfw7E+GuLVNzazbVM
|
||
+ZYAtU3VqP25Ic4diQSb1G6rYIDQeoMYXF0WQ+u5kw3yLVck/0aNBBpgyJr5
|
||
Jy6oGb7r/qhGhh/F6Cl9cymSWGfJcmqZhFI420a0klPrVI6VAiZ9hei7WVEE
|
||
g+1SQrSnnFP2GHIuzXpPyyC5wb6jHAnoOJjhYqfxAouUam1GNHgknyqUk8hF
|
||
DWQuLzCFJpER6+q2cHmRtLFVRu2eBfV75usow134w8AQVY10PXoSFk7wsRaL
|
||
+gmqTcTRc43YERjJdasTeoKDNwZl/CsDDldppnaweGMc/SBxYSHRrLIUhbIx
|
||
nBIvyE25OsyPbrTH5yeevY+tIO4D5ypv1ItRiQZcWitI5Rk+Qs/wEXgxJmT2
|
||
qJcaAu4n9b+220dhx4gasdijnEoxfaFMG6k1Ddu11S7wjEBXQ8UQrZ6uXZ9N
|
||
ED/WasxTwRi19do6HxjEXqswIrp5YwAqAtY2AFJCrqnCnSM4u5hKgYZls8SK
|
||
6GVm/ERKtTWGdvSxOPyY5XeZNCNgwPg1RqS8qhNNUaure0A+fVhKcutWf/NL
|
||
mbAdiZZjDWN6gixnmyOowR3OlTH9YLAnMn0dhFpmbduUKHOTWpwkKpHfAoJP
|
||
t+5qi0qlEi7rnTDbNyUNZXAVNuB2WnPHhEc/ShcipyOHaaMhDvdJwl2XUTl0
|
||
RkZ7Vj98d3R5zsgLd11C03mK8Rq7kITrFcryVFbjeQ0T2pGMaoEoR6mVDBLV
|
||
qllp7kVtaKc6nzteS2kReJ/NcLUKvhZXvTpk39b3YAtUeEUKNAf/G064Nx39
|
||
iKfbsg6cNUGDcMw7WQP7kmherpXrGLxi4cYO3sjkj0vKoZLEu+/ER2KKsfFR
|
||
sbVZyiRoZpMxJ3Ewjx/SHaeLdZGwav9BdV5TaEA8k67xuu+YHBkI3t4ZeW0H
|
||
A4IBwHe4O/DgS1GAkhRg4laVU+kdothAUlmHQ/91Mg366dqZyQcHYsKTs/5e
|
||
suWg6zNoE59HvtJyni+APjsM2LBrga1NWu8Jhbx32ps1eUBoYo+tZ9gEhTvK
|
||
ZY4dMozxwtiKPR4yGMEnXWJwW64GxZo9Ee/icM8Ail1U4viQyKEuGbr6jpWo
|
||
LxnWlDZBNFlCcKn2XLJYROzlwLGBpWBEKiV0kGFqS0Zh3+uOQsnibaPTt81B
|
||
JFXQj89w0+b6261iuEpgTOfC7OtWCqL29XZT+M4B7YxbWGJtDYpbbZq+3RK0
|
||
5mKIfVGCSsXc1xAs2D253Zqu4YWBXEnzwCKfzTS7j+7hal2scg7QOyHFQavt
|
||
BE64IedhmEhwg+x1d6bpkGcjY/ucs8iCsBPDTI0sFnlJ9ILFrkbVSPbBgmCG
|
||
JNyrB2orMrheWVspxEQ/sp+EaDUNsL/7NOyCXD9Op0Bjeqg54fsoKKQS8ks5
|
||
hyaEAkU4+pjlLRlkGHTfZzYvU8cxpVObBch4M5L1wesC8jnOp5t6TlocwhYw
|
||
/kw0OaFo2B2UgyADmxbDdjtzHu14QqL5lesP5g7OtaRBMX4KiE0hCjZe1s8m
|
||
uJEMuIYsbW112213dJ+vAVPRFnP9C7a/UAIFqvUWHZgEBokdusbwUUdtVuMe
|
||
y9csmXVFaLYCszmZHijlK3wU59Y1qNFJCB6/zTYQ/nkAAnP4L39qiMeeGYRv
|
||
YLdzyliD+qMVW9iIYwcEyQWNGiIq41mX10Y+7tqHeq1TgNoyT8dk7zIikDGd
|
||
vZFaeVYuCVRCRuABABrwJAOHTPqRLRxo37DveHbE2mLeZySP1+oAdmpANSfA
|
||
YyPPE2SAA7g23zaO7h6rSOjJ4H1nve1Q04Mxr9TXSKHq1IeTRG1eKRwMfH4t
|
||
nzlQ6jfh2D7vpSPqG1O6jFdfgpVoYakzyi0MKFsZjg3tR/DTNVBSnK15YA5u
|
||
AbLCowMq1tmyJJsftgRJnkpwSgPxq/qKJGRYxWSkl1LbTrCED2oAz+msVB+v
|
||
7QB4KCNI8sTOiA1oiAgq9khLKKSRmpmcSta1zIjEix+V3nGmHoKpTlef0xEY
|
||
/Q3Ch+i5ZRmK4hy77eetoqeM0gBojPHBICqSB6LLeSd5SIKjbMtKfr0akNl7
|
||
7K0hjNg2PUuujQi6dV1cJoomJK9RPMs7LXP8uT7HfYb+7dN4W6nDoSZTik1Y
|
||
Zfnwb9tEzJ+NfZif9VGhZhzWRZ2lXMXJn5SdHfSjWZx4l2oJ4t1cOg9wYQIt
|
||
FbeKcTABoBSHMEtpk21r6zRv+ZtoefNRu4RXtKOVeVXWisKzTYzrOEZsPnXv
|
||
FZ5MSe/fXGepKz63y84/b1mckl9vJtItOw3go8Dd1XgoG7JDMhFFozjBTp6v
|
||
x3MOGvb/GCN7q+ew1cPTivU1FYGlL7OxQ18jwEwKCVhLbzQcyQnhqXkkmy4G
|
||
65pgVUK32rNGffaje1Z9T0h0Kj1vEeM4VtprtHFqGtJ+ftJoQSshghIw6kYX
|
||
gYpq+6R5IWxa3EM6nHkrZEwuq2ieT+CXeLEpU67ao0UXS0/TdhoYY86Xzc7n
|
||
NtupNtkWCkDWZ6+MZ5CvxAduYhD90G7LuLIpx0IYARxPA0hwQP1mc1C2Nm0W
|
||
OalA63SQQ70M5FnM5sSE8zJodiynlKqUEhe0Yq1fSYHBUaI+G1AwK6+l3vHW
|
||
hFGqsC+hjLhrTBNyOzJ4XYhLUxCe9U7fAiJ2cR5crN2HzgZNwYVR+I4936pf
|
||
KYpY6zrHcBGKL/Mpm0TJLUoF8sSc7QeIySKlmLjU7YiBw1Vu1BJ3K+W7g1HS
|
||
CYeextiBO6/yTIJJQRNDOwzn32KQAKyXXUtaJB+Ea5Ctx1RXGTTf5ho0Td54
|
||
hPBCoqVZIlekb6quAg2+FFZIlFDs4aethRO8uUR11FILsT1sNvbmnu0ky82E
|
||
lE5LIih3BFeDplN6lDLYKSIKCyGHZ0nxEQPUi4TttM1VjBMDerZhY/ENaYDX
|
||
KIYZ2PBarmBDobjYpdLLhMb0zjWnwwEVeg+35gjvBxAeuEERpRZqz5xSrO02
|
||
tMRN0rxNbDIiPLLkkDEKKJrnd7U2v/WmX0i92mkKa9ZlEkgAvzs2mwPkRCbl
|
||
d9KGUxZpK1LfYXJcYNR/24uvlvvrFwWoN1gO2hssa6J2vTab6W6qYOPiO2Nk
|
||
31ozLODEe63+dJo5O+iTfctBWs7mNASFykkHWJdP/VFuncEvbDk4S6bkXD1O
|
||
yCt6efzmiDI4EC+C4DQjhOZHpvxImd9Ud5yCSmm9RA6tW6KLQ/T6weGpaR5X
|
||
YtyUBtrblIk5IQL5iVywBsphQm0zVADViZlaA3rECz8R1BbXDmyvpM+fXx0f
|
||
RnvDo1cXw6HjBxoOB8PdbsIm38+fT95HZ8cX8L0sIHCLC5m8WBObqHHp7s7V
|
||
cIOHZUCjtUZ90CFhRzFAO4Z0sa0YbIULPZEOg1EVhCjR7u4QSQBGHIV/+zng
|
||
uktUS1Gi+K5doF0jygXUYWxE6CdCoM2ZI9nKqwsXqjQpTXXDl2H3CCPDvkfj
|
||
FwK3saQ9uyRdpL80w5GugW2sSYCiJYEYg/KpFmwtr2+firh3/5KOwu4VWhvp
|
||
t8ZynjaWs+cvRxq0XWNK7HW5TiuzIPpkgqVHUF8zBfceXNBx2H25ThfTLSva
|
||
b6zoqb+iMb58LRh9HaPHLiYNnlbF31rxVc9t+6peU1znhdyQM7g71B/XX9VB
|
||
Y1X7/qpkPF2XLscsUy6ewGn7cvgLU44rNEmXcBHgDmgq1w7pKTsyfLScFdH+
|
||
Hi0I1vLZZFxfjzew4sFg8PMXzCo2SfDLpIpRTut5QrUkMkbldDFRofo+6tZR
|
||
OVkUADexRLgCp5LQ9TSBGb7MFVC1Ze39Th1f6S3tDOjlkphXUe3Npwm/Rqkb
|
||
dPChogMlM6sGNe1b54otDsfnveTzxlrPFE7NAa90FiJc0nNifPYDwgGY1AMl
|
||
ywMixTRp+TFdrVjWKxIS2iTC9EkIBFV0EBJTcLALm7iDsAiO2U8Qh/UGyrgF
|
||
GkCr2qmNGzQ55Pfi86zmW2mrJ+IrmfW2x7Sbc4vIK1BtVOJLSltVDhsDe8V/
|
||
VAoK3JrHlJDSc5rOuXI4HoeTs8SBT4Y5AGAk1dHQ8e42io1qInZnvA0Mge3W
|
||
SWjjmad4F+p0rfHUfthtpzWNJw9Aw/fvfy/8G+GZLSAw/dnP9J3GkbBKvmgO
|
||
JgD2IG7gmRmU0bi0ovGY0YV8TctgBaI9lZagMrUWUc0FYyHXidzgFhWVbUzL
|
||
cgjWGTivlynU22pL3lWa2UIzUQ5wWkktCNyBFUyNXsKVB4zU3QUZnxw/+Pl4
|
||
w2YGKnOgxZRAoITlRYscmwm71/WG+tTKIfT5njlyOxugyVrpVHmglTnpIl4P
|
||
HC21oaKhU1qUsmJwoVqYcBJnbuoqiI/WIEBroXN4SLIaUUzVGruHzFiOSKZe
|
||
zcYgVFIrZJfKyiExJG84+eJrZRrZHJAXA5rfCG2HWZZ8Ck9PQR9DZZ8lLZHZ
|
||
Yo17nCTarPfGJKHdL8KaWQ5Po8OjK5wIrg7KtsM97Hda5eg/nZAjl4rtxSue
|
||
IuWOUjDBPJ3NI1KgQAzm4pLkxcwXt9Ya20Lp7pl6f8T0axKrTuRfElOuNKfk
|
||
/dmcMBlRPJ+QDXmqblyHMdh5URd4RWVTsIbuVRFz0I6vCdyYByp5QImn6VKo
|
||
YXm0+ZiaceMG+4GDS35KLzE3LNVl0baNXwWmDClu1hlNzHm1iyzcmgYO7MA1
|
||
AfyCjsis8vEiuK0fjhu9Bv5LfnQjOOGHXMzHlcAfIX7rtr5e9BYvnmPEM7K3
|
||
fnJNsGIx92HB22R+/xNyN4Ff1mFOwYDk6T3r8NgN1/NRZrMdT0333sfSsrPT
|
||
V6fH0enply9yvdQA4bMjxT0tG6s7QVqibIDxMs6M4YmYh3jwtWeS5f981Y/f
|
||
XRzWCAzfcm/tp9gWYiL1doTs3E+l3ghtym9MhRwuj4P8Et6YFuktxTMKcbLV
|
||
cVorGppKAe4t1pJ7ZJdMS1KmkNZTCxADoj433Gixj2nqdzF162t75ey0EQeV
|
||
Uq4lnWNZBJP95zV5f6g+zzjOPhpVhAvoGINz2V6i5xGv1Kv0eK/4PYBqdXqG
|
||
B7sHjTo9w4Ph8Gvr9HwrVXekTM/0KdbniZ9F4+eTF9G3u8O9aJrc7EamRg98
|
||
0izTk1Iddb2815pS6JXqeUzNoKedn7UQD9WRcRP4bIH7f6aSjwdhViktfkY5
|
||
2n0V2O3pgyNKy2h7gKoyjh5RXrJWAsfDXqcMjlug0S2Bc+WXXCCctvUmaveg
|
||
juwBLaHPLYGkUgARGk6bpkxa0mCsPCgmtcBeXr25G76OJmuUKQJKO1m+xOKh
|
||
QFKwqtakBDJBNalZAWbJYGG+tBKBsfQ1mbUppiFsGrMbSQ6yHpZWndWTAUCl
|
||
C6wb2ZECTCOfUZ3d50hQzxdxhnEgj+f2qwV6VfFlw+DxF89s9Ej7GtVQLH8D
|
||
d1d/KldhLA1z519rdr6HmfslVdh5BGffImXExSyXfirG7Ei/NYDyoD3tnHu1
|
||
PMKWttcP261qhn9o4xddk/zqSxzb13TJdeBRDhM0bKzqQVsao/C1orQjhcmQ
|
||
j7E2ujTF3i0hKPYmqtzDquJ5XMCdSBZU46NE8oKOB7FNUSoPIhrydTxoikRg
|
||
3ZJTpaVlA10EfAhkGZGcE8kLpNG1hggekNNPDofr19w6qG3BBf4G63qwDkY0
|
||
RmOGdcRaSwHtOciNBCi/CL4mew7lYGt+dFnzOsXTaSHFDvX5ife8kweNK9PC
|
||
vLg5yhl5enCwp36RqzkS1fAMy6HVk6gr/i6eUAGbuEjMPERyovAsRmscEk1p
|
||
gJ7y1/ImdvPW/KZ6Fgmgi2SFcz0Rrz2Adt+jPEGndDzKgshlgNanpRo82GKK
|
||
ZffRWgAcnNqq24mpFCkVKSay5gXF5WPfhVgfCCeUSARxXhY0tOY4VJhRXUkv
|
||
P3Igb6z7WMxogfUAs8hYzZON4xVVY4XaN9DYma7YrHjPZPpQ4lSwCMgPGy9w
|
||
FlislORp1ifio7/ESpuHVGkTv3yDapymsTlVODHnYGG+U2MyYoNXqlOrcchs
|
||
Gh+tza+4qyIHXt1x60fuJM82X7fzrBRYYqtQVerZUcJLGB6Shq0YgFHkNSSc
|
||
UAFQRiGpRosjMS7JCiSTqEwqWmkt9Ak7X9vmI6b7B7BmxM5Aex9ov2micuin
|
||
psmk4rFfGdhxjdPFoRxTXIp3PDqDtWTEpfExT+W1ZnMM6pbIHaoXG1veSZ6n
|
||
0vI7UhceHe1JWavrQ3Zfmpr7HmhxNB2Bwer0drAVpMi4XMU2hJtJCN1wEJDw
|
||
yqMVT0IQTP8HQ0yr5sOB6J6ar2awCAuYV+kMT5WLp0W6MHuw/W3xOE4paMrD
|
||
cX0vncCrOxx2sdZcyvYrqkhJNaDVae7aKd3at1LbFgkltg9NK3GIStwZm2Fh
|
||
H6/zO7S8YvFhTgPgQoqtd8lENhYjSaLFaPnAVrsVZJvkkdvrXlMyNJDL1ycD
|
||
Y04Tmhy7xehMvqCdxCC+W75Xi/cecntIp3MqXT9cqTME+X+mEkaL8IIbu8Ka
|
||
t+xy+SDW3kNr7WWOBJRIBokcS3BExTu/cJ1wZoaMMh7RCi3R0kAQ/9htuWm3
|
||
gLA2/+QCwhXWfw+oRW17KeHWzsK8Vtvi1YGcQK3NwC2d0yMJ60kqSRuUGeSN
|
||
WgKf03TYfdEW00FiJq9eO5N1wi45myTwAy0k6nZCVQPwEoVCM6hiP6ll7ma0
|
||
BpFXR0yyBoOQ9DwllO5W28wZ/g7uI8l0HaU8kAOaQApqFcvSWahqeWLZ0UVv
|
||
QQXCXMnlKijjzV63vq3mJ1jihjz5aaC6pNr5+olLblAiuSmkJpu8TNzOxMtr
|
||
wS1msrpcJiBa4l0q87k0ShFNul2609pgqptFTMlaYjlXKx4689RrwhXDAb6w
|
||
Z+6b08BfSYX2SRmXf6diQM1aik5lbwkLNL4QXuOIA7hkMp+p4i0s+YbSlUDy
|
||
ZfKK5TOg5/2g1jpblWttButjodebdtspsgD1rpiBFMa59PD2OUiHeHewdEYp
|
||
0gAbzxxSOy5yyi/mnGQT0yNikimcZgyJUwn9Y4mL9BfsDA+7BF5sqz3ZygC5
|
||
vygysOYLfh2VjUWMYfRw1f4dWB371ckiMUPjCJmfR9SxlV6iljUgQbO5mK2r
|
||
ROZZkGYv3Bz0MlNjHx6spLqYEZ1tWyZ3EieqLy0b4XwsNbcH9IW1gD7H5emk
|
||
jZutjfTLWkyaNPxYATkJQuFyfRuO4Pa6pClYkXf6cbm7keZ47Gzj2FUCjt0X
|
||
xlhTmFmcZdqTljREak7MKGsgJRK6ye9zI6Y17FnyLF1xuVJx7RtPbJZrgclq
|
||
zSLMNonQ5gJJcGslVejNF4EwCevc09kw7b3R69gpYYDBsM5MTrQIpuM45RDc
|
||
zoOcQhFnm0D0v+0ztFQ58CoaPFDNIOyWVK0wWYXP2gr39jhD9r6ES0oWuGld
|
||
hbuCezJpE6oYirEtQn7clNrApNTiUtoqL6Bw6xRMo7ofi3RcxKx7wpimsqCJ
|
||
vTDN3lo3xlh4wT2xD0knRip3y6q64KGKBtxDo9ZpvaxlkR9Ebj46XDzbN106
|
||
5ThduFkL15o8bmkDbayA5WToUeAv68wkXZlcq3Jkor/dhCwxUwJf0VakcgLo
|
||
NGLLoU7qJOxTTd/E1Lqlmr6B2/WErbXojdX0KgSVZh9uErcwQNPma4sO27Bc
|
||
2Z0QVTad0X4Ct/OgV+BYTMZcHI6sDLGNh6AyoFwk2as2q4Z3dOs54gC3I8rJ
|
||
NGNWsw39nFh4rsKT3xCokFdH1MqcGy1LCG+VS4EeGVbl6dZ+59rtPHDawqLw
|
||
uqYKvVXiRge31bnEAGAbkHKWTrESyLmBqq+603omiS2MH+HyCmNtG0jrcG3x
|
||
Rs8BFpseb1dvLkl4xH+B/2Y8SanlNSho1oCfiskHUq0JM0O0cBMeej7JQQf6
|
||
fBodD9Kkuok4HbjcKyP99suXfmAWag2CqW0l79ZQDDmr/IwT7y1/KaUrwP4e
|
||
hroYH2bGtqSMg9rRnZmBDDhOWcQ1Dk5B5ymgZAbLAyhzWTkWGRWv2fDx5nKH
|
||
4NK1iybo9kZKWYBoJ2gP+BhRxyExvIknGJjFzofzq7DLNfhNAI0dI6coOK7t
|
||
b2qRZNMgNBn9akQ3UUWIUV3XDOP2IjZDX4jYWOvNPqWSQEhdqckVf82iAyMe
|
||
ylnWaCmFFlq5dMoOI7FtUSyhGiLpZgLpmiWBQ2q4WgncJJFgK1N0DL9tMZyg
|
||
zSHAoA06jC01tExDpGhB9kMj6BXYNYubdGHyZMHl3YFfdef5mkucT2NMlqeU
|
||
JZAh5yVpkOd2j04RUU5DI0HidVxMKU7JGMDPKCQQuMfryzNKuEMNyeiljOcM
|
||
NMk9Iuupw9BrPSRB55B2YrZiEL7yfkVdsVGsqcQpz+DvN0UEKcOPXFziq1xL
|
||
JI7N9VVKVMgAie9MUSgMKcJEWXoIUzjVWOjKbnFjOG6w7tV59wpeqKzkFEEq
|
||
EloqJz46XfGMzrPWihWBQ+d9tRDL0LoLs5X8FxtTFQrW1wlaantIfIWk0hBE
|
||
XpGB7ogtr8GhWpsadlugLlQUFJDcK/dhS3HBmrkWUC350bSy9jlh3lYlxDHB
|
||
uZ7bhSRUSHgXW7EM61uABMoG5VjsjZZcMJQ3IvttVONyIApAOeMbSNdMBCa+
|
||
go5yI+AnPpo0laS21KcgfCj5qU1X+tDU3Ufhe1ORa5tpRJwnahXdYhQNW42i
|
||
5LnBvJjITzA70xNIm4BAPgwPliKVyH2LNZVyYusU4+jv1hWWPRxzWCzg5Ih6
|
||
JLI7R8023DPGNT5srJeGepiQEifaCcgfTBYMDFcIsiITND+mYovUI415Nt3q
|
||
bUqCUPd1FRs/FxzhJwx+ADIbcGzypxS0LlQBhktOZsIBMRUAWGmBtVeFUCIA
|
||
Ti73Dp5hiUW4DYFzGx4sXhk2i1cGW4tXNuqTc082LVYp1SnR/Skl0jFr2RSn
|
||
bMqKgsZYr3oTkm2EVAC6e8xXD89PmemifK31fGy/RAIxWmdLbbBYowa2XqTT
|
||
6oI8b1tOxhR+vIvZagukBBgaEhxsLJgJMaRkcOtokU+pfaMghAlPDg/RgxNP
|
||
Nib1QvzONn65S6pFn0OhegzTennmQXBkewL4BffpUlBxeL6GvCxb2PmX9XSm
|
||
aYP38flNNpkXeUYhabi6UHcuLrK3V+c9t+sy1yKNH+5cENzTuSBgUlAzVXmJ
|
||
ioSwstVyFTstiNh9rFy+HjvubYLyn4U5YE5JOpsnUngs8FeLWORML2ZEl/vb
|
||
euXKQDUEW2w3ChGyebZ0crCWWnmfE1MoY8O6ROrzIjXClli5RCUuCV911eJu
|
||
q+MNRwkhpa63f0FEwWelal3QutJaoTZQ1025Nu28ysy41iYM+5dhvVbsMXxk
|
||
GiWoKZROallrr0BWkwWWKm70pCUUDyRBOvEamWGB6O14bU0K3NSEG5qQBdrW
|
||
xguxhbf45VExMzV3GV1Iv0Hjf7M9g6mhVVGGKnedLzieDFEWjos5vfTgEUPC
|
||
Y/u1kk03cJrAAgOkPrDOJXReREHT7eia3wQHIbdqZZsWSCs5pcTWWgSTSesJ
|
||
y+aTZsQJsjd0Bp9IxLcaTOUwM2pGxD05uEYYiTOHrt6FVqcuubD6bLxhKldT
|
||
r1RyxLfdrOoVn2nXurJ6Ti05SrEwAXBkozc2YMc1nq8reIbWgeGZ/ZpbqSdp
|
||
DFti9v2Ek8cQbCc4AnahDMIpbMdQYmc7N33HAtq2absmOHfFCCEiuO/ADdWP
|
||
jxUFbPtGwhDbiLFH4qVIQI7kgWYXY690UZfKCJO6loNWmmA3WWv5NY8vFgkv
|
||
Xx02+AZIeCrSiI1dGgPZInzd89PTnsWrM6eROHUCqzcX3yo5eG3M3Rm0Y5yi
|
||
6iCQi6euUDbjPbrrekds0BprV2uxTpIE1sCOs9karSku3srcVGrHm9Z29V41
|
||
nRLO8IFtzK6FgVg8FZrf3l6dp+p+/ux+a298MFV3AzMcagiAIm3G0riqV1zt
|
||
lZO4ODF/wV2rsT26BqRw9C62FVhiujOSRhQojdGaqp3Qyk0Qbj9At2KKZJ8y
|
||
Sfy28ybQnGSBSooY1huL140UffcUGQ6UdOoc40Oxzf65gqaeUO3QoHHCmH4a
|
||
czywt7SkcLpgU/O69uORy82FYNSq6qIwCHQfsaiLbecGIonEEdiCCOIckqIr
|
||
eOsPqUmD+u3UuGDsK25wgmuBiem1SDRW+B4EJ47V4J4yNlvBaFCcEypZr5ql
|
||
FZO7YjnYdmU1bBAYLlEysgxUZMUnYIgKpmVkpHCxjx1Oqi0SC4DBq/VCiSiu
|
||
yqWiXd8ZL9EGQjWFPPSChilKO0suNlb/EWWUTTTWMs+gC9S9ihUfqdaMwglv
|
||
SpYw+RdFk6ucsKBO+vd4XQWcO6jj6UpdVqC1mKiVhXpkDCwOpT1Hk+/cKH0H
|
||
FUoo/3gT/gNINzvwOMNaFxz4B6s2bjUF6x1zTElu58PASJ5SDcznw9+xZQSX
|
||
1yiOx66/wKvR+iQ8PXx72CaTYKJ7HF5tVgkCIeUIXA47S20hC5t1XTgPqUXE
|
||
BrgS50NVNgk0fMVOUHb07U3NO42LA0ZOq8Ce8aNgpM0CeTGX63HlfulX8QyC
|
||
C1MLSct1lvgY1uYMgndS+K31y5OMK0zUIn7xgRfjtPrOKXYUhz98kHgu+e3S
|
||
KbsuDQFAlvBaAvSlziu9YVK+AHCNlryCnpQZ1uzK6/XjvWwPU8ZFXybMR7ZE
|
||
PpuYZ604oyeMhgXEbeIZIkk2R2eYna/VI+rVq8EHPKwJgkN7iGJi54BBjE8w
|
||
qILvNR+0HlUbgUiKUTpxGnoY5UIi6ddisJHmuQAyvUNuJjG2NLaUx+EXuJSz
|
||
eAZTsEWnW/Zk02H4Kl04OpX7zRnOUuVAjG7wGcJUPFL7TMACHedYL1HSNmF2
|
||
OVPnCRPum3VBjLO2pqN5gYH7gItvkyzDclyAWOjA+h+Z/j7Aqr2nSgjW6I6i
|
||
N9+dnb17izeEHbwEYDTC6AO8vkPiTFumCoIj4OPCR4iv0ZOnJ1eviIa4zbip
|
||
rbZHSrArN30XubTjy2+kMF7nbaUxrzcoOOOJUy9wEAjJF0nOvi6urifreouu
|
||
WVncphO0UiF+UilNo4sx3D7quIBfwqwAH8L0y1qdOd5V40r0QXN0e5RzRxOk
|
||
K2zOr0OOJc3fBXISLJxmVC2jQyrwh2QsXVd4+oco9K/8HMNRfzm2Yjp+xqhy
|
||
ZFAFPrswMvqvwa+jKIpG9Lfz4wi+AKo+hYdNasqpLavxKyEb/FMrRYXjmQwa
|
||
+JoV3h1KMyFucu+LQGXhG+lqxu1tHd3h/lcBs35V/Rh78W5ZLXPuxru2fOav
|
||
9T6RACyqVfmIQTS30Q5yop9ol/OHhlFdF58jwY90ydfyib5JyqQJpfJHUPUY
|
||
HnzHAuNXD9GaY4mo5GYyvlrEM3fAVoWsbThSYGqDXeinjxgOycqv5PpgY9o7
|
||
Njl56FE3BcGLmIRF+ZTyoeZgbbnrlHUl9r46RvzIcqvSLSALcJSRopASh02D
|
||
MNhABWmOsn3wTmAuPnvd22hEF9be64SzIl+vuJSalRdV+QYVxaOEVjKjQnL/
|
||
cvHq6MVw7xllS3E2RUpKm/EVCd0yy4mpleSvvE4A9+9GbUwBlV9b7FzUpQ/1
|
||
g4cukIl0ahuFa8g+eJVbavAiLbuL2YvDeoX6H+4fzWKdiyJuqdgt5w/IA4AJ
|
||
OWcfFSKWuJAYw6AsDSXTP3XIWSu4yiEjHzRwXmlO+/NXGpoDJzqZpxgohEaN
|
||
RiwOfgtboQZZNoYn+NogHqNooVHexK1Qg0w+m/WK+iOgbG5UPax7hBEeGhQD
|
||
ssQdqNEdDNhNxRtHMui/iW2Q6smmleei1jSkj8kGHoMZFolXLqxDAS2Yu2HH
|
||
gzurQzrhLug+C0xlEngA7uEsEcNKQnVplraGEVBVbIQd+ebgwERESyBgXZb2
|
||
6ji8Qzkw3Bvsyo0/+TThC6YBlB2y+xH9aj9mCnt68ezbp3AE0+QGM5Doxa0j
|
||
mwNFcxjfeooENJN1DzFdsmfriuNXDhVVSiEWQscwqVmPGffEIGqmrhCvLXEc
|
||
YILhTLy9mP4+CvXQMZAP62Ggx3weL26QQMFXy0EHo8/wcMkBLD6Dco0u0nRC
|
||
IQ5oj0mWFOIY87Cm7xPJ4otNgKWwQQrpUrICr11cGrY3NIb+lBVlUMhO6MEe
|
||
5mbJJko/Bit0tuNa4ij6wxbYCDhZt6Bw1ixv1BntKx6aSiBUoNhLgLOh6GRE
|
||
0shSOgSqIyBRKGapwRh9YnMEVvcmziIYpxdy9MFtUsyIbtMXadazeVdovQts
|
||
QAtmRRwffj8wEbNusqvmpGGB5TSbVFplHmVWx3itVZ04UnOHNk+qm/FeYxAL
|
||
E0nbMMyilxSPq+5Ig8NS3ZJSABpcPsO1jORxNfAQSjk2QESjfqeFOGAC4hTO
|
||
u4/oTp+QOaivDZ8NhQjUHzPosL/cqRxD96xsv6V8G5tPu1Q1x5VGTi2aiD3z
|
||
oLOgpyKm+Dcf7VTvloqtJqVqwv2UEJ35ll59yiKmAx2Q967vjFEfiNd6ueb+
|
||
8OyejSNrDsFsHkxn1IHFVGDb3oiTh53ItFrH/iLu2TIppY2zF3NJmjisM2K0
|
||
5fPg1F4T3mQXW8dEtfRzDBLdcb7ao5Zt4O3njKY5Xjt7Ich3toRbwDETtgIy
|
||
VbaSfCsDVbgkJYrflL0sznzKAr9DT3ESL5WBYrcdpC+mJaaJUjYbMr70gNsM
|
||
2jVxFyW4BmMucMabQ783uwpHnEPTfiQUKm2OhLKp8dCNLbiBgRr44zaOkzV+
|
||
F4T1WQD+d7GUguOR1xmzlamxjbrZ4KdVndxJSOwM1oG+G6BjGGzZjNHB1Dv8
|
||
fKtDlPOusUq3b4Uiy5pRHqQipbBeU9Q66PK923bl0HvCybnodELbkSQNuQG5
|
||
4cRGCITdjkxyPak+dXoUpuguztqXYT1e2LzSVGrI2iQQsSmTQl6JYoMIbq6z
|
||
pQx1jqSkoduR5i2MH2npEEQKf6SC2OFffYYLkCrCn4DlsTylRlkhrMHWUGOY
|
||
jUwBRFFN8FJfMqaZr3NUQXjOtSvO94TKylH/h1vjEc2ImjPZo1zdQJvN8nYk
|
||
VR5wbCPd7hxSx852ByjEf2UrlLFYq12O1IcZKgqjnaqaC5kMWLKacgGK++Vg
|
||
dCihfh5hlDlIOjgUJw/mkdbTMGv8jnKXlym6MRtR6XQ8zG/9NAbuDmNtoxLM
|
||
5/Q3uBJDbPcdwP2KWleCxNbbwpzcZ2B/785P3l6dvDk5O7m6+ElVA1mk20RB
|
||
rL2Blk1UDUCyVp1ijtNkvOYyZ5RRlmfosWFoU0gGB+UgdEsk/GgjxriECjsY
|
||
38WbcmRVhkYKZiDeIsC2iJDvvjyy78xAAUflR5xLjtE2XMIcnQwmyq6U57WV
|
||
tB+MFFBi3Xe0p3bvVb26rucfd73FHkj88yBPGnJTjldcbKxVeBpImj1Q/Ip4
|
||
o9bf1LIwFGzbbAthuuOZDtPqLsP36mectFIh/iZoP3SmGr4DjsHS6BcwCCSN
|
||
ceOEFvggoKmaBfklJolT6ySitiiShZP59RJjvljAwJ25V4RTO7fIay+RlhiA
|
||
jO0odVy3TVp0O9wHJfD7oPgCs+ppxMg1ma5SmrWMyR0ckK6a5Vg/SL2qjTYl
|
||
emxy1MZhHtzTL6UlIMepeQSc19muJLKQHhK6jVJ4/7ZIKRudAtsaJfRIZqPz
|
||
jRTvuTw6vboKu5drCqY9ojlNK48+80OSDSabvnDIdVltoWNIuHnAbRaPcpJW
|
||
VeR+62jNcU11N8XaKrOKynq26MxLXjfByil7ypTEXbyKWQDIS74H6NTg+pK0
|
||
sYDSQldV6V5E3UyioTp0+f1bKJmpVEkw7LbY8lWRp4KXGDvDSXHOVXHraZsr
|
||
SAfHC2hZsVZFiG01bco6d0LbiOe5AHLgiEnJBK1B8Ir4MJXZ63N6sTWZLEFI
|
||
xELYnNNv69WRcM0CGSW8cmCJaT2PsWfCzsOaejfesBLIRtfA0eyMqEP59MSE
|
||
FjZsvtZvnICNiUhiPtFMw3Z4cehrGzoM2ICseZkm9sKGXJgUfxQO4MZh3JoV
|
||
KingLexiFB3u22dPRpsPkRJUeYT1wzyMtbYEGoJXr4jYc3ztvOFYFJk5ZjAE
|
||
DgJJATA3TtQYjwiZuzWXTi+gsq8kttGstm+LtgxAi/Acp2yDW+DyAkAgWbMb
|
||
5ErWBiyubNL3Hbbw4emRJKTTNT6C/bBotYUdbH/eKZImbod4jCqitGc0MVyq
|
||
OPQ1fkV87z2973acZked/CbQ+qpdQtk5kXdqA+XbKxoZfL2BWs0Ik9bU8fVq
|
||
B6WcmCMknNgJ4T59iQc3baiIQNmOQCTmiK2HY1387lbfS7m2rXZsCp0ERPbf
|
||
a3/8kMMl2WOB6yMd2Z8QI4vw0kgrrSNOdIJ9Cq9r78ftxPX2OU1a2l1jeGw/
|
||
vKdft40QMoNRcC6/XgvQpQoX7TWvjII0oC5dSDecel/3l0Kg1FYtakDdv7DY
|
||
gV5YzNvrUnoNIdFySVEKvQF15JJukl6mj80Z8qsZgHiG7bW2tPXuClck6w7e
|
||
u34zopihwiUtjLgJKzkwTc+0Ten2ekR+vOCF7kjCqlrxJvI6qoEINAL4Utep
|
||
inVK4CHfqfjGQut4I9I7mi6ORVzis3D6e40QGJSDtV2GkuLu4VhawGKkmUTq
|
||
49CNRnQYBMNx/d6CbDEVDfNuyzohQOG4rzfjIp2Owtd5ZeQ04qgq+vXRwjpl
|
||
6eiWvjPiK0ZBaR4qwloOnCLKa1FsW8DN2NaeoCT1MrfkhgVhPTuMoOSh2uiB
|
||
NDCb92USwtCARFG0VnMql0gKyOrBWV82sonyfMlj4ZHEEVLyCHTfRcrZP7pu
|
||
SteljnkrirRhewSeOkaa1Dd8EA13lyjpUYtJAbjvH7IxVrxJN84yJQqAl53s
|
||
2DgLlqaKJXcQD6weTNZ+TPXw1pjMCJIkiCUoGhU4mFeYKhxB94d3lyeSPEAa
|
||
C4vJEmvl1d4ASsy1Ofzg/7RlDXAh8myGqhEWOV4jHk5b8mNQb3eXizHc0n9d
|
||
qJdJskKHla0dgpm0lKxEMo8LpwF7X42ebgv7w51crdC+sVXZcAqNijqwXMZo
|
||
WSuppJDRzLwa8W5/BaItt/AKJhEXbZ3SjDqAeVbcKpOyFqljDM5Mytp3gFjz
|
||
NLnluEozvGYVB07Yb414LJOYmwuZFnktXfF+VQBxDMCFLY6PgRpwh490g/RA
|
||
YN3//BcMgA1m9obh0asLjP+pwuEQPe5uDzcrs7tNRtSg0TcV5rvav6SH4Qge
|
||
BXa5GZsOLQPgIGi/Wr+rrnj9pHDFJ+/Ds+MLmONRLUu62uKkxyBp2D2coOPD
|
||
04g77WG9Mg0L0FBVM/nhKUZXYa+AQTjcI2g91M/E72bya6NBgc+v6n0KWife
|
||
h2G4c5ntVmKm3Zg57m11ck+jE5zyLH11egyQQ1A79m8FGFFr9PLepiUb0rhn
|
||
FO65BupaZ6JmAyAdE6fFhg4OdNs6N7DYZiZqIlHZ6PngopQbHeJcbtOI6R6a
|
||
w42Epfz8Fpb7xDwQDlW4Ca/u8ohz2ExHmHaxWiqtS9noUqSE0HReZec0R4Vk
|
||
09IxU2mN9BEniyM/kGDUejsHEFCxND9JBlzdH1gxfuKHk/NXH7kVAkm8URyB
|
||
7Bnt7e49i3b3tHQ/TXeu7bzv7xwhJoUBUEPpAkEBcWZ77c0jHvdWvX9E8y2R
|
||
W/JGA4ndZ/vDRgMJ+PD51zaQ2B16DSTGw8keNpGIqIsENoyIxpNpEt3s2hYS
|
||
zQYSNwmIp9eYs4upRLhVr3eE3xVikRIRpMeuOdnj67pDmDQ/hN08jgApRtn+
|
||
+C+zn+ZnNx8+xG+if8w+/Vj85VX87vrqU1kc7Z+Wuz8Oy1fj47uj2YwHMcmB
|
||
ziBvjuLdeO+X60/59cFy9/2L11cvX759+fbozV9ffpw9j2bRT6sk/f6H5cGz
|
||
fYNKWuffc9ECfvVVGcEwo757PRy7P14NNkdqxAtWeZYKjl+PmTVseRgpay/c
|
||
h4/3tjNBbHzWho3PvhYb934HbDSNE7g9wVe3MRn6bUykyYHTotN0XngAWxVH
|
||
rsiyjcHByAtq3QIHg0G0Sy0Dm7eo1rhPHt0Lu7UtcltMl5DvjVr7/JKcqK1D
|
||
D6XH51Z7CS44IsPotobAtsjknduXIIhtExFtCZxNa50stcUo5g8hixh63XFN
|
||
t9X7L0GtyyijNYqdkfadbL8Lj32vfiVa38OUEWx99xuJdDwc702eAiIiGuBf
|
||
u/Yv+eMTab4UNwdR/Gz8PMKmPhHcipvIuRXD5rXY1pFyO6lu7Sr8/xyFJuTa
|
||
8xsdozD3TyCYf+CPwi3/lUehFWqkUbHGGqktmLW324JZL3a/FrP2fgfMqvcv
|
||
9Snuo9C71jiq0Tr6sZQWz/opKFGW/njNpH/DWTdO4VHH3XjrUSdOynjbWbcx
|
||
1xfPvvasn/4OZ93sQ/vVp73nn/aWvtxfc+L79Rbdv+GcHdg/6oSd5x8427bW
|
||
1y2H/HTYcsjfDr/2kPd/h0NubyP81Qdd6wfX0ur8McykjQ9cbIY/3bzLP+z9
|
||
dXV0cPaPF68/fv9fbz89nb759vZlvF++/+Xkefrv1e7d+X9MfEw5CLut/dON
|
||
MPS1yLP9cB/Aou0vPoBOD0niBy14dDD8ajw6+B3wqNZk+qsRaN9HoC3N6f+p
|
||
joKPPhX0Ro/Cz+ya8+oCwmYCbjK2nWSgNWfnH3GkZQCjYYfewUZiX7bqCU73
|
||
O9vjjiT5EdlWpcYGFk+fYM5TzSTer/s39blQmnL09Qc7Al1S1km3tJ6/p4G1
|
||
qTNjsyFSSV44MAG82sLAOOhv0zi4r9oitTtq1Zge2WTd6k0PdFqXBx/Tbl0e
|
||
fWzPdXl8e+P1n8WckJGFWwI46j3n05JD1rF4RVJsTDsRx8PJlUgXC8f/i9m5
|
||
j7vA5J/ngBEcm/uFqy3cac/4QAv3wBShJ6WTvRuCLxicwF2ctLC9OEZ9A28g
|
||
AyjuzbRFjtFwn45s9zuT681j/ZCnW4MArJ5KzjFMAuEw4pa+d3ILqIwnlwqv
|
||
db9r1+O5Bza1iSYsCJ0/f0eUcD9o4GjoYWLQ5QJ2+qfLp+P4fnr48SKFGwBI
|
||
sGlMuFObsIG+XuPmnsMq8Vs0lK4eZyht6ZdrDOeP7rBbe+O3N9hFoblN9X7h
|
||
q943wwTuxYR40P5j5Knf1mDXg7HHBZmduMvYu09Pqz37dJvcBY/6MjY19m1p
|
||
x/0VFiynn5HEldzlpp+f16aVIoScruSEwhq0bVDVrzzqt3Hd3sz9SXg4+Zjl
|
||
d3jsHCKx1avKDh6KkZYOu5zGiiQAV0Pp0JpNlhZOjmm8CCh6M2/pLoUEQixj
|
||
3DrU7a4mqWUmrSy/aWbZmoSMbGq/PC9yeFYyv5wM2PCBDNhG6ZRAS6ekpWTF
|
||
Bv8HsdE69JohAQA=
|
||
|
||
-->
|
||
|
||
</rfc>
|
||
|