Christian Nennemann
1385ec8af1
Remove all companion draft (ect-pol) references, regulatory compliance mappings, pre-defined extension keys, witness concept, pseudocode blocks, implementation guidance appendix, and redundant examples. Keep only the core token format, DAG validation, verification procedure, and one cross-organization use case. Draft reduced from ~40 pages to 27 pages. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2011 lines
88 KiB
XML
2011 lines
88 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-ect-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
|
||
<front>
|
||
<title abbrev="WIMSE Execution Context">Execution Context Tokens for Distributed Agentic Workflows</title>
|
||
|
||
<author fullname="Christian Nennemann">
|
||
<organization>Independent Researcher</organization>
|
||
<address>
|
||
<email>ietf@nennemann.de</email>
|
||
</address>
|
||
</author>
|
||
|
||
<date year="2026" month="February" day="25"/>
|
||
|
||
<area>Security</area>
|
||
<workgroup>WIMSE</workgroup>
|
||
<keyword>execution context</keyword> <keyword>workload identity</keyword> <keyword>agentic workflows</keyword> <keyword>audit trail</keyword>
|
||
|
||
<abstract>
|
||
|
||
|
||
<?line 53?>
|
||
|
||
<t>This document defines Execution Context Tokens (ECTs), an extension
|
||
to the Workload Identity in Multi System Environments (WIMSE)
|
||
architecture for distributed agentic workflows. ECTs provide
|
||
signed, structured records of task execution order across
|
||
agent-to-agent communication. By extending WIMSE Workload Identity
|
||
Tokens with execution context claims in JSON Web Token (JWT)
|
||
format, this specification enables systems to maintain structured
|
||
audit trails of agent execution. ECTs use a directed acyclic
|
||
graph (DAG) structure to represent task dependencies 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.</t>
|
||
|
||
|
||
|
||
</abstract>
|
||
|
||
|
||
|
||
</front>
|
||
|
||
<middle>
|
||
|
||
|
||
<?line 69?>
|
||
|
||
<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 or in what order.</t>
|
||
|
||
<t>Regulated environments increasingly deploy autonomous agents that
|
||
coordinate across organizational boundaries. Domains such as
|
||
healthcare, finance, and logistics require structured, auditable
|
||
records of automated decision-making and execution.</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 and in what order.</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, producing Output Z."</t>
|
||
<t>No standard mechanism exists to cryptographically order and
|
||
link task execution across a multi-agent workflow.</t>
|
||
<t>No mechanism exists to reconstruct the complete execution
|
||
history of a distributed workflow for audit purposes.</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>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>
|
||
<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.</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 audit and verification.</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>
|
||
</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>Maintaining structured execution records</t>
|
||
<t>Linking actions to their predecessors with cryptographic assurance</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, |
|
||
| inputs/outputs hashed" |
|
||
+--------------------------------------------------+
|
||
|
|
||
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 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"/>. ECTs <bcp14>MUST</bcp14> use
|
||
JWS Compact Serialization (the base64url-encoded
|
||
<spanx style="verb">header.payload.signature</spanx> format) so that they can be carried in
|
||
a single HTTP header value.</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>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. Parent ECTs may have passed their own
|
||
"exp" time; ECT expiration applies to the verification window
|
||
of the ECT itself, not to its validity as a parent reference
|
||
in the ECT store.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</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="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>Extension keys for domain-specific use cases <bcp14>MAY</bcp14> be defined in
|
||
future documents.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="complete-ect-example"><name>Complete ECT Example</name>
|
||
|
||
<t>The following is a complete ECT payload example:</t>
|
||
|
||
<figure title="Complete ECT Payload Example" anchor="fig-full-ect"><sourcecode type="json"><![CDATA[
|
||
{
|
||
"iss": "spiffe://example.com/agent/clinical",
|
||
"aud": "spiffe://example.com/agent/safety",
|
||
"iat": 1772064150,
|
||
"exp": 1772064750,
|
||
"jti": "550e8400-e29b-41d4-a716-446655440001",
|
||
|
||
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
|
||
"exec_act": "recommend_treatment",
|
||
"par": [],
|
||
|
||
"inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
||
"out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564"
|
||
}
|
||
]]></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>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>
|
||
|
||
<t>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.</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>Perform DAG validation per <xref target="dag-validation"/>.</t>
|
||
<t>If all checks pass and an audit ledger is deployed, the ECT
|
||
<bcp14>SHOULD</bcp14> be appended to the ledger.</t>
|
||
</list></t>
|
||
|
||
<t>If any verification step fails, the ECT <bcp14>MUST</bcp14> be rejected and the
|
||
failure <bcp14>MUST</bcp14> be logged for audit purposes. Error messages
|
||
<bcp14>SHOULD NOT</bcp14> reveal whether specific parent task IDs exist in the
|
||
ECT store, to prevent information disclosure.</t>
|
||
|
||
<t>When ECT verification fails during HTTP request processing, the
|
||
receiving agent <bcp14>SHOULD</bcp14> respond with HTTP 403 (Forbidden) if the
|
||
WIT is valid but the ECT is invalid, and HTTP 401
|
||
(Unauthorized) if the ECT signature verification fails. The
|
||
response body <bcp14>SHOULD</bcp14> include a generic error indicator without
|
||
revealing which specific verification step failed. The receiving
|
||
agent <bcp14>MUST NOT</bcp14> process the requested action when ECT verification
|
||
fails.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<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="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., claiming an action was performed when it was not).</t>
|
||
|
||
<t>ECTs do not independently verify that:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>The claimed execution actually occurred as described</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 and the integrity of the broader deployment
|
||
environment.</t>
|
||
|
||
</section>
|
||
<section anchor="organizational-prerequisites"><name>Organizational Prerequisites</name>
|
||
|
||
<t>ECTs operate within a broader trust framework. The guarantees
|
||
provided by ECTs are only meaningful when the following
|
||
organizational controls are in place:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Key management governance: Controls over who provisions agent
|
||
keys and how keys are protected.</t>
|
||
<t>Ledger integrity governance: The ledger is maintained by an
|
||
entity independent of the workflow agents.</t>
|
||
<t>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.</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>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>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.
|
||
Extension keys in "ext" (<xref target="extension-claims"/>) deserve particular
|
||
attention: human-readable values risk exposing sensitive operational
|
||
details. See <xref target="extension-claims"/> for guidance on using
|
||
structured identifiers.</t>
|
||
|
||
</section>
|
||
<section anchor="storage-and-access-control"><name>Storage and Access Control</name>
|
||
|
||
<t>ECTs stored in audit ledgers <bcp14>SHOULD</bcp14> be access-controlled so that
|
||
only authorized auditors can read them. Implementations <bcp14>SHOULD</bcp14>
|
||
consider encryption at rest for ledger storage. ECTs provide
|
||
structural records of execution ordering; they are not intended
|
||
for public disclosure.</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>
|
||
<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 agentic workflows requiring execution
|
||
context tracing and audit trails.</t>
|
||
</dd>
|
||
<dt>Additional information:</dt>
|
||
<dd>
|
||
<t>Magic number(s): none
|
||
File extension(s): none
|
||
Macintosh file type code(s): none</t>
|
||
</dd>
|
||
<dt>Person and email address to contact for further information:</dt>
|
||
<dd>
|
||
<t>Christian Nennemann, ietf@nennemann.de</t>
|
||
</dd>
|
||
<dt>Intended usage:</dt>
|
||
<dd>
|
||
<t>COMMON</t>
|
||
</dd>
|
||
<dt>Restrictions on usage:</dt>
|
||
<dd>
|
||
<t>none</t>
|
||
</dd>
|
||
<dt>Author:</dt>
|
||
<dd>
|
||
<t>Christian Nennemann</t>
|
||
</dd>
|
||
<dt>Change controller:</dt>
|
||
<dd>
|
||
<t>IETF</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="header-registration"><name>HTTP Header Field Registration</name>
|
||
|
||
<t>This document requests registration of the following header field
|
||
in the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
|
||
maintained by IANA:</t>
|
||
|
||
<dl>
|
||
<dt>Field name:</dt>
|
||
<dd>
|
||
<t>Execution-Context</t>
|
||
</dd>
|
||
<dt>Status:</dt>
|
||
<dd>
|
||
<t>permanent</t>
|
||
</dd>
|
||
<dt>Specification document:</dt>
|
||
<dd>
|
||
<t>This document, <xref target="http-header"/></t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="claims-registration"><name>JWT Claims Registration</name>
|
||
|
||
<t>This document requests registration of the following claims in
|
||
the "JSON Web Token Claims" registry maintained by IANA:</t>
|
||
|
||
<texttable title="JWT Claims Registrations" anchor="_table-claims">
|
||
<ttcol align='center'>Claim Name</ttcol>
|
||
<ttcol align='left'>Claim Description</ttcol>
|
||
<ttcol align='center'>Change Controller</ttcol>
|
||
<ttcol align='center'>Reference</ttcol>
|
||
<c>wid</c>
|
||
<c>Workflow Identifier</c>
|
||
<c>IETF</c>
|
||
<c><xref target="exec-claims"/></c>
|
||
<c>exec_act</c>
|
||
<c>Action/Task Type</c>
|
||
<c>IETF</c>
|
||
<c><xref target="exec-claims"/></c>
|
||
<c>par</c>
|
||
<c>Parent Task Identifiers</c>
|
||
<c>IETF</c>
|
||
<c><xref target="exec-claims"/></c>
|
||
<c>inp_hash</c>
|
||
<c>Input Data Hash</c>
|
||
<c>IETF</c>
|
||
<c><xref target="data-integrity-claims"/></c>
|
||
<c>out_hash</c>
|
||
<c>Output Data Hash</c>
|
||
<c>IETF</c>
|
||
<c><xref target="data-integrity-claims"/></c>
|
||
<c>ext</c>
|
||
<c>Extension Object</c>
|
||
<c>IETF</c>
|
||
<c><xref target="extension-claims"/></c>
|
||
</texttable>
|
||
|
||
</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>
|
||
|
||
|
||
|
||
</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="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 986?>
|
||
|
||
<section numbered="false" anchor="use-cases"><name>Use Cases</name>
|
||
|
||
<t>This section describes a representative use case demonstrating how
|
||
ECTs provide structured execution records.</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 numbered="false" anchor="cross-organization-financial-trading"><name>Cross-Organization Financial Trading</name>
|
||
|
||
<t>In a cross-organization trading workflow, an investment bank's
|
||
agents coordinate with an external credit rating agency. The
|
||
agents operate in separate trust domains with a federation
|
||
relationship. The DAG records that independent assessments from
|
||
both organizations were completed before trade execution.</t>
|
||
|
||
<figure title="Cross-Organization Trading Workflow" anchor="fig-finance"><artwork><![CDATA[
|
||
Trust Domain: bank.example
|
||
Agent A1 (Portfolio Risk):
|
||
jti: task-001 par: []
|
||
iss: spiffe://bank.example/agent/risk
|
||
exec_act: analyze_portfolio_risk
|
||
|
||
Trust Domain: ratings.example (external)
|
||
Agent B1 (Credit Rating):
|
||
jti: task-002 par: []
|
||
iss: spiffe://ratings.example/agent/credit
|
||
exec_act: assess_credit_rating
|
||
|
||
Trust Domain: bank.example
|
||
Agent A2 (Compliance):
|
||
jti: task-003 par: [task-001, task-002]
|
||
iss: spiffe://bank.example/agent/compliance
|
||
exec_act: verify_trade_compliance
|
||
|
||
Agent A3 (Execution):
|
||
jti: task-004 par: [task-003]
|
||
iss: spiffe://bank.example/agent/execution
|
||
exec_act: execute_trade
|
||
]]></artwork></figure>
|
||
|
||
<t>The resulting DAG:</t>
|
||
|
||
<figure title="Cross-Organization DAG" anchor="fig-finance-dag"><artwork><![CDATA[
|
||
task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating)
|
||
[bank.example] [ratings.example]
|
||
\ /
|
||
v v
|
||
task-003 (verify_trade_compliance)
|
||
[bank.example]
|
||
|
|
||
v
|
||
task-004 (execute_trade)
|
||
[bank.example]
|
||
]]></artwork></figure>
|
||
|
||
<t>Task 003 has two parents from different trust domains,
|
||
demonstrating cross-organizational fan-in. The compliance agent
|
||
verifies both parent ECTs — one signed by a local key and one by
|
||
a federated key from the rating agency's trust domain.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<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?" 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 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."</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,
|
||
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"). 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="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 transparent and auditable supply chain records.
|
||
ECTs and SCITT are complementary: the ECT "wid" claim can serve
|
||
as a correlation identifier in SCITT Signed Statements, linking
|
||
an ECT audit trail to a supply chain transparency record.</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:
|
||
H4sIAAAAAAAAA81963bbyLXm/3qKGvpHSwkhW7bkdst9+hxZltvqY1uKJXen
|
||
p5PlgCREog0CDABKZtzOOg8xDzDPMo8yTzJ7f3vXBSApJ5n5MV652CBQl137
|
||
fqskSUybt0V2ZAenH7Pxss2r0p5UZZt9bO1V9SErG3td1fZ53rR1Plq22cQe
|
||
T7Oyzcf2p6r+cF1Ut83ApKNRnd3QID+dvb48tWtDDcw4bbNpVa+ObNNOzKQa
|
||
l+mcZp3U6XWblFlZZvO0LJPbfN5kSTZukwcPTLMczfOmoXHa1YJePju9emHK
|
||
5XyU1UdmQgMeGZrzkUnrLKW5L2nSOm9XA3NLK5vW1XLhVjQwH7IVPZ0cGWsT
|
||
m/n1jWV9eMpfFVU6sfmEN9iu8DTV3d663crT5SRvbVuneWFMumxnVY2h6b/W
|
||
Xi+LQrZ3MqsJcHla2jdui3ijqqdpmf8t5TXQvspJtshKntW+zZosrcezrMaL
|
||
9EleHNk8a6//w0Npb5IZU1b1nL6/yXjety9Ovj7cPwx//Tr89Zvw1yf6128O
|
||
Hz90f93ff8B/PUue7/EsegK8hA2Pm4dNsqirthpXxZExeXndW8Wjw0M38pPH
|
||
3zxykxw83HejlbmbIk8A28SBm9+4vDh78eL0CHt3iIlzzexFXU2WY5zamX5h
|
||
X9QEZj4ZIOnpTVavqjKzOzLM7kDGSetp1h7ZWdsumqP795tFfn2d7eXVfULD
|
||
5n5BiNS0+jRJR9WyvV/RSDd5dnsfAwDV7HVaNBn9+/zi9M3V6avT16dXb3/u
|
||
rvScTvEqK7J51tYre7nIxvl1PsYpb15KRR+07gO/ooY+bO5X9MOm+a0N+MZ/
|
||
EsYmQrWiWk7sGxwGkd18QQheTu2LallOsIL4NJtx3rY45LwlYiPwdg674hkS
|
||
wu6ySQHxpAUrcC9t+z2hU5BDpVdNkhCdjIhv0DvGXM3yxtL2lnNG80l2nZdZ
|
||
s84pHNPZOT25anaHlkiHntIT3kFb2XaWgfGAUD0e5KV9vSza3F6umjab29Py
|
||
Jq+rkqeiocACdk28XeDLJGJqa2S+Zy0vwRK63xCGmiafltlkSOyrXmKIia2z
|
||
MbGUxlbXdLDNh4it0OOstum4rprGCJa3lUCGWM58viwVLWiWZyvZ4YSPS/jn
|
||
2gaNQuU2b2fr3MuOi5RIiqHww+X5G/tTNhIw2p0ffrraNUKkQ4IdHUETY6XN
|
||
ynRU0Dk0gFtjCcLEccqW/hvt1ETsDtuVnfiFOFgtm8ymBFYCDGA6Xo2LfGym
|
||
dbqY2Z3nx9/vhkF5qjpb1MTvaCjAz3HBcU4rSktixLQ9+rjNDDa+BTgeZX46
|
||
u9qlNTAcGU0a4g2Wj40emHk1yQoMOq5Xi7bCmui8F3U+z5lm+MCPbZnd2pdX
|
||
Vxd2lqV8hNd5VkyGxqNpomg6tIzNQOIJcAnEsKhqEB2AkRZVOW0YdbKPLAT8
|
||
6crQzZ5QyDyfTAri5/dIDLSexdG/79nXFS1MaJfI51/G+2vPJD992sDmP392
|
||
ON7Yuhotm9ZLQkg20IVgSzsjoTqdfekIGMruFUNsmxDG/35xtUuAxm4AjIYZ
|
||
7Thj8tC/WidgzNpyY/FDy3ZMZFbd+iU3NlozgT4dz2xFDxw12nFaFHY8IwRv
|
||
Ilxxy038jmgTxj/FJhKhqQg9+AxfVrcZSYvhuvoADMiI59ESy6q16WRC2N4E
|
||
sjHpeEzsuU1HeUHvE1z+s6xueUm3s8ouspoJl+motMJmw1jCesztLKXTSpmx
|
||
0kyEhoQQeAYGRKt7m02XLOAmROkRauTlmHQm3n2xYrIrqhXDrSqrebVshLyJ
|
||
GdBIZlzRWHlJYzgIxspLWtgRJEydg4KeV3NAtlkS3NPGEJyKdjYmDW1ItFSm
|
||
5TgbAj+KaspEMSacy/66JI4RsZuhqFfMmUzEY3mBc+xlQiyMBUIyTz8wuHjA
|
||
wIy2yZpYlFgnSoCEHcmAXetZZQ3emqYLO8ra24yOf8Mxx7Ovn6lOEWGlA/BT
|
||
4chhUbpZOVZ6n84mnygn7J7rcaPzE4PCr0Ir25Wrz5+Hivqq8dI3azKP2F82
|
||
gRAYZfaGQEwngOnBpuubbKKc3ijHIG4/z4iYyryZ82cOxbEvPVicAfh3h/Oa
|
||
tGmWNSMEUxFxO6Ixmm5uL1sCEX/E51hnGa24xhEwpAhneLekENY8bLqghRCJ
|
||
Z42IE4fsujOjYo2Ukf07T8KSEtAnLutPQZQuwg6CH44EooJYHRgnfTSASUTP
|
||
8kaVs/xv2WSAUWlAfO/fEVShRV6xzPvjkAchrs94fL5sSW2z/31vYMxDmuRN
|
||
RVSRMnVNIjgDCthwB6BYnCoexLt4ziIvP/RVEyViOjgWHKqTOAygk3gk826a
|
||
juFSCpmCLEiTWRQZMYaA/TwrnX1Llh5ItqNjuVkgMEWlWCzrRdUABU6dlKxG
|
||
jGtKQDRvVXh+0hmOFUsW7Z8+dVTyIM8EhWUY6HvZaDmdOoYxr8qc1skjyOnj
|
||
7N2nXS0hwlUSXjIvq+Upnzif8PpJOH2RB23TOXHzJLsBNQoD5OckcvEWr84o
|
||
9jLkBDbNmLSzOq+UPi7HZC3g0+PFgtQqBdAWbsf6N8TsFg0bCvauFdXQ7nz6
|
||
xDa3/Ovz5136lrS1SFmDitPR0RTXGBD09SSdJjdpkYupISOcqfbGc4P+A8P1
|
||
vNPrJoQ5NIwwrzx8KCMdl12ljG29k6ugc/GnbFIl8oJ+BCAW2WSa1dAk6+uU
|
||
tIuIKzX8nbyQ+Bf4Y2hb11VRiDQm6WXJKmSEbvwh8EOiENLdJna0kn0B6F45
|
||
6ilPYONu30Az5vmMfon9T7B6RW33Mpn6RJ3ghHSUNStmE4hXS/YqCce8meHE
|
||
1949IRnK85BwLvLrjLXwLH6DdE3ChRt+hegZ3z9nrMnxb9n9B1rRLSTv4PW7
|
||
y6vBUP7fvjnH39+e/uHd2dvT5/z3y5fHr175vxh94/Ll+btXz8Pfwpcn569f
|
||
n755Lh/TU9t5ZAavj38eCI0Mzi+uzs7fHL8aMNNvO3ieiglBggpHRxIKjL8x
|
||
RFRjgqOIxWcnF//rf+4fkHj8b29fnDzc3/+G2IP848n+1wf0j1s6I5mtKols
|
||
5Z/g+iRcshQqFeRmuiCVpGiGzIYaUjlLQsc6I9r83S8MmT8f2W9H48X+wXf6
|
||
gDfceehg1nkImK0/WftYgLjh0YZpPDQ7z3uQ7q73+OfOvx3co4ff/jtJk8wm
|
||
+0/+/TvTpxA6ADIe+UjIBJysHRbRBaTfkTliWo40TadNAarOnnLkRDxhi8Uy
|
||
hJbmRGkD1iTWMZ9WLM5YyGJapq8xI4kl47sNRiwMI4zGwo2Wy9oxSeFGFR+W
|
||
zRk7/SoIZ2bGz52BeywGrv0+GLgyl1i8gX16QxfA2sZHbxmhaCbmSALNYEpD
|
||
YliQsupBEJl38HZZSc8h8OmTOgW9+QRwb/AMQA223sfR0yImWcu+ANZEwWZf
|
||
gYu6813w3hKmJ7KT5/MlVHlW+QF2IiYYyGvHRZCgGZsMp+OV0qHgVNAZGBZk
|
||
cfml0iK2GKRijwogRPCMA2sEC2bu7pHwqyYwaL+4lhkvLUtYbzxXZNmKYRtP
|
||
tIDFSP8h9Yb0G7U5+FW/G5ZExMmTguzHwtievGDcBc8Xk6qziYo0kUXbxaq0
|
||
3GKYyV5syqCdpey38pvMSa1h05WOmAZaVOKDYj1eHbGEL/KXz5/p8zaSQayT
|
||
6HKOY+spFvqf7q3Lc6gy8l3kmjRXm22xbQ6LWMn5gjMCpA09ffNJ0766Z+2E
|
||
7M7gzKZziXbYP4KnxT//PNiNJ193c8QzR0jAzsIZOznYtcPUzpKW9MtqnMN0
|
||
kcOCdcErYHOtrgp8w28y4uiSsAC4f5JZteirGzd5Kl6wOxwsG/hr18XS5/Ox
|
||
GRGbuWo4MssSo4C5PqNeW5mg9XWVp8glIkxoiwMFh/wWbEiYJEFVrbZgk1Ve
|
||
w8zrjoXHhpA/agKXOjd5pMiTG/blTPDEviLjCYQ1FjVJPAY0/IJ5CMmEpqqb
|
||
DYZtMBaA66feun/NLkhi2sz7xOOrcKG9EyCUiLeCuEhXWW2cG4Kh6uGEnwBY
|
||
fpyKeYAx8AtB8O9//zuta5yTwVe35vfJP/3n9+Y3Z0C/wmw7jtx27dY/v/FH
|
||
/NnVke1S046EW47u328n93Ga9z/uDuJvLuQboZ+76YA/+pe2tHXZW364+Zch
|
||
x+aKwi0I7ePOAe/aX2DJcdjozwoF+oygcBVkL1uUHTf5PCN7sgtu+SNKzH3V
|
||
WshUaWbskti02//PYXe+EIF2ZGNdgxDQaxbCHXb9EgCGAQiNNFu2EUQlYadB
|
||
BXdqZBsO/m+gQHRlPh3Ze9f5NAGtNRIM/DcfCXfU35GSQIVm8FmN99gDuHRO
|
||
R+WZEr+wiF8MlW809oefrjTqY8SJ7f1E/IuOp4wj0vmGaiwKE2xUzVZ9Am7h
|
||
Yik6QCTqRBPucefrXNzf9+51RP5FlTNj/nQvkvmkAvFD2izphkwIPqzTfNkv
|
||
4GMO9JIJgsi7pyJHB438w7mPr9jBh5zwfZHySGSfWNhkdXZNOjZtV4TwcsTx
|
||
KZHBYV80ezUXVsoc5iuG0xWHa2irulDxmcOJAGsRsw9InxrIsVg1zjgi5rfH
|
||
qsY6FL0PxitdZ88jvWt3L94gNjHK1LsUwIdYl+oUPY1CFZyN+3HDOixLi2lV
|
||
08tzu9MBJT2PQLmLZdC4tOyxDuw/DAZg1tMrZdKfSDSDBMG85+kH8czDv6Ma
|
||
sRCpRm2m8Jjx6a8F4dzyco7q1DV7wn3QrYdQRgM2a6IQ877VeXHuzk9Li5C/
|
||
PuOw91qA6Ii5xrespgVRdPwdvbm2THmTwVx3tRi2SSffdXhI5MXynARLfClb
|
||
vWzTMWslzDoEkhtVUNVA2R19Q3YamOSCtIcvqHtDp1gp9go/IEWjNQGwgs5X
|
||
YAq0KYkIdAyy4EkXUWWqUnVetlaI9uAZphU+9aSTM/PxWTCk0cl4CAE5TRYO
|
||
d1AsY/ie6KYE0iwXOw5HsKNntqsjwJwXE9tHAa40NCra0e6R/dG9qse4wRBk
|
||
BORz7NhAUFM6Wyd791r3SVi70CyeL4B9T7z9DIedbkSI1vZWDXDBGMVNFxa6
|
||
FSPd8pRjWLbqCnEeAvbmO3lJKxO2lU1o3GNIRBE1CqqJeFUlMgYRKVEEfA+D
|
||
b5vD4YWwsE/3Ii+ysPstHzBmbkxWiKWV5lywayh6+ZIeppCi9MFl+OCQAKl5
|
||
COCSxIgMvYBcGNLh7SVtMi3UPGZAZ3aUNtnjg2VdJISWJGAn5i9Ce3uLdMU0
|
||
tde4yf6ibHrXNpVYdojPjYl1ETt27CcvTWoRVs06HuubtFhmIi3BV5WaP937
|
||
tSJsUK+1IHRfjGEvrP2mylSDEPQMWdnarw2Z0p/ozMCvOaXv8uHh48GQn7Sr
|
||
BT/R/Do6ld//etvKTywn6SeJF6YJ0VaST5L9h48G5nOXOcmKlC35hepmTj+m
|
||
bPkxZ6Lp2V/hHJ4a8J/kU/agWg/TvtQgzOPfHFPYo8Vh95vEzHYJY+2Zt0DF
|
||
csMgzXKBUAFg4pHmCZCGVweY0cc4KuscuHy4g5Ks0AG9drmac6IWm3huHWTr
|
||
Z3vTvaF9ycMyOF9ePnpywP8+3H+42xmH9wg/J3DUhb3Txo3KDhoHGsm6pImT
|
||
OlsQJTqXEB1jD7JeI8ggN/snzM8mElhb5s1MordWJJ1IWFYYOb+yGcIDSu/6
|
||
gG1QzMY+XoBYlcUXkXIFqLE+SMi04eh7+pXTwlz2ReDqWBgP31VW/Hl9jfN6
|
||
px4D5Vs1jPOiqj7Y5UI5NRBj3HaGJogG3Ot5EJkyCRAnkklFhHnbJqJgR3Sp
|
||
XMGRY2NHlUtLStjvQYOxpO3o4qqld5IE+olbd3pisbh7LPnDoLLMvndmw7wd
|
||
h69DFZd0RdyKU1dWMDONIe21d3SXLfulz+t3b88Q8qb/d8e4cmcnPkR1axmr
|
||
KsE2RTn3usVINIngkfPZn6z/el4HufIX7y34FvI3Efn73f1vCeSz7/4ydLqo
|
||
W9SgWY6cJq4Ot1j15Qh3mTidPFoizEXW2YU0eL/NeJZxUMDROXH1S/rhVSPe
|
||
6ndv3xy9e8crDmYRq+wkPrcDkzN1SGKkiJF3gcwnyvYRG6vifs8XOY280+y6
|
||
nQiEn2XjlFcKZoLkDGYtQEgExCSyz4DJmiadakadGL7q5BLLZUDPelZLJG68
|
||
+0zoTP330I3yTFKEiFfQI9DTKlrgGWcDLDj5M4e5lbOzIuUkUnr+O/rP72As
|
||
smMSBiKdQ5EzOv7ud0cIw7FZoLoh0FV4Vil6mKp78FWrwC2ZotRe0E05Om29
|
||
0xB4ZtcMMWTqbNInvRbpNFWXW8G4eZuyZpa3TmfSYHPFOsEsLa7diQmN7PmN
|
||
SwCJd65fhEz3TZvnH1ux5OiPxISKVUdRc1MrlqbXzJRT+2sF5deqlhgiLZq6
|
||
wSrmBmC5nUR6cFi8eJx5Vtbl++uds3o8ilRK4mlASqdAR8fkPZY+SB9ZAG5Z
|
||
jmmlpZ476EYXy+ckKB/hqMBA3v7TLwPPOzJRUPZo7+py5KUM9M3N70kC0X31
|
||
FP3pz5y8eMo5hU70WGIP4w+KVECznNgIR4eDFxtx5MbxNGwA4CQmKUk4JEdh
|
||
u/Bx7Ya8DwkIclwiRAwbxq5YiGOERQFhDJhOg1OCxwuozCl/SHlCliuNEXsG
|
||
9GvMdPYcix3Qs4HXjvgsgM6c8eK/B222cFXXLnjEw9VLjlOmI3bespbN0XXd
|
||
jiMk5ho0Ah2tEj699L//638wOXWtQUdFsgbRNKznTrpwBgkBlRSlHtt9s5zT
|
||
UY2f09Z1L20+J6AS25rlqlZiOcQ9QacTViGdxHfhz9QnO000IDAUQ4CWRXPq
|
||
slixKYg4+XBAFK1wFGST0fhyApoUJC90w6qjbJqywM8+9tW89W3QO7l63bCj
|
||
SDps0IGVs0NL5COkczrk/9k/tPO8RBBdmAa2wxoYaVScGq17WJCtTEdWTjjX
|
||
dpZzXqBTOySWmZLxAT/DuKjGnM7TfCAs0Rg6R0uAHbRQNdw7ysqgHF0P7M4b
|
||
AsuzjMbLdlUgSXqVdyoB8Uex5FPo9k+n8WEmZCVxFDpjLTorVmZJ5gKOmmM0
|
||
tJpf23yjqIbKMy2qEUJMyzL/6zLr+e1i1qbCAfDCscaCltYOLUEVGmhlXIUD
|
||
dfYy52CRtUhWFqxTFY0N+RTMnvN7eVRii7TegUj8xot8WYIEmKMl7sjZ4PAm
|
||
GXufmeP3lulf5xwsFHsdf+/IyvtLA0dgFvgWUpKZrXpVf6WhjVrftzMyanWZ
|
||
M7bdC8KOCYkBjls1yKH1PpUIi8GNGL/YrcK0QaYM0XveBH+KnEHJGabMeDic
|
||
OFGOY4Jweyqk5T9PR2tfO6GScQHTGJLVH7QmSDq+wLmMmerg696MT/eYeLuW
|
||
QlDIVQdHJsddKj6pRLdiN7nEmy4SerEdHS1kDYrcmAgK9fTiAEiZitQinwyj
|
||
YPXQ9JIVqIlgcMBK5kHZ+D0h3zba4K1qWrpLDoRRGK1RU7E4x836dFqVRiG9
|
||
XXWWgfKJ92RlMeMS54QmFWbvm/Q6a1ecMjZOizHyfN9PKtZsgZHEOrIjAa3j
|
||
HCyeWJOW6BGdLNfkTezAbWxgCfFmAkpCFzxhwN1U+QQWZFEgRS8ISXln53hM
|
||
OOE4VJ1xIjuk12jlgMi1bwAiEUwPfsdO728ASE4ovYhkb6TIQP2PMjyYLOPY
|
||
n1NFMmH0/jyxUqY+782Av5VGusmrZeOdq5nz3x6XNpsvWFPB2ogIJTmac1Js
|
||
XVW6NIChrPpriNCTrSfVzNjwcJqJHyLaLBB1TrPNUs6PSJEEIPF1Up745Ikz
|
||
DCAwnoIOI3GHAHfmIvJd17OwEE7X8uKQNbKsuNZU3AoKGtAKyhnL9j6zA+Zs
|
||
5ADPOedXAl4Ird3jJGBNcKEHX2AELrnYv99du0uyNVECmovfMvA5B5UOMaO1
|
||
q50rKcjYHsoxF+85zrudkXQTFfhdb6LwlBiPyU7ElCRU2gG/l3iX19Ga1zTh
|
||
FwZB7x40szR5ePj4qDwY/WH68+z19U8/pa+Sv04//lj/4UV6/qf3Vx+b+uTg
|
||
rHnw437zYvT89mQ6HWhdEH2PdUWuvsBQAssiwGb1mFaiKO5Cdqz6HL85tm9A
|
||
62euQJWg+5JHPfajvgXd1ivPfnTRA7+DR08OBvr8cP8h1nenZ9GPwHRDRxeF
|
||
AP1PJISKDOn3NHdVstUTbVRIHn7BybbZ2JlI6jbnf3XhBKUzSz84hnb58pin
|
||
dPt7/fxwiGf7rgALnytEwe+4ZpQ19RsMQXSb3tpq3GZts44lRA+Ejv8yugla
|
||
e3zrFe2plgQVzkOnk7jNaOnQfeCls0ZNGohl/UcgSQ7FdZd6PmK9RTmgj8FX
|
||
eCoVA/AzJU5YM5SEkiW4dZfXbu34jNqHWmiwLDnG14pf0E2to+NQ8mlZibk0
|
||
Z5VZBRM8mV40Nb4sacLGK7iYBu2HUd0sf8PCr4lxkjlJ3WQun43WpJERIeMB
|
||
4cOeN4XJqq/m71ENOdj1UnLDQkw3jDfh3EaoaX41KKGoII5gr45QNVpO6Hxg
|
||
Jtxkqsc2+d+yocthQ+iGhkEYyItFWXF1jSSzAVvz7vRCcrTlcenLgwffPKaz
|
||
atnR7RRgHs2QRgj5SusmARfppl8Y8NAgc7PZQKn6sujFHa0YQ+KYjQwDTZN+
|
||
gbEldTAOG+jYmk1oiONj3ufTWxwqkty9XsK97VKvNUfjxJXqsEDTSE1fSOWx
|
||
mdvxdysa9KNMnO5wtMVxIg6WMUkqrocRpsr2+93vOyUPo5MdemT3v/764YPH
|
||
B/uHD4ZOKfAPv9aHrOvQuIeHD7InBw8eJNnDb0bJwf7kIEm/3n+cHBw8fnx4
|
||
eEC/PNinofmLWw15PRjtjx9OHiXZwfVh8vjrJ98k6Wg8SbLrB/sPHx0c8pOB
|
||
zqs6I33FRh2Zk+Xkfcv2fNBV2To6sr/8Webw7OnoiwJxozzEkI7HxoO8Okkf
|
||
pA9/ff+xen84f/DuycurZ8/ePHtz8uqPzz5Mv06myc+LLP/+h/nh44N+BI87
|
||
U3B3DRfD66DFhZ52FMi7Z+Pkgytfb/PpXlxuo3mO/ewM/eoFMw1NdOqmmLvC
|
||
zDYuUwqf98uwjdgn+/sPPn/eUnPtuKE4wdTTEI+h2kIe7Dsumt8WJTaxue5D
|
||
zDymDKPxMhWPXKv4bC2iTEjRspOMY2WtSAsyffKK7J7BHvHS8SxlH7lkUx27
|
||
vJhG+wGkW3NiXHJGc3duTD9vI66g97ksmh0j9G2+P72y99NFrtSYwMOJ47i/
|
||
v7dvXlZNe2T1NyxlLyJksyFRJlv9MBt9P8739vY4+rK3t77czktsldBLa3kx
|
||
Ok0nL8al7sA44fMUrPP5MX33qKRHIJsUZYQ+FBebzArzofFfb4WvYFUBPFZm
|
||
rAczGcKhYzg3YCVn6bDgi4inGpBPl9KwRFY7Zxpnfn5pbex2ao3oEoRNZHlI
|
||
srRGary3aaHqHoaesPAgMfLpU2yaAO/PyIosVw5G/OU1+kF0818YG/1qI++Q
|
||
eHsII2oPX6UlLfhwRqnpu6JdxWpRODBMnO/Pu8naqBzV6IA6TrerhE+HAgNZ
|
||
D/h81XDboYYXKFYq8l7Y9P7RlzfC7OvUO4IDnmvTGE3x5iOkk7urWEg94jgJ
|
||
GH6xu4121cFZlwYFMSMqBADIbNVlshvfySHdUBys6TTqMiUI9RqWEBCGBh1B
|
||
AA6OK1X13ZW/3vT3RTkrAy3XmTFxtrwr08pq5xVnfgh/rz+l1oijwBiGeQAx
|
||
/IChI8KUVdy2a6IjepDlwiJL04mL6WF3McM5kAWl8pKpWNSl6KzfciRD6TDC
|
||
Fb9dTdunsbjWaYPBpqs23dyd3u6aNlu4MvUrQXz7zvsrjyQGA4+qeJ2cIaxe
|
||
6V6SmlYAIBcBNRc7LtTe9SJCGkEZGiqE8LlSaQBsft33pu46fqChnCgNVard
|
||
sVbn+ZUS8pAo61YvnIEjLkiAc66hj8hBGWdH0tGp7xgjbtu0IckU9GBCaFAT
|
||
plxekDB2cU8iPBczgeDlwQCy2x3Fochh5rFVPwhY5dDHSM49aiThU/I+toBs
|
||
u4GJxjxOS8glpkxm4Z1w4oS+q2xOWk9a2HOlWsWPKBDFxA3YxRNp1q51CUlT
|
||
hKPUXdAPZamh7jotYIBFwc1BMATxA5LLyzqEfCTg01ZFhuIXuxMVmx7ZRw+I
|
||
+OijCWdH8ABXchhDMGJwQFnqkf2L/GWPFmO/Jf0oLyb4u9QcYK73PNd7P9df
|
||
XGTPT661M2I+heVhhK6S+JTjND5hdbokAU1CFO1IcuJ2HGoiSDv+KKcEX1M+
|
||
5zLs+UI6/XBU7qT7roQu8nla54RCUajBissg69XY7+hZZQ7/15yQu+LDHElH
|
||
irCCzXhFyIveZuoVBwPnzP+hJ/QtOHbAHhGRVtDfXoQ6X8YI7p0TcdFIZjkH
|
||
laaNki0xSgny6qd1qESzftUIh9CFS12rtFRqsQoJyt9BB4doxBDqIzkiI7lr
|
||
Y1rxRSw4fcIRq8IhXGTF19Qp6mMmWPULAcHdJFic2muSZj5eZSXywrx+li8Q
|
||
7EKQy9fnY6mRs4N4GCl5XBbqavFYqpPKxn4tuEuyBS/ilhV2wo5maPoyRXej
|
||
6MR9PNKP+XxJqgYfQStmEXt2UP0/Jw2wS4j7ZAY/IDQiJUH5ERgaQr1o2sLt
|
||
VLxYxsEYHzr0gj9i5iGfKzqee1GaLstKyfD9MfZ2f7rX0TBF7sYvXDh9tF80
|
||
oDy3CXK37Yjabpqs6fjYIWj7KeGELlqnsV0jJ7zgc0pVA4pSdAVX1VcivqWQ
|
||
ZsgAI+7ArIj17NiSFKH3o8ub0ugYMnWddRESLOlo+qmdKg3WBkCxxqYBmHdI
|
||
Mqs0o5CsFdRh2mY9t1U5wY8hsUtKataGjjhAaj+U1S2ZAdBtBDDd5E6tbY3c
|
||
bL2y4kPEl2kp2U1cpdPNIRXNBcsJqpg7QSFufwQ9uNO5Ci4f7j2k6R5vAKEr
|
||
h9k2JRM6GDE7PIUN3BCCT7buaosvH5a153Q021cNhvK4ShuIu5TFY9KrH7Q1
|
||
UdTkw3ftUa//OKtbQf4sHpk1qKE9P7m8EOQlrqG5lzLFaMmNTexywaFX5DN+
|
||
3cOEzUiGJEz16PRztVVtWK8IetIbOqqiisfbkNNJ34vi1yufDrjaqRf5pr+H
|
||
kPjYSX5zuV1fSSKX74YHFS+kC0qSAgbJwYugfw41galZXhPcc4ghxSsMEA2+
|
||
liGWNsjz0IDuU7XKfdGMHJXYN5p+59KhvAIjqTHdsCJpu0uOYPLnP7m0JJ/A
|
||
pr6w2FwadnMAJSAb9i7IG9qjAAYE3/0Hex34IoKr0XgXU/Ziw9EQ4rqQGfv7
|
||
3c+hjHbTgEqfZ0TMRCaX5LVG9OedrrQMHnP2zjWzqiD+HElDLzsVtiEZalc5
|
||
5J3TiqtdJu7I2LKyc4ndEFYEzdemTDAhVbqDDF7RJq1uCC1EVNieBsu0uP/Q
|
||
A0qcImpqa/RoB6rVMHJaDzVzhzNRjJYLNS4B8zYrikTsah6bRMqFitGejSp8
|
||
tN/pib8hMXEmicGSDYl4voTvurW2ouJJDZLXILCioEXEpboBDWkaVXHXxLm4
|
||
obZbTS7aY5QQ/AtFNZ12Oov4bmSkGtc1PXa50yaK/kgEnl03oESPYn23lW9W
|
||
B/+sU+FxtE4dzKPwNLenKaoGhCr6zlpZnbjbSCNi3tkpmAwpdrEDLqR++niU
|
||
mMRgkhjg4MEju/Oiqkf5hIh7ly19/p4ldK5ZEuhi573lrDvhsSg6Osi+2XlX
|
||
hs53bhxfW7peciGb0ZC/rIv41qiarPrFh6mlLXDuo81wJspKoCUjJ8KEnAjR
|
||
0v2RbEYVxNavYteftOgN8XUFp/oHAWKfWSjJZf2zMdfaDudet0j9zPcd+3Rv
|
||
rdOYOgrVbRz7GIhsQt+cDgGBG7ASnqPDRGeHSLasmjaZVaTGlWmxIosIgfhA
|
||
fTH3i7rO9RuE8pnnrhuisheeetFJ2TfVQo0h74nsBnicVJpzrid3EA1nw9RA
|
||
YDdkWczKikhxtUlL0nKMqKMQUy0RO2cOcCJKYzZ04OD4XI7AnCvfGHY6Bwo4
|
||
GnZ6Gbi0ZS1xL0vXuyXXCEvs0ORdc/VDXM18J5PrSiW1VWRwtUCOow023OSd
|
||
W6Me2XP4MnwlgEORYPGIJwccdF5NRE1Fp0Mkw6qJ0XUT6SK1sk57PZPJW7Wx
|
||
74KElGPNGcdKMnFAp9w2sWqrUl3KoZGsFZ85rVc69Lvi06r6sFyw6sx7OHu+
|
||
vgaXPpN5fakW7T8tROG5lvwvXQUr4XAuuprKA9SabEqo6sylXGVD41JRwKtg
|
||
RKTctdNPiAQ1mPXSxtEpmVGZATJbtKcwQf91Rgoja+uZ6M7rqxhlHvRiV3Dj
|
||
F9fSuZ/4boKTXfvyskOe25IJYuYkcOhNzsVYNlowZt1lCOIXcT6LxsVh1QQK
|
||
bW4b9/64837c441WMl2S3FfPFEwq7vcPHYCMd+7WSqDTNjfd3IJWfkvHiChI
|
||
nyCZJ5ugg8PrlL1NvvkwaXLys365K43FpGNbz8gyrjmXOng7OZ+u6AHd84FI
|
||
oiXtcZ9E4qNkkeaN6xhLZ/qRmDM3z0pbrrRHdXiYGCkc3c5N3udTjbqn2R+I
|
||
J1ShoHhUY2hnArQt52BqCQVoeRUoWdHHBGKUZP12lq0iBHX8gee64poAYiT5
|
||
QrqK3jGZeymLXIpSAZAWPAstVmMk6wEj7U2aFdfJMSFSjR9fsTfJeXk4OTFJ
|
||
3W9J4X9z8o+xIXrJZVT5trJOi3E5x1LMIhWQt1JxwwXxLqsnygDutMlAQC10
|
||
yGCma8YRBrC610NCUsCLiaJQ6FmnuKQrcIY2/0tjQU5RSOOQFdSGXLp1Ewdl
|
||
voARNR1sQ/cDYUW+vwlm6JyBb39VjWE9TKSJora/1M+QsqdtgKQLUNOLjrSS
|
||
yE1DST6pCzG7EQQWpOC0M84fWUWbaqWQI2hHQvcgS+JaTKesRykL99WuvpCp
|
||
XX/ZqG3vW5J0KsVC5qy+Nqor+CBCEaeJFBnBzvNuX7wLIj0W5k3OOc5yCqLI
|
||
+EBa6scVf4hvR6M46MMEvhP2REWcoDPkOFc70g4IZqEYKHgle836tL+VfE4r
|
||
WBSkIeLsuTdsaN5qp5yeiUbqR6hCwEdI2UTTeNdXVlFYuJTYYtwmX/5RSw84
|
||
ddZ6vhSAG08SSS8u4eyJLWFJmwWX7Qkunko6WITT6kx1rG3dJB4MBarTsEi6
|
||
uZVwepelK4JwzckbzR/321De5O2P2LvsdO8t/XRctXDcUkf8cOxfXM8H2tTT
|
||
YFvvAqM6cAgndmuTe8U13cJaE80UBcG7vVGc9z6qvCI116jk2z7DBvdnx9X5
|
||
BTen3WkQOCM76/GmHJJdMeLvMghxh8H1xlXEK7jD2JfgdbHyLCO2+o23+nkp
|
||
m1yybG1E4RsEBIp8VKe1u5TEB7m8Vm8lPfbO5gJvpQjrGNoAsyBtp6B46Izd
|
||
ZgZVuFva1/TcS4dJ7KhqKxMK9bRCLyr7Ev2j6dRxusoViXE2Rl8lWbAsXfF5
|
||
KD0nOyQNjbvwW2h59Myg+js+AeIL8tuJmzTy5LkLZ2qPgrT+OE9WSrXR3Lmy
|
||
cNgxqBgpGA1XWewxvFqLoYb8l8kkV9aqu1OOB7tA9mPiPhSdXBtZhGYvQL9K
|
||
g32OiLTk63T7b6nc154w10UK95JUmFRQSv1qtqFfZJCNORDHnJRBxVpBgto5
|
||
qexRty8390BsTod1mVEbC+xceZ1rw6adRidLaReZxXbVppAr30iTlkleJjRu
|
||
8hr31nCQTqHa1WewHrZQXI6mtMfzdkanVQ9ZsHhPytxFml29uoRKxv9PwrGU
|
||
SRrnd0dFaLdJibmj1emXWjANTWgm702hPNQuxhFdK16v1+IbDPKl0QTVg4f7
|
||
0R0ErA8WsAVwMxfbnGVGBJNLCMRboYrOE0LJEj1zE8lHl4uLHF6LNvjq8j7g
|
||
shMW7VpZKWfhGm1Wqj5Id2E1OaCvJyws7nPjqp1e070wBm610DTT+EIc6z2O
|
||
ztmnLC6R7lV3Ny/td7Pyog93agDBWNkJZpn6fDdKY6Q0eO0dF4U5UwsUSCxq
|
||
mpmIpUi4giiGlj2VC220aMj1hpDCBL4OagpjiEwJw9Y1gL4lxZ/lBZh2UsBC
|
||
8tpWzfUUUr6BUn3JKCS5tDOrlpJVN0lXjWR0zEmRm7GvICHg+z3GvVLgPIbC
|
||
8DKtJ7fMIL2JTxY3yu13Xl6+bnYNwnms4BIlSy4x7s9joKmja693oUCvkKlO
|
||
F1poEkKG/Mk7Lpxulqy+MJkG8A/XVQHN/GRprdGO2NZCh0IEWJplpg0JXFSY
|
||
kyw4WIOXFmleO0sp1tHSteGkE0kntVB976q8qk4URUHrDEsVL7fcWsJuLV/0
|
||
z05QOQET8fNuChgXIsULC8mjxcqHhWl9A7Px0hOUZqjfBhB5AdvS9fc5dtm2
|
||
a5YpcZGqFSTvRB5CLN7XyffCOOrI7GWXIr0hClho1IV4nbvfyucbw9E08bZZ
|
||
o2ayF3EFaZpiMqdqKge24O6GER1v1Wnr6wM9r4UCQWaqGAkJRhaGgh/yMlu3
|
||
VDb52Yz9kqdtk8FywsnHSdet+NqBIl9fEQs+erFRNUARP3UO9HFIU+LRz5ct
|
||
ZwONfG+eI5SxiefIJeBKvYB6XFVZ9w4h5K/DalJzgAS+0KffzIL9PXWp+PYc
|
||
OUjoPCRC0pg7wjTKZpdt6l1qBEuaouRKLbODG5g+5nO0VrD7c0lz4QHpY5Zd
|
||
NR2641i4uIUbpXHmEaGlidBSMos+qtw93/nRZUf/6CLU4ldGMbOmOhmkMUnO
|
||
kiR1u8ata7lpTyXhe7UAhTczdK/gHGNNj+Oui84BvUE5U3zixNqVhacAOjeI
|
||
QATZ8cWZ9uEmhdYF+EJJG0Dsu/w0sv+YLD3GmijNGU6+LSfji/BuU6lfI5om
|
||
ycKUT78uS+VKiJhpN7SQAy73darf1jn9uCH1sk7HK2W4MKOcDSKpjjvQ5YcS
|
||
298VmLps1OASPAn5oN1kSxAFEgO5DtstK2RX/rqcTKVqbWtNHQTuqhzP6qpE
|
||
RSCan7idqzfuzdXFblyDi9OG0PhC1qq5I2vVCCvoOW7i7mHar0e22izSqPxE
|
||
PNVO3IpDMmIe8SYQ9fLtAYllTjnOLG1VuqtlLIqm10ShWAyHdEUnyfwFOuIs
|
||
cRBB+sCGLF6xBgIoDaGNuDkKJrKWKIbb3q23jJ5yOVRViqSeA1/dqtVJ2Mcb
|
||
SR5gAdRP/WdE4Xc1f8RsXGkvZYLsY5844YpjRSr2SsS4do3TGAmZECyRJFnn
|
||
GMRJzXuptXBTFHyX71rZMFDcaFis2wSU61m343Ww4SWhXZLZkY0aslQsF3Rr
|
||
CGDPhhu4FV2kUTiXgayl5vqgutwxqrcmaVMcAgYdl4hc4xo1XM3+iZJaeDhN
|
||
VKdLAhCluhERRh+yxhcX3VbX5tBKNa04kUhtqMhmW6vihg/pnijJ4/XgluvQ
|
||
cPpxgVQK3zNIDrNEIYrkY0vSAPSK49jQYTfPDnLQtAOZcLmePeNUOP5ar+aE
|
||
330hZ7oTcm92o/wSXKDrc2jh7U4C+/3HuGsUNPHXxxGWhMwU2ZL486Ven4aJ
|
||
6u1dytiOmuiTTZczWhcq4KBvKGWVW7l8Uaq75a0WD7ZXE9z1QCJ8IjxD9i2M
|
||
nIpsuQxXhES9VPX1gntoLeWKHg6188UdF1ndOP1DMzK1giOk0OxcnJ3tBiR4
|
||
nZdEU38LJVttmsyjZ5+3inl9K9OQQ5jBlfY5vNozSiWuo8xa8/fokpENPerW
|
||
et7sdnrSQOxzHndaTpfsa4iRbK9fKc6ZeKDXnY2Ewx+jTaSw7SXxL8OKYSk6
|
||
7WxJXC5hbwfgqkiC4HLG1CQhfhoTbgyf+JEWxt0FZUmhzDYSLTDZx45ZO+Hh
|
||
zGbYqNdeUzJw3+EY2Tga7XDWoDeI49yL2GRO8VmiJgbf06etmw3CMyFdKWja
|
||
rJ7UUE+468I2Xm1c7JpYMcgGxlsLhyq26ro6qrXdv0lctx1Zmhtr8Z6KieTu
|
||
yvFdQZGHI77+TtLYi2XhKD50jhGS31m74YkxW0lccXnXrHkbXL1qsQqate5N
|
||
rPDgZBVgGxfGGrLhOs4CZLnVD18SFCVaSNaEqIAIE5K9bZDr5cdzK435lqYl
|
||
8WBaaoCGLxtEwWvmOvaKm1Jptxd/21R8k6C6tBpt5VS7phLdgJ0FD0OLK+Mq
|
||
z8IEzcB9veqFyHhxxJKxCu7BwS1Ioht6jLlcjtr4x26WP1/h7BKPonbfnGNa
|
||
kuXm7kbZ+OMpl6BDserAhl94Msrbp1FmUSptoF2BHMIeIe9cKyKM7dZEDDXf
|
||
Dl/49B8C3FoVvJ4ddwXcUAjfKYG/3JyIwotm9sLL2ZLb4rNaXJtKd8Jsz7EU
|
||
AtNSAb4+usDsYukiP70ObUe2gzXGHIdDVBejXPaBPrcOVXBt29qLIXK0fgVz
|
||
0OTiW3V9lbrePRt6+UKnQO+AQIyRyOIFvE6nNIWYzzvNrm7V2hfcxtFz6/iX
|
||
1zxLWxF9XvM7wE8+yPCOEYEsl1/PWa3xdz9Xkk2vLXSulzUEWm9NJ7Oau5IT
|
||
Br7JypIz3vjuhKy9/o/S/XtvksnBIeS0ZGc7viTz7PwN04WErwBWyBR9QdZ3
|
||
DPa+ZSqy5Ui+TjPrhQPePDu9egHOEXe9QP+KDgPh9hf4LYk5xud/ka90Wlw4
|
||
zvJyxYoP7ktgFz+p8Yi0IJSxw6vb1XVxnyvfy2pgNvIeedPxl7V2AURzKDTh
|
||
H2lWgg/w+7KXyumu8uwRwtD27t7t91LvQU50gv8nkNN8kryU9j+96yRk+i/x
|
||
5d/kPYGj+8fzoGbxM0GVE48q9Oytv0foN/PbUZIkR/jf6K9HfA3VbT6hl52Z
|
||
pjcUouriNyAb/R/rS6GD5GfcXuX0SfpZrIv7qAmHDLnzQ+Kt9ItWP0odeaR0
|
||
3vmp0/H5LegQ0KFf6hP33eZ2dzKCMwvoRb3I/J8eghH+t+jSLGnQ1V34mnL5
|
||
G7qEIFdaH7oOIVuwEBdv0RGhOpUViHfsckc/pU/3iIkn6K30mYYVnplN/m0A
|
||
R7a/sMtJGpds1SA+HJpS3WS+RxO9MxevAuzdWXVrYm3wzlsIiatrX8tea0h/
|
||
w65P5GSXzGjEFesQrpLazbo8xJ105JfLbEVys/8miveKQelznHGxsuG2oK5s
|
||
sYMwGriAOyxOriKexK54di8T25rgcvZNMDyDW2jNm8ayTG5HUoJBVC8vb4gX
|
||
gC+M0vLDV43xYQf0nHZpW52sS77nlfvvpj59cKwd3t3XLuMrL0Nblq4LywWj
|
||
QsVvXO2rHhJ2Vfk7ciX9NHj1Utz6Kc45XGyBXr3xlrUbRmhfrFEqhkQUN9mT
|
||
zjydC2EBDdd6h2S23g20T2ZwVbfEJfPKviXzbfcIOcrc5Rh4lDx4sC8FqzU3
|
||
q5LKLu4x4ftyxQNrYy62AyUZ3HWFlQKDv2XvF26293ipt0g5gcYNFzJsd/2S
|
||
n9GST+S83uLtDSt+ePeKe7O47mMYtL9snMl7+e29fNhf9GbIPqRl+sqLDWt8
|
||
FNbo4Dz06/8H4RyVdnSXLTbTe+DF++itsLxH0dWSG1Z3sLa6R//gmmI9NF6S
|
||
3kgpa+q2GQMb8I2aNjAKZQ9eNA4+u+u8GvaYS4MU7UflkXZnM8rxvY8eTXY2
|
||
nS/j2i/xzv5sN/75pYdHAiD586fNn7g/96NX7c1db96ENz3i7Gw53t141O4O
|
||
zPrI227fXJ/xwKVq6OndNc+Gg00m6fSOw6Wjw3my0OLdcfZee1upB11YYdSw
|
||
ssN1h6YrL9elBHH3a6QhKQcO0NKUV39lB7ht3OuHGwRxga26TTkabIuKA4Iu
|
||
IYF/Ha2M5/qaXOC9Hx2B8lWzfiX2W2nFDcTeLPz8/ddrF1dvUzj+qaux0X4g
|
||
JEKZfzYTyismHGgJ93H6u7ot2ueL4e890aNlXrRytx4yi8hkIblmBpySnGuE
|
||
FYfz7+pCRmVY3nbi/y7BnQBOr+GSAReHRMOqAZKG+Oq7MB6Bnt4ljX+aqdtU
|
||
Lnridhh+9Qn3rUl6Hvxww6gkS7oyOLXIjdz8od7Ic7Ym7cO9B2pbnH4ci1Hg
|
||
kkylMzh0zc2nGLUF7/Q93DqyPy/Ou3JNxptosm4bcjUcI43X2T3qo47c064m
|
||
ppS6RthNLnrVvVPecPnJVAP0M8hGd6ac7Mh1YvFdN/TTfG/AGXp8dojZa5in
|
||
WXJUOx8jPYS5fDZHGmgqw/qieVj0xcpwH6WUr7PhxkCydo1C+Ur9lNOmiPiY
|
||
ZHUneHF3aKLGcJ08NRttJ/azd2/hGOKyLrnSj32N69o34hRRWYW3ZgxaI7tU
|
||
W0Ac3XI0Xcevy4w4ZonrqnaYmdE4u1ayQ4h7TWFY7giX87c11NAMTcj8QXe5
|
||
4+/3fApxXPfkLp6Vu9/GWjADJ0Acr9AueEZSV++HLv7rLX77bfBDBzo66ls4
|
||
feQWYRRA1AT2qdzaLK87JRn4E/neGWeGgw2EzoUyEzpcXJ6BJ3CM7w0kaYHd
|
||
IppwC8ppNtOd0Nf62zEbrHg5SRveSSQ94vNnru5YpMgG7CKS88dpb0J/m9RY
|
||
iuAZQYXurj6WiVD2gKyr97eFI0JiR8v5stAbeThGnibBOcoNOrgSxg2sxkUo
|
||
RtbgnUTysdrIG6sx8iZrtJtUJ9MUHjpaZyK46S+lJUTyyV5hsX10s5pWJhlZ
|
||
oFoh1qMN25A7DvzNAQHrcXfanFBdElfids4uwzcNUCVKaNi9gGo1zahA1d8t
|
||
KwpZOncSr5Gem6FDkM/N9hvyCQ3GagGRW5PUthOuE2fa85vj5AMxzo6krGfz
|
||
kYgDwB2JcXexeMVhDQNd9lXcR0PX+NTY/ix62ZjkWeLzZSmCYuIDRHH131nb
|
||
Z2CaCDyldXDoj5gVp56uJ0oNtXs9V8B27yuEIz1qso64tvqvfUdqsyOEtY2m
|
||
uNOEdI1FTDKdqMQ1cZ5x1KyMg+I6yftx+3Gwi6zMeHEm1CzX3WoAxxnRgGqd
|
||
A6Te8EaEr14xBnt6DaTfFyKO9ncG0EMcAuRNxNYQpJPei3/sykiCVG1/Jinl
|
||
rlEq44umzNYMapoNPsBuWeFQq+lEFEvuhr3Yx5Yv5M6C49K4tlmyUK1q5La0
|
||
oiJHu9ZkhWi7Rtt4oN8rJxb3nFThMhhW/AZtO3P9zUNT8i/qnBx3xS0TnBZP
|
||
agcPhdSXcZW4XiV+jU/RqHeeExavp9ED8CIPu3UX2hfd+w81GTLqCnClsZWd
|
||
c4LoFZrwkPq0u0WuxO/Q/s4vTt9cnb46fX169fZnp4brIuPWAxrAceql17ar
|
||
EbMwr5yi8ne0nE5dsIdsIg6kCrSR0iIGlPivbhAzzTlVpE25UjldkVHv1fO1
|
||
VrDuZmXCoyTc7bKl8O2pH8hIGUGS3eSStTarq+V0hmhhuLpW33cd6rrJXAY3
|
||
wz11t4f3ElkiVZyzhPW2yqCpmSjvoAuS7nnIvSiNy/csViHQMzFaXUzMuoVY
|
||
kzEZ76H2oXhnQzMF327Ed8NzgX3+rn/G2Ub+Ir+YzYcu/KDrHBawbHAM+/tz
|
||
POfugQBTrfuMNadLagE1I7l2fk1NvTg5u7qyO5dLJLueQEnwDRaG2gWexcZ4
|
||
NVTeSkbwFjphxiADbrNem3Hetkn8a2QipaZrp7V+8jbEQKXRrSw31mkcmJCD
|
||
pmtYPxItJJQGt2ogpaVcsGZSUc48hOI2tDSPjHopp8RRtExvuiWV6AMaywjj
|
||
jNO/pNF4vNo2gqguXTrJjLmZHidcYNTtABaGDQr50ISCKCgRzEBwTZjT9fM6
|
||
subTAt0lcDtj/0ZU3qDcTynMqtMhRhV/r/STZFvzZ3hBW07Cjxd1Re+qyh75
|
||
GuwXfA1rlycbFwvPG/U/mP8DO2hh6c+kAAA=
|
||
|
||
-->
|
||
|
||
</rfc>
|
||
|