ATAP v0.1 — Agent Trust Attestation Protocol

1. Abstract

ATAP is an open protocol for agent behavioral attestation: a canonical receipt format that lets the principal of an agentic system — the advertiser, the compliance officer, the regulator, the auditor — cryptographically verify what an agent actually did, in chronological order, without trusting the agent's self-report. v0.1 specifies five artifacts: the AIT capability declaration, the Witness Event record, the Attestation Block roll-up, the Receipt ZIP compliance export, and the hash-chain plus Ed25519 signature model that binds them together. ATAP is invoked from inside the agent (or a trusted dependency such as an MCP server, a verification API, or a language-model SDK wrapper) via a single witness(event) call. The witness service is the trusted intermediary that signs and chains every artifact — the AIT itself, every Witness Event, every Attestation Block, every Receipt. There is no kernel observer in v0.1 and none is required. The receipt format is designed so that stronger observation tiers — sidecar daemons, TEEs, kernel attestation — can be introduced in later versions without invalidating earlier receipts or breaking the reference verifier. The format is the moat.

2. Object identifiers

ATAP defines four canonical object types and one external reference type. Each has a fixed identifier form.

2.1 Why uuidv7

uuidv7 (RFC 9562) encodes a Unix-epoch millisecond prefix, giving natural time-ordering and database-friendly insertion locality. Agent instances, events, blocks, and receipts are short-lived high-cardinality objects unsuitable for a per-year sequence like OAI: a single media-buying agent emits thousands of events per second, and any registry-issued sequence would become the system bottleneck. uuidv7 is the only identifier scheme in v0.1; v2 MAY introduce others.

2.2 Formal grammar (ABNF, RFC 5234)

ait        = "AIT-" uuidv7
atap-we    = "ATAP-WE-" uuidv7
atap-ab    = "ATAP-AB-" uuidv7
atap-rcpt  = "ATAP-RCPT-" uuidv7
uuidv7     = 8HEXDIG "-" 4HEXDIG "-" "7" 3HEXDIG "-" 4HEXDIG "-" 12HEXDIG
HEXDIG     = DIGIT / %x61-66       ; 0-9 lowercase a-f
DIGIT      = %x30-39

The literal 7 in the third group enforces uuidv7 at parse time; uuidv4 and other versions MUST be rejected.

2.3 Bounds

2.4 Witness service identifier

A witness service — the surface that signs and chains all ATAP artifacts on behalf of a principal — is identified by canonical OAI under the witness.operator category, added to OAI v1.0 §3 as an editorial expansion on 2026-05-14 alongside the publication of this standard. The AIT field witness, the public-key lookup at /atap/keys, and the Receipt witness field all reference this OAI.

2.5 Anti-collision

A witness service MUST reject any AIT whose id it has previously signed under any other AIT. uuidv7's 74 bits of post-timestamp entropy make accidental collisions vanishingly improbable; rejection of seen IDs guards against deliberate impersonation by an adversary that scrapes published AITs and replays them under a different operator.

3. Scope

ATAP v0.1 specifies a protocol and a receipt format for the following:

Application-specific extensions (the witness vocabulary for media buying, e-commerce, data brokerage, etc.) are out of scope for the base protocol and live in application profiles (Section 9). The base protocol provides the structural envelope; the profile fills it with domain-specific event types and aggregation rules.

4. Out of scope

The following are deliberate non-goals in v0.1. Each exclusion is load-bearing; do not work around them.

5. Stability guarantees

A receipt issued under v0.1 remains independently verifiable indefinitely. The standard never invalidates an existing receipt.

6. Lifecycle

An ATAP-instrumented agent traverses six states:

stateDiagram-v2
  [*] --> declared : operator submits AIT to witness
  declared --> witnessing : first witness(event) call accepted
  witnessing --> witnessing : subsequent events
  witnessing --> rolled_up : block_interval elapsed OR explicit flush
  rolled_up --> witnessing : agent continues
  rolled_up --> receipted : receipt(period) requested
  receipted --> [*] : AIT retired

