This specification defines a trust model for AI agents built on W3C Verifiable Credentials [[VC-DATA-MODEL]]. It has two parts: a deterministic trust-scoring function that maps observable evidence about an agent to a bounded score and a discrete trust level, and an ATP Trust Credential — a verifiable credential through which an issuer attests an agent's trust level to a relying party. It also profiles a policy-assertion decision model that consumes a verified trust level to make allow/deny decisions.

The model is fail-closed: unverifiable evidence never raises an agent's trust. A credential contributes to trust only after it is cryptographically verified; absent a verifier, candidate credentials are credited zero.

Agent identity and key material are defined by the did:atp DID Method. Privacy-preserving disclosure of credential attributes is defined by ATP Privacy-First Interaction. Interoperability vectors are defined by ATP Conformance & Interoperability.

This document is an early draft work product of the Agent Trust Protocol (ATP) Community Group. It is not a W3C Standard nor on the W3C Recommendation track. It is published to seek review, comment, and contribution from Community Group members; the normative thresholds, factor weights, and credential shape below are provisional and expected to change in response to that review.

The ATP Community Group coordinates with the W3C AI Agent Protocol Community Group [[AI-AGENT-PROTOCOL]]. The scoring weights given here are seeded from a running reference implementation and its conformance vectors; they are presented as a starting point for discussion, not as a finalized normative scale.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else is normative.

The key words MUST, MUST NOT, SHOULD, and MAY are to be interpreted as described in BCP 14 [[RFC2119]] [[RFC8174]] when, and only when, they appear in all capitals.

Trust Levels

A conforming trust-scoring engine MUST compute a score s ∈ [0, 1] and map it to exactly one trust level using the following bands:

Score bandLevel
s ≥ 0.9PRIVILEGED
0.7 ≤ s < 0.9TRUSTED
0.4 ≤ s < 0.7VERIFIED
0.2 ≤ s < 0.4BASIC
s < 0.2UNKNOWN

The band boundaries are seeded from the reference implementation. CG members are invited to challenge the five-level scheme and the exact cut-points (e.g. whether PRIVILEGED should require attested credentials in addition to a high score).

Trust-Scoring Function

The scoring function takes evidence about an agent and returns a score in [0, 1]. A conforming implementation MUST satisfy the following properties (each is exercised by the conformance suite):

Determinism
Identical evidence MUST yield an identical score and level.
Bounds
The score MUST lie in [0, 1] and the level MUST be one of the values in Trust Levels.
Monotonicity (at a fixed point in time)
Evaluated against a fixed evidence set at a fixed instant, additional successful interactions, endorsements, or verified credentials MUST NOT lower the score; additional failed interactions or violations MUST NOT raise it. Monotonicity is scoped within a factor and does not extend across time: because evidence decays (Recency Decay), an unchanged evidence set MAY yield a lower score when re-evaluated later. Raw count alone MUST NOT move a score across a band boundary.
Fail-closed credential gating
A candidate credential MUST contribute to the score only after it is verified. With no verifier available, candidate credentials MUST be credited zero.

The reference evidence factors are: identity verification, the count of verified credentials, the success/failure ratio of recorded interactions, and net reputation (endorsements minus violations, each term capped).

Counting evidence without regard to its age, its independence, or the conditions under which it was earned makes a score a measure of volume rather than of trustworthiness: an agent that accumulates many cheap, low-risk, successful interactions — or endorsements from colluding peers — would otherwise reach the highest bands. The three requirements below constrain that. Their parameters are seeded starting values, not derived optima, and are adjustable by the Community Group.

Recency Decay

Evidence MUST lose weight as it ages. A conforming implementation MUST apply exponential decay to interaction and endorsement evidence with a default half-life of 90 days: evidence 90 days old contributes half its original weight, and evidence approaching one year contributes near zero. Identity verification and the verified-credential count are not subject to decay; they are re-evaluated against credential expiry and status instead (Issuer Authorization).

The half-life is a profile parameter. An implementation MAY use a different value and MUST state the value it uses when making a conformance claim.

