draft-farley-acta-signed-receipts-01.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-farley-acta-signed-receipts-01" category="info" version="3">
  <!-- xml2rfc v2v3 conversion 3.32.0 -->
  <front>
    <title abbrev="Acta Signed Receipts">Signed Decision Receipts for Machine-to-Machine Access Control</title>
    <seriesInfo name="Internet-Draft" value="draft-farley-acta-signed-receipts-01"/>
    <author initials="T." surname="Farley" fullname="Tom Farley"
            orcid="https://orcid.org/0009-0009-7373-5650">
      <organization>Veritas Acta</organization>
      <address>
        <email>tjf@veritasacta.com</email>
        <uri>https://veritasacta.com</uri>
      </address>
    </author>
    <date year="2026" month="April" day="1"/>
    <area>Security</area>
    <workgroup>Independent</workgroup>
    <keyword>MCP</keyword>
    <keyword>receipts</keyword>
    <keyword>Ed25519</keyword>
    <keyword>access-control</keyword>
    <keyword>AI agents</keyword>
    <abstract>
      <?line 40?>

<t>This document defines a portable, cryptographically signed receipt
format for recording machine-to-machine access control decisions.
Each receipt captures the identity of the decision maker, the tool
or resource being accessed, the policy evaluation result, and a
timestamp — all signed with Ed25519 <xref target="RFC8032"/> and serialized using
deterministic JSON canonicalization <xref target="RFC8785"/>.</t>
      <t>The format is designed for environments where AI agents invoke tools
on behalf of human operators, particularly the Model Context Protocol
(MCP) ecosystem. Receipts are independently verifiable without
contacting the issuer, enabling offline audit, regulatory compliance,
and cross-organizational trust federation.</t>
    </abstract>
  </front>
  <middle>
    <?line 55?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>As AI agents increasingly act autonomously — invoking tools, accessing
APIs, and modifying state — there is a growing need for cryptographic
evidence of what decisions were made, by whom, and under what policy.</t>
      <t>Current approaches rely on centralized logging (e.g., CloudWatch, SIEM
ingestion), which requires trust in the log operator and provides no
independent verifiability. A compromised or malicious operator can
silently alter or omit log entries.</t>
      <t>This specification defines a <strong>Signed Decision Receipt</strong> format that
provides:</t>
      <ol spacing="normal" type="1"><li>
          <t><strong>Portable evidence</strong>: Receipts are self-contained JSON objects
that can be stored, transmitted, and verified independently.</t>
        </li>
        <li>
          <t><strong>Cryptographic integrity</strong>: Each receipt is signed using Ed25519
(RFC 8032), ensuring tamper detection without PKI infrastructure.</t>
        </li>
        <li>
          <t><strong>Offline verification</strong>: Any party with the issuer's public key
can verify a receipt without network access or API calls.</t>
        </li>
        <li>
          <t><strong>Minimal disclosure</strong>: Receipts capture the decision metadata
(tool name, decision, tier, timestamp) without logging raw request
payloads, prompts, or sensitive parameters.</t>
        </li>
      </ol>
      <section anchor="relationship-to-mcp">
        <name>Relationship to MCP</name>
        <t>The Model Context Protocol <xref target="MCP"/> defines a JSON-RPC transport for
AI tool invocation but provides no built-in access control, auditing,
or accountability mechanism. This specification is designed to be
deployed at the MCP transport layer (typically as a stdio proxy)
without modifications to the MCP protocol itself.</t>
        <t>This specification is complementary to <xref target="I-D.serra-mcp-discovery-uri"/>,
which defines the mcp:// URI scheme and server discovery mechanism.
Discovery (how an agent finds a server) and accountability (what gets
recorded after the agent uses it) are independently deployable layers.
A server's discovery manifest MAY declare a trust_class that informs
receipt-generating proxies of the server's operating context
(e.g., "regulated"), enabling jurisdiction-aware policy evaluation
without encoding legal regime information in the receipt itself.</t>
      </section>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="receipt-structure">
      <name>Receipt Structure</name>
      <t>A Signed Decision Receipt is a JSON object with two top-level fields:
<tt>payload</tt> and <tt>signature</tt>.</t>
      <section anchor="signed-envelope">
        <name>Signed Envelope</name>
        <artwork><![CDATA[
{
  "payload": { ... },
  "signature": {
    "alg": "EdDSA",
    "kid": "<issuer-identifier>",
    "sig": "<hex-encoded-ed25519-signature>"
  }
}
]]></artwork>
        <section anchor="signature-object">
          <name>Signature Object</name>
          <dl>
            <dt>alg (REQUIRED):</dt>
            <dd>
              <t>The signature algorithm. MUST be "EdDSA" for Ed25519 as
defined in RFC 8032.</t>
            </dd>
            <dt>kid (REQUIRED):</dt>
            <dd>
              <t>The key identifier of the signing key. This is an opaque string
that SHOULD resolve to a public key via a well-known endpoint
or out-of-band distribution. The RECOMMENDED format is
<tt>sb:issuer:&lt;base58-fingerprint&gt;</tt> where the fingerprint is the
first 12 characters of the Base58-encoded Ed25519 public key.</t>
            </dd>
            <dt>sig (REQUIRED):</dt>
            <dd>
              <t>The Ed25519 signature over the canonicalized payload, encoded
as a lowercase hexadecimal string (128 characters for 64 bytes).</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="payload">
        <name>Payload</name>
        <t>The payload is a JSON object whose schema depends on the receipt type.
All payload types share the following common fields:</t>
        <dl>
          <dt>type (REQUIRED):</dt>
          <dd>
            <t>A namespaced string identifying the receipt type.
Examples: <tt>"protectmcp:decision"</tt>, <tt>"protectmcp:restraint"</tt>,
<tt>"blindllm:arena-battle"</tt>.</t>
          </dd>
          <dt>issued_at (REQUIRED):</dt>
          <dd>
            <t>ISO 8601 timestamp <xref target="RFC3339"/> of when the receipt was created.
MUST include timezone designator (typically "Z" for UTC).</t>
          </dd>
          <dt>issuer_id (REQUIRED):</dt>
          <dd>
            <t>The identifier of the entity that issued and signed the receipt.
MUST match the <tt>kid</tt> field in the signature object.</t>
          </dd>
          <dt>payload_digest (OPTIONAL):</dt>
          <dd>
            <t>A content-addressable hash of associated data (tool input,
tool output, or other large payloads) that exceeds a size threshold.
Format: an object containing "hash" (SHA-256 hex string), "size"
(byte count), and optionally "preview" (first 256 characters).
Enables integrity verification of associated data without embedding
it in the receipt.</t>
          </dd>
          <dt>hook_latency_ms (OPTIONAL):</dt>
          <dd>
            <t>The time in milliseconds spent evaluating the policy decision.