witnessing → rolled_up is the only periodic transition; all others are event-triggered.

6.1 AIT acceptance

The operator constructs an AIT object with all fields populated except witness_signature. The operator submits the AIT to the witness service. The witness validates: schema conformance, profile registration, that the AIT's id has not been seen before, that the witness field matches its own canonical OAI, and that the operator's identity satisfies the witness's onboarding policy (out of scope for v0.1). On success the witness signs the canonical bytes of the AIT minus witness_signature and returns the signed AIT.

A signed AIT is the agent's credential. Subsequent witness(event) calls reference it by id.

6.2 Block roll-up triggers

A witness service MUST roll up pending events into a new Attestation Block when ANY of:

1. The block interval declared in the AIT's attestation_policy.block_interval_seconds elapses since the previous block.
2. The pending event count exceeds the witness service's configured ceiling (default 10,000; configurable per profile).
3. The agent's principal requests a flush via POST /v1/atap/flush.
4. The witness service is about to shut down or rotate keys.

Witness services MAY roll up more frequently than the declared interval. They MUST NOT roll up less frequently.

6.3 AIT lifetime

An AIT SHOULD have a useful lifetime no longer than 90 days. An AIT MUST be retired no later than 365 days after issued_at. Long-lived AITs accumulate key-rotation, profile-version, and policy-drift risk. Profiles MAY specify tighter ceilings; profiles MUST NOT relax the 365-day cap.

The witness service MUST refuse witness(event) for an AIT older than its profile's maximum lifetime or older than 365 days, whichever is shorter, even if no retirement event has been recorded.

7. Schemas

All four object types are JSON. The on-the-wire encoding is JSON-LD where context is required for downstream tooling; the canonical form for hashing is RFC 8785 (JSON Canonicalization Scheme).

7.1 AIT (Agent Identity Token)

{
  "@context": "https://tunnelmind.ai/atap/context.jsonld",
  "@type": "AgentIdentityToken",
  "id": "AIT-018f3c4d-7b2a-7d8e-9f01-4a5b6c7d8e9f",
  "ait_version": "0.1",
  "issued_at": "2026-05-14T08:00:00Z",
  "expires_at": "2026-08-12T08:00:00Z",
  "agent_type": "media-buyer",
  "profile": "sigil:media_buyer:v1",
  "operator": "OAI-2026-0000234",
  "witness": "OAI-2026-0000017",
  "capabilities": [
    "bid:submit",
    "bid:read_response",
    "supply:verify_via_sigil",
    "budget:read",
    "budget:decrement",
    "creative:select",
    "report:generate",
    "report:export_receipt"
  ],
  "constraints": {
    "max_bid_cpm": 50.00,
    "currency": "USD",
    "allowed_channels": ["display", "video", "ctv", "audio"],
    "blocked_domains": ["example-blocked.com"],
    "blocked_categories": ["IAB25-3", "IAB26"],
    "geo_targeting": {"allowed_countries": ["US", "CA"]},
    "supply_trust_minimum": 0.7,
    "budget_daily_cap": 10000.00,
    "budget_total_cap": 150000.00
  },
  "attestation_policy": {
    "witness_granularity": "per_action",
    "block_interval_seconds": 300,
    "receipt_generation": "on_demand"
  },
  "witness_signature": "ed25519:0x..."
}

7.1.1 attestation_policy

7.2 Witness Event

{
  "@context": "https://tunnelmind.ai/atap/context.jsonld",
  "@type": "WitnessEvent",
  "id": "ATAP-WE-018f3c4d-7b2a-7d8e-9f01-4a5b6c7d8e9f",
  "ait": "AIT-018f3c4d-7b2a-7d8e-9f01-4a5b6c7d8e9f",
  "witnessed_at": "2026-05-14T08:00:01.123Z",
  "event_type": "bid:submitted",
  "payload": {
    "exchange": "openx.com",
    "publisher_domain": "example-publisher.com",
    "seller_id": "12345",
    "bid_amount": 1.45,
    "creative_id": "cr-abc-123",
    "sigil_token": "sigil:tok:abc...",
    "supply_trust_score": 0.91
  },
  "prev_event_hash": "0x9f3a8b2e...",
  "self_hash": "0xa1b2c3d4...",
  "witness_signature": "ed25519:0x..."
}

