Skip to main content

Validation Scenarios — Planned Mechanics

This file holds the planned-only scenarios extracted from concept/validation-scenarios.md. They exercise the planned /.well-known/trstd.json manifest and entity matching, which are tracked on the roadmap but not in the current spec.

Scenario A: MCP Service Integration​

Context: An enterprise agent needs to connect to a data enrichment MCP service at https://enrich.example.org. The agent platform requires verified identity and compliance before allowing MCP connections. This scenario uses the planned manifest because the API-only service has no HTML pages and cannot use the link tag.

Flow​

1. Discovery

The MCP service has no HTML pages. The agent requests https://enrich.example.org/.well-known/trstd.json:

{
  "$schema": "https://cdn.example.org/schemas/trstd-protocol/v1/manifest.json",
  "@context": "https://cdn.example.org/schemas/trstd-protocol/v1",
  "@type": "VerificationProvider",
  "version": "1.0.0",
  "name": "Trusted Shops SE",
  "entities": [
    {
      "entityId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "host": "enrich.example.org",
      "pathPrefixes": ["/"]
    }
  ],
  "capabilities": [
    {
      "id": "verify",
      "type": "VerifyEndpoint",
      "endpoint": "https://trust-authority.example.org/v1/entities/{entityId}/trust-signals",
      "method": "GET",
      "description": "Retrieve trust signals for an entity"
    }
  ]
}

2. Verification

GET /v1/entities/a1b2c3d4-e5f6-7890-abcd-ef1234567890/trust-signals?url=https%3A%2F%2Fenrich.example.org HTTP/1.1
Host: trust-authority.example.org
Authorization: Bearer eyJhbGciOiJFZERTQSJ9...
Accept: application/json

3. Response

{
  "meta": {
    "responseId": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
    "entityId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "status": "verified",
    "url": "https://enrich.example.org/",
    "timestamp": "2026-03-21T09:00:00Z",
    "expires": "2026-03-22T00:00:00Z"
  },
  "signals": [
    {
      "type": "identity",
      "verifiedAt": "2025-12-01T00:00:00Z",
      "data": {
        "legalName": "DataEnrich Ltd",
        "country": "GB",
        "registrationNumber": "12345678"
      }
    },
    {
      "type": "compliance",
      "verifiedAt": "2026-01-15T00:00:00Z",
      "data": {
        "certifications": ["SOC 2 Type II", "GDPR"],
        "lastAudit": "2026-01-15",
        "auditor": "Deloitte"
      }
    },
    {
      "type": "contact",
      "verifiedAt": "2025-12-01T00:00:00Z",
      "data": {
        "emailVerified": true,
        "phoneVerified": true,
        "addressVerified": true
      }
    }
  ],
  "kid": "authority-key-1",
  "signature": "pV2qFz8kRn0LhVbUqSSR3IyzQlDu5XbE0MwvMXfBjlNRqIjmGT6c2Eq..."
}

4. Agent Decision

The agent platform checks its policy: MCP connections require identity with high confidence and at least one compliance certification. Both conditions are met. The agent connects to the MCP service.

What This Tests​

  • API-only service with no HTML — manifest required, link tag is not applicable
  • Single-entity manifest for a simple service
  • Not all signal types are present (no reputation, no recourse) — this is valid
  • Enterprise agent platform enforces a policy on top of raw signals

Scenario B: Marketplace Seller Verification​

Context: A marketplace hosts multiple sellers. A consumer agent wants to verify a specific seller within the marketplace at https://market.example.org. This scenario uses the planned manifest with multi-entity matching. With link tags alone, the marketplace would use per-page link tags with the seller-specific entityId pre-computed at render time.

Flow​

1. Discovery

The agent requests https://market.example.org/.well-known/trstd.json:

{
  "$schema": "https://cdn.example.org/schemas/trstd-protocol/v1/manifest.json",
  "@context": "https://cdn.example.org/schemas/trstd-protocol/v1",
  "@type": "VerificationProvider",
  "version": "1.0.0",
  "name": "Trusted Shops SE",
  "entities": [
    {
      "entityId": "mkt-00000001-0000-0000-0000-000000000001",
      "host": "market.example.org",
      "pathPrefixes": ["/"]
    },
    {
      "entityId": "mkt-00000001-0000-0000-0000-000000000abc",
      "host": "market.example.org",
      "pathPrefixes": ["/sellers/seller-abc"]
    }
  ],
  "capabilities": [
    {
      "id": "verify",
      "type": "VerifyEndpoint",
      "endpoint": "https://trust-authority.example.org/v1/entities/{entityId}/trust-signals",
      "method": "GET",
      "description": "Retrieve trust signals for an entity"
    }
  ]
}

2. Entity Matching

The agent is on https://market.example.org/sellers/seller-abc/products/widget. It matches:

  • Entity 1: prefix / matches (length 1)
  • Entity 2: prefix /sellers/seller-abc matches (length 20)
  • Longest prefix wins: the seller-specific entity

3. Verification

The agent queries for the seller entity. The response contains the seller's identity and signals — distinct from the marketplace's signals.

4. Agent Decision

The agent evaluates the seller's trust signals. A dedicated entity for the seller provides stronger assurance than relying on the marketplace's top-level entity alone.

What This Tests​

  • Multi-level trust: marketplace + seller via different entities in the same manifest
  • Path prefix matching scopes entities to sub-sections of a site
  • Agent selects the most specific entity for the URL it is visiting

Scenario C: Entity Mismatch Recovery (manifest path)​

When the verify endpoint returns 400 entityMismatch and the agent has used a manifest, the agent re-examines the manifest and retries with a different entity that covers the URL (typically a less-specific prefix). With link tags alone, entityMismatch is a discovery failure with no self-recovery — see Scenario 5 in the main validation scenarios.