AGTP Trust and Verification Specification
draft-hood-agtp-trust-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Chris Hood | ||
| Last updated | 2026-10-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hood-agtp-trust-03
Independent Submission C. Hood
Internet-Draft Nomotic, Inc.
Intended status: Informational 30 October 2026
Expires: 3 May 2027
AGTP Trust and Verification Specification
draft-hood-agtp-trust-03
Abstract
This document specifies the AGTP trust and verification model: the
trust tiers an AGTP agent may occupy, the verification paths by which
a Tier 1 agent's identity is established, the registration procedures
by which a governance platform assigns a tier, and the trust score
that is carried alongside an agent's identity to express runtime
behavioral assessment. AGTP-TRUST is consumed by AGTP-aware
infrastructure components (Scope-Enforcement Points, governance
gateways, peer agents) for runtime trust-aware routing and authority
decisions, and by registration authorities when issuing or evaluating
Agent Genesis documents. This is an early working draft; the
dimension catalog, computation methodology, and several aspects of
the registration procedure are placeholders pending further work.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 May 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hood Expires 3 May 2027 [Page 1]
Internet-Draft AGTP-TRUST October 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Credit Rating Analogy and Composable Trust Providers . . . . 6
3.1. The Credit Rating Pattern . . . . . . . . . . . . . . . . 6
3.2. AGTP-TRUST as Substrate for Agent Credit Scoring . . . . 6
3.3. Composable Trust Providers . . . . . . . . . . . . . . . 7
3.4. Where the Credit Scoring Lives . . . . . . . . . . . . . 8
3.5. Forward-Looking Composability . . . . . . . . . . . . . . 9
4. Trust Tiers and Verification Paths . . . . . . . . . . . . . 9
4.1. Trust Tier 1 (Verified) . . . . . . . . . . . . . . . . . 9
4.1.1. dns-anchored . . . . . . . . . . . . . . . . . . . . 10
4.1.2. log-anchored . . . . . . . . . . . . . . . . . . . . 10
4.1.3. hybrid . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Trust Tier 2 (Org-Asserted) . . . . . . . . . . . . . . . 11
4.3. Trust Tier 3 (Experimental) . . . . . . . . . . . . . . . 11
4.4. Verification Path Field Values . . . . . . . . . . . . . 11
4.5. Trust Tier Summary . . . . . . . . . . . . . . . . . . . 12
4.6. Agent Identity Document Trust Posture Loading . . . . . . 13
4.6.1. Surfacing Trust Posture on Response Headers . . . . . 14
5. Registration . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Tier 1 Registration (Verified) . . . . . . . . . . . . . 15
5.2. Trust Anchor Resolution . . . . . . . . . . . . . . . . . 16
5.3. Tier 2 Registration (Org-Asserted) . . . . . . . . . . . 17
5.4. Tier 3 Registration (Experimental) . . . . . . . . . . . 17
6. Resolution Paths Beyond DNS . . . . . . . . . . . . . . . . . 18
7. Trust Score Range and Interpretation . . . . . . . . . . . . 18
7.1. Normative Range . . . . . . . . . . . . . . . . . . . . . 18
7.2. Interpretation . . . . . . . . . . . . . . . . . . . . . 18
7.3. Trust Score Versus Trust Tier . . . . . . . . . . . . . . 19
8. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. The trust_score_computed_at Field . . . . . . . . . . . . 19
8.2. Freshness Thresholds . . . . . . . . . . . . . . . . . . 20
8.3. Issuer Refresh Cadence . . . . . . . . . . . . . . . . . 20
9. Trust Score Dimensions . . . . . . . . . . . . . . . . . . . 21
9.1. Composite vs Decomposed Scores . . . . . . . . . . . . . 21
9.2. Dimension Catalog . . . . . . . . . . . . . . . . . . . . 21
9.2.1. provenance . . . . . . . . . . . . . . . . . . . . . 21
9.2.2. attestation . . . . . . . . . . . . . . . . . . . . . 21
9.2.3. behavioral_history . . . . . . . . . . . . . . . . . 21
9.2.4. peer_reputation . . . . . . . . . . . . . . . . . . . 22
Hood Expires 3 May 2027 [Page 2]
Internet-Draft AGTP-TRUST October 2026
9.2.5. compliance . . . . . . . . . . . . . . . . . . . . . 22
9.3. trust_score_dimensions Object . . . . . . . . . . . . . . 22
9.4. Custom Dimensions . . . . . . . . . . . . . . . . . . . . 23
10. Signature Binding . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Trust Score Signed Within the Identity Document . . . . 23
10.2. Detached Trust Score Documents . . . . . . . . . . . . . 23
10.3. Issuer Key Rotation . . . . . . . . . . . . . . . . . . 24
11. Computation Methodology Guidance . . . . . . . . . . . . . . 24
11.1. What This Document Leaves to the Issuer . . . . . . . . 24
11.2. Recommendations . . . . . . . . . . . . . . . . . . . . 24
12. Consumer Behavior . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Trust Score Evaluation . . . . . . . . . . . . . . . . . 25
12.2. Decision Mapping . . . . . . . . . . . . . . . . . . . . 25
12.3. Consumption by AGTP-Presence . . . . . . . . . . . . . . 26
12.3.1. Overlay Admission . . . . . . . . . . . . . . . . . 26
12.3.2. Visibility Posture as a Trust-Bearing Claim . . . . 26
12.3.3. Trust Score in Scope Admission . . . . . . . . . . . 26
12.3.4. Cross-Scope Resolution Trust Evaluation . . . . . . 27
12.3.5. Presence Operations as Behavioral Evidence . . . . . 27
13. Security Considerations . . . . . . . . . . . . . . . . . . . 27
13.1. Trust Score Forgery . . . . . . . . . . . . . . . . . . 27
13.2. Trust Score Replay . . . . . . . . . . . . . . . . . . . 27
13.3. Issuer Compromise . . . . . . . . . . . . . . . . . . . 27
13.4. Score Inflation Attacks . . . . . . . . . . . . . . . . 28
13.5. Out-of-Band Trust Score Channels . . . . . . . . . . . . 28
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
15. Open Items . . . . . . . . . . . . . . . . . . . . . . . . . 28
16. Changes from v02 . . . . . . . . . . . . . . . . . . . . . . 29
16.1. Substantive Changes in v03 . . . . . . . . . . . . . . . 29
17. Changes from v01 . . . . . . . . . . . . . . . . . . . . . . 30
17.1. Substantive Changes in v02 . . . . . . . . . . . . . . . 30
17.2. Changes from v00 (Carried Forward from v01) . . . . . . 30
17.3. Wire Format Compatibility . . . . . . . . . . . . . . . 32
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
19.1. Normative References . . . . . . . . . . . . . . . . . . 32
19.2. Informative References . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction
AGTP v07 carries identity-related fields in the Agent Genesis and
Agent Identity Document that together express the trust posture of a
registered agent: trust_tier (1, 2, or 3), verification_path (dns-
anchored, log-anchored, hybrid, or org-asserted), and trust_score (a
scalar on the closed interval [0.0, 1.0]). The base AGTP
specification establishes that these fields exist and defines their
syntactic representation in the Identity Document schema. AGTP
Hood Expires 3 May 2027 [Page 3]
Internet-Draft AGTP-TRUST October 2026
defers to this document for the normative semantics that govern how
trust tiers are assigned, how verification paths are exercised at
registration time, how a trust score is computed, how its freshness
is asserted, how its dimensional structure is exposed, and how its
integrity is bound to the signing issuer.
This document is organized in four parts:
* *Credit Rating Analogy and Composable Trust Providers*: the
framing that situates AGTP trust scoring alongside the established
credit-rating infrastructure operated by Experian, Equifax,
TransUnion, and similar institutions. AGTP-TRUST provides the
substrate primitives that allow existing credit bureaus and new
entrants to operate as agent trust providers, with their
proprietary scoring algorithms composing over AGTP's wire-level
evidence.
* *Trust Tiers and Verification Paths*: the structural identity
framework. Tier 1 (Verified), Tier 2 (Org-Asserted), Tier 3
(Experimental); the three Tier 1 verification paths (dns-anchored,
log-anchored, hybrid); the verification_path field values and
their consequences for Authority-Scope eligibility.
* *Registration*: the operator-facing procedures by which a
governance platform issues an Agent Genesis at a given trust tier.
Tier-specific packaging and evidence requirements.
* *Trust Score*: the runtime behavioral assessment overlaid on the
trust-tier structure. Normative range, freshness, dimensions,
signature binding, computation guidance, and consumer behavior
including consumption by AGTP-Presence overlay coordinators for
scope admission and visibility enforcement.
The motivating problem for the trust-score portion is that an
unbounded trust_score field is operationally useless. An
infrastructure component that receives a trust score with no
normative semantics cannot distinguish a well-computed value from a
freshly-fabricated one, cannot decide whether to refresh it, and
cannot verify that the value it received is the one the issuer
computed. AGTP-TRUST closes these gaps by specifying:
* The trust-tier framework that contextualizes any trust-score
evaluation.
* The verification paths that anchor a Tier 1 trust assertion in
cryptographic evidence.
* The normative numeric range and interpretation of trust_score.
Hood Expires 3 May 2027 [Page 4]
Internet-Draft AGTP-TRUST October 2026
* The required trust_score_computed_at freshness timestamp.
* The optional but normatively-specified trust_score_dimensions
structure that decomposes a composite score into the inputs that
produced it.
* The signature binding that ties a trust score to its issuing
authority.
* Implementation guidance for computation, refresh cadence, and
consumer-side trust evaluation.
The key requirements language follows [RFC2119] and [RFC8174].
2. Terminology
Trust Tier: One of three structural classifications recorded in the
trust_tier field of an Agent Genesis and Agent Identity Document.
Tier 1 (Verified) agents have completed a cryptographic
verification path at registration time. Tier 2 (Org-Asserted)
agents have declared an organizational affiliation without
cryptographic verification. Tier 3 (Experimental) agents are
unregistered and confined to development environments.
Verification Path: The mechanism by which a Tier 1 Agent Genesis was
anchored to evidence at ACTIVATE time. One of dns-anchored, log-
anchored, or hybrid. Tier 2 agents carry verification_path: org-
asserted to signal the absence of cryptographic verification.
Trust Score: A scalar on the closed interval [0.0, 1.0] representing
a behavioral trust assessment of an AGTP-registered agent at a
specific moment in time, attested by the issuing governance
authority. The trust score is overlaid on the trust-tier
structure: a Tier 2 agent may still have a high trust score
reflecting good behavioral history, but the absence of
cryptographic verification at the tier level remains a separate
consideration for consumers.
Trust Score Dimensions: The named decomposed inputs that contribute
to a composite trust score. Examples: provenance, attestation,
behavioral history, peer reputation. The dimension catalog is
normatively defined in Section 9.
Issuer: The governance authority that computes and signs an agent's
trust score and (for Tier 1 agents) anchored the verification path
at registration time. The Issuer URL is recorded in the issuer
field of the Agent Identity Document; the Issuer's public key is
published at a well-known location under that URL.
Hood Expires 3 May 2027 [Page 5]
Internet-Draft AGTP-TRUST October 2026
Freshness: The age of a trust score relative to the moment of
consumption, expressed as the difference between the current time
and the trust_score_computed_at timestamp.
3. Credit Rating Analogy and Composable Trust Providers
The architectural pattern this document specifies follows the credit
rating infrastructure that operates for human and institutional
entities today. Understanding this analogy clarifies what AGTP-TRUST
defines, what it leaves to others, and how existing credit bureaus
and new entrants can compose as trust providers in the agent
ecosystem.
3.1. The Credit Rating Pattern
Credit bureaus including Experian, Equifax, TransUnion, and similar
institutions in other jurisdictions operate on a consistent pattern:
* The underlying entity (a person or business) has identifiers
issued by external authorities (Social Security Administration,
Internal Revenue Service, Companies House, equivalent national
registries).
* The credit bureau collects behavioral evidence about the entity
from many independent sources (creditors, public records, payment
histories, employment records).
* The bureau computes a credit score using a proprietary algorithm
that aggregates and weights the evidence.
* The bureau signs and timestamps the score, making it consumable by
third parties for credit decisions.
* Multiple bureaus may score the same entity differently; consumers
of credit scores select which bureau to trust for which decisions.
The credit scoring algorithms used by FICO, VantageScore, and the
bureaus themselves are proprietary and left unstandardized at the
data-exchange layer. What is standardized is the identifier
infrastructure, the evidence-collection mechanisms, and the format in
which scores are exchanged.
3.2. AGTP-TRUST as Substrate for Agent Credit Scoring
AGTP-TRUST applies this pattern to agent infrastructure. The
architectural decomposition is:
Hood Expires 3 May 2027 [Page 6]
Internet-Draft AGTP-TRUST October 2026
+=============+=======================+============================+
| Layer | Human Credit Scoring | AGTP Trust Scoring |
+=============+=======================+============================+
| Identifier | SSN, EIN, national | Canonical Agent-ID, Owner- |
| | IDs | ID |
+-------------+-----------------------+----------------------------+
| Evidence | Payment history, | Attribution-Records, AGTP- |
| | public records, | LOG, peer interactions, |
| | creditor reports | attestations |
+-------------+-----------------------+----------------------------+
| Score | Proprietary algorithm | Proprietary algorithm (per |
| Computation | (FICO, VantageScore, | trust provider) |
| | bureau-specific) | |
+-------------+-----------------------+----------------------------+
| Score | Numeric score | trust_score on [0.0, 1.0] |
| Format | (300-850 for FICO) | with issuer signature per |
| | with bureau signature | this document |
+-------------+-----------------------+----------------------------+
| Consumer | Lender uses score for | AGTP infrastructure uses |
| Decision | credit approval | score for authority |
| | | decisions |
+-------------+-----------------------+----------------------------+
| Multiple | Person has scores | Agent has scores from |
| Providers | from multiple bureaus | multiple trust providers |
+-------------+-----------------------+----------------------------+
Table 1
AGTP-TRUST normatively defines the identifier infrastructure, the
evidence primitives, the score format, the freshness model, the
signature binding, and the consumer behavior. AGTP-TRUST leaves the
score computation algorithm to the issuer, just as the credit bureau
infrastructure leaves the FICO formula to FICO. Score computation is
the trust provider's intellectual property and competitive
differentiator.
3.3. Composable Trust Providers
This document explicitly invites existing credit bureaus and new
entrants to operate as agent trust providers. The operational and
regulatory infrastructure that Experian, Equifax, TransUnion, and
similar institutions have built over decades for human and business
credit scoring transfers to agent trust scoring:
* Data aggregation pipelines that ingest behavioral evidence at
scale
* Algorithmic scoring infrastructure with operational maturity
Hood Expires 3 May 2027 [Page 7]
Internet-Draft AGTP-TRUST October 2026
* Regulatory compliance frameworks for fair, accurate, and
disputable scoring decisions
* Distribution channels through which scores reach consumers
* Dispute resolution and correction processes
* Multi-bureau coexistence patterns that allow consumers to source
from multiple providers
These institutions are positioned to extend their existing
infrastructure to agent populations. AGTP-TRUST provides the
substrate primitives (verified identifiers, signed evidence, score
format, consumer behavior) that allow them to do so without
fundamental re-architecture.
New entrants specializing in agent-specific trust scoring are equally
valid as trust providers. The agent trust market may develop
differently from the human credit market, with providers specializing
by industry, capability domain, or trust tier. AGTP-TRUST favors
neither incumbents nor new entrants; both consume the same substrate
primitives.
3.4. Where the Credit Scoring Lives
A specific architectural point: agent credit scoring infrastructure
runs at the application layer over HTTP, the same way human credit
scoring infrastructure runs today. AGTP-TRUST places no requirement
that credit scoring be performed within the AGTP substrate. The
substrate provides the wire-level evidence (Attribution-Records,
verified identifiers, signed assertions) that scoring infrastructure
consumes; the scoring itself is application-layer software operated
by trust providers.
This composition matters because it lowers the adoption barrier for
existing credit bureaus. They can operate as agent trust providers
without deploying AGTP infrastructure. They need to ingest AGTP-
formatted evidence, run their existing scoring pipelines adapted for
agent-specific data, and publish scores in the format this document
specifies. The substrate-level evidence and the application-layer
scoring compose.
Hood Expires 3 May 2027 [Page 8]
Internet-Draft AGTP-TRUST October 2026
3.5. Forward-Looking Composability
This document is forward-looking about composable trust provision.
The agent population is going to grow rapidly. Agent-driven economic
activity is going to outpace human-driven activity in many domains.
Existing credit infrastructure has the operational maturity to extend
to agents; new entrants will compete for niches.
AGTP-TRUST is designed to accommodate both incumbent and new-entrant
trust providers, single-provider and multi-provider consumer models,
and trust scoring that evolves in sophistication as the agent
ecosystem matures. The specification provides the primitives;
operational ecosystems are expected to layer on top.
4. Trust Tiers and Verification Paths
AGTP recognizes three trust tiers and four verification path values.
Tiers express the structural identity classification; verification
paths express the evidence mechanism backing a Tier 1 assignment.
The combination is recorded in the Agent Genesis and surfaced in the
Agent Identity Document via the trust_tier and verification_path
fields.
4.1. Trust Tier 1 (Verified)
Tier 1 agents are eligible for the full Authority-Scope vocabulary,
delegation chains, financial transactions, and multi-organization
collaboration. Tier 1 verification requires exactly one of three
verification paths to succeed at ACTIVATE time. The verification
path chosen leaves the identity model and the canonical Agent-ID
untouched; it affects only the evidence chain backing the Agent
Genesis.
Hood Expires 3 May 2027 [Page 9]
Internet-Draft AGTP-TRUST October 2026
+==============+============================+=====================+
| Path | Mechanism | Evidence Anchor |
+==============+============================+=====================+
| dns-anchored | RFC 8555 ACME challenge | DNS TXT record |
| | against claimed org_domain | |
+--------------+----------------------------+---------------------+
| log-anchored | Agent Genesis inclusion in | Log inclusion proof |
| | AGTP transparency log | (RFC 9162 VDS, RFC |
| | | 9943 receipt) |
+--------------+----------------------------+---------------------+
| hybrid | DNS challenge combined | DNS TXT record + |
| | with blockchain address | blockchain |
| | signature | signature |
+--------------+----------------------------+---------------------+
Table 2: Trust Tier 1 Verification Paths
All Tier 1 paths produce identity attestations of equivalent strength
for AGTP protocol purposes. All Tier 1 paths require a .nomo
governed package.
4.1.1. dns-anchored
The governance platform *MUST* verify that the registering party
controls the DNS zone for the claimed org_domain before issuing a
Tier 1 Agent Genesis. Verification follows [RFC8555] (ACME). DNS-
anchored agents *MUST* have the following DNS record published and
verifiable at resolution time:
_agtp.[domain.tld]. IN TXT "agtp-zone=[zone-id]; cert=[fp]"
4.1.2. log-anchored
The governance platform *MUST* submit the Agent Genesis to an AGTP-
aligned transparency log and record the resulting inclusion proof in
the registry record. The log *MUST* implement the verifiable data
structure defined in [RFC9162] and *SHOULD* issue COSE_Sign1 receipts
per [RFC9943] (SCITT) for cross-ecosystem interoperability. A log-
anchored agent is verifiable by any party with access to the
transparency log, without dependence on DNS ownership. The log
server protocol, receipt schema, and federation model are specified
in [AGTP-LOG].
Hood Expires 3 May 2027 [Page 10]
Internet-Draft AGTP-TRUST October 2026
4.1.3. hybrid
The governance platform *MUST* verify both DNS control over the
claimed domain and ownership of the declared blockchain address via
signature challenge. This path is used by agents whose identity is
also anchored in a naming system other than DNS (a blockchain name
service, say) and who hold a verified DNS presence. The signature-
challenge procedure is the one the naming system itself defines; this
document fixes only that both proofs are required.
4.2. Trust Tier 2 (Org-Asserted)
For agents operating within a single organization's internal
infrastructure, or where no Tier 1 verification path has been
completed. The registering party asserts an organizational
affiliation without cryptographic proof. The Agent Identity Document
for Tier 2 agents *MUST* include a trust_tier: 2 field and a
trust_warning field with value "verification-incomplete". AGTP-aware
browsers and clients *MUST* surface a visible trust indicator
distinguishing Tier 2 from Tier 1.
Tier 2 agents *MUST NOT* be granted Authority-Scope values above
documents:query and knowledge:query without the AGTP Agent
Certificate extension [AGTP-CERT] providing cryptographic identity
binding at the TLS layer, Level 3 of [AGTP].
Tier 2 agents carry verification_path: org-asserted.
4.3. Trust Tier 3 (Experimental)
For development and testing environments only. Agent label uses the
X- prefix. Tier 3 agents are absent from the public AGTP registry
and from search. Implementations *MUST NOT* deploy Tier 3 agents in
production environments.
4.4. Verification Path Field Values
The verification_path field in the Agent Genesis declares how the
agent's identity was verified at ACTIVATE time:
Hood Expires 3 May 2027 [Page 11]
Internet-Draft AGTP-TRUST October 2026
+==============+============================+============+
| Value | Meaning | Default |
| | | Trust Tier |
+==============+============================+============+
| dns-anchored | DNS ownership verified via | Tier 1 |
| | RFC 8555 ACME challenge | |
+--------------+----------------------------+------------+
| log-anchored | Agent Genesis inclusion in | Tier 1 |
| | an AGTP transparency log | |
| | per RFC 9162 / RFC 9943 | |
+--------------+----------------------------+------------+
| hybrid | DNS ownership and | Tier 1 |
| | blockchain address | |
| | signature both verified | |
+--------------+----------------------------+------------+
| org-asserted | No cryptographic | Tier 2 |
| | verification; affiliation | |
| | asserted only | |
+--------------+----------------------------+------------+
Table 3: verification_path Field Values
Implementations that encounter an agent whose Agent Genesis carries
an unsupported verification_path value *MUST* treat the agent as
Trust Tier 2 (trust_warning: "verification-path-unsupported") until
an extension specification defining the value has been published and
implemented.
4.5. Trust Tier Summary
+==============+===========================+==========+==========+
| Trust Tier | Verification Paths (any | Package | Registry |
| | one sufficient) | Required | Visible |
+==============+===========================+==========+==========+
| 1 - Verified | DNS challenge per | .nomo | Yes |
| | [RFC8555]; OR log | | |
| | inclusion per [RFC9162] / | | |
| | [RFC9943]; OR hybrid DNS | | |
| | + blockchain signature | | |
+--------------+---------------------------+----------+----------+
| 2 - Org- | None (affiliation | .agent | Yes |
| Asserted | asserted without proof) | or .nomo | (with |
| | | | warning) |
+--------------+---------------------------+----------+----------+
| 3 - | None | Any | No |
| Experimental | | | |
+--------------+---------------------------+----------+----------+
Hood Expires 3 May 2027 [Page 12]
Internet-Draft AGTP-TRUST October 2026
Table 4: AGTP Trust Tier Summary
4.6. Agent Identity Document Trust Posture Loading
The Agent Identity Document carries the trust-posture fields
trust_tier, verification_path, and trust_warning (as defined in
[AGTP]). The fields *MAY* be declared directly in the Agent Identity
Document, *MAY* be derived from the agent's paired Agent Genesis at
load time, or *MAY* fall through to conservative defaults.
A conforming AGTP server *MUST* resolve trust-posture fields on the
Agent Identity Document according to the following precedence,
evaluated independently for each field:
1. *Explicit declaration.* If the field is present in the source
Agent Identity Document JSON, that value is authoritative for the
field and *MUST NOT* be overridden by a Genesis-derived value.
Operator intent is preserved.
2. *Genesis-derived fallback.* If the field is absent from the Agent
Identity Document and a paired Agent Genesis is loaded for the
agent, the server *MUST* lift the value from the Genesis:
trust_tier from the Genesis's trust_tier field, verification_path
from the Genesis's verification_path field. The lifted value is
treated as authoritative for the lifetime of the loaded document.
3. *Conservative default.* If the field is absent and no paired
Agent Genesis is loaded, the server *MUST* default the agent to
Trust Tier 2 with verification_path: org-asserted. This is the
conservative posture: an unverified agent is treated as org-
asserted, Tier 2, with no default promotion to Tier 1 and no
default demotion to Tier 3.
The trust_warning field is computed after the precedence is resolved,
on the basis of the resolved trust_tier:
Hood Expires 3 May 2027 [Page 13]
Internet-Draft AGTP-TRUST October 2026
+============+============================================+
| Resolved | trust_warning behavior |
| trust_tier | |
+============+============================================+
| 1 | Omitted unless the operator explicitly set |
| | a warning (in which case the operator |
| | value is preserved). |
+------------+--------------------------------------------+
| 2 | If the operator set no warning, the server |
| | *MUST* auto-populate trust_warning: |
| | "verification-incomplete" per Section 4.5. |
| | Operator-set values are preserved. |
+------------+--------------------------------------------+
| 3 | Omitted unless the operator explicitly set |
| | a warning. Tier 3 is experimental-only; |
| | warning policy is operator-controlled. |
+------------+--------------------------------------------+
Table 5: trust_warning Auto-Population
The owner_id field on the Agent Identity Document follows the same
precedence as the trust-posture fields (explicit declaration >
Genesis-derived > absent). owner_id lies outside the trust-posture
concepts and its semantics are specified by [AGTP-IDENTIFIERS]; the
loading rule is included here because the Agent Genesis is the common
source of all four fields and operators benefit from a single
precedence rule.
A server *SHOULD* log at startup which fields it resolved by Genesis-
derived fallback and which by conservative default, so operators can
audit whether their declared posture matches what the server
resolved.
4.6.1. Surfacing Trust Posture on Response Headers
A conforming AGTP server *SHOULD* stamp the resolved trust posture on
every response by emitting the following response headers defined in
[AGTP]:
* Trust-Tier: the resolved trust_tier value (1, 2, or 3).
* Verification-Path: the resolved verification_path value (dns-
anchored, log-anchored, hybrid, or org-asserted). Emitted when
Trust-Tier is emitted.
Hood Expires 3 May 2027 [Page 14]
Internet-Draft AGTP-TRUST October 2026
* Trust-Warning: the operator-set or auto-populated trust warning
token (e.g., verification-incomplete, verification-path-
unsupported). *MUST* be emitted when the resolved trust_tier is 2
and a warning is set; omitted on Tier 1 and Tier 3 responses
unless an operator-set warning exists.
The headers carry values resolved by the precedence rule in
Section 4.6. Servers that have yet to resolve a trust posture for
the responding agent (e.g., TLS-only deployments without a loaded
Agent Identity Document) *MAY* omit the headers.
Relying parties *MAY* branch on the response headers to apply trust-
tier-conditional policy on every exchange without consulting the
Agent Identity Document. Relying parties *MUST NOT* treat the
absence of Trust-Warning on a Tier 2 response as authoritative
without verifying that the server is conformant with this revision;
older servers may emit Tier 2 responses without the warning header
even when a warning is set on the Agent Identity Document.
5. Registration
The registration tier determines the verification procedure a
governance platform applies at ACTIVATE time. Registration tiers
correspond one-to-one with trust tiers; the procedural and packaging
requirements differ.
5.1. Tier 1 Registration (Verified)
Required for agents carrying Authority-Scope beyond read-only query
operations, or participating in delegation chains, financial
transactions, or multi-agent collaboration with external
organizations. Tier 1 registration requires exactly one of the three
verification paths defined in Section 4 to succeed at ACTIVATE time.
Common requirements for all Tier 1 paths:
* Agent package *MUST* be in .nomo governed format
* Package *MUST* include a valid CA-signed certificate chain
* Governance platform *MUST* validate package integrity hash and
certificate chain before issuing the Agent Genesis
* Agent Genesis *MUST* record the specific verification_path used
(dns-anchored, log-anchored, or hybrid)
Path-specific requirements:
Hood Expires 3 May 2027 [Page 15]
Internet-Draft AGTP-TRUST October 2026
* dns-anchored: Registrant demonstrates DNS control over the claimed
org_domain via DNS challenge per [RFC8555]. Tier 1 _agtp TXT
record *MUST* be published and verifiable at resolution time.
* log-anchored: Governance platform submits the Agent Genesis to an
AGTP-aligned transparency log implementing [RFC9162] and records
the inclusion proof in the registry. COSE_Sign1 receipts per
[RFC9943] (SCITT) *SHOULD* be issued for cross-ecosystem
interoperability. The registering party need control no DNS
domain.
* hybrid: Registrant demonstrates both DNS control and blockchain
address ownership, the latter by the signature challenge the
naming system defines.
5.2. Trust Anchor Resolution
Tier 1 verification requires the relying party to determine that a
Genesis-issuer key is trustworthy. The mechanism by which a verifier
decides this is a deployment-policy concern, but two patterns are
defined here normatively:
*Local trust anchors.* A verifier maintains a static list of trusted
Genesis-issuer keys (typically operator-curated per governance zone).
Each entry has the form {"type": "key", "value": KEY} where KEY is
the base64url-encoded Ed25519 public key. A Genesis whose
issuer_public_key matches an entry in the list is treated as Tier 1;
a Genesis with no matching entry falls back to lower-tier treatment
per local policy. This is the simplest pattern and the appropriate
default for closed deployments.
*OIDC-federated trust anchors.* A verifier maintains a list of OIDC
discovery anchors. Each entry has the form {"type": "oidc",
"discovery_url": URL, "trusted_issuer": ISSUER} where URL is the OIDC
discovery document URL and ISSUER is the trusted issuer identifier.
At resolution time, the verifier fetches the OIDC discovery document
at the configured URL, locates the jwks_uri, fetches the JWKS, and
confirms that the Genesis-issuer issuer_public_key matches one of the
keys published in the JWKS. The JWKS response *SHOULD* be cached
with a reasonable TTL (default 1 hour); cache misses *MUST NOT*
propagate as Tier 1 trust failures; unresolvable issuers fall back to
lower-tier treatment per local policy.
Hood Expires 3 May 2027 [Page 16]
Internet-Draft AGTP-TRUST October 2026
The OIDC-federated path lets enterprise deployments bottom the
Genesis-issuer trust path out in their existing identity
infrastructure, with no separate trusted-registrars list to maintain.
The Genesis schema is unchanged; the change is confined to the
resolution path the verifier uses to decide whether a recorded issuer
key is trusted.
The pattern types coexist: a verifier *MAY* maintain a mixed list
with both key and oidc entries and consider an issuer trusted if any
entry matches.
Verifiers *MUST* treat network failures on OIDC discovery or JWKS
retrieval as non-fatal: the affected Genesis is treated as having an
unresolvable issuer (typically falling back to Tier 2 or Tier 3 per
local policy), but other trust evaluations against the same verifier
are unaffected.
5.3. Tier 2 Registration (Org-Asserted)
For agents operating within a single organization's internal
infrastructure, or where no Tier 1 verification path has been
completed.
Requirements:
* Organizational affiliation is declared but no cryptographic
verification is performed
* Agent package *MAY* be .agent or .nomo format
* Governance platform *MUST* issue Agent Genesis after validating
package integrity hash
* Agent Genesis and Identity Document *MUST* include trust_tier: 2
and trust_warning: "verification-incomplete"
* Authority-Scope *MUST* be restricted at the Scope-Enforcement
Point layer until upgraded to Tier 1
5.4. Tier 3 Registration (Experimental)
For development and testing environments only.
Requirements:
* Agent label *MUST* carry the X- prefix
* Agent *MUST NOT* be published to the public AGTP registry
Hood Expires 3 May 2027 [Page 17]
Internet-Draft AGTP-TRUST October 2026
* Agent *MUST NOT* be deployed in production environments
* Governance platform issues a locally-scoped Agent Genesis
6. Resolution Paths Beyond DNS
AGTP identity is agent-first and anchored in the Agent Genesis.
Verification paths (DNS, log, hybrid) and resolution paths (canonical
ID, domain-anchored lookup, and any other naming system that resolves
to a Canonical Agent-ID) are independent dimensions of the identity
model. An agent resolvable through a naming system other than DNS is
a full participant: its Agent Genesis is verified through one of the
paths above, and the other naming system is an alias that resolves to
the canonical ID per [AGTP].
Earlier revisions cited a Web3 bridge companion for this case. That
draft has expired and is withdrawn from the family for this cycle;
the hybrid path and the alias rule of [AGTP] cover what this document
needs from it.
7. Trust Score Range and Interpretation
7.1. Normative Range
The trust_score field *MUST* be a scalar on the closed interval [0.0,
1.0], inclusive of both endpoints. Implementations *MUST* encode the
value as a JSON number with at least two decimal places of precision.
Trust scores outside this range *MUST* be rejected by consumers; the
Identity Document carrying an out-of-range score *MUST NOT* be
admitted as authoritative.
7.2. Interpretation
The interpretation of trust score values is anchored at the endpoints
and at the midpoint:
* *0.00*: No trust. The agent has been positively attested as
untrustworthy or has accumulated behavioral evidence sufficient to
warrant a Revoked or Suspended lifecycle state. Consumers
*SHOULD* treat a score of 0.00 as equivalent to a 410 Gone
response for governance purposes.
* *0.50*: Neutral. The agent has insufficient behavioral history,
attestation, or provenance evidence to warrant a more favorable
score. New agents (recently registered, no operational history)
*SHOULD* be assigned a score in the neutral band [0.40, 0.60]
pending accumulation of evidence.
Hood Expires 3 May 2027 [Page 18]
Internet-Draft AGTP-TRUST October 2026
* *1.00*: Maximum trust. The agent has accumulated complete
positive evidence across all dimensions defined in Section 9.
Implementations *SHOULD* rarely return 1.00 in practice; reserving
1.00 for ideal evidence preserves the dynamic range of the scale.
The interpretation of intermediate values is governance-policy
defined; this document fixes only the endpoints. AGTP-TRUST
specifies no mappings from trust score ranges to authority decisions;
consumers (SEPs, governance gateways, peer agents) make those
decisions according to their own policies, with the trust score as
one of several inputs.
7.3. Trust Score Versus Trust Tier
The trust_score field and the trust_tier field carry distinct
semantics and *MUST NOT* be conflated. Trust Tier (defined in
[AGTP]) is a discrete classification (Tier 1, Tier 2, Tier 3)
reflecting the verification strength of the agent's identity
attestation. Trust Score is a continuous behavioral assessment that
varies over the agent's operational lifetime independent of Trust
Tier. A Tier 1 agent may have a trust score of 0.30 (high
verification strength, poor behavioral history); a Tier 2 agent may
have a trust score of 0.85 (lower verification strength, strong
behavioral history). Both fields are surfaced in the Identity
Document; consumers evaluate them independently.
8. Freshness
8.1. The trust_score_computed_at Field
Every Identity Document carrying a trust_score field *MUST* also
carry a trust_score_computed_at field. The value is an ISO 8601
timestamp recording the moment at which the issuer computed the trust
score. The timestamp *MUST* be in UTC with explicit timezone
indicator (Z).
A trust_score value without a corresponding trust_score_computed_at
*MUST* be treated as absent: the consumer evaluates the agent as one
that presents no score, and *MUST NOT* reject the Identity Document
on that ground alone, since the document's identity function is
independent of its trust posture. An Identity Document that asserts
a trust score with no freshness anchor cannot be evaluated for replay
or staleness. The coupling is carried into the Identity Document
schema by [AGTP-IDDOC], which lists trust_score_computed_at as
REQUIRED whenever trust_score is present.
Hood Expires 3 May 2027 [Page 19]
Internet-Draft AGTP-TRUST October 2026
8.2. Freshness Thresholds
Consumers of trust scores *SHOULD* apply a freshness threshold
appropriate to the operation being authorized. AGTP-TRUST defines
the following recommended thresholds, expressed as upper bounds on
the difference between consumption time and trust_score_computed_at:
+===============================+===============================+
| Operation Class | Recommended Maximum Freshness |
+===============================+===============================+
| Read-only QUERY, DESCRIBE, | 24 hours |
| DISCOVER | |
+-------------------------------+-------------------------------+
| EXECUTE without external | 1 hour |
| state effect | |
+-------------------------------+-------------------------------+
| EXECUTE with external state | 5 minutes |
| effect (writes, transactions) | |
+-------------------------------+-------------------------------+
| DELEGATE with elevated | 1 minute |
| authority | |
+-------------------------------+-------------------------------+
| PURCHASE / financial | 30 seconds |
| transactions | |
+-------------------------------+-------------------------------+
Table 6: Recommended Trust Score Freshness Thresholds
These thresholds are recommendations and carry no normative force.
Consumers *MAY* adopt stricter or looser thresholds based on
governance policy. Implementations *MUST* document the freshness
thresholds they enforce.
8.3. Issuer Refresh Cadence
Issuers *SHOULD* refresh trust scores at a cadence sufficient to keep
most consumed scores within the recommended freshness windows for the
operations the agent typically performs. For agents participating in
transactional operations (PURCHASE, DELEGATE with elevated
authority), the issuer refresh cadence *SHOULD NOT* exceed 5 minutes.
Hood Expires 3 May 2027 [Page 20]
Internet-Draft AGTP-TRUST October 2026
The mechanism by which an issuer publishes refreshed scores is
implementation-defined. Two common patterns are: (a) re-issuing the
Identity Document with updated trust_score and
trust_score_computed_at fields, with the new document replacing the
previous version at the same canonical Agent-ID; (b) publishing trust
score deltas through a separate Trust Score Update endpoint that
consumers poll independently of full Identity Document retrieval.
Pattern (a) is simpler and is *RECOMMENDED* for v00 implementations;
pattern (b) is anticipated in a future revision.
9. Trust Score Dimensions
9.1. Composite vs Decomposed Scores
A trust score *MAY* be a composite of multiple dimensional inputs, or
*MAY* be a single-dimensional value. Issuers that compute composite
scores *SHOULD* expose the decomposition in a trust_score_dimensions
object so consumers can apply dimensional weighting in their own
evaluation.
9.2. Dimension Catalog
AGTP-TRUST defines the following named dimensions. The catalog is
non-exhaustive; issuers *MAY* add custom dimensions following the
naming and structure conventions defined in Section 9.4.
9.2.1. provenance
The strength of the agent's identity provenance, including
verification path used at registration (dns-anchored, log-anchored,
hybrid), governance platform reputation, and signature chain
integrity.
9.2.2. attestation
The strength of available execution attestation evidence per
[RFC9334]. Agents producing RATS attestation evidence in
Attribution-Records score higher on this dimension than agents
producing none.
9.2.3. behavioral_history
A summary of the agent's operational history, including:
* Frequency of normative-correct ESCALATE invocations.
* Frequency of scope violations (455), zone violations (457), and
budget exceeds (456).
Hood Expires 3 May 2027 [Page 21]
Internet-Draft AGTP-TRUST October 2026
* Frequency of confirmed-rejected CONFIRM responses on prior
delegations.
* Time-in-service (older agents with clean history score higher than
newly-registered agents).
9.2.4. peer_reputation
Trust signals received from peer agents and governance authorities
external to the issuer. Specific peer-reputation protocols are out
of scope for this draft; the dimension is reserved.
9.2.5. compliance
Agent's recent compliance with governance policy: attestation
freshness, revocation responsiveness, and audit cooperation.
9.3. trust_score_dimensions Object
When present, the trust_score_dimensions field *MUST* be a JSON
object whose keys are dimension names (from the catalog or custom)
and whose values are scalars on the closed interval [0.0, 1.0], each
interpreted according to the same scale as the composite trust_score.
{
"trust_score": 0.78,
"trust_score_computed_at": "2026-04-15T14:30:00Z",
"trust_score_dimensions": {
"provenance": 0.95,
"attestation": 0.80,
"behavioral_history": 0.70,
"peer_reputation": null,
"compliance": 0.85
}
}
Figure 1: Example trust_score_dimensions Object
A dimension value of null indicates that the dimension is defined but
has no value computed for this agent (insufficient data,
inapplicable, or pending). A dimension absent from the object
indicates that the issuer computes no value for that dimension at
all.
The composite trust_score is *NOT REQUIRED* to be the arithmetic mean
of the dimensional values. Issuers *MAY* weight dimensions non-
uniformly, apply non-linear combinations, or compute the composite
through governance-policy-specific algorithms. The dimensional
Hood Expires 3 May 2027 [Page 22]
Internet-Draft AGTP-TRUST October 2026
decomposition is informational; the composite is the authoritative
score for protocol-level decisions unless a consumer explicitly
applies its own dimensional weighting.
9.4. Custom Dimensions
Issuers *MAY* define custom dimensions. Custom dimension names
*MUST* be lowercase ASCII identifiers with optional dotted
namespacing (e.g., acme.financial_compliance). Custom dimensions
without a dotted namespace are reserved for future AGTP-TRUST catalog
additions and *SHOULD NOT* be used by issuers.
10. Signature Binding
10.1. Trust Score Signed Within the Identity Document
The trust_score, trust_score_computed_at, and (when present)
trust_score_dimensions fields *MUST* be covered by the issuer
signature on the Agent Identity Document, as specified in
[AGTP-CERT]. Signature binding ensures that:
* A consumer can verify that the trust score was actually issued by
the authority identified in the issuer field.
* A trust score cannot be substituted, edited, or replayed without
invalidating the document signature.
* Trust score and freshness timestamp are bound together; an
attacker cannot present an old trust score with a fresh timestamp
or vice versa.
10.2. Detached Trust Score Documents
A future revision of this specification will define a detached Trust
Score Document format that allows trust scores to be refreshed and
signed independently of the full Identity Document. The detached
form is anticipated to be a small COSE_Sign1 envelope ([RFC9052])
carrying just the trust score, dimensions, freshness timestamp, the
canonical Agent-ID being attested, and the issuer signature.
Detached Trust Score Documents are deferred to a later revision.
Hood Expires 3 May 2027 [Page 23]
Internet-Draft AGTP-TRUST October 2026
10.3. Issuer Key Rotation
When an issuer rotates its signing key, all trust scores signed by
the previous key remain valid until they expire by freshness or until
the previous key is explicitly revoked by the issuer. Consumers
*MUST* continue to accept trust scores signed by the previous key for
the freshness windows specified in the freshness section above.
Issuer key rotation is specified in [AGTP-CERT].
11. Computation Methodology Guidance
11.1. What This Document Leaves to the Issuer
AGTP-TRUST is silent on the specific algorithm an issuer uses to
compute a composite trust score. Computation methodology is
governance-policy and issuer-specific. Two issuers operating under
different governance frameworks may legitimately compute different
scores for the same agent based on the evidence each weights. AGTP-
TRUST specifies the data structure, freshness, and binding properties
of the score; the function from evidence to score belongs to the
issuer.
11.2. Recommendations
The following are non-normative recommendations for issuer
implementations:
*Avoid arbitrary single-dimensional scoring.* A trust score that
collapses to "the agent is still active" is a Boolean dressed as a
scalar. Implementations *SHOULD* incorporate at least three distinct
dimensions before publishing a composite.
*Apply non-linear weighting.* A linear average of dimensional inputs
makes any single dimension proportionally substitutable. In
practice, some dimensions (provenance, attestation) act as gating
conditions: a low score on those dimensions *SHOULD* dominate the
composite even when other dimensions are high.
*Document the methodology publicly.* Issuers *SHOULD* publish a
public description of the computation algorithm, dimension
weightings, and refresh cadence at a known location under their
issuer URL. This enables consumer-side audit and informed trust
delegation.
*Prefer evidence-weighted dimensions over policy-weighted
dimensions.* A trust score that primarily reflects compliance with
the issuer's own policies is reflexive: it tells the consumer whether
the issuer trusts the agent, which is a different question from
Hood Expires 3 May 2027 [Page 24]
Internet-Draft AGTP-TRUST October 2026
whether the agent is behaviorally trustworthy. Implementations
*SHOULD* prioritize dimensions grounded in observable evidence
(attestation, behavioral history, scope-violation frequency) over
policy-conformance dimensions.
12. Consumer Behavior
12.1. Trust Score Evaluation
Consumers evaluating an Identity Document carrying a trust score
*MUST*:
1. Verify the issuer signature on the Identity Document per
[AGTP-CERT].
2. Verify that the trust_score value is on the closed interval [0.0,
1.0].
3. Verify that trust_score_computed_at is present and is within the
consumer's freshness threshold for the operation being
authorized.
4. Verify that the issuer is one the consumer recognizes and accepts
trust scores from. Trust score acceptance *MAY* be restricted to
a list of recognized issuers; trust scores from unrecognized
issuers *SHOULD* be ignored or treated as informational.
If any of these checks fail, the consumer *MUST NOT* use the trust
score for protocol-level authority decisions.
12.2. Decision Mapping
Consumers *MAY* apply trust score thresholds to authority decisions.
The mapping from trust score to authority decision is governance-
policy defined and outside this document. Common patterns include:
* Accepting all method invocations from agents with trust score
above a threshold; escalating to human review below the threshold.
* Reducing the maximum Authority-Scope a consumer is willing to
honor for an agent based on trust score; an agent with a low score
*MAY* be denied scopes the same agent at a higher score would
receive.
* Rejecting DELEGATE with a target_agent_id whose trust score is
below a delegation-acceptance threshold.
Hood Expires 3 May 2027 [Page 25]
Internet-Draft AGTP-TRUST October 2026
These patterns are illustrative. Implementations document their own
mappings.
12.3. Consumption by AGTP-Presence
AGTP-Presence [AGTP-PRESENCE] consumes trust posture from this
document in several distinct ways. AGTP-Presence overlay
coordinators and participating agents *MUST* evaluate trust posture
as specified here when performing the operations described below.
12.3.1. Overlay Admission
Trust-tier-partitioned overlays admit agents based on the agent's
declared and verified trust tier. An overlay coordinator for a Tier
1 Verified overlay *MUST* verify the joining agent's tier assignment
through the verification path declared in the agent's Identity
Document before permitting overlay membership. Agents asserting Tier
1 membership without a verifiable verification path *MUST* be denied
admission.
12.3.2. Visibility Posture as a Trust-Bearing Claim
The visibility posture declared in an agent's AGTP-CERT extension per
[AGTP-PRESENCE] composes with trust tier verification. An agent
declaring presenceMode: tier-scoped in its certificate is asserting
visibility scoped to its trust tier. This assertion is verifiable
through the same mechanisms that verify the trust tier itself.
Consumers evaluating presence claims *MUST* verify that the agent's
visibility posture is consistent with its verified trust tier. An
agent at Tier 3 Experimental claiming visibility in a Tier 1 overlay
is presenting a contradiction and *MUST* be rejected.
12.3.3. Trust Score in Scope Admission
Overlay coordinators *MAY* apply trust score thresholds for admission
to specific scopes. A capability overlay representing a high-value
capability domain may require a minimum trust score for admission.
Agents below the threshold *MAY* be admitted to a less restricted
overlay representing the same capability but *MUST NOT* be admitted
to the threshold-gated overlay.
Hood Expires 3 May 2027 [Page 26]
Internet-Draft AGTP-TRUST October 2026
12.3.4. Cross-Scope Resolution Trust Evaluation
When a cross-scope resolution per [AGTP-PRESENCE] returns an agent
record, the requesting agent *SHOULD* evaluate the returned agent's
trust posture before initiating runtime communication. This is the
standard trust score evaluation specified in this document, applied
to the cross-scope query response.
12.3.5. Presence Operations as Behavioral Evidence
ANNOUNCE, WITHDRAW, and PROBE operations performed by an agent
generate behavioral evidence that *MAY* be incorporated into the
agent's behavioral_history dimension. Excessive churn, malformed
announcements, or abnormal probe patterns are negative behavioral
signals. Consistent, well-formed presence operations are positive
behavioral signals. Trust providers consuming AGTP-LOG behavioral
evidence *SHOULD* include presence operations in their evidence
catalog where available.
13. Security Considerations
13.1. Trust Score Forgery
A forged trust score (one the claimed issuer never issued) is
detected by the issuer signature verification specified in
[AGTP-CERT]. The threat model assumes the consumer correctly
verifies signatures; failure to do so removes the integrity
guarantee.
13.2. Trust Score Replay
A replayed trust score (a real, previously-issued score presented out
of date) is detected by the freshness check on
trust_score_computed_at. The threat model assumes the consumer
applies a freshness threshold appropriate to the operation; failure
to apply a threshold removes the freshness guarantee.
13.3. Issuer Compromise
A compromised issuer can issue any trust score for any agent under
its authority. AGTP-TRUST cannot mitigate issuer compromise at the
protocol layer. Mitigations include: cross-issuer attestation
(consumers accepting trust scores from multiple independent issuers
and weighting accordingly); transparency log inclusion of issued
trust scores per [AGTP-LOG]; and issuer reputation governance
external to AGTP.
Hood Expires 3 May 2027 [Page 27]
Internet-Draft AGTP-TRUST October 2026
13.4. Score Inflation Attacks
An issuer or agent may attempt to inflate trust scores by
manipulating the dimensions that contribute to the composite. The
mitigations are governance-side: dimension definitions *SHOULD* be
grounded in observable evidence, with self-attested properties given
no weight; issuer methodology *SHOULD* be publicly documented and
auditable.
13.5. Out-of-Band Trust Score Channels
Trust scores *MUST NOT* be communicated through channels other than
the Identity Document or future detached Trust Score Documents. An
out-of-band trust score (sent in an HTTP header, an email, a side
channel) has no signature binding to the issuer and *MUST NOT* be
relied upon for authority decisions.
14. IANA Considerations
This document requests no IANA actions in this revision. A future
revision will request:
* Registration of the trust_tier, verification_path, trust_warning,
trust_score, trust_score_computed_at, and trust_score_dimensions
fields in the AGTP Identity Document Field Registry (when that
registry is established by [AGTP]).
* Establishment of the AGTP Trust Tier Registry with initial
registrations for 1 (Verified), 2 (Org-Asserted), and 3
(Experimental).
* Establishment of the AGTP Verification Path Registry with initial
registrations for dns-anchored, log-anchored, hybrid, and org-
asserted.
* Establishment of the AGTP Trust Warning Registry with initial
registrations for verification-incomplete and verification-path-
unsupported.
* Establishment of the AGTP Trust Score Dimension Registry, with
initial registrations for the dimensions defined in Section 9:
provenance, attestation, behavioral_history, peer_reputation,
compliance.
15. Open Items
The following items are explicitly out of scope for this revision and
are anticipated in future revisions:
Hood Expires 3 May 2027 [Page 28]
Internet-Draft AGTP-TRUST October 2026
* Trust-tier upgrade and downgrade procedures (e.g., a Tier 2 agent
completing a delayed Tier 1 verification path).
* Tier 1 verification revocation flow when DNS control lapses or a
transparency log withdraws an entry.
* Detached Trust Score Document format and signature envelope.
* Cross-issuer attestation aggregation protocol.
* Trust Score Update endpoint specification (refresh pattern (b)).
* Federation model for issuers.
* Concrete computation methodology for behavioral_history and
compliance dimensions.
16. Changes from v02
Version 03 is an alignment revision. The tiers, the verification
paths, the trust-posture loading rule, the score range, the freshness
rule, and the dimension catalog are unchanged.
16.1. Substantive Changes in v03
1. *Score without timestamp is treated as absent.* The Identity
Document itself stays valid, since identity and trust posture are
independent functions of the document; the coupling is now
carried into the Identity Document schema by draft-hood-agtp-
identity-document-00, which lists trust_score_computed_at as
REQUIRED whenever trust_score is present. This closes the v09
backlog item on the range and timestamp coupling.
2. *Web3 section replaced* by "Resolution Paths Beyond DNS". The
Web3 bridge draft has expired and is withdrawn for this cycle;
the alias rule of base AGTP covers non-DNS naming systems.
3. *Agent Certificate* described as Level 3 of base AGTP v10, at the
TLS layer.
4. References: base to -10; AGTP-CERT -04, AGTP-LOG -03, AGTP-
IDENTIFIERS -03, AGTP-PRESENCE -01; AGTP-IDDOC added; AGTP-WEB3
and three unused RFC references removed. Hardcoded section
numbers replaced. House style pass.
Hood Expires 3 May 2027 [Page 29]
Internet-Draft AGTP-TRUST October 2026
17. Changes from v01
Version 02 adds the credit-rating-analogous framing and the AGTP-
Presence integration. The trust tiers, verification paths, score
range, freshness, dimensions, signature binding, and consumer-
behavior contracts established in earlier versions are unchanged.
New material is additive.
17.1. Substantive Changes in v02
The following substantive changes were made in v02:
1. *Credit Rating Analogy section added.* A new section (Section 3)
frames AGTP-TRUST in terms of the credit bureau infrastructure
operated by Experian, Equifax, TransUnion, and similar
institutions. The section makes explicit that AGTP-TRUST
provides substrate primitives (verified identifiers, signed
evidence, score format, consumer behavior) and that scoring
algorithms remain proprietary to trust providers, just as FICO
and VantageScore are proprietary in the human credit ecosystem.
The section explicitly invites existing credit bureaus and new
entrants to compose as agent trust providers, operating at the
application layer over HTTP without requiring AGTP substrate
deployment.
2. *AGTP-Presence consumption subsection added.* A new subsection
under Consumer Behavior specifies how AGTP-Presence overlay
coordinators and participating agents consume trust posture for
overlay admission, visibility posture verification, cross-scope
resolution trust evaluation, and incorporation of presence
operations as behavioral evidence.
3. *Introduction updated to four-part structure.* The introduction
now reflects the addition of the Credit Rating Analogy section as
the first organizational part. The Trust Tiers, Registration,
and Trust Score parts retain their roles unchanged.
4. *Informative reference to AGTP-PRESENCE added.* Cross-references
between this document and the AGTP-Presence specification.
17.2. Changes from v00 (Carried Forward from v01)
Version 01 is a drift-cleanup revision. The trust tiers,
verification paths, score range, freshness, dimensions, signature
binding, and consumer-behavior contracts are unchanged.
The following substantive changes were made in v01:
Hood Expires 3 May 2027 [Page 30]
Internet-Draft AGTP-TRUST October 2026
1. *Trust Posture Loading rule added.* A new normative section
(Section 4.6) specifies how a server resolves the trust-posture
fields (trust_tier, verification_path, trust_warning) on the
Agent Identity Document at load time. The rule is three-tier
precedence: explicit operator declaration in the Agent Identity
Document beats Genesis-derived fallback, which beats a
conservative Tier 2 / org-asserted default. The trust_warning
field is auto-populated by the server when the resolved
trust_tier is 2 and the operator set no warning. Operator-set
values are always preserved. The owner_id field follows the same
precedence and is noted alongside, with semantics deferred to
[AGTP-IDENTIFIERS]. This section documents behavior that
v07-conformant implementations have shipped.
2. *Trust posture surfaced on response headers.* A new subsection
(Section 4.6.1) documents the Trust-Tier, Verification-Path, and
Trust-Warning response headers defined in [AGTP] v08. Conforming
servers stamp the resolved trust posture on every response so
relying parties can apply trust-tier-conditional policy without
consulting the Agent Identity Document. This documents behavior
introduced in deployed implementations after the trust-posture
loading rule shipped.
3. *Normative reference to [AGTP] updated to v08.* Informative
references to [AGTP-CERT] and [AGTP-LOG] updated to v01.
Informative reference to [AGTP-IDENTIFIERS] added; the identifier
stack is referenced from the new trust-posture loading section.
4. *Trust Anchor Resolution section added.* A new section
(Section 5.2) specifies two normative patterns for verifiers
determining whether a Genesis-issuer key is trustworthy: local
trust anchors (static list of trusted Genesis-issuer keys) and
OIDC-federated trust anchors (OIDC discovery + JWKS lookup,
letting enterprise deployments bottom Tier 1 trust out in their
existing identity infrastructure). The patterns compose: a
verifier *MAY* maintain a mixed list with both entry types. The
Genesis schema is unchanged; only the resolution path the
verifier uses to decide whether a recorded issuer key is trusted.
Network failures on OIDC discovery or JWKS retrieval *MUST* be
non-fatal: the affected Genesis is treated as unresolvable, which
is a different outcome from a verification failure.
Hood Expires 3 May 2027 [Page 31]
Internet-Draft AGTP-TRUST October 2026
17.3. Wire Format Compatibility
None. The v02 additions are framing (credit rating analogy) and
cross-document integration (presence consumer behavior). No changes
to the wire format of the Agent Identity Document or trust score
representation. Clients that interoperate with v01 continue to
interoperate with v02.
18. Acknowledgments
The trust score scope and structure were developed during the v07
revision of [AGTP], in coordination with the Agent Genesis taxonomy
clarification documented in [AGTP-LOG]. The trust-tier and
verification-path content was extracted from earlier AGTP base draft
revisions (v05 through v07) and consolidated here as the canonical
normative location.
19. References
19.1. Normative References
[AGTP] Hood, C., "Agent Transfer Protocol (AGTP)", Work in
Progress, Internet-Draft, draft-hood-independent-agtp-10,
2026, <https://datatracker.ietf.org/doc/html/draft-hood-
independent-agtp-10>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.
Hood Expires 3 May 2027 [Page 32]
Internet-Draft AGTP-TRUST October 2026
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
19.2. Informative References
[AGTP-CERT]
Hood, C., "AGTP Agent Certificate Extension", Work in
Progress, Internet-Draft, draft-hood-agtp-agent-cert-04,
2026, <https://datatracker.ietf.org/doc/html/draft-hood-
agtp-agent-cert-04>.
[AGTP-IDDOC]
Hood, C., "AGTP Agent Identity Document", Work in
Progress, Internet-Draft, draft-hood-agtp-identity-
document-00, 2026, <https://datatracker.ietf.org/doc/html/
draft-hood-agtp-identity-document-00>.
[AGTP-IDENTIFIERS]
Hood, C., "AGTP Identifier Stack: Identifiers and Per-
Agent Audit Chain", Work in Progress, Internet-Draft,
draft-hood-agtp-identifiers-03, 2026,
<https://datatracker.ietf.org/doc/html/draft-hood-agtp-
identifiers-03>.
[AGTP-LOG] Hood, C., "AGTP Transparency Log Protocol", Work in
Progress, Internet-Draft, draft-hood-agtp-log-03, 2026,
<https://datatracker.ietf.org/doc/html/draft-hood-agtp-
log-03>.
[AGTP-PRESENCE]
Hood, C., "AGTP Presence: Ambient Discovery and Visibility
for Agents", Work in Progress, Internet-Draft, draft-hood-
agtp-presence-01, 2026,
<https://datatracker.ietf.org/doc/html/draft-hood-agtp-
presence-01>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
Author's Address
Chris Hood
Nomotic, Inc.
Hood Expires 3 May 2027 [Page 33]
Internet-Draft AGTP-TRUST October 2026
Email: chris@nomotic.ai
URI: https://nomotic.ai
Hood Expires 3 May 2027 [Page 34]