Skip to main content
#trstdBeta

Trust must be verifiable.

#trstd is the trust infrastructure for People, Brands and AI.

Access to the trust infrastructure is free and remains free. Trust is earned, never bought. Paid plans add advanced services.

One trust infra­structure. People, Brands and AI.

#trstd is the shared trust infrastructure through which People, Brands and AI can verify each other before they interact.

It connects verified identities, trust signals and evidence from real interactions so participants can understand who they are dealing with and make better trust decisions.

Trust cannot be reduced to a badge, a claim or a single score. It develops through what participants can prove and how they behave over time.

01

How #trstd works

Different participants. One trust infrastructure.

People, Brands and AI interact in different ways. #trstd connects them through the same underlying trust infrastructure.

People can verify that a website really belongs to the Brand behind it and see trust information backed by #trstd.

Brands can prove who they are and make relevant trust signals available to People and AI, while deciding how verified AI agents may interact with their services.

AI agents can prove who they are, who operates them and what they are authorised to do, while verifying the Brands and services on the other side.

Different participants. Different interactions. The same principle:

Check and be checked.

People verify Brands. AI agents verify Brands. Brands verify AI agents. Trust works in both directions.

PeopleVerifies and is verified
BrandsVerifies and is verified
AIVerifies and is verified
#trstd — the shared trust infrastructure underneath
Mutual verification between three equal participants. #trstd is the infrastructure underneath, not a fourth participant.

Identity establishes who is acting. Behaviour shows what happens next. Reputation reflects the track record over time.

Trust starts with identity.

A verified identity creates accountability, but identity alone does not make someone trustworthy. Real interactions create evidence about what happens next.

Were permissions respected? Were commitments kept? Was a transaction completed correctly? Was data protected? Did the outcome match what was expected? What happened when something went wrong?

Repeated interactions build a track record. Good behaviour strengthens Reputation over time. Serious violations can damage trust quickly.

  1. 1IdentityKnow who or what is behind an interaction.
  2. 2BehaviourSee what actually happens when participants interact.
  3. 3ReputationUnderstand the track record that behaviour has created over time.

Trust works both ways.

A trustworthy interaction cannot depend on only one side being verifiable.

A person can check whether a website really belongs to the Brand behind it.

A Brand can identify an AI agent, its operator and relevant authority before deciding what that agent may do.

An AI agent can verify the Brand or service before sharing data, recommending it or taking action.

Each side brings evidence. Each side can verify the other. And every relevant interaction can create new evidence for what happens next.

02

Evidence & Trust Graph

Trust needs evidence.

Not every signal carries the same weight.

A verified identity tells you who is behind an interaction. A genuine transaction can prove that a Review is based on a real experience. A signed interaction can show whether an AI agent respected a Brand’s policy. A purchase, refund, dispute or successful remediation can provide evidence about what actually happened.

#trstd connects relevant evidence to the participant and interaction it belongs to.

Its provenance matters. So do recency, diversity, relevance and the outcome itself. Evidence backed by real, verifiable interactions is stronger than self-declared claims or unverified ratings.

One side proves what it did. The other proves what happened.

An agent can sign its request. The receiving service can provide signed evidence about the action it observed and the resulting outcome. #trstd can connect both sides of the interaction and turn them into verifiable behavioural evidence.

Agent / participantSigned action
CounterpartyVerified outcome
One interaction record in #trstd

Both sides connect to the same interaction and become verifiable behavioural evidence.

One interaction, two independently signed perspectives.

Trust needs memory.

A single participant usually sees only one part of someone’s history.

#trstd connects verified relationships and outcomes across the ecosystem so relevant evidence from one interaction can help inform the next.

The Trust Graph connects participants and the evidence around them: People, Brands, AI agents, Operators, credentials, mandates, policies, interactions, transactions, incidents and outcomes.

It is not a public social graph. Raw personal and commercial data does not need to become part of a public pool. What matters is the verified relationship, status, evidence and reason needed for a trust decision.

This becomes particularly valuable across organisations. An individual provider sees only its own interactions. #trstd can connect standardised, verifiable evidence from independent participants across the ecosystem.

takes part inholdsholdsoperated byacts inparty toproducesevidence aboutPersonBrandAI agentOperatorCredentialInteractionOutcome
Verified relationships between participants, credentials, interactions and outcomes.

Trusted for what? And under which conditions?

Trust is not universal.

An AI agent may have a strong track record for search and comparison but still be unproven for autonomous payments. A Brand may have different evidence for identity, certification, Reviews, service quality or protection.

#trstd therefore does not reduce trust to one universal score. The relevant identity, authority, behaviour, outcomes and strength of the available evidence depend on the interaction that is actually taking place.

Allow
Allow with limits
Challenge
Restrict
Block
More accessLess access
The receiving Brand or service remains in control and defines the policy under which it interacts.
03

Trust Authority & Governance

Evidence needs an accountable authority behind it.

