1691 lines
74 KiB
XML
1691 lines
74 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>ART</area>
|
||
<workgroup>WIMSE</workgroup>
|
||
<keyword>execution context</keyword> <keyword>workload identity</keyword> <keyword>agentic workflows</keyword> <keyword>audit trail</keyword>
|
||
|
||
<abstract>
|
||
|
||
|
||
<?line 51?>
|
||
|
||
<t>This document defines Execution Context Tokens (ECTs), a JWT-based
|
||
extension to the WIMSE architecture that records task execution
|
||
across distributed agentic workflows. Each ECT is a signed record
|
||
of a single task, linked to predecessor tasks through a directed
|
||
acyclic graph (DAG). ECTs reuse the WIMSE signing model and are
|
||
transported in a new Execution-Context HTTP header field alongside
|
||
existing WIMSE identity headers.</t>
|
||
|
||
|
||
|
||
</abstract>
|
||
|
||
|
||
|
||
</front>
|
||
|
||
<middle>
|
||
|
||
|
||
<?line 61?>
|
||
|
||
<section anchor="introduction"><name>Introduction</name>
|
||
|
||
<t>The WIMSE framework <xref target="I-D.ietf-wimse-arch"/> and its service-to-
|
||
service protocol <xref target="I-D.ietf-wimse-s2s-protocol"/> authenticate
|
||
workloads across call chains but do not record what those
|
||
workloads actually did. This document defines Execution Context
|
||
Tokens (ECTs), a JWT-based extension that fills the gap between
|
||
workload identity and execution accountability. Each ECT is a
|
||
signed record of a single task, linked to predecessor tasks
|
||
through a directed acyclic graph (DAG).</t>
|
||
|
||
<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>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="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>
|
||
|
||
<t>ECTs reuse the WIMSE signing model. The ECT <bcp14>MUST</bcp14> be signed with
|
||
the same private key associated with the agent's WIT. The JOSE
|
||
header "kid" parameter <bcp14>MUST</bcp14> reference the public key identifier
|
||
from the agent's WIT, and the "alg" parameter <bcp14>MUST</bcp14> match the
|
||
algorithm used in the corresponding WIT. In WIMSE deployments,
|
||
the ECT "iss" claim <bcp14>SHOULD</bcp14> use the WIMSE workload identifier
|
||
format (a SPIFFE ID <xref target="SPIFFE"/>).</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>
|
||
|
||
<section anchor="standard-jwt-claims"><name>Standard JWT Claims</name>
|
||
|
||
<t>An ECT <bcp14>MUST</bcp14> contain the following standard JWT claims <xref target="RFC7519"/>:</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. The "aud" claim <bcp14>SHOULD</bcp14> contain the
|
||
identifiers of all entities that will verify the ECT. When
|
||
an ECT must be verified by both the next agent and the audit
|
||
ledger independently, "aud" <bcp14>MUST</bcp14> be an array containing both
|
||
identifiers. Each verifier checks that its own identity
|
||
appears in "aud".</t>
|
||
</dd>
|
||
<dt>iat:</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14>. NumericDate. The time at which the ECT was issued.</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".</t>
|
||
</dd>
|
||
<dt>jti:</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14>. String. A unique identifier for both the ECT and
|
||
the task it records, in UUID format <xref target="RFC9562"/>. The "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"). This claim name avoids collision with the
|
||
"act" (Actor) claim registered by <xref target="RFC8693"/>.</t>
|
||
</dd>
|
||
<dt>par:</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14>. Array of strings. Parent task identifiers
|
||
representing DAG dependencies. Each element <bcp14>MUST</bcp14> be the "jti"
|
||
value of a previously verified ECT. An empty array indicates
|
||
a root task with no dependencies. A workflow <bcp14>MAY</bcp14> contain
|
||
multiple root tasks.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="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. The base64url encoding (without padding) of
|
||
the SHA-256 hash of the input data, computed over the raw octets
|
||
of the input. SHA-256 is the mandatory algorithm with no
|
||
algorithm prefix in the value, consistent with <xref target="RFC9449"/> and
|
||
<xref target="I-D.ietf-wimse-s2s-protocol"/>.</t>
|
||
</dd>
|
||
<dt>out_hash:</dt>
|
||
<dd>
|
||
<t><bcp14>OPTIONAL</bcp14>. String. The base64url encoding (without padding) of
|
||
the SHA-256 hash of the output data, using the same format as
|
||
"inp_hash".</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="extension-claims"><name>Extensions</name>
|
||
|
||
<dl>
|
||
<dt>ext:</dt>
|
||
<dd>
|
||
<t><bcp14>OPTIONAL</bcp14>. Object. A general-purpose extension object for
|
||
domain-specific claims not defined by this specification.
|
||
Implementations that do not understand extension claims <bcp14>MUST</bcp14>
|
||
ignore them. Extension key names <bcp14>SHOULD</bcp14> use reverse domain
|
||
notation (e.g., "com.example.custom_field") to avoid
|
||
collisions. The serialized "ext" object <bcp14>SHOULD NOT</bcp14> exceed
|
||
4096 bytes and <bcp14>SHOULD NOT</bcp14> exceed a nesting depth of 5 levels.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</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": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
||
"out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
|
||
|
||
"ext": {
|
||
"com.example.trace_id": "abc123"
|
||
}
|
||
}
|
||
]]></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. 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.</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>
|
||
|
||
<t>ECTs form a Directed Acyclic Graph (DAG) where each task
|
||
references its parent tasks via the "par" claim. DAG validation
|
||
is performed against the ECT store — either an audit ledger or
|
||
the set of parent ECTs received inline.</t>
|
||
|
||
<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>
|
||
|
||
<t>In distributed deployments, a parent ECT may not yet be available
|
||
locally due to replication lag. Implementations <bcp14>MAY</bcp14> defer
|
||
validation to allow parent ECTs to arrive, but <bcp14>MUST NOT</bcp14> treat
|
||
the ECT as verified until all parent references are resolved.</t>
|
||
|
||
</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 appears in the
|
||
verifier's configured allowlist of accepted signing algorithms.
|
||
The allowlist <bcp14>MUST NOT</bcp14> include "none" or any symmetric
|
||
algorithm (e.g., HS256, HS384, HS512). Implementations <bcp14>MUST</bcp14>
|
||
include ES256 in the allowlist; additional asymmetric algorithms
|
||
<bcp14>MAY</bcp14> be included per deployment policy.</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>
|
||
|
||
<section anchor="threat-model"><name>Threat Model</name>
|
||
|
||
<t>The threat model considers: (1) a malicious agent that creates
|
||
false ECT claims, (2) an agent whose private key has been
|
||
compromised, (3) a ledger tamperer attempting to modify recorded
|
||
entries, and (4) a time manipulator altering timestamps to affect
|
||
perceived ordering.</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. ECTs provide a technical mechanism for execution
|
||
recording; they do not by themselves satisfy any specific
|
||
regulatory compliance requirement.</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)
|
||
and audience restriction via "aud" to limit replay attacks.
|
||
Implementations <bcp14>MUST</bcp14> maintain a cache of recently-seen "jti"
|
||
values and <bcp14>MUST</bcp14> reject ECTs with duplicate "jti" values. Each
|
||
ECT is cryptographically bound to the issuing agent via "kid";
|
||
verifiers <bcp14>MUST</bcp14> confirm that "kid" resolves to the "iss" agent's
|
||
key (step 8 in <xref target="verification"/>).</t>
|
||
|
||
</section>
|
||
<section anchor="man-in-the-middle-protection"><name>Man-in-the-Middle Protection</name>
|
||
|
||
<t>ECTs <bcp14>MUST</bcp14> be transmitted over TLS or mTLS connections. When used
|
||
with <xref target="I-D.ietf-wimse-s2s-protocol"/>, transport security is
|
||
already established.</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. Mitigations:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Implementations <bcp14>SHOULD</bcp14> use short-lived keys and rotate them
|
||
frequently.</t>
|
||
<t>Private keys <bcp14>SHOULD</bcp14> be stored in hardware security modules or
|
||
equivalent secure key storage.</t>
|
||
<t>Trust domains <bcp14>MUST</bcp14> support rapid key revocation.</t>
|
||
</list></t>
|
||
|
||
<t>ECTs recorded before key revocation remain valid historical
|
||
records but <bcp14>SHOULD</bcp14> be flagged for audit purposes. New ECTs
|
||
<bcp14>MUST NOT</bcp14> reference a parent ECT whose signing key is known to
|
||
be revoked at creation time.</t>
|
||
|
||
</section>
|
||
<section anchor="collusion-and-false-claims"><name>Collusion and DAG Integrity</name>
|
||
|
||
<t>A single malicious agent cannot forge parent task references
|
||
because DAG validation requires parent tasks to exist in the ECT
|
||
store. However, multiple colluding agents could create a false
|
||
execution history. Additionally, a malicious agent may omit
|
||
actual parent dependencies from "par" to hide influences on its
|
||
output; because ECTs are self-asserted
|
||
(<xref target="self-assertion-limitation"/>), no mechanism can force complete
|
||
dependency declaration.</t>
|
||
|
||
<t>Mitigations include:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>The ledger <bcp14>SHOULD</bcp14> be maintained by an entity independent of the
|
||
workflow agents.</t>
|
||
<t>Multiple independent ledger replicas can be compared for
|
||
consistency.</t>
|
||
<t>External auditors can compare the declared DAG against expected
|
||
workflow patterns.</t>
|
||
</list></t>
|
||
|
||
<t>Verifiers <bcp14>SHOULD</bcp14> validate that the declared "wid" of parent ECTs
|
||
matches the "wid" of the child ECT, rejecting cross-workflow
|
||
parent references unless explicitly permitted by deployment
|
||
policy.</t>
|
||
|
||
</section>
|
||
<section anchor="privilege-escalation-via-ects"><name>Privilege Escalation via ECTs</name>
|
||
|
||
<t>ECTs record execution history; they do not convey authorization.
|
||
Verifiers <bcp14>MUST NOT</bcp14> interpret the presence of an ECT, or a
|
||
particular set of parent references in "par", as an authorization
|
||
grant. Authorization decisions <bcp14>MUST</bcp14> remain with the identity and
|
||
authorization layer (WIT, WPT, and deployment policy).</t>
|
||
|
||
</section>
|
||
<section anchor="denial-of-service"><name>Denial of Service</name>
|
||
|
||
<t>Implementations <bcp14>SHOULD</bcp14> apply rate limiting to prevent excessive
|
||
ECT submissions. DAG validation <bcp14>SHOULD</bcp14> be performed after
|
||
signature verification to avoid wasting resources on unsigned
|
||
tokens.</t>
|
||
|
||
</section>
|
||
<section anchor="timestamp-accuracy"><name>Timestamp Accuracy</name>
|
||
|
||
<t>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). Cross-organizational deployments <bcp14>MAY</bcp14> require a
|
||
higher tolerance and <bcp14>SHOULD</bcp14> document the configured value.</t>
|
||
|
||
</section>
|
||
<section anchor="ect-size-constraints"><name>ECT Size Constraints</name>
|
||
|
||
<t>Implementations <bcp14>SHOULD</bcp14> limit the "par" array to a maximum of
|
||
256 entries. See <xref target="extension-claims"/> for "ext" size limits.</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="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="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="RFC9449">
|
||
<front>
|
||
<title>OAuth 2.0 Demonstrating Proof of Possession (DPoP)</title>
|
||
<author fullname="D. Fett" initials="D." surname="Fett"/>
|
||
<author fullname="B. Campbell" initials="B." surname="Campbell"/>
|
||
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
|
||
<author fullname="T. Lodderstedt" initials="T." surname="Lodderstedt"/>
|
||
<author fullname="M. Jones" initials="M." surname="Jones"/>
|
||
<author fullname="D. Waite" initials="D." surname="Waite"/>
|
||
<date month="September" year="2023"/>
|
||
<abstract>
|
||
<t>This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.</t>
|
||
</abstract>
|
||
</front>
|
||
<seriesInfo name="RFC" value="9449"/>
|
||
<seriesInfo name="DOI" value="10.17487/RFC9449"/>
|
||
</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 757?>
|
||
|
||
<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>
|
||
<t>It cannot represent convergence (fan-in): when two independent
|
||
paths must both complete before a dependent task proceeds, a
|
||
linear "req_wl" string cannot express that relationship.</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="w3c-provenance-data-model-prov"><name>W3C Provenance Data Model (PROV)</name>
|
||
|
||
<t>The W3C PROV Data Model defines an Entity-Activity-Agent ontology
|
||
for representing provenance information. PROV's concepts map
|
||
closely to ECT structures: PROV Activities correspond to ECT
|
||
tasks, PROV Agents correspond to WIMSE workloads, and PROV's
|
||
"wasInformedBy" relation corresponds to ECT "par" references.
|
||
However, PROV uses RDF/OWL ontologies designed for post-hoc
|
||
documentation, while ECTs are runtime-embeddable JWT tokens with
|
||
cryptographic signatures. ECT audit data could be exported to
|
||
PROV format for interoperability with provenance-aware systems.</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:
|
||
H4sIAAAAAAAAA71963bbWLLefzzFDv2jqRxBlmz50uo5M1HLclsd29JYcvv0
|
||
msxyg+QmiTYI8ACgZI7as/IQeYA8Sx4lT5L6qmpfAJLumZyszEpOyyCwd6F2
|
||
3W9I0zRp87awJ2Zw/tmOV21eleasKlv7uTU31SdbNmZa1eZF3rR1Plq1dmJO
|
||
Z7Zs87H5UNWfpkV11wySbDSq7S0t8uHizfW52VhqkIyz1s6qen1imnaSTKpx
|
||
mS1o10mdTdu0tGVpF1lZpnf5orGpHbfp4WHSrEaLvGlonXa9pJsvzm9eJuVq
|
||
MbL1STKhBU8S2vNxktU2o71P390MkjsCalZXq6UDZpB8smu6OjlJjEmN9aCN
|
||
BTS+iqeKKpuYfIJ3a9d8NdMXvXMvKldXk7w1bZ3lRZJkq3Ze1bw0/X9jpqui
|
||
kDc7m9eEszwrzVv3dnxHVc+yMv9bBhjolcqJXdoSu5p3trFZPZ7bmm+kR/Li
|
||
xOS2nf4Xj6CDiU2SsqoX9Pytxb7vXp49e3L0JPz5LPz5bfjzuf757ZOnj9yf
|
||
R0eH+PMifXGAXRT5AGHL5eZRky7rqq3GVXGSJHk57UHx/Om3j/Hn9dXFy5fn
|
||
J/wOjrauCem1NVd1NVmNGfsXimjzsiZ0AcNMZ+e3tl5XpTVDWWZvIOtk9cy2
|
||
J2betsvm5OHDZplPp/Ygrx4SJTUPC6KFptWraTaqVu3Dila6ze3dQ16AqcVM
|
||
s6Kx9O/Lq/O3N+evz9+c37z7uQvpJZ3GjS3swrb12lwv7Tif5mM+re2gVPRA
|
||
6x7wEDX0YPOwoh+27W9MoBv8LwVVEMkU1Wpi3jJSiXMWSyLUcmZeVqtywhDE
|
||
p9KM87blw8pb4hdCrzvW4+NvO+dXYbOUCLZsMkZ+2jJju5t2/Z7SgaTMA3Rr
|
||
kqZE+iOSAnRPktzM88bQm64WoNyJnealbTb53omQ4fnZTbO3bzLz44ebdJQ1
|
||
dpLQz/QTbm4r086tEdkRvxFdzlpT2zGxb0OYbz4F/k2ycV01BEQkmTYY9sCY
|
||
82w8N7S9IYAz0+Szkm6UJZNqypfKWWF59X1T5OUn+p0gWtZ2Yse2aYgq8Rvt
|
||
Pye5MpvTI5OcFqANCYb1uKANZ3W2nJvhi9Mf9rAlvSxtsWps9F7YGae5qCa2
|
||
MFlJ0NY2YawvqxrQ5yUtXdq7gMbUofHVzc2VmdtsYmszzW1BDxdVOWtIXBEe
|
||
IWdoZdnHSTC9vTmQo1vkk0lBsuMBiZzWsyEO0gE49Yx4f79FJHz5wkDnbWMa
|
||
cNbYEpmkif5tnGjYfDgWHFiEiI1PiTgicXKXjkZOc5wVhRnPs5yIhs6USMyU
|
||
lSMBcwdyIMZpuk+2K3pqTacyIeT/g5SZ7KZME1EmNpzmRdHwSc6ypRnZ9s7a
|
||
MtlQGYyeoF6y8Zj4ts1GeUE/9gkx6RCi+acIMdkkRLONEOmwH5jrMQkoBu10
|
||
uaQ7FJ4dHAw+NyCJHZzM6NozIvrN8P4emlr+9eXLHj1LG5OCr1fCvlMF2Tgl
|
||
N16TpCOqBLnS05Nslt5mRS7STVY4LbvUDqVASPOMgucge1O5QR9inVzYyYwe
|
||
yQngepoRUdb231eEIbxhg+fkhtTfgIeZA6ZVQeICUBFTGlIfOJHGow4X5/QH
|
||
PW9Ga+EXRtUHRwQRVfPhlxFdEPHf5iAnWp+e+a92HYSWu5l0OwkvAIoDqFcN
|
||
SJ8MgNKQYstGRd7M+Zw27j0DddA+WUEkM7UgAxvfQQxPJ3iLWyoidzz/Amed
|
||
87/l7clAgsgkXhq8eX99M9iX/5q3l/z3u/M/v794d/4Cf1+/On392v+R6B3X
|
||
ry7fv34R/gpPnl2+eXP+9oU8TFdN51IyeHP6M/0CqAaXVzcXl29PXw8gCNsO
|
||
dQL/xAkjK2dLHME03yQT24wJjyI8vz+7+l//8+iYJNB/IjX46OjoWxI38o/n
|
||
R8+O6R93dEayW1WSwJB/0sGtk2y5JNuLRTAEULbMW9LVdC9Ju3l1VxI51pY4
|
||
6j//BZj564n5w2i8PDr+o17AC3cuOpx1LjLONq9sPCxI3HJpyzYem53rPUx3
|
||
4T39ufNvh/fo4h/+ROLHmvTo+Z/+mPQ5hA5g0fCRrBpBfOewiC/YQThJTsDL
|
||
xBhVWS2qVeONbMaqCJzATmSL7FA7+yKFRbLaRpXxXU67QmE6XU+Hc0O/8Lbg
|
||
rzGIxKyI0Fm6AiS+V1Yj478hcBsCn6ws4Yslq0ULK58kAC7Tmi+chD1VCftD
|
||
kLCyl4jcIPRqS/TZgOGArF3S7w4ERTtBIgk2gywnWMrKMCs3htU7AfJViSyQ
|
||
/Hh9+dZ8sCP95f5evQCi/AjdfFpNbNgySgiW7YYWPduSJwJkiJh9zVLUne8S
|
||
75aCn/ZNvlisIK2sKaoZo52Yia2hjeMiTNCOjeXT8fbavtAUhL64WcAFGfIe
|
||
VALCy1zvQigiPlw4RIhBMw6ikUUwpLsnwm+aIKA9cC0EL4ElojfeizwXgtNt
|
||
dNXdaIkfU/p/SzJhbKM2LW71bwNNRJI8LeytLRLT0xegXZb5L3jjzktU5dgu
|
||
2y5VkVMZu5H0giP2EWp5FzIvCLVzIqpIC5EjvbL1Pi1Y00LLqpwwfVb02uJq
|
||
Eb3IH1++0ONtpINgSey0CF6KLXD/IDIFiFLKnQ+wHd4j1SEZX3sxwTr7KOvc
|
||
fE0XM2YyeuA6PPDkyxdndrM0JrQndAP7UGQemmuiIDIzBFtmCFMOlt7T41Vd
|
||
pMSXZJJPkl/EoDhYZmsc+UHjNvtF7Z0901QiPaAySEmU0EjjrK5zloOJN+Fi
|
||
A4bsmxU0x+87BWy8WrZ2+C1occUCDjXBUw2Z6ERu+S0Zz6y2MzILx3nW6k28
|
||
NMs6om/iB13yx0sSsArP4FM+GZhlBmufRLlsVdspiSOiNF5guRpB0mF9IR9y
|
||
OepkWleL/vqiTHFxkBWzjWUJaWOGKaFfq5oAXERKw/ZoUeC9KBU3JDWLas22
|
||
2z6/PBAzIDIemHGR5QujOrGL0Z5ZLpCrueop/eJFROxqKANH5pXg6P7Br+Rj
|
||
OAtTFCB253sUj/yCiCFl+jJBQ3oswJ7++9///mtDntY9MRUjCaG260dPnpL5
|
||
Q1fa9RJXNO5FLPMvv9618hMOin5idKdZSseR5pP06NHjQfIFyyb3J+bBNJ8p
|
||
nBLC+NeBB1Rf5vxztlgWdkDvQdtDtjjjRKljks9g7RhP8KZ3WiQk8JvRQzgg
|
||
4LrHGz2w82QRbAAcONBMjFFepFkt2axnnHiOfs4cfeMIix5mPjLO2AJzDMqq
|
||
tAO67Xq9QPSFSNbDQea+PZgd7JtXWBbofHX9+Pkx/v3k6NFeZx28I9skyqLs
|
||
M9C/3aoQpg41Eg2ljVMSyKShnPimY+xh1rMwqThCYP+EcW0ijvuKjHvemzZi
|
||
JqsIgzX8UYO4Z7PP1grdyyaM43KvHtS2B2CQ2/RExIaMNahuIqYtR99lcS8G
|
||
WDN0BQEAw/Jd/vfn9YzP630jJoZobKJ/vGVRVZ/MasliwAhhkEiOlyaMBtrr
|
||
aXtwJiHiDBzfgDHv2pTZv/mCH8nBbTNovkl0m6gfJ0a382gTPzbW1YP+QYSz
|
||
aXoYu25hul3W799d0L9ODf3XYW/tUCZqFkaNvC/4ZYdQE0tMpdhIhFgwT3wk
|
||
FdLKg8+C7BcJdJ48fPgHVtOpqOk/PvzDMmvnf/wF5M686YAaNKuRk5oCWU9J
|
||
vCWCdmZ4BKIhX4Hlq1Ak3rcZzy3sZsdepOmu6YfXjRh079+9PXn/HhB7qmog
|
||
YMma241MA3OvrrM1gOsiGUQKn6+EhmYLNV/mtPKw2XNvIhgWUbGa9JRDdPj0
|
||
eASUs07ZOsrhVkCx3+V0iSlwHa39gUw12GxCVAsYRiNHqELwo0q5soSdI86G
|
||
04xsyNLjPjrhI/4wmQVmJyxoC0GEwo0DxNpd2F0wybGZoTMZf9JXQIAODmuU
|
||
yRDnFr6ObEfnQYKrdx5vyR0iYfeCbAlFZ5uTsQGkzHMV83j9OxKUTOQTWsZ+
|
||
7ou9zWXonrxWPwMrRse2RSfoubHUBHuQAHmC/3P0xCzykh3AbArJNqBXwJv8
|
||
2uZbKYs5lNw/srtjEQdh408L70PHpHKN3Z7cx5v3gS+mZWU7Fg/InwTdRJsP
|
||
2I2pbwFYE5YW+z/aeChuwLKg0yWPynL8dW9j+94DiKeRNAc9eRtNDpKuDvaA
|
||
wXd2bPNbkLSacr9CvorXhVCpQGnmMKWLmmwCIldLsDWWqVqdn7Z7UiQjJ+RT
|
||
C+1DeRGR0mmoDwIBI6gtyd3BDxwrm7hIvvPnvuMQS3g8G2152tG+RUZpTIvM
|
||
imrEAV2NCbuTatqKYzCQ+pvOBTkgdC3ohm7QQiU8+9lfc4VJ7t+JpnRhkS5B
|
||
efc1OihmO845wnpALmqSqDdCoqsKkV0fqlC0OmwG9md641BIIDVwmR1/JD9m
|
||
F53jVSVzY1zAlc2ACEYNlCECaVwYXZWAWdoaFE4oUaE+IIcWAeeP5AqBNcUc
|
||
1UCt/dhkU9uuB3su2C4CF1lPk91W+YSuEN454unNFTZ+x2T2DE/HdIx7+lBt
|
||
Z7BrajkOfmukEfmticB7L3zqdETDbw45eCW80eOdhlVF5DCDjXwUhqS9k6BW
|
||
ZI8/gDZiajE4OTJPK93m1aop1kHqi2ogQ8Mulgj+M2zENZzYAACZqatKQWM0
|
||
lFUfhoieoGlV6EN7r4o2J8EYlmiU8EmwZkjh2FkNr/7+AR1JxhFtvvA79M9x
|
||
kImoVFkgNrd8vD6JomIaCuNXQGCcUGGJEtSywO5QObaYclJ4+ZHkzHwX/9zE
|
||
jrdhx5szAW7tZTbBBah2FYrXr05T+AVY1WkOBo53hmWMLCkdB9K9/Gud3Zlq
|
||
3NqW43jREwBEV8tFqCxgAhI1riP/RU8K5+ev0fFP88/OCGO62LTJhWWPj7+V
|
||
RNm2eGY3E0YHSu/8/wFfcoKKsFXjjo5jCaraMiBr4I5v4IWs5sEalq76j0Bi
|
||
dKkH+eUIyocpm0SLrbMiXa7qJbRQSKpVfJP6K2K6pk4IO0JF0u+rgnqb7cCC
|
||
WDOGqxLJz1Zycm5nXRzcDotqVlacY7YLyAN/F3wSSLMmjjCA7Gv6r8BLT9Mm
|
||
Gk5SoUmkeGDF1z4Yk41YLT5yqnawx1E2SEb2f1Q0Nnq+jcam6EUHqJRx6AkR
|
||
f3qBsWWdcnz47VNCBxtB9GIbt3D+WJLBJGlapoAnhmOOIj84IlYgMA6FqpGB
|
||
vqzgAN04vlFDYkZfrx/VQEzmhJwM55V4LFSLh6xiHo5JYNDBFaJJYIN+/X5V
|
||
MXw37LwTc/Ts2aPDp8dHTw75Ipkq4eIzvQjBTes+eXJonx8fHqb20bej9Pho
|
||
cpxmz46epsfHT58+eXJMvxwe0dJ44k5DLIejo/GjyePUHk+fpE+fPf82zUbj
|
||
SWqnh0ePHh8/wZWB7iuqGE/BTlwQ+U0+tmRWtUFTwjQ7MX/5q+zhuYoeKY9H
|
||
f579PH8z/fAhe53+++zzT/WfX2aXH28+N/XZ8UVz+NNR83L04u5sNpOlnITA
|
||
w6/PssPs0a8fP1cfnywO3z9/dfP992+/f3v2+t++/zR7ls7Sn5c2/+HHxZOn
|
||
x/p6oKcTc89VJh36RBWH/agvPxpzTMmYL724EoqZUIvlIksd4rlSmojCSw8k
|
||
8Klxpxufsb1/ECdsmQ63lDjIUy/BMpqd7iYpXCq/jdPTuyskEhHIR0eHJJBZ
|
||
sTl4QONsnWkqX8wgMAj4oFNlITZAHmxQ0gE7A8tJ7Cf4qPSNUxlOYzQil2tr
|
||
zfcbQWgiHS6wQASnFdlH5llekW02OCBJMp5nKMCRuo5TBZ3ulzhb5vIMLHFK
|
||
8drllrwcF6uJoC/ZRJ++ta8qiUJMLgeSunyLRpKdFZuZ3VkSliW3WV5wUoje
|
||
JPkdpbivh+Fkm4JNJkbSh41dN3EjmWp/OL8xD7NlrsIjZaeY6eLh0cFR8qpq
|
||
2hOjv/EmB5HcSTbe8sTY9Y/z0Q/j/ODgAFGSg4NNvHVuAih0UycyC7rXbRwX
|
||
MaW+03Ni0wGEJeQPLmKkegNwGQzchg1EqXVy1Ysm9i/08PcT//TOgxbyLpih
|
||
YHpyap1RPdk3lkzjBHmNtRCVI8ff5QA1Jw70JUCO4psa9Shot9+FDY53m7BF
|
||
DnOa7FUp79GwjHVlNEs1+HjpCUKHpJfv72ODlhnwgiz4cu1whCenSGd2LF+u
|
||
Akg8tLEjzY4xUUTt8esVN+cunUOQRCdlLl74iiYEmXThiYswq2fSaKhcpGqi
|
||
C+o6sasQ8RBLMpi5vCSfj0TyUC3bAMCyVaZ4wG7PT76+hp2FTsGNZqVwanRY
|
||
X0t1S75akM8eQhyNoBfpkOltnoknBUUoRhfhDMCEvRNEE7zjmc1Q8dV2XX3z
|
||
v//7/zA2FyFWakJYo2hkO7bhDHR3xa7iOi9B3o4WI3y5lPJaU6n0GFLXW3IT
|
||
CmDSDR13X4RgtUskeo5AF3L45r0Pb5yEQJH6vM7X1NhUiL9IYahWadFRS/3R
|
||
MA6oBB+XVQPbL/tGSEKKhoVSAw7zaT/8sud4QsJ5Lp8Ad0AMBYbVhYq4/IBj
|
||
1d3MpHAHBwEfBT/8/DO7RGN7IpW8G0GtAr/7/B8TiLw2u88ar3epIxFuEs/g
|
||
0GbMCLnPR/EC8rZDJZfIYZdoXtjTE5CnFH5eqEXyzd7HD3S1FwRJzOc5eypS
|
||
+Y0M/Ffx9BgEYhdkgmSFudRCEKUPGLkh4mAZd/FG6rIYl7OaweKU2JOisrsC
|
||
C5ZVHRZYFquG6wLggpSkm1Y1o3FcVKQlm0/2jrBdkMeGJPAwqh06MY8Pic/o
|
||
oUnD8UZIPz6MfRZGLBIE1BPzi/xxQMCYP5CxkhcT/vtfZGPs9RF7ffR7/eKC
|
||
zX5zLZyUTFsAj1foWmzfIVo7qay4i7MVKSlSJJbDQyS5x9mqIUy7khs5JU5i
|
||
5wtU1S2WDRs8CFSfde+VWGe+yOqcSMhFJgUEyQx0Cx2HelbW0X9EnkKae/sM
|
||
5Git1eYOgu10RcTLNe3i+MJwRL8BQoWO0XfQ2DF8bxHfbMO8DGVboAgU1kYC
|
||
MxLiLiHKixfE+maUEeY1oOtIiXb9phEJoYBLmRLwJUFtsh/kDXfzwRMceVTu
|
||
ghCuhFLGBPFVrEl8cgy2nwIj7I7gRVyjwkKwcjU87iJLN8lfZGZq6XBdHb2R
|
||
UC1k/TxfcnSco+K+3JJBveHy21vRxyUZOqjycSXPUHNktqC+FNXH1i4BxB0s
|
||
VKKOZj/p6xR9GyUngmiRfc4XK9K9OIJWfBSEGbiYc0FWUJcRj8hzPSQyIjNe
|
||
5RELNNyJA6jBilAMdgpZyAeT+FSDtzMiYR5yj9HxXJSdmvpOxjKLRCJBv2aa
|
||
XlvOh3nRnBDPSkH2iss2kfRwTlyRIa61UQhAFugEtJhEehWnCeLtaHdcrGuS
|
||
2vtcHu7T+OyB+yqRrAkynERJXrAVtkn0GRt1TVXc8ps/iAqMYCWII/NTHCG9
|
||
f9CxL9mX7dxw5axRZwM7H021TRMsjrZjZHTz00knLssmhmEin6Dyjm0NYhSt
|
||
fNltjxO6QKGZ2rFR/YpwqQZ2pIwn5OBBKiQXIYRhZccOraj7n1yKVBMJXMbi
|
||
fItQfUBE2a97UD24sQCXD20sEGUuHee7pOc3jVdkMCCBNxgXHLAfo2TOTnx5
|
||
VSgLcQrMRk94InLOphSWcFYajkNUBxJHhTsFJt3ykm0k7hS420TqXVRNeGC+
|
||
MwjpalFfKEGJ3oAX6blsfEqBUc2yIoZbqzr4KaSzpfZrA8sxR5hPZXVH/hAz
|
||
otBItwgE/v7FTZw27JUKQry/A9QkN3eWk4n5yuAEe9wRs0h4T409EiQSF4H2
|
||
5OARbfd0CzW5c9+1JaQ9a2NJgUIX3FaftIZu21vtqF3iEINXd7TbNw0v5dmW
|
||
XqCJQu7xmnQrPSDqNhTuW1LRZd546hrbuhU5YOOVQSr75vLs+kr4mEhVi0Vk
|
||
i9EKzQpmtUTCjgswnvUoYTu/cdWIxtj6NV1qO27UdSXPe0tHJXrxeluKUOh5
|
||
YaotVYxap+hphzb6tv8OodxDU2eyUyQiUAnhamqE/TS841PbvEje+NILFswI
|
||
Pq6mhPecbRGlq778CZ0/KqaIrNC7qFnF7zQ8AV9/bCVHY7SUBs4sX5UCrWDF
|
||
wmi1vawc6dUVMt94nIGOX9JFJ2P3eD/ydAQJnXcX4g0tD64o5OjwoINfBNkV
|
||
vz6x6W0Hx0NcNMDq8+io+zh7JPp4o0kZUtMNybYRWQdT2ZxxlDXiRA27JlNI
|
||
CyFe2syrglRVZBJ5A0pxG4pE9qQF5+vbTleQL7Jxx9AqK7OQ1BBRRXB/TAaG
|
||
CbVdXWXkvC0y7ffZThE/pufGgBePHnlESXSIKw4nLj01ZPt6P0o27Gu5B7cM
|
||
skyWABK/5J0tilTiKFibtOuVWhS9QIXI0X7PFZ4hNXEh5VBaSUQHIimmftyF
|
||
7XzoGRt8XYYomJLSERCKQeRJGJbi52xYNhKP2+06u0qqRBnB31BUs1mnW0Bz
|
||
jZzer2u6TF5WQ+ZXk0SpMklgI6DFnOhJrB+/Y1/OyT7vx+1rS96tBNW1Cbpi
|
||
m5lOuWFGFdMPz2wwMuFvxR4mh4FduF7Do3Q9jkT66J7DrouLsJDkBY4PH5vh
|
||
y6oe5RNi7j2Ee/A8NDQdFZ8zG8o+fwFbii+LzaeLHCXD96X0JCMT6dYR93Vr
|
||
aaa8jDjvicBFcmtUTdb90H0mqWDCsOUzUVHCrhKnsZNQUiCumj+S7aRiJxoz
|
||
8FhKBEvekFN0aqCUUcw9klLatO1skqm2uDwwcZMLV1pIL+H9g43uQQ2fqjEW
|
||
B5qIbUIvTIeBWBrAE8vh9HXNfG5Cqpo2nVdk8ZEFuCa3mJPpgfti6YcMem1n
|
||
Ky45IrfyNq+rUgo3ceYq/bx4wdbLisBH4y7/kVRL9YhdLU8v5ea0klRK4Cz9
|
||
2YAbCO0JuZfzsiJWXO9w7KDPoi4hcC0xO6oRUNrQJEzM43q9bCtupUIRQLUg
|
||
n5ZNWa033e/4pIKOBpHPhE10gSUyn1hla7VLoANGA11dwqrismjvo31VyHW1
|
||
krptsrg6Y6fRCzaY1NDm4+bEXHJAq3Ss50gkOH8SzmMJuqgmYqZWsOXhqbvg
|
||
ajdWqEBqBX4u9a0ZiaU2DmCRknKi2SJpZCUsn9E2dKAVZ+MLFCyNoRu5IpqT
|
||
BwSvTNhQR+11VX1aLWE64x0uXmzC4Ar4rbeXarH+s0IMHobEQwEjnCPMrjHm
|
||
mOujt9UjdfZSqeIqmLJw2GKAV8GJoKMnDe42nGfkh3BsBwE3rjVjkhMLmx/m
|
||
ahntOifsv7FkMMJat2I7b0Ixsh714lfQGbs+q2iih1oKPnqvuU2OiaDVUAgz
|
||
J4VDd6IyZNVo1bvhiRlYj4NjLnDVcMDhZo5oh3mDpiGBrpUrMltgrE8Q/Q2P
|
||
9jjMhHAgWjBFTkoHJEeQm4RnUvAJifmxb4aP9kLYQkpI45YjFypLIMbIIcy5
|
||
fWL4GDsplhTRpJbbFuVx2mnGFB4i8omekGii4TEW4AphYp98CakGxV60QtBR
|
||
0BbG1ZRcpjahXTTb4whfu95tMU1PmwZ8Tgz7GiEyF8BBrVqaud/Swv/m5Dmi
|
||
QtFNrgLJupZIp5Vd5SXjSZCX3EkJNmYRuN4oXyEJ8Rr6uSRtFvAKIRKjFITY
|
||
PzgyKIuJnlzoq5SxIg4C5zjiX5rgcoovi1NurAYJ0jux4/dci5rWT3XK1GPW
|
||
8iMCeAfbHXmgkxiqMVvDE2n01RZtfYxr8R5qTRoYzza9lE8r5ay0lJQXutyx
|
||
W0FwQQq7naNCZR29FDv/bRa0vbIHnGLiQjj3sAtUJKm9LS8K1y046eHmRH1V
|
||
H0vqFPeHQkq9bVRX7FOHaEwSKWbXpRikGKtPCONIeXFaxc85EXahrdmfXLsD
|
||
EppcEKEiqNgQBTfwJ6ANVUU72wAFjsHkiIciKLN4Ay+OZDrjZrMTMZQOf9Oh
|
||
YA10IICzWQKzrblsVxNZom8QknbdbpVexXu3XyOJdoqyyrCIo0CUxsiD3Q3M
|
||
JUIQX9lhS3ypE0v6nTiSGTacniJD9um2aoU98ZK+ZnFDLOTTrVDEEHzFm5IU
|
||
cbH2NBy7VYl3qwDKtpgXzLkoScLB5yIf1RkrW6zpU0nebDJSD/nVLq930hpx
|
||
2rbIO12JhxXo0HkTzZxtjW5PSdPz35+kUSQgYT/WxVtIznB2EI/CIJL4D9rU
|
||
OI2iDRoZQ0EG4lYURFbXGCkX8D58EYjKFG0VWkOusR2Pk05rBhhpspLMiI1N
|
||
IlecnqjR2DGNWbxys7eTlOjFCXKJXwmRs++S0ITn2uCmea2WsQTXNPXRuKUk
|
||
cufqSUBWQ6bV52DDbbRKx/YmK8kjSunx9A2PGEIGRFNOPRHCBXiEZF+uffP6
|
||
mrUc/kvglfJU40Jz6MtMtLb6d4rGwnSYxtlNeZP4GoZOTo+AxgiWM69qNTKx
|
||
VaRx9jUyc3Ab0wa6rjIueJpZeU1GrAbVCKEkymZ5iXW0cTprvdnwJm/zmVAU
|
||
q9MdTVBgNaZ3MlJg4xBAQk01ao+lcpl7RqXsp1gf0FpXAfq4uZCDFyxP51k9
|
||
uRMbR1FFdtkKoya4IBvagehQygp5ahvwoB7WQW86Ta+Hl2g0ZzCjWHVofVf3
|
||
WEVv9y76kwWkRCzIZqL9QO2Jm0kBhza8zbTIdod+3mKEFtppvYcV2ts7CUyx
|
||
bTvJgkbyH3SAycj6tIAzl528cbXUarDLVJ3THzp9Gd6cT+nXlE20UDl/6srR
|
||
Niy8rIQyYbLqRKRCjoYAkyBxL7yner1Xi8UZwBDIEg3JjVTGvKruUGmyH2ry
|
||
GOiJFydN1+LMdIBdsPjkoNh29WkrdDVu+hxIFldIaatlt63KjRlFisYI7Lk0
|
||
qkyLlaSmKpirTSKW43fGYWG7yZ4M7+93G/pfuBojsriUlcdRNV40tGVi6eBq
|
||
R80R8zqt5G3i/4iXaEzPTwSzvXEnEz+gu2hevfGTKJAC1kAPdxr4qgqshP6G
|
||
mrOK4Jeqlsf0GSYNeU0rpOxsJ9K0MuouAm8Jt64uET/5ySsZfWfXJRaMJb+s
|
||
1KF1y/WSTobI3SC1KnkxkUy56E1uY0JJZeoASTYz+quygIFPUHMFjDgHqnNG
|
||
69gq9zlS4mTIzLywxHLnDQmdzFsHDGIsv8wG7Xetcu7HXxsXSlWa+amriiXX
|
||
rIOs+kkiXx8A0cb14PmYrPi6V+u4pRuUZxhwLCvaPJmhKAoMGl/FoUgXirNM
|
||
QrkMGxXRTLuks54h8wjNqTz848OVTgDZyD2rdfCCi2a4rVuKZjaNSqUb1D2S
|
||
QgDlMKNqyMBF2tHfQnb6rUbi/WDYZqOwNGK+qL4ULcPJDrvadefAFeZ9YRet
|
||
apU5q1Jcn0SGYsp73bhghDmFq5uN1ztfjJX4uhzPyQXkLh8OcbgN1Ft/e3Ml
|
||
dqrDBhe+ZP9sqV4Sl+oZc8bc0psU1G/v9/Muknk+Q0IkqsQLAPlRbMyaoe7C
|
||
BfHQ0oGCInpDjlhJuVqzEytibfsaUK3/5AKuKKeHCgkNEqEtjnyn+/uNPjTp
|
||
7pDeqQb789oSy2djaLw1iMaNlOefl5yyAQ9FvF7yvEUp/pPkBEv4U+mkEN6A
|
||
whqyxaxN/HtijXTGPnqzBE+PlfMQD1kKNoYhx7cXGTM8XNirIo5CpIHmeN+s
|
||
lQzhUh9sXWGpL3cMwSzaUrx3wm/IgMkriTaWlkpaJuoVdKnpIftEY+f8d9yR
|
||
xLgQDjsevtVJJvr55iWMaORMCghQWjadGGq9U4vfiVdRBiAFT2zMVmSN001x
|
||
j6a/vSisGhMS0l/jCZKyYoX4yg8tFw6puuHVxcVeIII3eUkU87dQI99m6SK6
|
||
9mUnFetdVkNBYQdfmKN0dcBhqHDYmxOMfC3ppDOlQoPUGx3ZexCVc1cAzFIN
|
||
RYNZOVshERITGdpWotZG0RfMLcNt3LSHhzHPwATdk0DhlxKSn68WGabfZBPG
|
||
qxIJB7EtuElSCbQmTzH2CSYy5d0cud/h5NmKJDnrwlIiSsl23GjwSlM/POF0
|
||
zFk/tJPUVaEMEByfOMcTu0YZP5aO5THM+NQ5Xwmnc0JatGs6AQXsgm3Je8ni
|
||
iYvEo3UXbMO+QssxCH5VNeScc9UNDvrXzgo/mQ+14d4AcZyuFgg4XSK3Oi6F
|
||
830S8uokp1+uCsfxocFbWH64MR0OlK0srrS8l2x4la5BqFgbPyVM303m0UU1
|
||
bYzsRJHd7MMRGtuAWS4qtSKrNOwm2RmZG8ThW/IFE20v1vUcpLHc0vQnFtPq
|
||
zovTt6fbVMEbSB1zg5EJ73gggVYJ92bkaia50akFGn9SczW0h7AM4wEMiWtz
|
||
CBs0A/f0uucbADgSyQwFT5BPTlwziABzvRq18Y/dwsokeecTnNH4MdSylGR1
|
||
XS4V/9t+PHeN5eMObnDD81GOmkSfwcxkLJXrxuDoX6hv0yJUjC6Ky1D3Na8v
|
||
E7hdmpEQt9H/qGfHI1U2WyA7zY8+QbYJNMQLwNmRQ4OJFI4uOmEufqblWWip
|
||
At9cXXB2tXIB0N78kJPuBGry9cMhapBIJtbRTYFUeOTjxo0hgLox2VztNmA+
|
||
pApMaAskRLlmp8im4K7RwIyRygIAb7IZbSHp32Gzp69qzEvyjUIXffzLG+zS
|
||
VsSfU9zD9ImDDPckopBlODa+aABhUCvLctWejAIw01XNCq0H05bPKOxv+ybC
|
||
hUo9Qi7hip8ks/jyLfjCR3zFoHc3CHynOol/+xcbkjPSrzNpt2TlwHfyhygg
|
||
OeJ+Z+5c7ggQND7zb2ksMb78X8qVTnOzkyyv1jB8eLgmQqDkE3L8lSexDwHd
|
||
nsL1Fg0TCtx6kGyVPXKnky8b/ZnEc1zQih/hVWcl0/d1r2TEjQHuMcK+6c3t
|
||
7s9262FObIL/J5jTPF9ecoPAoDd7VLb/Pbn8m9wneHT/eBHMLFwTUjnzpELX
|
||
3vnI42/Jbydpmp7w/43+PKEf0DRCN7sPquhkW67u/I2Jjf4DeynMN/qC9Yyz
|
||
J+ln8S4ecgMi65CvPkiylX7RVhtpWoyMzq8+6mx83MU2BNvQr/SKe277VBpZ
|
||
wbkFdOOl2B7/9BIg+N+ikR0yd6QL+IZx+Ru3ZXNNll50Ldk7qLBBOzY+noBW
|
||
KBgQ70lwn6FoiehzhXgu/v5Cy4rMtJN/HXCEdOAo1WkalwRvuCdaqzflOx9Q
|
||
BliH7lmI48wxiHl1l3RSxZERHExAtQtJqr+t8IGR/hwkP53bAQIjUT7WI+XW
|
||
UkIGW959puCi1EHYorlRFBonp7RnRk0NHsqeYGiV6xTpEIzGyTkMcRmFIUgm
|
||
lWTiIzREYgumx3YcXnCKbSOKAV3G9orThpyXyctbkgUsF0ZZ+embJvExbM6f
|
||
w68Ua7RkZSbOKG2ItF/myzrGay1q1KfFg+EIge+DbzspEFk0bi+LW8s0/40g
|
||
lZ+vzbo9CuhmPDZaYjI8aJPHyMWvTLvYOkSnfRYFmLCBIHQUQmeYNGPDzTog
|
||
nS1RjNMjcoOruiUpmVfmHblve/I1GszTYzpKDw+PpEeoxjATqSBHQ7Of2xIv
|
||
rINb4AdK0ZmbWSaFjH+zH5dut498Uw9IOYHGLUeOrx7Rngf5ewL5TM7rHd+9
|
||
BeJHX4e4t4ubTsOL9sHmM/kov32UB/tAb8fsIwLTl1tsgfFxgNHhed/D/w/i
|
||
OSoh7YItPtNHpouP0V0BvMdm6FX7FuiON6B7/A/CFNuhMUg6uV9g6g6YYTHg
|
||
J2NsERQqHrxqHOhkM5KgyIxIN77MI0o80Q63k9weygQdmQy3nS9o7S/xm/3V
|
||
bP3fX3p0JAiS//237Y+4/z2MbjW3X7vzNtzpCWe443j34lW7b5BsrmxIFf5j
|
||
Ox6DD6PT+9o+Ww42nWSzrxwuHR2fJ5QW3g5FLO1dpSkOzQdOQHCS0Iyl7n7S
|
||
1ZebWoKk+5SLE1QCRyVQTK+uQEKHdsZdphg8gUYeDZsic2e4qVVmrvP3Qyx6
|
||
ub3Ul+x8iH50FMo3zeY4/XcyKJIJe7vyI83ZHcDjP3iwy+DY+gmtr33M6T/0
|
||
ISdnmCB36fNFU/+tMrNacrF9LuNaxHAYrfICyagPFzcPP1xhgk9Dei0Z3M0r
|
||
6WPKNV/8Jw0hcwV63jr/S9IPWnhICKfbaIfCdlJ0Ay7CnOSTaD1CPd1LFv/M
|
||
athUBk+j99pDn2JIQtqL4E8736cL5fbqkSfNumntQqORl/AmzaODQ/Utzj+P
|
||
xSkIY/IR/WVbc/spRjMwOxOvdq7szwupOjdPs4k2607cVMcxsnid36Mx6ig8
|
||
rSXCPFMOlV7wm2Q6XTTEhsk8QcG6JMWljhoj7eVMM8ncVkhRz7Niyt/7mFeL
|
||
gwHKfHB2gMeNrWtWSNrlMA0599LYxahgs5mX9c157NEX6wRDO8iXGfIUCoFd
|
||
5+f5jkCui0ZjcGndm/CNe/tJNIkn66VH/evEcfbuh1H2OWMn339ArHHT+uY8
|
||
RVTu6r0ZfL0y81OrGeM8mkHLPzxcyQiZOJ7jPYQwo3X2DHeQkLFbz9ixHIqU
|
||
23M0VrNlmIRKEp7tc/rDga+k01g+o9h9PUFm0Y/beJprlK/QsUOJVNU+DDNm
|
||
ffJ0c+ZrTEtqU0O66xdNRCCgzLaaAZYTvd0ZyUw/UewdNLM/2MLoKGCe0OHy
|
||
vGa+woHxg4FkasNnDfVjhNv5Tvhr8+5YDO76UOKXLwkyUNmMi2Q6hOTicToM
|
||
yn+dIvrOnfDdzecyFc4ekHf18a5wTEjiaLVYyTQQHsu4yNIQHEUjcKJf0JHP
|
||
4eknE13TkybvJHfL0EbRWJwo8gK20dElEr/2TTQVw5kKbfo6ZCIkXzkUgO2T
|
||
myvQkQI35lph1pMtryEDff2Y3ED1XMmyIFKXvHzwnLllSaeMeawSJzT89TY0
|
||
G2jlDM8YvYOhYLOF03iNDDkLQxm4npZp3r2QjNIJ47kDTNJDR7ROkunAvxwx
|
||
jzpnJ/p1sa1HIgEAdyRYmw/dGw4bFOgqJ+J+XYXxOy3KiXYh/N/hqwZceSyf
|
||
ICpFUUx8gshV4insPQEmnyjCV61KpP5IWHGt1EbZCTpn9EtVvW/qIpCuK3el
|
||
2VaxdSKdCJAMkUucwAdp541O24eB5ieSquubmeBAy4gj5EgtBrdjzpFqBn+e
|
||
SmIKk/28lCC0HE3krichXSojiFzo3QVqGtSW/YPfTUU6NZuosZDEVTXRUB/k
|
||
83WTj+P282CPix1jvCahravuTh5yQp3HlWwKr8zHDDg5ic8vZ0HUBKnV139O
|
||
bA0HbEI52s2bSCJzflFmlP1bV70TpmrzMylYMc5c+kglexI3jHRMLdqNw5fd
|
||
TpV9PWexIhIpa7w64le+esRjyE/LxA1ZEUC1bBEjDIV4orfWOou4Rko7nXk2
|
||
YNx7Eck80dWwWQdtO1fhnLgRxVwf/XVzGSljRD3TUY7dEizF9S7jKnX84WH8
|
||
joc6LnLUfeH+jlxO9JuYjSTUlhXrc7g73M8eMjVagxU1Tt5oWmjY+czx3g6V
|
||
2PkU8v1956vJzoNQIOPuTM09OcvYOwrVCNLX29Xc5jhazWYuT0XuHHLAgm2u
|
||
xhHfT0Jvt5zuzVHl0mZoTMvWzUnwLDaq5N0XxIiO0jCDfUfrynd+oUR611J7
|
||
m4tk0W+tItEZvgKk97tJTr3RhjWqqb9z40l7NTiRF8GTx1caf3RGZhKVTHRR
|
||
0j0PmbzewArTtoBQwJBowxrpmZY1sqzJA20mrlx0S7+p78j2U6NcTQIX+fXO
|
||
2G6VL/JLsv3QRR5049qCli0xbb4N9QChfLuLAt5qM9xtpbxFunm04bp2Ml54
|
||
4sPjM+TJbq3En6QMiJsnh1fvLn/awRAsAfAk3RI/4/w0iBBxJJGNueU/WCzR
|
||
wXCHdKLfAAme0zIAESU+Md2J9pARR2IsL7KlmGoFl8nJPAJVAsQHDJLumm90
|
||
1KHom+Xmvt7oAuPxTd3vp2lXpoBBDnrWXJQij79fD7zGjJZoHFhS0BcMhYNg
|
||
LfLmK+RP3r14+fDyw2uHGYDc4RDXBp+4XF8oJCiimu8a070WNiUv0U6kIInr
|
||
E0T78Wfzup3lgYWFspX/mJlEaYz4OyjyRe62ShhkHew8dWVqcYEAi5VwjGkm
|
||
vRVxVOD67OLmxgyvV1zjesbWtG8V2NdB2bCvxut91eRk9XyFCGXBXWGezS/D
|
||
R7GELOkGNFq/eRuKBWT8qIAbG/+OKbkwVGHYFADaeCbV3BpJyEr5SE6SiRfj
|
||
+TEeDkr7yKrXQghIN1udPIfvYfOkhzI6NqmTlBHIMbRthFEFXUY7jNHdgcok
|
||
XnU3gsU8YHn8qdH+QccdYFv+2otzivM6CntlBbd7wyDa/EJ4roOdUyGPzsgG
|
||
9ZA9w5MdteNLp4L/bUO3g9jtFHFvD8r1rPbPbeKKRvJGA3XJ/wHrwy7TIIQA
|
||
AA==
|
||
|
||
-->
|
||
|
||
</rfc>
|
||
|