7.2.1 Replay protection

A witness service MUST reject a witness(event) call whose intended witnessed_at would be more than 30 seconds older than the current witness clock. The witness sets witnessed_at itself at signing time; clock skew between the agent and the witness is the agent's problem to handle. This bounds the window during which a stolen credential could be used to back-date events.

7.3 Attestation Block

{
  "@context": "https://tunnelmind.ai/atap/context.jsonld",
  "@type": "AttestationBlock",
  "id": "ATAP-AB-018f3c4d-7b2a-7d8e-9f01-4a5b6c7d8e9f",
  "ait": "AIT-018f3c4d-7b2a-7d8e-9f01-4a5b6c7d8e9f",
  "ab_version": "0.1",
  "profile": "sigil:media_buyer:v1",
  "period_start": "2026-05-14T08:00:00Z",
  "period_end": "2026-05-14T08:05:00Z",
  "first_event": "ATAP-WE-018f3c4d-7b2a-7d8e-9f01-4a5b6c7d8e9f",
  "last_event": "ATAP-WE-018f3c4d-9a8b-7d8e-9f01-4a5b6c7d8e9f",
  "event_count": 1247,
  "chain_head_hash": "0xa1b2c3d4...",
  "period_summary": {
    "bids_submitted": 1247,
    "bids_won": 89,
    "total_spend": 342.17,
    "unique_publishers": 34,
    "unique_exchanges": 5,
    "supply_verifications": 1247,
    "supply_rejections": 203,
    "average_trust_score": 0.84,
    "constraint_violations": 0,
    "channels_used": ["display", "video"],
    "geos_reached": ["US"]
  },
  "prev_block_hash": "0x9f3a8b2e...",
  "self_hash": "0xab12cd34...",
  "witness_signature": "ed25519:0x..."
}

7.4 Receipt

A Receipt is a metadata record that describes the contents of a Receipt ZIP. The Receipt object itself appears as manifest.json inside the ZIP.

{
  "@context": "https://tunnelmind.ai/atap/context.jsonld",
  "@type": "Receipt",
  "id": "ATAP-RCPT-018f3c4d-7b2a-7d8e-9f01-4a5b6c7d8e9f",
  "ait": "AIT-018f3c4d-7b2a-7d8e-9f01-4a5b6c7d8e9f",
  "profile": "sigil:media_buyer:v1",
  "period_start": "2026-05-01T00:00:00Z",
  "period_end": "2026-05-13T23:59:59Z",
  "block_count": 3744,
  "event_count": 4671293,
  "first_block": "ATAP-AB-018ec7a1-...",
  "last_block": "ATAP-AB-018f3c4d-...",
  "chain_head_hash": "0xab12cd34...",
  "witness": "OAI-2026-0000017",
  "format": "full",
  "generated_at": "2026-05-14T09:00:00Z",
  "verifier_url": "https://tunnelmind.ai/atap/verify.sh",
  "keys_url": "https://tunnelmind.ai/atap/keys",
  "files": [
    {"path": "ait.json", "sha256": "0x..."},
    {"path": "attestation_chain.json", "sha256": "0x..."},
    {"path": "summary.json", "sha256": "0x..."},
    {"path": "public_keys.json", "sha256": "0x..."},
    {"path": "verify.sh", "sha256": "0x..."},
    {"path": "compliance_report.pdf", "sha256": "0x..."},
    {"path": "profile_artifacts/", "sha256": null}
  ],
  "witness_signature": "ed25519:0x..."
}

7.5 Receipt ZIP layout