Enables operators to verify that security middleware adds negligible
overhead.</t>
          </dd>
          <dt>tool_duration_ms (OPTIONAL):</dt>
          <dd>
            <t>The time in milliseconds between the initiation and completion
of the tool invocation. Present only in post-execution receipts.</t>
          </dd>
          <dt>sandbox_state (OPTIONAL):</dt>
          <dd>
            <t>Whether the execution environment had OS-level containment
active at the time of the decision. One of: "enabled", "disabled",
"unavailable". Enables auditors to verify that agent actions occurred
within a sandboxed environment.</t>
          </dd>
          <dt>spec (RECOMMENDED):</dt>
          <dd>
            <t>The identifier of the specification version this receipt
conforms to. Format: the IETF Internet-Draft document name
(e.g., "draft-farley-acta-signed-receipts-01"). Ties every receipt
to the standard, enabling format-level interoperability verification
across implementations.</t>
          </dd>
          <dt>issuer_certification (OPTIONAL):</dt>
          <dd>
            <t>The certification level of the receipt issuer. One of:
"scopeblind:verified" (issued via a VOPRF-backed credential backend),
"self-signed" (signed with a locally-generated Ed25519 key),
"uncertified" (unsigned receipt). Enables auditors to distinguish
between cryptographically-certified and self-attested receipts.</t>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="receipt-types">
      <name>Receipt Types</name>
      <t>This specification defines six receipt types. Implementations MAY
define additional types using the namespaced <tt>type</tt> field.</t>
      <section anchor="access-decision-receipt">
        <name>Access Decision Receipt</name>
        <t>Type: <tt>protectmcp:decision</tt></t>
        <t>Records the outcome of a policy evaluation for a tool invocation.</t>
        <artwork><![CDATA[
{
  "type": "protectmcp:decision",
  "tool_name": "delete_database",
  "decision": "deny",
  "reason": "tier_insufficient",
  "agent_tier": "signed-known",
  "required_tier": "privileged",
  "policy_digest": "sha256:a8f3...c91e",
  "session_id": "ses_7f8a2b",
  "issued_at": "2026-03-22T14:32:04.102Z",
  "issuer_id": "sb:issuer:4Kpm7Q3wXx2b"
}
]]></artwork>
        <section anchor="fields">
          <name>Fields</name>
          <dl>
            <dt>tool_name (REQUIRED):</dt>
            <dd>
              <t>The name of the tool being invoked, as declared in the MCP
<tt>tools/list</tt> response.</t>
            </dd>
            <dt>decision (REQUIRED):</dt>
            <dd>
              <t>The policy evaluation result. One of: <tt>"allow"</tt>, <tt>"deny"</tt>,
<tt>"rate_limit"</tt>.</t>
            </dd>
            <dt>reason (OPTIONAL):</dt>
            <dd>
              <t>A machine-readable reason code for the decision.
Examples: <tt>"tier_insufficient"</tt>, <tt>"rate_exceeded"</tt>,
<tt>"policy_block"</tt>, <tt>"agent_refusal"</tt>.</t>
            </dd>
            <dt>agent_tier (OPTIONAL):</dt>
            <dd>
              <t>The trust tier of the requesting agent at the time of the
decision. One of: <tt>"unknown"</tt>, <tt>"signed-known"</tt>,
<tt>"evidenced"</tt>, <tt>"privileged"</tt>.</t>
            </dd>
            <dt>required_tier (OPTIONAL):</dt>
            <dd>
              <t>The minimum trust tier required by the policy for this tool.</t>
            </dd>
            <dt>policy_digest (OPTIONAL):</dt>
            <dd>
              <t>A content-addressable hash of the policy document in effect
at the time of the decision. Format: <tt>"sha256:&lt;hex&gt;"</tt>.</t>
            </dd>
            <dt>session_id (OPTIONAL):</dt>
            <dd>
              <t>An opaque identifier for the MCP session. MUST NOT contain
PII or be correlatable across sessions unless the operator
explicitly configures session binding.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="restraint-receipt">
        <name>Restraint Receipt</name>
        <t>Type: <tt>protectmcp:restraint</tt></t>
        <t>Records an agent's interaction with a policy boundary, specifically
whether the agent attempted to use a restricted tool and whether the
restriction was enforced by an external policy or self-imposed.</t>
        <artwork><![CDATA[
{
  "type": "protectmcp:restraint",
  "agent_id": "sb:agent:8xKm3Qw2Yb1c",
  "agent_manifest_version": "1.2.0",
  "tool_name": "rm_rf",
  "decision": "deny",
  "denial_type": "policy-block",
  "issued_at": "2026-03-22T14:35:12.441Z",
  "issuer_id": "sb:issuer:4Kpm7Q3wXx2b"
}
]]></artwork>
        <section anchor="fields-1">
          <name>Fields</name>
          <dl>
            <dt>agent_id (REQUIRED):</dt>
            <dd>
              <t>The identifier of the agent whose tool call was evaluated.</t>
            </dd>
            <dt>agent_manifest_version (REQUIRED):</dt>
            <dd>
              <t>The semantic version of the agent's manifest at the time of
the decision.</t>
            </dd>
            <dt>tool_name (REQUIRED):</dt>
            <dd>
              <t>The tool that was called or attempted.</t>
            </dd>
            <dt>decision (REQUIRED):</dt>
            <dd>
              <t>One of: <tt>"allow"</tt>, <tt>"deny"</tt>.</t>
            </dd>
            <dt>denial_type (OPTIONAL):</dt>
            <dd>
              <t>If the decision is <tt>"deny"</tt>, indicates whether the denial was
imposed by external policy (<tt>"policy-block"</tt>) or self-imposed
by the agent (<tt>"agent-refusal"</tt>).</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="arena-battle-receipt">
        <name>Arena Battle Receipt</name>
        <t>Type: <tt>blindllm:arena-battle</tt></t>
        <t>Records the outcome of a competitive evaluation between two AI agents,
as conducted by a neutral arena platform.</t>
        <artwork><![CDATA[
{
  "type": "blindllm:arena-battle",
  "battle_id": "bat_9x8f7a2b",
  "lane_id": "lane_creative_writing",
  "agent_a": {
    "id": "sb:agent:3mK9pQ7wXx2b",
    "manifest_version": "2.1.0"
  },
  "agent_b": {
    "id": "sb:agent:8xKm3Qw2Yb1c",
    "manifest_version": "1.4.0"
  },
  "winner": "A",
  "issued_at": "2026-03-22T15:00:00.000Z",
  "issuer_id": "sb:issuer:4Kpm7Q3wXx2b"
}
]]></artwork>
        <section anchor="fields-2">
          <name>Fields</name>
          <dl>
            <dt>battle_id (REQUIRED):</dt>
            <dd>
              <t>Unique identifier for the battle instance.</t>
            </dd>
            <dt>lane_id (REQUIRED):</dt>
            <dd>
              <t>The evaluation category or "lane" in which the battle occurred.</t>
            </dd>
            <dt>agent_a, agent_b (REQUIRED):</dt>
            <dd>
              <t>Objects identifying each participant, containing:
