1393 lines
55 KiB
XML
1393 lines
55 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.8) -->
|
||
|
||
|
||
<!DOCTYPE rfc [
|
||
<!ENTITY nbsp " ">
|
||
<!ENTITY zwsp "​">
|
||
<!ENTITY nbhy "‑">
|
||
<!ENTITY wj "⁠">
|
||
|
||
]>
|
||
|
||
|
||
<rfc ipr="trust200902" docName="draft-nennemann-agent-cross-domain-audit-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
|
||
<front>
|
||
<title abbrev="Agent Cross-Domain Audit">Cross-Domain Agent Audit Trails and Resource Accounting</title>
|
||
|
||
<author fullname="Christian Nennemann">
|
||
<organization>Independent Researcher</organization>
|
||
<address>
|
||
<email>ietf@nennemann.de</email>
|
||
</address>
|
||
</author>
|
||
|
||
<date year="2026" month="March" day="06"/>
|
||
|
||
<area>OPS</area>
|
||
<workgroup>NMOP</workgroup>
|
||
<keyword>cross-domain audit</keyword> <keyword>resource accounting</keyword> <keyword>agent workflows</keyword> <keyword>regulatory compliance</keyword> <keyword>billing</keyword>
|
||
|
||
<abstract>
|
||
|
||
|
||
<?line 57?>
|
||
|
||
<t>This document defines standardized formats and protocols for
|
||
maintaining audit trails when autonomous agents operate across
|
||
multiple administrative domains and organizations with divergent
|
||
regulatory requirements. It additionally specifies mechanisms for
|
||
tracking, recording, and settling agent resource consumption
|
||
across domain boundaries.</t>
|
||
|
||
<t>The cross-domain audit trail format extends the Execution Audit
|
||
Token (EAT) defined in <xref target="I-D.nennemann-exec-audit"/> with
|
||
regulatory profile metadata, audit trail stitching identifiers,
|
||
and selective disclosure controls. The resource accounting
|
||
framework introduces metering points, consumption records, and
|
||
a settlement protocol for multi-domain agent deployments.</t>
|
||
|
||
|
||
|
||
</abstract>
|
||
|
||
|
||
|
||
</front>
|
||
|
||
<middle>
|
||
|
||
|
||
<?line 73?>
|
||
|
||
<section anchor="introduction"><name>Introduction</name>
|
||
|
||
<t>Autonomous agent workflows increasingly span multiple
|
||
administrative domains, each subject to distinct regulatory
|
||
regimes. An agent operating in the European Union must satisfy
|
||
GDPR data protection requirements; the same workflow may cross
|
||
into a US domain governed by HIPAA for healthcare data or SOX
|
||
for financial reporting. Each domain maintains its own audit
|
||
infrastructure, retention policies, and disclosure obligations.</t>
|
||
|
||
<t>This document addresses two gaps identified in
|
||
<xref target="I-D.nennemann-agent-gap-analysis"/>:</t>
|
||
|
||
<dl>
|
||
<dt>Gap 6 -- Cross-Domain Audit Trails:</dt>
|
||
<dd>
|
||
<t>No standardized mechanism exists for maintaining coherent
|
||
audit trails when agent workflows cross organizational
|
||
boundaries with different regulatory requirements. Existing
|
||
audit systems are domain-local and cannot correlate execution
|
||
records across trust boundaries without leaking regulated
|
||
information.</t>
|
||
</dd>
|
||
<dt>Gap 9 -- Resource Accounting:</dt>
|
||
<dd>
|
||
<t>Agent workflows consume computational resources -- CPU cycles,
|
||
network bandwidth, storage, API calls, and large language
|
||
model token usage -- across multiple domains. No standard
|
||
format exists for metering these resources, attributing
|
||
consumption to specific agents or tasks, and settling costs
|
||
across organizational boundaries.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
<t>This document builds on the Execution Audit Token (EAT) format
|
||
defined in <xref target="I-D.nennemann-exec-audit"/> and the Execution Context
|
||
Token (ECT) defined in <xref target="I-D.nennemann-wimse-ect"/>. It extends
|
||
both with cross-domain audit claims and resource accounting
|
||
fields while preserving backward compatibility.</t>
|
||
|
||
<section anchor="scope"><name>Scope</name>
|
||
|
||
<t>This document defines:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Cross-domain audit record format extending EAT
|
||
(<xref target="audit-architecture"/>)</t>
|
||
<t>Regulatory profile mapping for GDPR, SOX, and HIPAA
|
||
(<xref target="regulatory-profiles"/>)</t>
|
||
<t>Audit trail stitching protocol for cross-domain correlation
|
||
(<xref target="audit-stitching"/>)</t>
|
||
<t>Selective disclosure mechanisms for privacy-preserving audit
|
||
(<xref target="selective-disclosure"/>)</t>
|
||
<t>Resource metering model and consumption record format
|
||
(<xref target="resource-metering"/>)</t>
|
||
<t>Billing integration and settlement protocol
|
||
(<xref target="billing-integration"/>)</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="terminology"><name>Terminology</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>Audit Domain:</dt>
|
||
<dd>
|
||
<t>An administrative boundary within which a single set of audit
|
||
policies, retention requirements, and regulatory obligations
|
||
apply uniformly.</t>
|
||
</dd>
|
||
<dt>Domain Boundary:</dt>
|
||
<dd>
|
||
<t>The point at which an agent workflow transitions from one audit
|
||
domain to another, triggering boundary crossing records and
|
||
potential selective disclosure.</t>
|
||
</dd>
|
||
<dt>Regulatory Profile:</dt>
|
||
<dd>
|
||
<t>A machine-readable identifier specifying the regulatory
|
||
framework (e.g., GDPR, SOX, HIPAA) governing audit records
|
||
within an audit domain.</t>
|
||
</dd>
|
||
<dt>Audit Record:</dt>
|
||
<dd>
|
||
<t>A single entry in the cross-domain audit trail, extending the
|
||
EAT format with domain-specific metadata and cross-reference
|
||
identifiers.</t>
|
||
</dd>
|
||
<dt>Audit Stitching:</dt>
|
||
<dd>
|
||
<t>The process of correlating audit records across domain
|
||
boundaries to reconstruct end-to-end workflow execution
|
||
history without requiring full data disclosure.</t>
|
||
</dd>
|
||
<dt>Selective Disclosure:</dt>
|
||
<dd>
|
||
<t>A mechanism allowing an audit record holder to reveal only
|
||
specific claims to a verifier while proving the integrity of
|
||
the complete record.</t>
|
||
</dd>
|
||
<dt>Resource Meter:</dt>
|
||
<dd>
|
||
<t>A component that measures agent resource consumption at defined
|
||
metering points within the execution pipeline.</t>
|
||
</dd>
|
||
<dt>Consumption Record:</dt>
|
||
<dd>
|
||
<t>A signed attestation of resource usage by an agent or task,
|
||
including resource type, quantity, and attribution metadata.</t>
|
||
</dd>
|
||
<dt>Settlement:</dt>
|
||
<dd>
|
||
<t>The process of reconciling consumption records across domain
|
||
boundaries and resolving financial obligations between
|
||
organizations.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="cross-domain-audit-trails"><name>Cross-Domain Audit Trails</name>
|
||
|
||
<section anchor="audit-architecture"><name>Audit Architecture</name>
|
||
|
||
<t>Cross-domain audit trails follow a federated architecture where
|
||
each domain maintains sovereign control over its audit records
|
||
while enabling end-to-end trail reconstruction through
|
||
cryptographic stitching.</t>
|
||
|
||
<figure title="Cross-Domain Audit Architecture" anchor="fig-audit-arch"><artwork><![CDATA[
|
||
+------------------+ +------------------+ +------------------+
|
||
| Domain A | | Domain B | | Domain C |
|
||
| (GDPR) | | (SOX) | | (HIPAA) |
|
||
| | | | | |
|
||
| +------+ +----+ | | +------+ +----+ | | +------+ +----+ |
|
||
| |Agent | |Audit| | | |Agent | |Audit| | | |Agent | |Audit| |
|
||
| | A1 |->| Log| | | | B1 |->| Log| | | | C1 |->| Log| |
|
||
| +------+ +--+-+ | | +------+ +--+-+ | | +------+ +--+-+ |
|
||
| | | | | | | | |
|
||
| +---------+ | | | +---------+ | | | +---------+ | |
|
||
| |Reg. | | | | |Reg. | | | | |Reg. | | |
|
||
| |Profile | | | | |Profile | | | | |Profile | | |
|
||
| +---------+ | | | +---------+ | | | +---------+ | |
|
||
+--------------+----+ +--------------+----+ +--------------+----+
|
||
| | |
|
||
v v v
|
||
+-----+-------------------------+-------------------------+----+
|
||
| Cross-Domain Audit Stitching Layer |
|
||
| |
|
||
| Boundary Crossing Records + Correlation Identifiers |
|
||
+--------------------------------------------------------------+
|
||
]]></artwork></figure>
|
||
|
||
<t>Each domain operates independently with its own audit log and
|
||
regulatory profile. The stitching layer connects audit records
|
||
across boundaries using cryptographic cross-references without
|
||
requiring domains to share raw audit data.</t>
|
||
|
||
</section>
|
||
<section anchor="audit-record-format"><name>Audit Record Format</name>
|
||
|
||
<t>The cross-domain audit record extends the EAT payload defined
|
||
in <xref target="I-D.nennemann-exec-audit"/> with additional claims for
|
||
domain identification, regulatory context, and cross-referencing.</t>
|
||
|
||
<section anchor="base-audit-record-structure"><name>Base Audit Record Structure</name>
|
||
|
||
<t>The base audit record is a JSON object carried as the payload of
|
||
a JWS <xref target="RFC7515"/> with the following claims:</t>
|
||
|
||
<figure><sourcecode type="json"><![CDATA[
|
||
{
|
||
"iss": "https://domain-a.example.com/audit",
|
||
"sub": "agent:a1:task:12345",
|
||
"iat": 1700000000,
|
||
"jti": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
|
||
"eat_ref": "urn:uuid:a1b2c3d4-e5f6-7890-abcd-ef1234567890",
|
||
"aud_domain": "domain-a.example.com",
|
||
"reg_profile": "gdpr-v1",
|
||
"xref": {
|
||
"prev_domain": "domain-b.example.com",
|
||
"prev_jti": "urn:uuid:12345678-abcd-ef01-2345-678901234567",
|
||
"boundary_id": "urn:uuid:bnd-98765432-dcba-10fe-5432-109876543210"
|
||
},
|
||
"task_desc": "Process customer data enrichment",
|
||
"inputs_hash": "sha256:abc123...",
|
||
"outputs_hash": "sha256:def456...",
|
||
"assurance_level": "L2"
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
<t>The claims are defined as follows:</t>
|
||
|
||
<dl>
|
||
<dt>eat_ref:</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14>. A reference to the corresponding Execution Audit
|
||
Token for this task, enabling correlation between the audit
|
||
record and the execution context.</t>
|
||
</dd>
|
||
<dt>aud_domain:</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14>. The fully qualified domain name of the audit domain
|
||
that produced this record.</t>
|
||
</dd>
|
||
<dt>reg_profile:</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14>. The regulatory profile identifier governing this
|
||
audit record. See <xref target="regulatory-profiles"/>.</t>
|
||
</dd>
|
||
<dt>xref:</dt>
|
||
<dd>
|
||
<t><bcp14>OPTIONAL</bcp14>. Cross-reference object for audit trail stitching.
|
||
Present when this record follows a domain boundary crossing.
|
||
See <xref target="audit-stitching"/>.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="domain-specific-extensions"><name>Domain-Specific Extensions</name>
|
||
|
||
<t>Each regulatory profile <bcp14>MAY</bcp14> define additional required claims.
|
||
Domain-specific extensions are carried in a "domain_ext" object:</t>
|
||
|
||
<figure><sourcecode type="json"><![CDATA[
|
||
{
|
||
"domain_ext": {
|
||
"gdpr": {
|
||
"data_subject_category": "customer",
|
||
"processing_purpose": "enrichment",
|
||
"legal_basis": "legitimate_interest",
|
||
"retention_days": 730,
|
||
"dpo_contact": "dpo@domain-a.example.com"
|
||
}
|
||
}
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
</section>
|
||
<section anchor="cross-reference-identifiers"><name>Cross-Reference Identifiers</name>
|
||
|
||
<t>Cross-reference identifiers enable trail stitching without
|
||
requiring access to the full audit records of other domains:</t>
|
||
|
||
<dl>
|
||
<dt>boundary_id:</dt>
|
||
<dd>
|
||
<t>A globally unique identifier assigned at the domain boundary
|
||
crossing point. Both the outgoing record in the source domain
|
||
and the incoming record in the destination domain carry the
|
||
same boundary_id.</t>
|
||
</dd>
|
||
<dt>prev_jti:</dt>
|
||
<dd>
|
||
<t>The JTI of the last audit record in the preceding domain.
|
||
This enables sequential chain verification.</t>
|
||
</dd>
|
||
<dt>prev_domain:</dt>
|
||
<dd>
|
||
<t>The audit domain identifier of the preceding domain.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="regulatory-profiles"><name>Regulatory Profile Mapping</name>
|
||
|
||
<section anchor="profile-definitions"><name>Profile Definitions</name>
|
||
|
||
<t>A regulatory profile is identified by a string of the form
|
||
"{framework}-v{version}". This document defines the following
|
||
initial profiles:</t>
|
||
|
||
<texttable title="Regulatory Profile Definitions" anchor="tab-profiles">
|
||
<ttcol align='left'>Profile ID</ttcol>
|
||
<ttcol align='left'>Framework</ttcol>
|
||
<ttcol align='left'>Required Claims</ttcol>
|
||
<ttcol align='left'>Retention</ttcol>
|
||
<c>gdpr-v1</c>
|
||
<c>EU GDPR</c>
|
||
<c>data_subject_category, processing_purpose, legal_basis, retention_days</c>
|
||
<c>Per purpose</c>
|
||
<c>sox-v1</c>
|
||
<c>US SOX</c>
|
||
<c>control_objective, control_id, evidence_class, attestor</c>
|
||
<c>7 years</c>
|
||
<c>hipaa-v1</c>
|
||
<c>US HIPAA</c>
|
||
<c>phi_category, access_purpose, minimum_necessary, covered_entity</c>
|
||
<c>6 years</c>
|
||
</texttable>
|
||
|
||
</section>
|
||
<section anchor="compliance-field-mapping"><name>Compliance Field Mapping</name>
|
||
|
||
<t>Each profile maps to a set of required and optional claims in the
|
||
"domain_ext" object. An audit record <bcp14>MUST</bcp14> include all required
|
||
claims for its declared regulatory profile. A verifier <bcp14>MUST</bcp14>
|
||
reject records missing required claims.</t>
|
||
|
||
<dl>
|
||
<dt>GDPR Profile (gdpr-v1):</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14> claims: data_subject_category, processing_purpose,
|
||
legal_basis, retention_days.
|
||
<bcp14>OPTIONAL</bcp14> claims: dpo_contact, cross_border_transfer,
|
||
data_categories, recipients.</t>
|
||
</dd>
|
||
<dt>SOX Profile (sox-v1):</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14> claims: control_objective, control_id, evidence_class,
|
||
attestor.
|
||
<bcp14>OPTIONAL</bcp14> claims: deficiency_flag, management_response,
|
||
test_procedure.</t>
|
||
</dd>
|
||
<dt>HIPAA Profile (hipaa-v1):</dt>
|
||
<dd>
|
||
<t><bcp14>REQUIRED</bcp14> claims: phi_category, access_purpose,
|
||
minimum_necessary, covered_entity.
|
||
<bcp14>OPTIONAL</bcp14> claims: business_associate, disclosure_authorization,
|
||
breach_risk_assessment.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="regulatory-metadata-claims"><name>Regulatory Metadata Claims</name>
|
||
|
||
<t>Regulatory metadata is carried as claims in the EAT payload
|
||
under the "reg_meta" key:</t>
|
||
|
||
<figure><sourcecode type="json"><![CDATA[
|
||
{
|
||
"reg_meta": {
|
||
"profile": "gdpr-v1",
|
||
"jurisdiction": "EU",
|
||
"supervisory_authority": "de-bfdi",
|
||
"cross_border": true,
|
||
"adequacy_decision": "eu-us-dpf",
|
||
"retention_expiry": 1763078400
|
||
}
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="audit-stitching"><name>Audit Trail Stitching</name>
|
||
|
||
<section anchor="cross-domain-correlation-protocol"><name>Cross-Domain Correlation Protocol</name>
|
||
|
||
<t>When a workflow crosses a domain boundary, the following protocol
|
||
ensures audit trail continuity:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>The source domain creates a boundary crossing record containing
|
||
the last audit record's JTI and a newly generated boundary_id.</t>
|
||
<t>The source domain signs the boundary crossing record and
|
||
transmits it to the destination domain along with the agent
|
||
handoff.</t>
|
||
<t>The destination domain creates its first audit record with
|
||
an xref object referencing the boundary_id and the source
|
||
domain's last JTI.</t>
|
||
<t>Both domains independently log the boundary crossing record
|
||
in their respective audit ledgers.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="boundary-crossing-records"><name>Boundary Crossing Records</name>
|
||
|
||
<t>A boundary crossing record is a JWS-signed JSON object:</t>
|
||
|
||
<figure><sourcecode type="json"><![CDATA[
|
||
{
|
||
"type": "boundary_crossing",
|
||
"boundary_id": "urn:uuid:bnd-98765432-dcba-10fe-5432-109876543210",
|
||
"source_domain": "domain-a.example.com",
|
||
"dest_domain": "domain-b.example.com",
|
||
"source_last_jti": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
|
||
"crossing_time": 1700000100,
|
||
"workflow_id": "urn:uuid:wf-11111111-2222-3333-4444-555555555555",
|
||
"source_reg_profile": "gdpr-v1",
|
||
"dest_reg_profile": "sox-v1",
|
||
"disclosed_claims": ["task_desc", "inputs_hash", "outputs_hash"],
|
||
"redacted_claims": ["data_subject_category", "processing_purpose"]
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
<t>The "disclosed_claims" and "redacted_claims" arrays enumerate
|
||
which claims from the source domain's audit record are visible
|
||
to the destination domain and which are withheld for privacy.</t>
|
||
|
||
</section>
|
||
<section anchor="partial-trail-assembly"><name>Partial Trail Assembly</name>
|
||
|
||
<t>An auditor with access to multiple domains can reconstruct the
|
||
full workflow trail by following the chain of boundary_id
|
||
references. When an auditor lacks access to a particular domain,
|
||
the trail contains a gap that can be verified structurally
|
||
(the boundary crossing records on either side reference the same
|
||
boundary_id) without revealing the content of the missing
|
||
domain's records.</t>
|
||
|
||
<t>This allows privacy-preserving end-to-end audit where each domain
|
||
proves its segment of the trail without exposing regulated data
|
||
to unauthorized parties.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="selective-disclosure"><name>Selective Disclosure</name>
|
||
|
||
<section anchor="using-sd-jwt-concepts-for-audit-records"><name>Using SD-JWT Concepts for Audit Records</name>
|
||
|
||
<t>Cross-domain audit records <bcp14>MAY</bcp14> use Selective Disclosure JWT
|
||
(SD-JWT) <xref target="SD-JWT"/> mechanisms to enable fine-grained claim
|
||
disclosure. When an audit record is issued, the issuer creates
|
||
an SD-JWT where each claim can be independently disclosed or
|
||
withheld.</t>
|
||
|
||
<t>An SD-JWT audit record replaces direct claims with hashed
|
||
disclosures:</t>
|
||
|
||
<figure><sourcecode type="json"><![CDATA[
|
||
{
|
||
"iss": "https://domain-a.example.com/audit",
|
||
"aud_domain": "domain-a.example.com",
|
||
"reg_profile": "gdpr-v1",
|
||
"_sd": [
|
||
"WyJ...base64url-encoded disclosure hash..."
|
||
],
|
||
"_sd_alg": "sha-256"
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
<t>Individual claims are disclosed by providing the corresponding
|
||
disclosure values alongside the SD-JWT.</t>
|
||
|
||
</section>
|
||
<section anchor="per-domain-visibility-controls"><name>Per-Domain Visibility Controls</name>
|
||
|
||
<t>Each audit domain declares a visibility policy specifying which
|
||
claims are:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Public: Disclosed to all domains in the workflow trail.</t>
|
||
<t>Boundary: Disclosed only to the immediate upstream and
|
||
downstream domains.</t>
|
||
<t>Private: Never disclosed outside the originating domain.</t>
|
||
</list></t>
|
||
|
||
<t>The visibility policy is declared in the regulatory profile
|
||
and enforced at each domain boundary crossing.</t>
|
||
|
||
</section>
|
||
<section anchor="redaction-and-minimization-rules"><name>Redaction and Minimization Rules</name>
|
||
|
||
<t>When an audit record crosses a domain boundary, the following
|
||
rules apply:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>Claims classified as "private" <bcp14>MUST</bcp14> be redacted using SD-JWT
|
||
disclosures. The destination domain receives proof that the
|
||
claims exist but cannot read their values.</t>
|
||
<t>Claims classified as "boundary" <bcp14>MUST</bcp14> be disclosed to the
|
||
immediate destination domain but redacted for subsequent
|
||
domains in the chain.</t>
|
||
<t>Claims classified as "public" <bcp14>MUST</bcp14> be disclosed to all
|
||
domains.</t>
|
||
<t>The minimum set of public claims required for trail stitching
|
||
is: jti, boundary_id, aud_domain, and crossing_time.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
</section>
|
||
<section anchor="resource-accounting"><name>Resource Accounting</name>
|
||
|
||
<section anchor="resource-metering"><name>Resource Metering Model</name>
|
||
|
||
<section anchor="resource-types"><name>Resource Types</name>
|
||
|
||
<t>This document defines the following resource types for agent
|
||
metering:</t>
|
||
|
||
<texttable title="Resource Type Definitions" anchor="tab-resources">
|
||
<ttcol align='left'>Resource Type</ttcol>
|
||
<ttcol align='left'>Unit</ttcol>
|
||
<ttcol align='left'>Description</ttcol>
|
||
<c>compute</c>
|
||
<c>cpu-ms</c>
|
||
<c>CPU time in milliseconds</c>
|
||
<c>memory</c>
|
||
<c>byte-s</c>
|
||
<c>Memory usage in byte-seconds</c>
|
||
<c>network_egress</c>
|
||
<c>bytes</c>
|
||
<c>Outbound network transfer</c>
|
||
<c>network_ingress</c>
|
||
<c>bytes</c>
|
||
<c>Inbound network transfer</c>
|
||
<c>storage</c>
|
||
<c>byte-s</c>
|
||
<c>Persistent storage in byte-seconds</c>
|
||
<c>api_calls</c>
|
||
<c>count</c>
|
||
<c>External API invocations</c>
|
||
<c>llm_tokens</c>
|
||
<c>count</c>
|
||
<c>Large language model tokens consumed</c>
|
||
<c>gpu_compute</c>
|
||
<c>gpu-ms</c>
|
||
<c>GPU time in milliseconds</c>
|
||
</texttable>
|
||
|
||
</section>
|
||
<section anchor="metering-points"><name>Metering Points</name>
|
||
|
||
<t>Resource meters are placed at defined points in the agent
|
||
execution pipeline:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>Task Ingress: Resources consumed receiving and parsing task
|
||
inputs.</t>
|
||
<t>Execution: Resources consumed during task execution proper.</t>
|
||
<t>Tool Invocation: Resources consumed by each tool call within
|
||
a task.</t>
|
||
<t>Task Egress: Resources consumed producing and transmitting
|
||
task outputs.</t>
|
||
<t>Audit Overhead: Resources consumed generating and transmitting
|
||
audit records themselves.</t>
|
||
</list></t>
|
||
|
||
<t>Each metering point produces a meter reading that is included
|
||
in the task's consumption record.</t>
|
||
|
||
</section>
|
||
<section anchor="meter-reading-format"><name>Meter Reading Format</name>
|
||
|
||
<t>A meter reading is a JSON object:</t>
|
||
|
||
<figure><sourcecode type="json"><![CDATA[
|
||
{
|
||
"meter_point": "execution",
|
||
"resource_type": "llm_tokens",
|
||
"quantity": 4096,
|
||
"unit": "count",
|
||
"start_time": 1700000000,
|
||
"end_time": 1700000005,
|
||
"confidence": "measured"
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
<t>The "confidence" field indicates whether the reading is
|
||
"measured" (exact instrumentation), "estimated" (statistical
|
||
sampling), or "allocated" (apportioned from a shared pool).</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="consumption-records"><name>Consumption Records</name>
|
||
|
||
<section anchor="per-agent-resource-consumption-claims"><name>Per-Agent Resource Consumption Claims</name>
|
||
|
||
<t>Resource consumption is recorded as claims in the EAT payload
|
||
under the "resource" key:</t>
|
||
|
||
<figure><sourcecode type="json"><![CDATA[
|
||
{
|
||
"resource": {
|
||
"agent_id": "spiffe://domain-a.example.com/agent/a1",
|
||
"task_id": "urn:uuid:a1b2c3d4-e5f6-7890-abcd-ef1234567890",
|
||
"domain": "domain-a.example.com",
|
||
"period": {
|
||
"start": 1700000000,
|
||
"end": 1700000010
|
||
},
|
||
"meters": [
|
||
{
|
||
"meter_point": "execution",
|
||
"resource_type": "compute",
|
||
"quantity": 2500,
|
||
"unit": "cpu-ms",
|
||
"confidence": "measured"
|
||
},
|
||
{
|
||
"meter_point": "execution",
|
||
"resource_type": "llm_tokens",
|
||
"quantity": 4096,
|
||
"unit": "count",
|
||
"confidence": "measured"
|
||
},
|
||
{
|
||
"meter_point": "tool_invocation",
|
||
"resource_type": "api_calls",
|
||
"quantity": 3,
|
||
"unit": "count",
|
||
"confidence": "measured"
|
||
}
|
||
]
|
||
}
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
</section>
|
||
<section anchor="aggregation-across-dag-nodes"><name>Aggregation Across DAG Nodes</name>
|
||
|
||
<t>When a workflow DAG spans multiple tasks, consumption records
|
||
can be aggregated to produce a workflow-level resource summary.
|
||
The aggregation <bcp14>MUST</bcp14>:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Sum quantities of the same resource type and unit across all
|
||
DAG nodes within a domain.</t>
|
||
<t>Maintain per-task granularity for dispute resolution.</t>
|
||
<t>Record the aggregation method ("sum", "max", "weighted") for
|
||
each resource type.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="multi-tenant-isolation"><name>Multi-Tenant Isolation</name>
|
||
|
||
<t>In shared infrastructure deployments, resource meters <bcp14>MUST</bcp14>
|
||
provide tenant isolation guarantees:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Each agent's resource consumption <bcp14>MUST</bcp14> be independently
|
||
metered.</t>
|
||
<t>Shared resources (e.g., shared GPU pools) <bcp14>MUST</bcp14> use the
|
||
"allocated" confidence level and document the allocation
|
||
method.</t>
|
||
<t>Consumption records <bcp14>MUST NOT</bcp14> leak information about other
|
||
tenants' resource usage.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="billing-integration"><name>Billing Integration</name>
|
||
|
||
<section anchor="settlement-protocol-overview"><name>Settlement Protocol Overview</name>
|
||
|
||
<t>Settlement between domains follows a three-phase protocol:</t>
|
||
|
||
<dl>
|
||
<dt>Phase 1 -- Reporting:</dt>
|
||
<dd>
|
||
<t>Each domain produces a signed usage report summarizing
|
||
consumption records for a billing period. The report is
|
||
signed using the domain's audit signing key.</t>
|
||
</dd>
|
||
<dt>Phase 2 -- Reconciliation:</dt>
|
||
<dd>
|
||
<t>Participating domains exchange usage reports and verify that
|
||
boundary crossing records match. Discrepancies are flagged
|
||
for manual review.</t>
|
||
</dd>
|
||
<dt>Phase 3 -- Settlement:</dt>
|
||
<dd>
|
||
<t>Reconciled usage is converted to monetary amounts using
|
||
pre-agreed rate cards. Settlement records are logged in
|
||
each domain's audit ledger.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="usage-report-format"><name>Usage Report Format</name>
|
||
|
||
<t>A usage report is a JWS-signed JSON object:</t>
|
||
|
||
<figure><sourcecode type="json"><![CDATA[
|
||
{
|
||
"type": "usage_report",
|
||
"reporter_domain": "domain-a.example.com",
|
||
"billing_period": {
|
||
"start": 1700000000,
|
||
"end": 1702592000
|
||
},
|
||
"counterparty_domain": "domain-b.example.com",
|
||
"summary": [
|
||
{
|
||
"resource_type": "compute",
|
||
"total_quantity": 15000000,
|
||
"unit": "cpu-ms",
|
||
"task_count": 1250
|
||
},
|
||
{
|
||
"resource_type": "llm_tokens",
|
||
"total_quantity": 5242880,
|
||
"unit": "count",
|
||
"task_count": 1250
|
||
}
|
||
],
|
||
"detail_hash": "sha256:fedcba987654...",
|
||
"rate_card_ref": "urn:uuid:rc-aabbccdd-1122-3344-5566-778899001122"
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
<t>The "detail_hash" is a hash of the full set of per-task
|
||
consumption records, enabling the counterparty to request and
|
||
verify individual records during dispute resolution.</t>
|
||
|
||
</section>
|
||
<section anchor="fair-use-enforcement-mechanisms"><name>Fair-Use Enforcement Mechanisms</name>
|
||
|
||
<t>Domains <bcp14>MAY</bcp14> enforce fair-use policies on agent resource
|
||
consumption:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Rate Limiting: Domains <bcp14>MAY</bcp14> impose per-agent or per-workflow
|
||
rate limits on resource types. Rate limit policies <bcp14>SHOULD</bcp14>
|
||
be communicated in the boundary crossing record.</t>
|
||
<t>Budget Caps: Workflows <bcp14>MAY</bcp14> carry a resource budget in the ECT
|
||
that specifies maximum consumption per resource type. Agents
|
||
<bcp14>MUST NOT</bcp14> exceed the declared budget without obtaining a revised
|
||
ECT.</t>
|
||
<t>Anomaly Detection: Domains <bcp14>SHOULD</bcp14> monitor consumption patterns
|
||
and flag anomalous usage (e.g., token consumption 10x above
|
||
the workflow's declared budget).</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
</section>
|
||
<section anchor="integration-with-ect-and-exec-audit"><name>Integration with ECT and Exec-Audit</name>
|
||
|
||
<t>The cross-domain audit and resource accounting claims defined in
|
||
this document extend the existing token formats as follows:</t>
|
||
|
||
<dl>
|
||
<dt>ECT Extensions (<xref target="I-D.nennemann-wimse-ect"/>):</dt>
|
||
<dd>
|
||
<t>The ECT payload is extended with a "resource_budget" claim
|
||
specifying per-resource-type consumption limits for the
|
||
workflow. The ECT <bcp14>MAY</bcp14> also carry a "reg_profiles" array
|
||
listing the regulatory profiles that the workflow is expected
|
||
to traverse.</t>
|
||
</dd>
|
||
<dt>EAT Extensions (<xref target="I-D.nennemann-exec-audit"/>):</dt>
|
||
<dd>
|
||
<t>The EAT payload is extended with the "aud_domain", "reg_profile",
|
||
"reg_meta", "xref", "domain_ext", and "resource" claims defined
|
||
in this document. These claims are <bcp14>OPTIONAL</bcp14> for single-domain
|
||
deployments and <bcp14>REQUIRED</bcp14> for cross-domain workflows.</t>
|
||
</dd>
|
||
<dt>Backward Compatibility:</dt>
|
||
<dd>
|
||
<t>Existing ECT and EAT processors that do not recognize the new
|
||
claims <bcp14>MUST</bcp14> ignore them per standard JWT processing rules
|
||
<xref target="RFC7519"/>. Cross-domain audit functionality degrades
|
||
gracefully: single-domain deployments continue to function
|
||
without modification.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="security-considerations"><name>Security Considerations</name>
|
||
|
||
<section anchor="audit-trail-tampering-across-domains"><name>Audit Trail Tampering Across Domains</name>
|
||
|
||
<t>Because each domain signs its own audit records independently,
|
||
a compromised domain can fabricate or alter its segment of the
|
||
audit trail. Mitigations include:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Requiring Level 3 assurance (ledger-anchored EATs) for
|
||
cross-domain workflows in regulated environments.</t>
|
||
<t>Cross-domain ledger anchoring as defined in
|
||
<xref target="I-D.nennemann-exec-audit"/> to detect tampering after the
|
||
fact.</t>
|
||
<t>Independent third-party audit of boundary crossing records.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="resource-metering-fraud"><name>Resource Metering Fraud</name>
|
||
|
||
<t>A malicious domain could under-report resource consumption to
|
||
reduce settlement obligations or over-report to inflate charges.
|
||
Mitigations include:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Bilateral verification of boundary crossing records, which
|
||
constrain the plausible range of resource consumption.</t>
|
||
<t>Statistical sampling and spot-checking of consumption records
|
||
against actual infrastructure metrics.</t>
|
||
<t>Requiring "measured" confidence level for high-value resource
|
||
types and rejecting "estimated" readings above a threshold.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="privacy-leakage-through-audit-correlation"><name>Privacy Leakage Through Audit Correlation</name>
|
||
|
||
<t>Even with selective disclosure, the structure of the audit trail
|
||
(timing, frequency, and pattern of boundary crossings) can leak
|
||
information about the nature of the workflow. Mitigations
|
||
include:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Batching boundary crossing records to obscure individual
|
||
workflow timing.</t>
|
||
<t>Using domain-specific pseudonymous identifiers in cross-
|
||
references rather than globally unique agent identifiers.</t>
|
||
<t>Minimizing the set of public claims to the structural minimum
|
||
required for trail stitching.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="selective-disclosure-attacks"><name>Selective Disclosure Attacks</name>
|
||
|
||
<t>An adversary with access to multiple boundary crossing records
|
||
could attempt to correlate redacted claims across domains.
|
||
SD-JWT provides unlinkability guarantees when fresh salts are
|
||
used for each disclosure. Implementations <bcp14>MUST</bcp14> use
|
||
cryptographically random salts of at least 128 bits for each
|
||
SD-JWT disclosure.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="iana-considerations"><name>IANA Considerations</name>
|
||
|
||
<section anchor="jwt-claims-registration"><name>JWT Claims Registration</name>
|
||
|
||
<t>This document requests registration of the following claims in
|
||
the JSON Web Token Claims registry established by <xref target="RFC7519"/>:</t>
|
||
|
||
<texttable title="JWT Claims Registration" anchor="tab-claims">
|
||
<ttcol align='left'>Claim Name</ttcol>
|
||
<ttcol align='left'>Description</ttcol>
|
||
<ttcol align='left'>Reference</ttcol>
|
||
<c>aud_domain</c>
|
||
<c>Audit domain identifier</c>
|
||
<c>This document</c>
|
||
<c>reg_profile</c>
|
||
<c>Regulatory profile identifier</c>
|
||
<c>This document</c>
|
||
<c>reg_meta</c>
|
||
<c>Regulatory metadata object</c>
|
||
<c>This document</c>
|
||
<c>xref</c>
|
||
<c>Cross-domain reference object</c>
|
||
<c>This document</c>
|
||
<c>domain_ext</c>
|
||
<c>Domain-specific extension claims</c>
|
||
<c>This document</c>
|
||
<c>resource</c>
|
||
<c>Resource consumption record</c>
|
||
<c>This document</c>
|
||
<c>resource_budget</c>
|
||
<c>Resource budget limits</c>
|
||
<c>This document</c>
|
||
</texttable>
|
||
|
||
</section>
|
||
<section anchor="regulatory-profile-registry"><name>Regulatory Profile Registry</name>
|
||
|
||
<t>This document establishes a new "Agent Audit Regulatory Profiles"
|
||
registry. The registration policy is Specification Required
|
||
<xref target="RFC8126"/>.</t>
|
||
|
||
<t>Initial registrations:</t>
|
||
|
||
<texttable title="Regulatory Profile Registry" anchor="tab-reg-profiles">
|
||
<ttcol align='left'>Profile ID</ttcol>
|
||
<ttcol align='left'>Framework</ttcol>
|
||
<ttcol align='left'>Reference</ttcol>
|
||
<c>gdpr-v1</c>
|
||
<c>EU General Data Protection Regulation</c>
|
||
<c>This document</c>
|
||
<c>sox-v1</c>
|
||
<c>US Sarbanes-Oxley Act</c>
|
||
<c>This document</c>
|
||
<c>hipaa-v1</c>
|
||
<c>US Health Insurance Portability and Accountability Act</c>
|
||
<c>This document</c>
|
||
</texttable>
|
||
|
||
</section>
|
||
<section anchor="resource-type-registry"><name>Resource Type Registry</name>
|
||
|
||
<t>This document establishes a new "Agent Resource Types" registry.
|
||
The registration policy is Specification Required <xref target="RFC8126"/>.</t>
|
||
|
||
<t>Initial registrations are listed in <xref target="tab-resources"/>.</t>
|
||
|
||
</section>
|
||
</section>
|
||
|
||
|
||
</middle>
|
||
|
||
<back>
|
||
|
||
|
||
<references title='References' anchor="sec-combined-references">
|
||
|
||
<references title='Normative References' anchor="sec-normative-references">
|
||
|
||
|
||
|
||
<reference anchor="RFC2119">
|
||
<front>
|
||
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
|
||
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
|
||
<date month="March" year="1997"/>
|
||
<abstract>
|
||
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
|
||
</abstract>
|
||
</front>
|
||
<seriesInfo name="BCP" value="14"/>
|
||
<seriesInfo name="RFC" value="2119"/>
|
||
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
|
||
</reference>
|
||
<reference anchor="RFC8174">
|
||
<front>
|
||
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
|
||
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
|
||
<date month="May" year="2017"/>
|
||
<abstract>
|
||
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
|
||
</abstract>
|
||
</front>
|
||
<seriesInfo name="BCP" value="14"/>
|
||
<seriesInfo name="RFC" value="8174"/>
|
||
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
|
||
</reference>
|
||
<reference anchor="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="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="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.nennemann-wimse-ect" target="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/">
|
||
<front>
|
||
<title>Execution Context Tokens for Distributed Agentic Workflows</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
<reference anchor="I-D.nennemann-exec-audit" target="https://datatracker.ietf.org/doc/draft-nennemann-exec-audit/">
|
||
<front>
|
||
<title>Cross-Domain Execution Audit Tokens</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
|
||
|
||
<reference anchor="RFC8126">
|
||
<front>
|
||
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
|
||
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
|
||
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
|
||
<author fullname="T. Narten" initials="T." surname="Narten"/>
|
||
<date month="June" year="2017"/>
|
||
<abstract>
|
||
<t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
|
||
<t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
|
||
<t>This is the third edition of this document; it obsoletes RFC 5226.</t>
|
||
</abstract>
|
||
</front>
|
||
<seriesInfo name="BCP" value="26"/>
|
||
<seriesInfo name="RFC" value="8126"/>
|
||
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
|
||
</reference>
|
||
|
||
|
||
|
||
</references>
|
||
|
||
<references title='Informative References' anchor="sec-informative-references">
|
||
|
||
<reference anchor="I-D.nennemann-agent-gap-analysis" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/">
|
||
<front>
|
||
<title>Gap Analysis for Autonomous Agent Protocols</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</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="RFC9334">
|
||
<front>
|
||
<title>Remote ATtestation procedureS (RATS) Architecture</title>
|
||
<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
|
||
<author fullname="D. Thaler" initials="D." surname="Thaler"/>
|
||
<author fullname="M. Richardson" initials="M." surname="Richardson"/>
|
||
<author fullname="N. Smith" initials="N." surname="Smith"/>
|
||
<author fullname="W. Pan" initials="W." surname="Pan"/>
|
||
<date month="January" year="2023"/>
|
||
<abstract>
|
||
<t>In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.</t>
|
||
</abstract>
|
||
</front>
|
||
<seriesInfo name="RFC" value="9334"/>
|
||
<seriesInfo name="DOI" value="10.17487/RFC9334"/>
|
||
</reference>
|
||
|
||
<reference anchor="SD-JWT" target="https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/">
|
||
<front>
|
||
<title>Selective Disclosure for JWTs (SD-JWT)</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="2024"/>
|
||
</front>
|
||
<seriesInfo name="Internet-Draft" value="draft-ietf-oauth-selective-disclosure-jwt"/>
|
||
</reference>
|
||
<reference anchor="EU-AI-ACT" target="https://eur-lex.europa.eu/eli/reg/2024/1689/oj">
|
||
<front>
|
||
<title>Regulation (EU) 2024/1689 (AI Act)</title>
|
||
<author >
|
||
<organization>European Parliament and Council</organization>
|
||
</author>
|
||
<date year="2024"/>
|
||
</front>
|
||
</reference>
|
||
|
||
|
||
</references>
|
||
|
||
</references>
|
||
|
||
|
||
<?line 818?>
|
||
|
||
<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>
|
||
|
||
<t>The author thanks the participants of the NMOP working group
|
||
for their feedback on agent management and operational
|
||
challenges.</t>
|
||
|
||
</section>
|
||
|
||
|
||
</back>
|
||
|
||
<!-- ##markdown-source:
|
||
H4sIAAAAAAAAA61963bbOLLufzxFHeVHJ6dFxXLuOnvP3mrHPeNeufjEzumZ
|
||
NauXFkRCEjoUoQZA2xrb8yznWfaT7VVVAAlKlDvZ0/6RyCIJ4lKo+uqrKjjL
|
||
MuG1L9UEBifWOJe9NWupK5guVeVhWhfaw6WVunQgqwI+KWdqmyuY5rmpK6+r
|
||
5UDI+dyqqwkM+KFuO9jCQOTSq6Wx2wk4X4jC5JVcqwkUVi58VqmqUmtZVZnE
|
||
BrKcGiiogUxiA9nRkXD1fK2d06by242awNnp5Y+iqtdzZSeikF5NxNUEnglp
|
||
lZzA4OP5xUBcG/tlaU29mcDgw/uP5wPxRW2vjS0mAiCD9EVAL6KvbRykbAZJ
|
||
31PvANtclObahXuXdSm9sVvIzXpTalnliq7MdVnik0LWfmUsvVEAACzqsuTh
|
||
n6ysdl7LCj7EKaA7jF3KSv9Dem2qCZxVhdqoqsCXf1JOSZuvlKUb1VrqcgJa
|
||
+cV/NrM4KpQQlbFr6fWVwvd++vHkeDx+Ez6+Hr96Hj6+etF8++rF+EX4+GY8
|
||
PsKPZ9nbUbs213rtVKZyP6FXR6k5vVF5jR2FE1N5dePh0nxRlYOFsfBWO2/1
|
||
vPaqYInSOfwc52/A7Ui7VH4CK+83bvL0aSG99FbmX5Qd4bhGxi6fFiZ/uisr
|
||
TX+e7nVV3aicBafb145kth0PUk7d/hc71b75qRC6WqSr0O0ji/pSbjJZyXLr
|
||
tOv29c9yA9NwheZyWntTmbWpXdic59Z4k5vyX+3zfk/ijOJjmcu19xkKnfYq
|
||
97WNIvXm2TOSo4u32U8/X3Z7f6FKlePAUQTy0rjaKhrFTz9fOnjMjzz5H3Wc
|
||
OmVwU2UuviUrmrdkv16TRAA4ZbVyuAjcN4CzyitbKZ+9xZai+vmKBul50jFw
|
||
fHT8XACcfs6mZ9n0ZGfcn1gdoFQ9Pv38hO5+On75+g08np7BNPcHxqxqm5Xq
|
||
ZqRqazZypOqnqtRPrVo+bVp4an7d7wZAq13wJ0PdMYFTbEbJCs6lLbVco7ig
|
||
+j4xdZXrUogsy0DOHU6zF+JypR0UJq/pxkItdKUcOC+rQtpC/0MVwJLMRmAT
|
||
BQ+/FbiZvNSVrpasQ8GzvbheKdSqjdSSnDkwG2WlR+WKu1Gs69LrTalAFmtd
|
||
ob6gDQOslfmFqT50cK39Cgp9pSw2KBINbNVvtbYKR+FGAGceZFFofEqW5Rbc
|
||
RuV6oZWDtcpXstJuzUMgadPVcghW5cYW9BFf7JT3JQ2MdlxjGHJTuXq9wZYF
|
||
jyP0F+amxknTyo1wXlWPjeH5CTMK6sarqnDgV2pXJQlSSfD4dHr5JKxKAbqC
|
||
29tD6u7+nmYnnZONNQtdKlgrL3FnDTudcF77fIUj1GhfcHasGwoee9zC7V7A
|
||
gXtrSpxdHFyfpVxYuVZoJEHjvUWd04R7ZfE1G6Mr74bpDIZJdzTlQvKk0yI2
|
||
kkaqgySlmckli+qmNFtebxbqtS6KUgnxCDc7vZ0WSUx35LA146Cr3CrpdLUk
|
||
GZEVRJkU/TI5BCXzFbh6/qvKPXiDM+R1lfsEDuAa6LXCmZrG7rLo02xXvOBx
|
||
n36ucCLWtfPgpNdusRV/fnv+CTe7pFlQeZiqVsL/DzXh5Fo1g4G13LLECV15
|
||
AxI+X0TJXJorVH4FzLfwl7Pz6ZQmdaVk6Ve5tIrfZSxcfPyrwEsLXckq17IE
|
||
qzbGYr9HAKc49NBk3PoONG7s6wiidLWw0nlbk7nAXeVRuEwFG1PqXCte61Sw
|
||
zLzUS97go12FJIvCKueUA39tYCk3rpVW3BBid0PsW7T7+4kQaFJfQpb1INSA
|
||
cSdiAh9MV/M1ugLUjXaejXGq9HKzUhY1EfTpvx1hY2WRKjRZCkjURlRviwU1
|
||
CofV2+kNSd2yea/bOq/WDmgxGT2XJpclzXUuq8p4yI21qkT9q6KyERB3YNDJ
|
||
4C0K4k6fTO2hVBL1ZOyUKgRAg3JMNeI5foNz3OMp4OxOd+eD9IAi8Fz7MCGN
|
||
XnG0WuefId/mpXJDAVApT8plLqviWhd+NQTnjZVLNYTp+RnksiyDeJVoZKGU
|
||
1bKWSwTla1OoEjxp1drJpcLmw5gbOxQ2+QhSSRDQ6utWCKJS8yvlWmWIb/cM
|
||
e3l1Ul3nTTRDeWMQLXjpvrgdk5Mb59HHkH0is2tn0u0yr3VZODBVn02B1Kbw
|
||
kMTXmhbsXrfJAPkbQ3XysKFqIPv9PZvnYPzE3PgVC36PucxLqdcMBHrtjVY4
|
||
3OsVWrmNVU7ZK5y/ucy/XEtbkGhJr+e61H47EuLRI7jIzUYdwD0TIaKG6HSD
|
||
90jXbON7TqeXAuDx7S17qilQvr9/InAn7BtjudngsyhFqOeHqHR5/Uk1c4Pt
|
||
1s/Cg45bnPZa8I6x7Mxj3PS82ZuuNo9yqxd9Br+LlGBj9ZXMsT/NPEe/+fHt
|
||
bR98jnMQFq7ZM7wXSTPtQYEomGEW+NEsPsot/sDuNYIMtbQMuZv900UP3E7w
|
||
x7PkAWxJPIJLZde6MqVZbhmzfVFbVFGFg8H7zxeXgyH/Dx8+0udPp//389mn
|
||
07f4+eIv03fvmg8i3HHxl4+f371tP7VPnnx8//70w1t++MPHS+h8JQbvp38b
|
||
sCAMPp5fnn38MH03YLTQsYhWoSaZKxq+3aCBLUA6USiXWz3n7ffDyfl//f/x
|
||
c7i9/V+BAbi/D78gB4BgcaUqfpupym341a/UVsjNRkmLrciyhFxutJekVx24
|
||
FVp6tHkjIf7333FmfpnAv83zzfj5n8IXOODOl3HOOl/SnO1/s/cwT2LPVz2v
|
||
aWaz8/3OTHf7O/1b5/c478mX//Yfpa4UZOPX//EnwTKyMGVprkn7KxuMbu14
|
||
4juLNUHwifuV8QYZwWrX2wnqfEtKUFeozfIVSCBUqlCowSyardaiqBZZpeBg
|
||
GJRlo3cSdIUWZbMpt1BXGrdZiSoxQKEfQi+wjzhGAusgfezOLpxBFVQ5zW7Z
|
||
wpo1mEo1vQzKB2FoZfxK2SF4q5dL3v/NiElTMagIIKQqaIw0Mln2OiIjIRK1
|
||
es7akaYW1hJ1msqskoWclyrxbILp3QabnaJ1gNZveaxGy9EwVcyklJ8ECN06
|
||
uqHHAuKyyWgseOyjuPSf6EbuX1hSVXm7jX7AISdxmNgZv0IIczq9jCaIgSLj
|
||
vAZTRDePNSs1axVBSaIlEy+v6dxFNAPNsluTK4Qci9Zy7I4ZOm5vF8F6Q3dV
|
||
7AGAqorMm0xVRSs4KfhcaUerGEEmSzKZx7os2S3prHwfuRTWvsHqMu5OuWO/
|
||
V6YslOU+XilZkuYT0KKyADfIe7pSlgUnogtzFWWHzYj2WzALAbyKSAArr8Kr
|
||
SEaD2XuPtov7iHeZCreRX0kPayWx/+4BigF3YEBVCGK7rnQUPexAM6uw0RuF
|
||
KmskxEnSUFcOlwjTpPfKMfDGBW/ez/h4vm13fcCpQ8L8eVkXvGnD/UjKD+G3
|
||
WlZe+y1roAYGo28bBJPWL5roHokjycl1gMB7JMFDchcRYkmL1LqvifaDufLX
|
||
SuGDHVIJYeFht5AwI38xTeAd3D7qwXxC9IDH4BKy0QAJC1UQC1ZA+iwaYKuE
|
||
6nWxHSofpZdVJGEAvyDPu6uNWFZVJec0icn2Y8SY7E3ySFbW1MuVyO12483S
|
||
ys1K5y2sHAnxz3/+U3yf7f18T4zjN10QdwAQJ5gZS7hr/o1W6NCFk3gBm3mM
|
||
6vkJND/N3Y8vPv41+T65ELQ4pM3s/twl/37lBXEXx/p9GPX3zd3fcEHcwR17
|
||
x/gBV/SuufsbLgi6OB0D3GV/uoN3ZpncDfDDoQsn3Qu7g/r+UN8fvrA7xXcH
|
||
p/L3rrQd4jd07v+mKzhDnxRyWXxf5/5vuoItBezRc/+3XPkDR7ez774/uCN/
|
||
74ro3QF9Pw9c2W3k6uCtD1xpG/m+7V/vz+9cSca00+ce3d/gIngnt8oeHNjh
|
||
0X/VT7elCMG5Q/jyT8HwfQ8nrRsPZy2Q62vp8Dx81c/3pPNvJ/BooZdZa+Q4
|
||
zvXvg57ZSg3j4F6IlCcOIR+k2ptQdsmAr8scQ2mWhP/3Axgh4tDSHSUtSm6q
|
||
SuV7NjCghAQc1DSZXSO3g48bnlO0EDSGoZC3W6GPZ+V1xPiMZhpowAsFPzI6
|
||
j9iAe5QxZr8/GBMK6LQTDZpewkZuSyOLBv59TfQnCXpFMItBrvC66AHkJEfD
|
||
bgIDsXnDHt+BgcCjR4/gB+lUd8AXkejnwc3xhs6gtAMJP118/ACGIya5tFYT
|
||
YUEDjYM0CyHhp58v4PY2JCTEEfmOw82DmhAw+dWZStwKgIF2bjCBQRNFDukj
|
||
I3UjEZaPcrN+St0aIIIduHqOtxO0ncjxBKHtZHz87PkLvq6lH0xg/Ooo/NCX
|
||
v3qND9W2mtS1LiaL1+Pi+UKq7FWh8mw8Lo4y+erli+zoSB7lb8bq5XzxkptT
|
||
0s+sWnSeluP5cf6seJ6pF4uX2avXb44yOc+LTC2oHy/xG35a1sWMB4QN9A2N
|
||
77NqOQv7BW9cFhubXY352g2//paUxGBj1dV+k/O9JuOtuyOPPYw9Phpn+E1G
|
||
nQ4XYwPR1Z/potPGvCqyN69fvXzx/NlxVuRzmY2PFiqjX8dH8cr4CEPm9zQG
|
||
XKQZclzYznlwGvLaebNWlj1FVVmdr9C5COtYbWrvZivpVviQW8njFy8ncp6P
|
||
j5+NRiO+ydS+765CLZ6/eNncJZ2rLeb3zEp1pUq88d3xQNyTsuSNHahqDMAE
|
||
GlxG1I8CG6QA3Z5IiGF8EBoVhHqGXUlrlduYQDHvxIUhsPjIyBLXRH5ZC/kT
|
||
vjc6PNRqZGbCvox8fus2Bg0wwqSlKHE7nSXuq8Zw+m+1LDkEF1QLJjWhC9e8
|
||
qvXSyNXdcDS44D43TnIitD3v6gllJ4ROy8hgm00kLLQNcKEUHCDSR0LchLWI
|
||
jN8o4oB2PYLGwpnujZuPBMA5kuFIi61UlY4tLjzIneyAlvTCx7mPe5R80Lds
|
||
ZLOLSE+cooVwxOSxje2ZoPfTvwX5S21BYAiLIKWjwPq13JFqmiYJjloabVTU
|
||
EDN14wdhUnYVcHJHo2ZQAzW/4T3Sy1kInM9iUiBupLiJg84gtUPbW1fL2aa2
|
||
G+NIpe1sb7qzVEtZzubSabIApVpqr9fSqxmx48ol9zaE6ayQW7z91bOj5mKx
|
||
MTPcAjL3pBQ35j97dS3df49aKW5+XCkWnU+N6CQQLXICrVwlRBzvW7UXz9kH
|
||
IzInhRd0BLFjXVLOLICY1ghbJkIkypd5n2Vp5pQOU1f6t7qzm6RrSCF6w47U
|
||
YigzolIin0aIV4N5NrVfmpbGjcxmYIcaRRB1jq5ys96/vVAY0mbNFYNX0tpt
|
||
YD8p2SEZ0UiIaJ0ilfTT5VnUQaV0fgeJ8Fs2VuWqaOEd7kKKBfJKOHDqtzqw
|
||
z/kKO8FEYB6j3In1jO9NFV46p6Ev+69E4LjPYcP7EBq8fdSntVjS4r1vcY8z
|
||
/S7EtFdVdlIlkM0DzMislrFfiEvF4LYhv++zq9srZVEL3A9GYVr2UsM6eExQ
|
||
H2QZX4pSd9f08ewt+jU/NuT6HXyKeuiErSV+E6MYd+Jukjoi6W/dK3tXxR0E
|
||
vBN8qdPPROHT5169M4R9HTOERJsk8RVSF3AH58pCuJW8dmdu4hvhDrNtLj7+
|
||
lT8Hlm7GylJfqWHzlS6GoK5wYXI1y0vpOGVAIQ8Od/AKtkpaR+2v9EbK8AZq
|
||
n1N34A42K52MhFVDOwqMLq3r9axS+L3EW3IiEIuZIoYW7uBl8x709LycN3IW
|
||
/bwe+UxkbhDE8aRJfIYfMRgfZTgYqCToHWj1EM5qDBIFIDddl4W3quixOyGj
|
||
Kt3XFHJkUlpRwDI2LVoHiDzNQuWlxFf2OpjTlvDHFoVVZPyjdqX0c1JZO4aU
|
||
c7XiDD0OYvgkRTPRafkGSRTwkCyizoq4pW28NWBD1tWzubGFsjOK1C2UxVap
|
||
C+HVIYqY640OWXQowM1QWLz7R/JtAo66P4h4f9fVAmOaVb6dLUq5HMJaVnJJ
|
||
UYIZQ2GeEmxiRrNVcDSIN0TT47hh+vv84KbB4MrvbZvevs+RXMCWpHMm19Kr
|
||
YRKxmnGKbgg14FvmFin+mdXuCz6inMNhBsCX7Ln3MZjHmrIT82wCfdql/nRn
|
||
96QUgqgrinutFLuJ+PwAMx12YVxzMfEVez1K9Idrq12hKZCAl08/xyuu3mB+
|
||
iDN2G8fvCegVKpsvCh3vS4V0MMHMMxWuyEL9Vst8OytUrl14gaqz2mXFZhGf
|
||
bzeFutlowpLjVy+fHb16/fzoqIvQ0pBOQu5FoqaF3imci6GHxKOKefdC/EwZ
|
||
fm1UkwajevD+cIfBaDJTVBWCf4lvgZtIV7X2uDTjEdNeKYwCzFf19J5DUXRq
|
||
hPMTcZ560dB3jsASBeqgUtflFpaqCmGpLsg67usFYkWGAgd7waF8ThNYo/7V
|
||
PqLXHqQnSxNgL7uQS06qhJWsCrNYjIR4xv3oQ4lhSvAlC213gR9lRWO2fAXo
|
||
9EW3LqG3OgOZ6dY75kHjw/yq7xxP5U+XZyMhno8YAkeesMtwIp350ARhq7xV
|
||
tcXQ5SbEtQMZqoolB+qJeDvEDCP0O7gCzL39fJEFZJ/QcLsbHyO4uMeaSYht
|
||
MfvxL7M4TLvRbH4VmYWr/DUUVWwTV2WPp/p6hi6Odub1WrXU3zhQf3GT7w7/
|
||
epGNw092fHx8nD179uxZ9vz58+fZi+Sn09OHaDoa9c4NbIXDdbYrqpixqh9M
|
||
4O8JLzbsMl7DHW7rl0ATFjL33Sb6PfNhrx/+S8p57feI09d2XwLSWsTQqqrX
|
||
pGQEZxVFhIbpQ3se43ddYp94iSvt9LxU4gFFgqkmnLKEQXXtVyuEpUkCY9hT
|
||
59KS58I2YeqcWs/LrRARXxobGPXG8d5NE8a86k62C4JW8szTJCldou+VpIwh
|
||
xUeOpVmkSke0sYgRAJuXtiulzL+4pC8SNtj/vC5l9PiHAptu7QiX0GDOPFNw
|
||
2Nu5ijC3gJikj4SAePyQqqKEYqWJXXC6UClnGcoQUq7hSZLOg2k2zaiRYax8
|
||
dD8DpBbNaoeXxaRmyQRaT9ppktbAEkK5E5DkTghM1wkmwanlOnktT1DsobrZ
|
||
GNdJayeIjAJWVxG8qYJnW7mQQtxX4Xb7qDcFloXtM72DS98wczpXGx9L+9pw
|
||
iuvNH4lrgMxe7VT/23/6+VLE0jq4veVP9/dpDq83kW1CRz5bWkkkNe1BkSRZ
|
||
7QhfYk20c7UqGNDQZxttr5BVHF2yFtR0lLuudWwUBxgr4i4d0e4L7XRebtWm
|
||
lBilK7SlKBIrDtqgqNxUkYzgXw0P/RERl5lDU/F3Bqo/b38ajUYYHHv5vLZl
|
||
pqrcFKpTA4ODwGCDAPglNjCT5TJEJLLjFy+baMNZVegrXdStw0xBh2ZG51vO
|
||
VivajZdEFJKJgitZ1oglEXzRxsa7ef6jllQ24uD/h7qXEukp9x9LwYKX3+G/
|
||
gpuNqueqfYLSVrdpEiYpadEOgHLvz+t5qfNJlGyMFxhy6luMRX3sKtgR5oTH
|
||
/NXkWUpsDqZCr9eqQPcM6o3zVsl1QKiFua7CF7H8AzuCWgeLLT8ozLRKxLX2
|
||
zUwZq5dkflJqD+3i/sB1wj+EMezTEFR7p7CmJmciNs0G64kfBJ8RbW1MgX+P
|
||
TmxwN+FTXSoXXZWd7fy1/oqw2AjnDbNPEqg7cu3ZkkiHUIEmbMB8zByHxxgg
|
||
RN9ZqghKtxs1xHl6zDhSpho1+MYaUtxMS+PzQWSoGAfmtY/lTZj0G+A0yzU7
|
||
L/3djaNt+1ukIhde1QpNTxfnZODCIFGVu3oeyOPWY2gklkw+uzEHJpBE/0B/
|
||
ZFkmbbLvcUk2lDiLyKpxG3GGGq6KYoXdCAONzk3gV6+HKQqhEtGg/ZJkgIiN
|
||
KVeyp7wrMNppxisu+nsq9EA6e7eOI8pueOJyu0FJ/QrGuZt1yjaUvcXYNlHQ
|
||
nZaRPa00psq9pRqJTS/f3HDKOzS0uAsVaqpJ1ck3dUbsNdan4bzgKq+xyMQh
|
||
HCyYv12rNW7u5qn51qsMn3rPFzjNFiWJLiRPhkK3mVpi8SM/6bCJj7WnxWpK
|
||
4SK313lMV53n7uCseuCpUEK3381zjAU4gmzxnr7Oyg3yamXp4uSgTBAJf4Ml
|
||
97Kk2jxdXZk8JOLiU2W5nnk+LaL71LtO5V5at9dUDBbUwnJTz9qFod95Uf58
|
||
eFEi2d0WGTZsdyovPUR3I9PnlHqd5HeT3LENJpBSJDnbMVE7KAEW1P1U7UD2
|
||
SPcFznjtJo0EJ6NmpciZ7QRJSbOiA8hkAvp6I9R5TdJAbzNFbeNzado4liPb
|
||
EfEsxpRw1ixYbyPzLVsnj/fi8odkdGJaqO0RKSl8yenhIXFeQBxSJIt85K7w
|
||
6eDEjsSLUUDLH6+UXSlZ9LYYeKxDTXYxtV+ptVPlFRkLwjLdFPuYt4B2kq6Q
|
||
lWFcJT1hYo48UHoWuRfSffnO9aSvjxI5gk+hFU4YQxan2/pu2tQuoqW7Z9RF
|
||
okbjKkZgGsiGSOu0m41viKn6gwk8P3rzkr6rK01t0UYMlIWX1u9wIjEdSlXF
|
||
3pUXTKaYasH0PzYXahyKTq5Meg9QESe6BxhjVVQ7TZ4mY6Q4H6JtCR6rG5l7
|
||
0OR3o6kgMX0yhAFaaYz+401U2eC8zmUpHEJ3XS2fDLGUYYCuZR5ukxsqcDe4
|
||
W4mIkJzth3vXlE/Y49svpHBw+yhZ5JDr10Rplc04PbtRE2kTLaffU/HR5JB8
|
||
E6vPDR1g9cPFhtUnPRTYLLfBevODbhHe+VQ2rD+xTTs02FfnsjWJIg/6VRh1
|
||
UFabIk0eIVHck0K6pKoiuTA+4gyN0BIr58YVg6bF39tETc7IzlYKFie9J9lN
|
||
xy/ajqV7ikxT+syhTcKX74d/UG93Nv5+h+P23+1wowT+qP6inZi1IODBXjeI
|
||
4kCnn/0BPab/f9nN45kul1ZxvRBMOY/47fTP8MEUrSPVOp94CQ8NSU4QCNX8
|
||
PdVLIvAgMryCgX2wL0mrGSUYtjDX1eu1tNsRKU6Z9A8dBXKaL+p1LL7CbOfA
|
||
c1G+TAcskz3E+YqFVOxV4CgqHGBTydg4sxm8DzVIsFE2I3O8tLJC1hGdWwTf
|
||
hXYEwaj6quYkmSzmB/udPq+VX5kCHg9cvUaCeS1v8L9rpZcrVMd0LoEAhhad
|
||
zkfzSQfBXKpKVh7OnAmV7eKsilq7ewBJekzMsG0xYDaK9DNXosBzozo2Csta
|
||
Wll5Fc4FYKoD9SFxlT2aO7puHaorlu2pAuflYhVSECJuCQWnofMIXdHsuCfc
|
||
GPJ97IumNqsVbWBhoQNVottEc843c5ElTzq+/aSnqC6WbNMBH+mJHiDnyJBS
|
||
UhkF33F63Hc7ZYJsH2NF/llSkX/7qK/snpexLQNsQqqE6q60uk6LBJsU1uhN
|
||
t2mVfmWVyjYrTDmPMdWJEOf0xZiPIQlH12A6QFqTkIC6EBpjV4zPugk7Tv9j
|
||
/wSPOGfkdMZT/oCtVZOzSm1QQmrTeCTidgIbeB0vfVEYlOCeH3PPQyEk428x
|
||
4WhFrjcp2YQcCLK7S9XpPxdDEs2/JZjaVkr2MPtr6fPVCIg1s2qDZZOKnRlM
|
||
xViqcPwJpmTUlEiKS9T09hn2tlvTGfvezKomNHylbFB5a1Mpj32Ra9TZoTwD
|
||
y76tyuTSKtwfyLnkEqMBkApLUwlqFQZYl3wGEKREWTO7HEIdRQIeu8ISkaDu
|
||
zrr/D+Kl9PyMn4/YGz8r+1UMcpCg2Q7eOYh2Wqxz/OLN8RFnOQTQXdNpENL6
|
||
7dcFTtmsNMioQVq/i3gG3nhZzhJ7PH6xA8kO4B5Gj2ypJzA+ftHBaod70INi
|
||
9jvx4vj58evXPX3oAINDXWh490J5qcvdaoCFwug2B7SbmgAU0hkK6V51h80z
|
||
KefzPC+KbDymwDDFhF++zF69ev36zZujI/y66xOlb2ZZxI9NsibGFSPNF2yx
|
||
6D1JrSkFYOq/lQsufP+tVo5OBBRBReg2nBC3V2AI+kw77aYfpbbZZ6fglMlq
|
||
2pvvm1BTPFSCY1aB0IYFPoQGLR5hgVHFbuV7OiCyuZ9QD7zTa01qHNJm9ZoS
|
||
MXEumhp1/CXiKKx1wKdLTdknNEMpczgCbp2ut33iw0VQZVJR/7quyC1tWPtD
|
||
mhTPoIMf6mKpPJzIjZu0h51SdzmVWbadmPO90a87uYylEslRhfKG2N10mTfE
|
||
EqTACPhgLTQ4jS1XN7lSRYiRh7BDeGGMfJp5c3IjaXVHqv705JJGMq3MWpZb
|
||
eKvC8XPt5IfjV9amosh0p3OY5mf5oJGqIAuCB4CsZYmH77GyDYCHT+JKHx4f
|
||
3SDkuFLhSIW4kN+53TGQU97BGhQIPD25pNci+5VxtcyhkrsDB0pFZ7s9x0p0
|
||
D9/hGr1QOcNHsIWRNIdkpjU/2KO2aANPIjp4KNaTmEyOz8SqOExLpzeqIiQj
|
||
JNqR52IQAriQxtZwHzScO0H/dKLDjuAKIpztONMBwmAPUGRl6Uwjt2m0MyZ0
|
||
YJZqnITegJZrAjet00RjwmQnkjeMtViJWeeIJJHdeGi+0nrHdsKmD0wYsSNJ
|
||
QHfYDds2cVzKehyGSrlhp6BlGHNaIsXSFRIBe8f+8Dy6Tk1YkzhKkSI6ByZr
|
||
KiMSJ4WP2o65q3vHeTWn542E+CGecnaSnnJGYDfKZrMlcI44mcfYsCqFAQ6b
|
||
5WZZ6X9wSLNSqDhDvzm1elkZSxfXpHzisXiYcpCkLgPFCQU0BZxv6KC3nnyG
|
||
RV3lnO+NLmSBe7igJ5dW5orqyybdGerMT0iRpHK52FQ4hQfV2toUabUGuhp5
|
||
bUPQGiO3NpyFtJsVeinXG2Z+o+PP+k6IH1Qu0W6l0VhOgOwWMEfr2XH/hkJS
|
||
+MiaNarYtrKlgoWcWzIuaLpk6cOJHt18FZGkh44A3mvfnGcSqGc2lE2h0Dvy
|
||
CJ9BU7EIjxkJZ7LKVwa16On00kVPu1+6gEKwMSNGVVfamiqctbpzQh43Dtw4
|
||
mZOO/oSHi5bxAFUyMeCb+ZcLr6JqWsjc4yvTg9D9StsiY0jDs5NkUu15OKMD
|
||
sckfrawLYt4lmn40UM2ReXWJRElBWpRcg1533xthFbE3ycFz6YEzxtI5LbER
|
||
b9C9pgM48xVGudxIHFrPHzTeZ2XZKT96cKDDkFLBLisKTKh4KmVNWXNgyVdM
|
||
T/pJhkPsREuZQ6TM+WS9jfFZvlJ0VDIfDrVPcAHIJe4Y5Jc8wskdKmatvNW5
|
||
G3XENaH192gNOqRWL1cZxfNblAgh9stWnCoQsKWE/A9xA8eAIrAFDs9/YnE4
|
||
56QyeKfkFwQll3wQTlAISca3EKdXKuCLvsPIOFuiHWOnBJY2rXjs9ZpOlV4Q
|
||
+K7ycEJSAEu9a+qekIZASkbsUzKkqGX6vsSCJxIlOhIlQ9L7YS7AGzBzl2O7
|
||
rVOQ4APgkeACckLb7glkG6fqwlRbOms5LXOkLG1UGlSB3Jy5YGWI9MhqrzaR
|
||
QX3n0LIsprdExNGb9hASftr0xpglQe8+nBLxQG7f1HvMv+Tk0ALRSjyvry89
|
||
9OAEC9YsuO7rDemD9kjeJpMkYob0rCs3EiErLpCVDuqq1NUXGbKMWqqSK5EX
|
||
KO3gZOkJfQg6nRDHzDYsTfY7Q16gCaK5hnfsHgpFK2MxGX8dmsUzCelUYOdh
|
||
fPwa5hFT4itidztntz2Cs+mHaZ8dpqxIHvcntQxHI+Lm6yaEBOcV2df2praa
|
||
sXtGBIN3xSzOz2oe6uZPYm4MtbAFPABtXmpMIcSYdoJeKI+EbocPyKXDbv4I
|
||
tPW+e7kkD5QyYspEA0ip1emB+tG7nRJMfDRBr0BdeKhE/lADiHaJDuk00JQV
|
||
hQqJvqepgiL+3HWRwF7lfF8DLbDmCT1Uhx5XsX8IwXzFIfQY55Dm9tDjwYNK
|
||
WwjfBA9p/+GYPxJVDSePHBBfTh3pK/QNd213BbwVRsd1OfHv6sQs4d2W3EBE
|
||
SW7PTGi3Rpt8GM8QCImBsUQyngh7/JIOHTgL1bxpI3slvbsVvQf2wKHy3Z1i
|
||
Xa7VpZyNEt6i9J23R94nf1KjbyGTAlyuv5V2Livlso83pdrin9zofSypq+Wy
|
||
WjoHH86qCJjPjfVRs6KlDnlu8av+dtvUouXX1NJGEWiEJM0/+mb56CbSDRr1
|
||
xlHDb5IJ+BqZYAIek8PCYd+dpCp6Dv8iA57DjXp/mn+pzDV6CuRDiNsJ//Em
|
||
Vfz7YCFLR6dGcSU9ZtwTIPgSDwgKgY/KN6FN/HNOBEpQ29PfeBKBzNAWFkoV
|
||
+N6WXWyrSUO1cbA9shT5SpalqgiK/ze7cTrVEGsAAA==
|
||
|
||
-->
|
||
|
||
</rfc>
|
||
|