ATAP-RCPT-{uuidv7}.zip
├── manifest.json              # The Receipt object (7.4)
├── ait.json                   # The AIT under which the period was witnessed
├── attestation_chain.json     # Array of AttestationBlocks, ordered, hash-chained
├── summary.json               # Aggregated period_summary across all blocks
├── public_keys.json           # Witness service Ed25519 public keys covering the period
├── verify.sh                  # Reference verifier (bash + openssl + jq)
├── compliance_report.pdf      # Optional human-readable rendering
└── profile_artifacts/         # Profile-specific files; structure defined by profile
    ├── sigil_tokens.json      # Example: media_buyer profile
    └── ...

The layout is frozen for v0.1. Receipts MUST contain manifest.json, ait.json, attestation_chain.json, public_keys.json, and verify.sh. The other files are optional but, when present, MUST conform to this layout.

7.5.1 Why a directory for profile artifacts

The base receipt verifies the chain. The profile artifacts carry the application-specific evidence that gives the chain meaning: for media buying, the Sigil verification tokens that justify each bid; for e-commerce, the order-state attestations; for content scraping, the per-source consent records. Putting them in a sibling directory lets verify.sh succeed without understanding the profile, while leaving an obvious place for profile-aware tools to look.

7.6 Payload constraint: no PII

Witness Event payloads, Attestation Block summaries, and profile artifacts MUST NOT contain personally identifiable information about end users. The following are explicitly forbidden:

What IS in scope: destinations (domains, ASNs, server-side IP ranges, app-bundle IDs), aggregate volumes, timings, prices, capability identifiers, profile-defined trust signals, and any field whose resolution does NOT reach a natural person.

Profile maintainers MUST encode this constraint in their JSON Schemas. Profiles that fail to do so MUST NOT be admitted into the registry (Section 9.3).

7.7 Canonical bytes for hashing and signing

A self_hash is the SHA-256 of the canonical JSON bytes of the object minus its self_hash and witness_signature fields. Canonical JSON is JSON Canonicalization Scheme, RFC 8785. The witness signature on a Witness Event or an Attestation Block is computed over the 32-byte SHA-256 digest that its self_hash encodes — the raw digest bytes, not the hex string. The witness signature on an AIT or a Receipt — neither of which carries a self_hash — is computed over the canonical JSON bytes of the object minus witness_signature. Implementations MUST NOT compute hashes over the raw JSON-LD as transmitted; differences in whitespace, key ordering, or numeric representation would silently invalidate signatures.

The canonical procedure for a Witness Event:

1. Construct the event object with all fields except self_hash and witness_signature.
2. Serialize via RFC 8785 JCS.
3. Compute SHA-256 → self_hash.
4. Sign the 32-byte SHA-256 digest that self_hash encodes — the raw digest, not its hex-string form — with the witness service's Ed25519 private key → witness_signature.
5. Add self_hash and witness_signature to the object for transmission and storage.

The same procedure applies, with the corresponding field exclusions, to Attestation Blocks.

For the AIT and the Receipt, the procedure is identical except that the only excluded field is witness_signature, and the signature is computed over the object's canonical bytes directly — neither carries a self_hash.

Ed25519 conventions in v0.1. Signatures are 64 bytes, hex-encoded as 128 lowercase characters with the ed25519:0x prefix. Public keys are 32 bytes, hex-encoded as 64 lowercase characters with the 0x prefix.

8. Key publication

Public keys for witness services are published at:

GET https://tunnelmind.ai/atap/keys

8.1 Response shape

{
  "keys": [
    {
      "witness": "OAI-2026-0000017",
      "key_id": "k1",
      "algorithm": "ed25519",
      "public_key": "0x...",
      "valid_from": "2026-05-01T00:00:00Z",
      "valid_until": "2027-05-01T00:00:00Z",
      "status": "active",
      "rotated_to": null,
      "compromise_notice": null
    },
    {
      "witness": "OAI-2026-0000017",
      "key_id": "k0",
      "algorithm": "ed25519",
      "public_key": "0x...",
      "valid_from": "2025-05-01T00:00:00Z",
      "valid_until": "2026-05-01T00:00:00Z",
      "status": "rotated",
      "rotated_to": "k1",
      "compromise_notice": null
    }
  ],
  "updated_at": "2026-05-14T08:00:00Z"
}