- <tt>id</tt>: The agent's passport identifier.
- <tt>manifest_version</tt>: The agent's manifest version at battle time.</t>
            </dd>
            <dt>winner (REQUIRED):</dt>
            <dd>
              <t>One of: <tt>"A"</tt>, <tt>"B"</tt>, <tt>"tie"</tt>.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="agent-lifecycle-receipt">
        <name>Agent Lifecycle Receipt</name>
        <t>Type: <tt>protectmcp:lifecycle</tt></t>
        <t>Records agent lifecycle events in multi-agent orchestration systems
(swarms, coordinator mode, scheduled agents). Enables reconstruction
of the full agent topology from the receipt DAG.</t>
        <dl spacing="compact">
          <dt>lifecycle_event (REQUIRED):</dt>
          <dd><t>One of: <tt>"subagent_start"</tt>, <tt>"subagent_stop"</tt>,
<tt>"session_start"</tt>, <tt>"session_end"</tt>, <tt>"task_created"</tt>,
<tt>"task_completed"</tt>, <tt>"teammate_idle"</tt>, <tt>"config_change"</tt>.</t></dd>
          <dt>agent_id (OPTIONAL):</dt>
          <dd><t>The identifier of the agent involved in the lifecycle event.</t></dd>
          <dt>agent_type (OPTIONAL):</dt>
          <dd><t>The type of agent (e.g., <tt>"coordinator"</tt>, <tt>"worker"</tt>,
<tt>"standalone"</tt>).</t></dd>
          <dt>parent_session_id (OPTIONAL):</dt>
          <dd><t>The session identifier of the parent/coordinator agent.
Creates a verifiable parent-child relationship in the receipt DAG.</t></dd>
          <dt>team_name (OPTIONAL):</dt>
          <dd><t>The team or swarm name, if operating in multi-agent mode.</t></dd>
        </dl>
      </section>
      <section anchor="spending-authority-receipt">
        <name>Spending Authority Receipt</name>
        <t>Type: <tt>scopeblind:spending_authority</tt></t>
        <t>Records the outcome of an issuer-blind spending authorization check.
Proves that an agent's purchase is within authorized limits without
revealing organizational identity, budget ceiling, or delegation chain.
Verification uses VOPRF (RFC 9497).</t>
        <dl spacing="compact">
          <dt>amount (REQUIRED):</dt>
          <dd><t>The monetary amount of the transaction.</t></dd>
          <dt>currency (REQUIRED):</dt>
          <dd><t>ISO 4217 currency code (e.g., <tt>"USD"</tt>).</t></dd>
          <dt>category (OPTIONAL):</dt>
          <dd><t>A classification of the spending type (e.g.,
<tt>"cloud_compute"</tt>, <tt>"saas_subscription"</tt>).</t></dd>
          <dt>utilization_band (OPTIONAL):</dt>
          <dd><t>A coarse indicator of budget utilization. One of:
<tt>"low"</tt> (&lt;25%), <tt>"medium"</tt> (25-75%), <tt>"high"</tt>
(75-100%), <tt>"exceeded"</tt>. The exact budget ceiling is NOT
disclosed -- only the band -- preventing price discrimination while
proving budget compliance.</t></dd>
          <dt>decision (REQUIRED):</dt>
          <dd><t>One of: <tt>"allow"</tt>, <tt>"deny"</tt>.</t></dd>
        </dl>
        <t>The receipt deliberately EXCLUDES: organization name, total budget
ceiling, exact remaining budget, agent identity, and delegation chain.</t>
      </section>
      <section anchor="formal-debate-receipt">
        <name>Formal Debate Receipt</name>
        <t>Type: <tt>blindllm:formal-debate</tt></t>
        <t>Records the outcome of a structured debate with audience and judge
scoring. Extends the arena battle format with additional governance
fields.</t>
        <artwork><![CDATA[
{
  "type": "blindllm:formal-debate",
  "debate_id": "dbt_4f2a8c",
  "spec_id": "spec_ai_safety_v2",
  "lane_id": "lane_policy",
  "artifact_hash": "sha256:b3c4d5e6...",
  "resolution_hash": "sha256:f7a8b9c0...",
  "pro": {
    "id": "sb:agent:3mK9pQ7wXx2b",
    "manifest_version": "2.1.0"
  },
  "con": {
    "id": "sb:agent:8xKm3Qw2Yb1c",
    "manifest_version": "1.4.0"
  },
  "audience_winner": "pro",
  "judge_winner": "pro",
  "restraint_result": "clean",
  "issued_at": "2026-03-22T16:30:00.000Z",
  "issuer_id": "sb:issuer:4Kpm7Q3wXx2b"
}
]]></artwork>
      </section>
    </section>
    <section anchor="signing-and-verification">
      <name>Signing and Verification</name>
      <section anchor="signing-process">
        <name>Signing Process</name>
        <ol spacing="normal" type="1"><li>
            <t>Construct the payload object with all required fields.</t>
          </li>
          <li>
            <t>Canonicalize the payload using JCS <xref target="RFC8785"/>. The canonical
form is a deterministic JSON serialization with sorted keys
and no whitespace.</t>
          </li>
          <li>
            <t>Convert the canonical JSON string to a UTF-8 byte sequence.</t>
          </li>
          <li>
            <t>Sign the byte sequence using Ed25519 <xref target="RFC8032"/> with the
issuer's secret key.</t>
          </li>
          <li>
            <t>Encode the signature as a lowercase hexadecimal string.</t>
          </li>
          <li>
            <t>Construct the signed envelope by wrapping the original
(non-canonicalized) payload with the signature object.</t>
          </li>
        </ol>
      </section>
      <section anchor="verification-process">
        <name>Verification Process</name>
        <ol spacing="normal" type="1"><li>
            <t>Extract the <tt>payload</tt> and <tt>signature</tt> from the envelope.</t>
          </li>
          <li>
            <t>Canonicalize the <tt>payload</tt> using JCS <xref target="RFC8785"/>.</t>
          </li>
          <li>
            <t>Convert the canonical JSON to a UTF-8 byte sequence.</t>
          </li>
          <li>
            <t>Resolve the public key using the <tt>kid</tt> field in the signature.
The RECOMMENDED resolution mechanism is a JWK Set endpoint
<xref target="RFC7517"/> at <tt>/.well-known/acta-keys.json</tt>.</t>
          </li>
          <li>
            <t>Verify the Ed25519 signature over the canonical bytes using