Confidence and Evidence Sufficiency

A trust level MUST be accompanied by a confidence signal reflecting the quantity and quality of the evidence behind it, so that a level derived from a handful of interactions is distinguishable from the same level derived from a large, diverse, recent body of evidence. A score computed from insufficient evidence MUST NOT be presented as equivalent to the same score computed from sufficient evidence.

Confidence is reported alongside the level; it does not itself raise the level. This specification does not fix a numeric confidence scale.

Endorser Independence

Endorsement evidence MUST be weighted by the independence of the endorsers rather than by their raw count. Endorsers that share a funding source, or that are connected by a mutual-endorsement edge, MUST collapse to a single effective endorser. An endorsement set MUST NOT move a trust level across a band boundary unless it contains at least three effective independent endorsers.

The threshold is a profile parameter, adjustable as above. See Security & Privacy Considerations for the limits of independence detection on an open graph. 

{
  "identityVerified": true,
  "credentials": ["a", "b", "c", "d"],   // verified
  "successful": 500, "failed": 0,        // one action type, one counterparty
  "endorsements": 20, "violations": 0    // one funding source, mutual edges
}
// → NOT a privileged/trusted band.
//
// The 20 endorsements collapse to 1 effective endorser (< 3 required), so they
// move no band. The 500 same-type, low-risk interactions against a single
// counterparty raise confidence for that one narrow capability, but raw count
// alone moves no band. The residual level rests on identity plus the four
// verified credentials — no higher than VERIFIED.
//
// See the anti-gaming conformance vectors (Fixtures A and B) in
// ATP Conformance & Interoperability.

Earlier drafts of this specification annotated this same fixture as reaching the PRIVILEGED/TRUSTED band. That outcome is the volume-farming result the requirements above exist to prevent, and the annotation is corrected here.

The ATP Trust Credential

An ATP Trust Credential is a Verifiable Credential [[VC-DATA-MODEL]] through which an issuer attests an agent's trust level. Its type MUST include both VerifiableCredential and AtpTrustCredential. The credentialSubject MUST identify the agent (id) and MUST carry a trustLevel; it MAY carry a trustScore and an evaluatedAt timestamp. The credential MUST carry an expirationDate. 

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiableCredential", "AtpTrustCredential"],
  "issuer": "did:atp:authority.example.com:e1_...:pq1_...",
  "validFrom": "2026-06-26T00:00:00Z",
  "expirationDate": "2026-09-26T00:00:00Z",
  "credentialSubject": {
    "id": "did:atp:agents.example.com:...",
    "trustLevel": "TRUSTED",
    "trustScore": 0.78,
    "evaluatedAt": "2026-06-26T00:00:00Z"
  }
}

A relying party that receives a presented ATP Trust Credential MUST cryptographically verify it (signature, expiry, revocation, schema) and MUST confirm that its issuer is authorized to issue credentials of this type (Issuer Authorization), before mapping its trustLevel into a policy decision. Both checks MUST succeed. A valid presented credential lets a relying party gate on attested trust without querying the issuer's scoring engine directly.

An ATP Trust Credential MUST carry a credentialStatus property using BitstringStatusList [[VC-BSL]] as the normative default status mechanism. This reuses the credentialStatus extension point already defined by the VCDM v2.0 data model [[VC-DATA-MODEL]] in which the credential is expressed, requiring no additional @context, serialization, or proof model.

Because a trust level is time-decaying evidence rather than a permanent fact, a credential needs to be both permanently withdrawable and temporarily withheld. credentialStatus MUST therefore be an array containing:

Each entry MUST conform to BitstringStatusListEntry and MUST carry statusListIndex and statusListCredential.

A relying party verifying a presented ATP Trust Credential MUST resolve and check both status list entries as part of the verification requirement above (signature, expiry, revocation, schema):

This design intentionally avoids per-credential status endpoints (OCSP-style checks): because many credentials share one status list and a relying party inspects it locally, the issuer does not learn which credential, agent, or relying party is being checked. This is consistent with this specification's privacy-first presentation posture (ATP Privacy-First Interaction).