A key per witness service:

When status is compromised, the compromise_notice object is required:

{
  "disclosed_at": "2026-09-12T14:30:00Z",
  "detected_at": "2026-09-12T13:45:00Z",
  "summary_url": "https://tunnelmind.ai/atap/compromise/2026-09-12.html"
}

8.2 Key selection at verification time

Given a Witness Event with witnessed_at: t and witness_signature, the verifier selects the key where:

key.witness     == event.ait.witness   (looked up via the AIT)
key.valid_from  <= t < key.valid_until
key.status      != "compromised"
   OR (key.status == "compromised" AND t < key.compromise_notice.disclosed_at)

There is exactly one such key at any moment per witness service. If zero or more than one key matches, the verifier MUST reject the event.

8.3 Rotation cadence

Witness services SHOULD rotate keys at least every 6 months under normal operation. Witness services MUST rotate keys within 1 hour of any reasonable suspicion of compromise.

8.4 Compromise disclosure

When a witness service detects key compromise:

1. The witness service MUST mark the key compromised at /atap/keys within 1 hour of detection. disclosed_at and detected_at MUST both be populated.
2. The witness service MUST publish a summary_url describing the incident within 24 hours of disclosure.
3. The witness service MUST rotate the key (publish a successor under the same witness OAI with status: active) within 1 hour of disclosure.

Caching at the edge (Section 8.5) is configured to permit propagation of compromise notices in under 5 minutes globally.

8.5 Caching

Verifiers MAY pin a snapshot of /atap/keys for the duration of a single verification run (typically seconds to minutes). Verifiers MUST NOT pin a snapshot longer than 24 hours; a 24-hour pin is the recommended ceiling. Pinning beyond that risks treating a compromised key as valid.

9. Witness model and application profiles

9.1 The witness is whoever the principal trusts

ATAP v0.1 makes one structural decision the implementation hinges on: the witness is not the agent. The witness is a service that observes the agent's actions, signs them, and chains them. The principal verifies the chain by checking the witness's signature.

This is a weaker trust model than kernel attestation. The witness can be deceived by an agent that bypasses it. v0.1 accepts this trade-off because (a) bypassing the witness is detectable as a chain discontinuity, (b) a documented witness-signed chain is strictly better than today's unsigned campaign logs, and (c) the receipt format is forward-compatible with stronger observation tiers.

For the v0.1 reference deployment in programmatic advertising, Sigil is the witness: the agent calls sigil.verify/supply_path before each bid, Sigil sees the decision, Sigil signs and chains it. No separate observer is required. Other application domains follow the same pattern: choose an interface the principal already trusts, and make it the witness.

9.2 Witness service identification

Witness services are identified by canonical OAI under the witness.operator category. This category was added to OAI v1.0 §3 as an editorial expansion on 2026-05-14 alongside the publication of this standard. Existing witness services that hold sensor.operator OAIs MAY continue to use them; new witness services SHOULD register under witness.operator.

9.3 Application profiles

A profile is a published document that defines, for a specific agent domain:

1. The vocabulary of event_type strings the agent's witness emits.
2. The JSON Schema for each event type's payload.
3. The JSON Schema for period_summary aggregation.
4. The JSON Schema for constraints in the AIT.
5. The contents of profile_artifacts/ in the Receipt ZIP.

Profiles are identified by a colon-delimited string of the form {namespace}:{domain}:v{N}. Examples:

The profile registry is published at https://tunnelmind.ai/atap/profiles and the source-of-truth repository is https://github.com/TunnelMind/atap-profiles. Third-party profiles MAY be registered subject to the constraints in Sections 7.6 (no PII) and 9.4 (acceptance criteria).

9.4 Acceptance criteria

A profile proposal is accepted into the registry if all of the following hold:

1. The proposed JSON Schemas validate as JSON Schema 2020-12.
2. The Schemas encode the PII prohibition of Section 7.6 — verified by automated test cases the proposer includes in the PR.
3. The proposed namespace token is not already claimed (first-comer wins).
4. The proposal includes at least one signed example AIT, Witness Event, Attestation Block, and Receipt that round-trip through the reference verifier.

Profile proposals are PRs to github.com/TunnelMind/atap-profiles. CI runs the four checks above and auto-merges PRs that pass within 7 calendar days, absent an editorial objection (Section 12.2). The editor's hand-review is reserved for scope and conflict cases.

9.5 Profile authority and collisions

The proposer of an accepted profile is its authoritative maintainer. ATAP v0.1 does not arbitrate when multiple parties want the same domain: they get separate namespaces. sigil:media_buyer:v1 and acme:media_buyer:v1 MAY coexist; verifiers select the profile referenced by the AIT they are verifying.

10. Hash chain and transparency

10.1 The chain

ATAP maintains two parallel hash chains per AIT:

flowchart LR
  subgraph Event chain
    E0[WE-0\nprev=0x00] --> E1[WE-1\nprev=hash E0] --> E2[WE-2\nprev=hash E1] --> Edots[...]
  end
  subgraph Block chain
    B0[AB-0\nprev=0x00\nhead=hash E_n] --> B1[AB-1\nprev=hash B0\nhead=hash E_m]
  end
  E2 -.->|chain_head_hash| B0

• The event chain binds Witness Events in monotone order. Every event's prev_event_hash is the previous event's self_hash.
• The block chain binds Attestation Blocks. Every block's prev_block_hash is the previous block's self_hash.
• A block's chain_head_hash references the self_hash of the last event it covers, binding the block chain to the event chain.

A break in either chain is a verification failure.

10.2 Genesis

The first Witness Event and the first Attestation Block for an AIT use the constant prev_event_hash and prev_block_hash of 0x0000000000000000000000000000000000000000000000000000000000000000 (32 zero bytes, hex-encoded — 0x followed by 64 zero characters).

10.3 Hash algorithm

SHA-256 over canonical JSON bytes (RFC 8785). v0.1 ships only SHA-256. The signed quantity for each Witness Event, Attestation Block, and Receipt is the raw 32-byte hash; the wire form prefixes 0x.

10.4 Transparency log (deferred to v1.x)

A public append-only log of Attestation Block heads, modelled on Certificate Transparency (RFC 6962), is the strongest near-term addition to the trust model. v0.1 reserves the URL https://tunnelmind.ai/atap/log and the optional Attestation Block field log_index. Verifiers MUST tolerate log_index values that cannot yet be checked against a live log endpoint; the absence of a log does not invalidate a v0.1 receipt.

The transparency log is on the v1.x roadmap, scheduled to land once ATAP has measurable external adoption (see Section 12.1). It is not a v2 deliverable; v2 work (post-quantum, federation) is downstream of it.

10.5 What the chain proves

The chain proves:

• Append-only. No event was inserted, removed, or reordered after the next event was signed.
• Witness attribution. Each event, each block, and the AIT itself was signed by the declared witness service.
• Period coverage. A receipt's chain head matches the last block in attestation_chain.json; if any block was omitted, the chain head will not match.

The chain does NOT prove:

• That the agent did not perform actions outside the witness's view. (Mitigated in later versions by stronger observation tiers.)
• That the witness's signed events accurately reflect reality. (Mitigated by witness reputation, witness-OAI registry, the transparency log when shipped, and out-of-band evidence.)

These limits are honest; the standard does not promise what its trust model cannot deliver.

11. Verification

11.1 The reference verifier

verify.sh is a single-file bash script using openssl and jq, intended to be readable in one sitting. It is published at:

https://tunnelmind.ai/atap/verify.sh

and is included verbatim in every Receipt ZIP. The verifier:

1. Parses manifest.json and validates the SHA-256 of every other file matches the manifest entry.
2. Validates the AIT's structure against the v0.1 schema and verifies its witness_signature against the appropriate public key.
3. Walks the event chain in attestation_chain.json (or the block chain in summary format), verifying each block's self_hash, prev_block_hash, chain_head_hash, and witness_signature against the keys in public_keys.json.
4. Reports per-block status to stdout; exits 0 if every block verifies, 1 otherwise.

11.2 Reference TypeScript wrapper

A TypeScript implementation of witness(event) is published as:

npm: @tunnelmindai/atap
source: https://github.com/TunnelMind/atap/tree/main/packages/atap-js

The wrapper is non-normative; it is provided to lower the cost of correctly integrating ATAP. Implementations in other languages are welcomed and need only conform to Section 7 and Section 10.

11.3 Verification environments

verify.sh runs anywhere bash 4+, openssl 1.1+, and jq 1.6+ are present. The reference TypeScript wrapper targets Node 20+ and ESM. No managed runtime, no specific cloud provider, no vendor dependency. This is load-bearing for adoption: a verifier that requires the principal to trust a specific cloud cannot become the citation format.

12. Governance

12.1 Editor

TunnelMind edits ATAP v0.1. TunnelMind is a single-operator project, not a foundation, not a consortium, and not a venture-backed entity. There is no board, no token, and no third-party investor with editorial influence. The editor's role is provisional; the conditions under which it transfers to a neutral host mirror those in OAI v1.0 §12.4 — external adoption (three or more independent organizations publishing ATAP receipts), standards-track recognition (IETF / W3C / MITRE citation), and operational maturity (99.9% key endpoint uptime, zero canonical-URL breaks) sustained over two consecutive quarters.

12.2 Conflict of interest

TunnelMind operates Sigil, a commercial witness service for media buying that consumes ATAP. To bound the conflict:

• Profile acceptance follows the published automated criteria in Section 9.4 and is not influenced by whether the proposing party is a customer, partner, or competitor of TunnelMind's commercial products. The CI checks are public and reproducible; their pass/fail decision is not subject to editor override on technical grounds, only on scope grounds.
• Editorial decisions on scope, schema constraints, and out-of-scope exclusions (Section 4) are public and reversible only by a versioning event (Section 13).
• The editor MUST NOT accept payment, sponsorship, or grant funding in exchange for profile acceptance or schema changes. Funding not tied to specific schemas or profiles is permissible and MUST be disclosed at tunnelmind.ai/atap/funding.

12.3 Automated workflow

The editor's stated commitment is to not be a bottleneck. To that end:

These SLOs are tighter than OAI's because the automation makes them feasible; OAI's longer windows reflect manual issuance decisions that ATAP does not require.

12.4 Continuity

The protocol spec, the JSON Schemas, the reference verifier, and the reference TypeScript wrapper are open: the spec is licensed CC BY 4.0 and the code artifacts are MIT-licensed. A current snapshot of the spec, schemas, profile registry, and public-key archive is publicly downloadable at tunnelmind.ai/atap/archive/ and updated at least monthly.

In the event the editor cannot operate the standard, the canonical URLs (/atap/standard, /atap/keys, /atap/verify.sh, /atap/profiles) MAY be repointed to a successor neutral host with a 301. Receipts issued under v0.1 continue to verify against the archived public keys regardless of editor identity.

12.5 Editor failure modes

A single-operator editor has failure modes a foundation does not. Even with automation:

• Profile review hand-cases. Conflicts between proposals competing for the same scope, or proposals raising novel PII or scope concerns, require editor judgment. The 7-day auto-merge SLO does not apply when the editor opens a hand-review on a PR. Hand-reviews target 14 calendar days.
• Capacity ceiling. If editorial workload exceeds what the automation plus the solo editor can sustain, the editor invokes the Transition RFC ahead of the standard-transfer gate. Premature transition is a recognized exit, not a failure.

These constraints are honest about scale rather than aspirational about it.

13. Versioning

ATAP follows semantic versioning at the standard level, not the receipt level.