the resolved public key.</t>
          </li>
          <li>
            <t>If verification succeeds, the receipt is authentic and has not
been tampered with. If verification fails, the receipt MUST be
rejected.</t>
          </li>
        </ol>
      </section>
      <section anchor="public-key-distribution">
        <name>Public Key Distribution</name>
        <t>Issuers SHOULD publish their public keys as a JWK Set <xref target="RFC7517"/>
at a well-known endpoint:</t>
        <artwork><![CDATA[
GET /.well-known/acta-keys.json

{
  "keys": [{
    "kty": "OKP",
    "crv": "Ed25519",
    "kid": "sb:issuer:4Kpm7Q3wXx2b",
    "x": "<base64url-encoded-public-key>",
    "use": "sig"
  }]
}
]]></artwork>
        <t>The <tt>x</tt> parameter MUST be the base64url-encoded Ed25519 public key
as specified in <xref target="RFC8037"/>.</t>
        <t>For offline verification, public keys MAY be distributed out-of-band
(e.g., embedded in configuration files, published in DNS TXT records,
or included in agent manifests).</t>
      </section>
    </section>
    <section anchor="trust-tiers">
      <name>Trust Tiers</name>
      <t>This specification defines a four-level trust hierarchy for agent
identity. Trust tiers are used by policy engines to gate tool access.</t>
      <dl>
        <dt>unknown:</dt>
        <dd>
          <t>No identity presented. Default tier for anonymous connections.</t>
        </dd>
        <dt>signed-known:</dt>
        <dd>
          <t>Agent presents a valid signed manifest with a verifiable
Ed25519 public key. Identity is pseudonymous but consistent.</t>
        </dd>
        <dt>evidenced:</dt>
        <dd>
          <t>Agent has accumulated verifiable evidence receipts (e.g., arena
battle outcomes, successful restraint records) that demonstrate
a track record of trustworthy behavior.</t>
        </dd>
        <dt>privileged:</dt>
        <dd>
          <t>Operator has explicitly granted elevated access. Typically
requires out-of-band verification (e.g., organization membership,
contractual agreement).</t>
        </dd>
      </dl>
      <t>Trust tier transitions are unidirectional within a session but MAY
be re-evaluated across sessions based on accumulated evidence.</t>
    </section>
    <section anchor="agent-identity">
      <name>Agent Identity</name>
      <section anchor="passport-manifest">
        <name>Passport Manifest</name>
        <t>An agent's identity is expressed as a signed manifest:</t>
        <artwork><![CDATA[
{
  "type": "scopeblind:agent-manifest",
  "id": "sb:agent:3mK9pQ7wXx2b",
  "version": "2.1.0",
  "previous_version": "2.0.0",
  "created_at": "2026-03-20T10:00:00Z",
  "public_key": "<base58-ed25519-public-key>"
}
]]></artwork>
        <t>Manifests are IMMUTABLE once signed. Version changes create new
manifests that reference their predecessor via <tt>previous_version</tt>,
forming a verifiable version chain.</t>
      </section>
      <section anchor="dpop-binding-future">
        <name>DPoP Binding (Future)</name>
        <t>For remote MCP transports (HTTP/SSE), agent identity MAY be bound
to per-request proof-of-possession using DPoP <xref target="RFC9449"/>. The
<tt>auth_key_bindings</tt> field in the manifest links the agent's Ed25519
identity key to one or more P-256 DPoP keys.</t>
        <t>This binding creates a verifiable delegation chain:</t>
        <artwork><![CDATA[
Operator → Agent Identity (Ed25519) → Request Auth (P-256 DPoP)
]]></artwork>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <section anchor="replay-protection">
        <name>Replay Protection</name>
        <t>Receipts include an <tt>issued_at</tt> timestamp but do not include a nonce
or sequence number. Verifiers SHOULD reject receipts with timestamps
that are unreasonably old (implementation-defined; 24 hours is
RECOMMENDED as a default).</t>
        <t>For environments requiring stronger replay protection, implementations
MAY add a <tt>nonce</tt> field to the payload.</t>
      </section>
      <section anchor="key-compromise">
        <name>Key Compromise</name>
        <t>If an issuer's signing key is compromised, all receipts signed with
that key become suspect. Issuers SHOULD implement key rotation by
publishing new keys at the well-known endpoint and including a
<tt>valid_from</tt> / <tt>valid_until</tt> window in the JWK metadata.</t>
        <t>Verifiers SHOULD check key validity windows when available.</t>
      </section>
      <section anchor="payload-privacy">
        <name>Payload Privacy</name>
        <t>Receipts are designed to capture decision metadata, NOT request
content. Implementations MUST NOT include raw prompts, tool
arguments, API keys, or other sensitive parameters in receipt
payloads.</t>
        <t>The <tt>tool_name</tt> and <tt>decision</tt> fields are considered non-sensitive.
The <tt>session_id</tt> field SHOULD be an opaque identifier that is not
correlatable across sessions.</t>
      </section>
      <section anchor="canonicalization-attacks">
        <name>Canonicalization Attacks</name>
        <t>The signing process relies on JCS <xref target="RFC8785"/> for deterministic
serialization. Implementations MUST use a conformant JCS
implementation to prevent canonicalization divergence attacks where
the signed bytes differ from the verified bytes.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
      <t>Future versions of this specification MAY request registration of:</t>
      <ul spacing="normal">
        <li>
          <t>A <tt>receipt-type</tt> registry for namespaced receipt type identifiers.</t>
        </li>
        <li>
          <t>A well-known URI suffix for <tt>/.well-known/acta-keys.json</tt>.</t>
        </li>
      </ul>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml">
          <front>
            <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8032"/>
          <seriesInfo name="DOI" value="10.17487/RFC8032"/>
        </reference>
        <reference anchor="RFC8037" target="https://www.rfc-editor.org/info/rfc8037" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8037.xml">
          <front>
            <title>CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)</title>
            <author fullname="I. Liusvaara" initials="I." surname="Liusvaara"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8037"/>
          <seriesInfo name="DOI" value="10.17487/RFC8037"/>
        </reference>
        <reference anchor="RFC8785" target="https://www.rfc-editor.org/info/rfc8785" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8785.xml">
          <front>
            <title>JSON Canonicalization Scheme (JCS)</title>
            <author fullname="A. Rundgren" initials="A." surname="Rundgren"/>
            <author fullname="B. Jordan" initials="B." surname="Jordan"/>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
            <date month="June" year="2020"/>
            <abstract>
              <t>Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results.</t>
              <t>This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8785"/>
          <seriesInfo name="DOI" value="10.17487/RFC8785"/>
        </reference>
        <reference anchor="RFC3339" target="https://www.rfc-editor.org/info/rfc3339" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml">
          <front>
            <title>Date and Time on the Internet: Timestamps</title>
            <author fullname="G. Klyne" initials="G." surname="Klyne"/>
            <author fullname="C. Newman" initials="C." surname="Newman"/>
            <date month="July" year="2002"/>
            <abstract>
              <t>This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3339"/>
          <seriesInfo name="DOI" value="10.17487/RFC3339"/>
        </reference>
        <reference anchor="RFC7517" target="https://www.rfc-editor.org/info/rfc7517" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7517.xml">
          <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="RFC9449" target="https://www.rfc-editor.org/info/rfc9449" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9449.xml">
          <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>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="MCP" target="https://modelcontextprotocol.io/specification">
          <front>
            <title>Model Context Protocol Specification</title>
            <author>
              <organization/>
            </author>
            <date year="2025"/>
          </front>
        </reference>
        <reference anchor="I-D.serra-mcp-discovery-uri" target="https://datatracker.ietf.org/doc/draft-serra-mcp-discovery-uri/">
          <front>
            <title>The mcp URI Scheme and MCP Server Discovery Mechanism</title>
            <author initials="M." surname="Serra" fullname="Marco Serra">
              <organization>Mumble Group</organization>
            </author>
            <date year="2026"/>
          </front>
        </reference>
      </references>
    </references>
    <?line 491?>