Issuer Authorization

Cryptographic verification of an ATP Trust Credential (The ATP Trust Credential) establishes only that the credential was signed by the key bound to its issuer and has not been altered in transit. It says nothing about authorization: whether the signing entity is recognized as authorized to issue credentials of type AtpTrustCredential within the ecosystem the relying party cares about. A syntactically valid, correctly signed, unexpired credential from an unrecognized or unauthorized issuer MUST NOT raise an agent's trust.

A conforming relying party therefore composes two independent checks before mapping a presented trustLevel into a policy decision (Policy-Assertion Decision Model):

Credential verification (local)
The relying party MUST verify the credential's signature, expiry, revocation status, and schema, as required by The ATP Trust Credential. This answers "was this credential really issued by the entity named in issuer, and is it intact?"
Issuer authorization (external)
The relying party MUST confirm, against an authority it trusts, that the issuer is authorized to issue this credential type. This answers "is that issuer permitted to make this kind of attestation in my ecosystem?"

Both checks MUST succeed. Consistent with the fail-closed property (Trust-Scoring Function), a credential whose issuer authorization cannot be positively confirmed MUST be credited zero and its trustLevel treated as UNKNOWN — a failed or indeterminate authorization check is handled identically to an unverifiable signature.

Authorization via TRQP

This specification defines a binding to the ToIP Trust Registry Query Protocol (TRQP) [[TRQP]] for the issuer-authorization check. TRQP moves the trust question up one level: the relying party is not asked to trust the issuer directly, but to trust a governing authority that — under a published governance framework — attests that the issuer may issue a given credential type. The relying party thus anchors on the authority and the framework it publishes, not on a per-issuer allow-list.

To perform the check, the relying party constructs a TRQP authorization query in which: 

POST /authorization
Content-Type: application/json

{
  "entity_id":    "did:atp:authority.example.com:e1_...:pq1_...",
  "authority_id": "did:example:ecosystem-governing-authority",
  "action":       "issue",
  "resource":     "AtpTrustCredential",
  "context":      { "time": "2026-06-26T00:00:00Z" }
}

A response with "authorized": true satisfies the issuer-authorization check for that credential. Any other outcome — false, an RFC 7807 error, a timeout, or an unreachable endpoint — MUST be treated as failure and handled fail-closed. 

HTTP/1.1 200 OK
Content-Type: application/json

{
  "entity_id":     "did:atp:authority.example.com:e1_...:pq1_...",
  "authority_id":  "did:example:ecosystem-governing-authority",
  "action":        "issue",
  "resource":      "AtpTrustCredential",
  "authorized":    true,
  "time_requested":"2026-06-26T00:00:00Z",
  "time_evaluated":"2026-07-13T09:15:00Z"
}

Governance is out of scope

This subsection is non-normative.

This specification deliberately does not legislate governance. It specifies how a relying party queries a governing authority, and leaves the identity, operation, and selection of that authority to each deployment — enterprise, consortium, or open web. ATP defines no root authority and endorses no registry operator. Naming this as an explicit non-goal is preferred to leaving the gap implicit.

Cross-ecosystem recognition

This subsection is non-normative.

Where the issuer is governed by a different ecosystem than the one the relying party's authority governs, the relying party MAY first issue a TRQP recognition query to confirm that its own authority recognizes the issuer's governing authority as a peer for issuing AtpTrustCredential, then evaluate the authorization query against that recognized authority. This lets a verified trust level cross ecosystem boundaries without collapsing every issuer into a single global trust root.

Recognition across governance frameworks is a hard problem and normalizing it prematurely would compromise this deliverable. It remains non-normative in this version and is expected to be revisited.

The binding above reuses the reference action / resource pair issue / AtpTrustCredential. CG members are invited to consider: whether resource should be more granular (e.g. scoped per trust level or per credential profile); whether authorization SHOULD be re-checked at presentation time in addition to issuance time for long-lived credentials; whether the authorization result should itself be cached and, if so, with what freshness bound; and whether a failed authorization check should map to UNKNOWN or to an explicit distrust signal distinct from the mere absence of evidence.