v0.1 is pre-stable. The schemas in Section 7 may evolve through v0.1.x without breaking already-issued receipts. Once v1 is published, the v1 schemas are frozen at additionalProperties: false for the lifetime of v1.

A v2 verifier MUST verify v0.1 and v1 receipts.

14. Locked positions and forward-looking work

This section records decisions that v0.1 commits to, distinguishing them from items genuinely deferred. Public comment on the locked positions is welcomed; the editor's prior is that they hold for v1.

14.1 Receipt revocation: LOCKED — immutability

Signed-and-shipped receipts are immutable. There is no protocol-level revocation. The only remediation path is witness-key compromise (Section 8.4): when a key is marked compromised, downstream verifiers downgrade receipts signed by it after disclosed_at to invalid, and receipts signed before disclosed_at to unverified (policy-dependent). Corrections to recorded reality go in a new chain under a new AIT.

Rationale: a revocable receipt is not a receipt. A compliance receipt's value is that the principal can verify it without coordinating with the issuer. A retroactively editable receipt collapses to a self-report. The cost of immutability is that erroneous receipts cannot be redacted; the standard accepts this cost.

14.2 Profile-domain collisions: LOCKED — first-comer wins, no editor arbitration

Multiple parties wanting the same agent domain (e.g. two different organizations proposing competing media_buyer profiles) get separate namespaces: partyA:media_buyer:v1 and partyB:media_buyer:v1. The editor does NOT arbitrate competing technical claims. Verifiers select the profile referenced by the AIT they are verifying.

Rationale: arbitration introduces editor bias risk and a slow path. Separate namespaces are honest about disagreement and let the market converge by adoption.

14.3 Algorithm agility: LOCKED — SHA-256 + Ed25519 frozen at v0.1

v0.1 ships SHA-256 and Ed25519 exclusively. v2 MAY add (not replace) post-quantum signatures and SHA-3 hashes. During the v2 transition, every artifact will be signed and hashed in BOTH the v0.1 algorithms and the v2 algorithms, so that v0.1 verifiers continue to function. v2 receipts retire only when the surrounding cryptographic environment retires SHA-256 / Ed25519.

14.4 Witness federation: DEFERRED to v2

v0.1 binds each AIT to exactly one witness service. Multi-witness co-signing of events (a stronger-assurance pattern for high-stakes domains) is deferred to v2 governance.

14.5 Cross-AIT linking: OUT OF SCOPE for v0.1

The same operator running multiple AITs across instances, time, or business units is identified at the OAI operator level (the operator field). No protocol-level AIT-to-AIT linking is provided in v0.1.

14.6 Privacy-preserving aggregation (zero-knowledge attestations): RESEARCH

Zero-knowledge proofs over sensitive aggregate signals (e.g. attesting "total spend was under cap X" without revealing the exact value) are a research direction. They are not on the v1 roadmap. Profiles needing this capability today should structure their period_summary to omit sensitive values rather than mask them.

14.7 Transparency log: SCHEDULED for v1.x

The append-only log of Attestation Block heads (Section 10.4) is the highest-leverage near-term addition to the trust model and is the first v1.x priority once external adoption is measurable. URL /atap/log is reserved.

Appendix A. References

• RFC 3339 — Date and Time on the Internet: Timestamps
• RFC 5234 — Augmented BNF for Syntax Specifications: ABNF
• RFC 6962 — Certificate Transparency (model for the future transparency log)
• RFC 8032 — Edwards-Curve Digital Signature Algorithm (Ed25519)
• RFC 8785 — JSON Canonicalization Scheme (JCS)
• RFC 9562 — Universally Unique IDentifiers (UUIDs), including uuidv7
• JSON Schema 2020-12 — https://json-schema.org/draft/2020-12/schema
• JSON-LD 1.1 — https://www.w3.org/TR/json-ld11/
• NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA, referenced for v2 post-quantum direction)
• OAI v1.0 — https://tunnelmind.ai/oai/standard (companion standard, identifier scheme for witness services)

Appendix B. Implementation references