<section anchor="implementation-status">
      <name>Implementation Status</name>
      <t>This section records the status of known implementations of the
protocol defined by this specification at the time of publication.</t>
      <section anchor="protect-mcp-reference-implementation">
        <name>protect-mcp (Reference Implementation)</name>
        <ul spacing="normal">
          <li>
            <t>Organization: ScopeBlind</t>
          </li>
          <li>
            <t>Implementation: https://www.npmjs.com/package/protect-mcp</t>
          </li>
          <li>
            <t>Description: A stdio proxy for MCP servers that generates signed
decision receipts. Supports shadow mode (log-only) and enforce
mode (policy evaluation).</t>
          </li>
          <li>
            <t>Coverage: Access Decision Receipts, Restraint Receipts.</t>
          </li>
          <li>
            <t>Licensing: MIT.</t>
          </li>
        </ul>
      </section>
      <section anchor="veritasactaverify-verifier">
        <name>@veritasacta/verify (Verifier)</name>
        <ul spacing="normal">
          <li>
            <t>Organization: Veritas Acta</t>
          </li>
          <li>
            <t>Implementation: https://www.npmjs.com/package/@veritasacta/verify</t>
          </li>
          <li>
            <t>Description: Standalone CLI and library for offline receipt
verification. Zero runtime dependencies on ScopeBlind.</t>
          </li>
          <li>
            <t>Coverage: All receipt types defined in this specification.</t>
          </li>
          <li>
            <t>Licensing: MIT.</t>
          </li>
        </ul>
      </section>
      <section anchor="scopeblindpassport-identity-sdk">
        <name>@scopeblind/passport (Identity SDK)</name>
        <ul spacing="normal">
          <li>
            <t>Organization: ScopeBlind</t>
          </li>
          <li>
            <t>Implementation: https://www.npmjs.com/package/@scopeblind/passport</t>
          </li>
          <li>
            <t>Description: Agent identity SDK for generating manifests, signing
receipts, and managing trust tier evidence bundles.</t>
          </li>
          <li>
            <t>Coverage: All receipt types, manifest signing, key management.</t>
          </li>
          <li>
            <t>Licensing: Apache-2.0.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="example-complete-verification-flow">
      <name>Example: Complete Verification Flow</name>
      <t>The following example demonstrates end-to-end receipt creation and
verification.</t>
      <section anchor="step-1-generate-issuer-keys">
        <name>Step 1: Generate Issuer Keys</name>
        <artwork><![CDATA[
import { generateIssuerKey } from '@scopeblind/passport';
const issuer = generateIssuerKey();
// issuer.issuerId = "sb:issuer:4Kpm7Q3wXx2b"
]]></artwork>
      </section>
      <section anchor="step-2-sign-a-receipt">
        <name>Step 2: Sign a Receipt</name>
        <artwork><![CDATA[
import { signReceipt } from '@scopeblind/passport';

const receipt = signReceipt(
  {
    type: "protectmcp:decision",
    tool_name: "deploy",
    decision: "allow",
    agent_tier: "privileged",
    policy_digest: "sha256:a8f3...c91e",
    issued_at: "2026-03-22T14:32:06.551Z",
    issuer_id: issuer.issuerId
  },
  issuer.secretKeyHex,
  issuer.issuerId
);
]]></artwork>
      </section>
      <section anchor="step-3-verify-cli">
        <name>Step 3: Verify (CLI)</name>
        <artwork><![CDATA[
$ npx @veritasacta/verify receipt.json --key issuer-public.json
✓ Signature valid
✓ Issuer: sb:issuer:4Kpm7Q3wXx2b
✓ Decision: allow (deploy)
✓ Issued: 2026-03-22T14:32:06.551Z
]]></artwork>
      </section>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The Acta receipt format was developed as part of the Veritas Acta