Binding to [[TRQP]] makes conformance to this section depend on a specification maintained by another organization (the Trust Over IP Foundation). The Community Group adopted this trade-off deliberately: reusing an established open standard is preferred to inventing an ATP-native registry protocol. A liaison contact for TRQP would help keep the binding current.

Policy-Assertion Decision Model

This section profiles how a verified trust level drives an authorization decision. A policy evaluator takes an evaluation context and returns an allow or deny decision, optionally with obligations.

The evaluation context carries at least:

{
  "agentDID": "did:atp:agent-1",
  "trustLevel": "VERIFIED",          // from a verified Trust Credential or engine
  "credentials": [ /* VerifiableCredentialInfo[] */ ],
  "tool": { "id": "database_query", "type": "database", "sensitivity": "internal" },
  "requestedAction": "read",
  "organizationId": "org_test",
  "timestamp": "2026-06-19T12:00:00.000Z"
}

A conforming policy evaluator MUST:

The reference engine uses a constrained visual-policy condition schema and a safe-expression sandbox. Whether to standardize that condition language, or reference an existing policy language, is open for CG discussion.

Conformance Vectors

Conforming implementations are validated against deterministic vectors covering determinism, bounds, monotonicity, level thresholds, and fail-closed credential gating, plus policy allow/deny, deny-by-default, and obligation handling. These vectors are maintained alongside the ATP Conformance & Interoperability suite. CG members may contribute additional vectors as table rows.

Security & Privacy Considerations

Because trust drives authorization, the fail-closed property is security-critical: an implementation MUST NOT credit a credential it cannot verify. Trust Credentials disclose an agent's standing; relying parties SHOULD prefer privacy-preserving presentation (selective disclosure) where the full credential is not required.

Manipulability of the score is as consequential an attack surface as credential-verification integrity. The requirements in Trust-Scoring Function — recency decay, confidence reporting, and endorser independence — exist to prevent a score from being driven by interaction volume alone.

Limits of Sybil resistance on an open graph

Endorser Independence raises the cost of endorsement farming but does not eliminate it. The collapse rule detects shared funding sources and mutual-endorsement edges; it does not detect a well-resourced adversary who creates endorsers that are genuinely independent by those measures. On a fully open graph, with no admission control on who may endorse, Sybil resistance cannot be complete — this is a property of the setting, not a defect of the rule.

Deployments requiring stronger guarantees SHOULD constrain who may endorse. Issuer Authorization provides the hook: where endorsements are carried as credentials from authorized issuers, the governing authority's admission criteria bound the adversary's ability to manufacture independent-looking endorsers. The residual exposure therefore narrows as issuer authorization is adopted, and is widest in fully open, unauthorized-endorser deployments.

Implementations MUST NOT present a trust level as Sybil-resistant on the strength of the independence threshold alone.

Contributor disclosure

This subsection is non-normative.

The anti-gaming conformance vectors contributed to this work map their authority-frame layer onto draft-kroehl-agentic-trust-aae-00, an IETF draft authored by the same contributor (Lars Kroehl, MolTrust / CryptoKRI GmbH). The Community Group records this on the record, as it does ATP's own commercial backing (Sovr Inc.). Contributors building on their own prior work is expected and is not an obstacle; the vectors themselves are implementation-neutral and assert bands, per-capability confidence, and invariants rather than a scoring formula tied to any one specification.

Acknowledgments

The following Community Group participants contributed substantive text or analysis incorporated into this specification. Contributions were made in the Community Group's public issue tracker under the W3C Community Contributor License Agreement.

The layer mapping accompanying the anti-gaming conformance vectors references draft-kroehl-agentic-trust-aae-00, an IETF Internet-Draft authored by the same contributor, whose work is commercially backed (MolTrust / CryptoKRI GmbH). This is recorded for transparency, in the same spirit as this specification's own commercial backing, and is not regarded as an impediment to the contribution.