Trust signals become useful when their origin, status and connection to a real participant can be verified.

A Trust Authority verifies facts, issues credentials, validates evidence and maintains the status needed for others to rely on it.

Within #trstd, this can include verifying Brands, Operators and AI agents, binding organisations to domains and credentials, validating evidence from trusted sources and maintaining current trust information as new evidence appears.

Independent evidence providers can contribute specialised signals such as KYB, security, payment, fraud, audit or dispute evidence. For that evidence to become useful, its issuer, subject, provenance, validity and status must remain verifiable.

The architecture is designed to support #trstd or another recognised party as a Trust Authority.

Independent evidence providers
KYBSecurityPaymentFraudAuditDispute
#trstd Trust Authority
Verifies facts, issues credentials, validates evidence, maintains status
Ecosystem participants
PeopleBrandsAI agentsOperators
#trstd does not own every source of evidence. It verifies, validates and maintains the status others rely on.

Trust must remain challengeable.

Trust changes when new evidence appears.

A new participant may simply not have enough history yet. A previously trustworthy participant can become risky after a serious incident. Evidence can also be disputed or turn out to be wrong.

That is why #trstd distinguishes between Trust Level, Evidence Confidence and Current Risk State rather than treating trust as one permanent number.

Credentials and status can be restricted, suspended or revoked when necessary. Incidents can be investigated. Incorrect evidence can be corrected. Remediation can rebuild trust progressively once problems have genuinely been resolved.

Trust is earned gradually. It can be lost quickly.

Active
Under review
Restricted
Suspended
Revoked
Remediation: once problems have genuinely been resolved, trust can be rebuilt progressively over time.
04

Standards, Security & Privacy

Use what already works. Add what trust still needs.

#trstd follows a standards-first approach.

Existing standards already solve important parts of authentication, identity, credentials, authorisation and agent communication. #trstd builds on them instead of creating proprietary replacements.

These foundations help establish who acted, how an interaction was authenticated and what was exchanged.

#trstd adds what makes that information useful for trust over time: verified behavioural evidence, outcomes and Reputation.

For agentic interactions, TSAI can carry relevant trust and policy context while #trstd provides the dynamic trust intelligence and Trust Authority behind it.

Request authentication
Web Bot Auth and RFC 9421 make automated requests cryptographically attributable.
Identity & credentials
DID and W3C Verifiable Credentials provide foundations for persistent identity and verifiable assertions.
Agent & tool interaction
A2A and MCP provide standards for communication between agents and their interaction with tools and data.

Share the proof. Not the dossier.

Verifiable trust should not require participants to expose everything they know.

Personal and commercially sensitive information can remain with its source. Pseudonymous identifiers, verified assertions, evidence categories, status and cryptographic proof can provide what another participant needs for an interaction.

For example, #trstd may need to know that an agent accessed payment_data or address_data without receiving the actual payment details or address.

Disclose what is necessary. Keep control of the rest.

Identity and behavioural information can remain separated where appropriate, supported by selective disclosure, access controls, revocation and auditable evidence handling.

Raw data stays at its source
Payment detailsAddress dataCommercial terms
Proof and status are shared
Pseudonymous identifierVerified assertionEvidence categoryStatusCryptographic proof
05

The infrastructure in motion

Every verified interaction can make the next decision better informed.

#trstd is not a static registry. The infrastructure learns from what happens across the ecosystem.

This network effect is fundamental to #trstd: more participants create more interactions and Data Trails, strengthening the Trust Graph and making future trust assessments more useful.

  1. Verified participants
    establish accountability.
  2. Real interactions
    connect identifiable counterparties.
  3. Evidence & outcomes
    show what actually happened.
  4. Trust Graph
    connects evidence across interactions.
  5. Reputation & current status
    reflect what has been learned over time.
  6. Better trust decisions
    help participants decide how to interact.
  7. More trusted interactions
    create new evidence.
    back to Evidence & outcomes — the cycle continues.

Questions about the #trstd ecosystem?

A shared trust infrastructure for People, Brands and AI. It makes identity, behaviour and reputation verifiable, so all three can recognise each other and act on evidence rather than appearance.
It is not a checkout system, not a universal social score, not blind acceptance, and not a public data pool.
It verifies evidence, signs it, issues credentials, observes outcomes, maintains a current Trust Level and answers verification requests in real time. Trusted Shops acts as the Trust Authority.
Three things are kept separate: the Trust Level (demonstrated trustworthiness), evidence confidence (how much reliable evidence exists) and the current risk state (active warnings or incidents). Every decision returns machine-readable reason codes, never an unexplained number.
Web Bot Auth and HTTP Message Signatures for request authentication, DIDs and HTTPS identifiers for agent identity, W3C Verifiable Credentials 2.0 for credentials, OAuth/OIDC and TSAI for authorisation, A2A and MCP for communication. #trstd adds the behavioural evidence and reputation layer on top.
No. The evidence log is append-only and tamper-evident, but no public blockchain is required.