protocol (https://veritasacta.com, https://veritasacta.org), an
infrastructure for verifiable machine decision-making. The design
draws on work in the IETF OAuth and Web Authentication communities,
particularly RFC 9449 (DPoP) for proof-of-possession patterns and
RFC 8785 (JCS) for deterministic serialization.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA7Vc6XIbyZH+309RwdmIASbQIAlSF2xPmENRNi1R5IiUj3FM
EIXuAtDDRjfc1SAIKxSxv/YBdvfnPp2fZL/MrOoDACltrD0xMwLQdWTl8eVR
2QrDMCiTMjVDtXedTDMTq9cmSmySZ+qDiUyyKK2a5IW60NEsyUxY5qH7qE6i
yFirTvOsLPJ0L9DjcWHusdBJVGrlVvOL7AVxHmV6jo3iQk/KcKKL1KxDjbGh
5bFh4caGBwdBpEszzYv1UCXZJA+SRTFUZbG05eDg4NXBINCF0UN1baJlkZTr
YJUXd9MiXy6G6jyLzcLgf1kZ3Jk1nsRD9deL06ue8hv01Fk8ePbs8FVPaT5E
GMkheurkXOkpptqfg0Avy1leDAOlQvynQIkdqpu+esOk809yopt83vwxL6Y6
S/6uS3ARNEb5wvyQJlmsOn80oFZbRRzq8lgz10mKo+Xz31oaOKaB/SifB0GW
F3OscW+Igg9vTl8eHA3qjy/8xxcvn7mPR0dHr9zHF88O/YBXx8f4NSA2NtYD
P4ZMgJf+RR6blIVpHkp1VeRlHuWpul5AHSZJxIfZkxm6mJpyqGZlubDD/f05
zYxk4sLN6yf5vm1O5ZkxhDpUg4PBM3w9D1/3rSkKHc6jRRgnOP69KdYhBNqm
7GZmFIaojx/OwcyZmRulwUycAPIvMEe99pPVhYlm4L2dC6m1BOmfUCR40ad5
hXa/eiFe6CLKN55AkniwnI9To35H6rWTATiWLgsd3Zmin5hy0se0faj7vmj6
I4fcb7PkeRCEYaj02NJSZRDczBKrsMpyDnVUsZnA5qzSapEXpQZBPRUV60WZ
Twu9mIHLabpWYkhezwORONsvfoIhJNlUzWtLdh+dEShnBNhLEMD2gzOM8Mup
SC/KZQEiSkgkIQOD6al8wt/9JKwPPvT4tzLP04A3t/myiIwaG6JAtjOxDFrk
aRKtlbnX6ZJVhYYv07LHUtaAp7mxpZ4v1D/+/b8VjulPuUrKmTdk9emTs5DP
n3kemJ7oNPk7xi0tNg1iU5pinkA3yiRSf7i+fI/zZHlGnHO26haBQX3+3CcB
GOU4SJIwblvipsnukyLPSDJWrWamMDVwQMnu8zs5vA2w6tjMdDohPs2Wc50p
WHmhy7wADC10AWqWKbBjzczYbYVBB8reVRChXdvSzPs1NgMHsWGFeFgG+gWr
Iw1hDuXLMiDBQqeI9yw6a5ckIpNpgpspSJukrAfLOCkJJqcgCRSuoRLzRZro
LDK9gNgaFTnQsglwOhVcVhMT07nwU19UeZ7EcWqC4BtAMvQqXkYMBMGJbTEr
ApKThEA6aCSTzbN8ni8tfiCJMzuZdGKoR2wS6cnVuRUtAQQlkzUNgqaUhueV
LJaETAaeYUUPM+Pk17KcwNyTMkM9IaLVTJe1AagVrTHXMaxtvMbDfC4bLsHt
QgaL/uLMp8uiIFPVC6Ag7AaGUhgcAioQ4ffCqWOaT6dETMf0p/2eOk3zZfwn
XUaznro+P7sAUE+h79i928MGCdvf35YJ2x0zOslYilinUiWmCbvSQazK4C9r
lagUIklhrn11wkIt8nkCEwTC4Xg4QAKG18vBMgKbpKJQOoXl0EBMKXlbOk1i
bN+BVAvoG0j13XePhBTffecNqwQHA084vNRhH7OuHMIpL5jvvhu2Nd6adMI+
Wye0PltzPv7FRKUlVKVV6QwwPShEXjDUFDqzOEBJX4hdwhbMbpkPzjQgGk6b
GoIhiEYo0CBKWphIx5dDMsx4PCIqOgATRZDUJVOzgHxSYgAZuEloxObgbVRd
vT2nUKfQwH9YCnAWpBwRKZfOOoVg4TLRcZKtGUDWgoS1ZX9r1WIJy47UnUQk
xAqeDWFWlPuNM1NS9OSdAOQMu1LkT0jAx0TBBWATWqLIf6U5TtKWiPMLG27A
lJocI3OCTJfdbK8aAIkk7Cc8vHcriryFFHrFuo/ntMpCr9NcxwSb0F4O40Cs
BWsTimqIF9gBukp0f/MN6EuZV3aWLAAeFDAIqD8S6nz6hBFwH7UCk16FH65O
RXnI8ZLeBkAvPhAhk1P6Mchu2B++J2kZwlLbrrUnEIvD9cgv4mG+hBKLaYJl
Lnjpqx121fRBOM3YwKUt0nyNr2xIhiOimtJUr6FonXK9cMGBpiPZMk5yIvVh
3Q08wxk+3T6WFver+XBOJSWZ3G6DT6y4CUPuUMNpYIFPn54I7z5/7gWCbJ7V
pYR4iKU4yrN1lGclwqvmN5gU1GFfZ5avMFycisKaMZ+V53YljmizusPQjSjO
BhIZERcnhHNEiiyztKAsKbs7fKxwnjGK2QyNO3HbwfgaxILSCdRXXZz8hTQ/
paW04PgtvlkrWCXBOdNCJhVif/alMAISFbDWh1nVJoLVNMKF3oFzKHvOfZt4
r9vw8b+A8TZOGHRCvSJCtiKvSiEAujkHi6mZwu6xIqxUVSkECV2cUAWDXj9g
dzccZ+Ww4rXYG1BIURpmkWV8vL7Z68mf6v0lf/5w9uPH8w9nr+nz9e9P3r2r
PsiIAF8uP75zz+lTPfP08uLi7P1rmYxf1cZP4Psew32wd3l1c375/uTdntDe
DK6JGWxSDPTFogCKxGQvMLioSMbsJIIfYBCHx+qvgPXB4eGrn/nTy8MXxz9T
CJiJV8mzdO2+gj9rCgaMLmhL2CCy2gXyP45iYEVQ2kxRlEJ883Cqrj3+I1JS
jzhQCWsabs+5gBVMN1+EqbkHwMG5pTGc6sgB54gJHBGEaFp/JOJyW5xlmAOl
Cjgt+eRSoD03d2+oPql+v69guu5JtQ49qzKmPZ1O8cPeWfz6+mSvV/9+l9Ai
e78WFxVK+gASi++bo7Aoj5qZh5CV0MShEZcaVht+v+cmfA7k/ziGnIMfq0tm
CfL3FFGW167uMBhiMOljtRBkMs3h1mdAXNZIaICjnMNEn1xoK7kaoxXpgvKu
HSzEwXbuQlpfn7KyX+xNhoWnDuVJlJQUaDg6wDNFCZJlEjA4facEKr1nJdUN
367uE40fViZNw7uMtAkItcihxK4OoWDMYT4JxyR5wBJWh6eiEJ1JbBhLnenw
1JEdD0VSw1+PtTXPXoYTCkxhG1j9+5FLeuhEjd/pLPiJV5gkBXDvcKAA15TQ
AiQ9D36QBZ18Ky7X5wJXwaedXPWDaxkS0vKyjXQOqzrF7Sm3jdQDyGzSHFF9
BBpgew+a4hGKbYTzqnM4eNkkmdTg+TGC/9LYrhjMlaws2Oa22WGQsxw7sCfT
SnyHpVSgiZrwzbD9E6S0fhn6hZBBe+bmaSq5C1zsHNO9UQc0cotDJxxk2YWO
wAF3IqeDa5/9tTcnrpw9aHLfdqhGe+TxQT45Yx+p7Y167QfQRoQZkDeeiLbs
cdkqTedDEJ5p6FtZpmaPEIa1KL6Fam0Se359qV4+PzisQ0BJwKmMhTCMkzHT
ZtgKAqR8EfAspLPVIodMl7Hhdf6eZ8bFSZzJNOKfvZ/Eqj/enHY9YcXtI9a7
bbmu3CH+mg8lAYqLyGoqG5TNKa/jZyPAxEik531nQ4VZZVpe4IYU4cn8apIv
i5YwbV+dV2GYhHJwf4GMVzqmwFPydVYyyVeIkIbOjOiZo1O03VV5Nz0QSMNI
aMwOhRkFwQcOqiSwAwZBeTm71juqPSQSvRlQ9zfcEJFFjmGXelYeida4pcPQ
SIT48OK3lIIQgNWjqnk8KFvXT6gQIb9TanKbIGebgO0J+FkP4tjwlgbQQFe5
ZvBtLsQJe1wNAzreI52eIiarBgknbuOE0n1ea6YHz54P9cvJETxt9OqwQbSl
kkee3YoTxbfbF5OXejCuR1R2RgOonhgeHIWDwc3h8fBoMDw47h8eDH7aGF74
9SqwP367mL/48Wj15wes3fSubxh3ADuexzuthh84e2GJSsFPKmJxT0IqjoIr
K6CsjDGEyzv7KZzUiPzdAvpLgVGVUO7a77HaYV9dZkQIIZomBBUMY3FXmIXw
2dymyTwpGahE+qrj48QKUn3BFANiDvndSHIrrL3NvHcbUbd1iWnh3c1DZAyc
U02U04pxmkd3MlAUrjCTpdUpU1qr4Ba1xBSpEpUN6HJJNNdeObVxCSMBphvj
Ahx3iAb7lpkoN9PSUveKZl+mib2nqJRd+Nowhp0EU1V2vpw3CfeTqOrWKBIL
tynKgLJg7ZYN7RAdp0ZZGQL8oBiWpTfTduYZ45atEgHopJlMKHjkaGGLSw0O
veF4iTjk7JZi1u/5xLWxbpNURXoNB+N1iDJuN9fFo5TRuDIXU3R1fk5RHcJU
wGtB9Q0+kuayrJ8LaM9SYx34upKeXDY9LKjURxksVp0kU67mu2lqDBcOFfHF
E+fjnwL8KhBoIL7Pwr+1kkzpusxVw/8YuXisi3Wv9m3w0AH8PVVtGzk44ggz
X5RS8kBCzvUrCmwi+Q0QQ064MTHwz3lXAI6hrDUSVQJxyJRNQV7QkcIlpHQS
JvMFArb4KxxPHf5sOIUKTPnr8OXD2/nRj6vBX8aH0eZQXxi4RfDqndFhf9A/
eMSbFfPbYvI1PgzfEp3eVmTzIUOBk6/yFc+Gh4P+8fHhP8FXeK58ZYAlEpe4
mSVLSiEiFHxn6ezm3+48D6F3Rrc9flBzI+hnVZ1pG7rLvpqY/gW3x9RyYMgB
KsiWynqlvU/5sSc8FU+r5LkFJucbN2/AxcrHUcGKIkZjm8ahZDkiU260RenJ
NDbtojNqK8+ou2kqvILDZ5Fdx3mrsPJWLmU6oawAeR9lBVuAsjN3eCqGpGqj
KaXo23D9Y1OuDCUMq7y+YOoFmquvdPvkMEBlZkm3MYr3UwugKCW/j1n+7tSm
Mg757owDX25fPbycvGiFZqnO/AD+yBkMiL9dFVwL3gQH3a6obMDK0fztq8WP
L8TsGqWTXZAy6B8CUny1ZGOb8ZPb7ESvR7Y57B/v2gZ5aybx78lXYM+z4cEB
/u0fHBz8E7CnEsuWvX3Mkkf8r8yhJoGSbjyhEE5yO42+oXm+WYUshEXMNUYp
cTcWzqOIrghrFNM95USxjQpym9XK3g1dPMmVcbIAsvV8bICH0uMQqhHSzCHT
51Fuoa1cCNQn7vvBm8LcmFoBpAdQIJw7C2ElziEifgLTTgTPfpA/ENvtubIj
x08p8soxXdg+iglclkrDmIc9BQrVtVmsZLALOZZxwne7FCb8soynJrBYgeIc
ROklV2UYwBgL3OFcLUwWqPPmKZWaMlKNQMowX4SMFvVNJ03fnVLH4/L2eDLQ
LxtBAkVFXufpo05urZ6Ycn17P3gcVwSvG2gCTZkg/rqlkLeRYY6PouP4mXmO
LLOZs9o85drg5nCg2cvxq+igNRzx0L8apSJ++i9FKK8dtzVU0cGq56wwjz2s
4sBbSTppQJQanX0F2D0fHv1/wY4L3pzSQbP/2Lgbrqr69PCqyKl+wzfrp8gN
2Eok93Elx+YFAgVcVepV6fgAUxu11dZsqSL94fS61TzDKFLVY4lksgQpku5o
xPHNOrpOFSwQCzTcmTVHKnTGLCdILaVUJZfjOBGEXLbLv25NqX5yxfzjzZvw
JddwsRXAX8D9uM9cEoRuPmtf5bdai/xNO9FUXbZbA49eusL1M+AKV5w3anxf
LD1j7vNNGbnionF3M9yDUujFwlfuAGTTJBMOd3D8sFUD71ZSqhoEdtUcv2lp
T0tjgJCUwEkF87FrJDUp8rkrkQqdj+hMvcJurfmSSJ+W5Qd/R0LaWV+R1GXO
p0qw7BE3r0RqSKxvnV2h/09v1bUpW9ctfBLqu6QOtFKN9vv1vcw+t7mSMvd/
sXCzoid/lJaM8iuvNeQSwrWzKeUqO3zouH15Aj1CbtDsF1F2GVGpyfba17aW
WyQNZ0kkVkA/7IzPM+ZYmttVXLPd9qoTnaQbS7p7NFqhMKRixhWSr4TCt5DJ
68ZNVBCcsx1Zf9fFJ7GsrknROJcVE/Ksb7A7ALt33oINxT//7uxGPSGNDSdO
vwN//9pwPHflmhD58u1V089Exb3cdLLodtx1PoLgjYEPfNlJ9ennx8sira48
5dREYut2dGmNKzpXruxn7w9IeUcPo7oLprrRlAh0Y4sdt26UKblyjJRnPfC9
YNt8Q9eJO1qRei0ZUaMD9qzuGikRru8gfY+CmY9NHMsuvhLlNCpJje15JZAR
r99fq5s/37geVsutM+7Oh59L8undvlzTqRsuJt4g2n36GkXzRYq7MpcK5AyT
dBHNpN7Iqwe+3bXvFqYqpfSiLV0C7WvR2VRaWnI1pShUalR8iQK6XDVVouT3
ed1Fu4Al4yOMBSHxRCOckEIoUwAAWFNHJPEqk74xK3ekVTXWlReZE24tOhty
lKS6o6rCeVeMqztFpWi9fQ+rzj194N/CmmXsKaGGJ1BjIWeMADFVEbhJCcEJ
zr6cS0NKsze1arr0Tfm+IZIjcaktuLRJwnxoBYOYtZNlqqrgy2tFVwowsZmz
B8V2UsNV3JntRnEFiOS3QngB+VJr7n2SF1RKrqrWLoXxvZB0hkbhdFpoEpMy
0Bg+k5Mt3di5MqZi7HM9m80b+BZ2uuM2e2nhZmAYBTWsidVz2xjQaknVimlh
+G6P9LtWQun4SuS+j/UxS2LsHLmkhWRNNlKXeZfcjhSMifVhVVrbKiITZFA/
S0uAXmpsYiJjryLubtwlmxdO14LgpFEQbmgTWFpwF7jrS2ur6PCRzKp+R0KS
gNBPaATRX5GI7G1lH43EBmeEhrcTlIPmEHcDvRnWH9wcHkgNoxHSizHdwpgq
qKfWB9fS0sR5D+SecyLN84uLjzcnP7w7gyQiHxBy6MDCpKhkavyluMrMKqhw
UAyiMBM4cJrrHCq8uSGNhWpT+8ho88CjHr83wJlF02Dv6y2TTFz666v8Sv0g
1waq82ZJgUtXPEUBOyw3WhJh4r+/ubnav74+67rKR60SznHwzUAA8IT5he7e
inrgYEL4dwENdWoscR1TwH6KXnNxmUcwoqCGeH7r7jTsRtxXISE06c62isK+
gbcijIJI0EN9BdQsnUMoVyHyYtmbowjnYNxmThi2zT66j566chFx0Gl4BTP/
+I//3DAo1XG0dPnhB8eME5xNdWoSupwLuhehOH9IfCO+dVc5i1Svuc/VuBb8
qnXXt07oTI2qZHXU6MggtIhzignrsfhGNRAuB7uMKVsScLmQNmlEcxID1iAv
mYhf3gasowJbcq0KZq1VDlF1klYzQ+i6r36lBsdqBpdNnVNBM1zXkl2y8+y6
gKX1ooZgsrwlgB+nfM/IvFlUvOmp9rY2IMXUMWBKjfjcXpVcm6zLacQgKLg9
rbrrEdpOiLN1olg3f/muWdeH33Opt+NS4w0X4RDNGBuudtklBTIlfHM7bq7o
5sE4kKuKrwMXTMkbECsXS0uGtSNo5jxAZM0YEIw4iLilLG+k9pX7uoSOpiOQ
mMX5ytsVBee+8Rsc2dKGaGbgi7lzjRZJuHedFrDS66PvkVCQubQ6raC6yb2O
1g29JY1pdkP7FvSt9vMe36H6LnJ3H7yjUcbftnolp97zqs2c32PSxZQvifGd
GuSJi9yAnvPlyq42dOKKfxXLN6+794pG1YWSS6er3hlXduETRs6YDRU/srDa
oy9r1PfMXicdm8em0VLYKHS73iXO8J66QBbun26+HnVSlgilrJzA6/JCygX0
qgu3KWebaT2HsK2iT9Cq9zwiDLnspeSAaqhQSywbtG2TBE/ei3R+612uGHwq
plL6FbqlZzFo1FUkoY6TyYQibV/FqF4M4ccc6ZyfvD/Zgtb2C3qSOctIXYXo
4hO973QdkFu5CEGM93XUa83xq1xYwk2E6kSNfGe49Ge5QZKgNNq3mu1gDcGD
ElqkYezcZU8dKQ+8xJeKFfQ61xg8ZF60ZXCNP5dViuVeaikaVXrLA+jksvUG
vvr+k+pVA99lyzeLW6za6MmQAMq3jEFpHZLTSweq86GKfdpEd4mpl4+8pYtH
7dH1i56r1aqfLea/WHpBdx8sv0PUsN/YEnNfc8v4QiaeNN+3kPeouceDevhd
fOZa/Y0H/aBuw6n8QV9dLxcSQdmZJryld25VJ82nITWcyysOrtEBC8jTreao
LqnBKRWWQPbwsc4+oNpW8wcr0LskIgDKpkP15vpdeNg/DC/Ob1Qnkoodp7z0
g7xHMVBrowvfM/vbe3nzmVRr372K1PHuYYc4mi9K/58FsmOzTcFAa7NYpxTU
nb47Z/alybjQzqR8ncOjt2qlbn31kylyVZALnBvlXwyJHP7VqrTB79rDuxbM
RkP5tqpvsBycdaysc6D96m6vUwWN16/f/nPVe9d+W3rejuVBA7Ox8RpLlZX0
vOcIVON9fH6JU2ea3/tq9IFVVYIx0oLU2C9wtFdH9m6XHkcbvDQf+XFFZqB3
jXtDjuKogbRdG3+T5iv/YrBvzDYypVl5oKajmF6wxh/129N8608QBiG01Eku
bEqzUIdD9TuHBy68o5DSBlWzBkT9qYIMGUEx52fxXt/uktW3v/KlBOsalwv1
m+01Ol0Zt7/vBvXlj/MYox+9jKooHwzlMkXXV7ktmkkcvrf5C9Q2yPW8+01z
fsfl1nWBtuRL4yebg5WqIi7umaL3txoP/fihcl049aO623J3I69SrS7Epxt5
3a0RZVk723Sf95Hw/bQ5nK4Eh5ti2bzMdI/lMgoC/b152HjUmglxV8I7Gvq7
iA7QsCsS+DeVLR52Arfvc6foQIWhZDP8Vo+4Y6mq0xr/+J//aryXwzF/9bto
3lDtVq1q2OtKMiwY1RHZddvrxPJ3KOxiJleqIoo9UhMLCLgQlv+eEq9i/s6f
W5TlGotLU9Rv4RvHWl7JByw9TvFab+4y+DVyf//3LHgtC+f6jm/8bmY+jaG/
FWXF7oNfxnX51PnZzRt1yRk/IeSfzJjTf76vkbteei1kmSErMJt/nQC9okRF
EdXhKgHTtKOQgsykpM4vyzvwe00I21UH4XZ3O3RvX9X2g/8FrBNow0BGAAA=

-->

</rfc>